Thursday, October 25, 2007

Practical SOA patterns

The SOA patterns I have discussed do not talk about the organization IT policies but the practical SOA patterns:-
1.1 Avoid point to point Web Services:
Problem: Web Service point to point is STILL point to point; doing a bad practice in XML doesn't make it better.

Effect: An organization believes that they are creating next generation loosely coupled architecture just because they are using Web Services. Web Service calls are invoked directly, using a URI which is hard-coded into the WSDL. Having a highly disorganized and interdependent systems model leads to increased cost of change and a high degree of fragility of the enterprise. When one service is changed a number of other services either fail or behave in unpredictable ways. There is a lack of clarity as to how one service depends on another and what the impact of change is across these services. Consumers then start demanding multiple versions of services, and these add further to the spaghetti in the enterprise.

While designing a BPEL process the endpoints of the web service may not be known, there is no simple way to determine the web service endpoint dynamically.

Resolution: The first step is to indirect all of the calls and this can be done in a number of ways; the least invasive is to "proxy" all web-service requests via some form of mediation. So while the host application is still calling webservice.mycompany.com, this is proxied so mediation and routing can be applied if required. The next stage is to understand the different dependencies and identify those which are valid and those which should have been done in a more managed way. A clear governance plan then needs to be created to identify and manage dependencies and versions and to help manage the Web Service infrastructure.

Once this level of management has been created it is time to start considering what the enterprise Service model should be, that requires the creation of the business service architecture and then overtime evolving the current infrastructure to better represent the business that pays for it.
1.2 Use Business Rules to make your process flexible:

Problem: Orchestration Languages provide constructs that break the linear flow of control. These constructs alter the flow of service orchestration based on run time information. These constructs change often.

Effect: In mortgage decisioning a conditional control structure implements the pre-screening step that determines whether the process performs decisioning or generates a rejection letter instead. The conditional verifies eligibility, determining how the orchestration unfolds based on whether the applicant's credit score is above a threshold. In effect, the condition associated with a control structure in the orchestration definition captures a business rule. In case the threshold changes, there is a change in the business process and the process needs to be changed and deployed again.

Resolution: Business rules complement processes. While business processes provide recipes for achieving results, business rules describe the operations, definitions and constraints that apply to an organization in achieving these results. For example a business rule might state that no credit check is required for existing Orchestra Bank customers. A business rules engine integrated with the BPEL manager can be used to solve the problem.

1.3 Use Composite Services to combine multiple services:

Problem: We need to combine the functionality of multiple services and make it available to consumers interested in is as a whole rather than the individual services implementing it.

Effect: Combining existing services could provide significant value over any individual service. In fact the recursive composition is key to the ability of adding value through combining functionality of the existing services. As the number of SOA adopters increases so does the number of choices.

Service consumers require functionality which can be implemented by suitably combining multiple existing services. They do not want to make multiple calls to the individual services and control the invocation flow.

Combining the functionality of existing business services (especially when they are provided by different organizations) requires a certain amount of know how and typically has sensitivities (e.g., the underlying services may change or different providers for these services can be selected). Exposing this knowledge to the service consumer introduces coupling.

Following mergers and acquisitions or through agreements with multiple partners several business services with similar functionality can be available to the enterprise (similarly to the credit check service from the context). These services can be distinguished by their interfaces and SLAs. The availability of multiple choices places the onus of selecting one service to the consumers, thus introducing coupling.

Solution: Expose the services involved in satisfying required functionality and their coordination as a separate service.
I was already using quite a few of these patterns but found them documented in Antipatterns and Orchestration patterns.