I would like to share some insight into practical ways of implementing Service Orientation Architecture and my intent is to clear some hazy definitions out there and bring some clarity from Enterprise Architecture perspective.
About Services
Services should be designed by simplifying the components of your enterprise and making them easy for business to own them and reference them in their day-to-day business processes. Simplicity should be the key aspect and should not be confused with buzz words (vendor originated) and truly aligned with business key words. Simplification could take some effort but achievable with clear decomposition mind set.
Data
Service design should always consider the importance of Data and its context of usage. I have seen too many times where canonical models were established only to be withdrawn due to poorly federated design practices. One size doesn’t fit all is the key. The data aspect ideally should be standardized amongst the business groups or domains. For e.g., P.O (purchase order) can potentially have 3 canonical forms in an enterprise along the lines of its decentralized units.
The key thing is to have a centralized or federal model for some services and demonstrate loose coupling by having shared services for others.
WS-* or REST
This is one topic that hits me the most… Both WS-* and REST are applicable models for distributed computing models that promote agnostic call-ins. The answer is “It Depends” approach based on what you are trying to solve. REST provides an uniform interface approach and in my opinion, there are advantages to develop features in a quicker manner to things such as Micro-formatting, late binding and dynamic content negotiation approaches, etc. Either WS-* or REST, a fundamental design-first approach is essential for any successful SOA initiative.
Contract design
Filed under: SDLC
