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

Service metadata for Agnostic Composition
Controller
In the previous CTU composition controllers' refactoring examples, two teams were tasked
to maintain, lookup, retrieve, and inject service metadata into a service message in a form
suitable for processing by at least two core players of our service composition:
• Composition Controller and Subcontroller (sync and async Service Brokers (SB))
• Adapter Factory (AF; also known as Generic Adapter (GA))
Both teams followed the same classification approach as follows:
• A single service's invocation is a task
• Each invocation has a number of particulars, expressed as parameters, bound to the
task
• Composition is a sequence of the tasks that logically represents the business pro-
cess or its completed part (scope is defined in BPEL terms)
Tasks can be grouped according to the business logic, but both teams must abide by the fol-
lowing rules:
• Do not make the routing slip (the task's execution plan) too complex
• If we have several logical groups ( >3 ) or too many tasks in a group ( >9 ), then it is
better to denormalize some processes again into an atomic task-orchestrated ser-
vice and call it dynamically from a smaller execution plan
We are reiterating this only because we want to remind you that we are not reinventing the
BPEL. We are purely centralizing the service metadata and applying it to the service mes-
sage when necessary. So, the general structure is obvious: metadata elements should cover
all composition levels (process, individual composition, task, and task parameters), but
how different can the understanding of metadata be? The composition's Execution Plan for
the custom synchronous Service Broker from the previous chapter is easier as we do not
have to focus on the actions on the return path. So, let's look at it now. The following is just
a single task node:
<TPProcess>
<TradingPartnerProcessList EdiProcessId="100"
EdiProcessCommType="6"