In this post I am attempting to summarize the SOA patterns that were published in the book, "SOA Patterns" by Amon Rotem-Gal-Oz. This is based completely on my understanding of the matter presented in the book and there is a possibility of a gap in my understanding, if so, please feel free to correct me by leaving a comment. Please also note that this is not the only book on SOA patterns but there is another one, "SOA Design Patterns" by Thomas Erl. The reason I decided to read the book by Amon Rotem-Gal-Oz is because it has a foreword from one of my favorite authors, Gregor Hohpe, one of the author of Enterprise Integration Patterns. With this post let me discuss the patterns presented by Rotem-Gal-Oz. For the patterns from Thomas Erl I may write another post.
The very reason I am writing this post is to make life easier for those who don't have time to read through 300 page book on SOA patterns but want to have a very high level & quick understanding of it. My post will try to give a very brief (2 - 3 sentences) description of patterns assuming that you the reader has come from a similar IT background as me and is familiar with some of the common SOA & integration concepts.
Please read my conclusion at the end of the post that is regarding how relevant and useful these patterns are for the Developers and Architects and others related to this industry.
Foundation Patterns
1) Service Host:
Use a common run time environment like the one provided by application servers that addresses common cross cutting concerns such as exception handling, logging, transaction, security etc . We should not develop run time services individually and separately for each service.
2) Active Service:
Simply states that services that depend on other services or internal applications or subsystems that may not be highly reliable should make provisions for handling downtime of those application/services that it depends on. For example caching the data returned by those applications frequently.
3) Transactional Service:
This pattern requires that the services use a transaction manager (ACID) commonly provided by application servers or databases.
4) Workflodize:
Use a workflow engine to orchestrate business logic scattered across multiple services and applications that this service uses. This also enables a service to efficiently change business logic when required.
5) Edge Component:
The pattern uses a component (the edge component) to handle cross cutting concerns like filtering, authentication, logging, security etc. before a request reaches service or after response is returned while leaving the service responsible only for implementing the business logic.
Patterns for Performance, Availability & Scalability
6) Decoupled Invocation:
During peak loads respond to service requests upfront with an acknowledgment receipt, add the request to reliable queue and then respond asynchronously. Internally handle the response after prioritizing based on request type, its importance to business and system capacity.
7) Parallel Pipelines:
This is the Pipes & Filters pattern used in context of SOA. The request is broken down into multiple sub-tasks and each task is added into a separate task queue. Once a task is finished the result is put into the next queue, this continues all the way till the outbound response queue.
8) Gridable Service:
When handling a computationally intensive request, scale out the request processing over several nodes i.e. grid (as in grid computing).
9) Service Instance:
Distribute the request load across multiple service instances that implement the same contract. Application servers generally provide this feature especially for stateless services.
10) Virtual Endpoint:
Make multiple service instances distributed across locations appear as a single service instance using a single Virtual Endpoint that (routes and load balances and) wraps the Edge Components & Service instances.
11) Service Watchdog:
Use an agent (JMX, SNMP installed on the service host) to monitor and publish report on the health of a service and attempt recovery on failures.
Security & Manageability Patterns
12) Secured Message:
Exchange encrypted or digitally signed messages.
13) Secured Infrastructure:
Exchange messages over secured channel (e.g. SSL).
14) Service Firewall:
Make messages go through a Firewall.
15) Identity Provider:
Authenticates, Authorizes and provides SSO for service requests
16) Service Monitor:
Centralized monitoring of a group of related (orchestrated) services for Quality of Service towards the goal of governance
Message Exchange Patterns
17) Request / Reply:
Synchronous request & response, handled in the same process on the server.
18) Request / Reaction:
Both Request & response are one way messages. This response can be implemented as Pull or Push.
In case of Pull when service receives a request it replies back with an ack and a reply-from address along with estimated time of processing. Based on this the consumer calls the service in the reply-from address and pulls the response. This is how it can be implemented in a duplex (2-way) protocol such as HTTP.
In case of Push, when the service receives a request, it also receives a reply-to address as part of the request from the consumer. When the response is ready, the services push it to the reply-to address where consumer is listening. This can be implemented using MoM queues.
19) Inversion of Communication:
Publish messages from a service in EDA style - Publish / Subscribe. The Edge Component acts as an Event Handler (receive & filter events from outside) & Propagator (publish events to subscribers).
This can be implemented easily using ESB or Message Broker but hard to implement with HTTP / REST, however techniques like ATOM, RSS, Email or Comet can be used. Subscription management is outside the scope of the pattern.
20) Saga: (Long running & compensating transactions)
Break the long running service interactions into smaller actions & compensatory counteractions.
Service Consumer Patterns
21) Reservation:
Compensating transactions do not support ACID and cannot be rolled back correctly/completely; make smaller actions in long running transactions reserve the resources for a limited time. If a commit takes place before the expiry time, the resources are granted otherwise you lose the resources. 3 components are used in the implementation – Reservation, Validation, Expiration. The validator checks if the reservation is still valid before finalizing.
22) Composite Front End: (Portlets)
Portlets invoke different web services and get data for different views that are aggregated on a Portal. Java EE specs JSR 168 (Portlets) and 286 (WSRP).
23) Client/Server/Service
Use an intermediate server between UI & services such that UI is unaware that the data for the view is fetched from multiple back-end services. UI is only aware of Server and continues to talk to the server over traditional protocols such as RPC but server is "SOAfied" and uses SOA to interact with bc-end services.
This pattern can be used for gradually transitioning the server side application to a SOA approach where the server starts using services instead of earlier RPC or other techniques without making any impact to the UI/Client layer which continues to interact with server as it always did.
Service Integration Patterns
24) Service Bus: (ESB)
The Service Bus takes care of all integration needs in an Enterprise or Business Unit like Publish/Subscribe, Routing, Transformation, Invocation and Registration (of service providers) and adapting to channels.
25) Orchestration:
Make a business process agile by externalizing service interaction logic to a workflow engine. Not sure why the author has included both the Workflodize and Orchestration as two distinct patterns.
26) Aggregated Reporting:
A service that gathers data from multiples sources for reporting purpose. It has 2 main components the service (SOA interface) and the data back end. The data backend is similar to a data warehouse which brings data from multiple sources and consolidates for reporting purpose.
Conclusion:
The Foundation patterns are like common services or cross cutting concerns that application servers or the run time environments provide. These will be relevant to you only when you are writing standalone services not hosted in any app server or run time environment. Furthermore these will be useful to those who are developing the run time environment for non-standard web services like those that use FTP or SMTP or any other custom protocol bindings for which there are no application server or run time containers available.
The Patterns for Performance, Availability & Scalability as the name suggest are about handling the NFRs for services with right hosting decisions. Same goes for the Security & Manageability patterns as they handle a specific NFR, the security.
The Message Exchange Patterns have been used in EAI before SOA came, here only the context is different i.e. SOA.
The Service Consumer patterns are mostly to do with UI except the Reservation pattern. Not sure if the Reservation Pattern is in the correct group.
There doesn't seem to be an obvious difference between Workflodize. Saga & Orchestration as the solution is the same only the intent appears to be different.
The Service Integration patterns, as the name suggests are about integration in the context of SOA.
The same pretty much can be said about most of the pattern here. Same patterns but new context. Patterns, as such can never be new, these are tried and tested solution themes used successfully in various context like Object Oriented Design, Integration and now SOA.
The very reason I am writing this post is to make life easier for those who don't have time to read through 300 page book on SOA patterns but want to have a very high level & quick understanding of it. My post will try to give a very brief (2 - 3 sentences) description of patterns assuming that you the reader has come from a similar IT background as me and is familiar with some of the common SOA & integration concepts.
Please read my conclusion at the end of the post that is regarding how relevant and useful these patterns are for the Developers and Architects and others related to this industry.
Foundation Patterns
1) Service Host:
Use a common run time environment like the one provided by application servers that addresses common cross cutting concerns such as exception handling, logging, transaction, security etc . We should not develop run time services individually and separately for each service.
2) Active Service:
Simply states that services that depend on other services or internal applications or subsystems that may not be highly reliable should make provisions for handling downtime of those application/services that it depends on. For example caching the data returned by those applications frequently.
3) Transactional Service:
This pattern requires that the services use a transaction manager (ACID) commonly provided by application servers or databases.
4) Workflodize:
Use a workflow engine to orchestrate business logic scattered across multiple services and applications that this service uses. This also enables a service to efficiently change business logic when required.
5) Edge Component:
The pattern uses a component (the edge component) to handle cross cutting concerns like filtering, authentication, logging, security etc. before a request reaches service or after response is returned while leaving the service responsible only for implementing the business logic.
Patterns for Performance, Availability & Scalability
6) Decoupled Invocation:
During peak loads respond to service requests upfront with an acknowledgment receipt, add the request to reliable queue and then respond asynchronously. Internally handle the response after prioritizing based on request type, its importance to business and system capacity.
7) Parallel Pipelines:
This is the Pipes & Filters pattern used in context of SOA. The request is broken down into multiple sub-tasks and each task is added into a separate task queue. Once a task is finished the result is put into the next queue, this continues all the way till the outbound response queue.
8) Gridable Service:
When handling a computationally intensive request, scale out the request processing over several nodes i.e. grid (as in grid computing).
9) Service Instance:
Distribute the request load across multiple service instances that implement the same contract. Application servers generally provide this feature especially for stateless services.
10) Virtual Endpoint:
Make multiple service instances distributed across locations appear as a single service instance using a single Virtual Endpoint that (routes and load balances and) wraps the Edge Components & Service instances.
11) Service Watchdog:
Use an agent (JMX, SNMP installed on the service host) to monitor and publish report on the health of a service and attempt recovery on failures.
Security & Manageability Patterns
12) Secured Message:
Exchange encrypted or digitally signed messages.
13) Secured Infrastructure:
Exchange messages over secured channel (e.g. SSL).
14) Service Firewall:
Make messages go through a Firewall.
15) Identity Provider:
Authenticates, Authorizes and provides SSO for service requests
16) Service Monitor:
Centralized monitoring of a group of related (orchestrated) services for Quality of Service towards the goal of governance
Message Exchange Patterns
17) Request / Reply:
Synchronous request & response, handled in the same process on the server.
18) Request / Reaction:
Both Request & response are one way messages. This response can be implemented as Pull or Push.
In case of Pull when service receives a request it replies back with an ack and a reply-from address along with estimated time of processing. Based on this the consumer calls the service in the reply-from address and pulls the response. This is how it can be implemented in a duplex (2-way) protocol such as HTTP.
In case of Push, when the service receives a request, it also receives a reply-to address as part of the request from the consumer. When the response is ready, the services push it to the reply-to address where consumer is listening. This can be implemented using MoM queues.
19) Inversion of Communication:
Publish messages from a service in EDA style - Publish / Subscribe. The Edge Component acts as an Event Handler (receive & filter events from outside) & Propagator (publish events to subscribers).
This can be implemented easily using ESB or Message Broker but hard to implement with HTTP / REST, however techniques like ATOM, RSS, Email or Comet can be used. Subscription management is outside the scope of the pattern.
20) Saga: (Long running & compensating transactions)
Break the long running service interactions into smaller actions & compensatory counteractions.
Service Consumer Patterns
21) Reservation:
Compensating transactions do not support ACID and cannot be rolled back correctly/completely; make smaller actions in long running transactions reserve the resources for a limited time. If a commit takes place before the expiry time, the resources are granted otherwise you lose the resources. 3 components are used in the implementation – Reservation, Validation, Expiration. The validator checks if the reservation is still valid before finalizing.
22) Composite Front End: (Portlets)
Portlets invoke different web services and get data for different views that are aggregated on a Portal. Java EE specs JSR 168 (Portlets) and 286 (WSRP).
23) Client/Server/Service
Use an intermediate server between UI & services such that UI is unaware that the data for the view is fetched from multiple back-end services. UI is only aware of Server and continues to talk to the server over traditional protocols such as RPC but server is "SOAfied" and uses SOA to interact with bc-end services.
This pattern can be used for gradually transitioning the server side application to a SOA approach where the server starts using services instead of earlier RPC or other techniques without making any impact to the UI/Client layer which continues to interact with server as it always did.
Service Integration Patterns
24) Service Bus: (ESB)
The Service Bus takes care of all integration needs in an Enterprise or Business Unit like Publish/Subscribe, Routing, Transformation, Invocation and Registration (of service providers) and adapting to channels.
25) Orchestration:
Make a business process agile by externalizing service interaction logic to a workflow engine. Not sure why the author has included both the Workflodize and Orchestration as two distinct patterns.
26) Aggregated Reporting:
A service that gathers data from multiples sources for reporting purpose. It has 2 main components the service (SOA interface) and the data back end. The data backend is similar to a data warehouse which brings data from multiple sources and consolidates for reporting purpose.
Conclusion:
The Foundation patterns are like common services or cross cutting concerns that application servers or the run time environments provide. These will be relevant to you only when you are writing standalone services not hosted in any app server or run time environment. Furthermore these will be useful to those who are developing the run time environment for non-standard web services like those that use FTP or SMTP or any other custom protocol bindings for which there are no application server or run time containers available.
The Patterns for Performance, Availability & Scalability as the name suggest are about handling the NFRs for services with right hosting decisions. Same goes for the Security & Manageability patterns as they handle a specific NFR, the security.
The Message Exchange Patterns have been used in EAI before SOA came, here only the context is different i.e. SOA.
The Service Consumer patterns are mostly to do with UI except the Reservation pattern. Not sure if the Reservation Pattern is in the correct group.
There doesn't seem to be an obvious difference between Workflodize. Saga & Orchestration as the solution is the same only the intent appears to be different.
The Service Integration patterns, as the name suggests are about integration in the context of SOA.
The same pretty much can be said about most of the pattern here. Same patterns but new context. Patterns, as such can never be new, these are tried and tested solution themes used successfully in various context like Object Oriented Design, Integration and now SOA.
