Database Reference
In-Depth Information
These items among many others form the so-called runtime discoverability. It is in your
best interests to expose your service to all who can potentially use it. This is possible if
you follow these points:
• Service operations and functional boundaries are well defined according to the
service contract
• Service particulars presented in the form of service metadata help everyone un-
derstand possible service runtime roles, model, composability potential, and limit-
ations
• Quality of service information describing service availability, reliability, and per-
formance is guaranteed
• Supplementary information regarding all test results and test conditions are in
support of declared performance
• Policy standards to which services adhere to mandatorily or optionally
All these items are elements of design-time discoverability. As part of governance efforts,
special layers of service infrastructure will be established in order to support these two
types of discoverability. We will dedicate a whole chapter to this challenge, as we reckon
lack of discoverability is probably the main problem in the implementation of SOA.
However, even if a technical platform is capable of supporting dynamic discovery and in-
vocation, and the service metadata storage is full of service details down to the particular
engines in use and rule types employed, we could still jeopardize potential reuse by keep-
ing interpretability of discovered information below the comprehension level. Information
that is too abstract (see the Implementation of Service Abstraction principle ) will prevent
the demonstration of full service potentials. A methodology in support of service tax-
onomy and metadata ontology (discussed in Chapter 5 , Maintaining the Core - the Ser-
vice Repository in great detail) will be not only established, but also conveyed to all indi-
viduals responsible for SOA governance from the very beginning to the end.
How do we measure service discoverability? What questions should you ask your deve-
lopers and architects (including yourself) in order to understand the level of principle ad-
option? Refer to the following questions:
• Do we have an inventory for all enterprise assets acting as service consumers and
service providers? In other words, what are the enterprise/domain boundaries?
• Do we have individual service profiles?
• What are the key elements of service metadata available from the service profile
that we will use for a service lookup?
Search WWH ::




Custom Search