Large service design
I have an application I need to expose via a Web service. The application is large and complex, covering a lot of scope. There are approximately 100 different request message types that the service must consume.
Is the intent of a WCF .svc file to expose the entirety of a service? Or should a complex service contain many .svc files (in which case a .svc file really represents a message handler rather than an entire service)?
If the intent is to access the entirety of a service via a single .svc file, then I would need to implement a service component with 100 methods! This would be an overly complex class.
If the intent is to implement the service as many .svc files, then how could I expose the functionality of the service with a single automatically generated WSDL file? Should a service's definition be split between many
WSDL files?
It seems the ideal balance would involve exposing many "message handler" classes via a single .svc file (and thus via a single WSDL file). Although this doesn't seem possible with WCF. Any guidance in this matter would be much appreciated.
Hi Bill,
If you're using Metadata Exchange, than your wsdl will be very large, and you cannot split it to smaller files, since it is generated in runtime.
I have a few questions that will help to decide whether this approach is good for you or not:
1. Are all your service operations logically related? You can place Customer module operations with Orders module operations technically, but according to the SOA tenets, services should be autonomous.
2. Do all your service operations share the same policies? I mean security requirements, transactions, instancing management? Policy differences usually make you consider whether to split the services.
3. Should all clients access / use all the service functionality? If a client uses Orders module, does it mean that he will use the Customers module?
4. Physical deployment - When splitting to smaller services, you can deploy your services in different machines, set the cache utilization according to the services that are deployed on a specific machine, and get better performance. Additionally, If you move or update a service, does it mean that you have to update all the other services?
Hope that helps,
Guy Burstein
http://blogs.microsoft.co.il/blogs/bursteg/
http://www.bursteg.net/
Hi Guy,
Thank you very much for your speedy reply. Each question is answered below:
1. All the operations relate to the Underwriting function of a small insurance carrier. There are a lot of configurable elements relating to risk assessment and premium calculation such as :
* commissions and retail rates pertaining to Dealers, Agents, Sub Agents, Distributors, Administrators and Dealer Groups.
* rate charts
* risk point charts
* vehicle build directory
* product disclosure statements
* products and cover types
* government charges
All of this configurable data is needed for the purpose of rate calculation and risk assessment - which I would want performed by a single autonomous service. I need maintenance screens for all of the above (and a little more), so I need service interfaces through which to interface my smart client application for that purpose.
In addition to the above, there are about 30 types of messages that relate to the actual underwriting process itself.
This is a *lot* of scope to cover from a single .svc file.
I will have a separate service to manage the Claims side of things, as well as a separate CRM service, location directory service, payment service and identity management service. It is just this very large Underwriting service which is giving me the most grief.
2. As far as I can tell each of the Underwriting service operations will share the same policies - although I will need to give this some more thought.
3. As it currently stands, there will be only 2 clients using the service(s) - a smart client application, and a process orchestration engine. The process orchestration engine will not likely need much access to the "maintenance" service interfaces - but other than that, all interfaces will be used by both clients.
4. At this stage, I can't see a need for the differerent Underwriting sub-functions to be seprately deployed.
Thanks again for taking the time to respond to my query. Any further insight you could give would be most appreciated.
Bill Poole
