The connectivity entry point focuses on providing access to servicesregardless of the location of the consumer or providervia open standards and, when needed, proprietary interfaces. Even when a service is available for reuse, finding it and a way to connect to it can be half the battle. Even if the interfaces match, remote access across networks can be notoriously unreliable. Even with matching interfaces over reliable networks, a service consumer actually needs access to multiple providers of a service, making the service itself reliable and scalable. Even when a consumer knows how to find a provider, the provider may move, in which case the consumer has to be able to find it again.
Service connectivity is best implemented by an enterprise service bus (ESB) and service registry. An ESB acts like a provider to service consumers and a consumer to service providers. It acts as a single connection point to a consumer, but can connect to multiple providers and route different invocations to different providers. When the consumers and providers don't match, the ESB can perform mediations to bridge the differences. The difference might be in data format bridged by a transformation, transport bridged by a conversion, or purpose bridged by a routing. In the process, the ESB can provide and enforce security and act as a point for management and monitoringnot just of the services or even their individual providers, but at an even more fine-grained level, the individual invocations of the services. Meanwhile, the registry keeps track of the available providers of each service, metadata about the providers, and their current status. The ESB can use the registry to find providers when it needs them.
|The more complex service access becomes, the more difficult an SOA is to develop and make operate correctly. Service connectivity encapsulates the access, making the means of access reusable, as well as simplifying both the consumers and the providers.|
The value of service connectivity is that a service that cannot be accessed cannot be used. The more complex service access becomes, the more difficult an SOA is to develop and make operate correctly. Service connectivity encapsulates the access, making the means of access reusable, as well as simplifying both the consumers and the providers. It creates a place to implement mediations so that consumers and providers that don't match can still work together. By necessity, service consumers and providers will tend to evolve somewhat independently; as they do, mediations will help bridge the differences.
Service connectivity fits well into SOA because developing service consumers and providers is only half the battle; they need to be connected as well. If every consumer matched its provider and they evolved in lockstep, each consumer had only one provider, the providers' locations and status never changed, and the consumer and provider ran in the same process or at least on the same machine, then service connectivity would be much simpler. But the promise of SOA is that it will work even when interfaces don't match, will enable each consumer to transparently access multiple providers that are not always available, to access them remotely across networks that aren't always reliable, and will enable providers to change their address, old providers to go offline, and new ones to come online. Service connectivity makes this possible; it decouples the consumer from the provider.
To start developing service connectivity, look for services (that is, service providers) that could be reused more if only they were more accessible. Perhaps multiple Java applications running on UNIX servers are having trouble accessing a service hosted on a mainframe, especially because they can become overloaded or sometimes get taken offline. Perhaps a business partner needs controlled, secure access to a service. Maybe a composite application has consumers running in one data center and providers running in a different data center. Perhaps the binding for accessing a needed service changes from time to time. Service connectivity makes services easier to reuse in general, but especially in these more extreme circumstances.
As we have seen, the IBM SOA Entry Points provide five specific approaches for getting started with SOA. They enable an organization to adopt SOA by building and using services a few at a time, without requiring a significant investment in skills or products. They can help you quickly and easily start down the path towards SOA success.