By Abhay Bakshi
Existing software architectures can be based on anything from primordial procedural programming (C language), to object-oriented programming (C++/Java), to component-oriented programming (J2EE platform), to service-oriented programming. Each step increases the order of complexity of systems development and integration. Project requirements push for the architecture to be settled on by system designers. The service-oriented architecture (SOA) programming paradigm is based on services, and corporations that have system integration needs favor SOA for both internal and external projects.
The term service in SOA is used mostly in reference to enabling network plug and play of devices. Existing examples of SOA implementations consist of JINI, CORBA, the Java RMI mechanism, ebXML, and more lately, Web services.
An implementation of SOA—Web services
Web services are uniquely identified by a Uniform Resource Identifier (URI) and a service contract, which is defined using XML. This service contract includes public interfaces and bindings of the service. Users of a Web service are software systems that communicate with the Web service using XML-based messages formatted as SOAP messages.
A client typically looks for the Web service that fits its requirements most accurately. A client performs this search by looking through a public or private service directory (i.e., service registry). Figure A shows a diagram of this interaction (the steps are listed below).
|Interaction in an SOA environment|
- A service provider registers a service with service directory. The service directory now knows about the location of the service contract.
- A client or service consumer locates the service it needs by querying the service directory. The service directory component returns information about how to bind to a service, the service contract, and possibly more details about the service as requested by the client.
- A client binds to the service provider, which in turn fulfills the requests.
Elaborating on the service directory pattern in Java Web services
The service directory is an integral part of SOA. Figure A showed that both service consumer and service provider need to access the service directory. While a provider publishes services to the service directory, a consumer may locate which service to use based on specific criteria at run time. This run-time feature is what makes service directory a powerful feature of SOA.
Consumers of a service don't know a service's location until they locate it in the registry. Since consumers discover and bind to a service at run time, the service itself may move from location to location without the client's knowledge.
A Java Web service is a classic example of an implementation of SOA. Web services use Universal Description, Discovery, and Integration (UDDI) for service directory implementation.
Characteristics of service directory patterns
A service directory pattern takes care of the location transparency aspect inherent in SOA. The pattern revolves around the main component, which is the Almanac of available services. Even though the service directory is implemented in many ways in SOA systems, it makes a lot of sense to implement the service directory as a Web service itself. Service directory patterns build upon a design principle in object-oriented systems—the principle of separation of implementation from interface.
The simple picture in Figure B gives you an idea about service directory patterns and the associations among the different parts of the pattern.
|Associations among different parts of a service directory pattern|
Figure B shows that a service provider can register service availability or can update or delete already registered services using the Almanac of Available Services. Clients can also locate a specific service or register for the future availability of a service. This major component and the adapter (the adapter design pattern) reside in the service directory.
Structure of UDDI
UDDI exists either as a private UDDI registry (for authorized users) or public UDDI registry (discovery from all over the Internet).
UDDI consists of four data structures:
- Business entity—This is business white and yellow pages information. It describes the service provider.
- Business service—This structure represents a service published by the service provider from the business entity.
- Binding template—This structure is a binding template that describes an aspect of a specific service. Collectively, all the binding templates on a specific service define the technical fingerprint of that service.
- tModel—The technical model (tModel) is used to define a service.
A company can set up and operate its own private UDDI registry implemented by its own developers using software packages from a variety of software vendors (e.g., Apache Axis). Public UDDI registries are made available by software companies such as IBM, Microsoft, Systinet, and xMethods.
Central point of directory access—UDDI in Web services
Web services integrate B2B systems, portals, enterprise applications, business process management systems, workflow processes, and other business intelligence systems. The central point of access for clients is through a specific implementation such as UDDI. UDDI, though optional in SOA, is the most omnipresent directory mechanism employed in Web services. Thorough understanding of service directory patterns and their relationship to UDDI is essential to the proper implementation of Web services.