Currently VS 2015 Update 2 provides an easy way to create owin based stateless web api service using create new service template for service fabric application. Is there a reason why only stateless web api service template is provided and not stateful web api service? If I wanted to, can I modify the stateless web api service to derive from stateful web service? Is it that simple? Or are there any gotchas with this approach?
Web Api is intended to be facade/public entry point to the service fabric app. Being stateless saves the clients from dealing with resolving partitions/addresses and other hassle.
If you want to - you can modify web api service and make it stateful. Maybe it would be even easier to create stateful service from the template, install missing packages (that web api template has), copy OwinCommunicationListener and Startup, wire them into CreateServiceReplicaListeners override, and add valid service endpoint to ServiceManifest.xml. OwinCommunicationListener will provide unique address for each replica.
Yup, you certainly can modify it to be stateful. Web API is great for internal service-to-service communication as well as a public-facing API.
There is a caveat that we are currently working through: The web host for stateless uses Kestrel, which presents some difficulties for stateful services where multiple replicas share the same process, because Kestrel doesn't have the same port-sharing capabilities that http.sys-based hosts do. We're working on a solution that makes it easier to use Kestrel for stateful, but in the meantime you can always use the WebListener host, which is the http.sys-based host.
If you're interested, I'm working on a project that will have an ASP.NET Core 1 stateful service (among other cool things) that you can track here: https://github.com/vturecek/service-fabric-xray.
Related
What I know so far is that:
Api gateway: Is fixed entry point that manage north/south communications.
Service Mesh: Is a side-car proxy that manage inter-service communication east/west.
service registry: Is a database of services, their instances and their locations.
All sound clear, but when I try to put all things together, I am confused:
Most of the service mesh/api gateway vendors say that they provide
access control mechanisms and other similar mechanisms, are these mechanisms an overlapping
functionalities between both concepts, or they have different scope
and goals?
Assume all Api gateway, Service Mesh and Service registry are deployed together:
Does the api gateway forward the request directly to the service, or
it communicate with service proxy?
Do I have to register a service twice, one in the gateway and one in
the service registry? or how to integrate the service registy with api gateway?
Finally Until now it seems for me the all concepts purely serve different purposes so they all necessary, but they overloaded with other functionalities. Is it possible to integrate them in meaningful way? or is there a reference architecture that I can follow?
Because no one posted an answer and based on my continuous reading, I was able to grasp a basic idea of how all components should work together, I will not answer directly to question, rather I will try to make things more clear:
API Gateway or Service Mesh are nothing just proxies, but with that said they are proxies of different types.
API Gateway is a front-proxy or edge-proxy, through it you communicate with the world. so in your architecture you may have an API Gateway running with or without Service Mesh beeing deployed.
To register your services in your Gateway you have two options(maybe more):
Static registration: using configuration file or using the Admin API of the API Gateway you are using, this is similar of how KONG work.
Dynamic registration: usually this is done by integrating your Front-proxy (API Gateway) with some other Service Registry/Discovery tool. you can accomplish that for example using Envoy and consul.io.
Using only Front-proxy (without service mesh) It is hard to do health monitoring, Logging and let all service know if it’s pointless to try to contact a down service(Circuit breaker).
Now, if you need to isolate your services from the topology of the network, or you need to provide a set of functionality around each of your services such as, mentoring, Logging, retries, circuit breaker..etc, then you can accomplish that by deploying a process (beside each service) that proxies all the out and in requests to your service. This process what we call a sidecar proxy. All the sidecars proxies usually run the same code, but they are configured differently.
Finally: The combination of the edge-proxy (API Gateway ) and the sidecar proxies forms what we call a Service Mesh. And obviously all proxies can utilize the same service registry/discovery mechanism.
I have an ASP.NET Web API 2.0 OData service project which I am trying to relay via a service reference + WCF Data Service (5.6) through an ASP.NET MVC project—the reason I am doing this is so users browsers’ can access the service without worrying about CORS for IE8 and IE9— so they will have the same host.
After some tinkering, this setup mostly works however there are some problems, my setup:
Service Project
1) ASP.NET Web API 2.0 OData endpoint
2) WCF Data Services 5.6 OData endpoint + Entity Framework 6.0.2 (EntityFrameworkDataService<DBContext>) using WCF Data Services Entity Framework Provider (1.0.0-alpha-2)
When I directly access both of these services they perform flawlessly with whatever I throw at them—both through a service reference, LINQPad, and raw URLs. Then I setup the ASP.NET MVC project:
ASP.NET MVC Project (relaying service references above): WCF Data Services 5.6, (DataService<ServiceReference-1-or-2>)
The problems come when I try to perform the same queries on the WCF Service acting as a relay:
Relaying (1) with $inlinecount=allpages gives me: “An error occurred while processing this request.”
Relaying (1) and (2) with $select=... both give me: “Not Implemented”.
When I relay a dummy POCO context through the reflection provider all of the operations work flawlessly on the relay WCF Data Service, which leads me to suspect that the problem is in the combination of WCF Data Services and the Service Reference, as they both work without problems independently… Perhaps the WCF Data Service is examining the LINQ Provider for the service reference and arbitrarily deciding that it does not support the operations?
I could live without $select but not having $inlinecount is a deal-breaker. There are a couple of alternate solutions I could take but I would really like to make this approach work: any ideas?
This was very similar to: WCF Data Service - Proxy mid-tier service
In a nutshell: you can have a relay by either
1) Making the service believe it is at a different URL than it is (so it is effectively broken for all access except through the proxy).
or
2) By writing another service which manually does the relaying to the service reference...
I chose none of the above and restructured my service as Web API Owin middleware. I lost the ability to have a separate service deployment but can easily swap in another piece of middlware and it makes CORS issues non-existent.
I am using AMX Service Bus 3.2. and trying to expose my rest services (ASP.NET WebApi) through the TIBCO Active Matrix. Unfortunately I have not found any way to do this in TIBCO business studio.
I found TIBCO Active Matrix Binding Type for REST but it is intended only for promoted services. It allows to expose SOAP services via REST interface but it is unable to invoke my REST services hosted on IIS.
As for now I see the only one way to implement that - Create addition SOAP service that will redirect HTTP request from Promoted service to my REST Service. But such solution is not very good SOA design.
Any help is appreciated.
We are planning to develop a big application in web, our current plan is to create a WCF service for each class in the Business layer. Is this effective? I want to know where can we use WCF in a big web application and main advantages of using it
we have these projects
1) MVC3 with Razor that handles UI
2) Class Library Project that communicate with Database
3) WCF Project
Method we using
1)Creates UI and Model in MVC
2)Makes dll that communicate with UI (eg:Save function/Update function) using ClassLibrary Project
3)The Class Library Created is Added (Added to Bin) in WCF Project
4) Builds the WCF and Host It in Server
5) The Hosted Service is Used in MVC Project for Communication with DB
Our Technical lead is saying it is light weight and more secure but i am wondering why he is saying to use WCF for whole appication
First ask this question, why do you need a service layer, when it could be achieved by a separate application. If you want to achieve this for just loose coupling, then it does not makes sense.
In my opinion, the service layer would be useful for exposing your data (dal-layer) and not Business Layer. For example take twitter. Twitter exposes it data over Web Services. What you do with the data is completely your interpretation. The data could be consumed by many application over HTTP. So your client could be remotely situated and need not to be on the same server as your application. The business layer could change based upon interpretation of data. The consumer, then need to worry about latest changes and including latest DLL. It will just consume the webservice. Also mocking your service would be pretty easy and you could write your NUnits tests very easy on your Business layer then. I would also recommend you to have a look at ASP.Net Web API, which provides restful way of exposing your services and data(with inbuilt capablity of exposing it as JSON). The RestFull service has many advantages over WCF, like you then need not to worry about WSDL and etc. The interface always remains same. Consuming a RestFul service is very easy.
As again with the twitter example. The clients consuming twitter api's are not situated on same server. So it makes sense to expose it over HTTP.
But if you do not have such a requirement(Client is not remotely situated), then exposing your data over web services does not make sense. Then a separate application will give you loose coupling and that should be good enough for you. Also exposing data on HTTP will have some performance impact too.
UPDATE 2
I understand the scenario you are trying to implement and I think its perfectly allright. By light weight he means, from your WCF service he would do interaction with Database and then send light weight DTO's for each action and controller as per requirement. So basically your WCF would do nothing but invoke methods from your class library, would fetch some Business Object and Convert it back to DTO(as required by your action to render UI) and send it to Controller.
Also make sure, you use Dependency Injection for your Services, so that you could write NUnit tests for your controller with mock data and hence no requirement of Database for running your NUnits
My preference is to have the service layer be a completely independent application that can be consumed by many applications. It makes projects, especially large ones, much easier to scale, than if you were to create your service layer inside a single web application.
Unfortunatly to tell you. Using WCF is less effective. The main purpose to use WCF it to let your data can be accessed with any client application. not just web application. you may also have a Silverlight or winform. WCF has nothing to do with "A BIG" web app.
So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))