Architects at WSO2 recently built a Smart Endpoint Registry solution for a large electronic media distributor. The driving force was the efficient routing of requests to the service best suited for that particular request. To provide the lowest latency the request should be routed to the closest geographical data center. Based on the processing requirements a particular message might be routed to a specialized service. Or requests from premium customers can be routed to higher-capability servers. In addition, services also move regularly between data centers for operational reasons. The solution developed routes requests based on logic matching the message to a list of registered services using metadata such as the type of service requested, the geographical location of the service, the business group the service belongs to, the API version, and so forth.
In this solution, the service definitions and endpoint addresses are stored as resources in a centralized WSO2 Governance Registry. Properties can be associated with each service resource to indicate the geography etc. Routing logic examines these property values to determine the address of the optimum endpoint.
The WSO2 ESB does the actual message routing, picking up message headers (such as the source IP) and comparing it with information in the registry to locate the most appropriate service and determine it’s endpoint address. With endpoint lookup complete, the message can be successfully routed to the optimum service for processing.
As services come online, each service registers itself with the WSO2 Governance Registry by writing it’s details directly to the registry during it’s initialization (in WSO2 Application Server, the “init” method). When they go offline (the “destruct” method) they remove their entries from the Registry. There are two available APIs that can be used to create the appropriate entries and to register the service metadata as properties – a Web services API or the RESTful ATOM-based API. Setting properties is an easy and flexible way to associate structured metadata with a resource as name-value pairs.
A housekeeping task periodically checks that registered services remain online and removes service entries for those that may have gone down without proper destruction.
Composite services (in this case BPEL-based services executed in the WSO2 Business Process Server) can also route their dependent services through the ESB to find the most appropriate match – or they can look up service endpoints directly from the Governance Registry in cases where the full matching logic isn’t necessary.
The Smart Endpoint Registry scenario has similarities with other discovery mechanisms such as WS-Discovery. In both the Smart Endpoint Registry pattern and in WS-Discovery, services coming online are automatically made available to the system. But beyond the surface similarities lie significant differences. This scenario goes beyond WS-Discovery with more sophisticated property matching and searching logic to match services and clients. WS-Discovery also is appropriate for a subnet that supports multi-cast IP, providing standard “hello” and “goodbye” messages to register. But in this case the data centers are widely dispersed and a multi-cast-based discovery mechanism can’t span the network range, and so a customized init/destruct process had to be used.
The WSO2 Carbon platform is an excellent platform for implementing this pattern. The ease and flexibility of adding look-up logic in the ESB using logic control and look-up mediators, the convenient APIs for writing to the Governance Registry and structured properties on each resource, and support for init/destruct in the WSO2 Application Server all combine to offer a straightforward implementation of the solution.
Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/