Service Design Guidelines - SOA

• Business Services should be Stateless
• Services should be reusable
• Standardize the interface contract , Should expose in CDM
• Each Business Services will expose as 1 or 2 Proxy Services
• Consumer not ready to adopt our business/Proxy services due to data format then will define the Adaptor Services for those consumer only
• Aggregation should be in Process Services/Adaptor services ie Process Service/Adaptor Services will aggregate more than one business services
• NFRS should be in Cross Cutting Manner , we can enable/disable without /minor changes in services level
• ESB will trigger the alert if any unknown exception or services down
• Communication between our Business services and Provider System always through enabler Services(Data Services) .
• Define the Throttling /rating in Service and Operation plus consumer level
• Security (authentication and authorization ) should be in place
• Try to implement the versioning in the business service to prevent the redundancy
• Define the strategy for Adaptor services and Versioning in Business Services
• Try to minimize the business logic and persistence in Integration Layer .
• All the Business services should be captured in Service Catalogue
• Business Services Should be Coarse grained
• Process and Adapter services may be coarse grained or fine grained
• Try to implement the Cache as much as possible for those read operation
• Environment related information should not bundle with service package , it should be externalize
• Service Name should Noun and Operation name should be Verb .
• Try to implement the Pagination for critical/bulk read operation to prevent the resource utilization
• A service interface (WSDL port type) should generally contain more than one operation. Operations defined as part of a single service interface should be semantically related by data on which they operate.
• Do not mix synchronous and asynchronous invocation semantics in a single interface (WSDL port type). If it is advantageous to support both semantics, define separate interfaces for synchronous and asynchronous invocations.
• If related information resides on multiple Provider System, should first define physical system-specific interfaces grouping information type-related transactions, and then aggregate these interfaces into a single interface.
•  Describe your service interfaces using WSDL and XSD instead of Java. Your service interface definition is a WSDL port type.
• Follows Top Down approach for those new Interface ,Stick with Bottom up approach for existing legacy (not ready to do any changes /those are under sunset umbrella ) .Try to follow Hybrid approach as much as possible 
• System level data (Meta Data) should be Header rather than Payloads
• Business Services Name should align with Business Process /Business Capablities .. 

Business Service Name	Good to Have	Try to avoid
CusomerManagementService	*
GetCustomer		*
ProductManagementService	*
CreateProduct		*

• Integrating with Downstreams system always through Enabler Services, Each Enabler Services may integrate with one or more than one Downstream System based on the Business Service Context
• Business And Enabler Services can build and deploy independently .
• Business Service always Integrate with one enabler Service.(1-1 Mapping)