Maintaining the Core – Service Repository - Applied SOA Patterns on the Oracle Platform - page 340

• The GU is supplied with all the necessary SOA guidelines and has a strong SOA
sponsorship that is willing to follow the Enterprise Integration Center of Compet-
ence (ICC) guidelines (expressed in the first table in this chapter)
• The GU is capable of maintaining its own SOA assets and infrastructure
• The GU SOA assets are mostly GU specific, so establishing an Enterprise Repos-
itory is simply impractical
Usually, we expect that lookups 1-4 are used. A domain Service Broker(s) will be imple-
mented to perform service dispatching. Part of the Service Broker, the service locator,
must discover enough information to support end-to-end transactions and supply the Mes-
sage Broker (ESB) with all the information for 3-4.
The design rules are as follows:
• Synchronous MEPs : This includes one DR lookup per transaction and persisting
data in Process Header
• Asynchronous MEPs with Global Correlation ID : This comprises one DR
lookup and one PH lookup by CorrID
• Asynchronous MEPs without Global Correlation ID : This involves more than
one DR lookup, depending on the number of services/operations to invoke
Again, the preceding rules are subject to trade-offs and depend on the level of service
granularity, message size, and process simplification.
This approach is also very traditional and requires you to perform the following steps:
1. Functional decomposition does not have to be completed before implementation.
Only the Utility Services must be clearly identified upfront, which is simple as
these services are well patterned: Service Broker, Translator, Transformer, RE
Endpoint, DE Endpoint, and Message Broker. Business services can be presented
initially in big chunks; this is suitable for further decompositions. This is the typ-
ical meet-in-the-middle approach, where top-down and bottom-up benefits are
combined. As a result, the optimal delivery time with measurable and attainable
performance is significantly better than that with a decentralized approach. Also,
reliability is constantly maintained in a balanced manner along the decomposi-
tion.
2. Business logic and complex composition logic are removed from the Composi-
tion Controllers and subcontrollers in order to make the composition adjustable
through simple configuration files (entities and rules), and not by recoding. The
important thing here is that Composition Controllers don't have to be totally ab-