When I meet architects and developers at different forums I see some people consider SOA to be a independent optional discipline. The fact is tears back there was a time when concept of SOA was new and people had to decide if they should do changes to their application to make them SOA compliant. Today we are convinced about the benefits of SOA and it is defacto design principle. I would go to the extent of stating that if you are not following SOA Principles when designing and coding applications i any technology, any programming language then you are doing something very wrong.
My past employer Accenture was a pioneer in SOA implementation and
innovation for SOA. I got opportunity to lead the SOA Practice, work
with industry leaders and implement multiple projects as a SOA Architect
for some of the top clients. The best way to learn is to implement
solutions for the most demanding fortune 500 clients and I was fortunate
to get the opportunity as the lead SOA architect for Accenture. One of
my innovations SOA Service Bench won 1st prize in Accenture wide
innovation contest and I was honored by Accenture CTO Don Rippert which
probably is the most rewarding thing an architect wants in his career.
This post is about some basic SOA Design Patterns that you should be familiar with. You can evaluate your existing application to see if they implement these patterns and if not then analyze the benefits of implementing the SOA Design patterns to make the applications SOA complaint. I assure you the benefits are immense in terms of maintainability, simplicity, loose coupling, reuse and atomic code. If you require any guidance feel free to write to me. I usually respond to queries on weekend.
1. Agnostic Services
Service capabilities derived from specific concerns may not be useful to multiple service consumers, thereby reducing the re-usability potential of the agnostic services. Agnostic services implement logic that is common to multiple business problems. Separating agnostic logic into discrete services facilitates service reuse and composability.
2. Service Declaration
Agnostic services should explicitly declare that they are agnostic. This makes it clear to future designers and builders which services are designed to be reused.
3. Atomic Service Transaction
Services can be wrapped in atomic transactions with a rollback feature that reverses all actions and changes. Transaction management services can be implemented in the component layer and reused by multiple services.
4. Enterprise Service Bus (ESB)
An ESB acts as a message broker between consumers and services. The ESB can perform message transformations, routing and connect to applications via a variety of communication protocols. YOu can use open source ESB products.
5. Service Façade
The service façade sits between a service and a contract. It eliminates the tight coupling between the service and its contract. This is intended to minimize changes to the service if the contract changes. A service can have multiple service façades to support multiple contracts.
6. Long Running Services & Service Callback
A service requires its consumers to call it asynchronously. If the consumer needs a response it provides a callback address. When the service reaches some milestone in processing it messages the consumer with a response. This approach frees resources and is useful when services are expected to be long running.
7. Backward Compatibility & Multiple Service Contracts
A service may support multiple contracts concurrently. This can be done to support backward compatibility (so that when a service changes all the consumers do not have to be updated). It is also done to provide different views to the service for different purposes (thus facilitating reuse).
8. Authentication Broker
In an enterprise scenario an authentication broker assumes responsibility for authenticating consumers. Consumers are issued a token they can use to access services.
9. Message Origin Authentication
Digital certificates are used to authenticate enterprise clients.
10. Message Filtering
Messages are filtered for harmful data before processing.
