Building the Core – Enterprise Business Flows - Applied SOA Patterns on the Oracle Platform - page 182

but it's part of the SOAP header, and it's still the WS-* standard; however, we will not al-
ways call WS, and WSIF is not always an option.
Also, you probably noticed that the routing slip is nothing more than a description of End-
points. Endpoints (API) are one of the key (probably most crucial) elements of our service
infrastructure, and from the Governance standpoint, we must simply register and maintain
them in our Service Repository (and Registry as well). The Registry structure will be dis-
cussed in a separate chapter, but for now, we can assume that endpoints are already there
after the completion of decomposition and logic centralization. It's also not a big deal to
extract a consolidated endpoint descriptor in the form of a routing slip from the Reposit-
ory. We have to stress that we are not opposing WS-Addressing routing slips and BPEL as
an Orchestration language; further, you will see how they gracefully coexist. Now we
come to the realization of two new SOA patterns:
• Metadata Centralization (4)
• Inventory Endpoint (7)
Metadata is data about data (probably the shortest description possible, and we love it).
The endpoints and types of Service Engines in use, which include runtime roles of ser-
vices and service models, are data elements that describe the service. They will be in our
Inventory eventually (the sooner the better) but accessed through the unified Inventory
Endpoint. So far, we have plans to keep the service endpoints and extract them using the
WS API, which we described in the development phase.
Tip
By cautiously practicing the philosophy "one baby step at a time," we cannot boldly pro-
claim an emerging inventory as an Enterprise. This Service Inventory currently belongs to
the OSS/BSS domain; thus, it's a Domain Inventory (3) .
Returning to the first point of concern, we would like to confirm its validity. Keeping the
routing slip reasonably simple is the key; otherwise, we will just reinvent the wheel. It
would be much easier than presenting the routing slip as the BPEL 2.0 XML artifact and
the routing slip parser as a subclass of the BPEL engine, reacting only on the constructs
invoke and transform. By doing this, universalism will be maintained, but we will have to
forget about portability.