How can standardization be applied to a meaningful extent to a collection of externally owned services (services outside own organization or in another independent domain within the organization, that are not under control)?
Externally owned services, whether services outside the own organization or in another independent domain within the organization, are usually not under control. A service consumer has to deal with all the varieties in their published service contract.
Present the service consumer with a collection of new services, represented by new service contracts to shield the service consumer from the varieties (e.g. non-standardization and usually strong heterogeneity) in the original service contracts. As a collection these new service contracts are designed to be more standardized and more homogeneous (less heterogeneous) regarding the various topics of concern in a service contract, e.g. data format and data model, messaging/transport protocol, exposed capabilities.
Various design approaches can be applied, several of which depend on the further application of the Composition Endpoints pattern.Streamline a collection of standalone services for internal use. By standalone services we refer to services that are modeled independently and conform to different standards, as is usual the case for services from various external sources either outside the enterprise or from another domain within the same enterprise. Streamline here means use an analysis and design process (to try) to establish a workable standardization, usually focused on internal use.
The streamline relies heavily on the repeated application of the Intermediary Contract pattern, in combination with a number of other patterns. As such the capabilities of the intermediary (or intermediaries) available are an important factor (e.g. the one(s) in the targeted domain inventory, that is the domain where consuming services reside). The net result will be a collection of services with aligned (streamlined) intermediary.
As this pattern relies on the Intermediary Contract pattern and mirrors the Enterprise Inventory or Domain Inventory pattern, it inherits also the impact these patterns have, predominantly the performance overhead and additional analysis/design effort respectively.
In addition, a conscious choice has to be made for each relevant topic to go for either a true standardization (one specific standard) or a limited set (a specific –low- number) of competing standards (and of course which).
PrinciplesStandardized Service Contract, Service Reusability, Service Abstraction, Service Composability
One of the basic goals of SOA is to foster intrinsic interoperability. An obvious contribution to this goal is made by standardization efforts. As such, various service oriented design patterns focus on both standardization and interoperability. In particular the Enterprise Inventory and Domain Inventory design pattern focus on both for a certain collection of services and attempt to realize a "homogeneous" collection. This attempt strongly favors from the fact that the services within the collection are usually fully owned and therefore under full control, so strong/strict standardization is relatively easily achievable (at least to a sufficiently high extent).
However, in many cases real life situations the full set of services in use include not only services from one domain inventory or a enterprise inventory but also from other domain inventories in an organization or enterprise(of course when present) and/or from services outside the organization or enterprise boundary. From a standardization and interoperability perspective, this full set is more heterogeneous and this may hinder reusability and composition of the services to a certain extent. Although this heterogeneity is a characteristic of the original external services (to be) consumed, this heterogeneity does not necessarily have to be visible in the same extent to the actual (internal) service consumers: using mediation technology (an intermediary like ESB or broker) part of the heterogeneity can be shielded away from the service consumer(s).
By the Intermediary Contract pattern, the service contract of an external service can be adapted to the needs of the service consumer to a certain extent (or formulated differently, the intermediary contract shields the consumer from the actual service provider).
If this pattern is applied to an individual service, the discrepancy between the consumer and the provider of this particular service may be reduced. If this pattern is repeatedly applied on a service-by-service basis, individual discrepancies are reduced, but not very effectively nor efficiently. There is more to gain, meaning heterogeneity can be reduced to a greater extent, when the various external services are treated as a collection and a proper analysis and design phase is executed, leading to more coherent and consistent intermediary contracts, thus to more streamlined (internally exposed) service contracts.
Streamline here also means (to try) to establish a workable standardization for internal use. This can be either true standardization (e.g. on one standard for a specific topic) or working with a very limited number (a specific low number) of competing standards for a specific topic. One of both situations can be the case for each topic of concern, e.g. WS Security for security issues and SOAP over http or just http itself as the protocol. Note that with regards to the options for this workable standardization, the capabilities of the intermediary (or even intermediaries) available (e.g. in the targeted domain) play an important role.
Preferably the standardization is the outcome of an analysis and design process to remodel the collection (as far as their service contracts are concerned) as much as possible in line with the standardization and governance of the service consumers (in either the service inventory or the targeted domain inventory in the own organization/enterprise). As such different intermediary inventories may result for different targeted domain inventories (in addition to differences introduced by potential differences in capabilities of the intermediaries available in the involved domains).
The resulting collection of intermediary contracts for the external provided services forms an Intermediary Inventory.
As an inventory design pattern, the Intermediary Inventory pattern relates to other design pattern for the service inventory architecture. When this inventory is established, with regards to protocols involved, the advocated visible set of a limited number of standards can be viewed as the result of applying a "generalized" Dual Protocols pattern.
Also, when designing the new Intermediary Contracts, the Service Normalization pattern can be applied together with the Inventory Endpoint pattern and in combination with the Capability Composition and Capability Recomposition patterns.
As with the Intermediary Contract pattern, the core quality of this pattern is that it acknowledges the real world fact that not always full standardization can be enforced, yet differences can be bridged and abstracted away to a certain extent. However, where the Intermediary Contract pattern focuses on a single service, this pattern deals essentially with a collection of services. Forcing a more uniform bridging of differences for this collection increases the opportunities for intrinsic interoperability.
As has been stated already an important result (or effect or influence) of the Intermediary Inventory pattern (and for that matter the Intermediary Contract pattern as well) is that the service consumer is provided with a new exposed service contract that abstracts/shields the original service contract. Usually the original service contract will be the service contract exposed by the ultimate service provider. However, this does not to be necessarily so: from an intermediary perspective, the service provider can be in reality another intermediary, resulting in chained inventories and contracts.
Note: the Intermediary Inventory pattern probably will also relate to other candidate design patterns, e.g. Composition Endpoints and Enterprise Domain Repository.
Also it may be considered a less stringent application of various "canonical" patterns, as the Canonical Data Format candidate pattern or the Schema Centralization pattern