At the foundation of Service Oriented Architecture (SOA) lies the concept of loose coupling. Modeling a complex system as a web of interacting services each of which are independent in their implementation, hardware, environment, physical location, and qualities of service, provides many advantages for internet-scale application development. Such as: the ability for parts of the system to scale independently. The ability of each service to be implemented and operated in the best environment, based on it’s own criteria analysis be it weighted towards leveraging established legacy to adopting the latest trend or even outsourcing to the best service provider. The ability to evolve and change internally without adverse affect on the system.
In a good SOA design, a Web service is typically coupled to others over a very small surface — the actual message formats (typically a neutral standards such as XML, SOAP, WS-*), the communication protocol (such as HTTP), and the network address. The items comprising the minimal coupling details constitute the “service contract” — everything a consumer needs to know to interact successfully with the service. The service contract details are often captured in a WSDL description.
One of the key unavoidable items of coupling is the endpoint address to which the service responds. This information is often part of the WSDL — but hard wiring addresses also fixes a service to a particular address and thus limits its options for movement to a new location. If for instance a service moves from one server to another (perhaps in another data center) even though the service itself hasn’t changed all the clients have to be updated with the new address.
A common pattern for addressing the mobility of services is with proxy services, a simple-to-configure feature of the WSO2 ESB. Basically, instead of communicating directly with a service, one can route requests through a stable endpoint provided and maintained by the ESB. If a service moves to a new address, only the ESB needs to be reconfigured — all the clients send their requests to the ESB itself.
Discovery mechanisms make this even easier, allowing the ESB to automatically reconfigure itself when a service moves or comes online. Discovery mechanisms also typically can help choose among several appropriate services to send the message to.
WS-Discovery is a standard for many SOA-based systems to look-up endpoints dynamically. The standard uses multi-casting and UDP to find and notify endpoints within a local network. More information about WS-Discovery can be found in the 2004-05 specification.
Scenarios where automated discovery is valuable include: a datacenter where a cluster of well-known production services are undergoing regular creation and destruction (for elasticity or other operational reasons), a local subnet which includes mobile resources (leaving and joining the subnet frequently), or a cloud where the creation and destruction of services is automated by the cloud management system.
WS-Discovery has a well-defined scope and thus doesn’t address all the desirable scenarios of automated discovery of services. It’s designed to locate services in a local network, not across the global network. It has some ability to match services based on properties, but one must be careful that services are stable and well-defined. If for instance WS-Discovery is used to dispatch messages to a set of services, and a new service comes on board that has a different API version, is a development version, or other discrepancy, it must be clearly marked as different from the other services to prevent clients from using it in the same service pool as the production services.
The WSO2 Platform supports WS-Discovery using the following model. The WSO2 Governance Registry includes a WS-Discovery proxy which periodically both broadcasts to and listens for services that have joined the local network. Once found, they endpoint information is collected in the registry so routing systems (such as the WSO2 ESB) can use this endpoint to route messages. Services deployed using WSO2 Carbon products such as the WSO2 Application Server respond to the WS-Discovery messages to advertise their availability. Other services such as Microsoft Windows Communication Foundation also support the WS-Discovery standard and participate in the system.
Thanks to Asanka and his Smart Endpoint Registry post for planting the seed for this post, and his review and creation of the nice diagram!
Jonathan Marsh, VP Business Development and Product Design
Jonathan’s blog: http://jonathanmarsh.net/blog