Additional SOA Patterns –Supporting Composition Controllers - Applied SOA Patterns on the Oracle Platform - page 539

Chapter 9. Additional SOA Patterns -
Supporting Composition Controllers
SOA is a form of distributed computing, or more precisely, an architectural approach to es-
tablish it. It is maintained on heterogeneous environments by means of API standardization
and canonicalization of service activities by service messaging/state messaging. The ability
to arrange the service composition dynamically and in an agnostic way is arguably the
main benefit of this architectural model, as demonstrated in all the previous chapters. This
is where the money is. About 80 percent of all SOA patterns are focused on achieving
composition-centric SOA characteristics (among others mentioned in Chapter 1 , SOA
Ecosystem - Interconnected Principles, Patterns, and Frameworks ) directly:
• Implementing Service Inventory and maintaining a dependable Service Registry
• Minimizing the Service Adapter layer and avoiding transformations
• Abstracting services and maintaining their state, even for completely stateless ser-
vices
• Allowing service invocations in an agnostic way
We have been working on all of this attentively in the previous chapters to provide you
with a blueprint of the working solution. Now you have all the essential components to im-
plement a business-driven, composition-centric solution right away. This is suitable not
only for Order Management (as an alternative you can go for OSM, Oracle Service Man-
agement/Order Management at http://docs.oracle.com/cd/E35413_01/doc.722/e35415/
cpt_overview.htm but also for Telecom and getting another silo, where you will implement
all special cases as custom cartridges and integrate them into your Service Inventory using
OFM/AIA). At the very least, it will be quick. Maybe, in addition to this, it will be
telecom-specific with about 40 percent coverage of real telecom needs. Mind you, it's not
bad at all; it totally depends on your business/IT strategy.
Still, something quite important is missing in this picture, something that's not directly con-
nected to any SOA pattern in the public catalog but essential in terms of practical realiza-
tion. In the previous chapter, we mentioned several technical monitoring tools, but business
monitoring must be in place as well. Oracle BAM is an obvious choice from the Oracle
stack and is not related to any pattern but is capable of addressing this requirement. While
discussing the Adapter framework and fault handling, we tapped into the Event Driven
Messaging pattern several times and presented working solutions, employing this pattern.
Here, we will look at conventional OFM ways of event utilization and discuss their benefits
and limitations. These limitations could have very profound effects on the overall perform-