There are several categories of services. Many leading SOA vendors and thinkers typically break them down into Business and Utility types. A Business service represents a business capability that is needed to complete a step within a larger business process. Examples may include retrieving customer information, making payments, or checking order status. Utility services represent a technical capability that is business process agnostic. Examples are e-mail, logging, or authentication services.
Services can be combined together to create composite services. This is called orchestration. An example of this can be a Money Transfer service that needs to debit one account and deposit money into another one. Composite services can also be categorized as Business and Utility. Best practices and general orchestration guidelines as related to orchestrations, atomic services, and their relationships will be discussed separately.
Regardless of the type, a service is comprised of three components.
- Interface
- This defines how services are exposed and can be accessed by its consumers.
- Interfaces are not limited to Web Services and can be represented by any remote messaging protocol.
- Contract
- This defines what services expect during the interaction with the consumer. Message structures, relevant policies, and related security mechanisms are all part of a contract.
- Contract defines a “legal” agreement on how the service and its consumers should interact.
- Implementation
- This is the actual service code.
A service may also have multiple contracts. I have recommended in the past that for a service to be maximally reusable, it needs to implement the Service Façade pattern (see “SOA Façade Pattern” post and “Service Façade” pattern). This pattern recommends that multiple different interfaces and contracts for the same service be created. The Concurrent Contracts pattern also addresses this issue.
It is important to understand that while the interface, contract, and implementation describe a service as a whole, they are not closely tied together. An interface is not dependent on the contract details and should not be tied to the specific messaging structure. The opposite is also true – the contract should not be tied to any specific communication protocols. Additionally, the implementation should be flexible enough to accommodate the potential for multiple interfaces and contracts. Ideally, however, I would recommend that a service expose only a single contract and interface and the ESB would take care of exposing additional endpoints and facades as necessary.
3 comments:
Hi Leo, thanks for a useful blog. If we look at your definitions from an OO perspective is a web service similar to a class in that a particular service, for instance the client service, might contain multiple operations, create a new client, update a client, delete a client each with it's own contract and implementation, or is a web service similar to an operation, so in my earlier example there were actually 3 services, create a new client, update a client and delete a client?
Thanks - TY.
Tony,
thanks for your comments. You've asked a very interesting question. While from the pure SOA perspective, each operation should be treated as a separate service, the technical details of the SOAP protocol do not allow this to be easily achieved. Each web service operation should be related to the others in the same WSDL but it represents a distinct business capability or utility function. Thus, every operation should be treated independently from others and should be allowed to have its own interface(s) and contract(s). However, web services, by definition, are coupled with a specific protocol (SOAP over HTTP), although other communication mechanisms such as MQ, for example, are becoming available. WSDL represents a complete contract. While you can define specific contract terms for each operation (message details), some high level provisions, such as security and policy, can only be specified for the whole service. You can create a separate WSDL for each operation but it will defeat the purpose of the SOAP protocol. To allow each service operation to be fully flexible and be able to define multiple interfaces and contracts, ESB should be used. I believe that a service itself should not have to worry about variability in access patterns from different consumers but rather let SOA infrastructure such as ESB handle this. Thus, I would recommend defining the most appropriate contract through the web service endpoint and maximize its flexibility and reuse potential through the ESB-exposed endpoint(s).
Hope this helps.
Leo
thank you for sharing this wonderful information..
Get Best Info for Garage Doors Elk Grove
Post a Comment