Database Reference
In-Depth Information
• From which service infrastructure layers will we perform the lookup and for what
purpose? In other words, who is allowed to discover this information and when
(security)?
• Can we perform reverse search metadata by service?
• How will these metadata elements be presented in a service message, in which
parts, and at what level of detail?
• Are these metadata elements in the service messages covered by the existing SOA
standards? Can we keep them vendor-neutral and minimalistic?
Believe it or not, a simple Excel spreadsheet will do the trick, and the explanation will be
provided shortly. How many times have we witnessed the situation when without a well-
structured and understandable taxonomy, even the most powerful harvesters (SOA arti-
facts introspection tools) with marvelous graphical representation of discovered relations
just turn the situation from bad to worse?
This principle undoubtedly supports all four desirable SOA characteristics. This principle
conflicts with the service abstraction and can negatively impact security when poorly im-
plemented.
Service composability
Finally, we come to the last principle that completes the foundation of SOA. This prin-
ciple is in fact the paramount realization of SOA, as it's the closest thing to money, the
universal entity that is understandable by any members of an enterprise.
Next, we compose and recompose the new business applications and processes out of the
existing building blocks; the less we waste, the more we gain through reuse. However, is
there any overlap between composability and the reusability principles discussed before?
Yes, but only at first glance, as the key here is in the measure of "waste" we would like to
prevent. Almost everything in IT could be reused; the question is how much effort (time)
it could cost for doing this.
The composability principle defines the measure of how easily any service from a particu-
lar service inventory could be involved in a new composition, regardless of the composi-
tion's size or complexity. Of course, a service should be involved in the operations it was
designed for and in the roles it can support. Thus, the common quantifier for this principle
is time. When designing a service from the very beginning, you should speculate on how
hard it would be to implement composed capabilities using your service along with others,
and how many compositions a single instance of your service can support from the per-
formance standpoint. Yes, the statement
regardless of the composition's size or complexity
Search WWH ::
Custom Search