Database Reference
In-Depth Information
Improving the Agnostic Composition Controller
The implementation of a redesigned service collaboration platform with the orchestration
pattern in the OSS/BSS business domain was recognized as a major success. Other depart-
ments decided to implement the existing functionality on their premises or, even better,
they decided to reuse the existing frameworks directly as a Service Broker / Mediator to
develop the service inventory. However, some concerns were expressed. It is clear that to
improve performance, we have to separate the synchronous and asynchronous service
activities. Together with the orchestration platform's performance fine-tuning, we will
probably gain some milliseconds.
However, this is not an ideal approach. Thus, a synchronous part that does not require the
Partial State Deferral pattern implementation shall be moved to the Enterprise Service Bus
we are about to build. This means that the Dispatcher and Decision Service (another in-
stance) elements of the functional decomposition figure in the previous chapter shall be re-
designed in a new framework. Not only that, the Business Delegate (
ht-
tp://www.corej2eepatterns.com/Patterns2ndEd/BusinessDelegate.htm
) that decouples the
service consumer / composition imitator will continue to play its role in the SCA realiza-
tion of the service broker by performing the following tasks:
• Minimize the number of calls from the client to the service provider, acting as a
transaction coordinator for logically aggregated business operations
• Hide the networking issues associated with the distributed nature of services
• Shield the clients from possible volatility in the implementation of the business
service API
• The Business Delegate should be implemented on ESB, somewhere close to the re-
positioned dispatcher (for performance reasons)
These roles associated with the maintenance of the Loose Coupling principle are tradition-
ally linked to implementation of the Proxy pattern of services/components. This design pat-
tern was one of the most popular patterns (before SOA) to wrap the physical component in
an additional layer to control access, maintain the distributed nature of an asset by delegat-
ing interoperability functions, and hide the complexity of the implementation. With emer-
ging enterprise services, especially on the WS technology, this pattern becomes even more
demanding, as the detachable service contract fits really well into the Proxy concept and
makes consumer-provider decoupling easier and more native. This design pattern is intrins-
ically connected to some other generic (non-SOA) design styles, and it's the basis for some
fundamental SOA patterns. In Oracle ESB realization, you basically put all actual develop-
Search WWH ::
Custom Search