Database Reference
In-Depth Information
General objectives
Actually, we should start the topic with this chapter, and only after establishing a solid
foundation should we proceed with the on-top frameworks. The deceiving simplicity of
WSDL-based service creation plays poor tricks on SOA-like projects, focusing only on the
API aspects of service orientation. The blueprint of the Service Repository is a fundamental
element of the Enterprise SOA architecture that demands commitment on all levels,
primarily from architects. Surprisingly, not all architects are willing to support this archi-
tectural layer due to its complex nature and the fact that the direct benefits don't seem all
that obvious. "We will think about it tomorrow. Today we stay on target—our delivery
deadline." For this kind of attitude (read: project delivery mode from the initial example of
Chapter 1 , SOA Ecosystem - Interconnected Principles, Patterns, and Frameworks ), archi-
tects are not required. If one does not know to which port one is sailing, no wind is favor-
able. The orchestration layer and ESB are not directions, but merely physical containers for
our Service Inventory. These containers have been packed mindlessly by different teams
working in parallel with a different understanding of service orientation, and will need total
refurbishing every four or five years.
Think of it this way—your SOA Enterprise architecture is a megalopolis, inhabited by doc-
tors, milkmen, truck drivers, firefighters, and so on. They are your service providers and
consumers. To operate smoothly, they need to be positioned rationally (logical layering),
that is, a fire brigade will serve no good if it cannot reach a certain location in the pre-
defined time (runtime interoperability). Any good citizen should be capable of locating a
(legally) required service with minimal effort, for example, by browsing the yellow pages
(runtime Discoverability on the Service Registry). Most importantly, a citizen must be able
to understand the nature of the service—look for a particular doctor, select the right one,
and be sure that this doctor is located exactly where mentioned (interpretability of the Ser-
vice Registry). These are our runtime features of the Service Inventory.
At the same time, you, as the good governor of this megalopolis, must plan the layering
wisely—concentrate on one type of service, such as financial institutions ( Inventory Cent-
ralization ), and evenly spread another, such as waste removal and law enforcement (the
Cross-Domain Utility Layer ). To do so properly, you need a wide variety of information
about these services (service records about your law enforcement officers), available in the
Service Repository. Only a precise subset of this information will be used during runtime
by other services. Some other types of service records will be constantly used to measure
their (services) runtime behavior, and based on that, we will decide about service promo-
tion or decommission. These are the design-time features of the Service Inventory.
Search WWH ::




Custom Search