Database Reference
In-Depth Information
Runtime Discoverability analysis
We will start with the runtime Discoverability requirements because it seems a bit easi-
er—we are already using runtime lookup for the service particulars and different XML arti-
facts in the EBF and EBS service composition controllers, and all requirements are ex-
pressed in the execution plan's structure (look at ExecutionPlanLookupService ).
This is our Service Registry and is currently based on MDS, but our intention is not to isol-
ate Registry and Repository, but to rationally combine them into one management pack. In
this respect, Oracle has two products to offer, OER and OSR, with a utility for the syn-
chronization of metadata between them (orrxu, http://docs.oracle.com/cd/E21764_01/
doc.1111/e16580/oereu.htm ). Adding the metadata harvesting capability in OER for reverse
engineering and the requirements for OSR integration with WLS for the automatic register-
ation of new service deployments in the Service Registry will complete the picture of
Oracle's response to the Discoverability principle and SOA Governance.
But isn't it too complex? Yes, it is. The simple fact that the OER DB schema has 145 tables
(Release 11.1.1.7.0) for "all weather conditions" doesn't make our life easier. From the very
beginning, it was clear that managing complex technologies such as SOA would not be
easy, but we should expect a bit more methodological support for SOA runtime composi-
tions in particular. We are about to provide this support to the best of our ability, focusing
on vendor-neutral SOA principles first and then extending them to Oracle's product realiza-
tion (OSR and OER).
We will do this exactly how we did in the previous chapter: discuss a generic Message
Broker requirement first and then implement it as a Service Broker on OSB. Speaking of
which, we must mention certain things related to its complexity:
• Runtime and Design-time lookups are closely related and the physical segregation
of Registry and Repository is not always optimal from a performance point of view
in regards to the complexity of queries. Registry realization is UDDI compliant;
thus, we will have three major XML data structures, presented in tModels. In gen-
eral, it's a representation of service interfaces (for instance, WSDL for WS), and all
other related extra features come in value-name pairs. It may be flexible (in terms
of the value-name pairs), but not always interpretable and, therefore, discoverable.
• Continuing with a repository's segregation issues, we can say that simply mixing
SOA project data, service design particulars, runtime logs, service session data,
results from load/stress—only because they cannot be easily defined in the
tModels taxonomy or are not related to the Registry—will definitely not improve
our SOA Governance (see a single schema of OER). Keeping the Governance un-
Search WWH ::




Custom Search