From: Herbjörn Wilhelmsen <[email protected]>
To: [email protected]
Sent: Tuesday, April 14, 2009 11:55:10 AM
Subject: Re: [service-orientated-architecture] Erl & Herbjörn offer the 5th SOA Pattern of the Week
I do not understand, why bother with services? Make them RPC, and end the story.I think that both Erl & Herbjör miss the point - why services, especially business services are coarse-grained. They are such because they implement business functionality. Retrieving a data field content from a database that somebody calls 'business data' - fine-grained activity - has nothing to do with any business functionality, this is why I do not consider it as a business service (in spite of calculation capabili ties of modern hardware).SOA business service may be as fine-grained as the business logic allows, i.e. when further splitting business functions does not make sense from the business perspectives.- Michael
From: Gervas Douglas <gervas.douglas@ gmail.com>
To: service-orientated- architecture@ yahoogroups. com
Sent: Monday, April 13, 2009 5:01:21 PM
Subject: [service-orientated -architecture] Erl & Herbjörn offer the 5th SOA Pattern of the Week
<<
A service inventory is a living body of services that individually will need the freedom to evolve independently over time. What we learned when documenting the SOA design pattern catalog is that there are patterns that emerged not only at design-time but also during this post-implementation evolutionary stage in a service's lifecycle.
There is one common scenario that repeatedly surfaced in many projects:
- When we model and design services during early stages of SOA adoption we are constrained by current infrastructure and technology. These constraints require that we limit the size of service compositions and the extent of cross-service message exchanges. As a result, each service encompasses more logic and is coarser grained.
- Our infrastructure improves over time (because of new platform upgrades or new funding for better hardware, etc.). Our existing service compositions are comprised of coarse-grained services that were delivered within the parameters of the older environment. However, we now realize that services could be more fine grained (and could perform and be composed more effectively) because the infrastructure can support larger service compositions.
It is in response to this situation that the Service Decomposition pattern provides a technique for splitting up a service after its initial deployment into two or more fine-grained services.
Of course, such an approach will raise a few eyebrows from those involved in version control and change management. How can we break apart a service with an established contract without impacting all of the consumer programs that have been using the service and have formed very real runtime dependencies on how it currently exists?
To address these issues, the Service Decomposition pattern needs the help of several other SOA design patterns:
- Proxy Capability -- When logic is moved from one service to another, this pattern can be used to preserve the original capability that is expressed as part of the original service's contract.
- Service Façade-- In support of enabling Proxy Capability, this multi-purpose pattern can be used to establish (within the original service logic) a façade layer of processing that acts as a liaison between the original service and the new service. The façade component may actually invoke the corresponding capability on the newly created service, thereby acting as its service consumer on behalf of the consumer of the original service.
When applying these two patterns together with Service Decomposition, the façade logic can also be designed to compensate for a change in behavior that is likely to occur as a result of physically moving a segment of the original service logic into a new location.
An important requirement for the decomposition of a service to be successful is that the resulting, more fine-grained services have distinct functional contexts. When modeling and designing these new services, all applicable service-orientation principles and patterns must be considered as with any other new service. Other fundamental patterns, such as Service Normalization, also need to be applied to ensure that the new services properly line up with the others in the existing service inventory.
One common problem with post-implementation service decomposition, however, is that a given set of capabilities may not correspond cleanly to the functional contexts of the new services. What this means is that a new service may only require a portion of what the original service capability represents.
There are several ways of dealing with this, including a hybrid application of the Proxy Capability pattern where the original service retains some of its logic but then still calls a new service for the portion that now belongs elsewhere. However, there is yet another pattern we can take into account early on during the initial modeling stages of the original service in anticipation of future decomposition requirements. This pattern is called Decomposed Capability and it essentially asks us to think ahead as to how a given coarse-grained service context can be split into multiple finer-grained contexts and to then align the initial service capabilities correspondingly.
In the SOA design patterns catalog, the Service Decomposition pattern is classified as a governance pattern, even though it is very much related to service design. It is one of those patterns that can really help augment and streamline an existing collection of services in continual support of service composition and recomposition.>>
You can find this at: http://searchsoa. techtarget. com/tip/0, 289483,sid26_ gci1352917_ mem1,00.html
Gervas
--
Med vänliga hälsningar
Herbjörn Wilhelmsen
