This is in continuation to my previous post covering the basics of Service Oriented Architecture. Today I am going to cover what constitutes a “service”.
Service is a self-sufficient unit of work representing a specific business function, accessible through well defined interfaces, governed by a service contract.
The idea of a service begins with identifying business functions which are good candidates for been classified as “service”. In a business application, there will be certain business functions which are needed by business applications within the enterprise applications or by other enterprises.
To understand this better, let’s consider a representative business process. Let’s use the US based life insurance application flow from application submission till policy issue/decline as our example. An applicant fills in the insurance application and submits the application. Post application submission, typically the following business activities are triggered:
Product Validation: Validate if the applicant’s age, gender, policy face amount, policy issue state is within the product permissible limits/ranges
Agent Validation: Validate if the agent code is valid, the agent has a license to sell the life insurance, the agent or his/her parent agency has been appointed to sell the specified insurance product within the state
Total Amount of risk: An insurance company needs to verify that the applicant is not overinsured. Each insurance company defines a specific total face amount limit beyond which they do not accept new policies or accept them only if adequate reinsurance cover is provided for.
RiskAssessment: Based on the applicant’s responses to health, employment, travel, driving history, avocation information, the company may decide if the applicant is fit for further consideration. Some times an applicant may be suffering from a serious aliment like AIDS, alcohol/drug abuse which could make the applicant uninsurable.
All the business functions listed above are possible candidate scenarios for services. Each business function represents a stand-alone, self-sufficient functionality. All these functions can be orchestrated together as a part of the post application submission business process.
Broadly a service should exhibit the following characteristics:
A service’s consumer should be loosely coupled with its provider. Similiarly within the service, the consituents of the service should also be loosely coupled with each other. The service consumer should not need to know the service provider’s programming language or platform or any other idiosyncrasy. The provider is free to choose any programming language or platform for implementing the business functionality. In due course of time if the provider wishes he/she might change to a different implementation option. As long as the service interface and contract remains unchanged, the consumer is not affected by such changes. This is an area where Web services scores over other SOA implementation platforms like EJB, CORBA, JMS etc. In case of web services the consumer need only concern himself/herself with the web service WSDL. A service itself might be a collaboration of number of services available within an enterprise or outside the enterprise. In our insurance application example, the risk assessment service need not be an inhouse service but could be a service provided by a third party service provider. The insurer will definitely look forward to the flexibility of changing the provider alongwith introducing a minimal ripple within the business process.
The service will be exposing reusable function which can be harnessed and reused by intra-enterprise or other enterprise’s business applications. Such a leverage is only possible if the service is accessible over the network and for other enterprises over the internet. Again Web services scores as the underlying transport protocol HTTP is a standard and is firewall friendly. Therefore the provider/consumer does not need to take any special efforts in making the service available to a wide variety of consumers.
Flexible for change
Typically when a service is created, the service provider is not in a position to anticipate all the potential service consumers. Therefore the service definition should be adaptable enough to accept changes in its definition or implementation post deployment. For example, the insurer develops a risk assessment service for underwriting term life policies, the service definition should be flexible enough to accept other products like whole life, Universal life, variable life which the insurer could introduce in due course of time.
Service definition & Contract
The service is clearly defined in terms of the expected inputs and the resultant output. The service will also be governed by a service contract covering the following aspects: Functionality: What the business functionality does the service offer? The type of interface it exposes e.g. WSDL, SOAP, IDL JMS etc Operational aspects: service availiability whether the service is up 24 by 7, service cost: transaction based or licensed based Quality of Services: scalability, failover, throughput, response time.
Self-sufficient & Stateless
The service will expose a self-sufficient standalone business function. The service will not retain any state specific information beyond the life time of the service invokation. The internal functioning of the service will not be dependant upon what steps or functions or software components the consumer invoked before invoking the service.
Adherence to all the above mentioned characteristics are mandatory to achieve a true SOA “service”.