I have a WCF web service that implements a RESTful interface. We're using the InstanceContextMode of PerCall, and are looking for options to use for caching objects for reuse on subsequent calls.
We're looking to override/extend the WCF Context logic in order to create/maintain/clean up objects to be shared among implementation methods of a PerCall service interface.
I'd also like to see a diagram of the objects created/used during a call to a WCF interface. I have a very nice one for ASP.Net event calls, but I haven't found anything for WCF. I'm not sure which classes to override or interfaces to implement to interject my own logic into the WCF call hierarchy for persisting objects between calls.
If you are looking for events happening, this is a must read - there are very nice diagrams there as well.
Objects created very much depend on your configuration. With WCF REST, I imagine it must be small.
If I were you, I would not go down the route of caching and solving a problem that does not exists - or at least I assume so from your question. PerCall is the only scalable setting. Also I imagine a REST service would be designed as stateless anyway.
Related
Let's say i do have a service, which is just a REST-API. This rest api provides some data.
As far as i understand, which makes sense, I can encapsulate data, which is sent from and to this service into DTO's. This totaly makes sense, since you'll have some business objects but often you'll need to serialize them in a way. So as far as i understand this would be a generally accepted and know way to abstract it regarding this part.
Then this DTO's are sent trough the REST-API. Regarding the server side it seams pretty straight forward, having some controllers which provide the data or receive them, I'm not seeing any issues there (at least for now).
So regarding my question. On the client side there are objects, which will access this API, this object, in my implementation contains a http client (not sure maybe i decouple them from this objects) and also it contains methods to access the api. So in one way or another, abstracting the use of http client and accessing the API away.
HOW DO YOU NAME THIS OBJECTS ACCESSING THE API?
I'm now naming them XXXManager/XXXHandler/..., but this names feel far to generic and i feel like there has to be some convention or pattern for this? Naming them XXXService also does not feel not completely right, because service for me is like the server side part, this object are accessing the service.
So how would you name this kind of objects and are there some deeper patterns to handle this kind of service/api accessors?
The model/pattern that would work here, is a classical layered architecture, which works like that:
The HttpClient should be wrapped around a class (let's name it ApiClient) that exposes methods for accessing the REST API. In each of those methods, the httpClient is used to execute the HTTP call.
There is a layer of Service/Manager classes that use the ApiClient and also apply their own business logic.
There is a layer of UI components which also inject the Services/Managers to grab the data and render it on the UI.
In this way you decouple the layers, which improves both the scalability and the testability of your code.
The naming somehow depends on the type of the client-side implementation/framework that you have.
If you have a web-frontend client, then the name TransactionService would tell me that this class talks to some external transaction service (Service is not a naming tied to server-side components).
This naming model applies to Angular, for example.
Patterns of Enterprise Application Architecture suggests Gateway, but I'd just go with Client.
I have a web service that's ~200 methods strong, implemented using .Net + WCF in a standalone service.
we're modelling the backing code to use different handlers for different methods,
but eventually there's still that one monolithic interface...
I used (and loved) RESTful interfaces in the past, especially for the way they break up a single interface into separate domains.
can that be achieved using web services, without splitting the web service?
would love to hear thoughts on the matter.
Why couldn't you define multiple WCF contract interfaces, all to be implemented by the single web service class, which you don't want to split up. You would then expose each interface as a separate service, and they just all happen to be covered by the same class.
I believe Jimmy Nillson said he generally made his webservices singletons. Is this the preferred method, and with WCF? Other than making the service methods static, is there something else to be done?
good responses, but I think there is a problem in the original question. "Typical use" of a technology is a poorly formed question. No one has a "typical" scenario, and you should review the requirements of your particular problem before deciding on an implementation or approach. Your requirements should inform your solution.
For instance, Singletons [ie the Singleton pattern] is just another tool in our box, and like any tool, there are cases where it works, and others it does not. Specifically, if you need to centralize business logic [more applicable in a standalone application than a remote WCF service], or share memory or a resource, a Singleton works well. Of course, if you are sharing business logic, state is maintained in the call stack, and multi threading is moot. If sharing memory between consumer calls, then multi threading is an issue. As regards WCF, there are two modes [actually three, but the third is a special case of the first] of multi-threading behaviour you can specify,
// we are specifying that this service implementation is single-threaded
// and WCF should permit *at most* one call at a time. Any requests made
// simultaneously/concurrently are queued.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
public class SingleThreadedNonThreadSafeService : IService { ... }
and
// we are specifying that this service implementation is multi-threaded
// and [hopefully!] thread-safe. WCF should permit any number of threads,
// or any number of simultaneous concurrent calls.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
public class MultiThreadedThreadSafeService : IService { ... }
The Xml comments for ConcurrencyMode basically say the same thing as above.
If you DO NOT need to share business logic or memory between consumers, then DO NOT use a Singleton, the "model" DOES NOT fit the problem. It's like forcing a glass slipper on a step-sister's foot! And no one should ever have to see that.
Conversely, if no state is shared between calls, host an instance per-call\session.
Typically NOT. Singletons are a mess, since to make them perform well, you'll need to make them multi-threaded, and that's just asking for trouble unless you really really really know what you're doing.
The best practice for WCF is to use per-call instantiation - each request gets its own copy of the service class, no multi-threading worries, good performance - store anything that needs to persist in a database - works like a charm.
The only real scenario where singleton might make sense is if you have to have all service request be using/handled by a physical resource that's available only in a single instance - if your singleton service serializes and thus protects a single resource, then it makes sense to use it.
Otherwise - spare yourself the trouble! :-)
Singleton WCF services should hardly ever be used- Singletons are the enemy of scalability! They only make sense in weird scenarios- logging to a single file, a single communications port or hardware device.
As Marc says the best choice for scalability with WCF is per call services (they offer the best trade off between performance and scalability). Per call services also work very well with load balancing.
WCF promotes good design by using interfaces and contracts etc. What baffles me is that, for example in my case if I have 2 sets of business functionality like ICustomerMgmtBIZ
and IProductMgmtBiz. If these two are ServiceContracts, and I have an interface like
IBusinessService:IProductMgmtBIZ,ICustomerMgmtBIZ
and implementation class BusinessService. I see that BusinessService class will be having too much implementation. The workaround I have been using so far is by implementing partial classes.
So bluntly put, can a WCF service have only 1 implementation and 1 service contract ??
No, it is possible to implement more than one Service contract on a WCF Service type (the class that is attributed with the ServiceBehavior attribute), since it is just a matter of having the class implement multiple interfaces. If you are using any of the Visual Studio templates or other kinds of code generators, this may not be immediately clear. However, although you can implement more than one Service Contract interface on a Service type, it does not do you much good if you need the service, presumably a singleton in this case(?), to behave as one service. IBusinessService implies that you need all of the service's functionality to be callable from one client proxy, so that all operations may operate in the same logical session (similar to ASPX web session). If that is not the case, then you are free to define individual proxies for each contract interface, but that will also require that you support one endpoint for each contract.
Is it an absolute requirement that you can only have on WCF ServiceHost instance for your implementation? What factors are influencing your decision?
By the way, partial classes do not trouble me anymore. The idea of splitting out code into multiple files now seems rather natural. For example, storing partial classes in files like ServiceType_IProductMgmtBiz.cs and ServiceType_ICustomerMgmtBIZ.cs seems natural enough, in addition to storing the core logic in ServiceType.cs.
Finally, the following question might be of use...
WCF and Interface Inheritance - Is this a terrible thing to do?
Bluntly put, no - sort of - yes, but. Any workaround is non-optimal and involves using an "IBlank" as a master WCF interface (where your interfaces derive from IBlank), and two endpoints, one implementing IProductMgmtBIZ and the other implementing ICustomerMgmtBIZ. I don't have my dev machine in front of me, this might involve some other overrides. So, at the WCF level you're screwed unless you want to have two WCF ServiceHosts (which is perfectly reasonable).
In short, the workaround is inelegant. Its easier to have two WCF endpoints on the same port with a different extension.
I am developing a WCF web service which has become quite bloated. What techniques do you use to split up the implementation of the contract?
Well you have a couple choices:
First, you could leave it all in one class, but split up into different files using the partial class feature of C#.
Second, you could have the main service class just pass requests off to one of a number of other actual classes that are organized logically.
A third alternative is to consider refactoring to reduce the number of operations you have. Is there actually a use to all of the methods you're exposing?
Finally, you could always split up the service into multiple WCF services.
It's hard to answer your question if you don't give any more information.
Do you mean that your service interface is bloated, or the class implementation? It's hard to answer well, if I don't see the code, or have no other information, anyway, I'll try:
Notice that WCF service is basically just a regular class that implements an interface and has some attributes on its methods. So all the other good OO design rules apply to it. Think about what it does, does it have really single responsibility, if not try to outsource some of that responsibility to other classes that your service depends on. If you need a non-default constructor, use IInstanceProvider to create the service class, and supply it with its dependencies (or if you use Windsor Container use WCF Facility).
If you really want to you can streach your inheritance chain, and move some of the code to a base class. I don't do it, however and always prefer to use composition over inheritance.
Inspect your service contract, and think about how cohesive it really is. Maybe what you should do is to split it, into few smaller, more cohesive services.