Adapters For Service Version Compatibility

Service Oriented Computing puts into practice the idea of assembling application components into a network of services that are loosely coupled and able to create flexible business processes that span across organizations. The main benefits of this architecture are reuse of services, abstraction, discoverability and Interoperability. The architecture for service-based applications has three main parts:a provider, a consumer, and a registry. Providers publish or announce their services on registries, where consumers find and then invoke them.A Service is a software component of distinctive functional meaning that typically encapsulates a high-level business concept. It consists of a contract, an interface, an implementation, a business logic and data.The contract provides an informal specification of the purpose, functionality, constraints, and usage of the service. The interface exposes the functionality of the service to clients that are connected to the service using a network. The implementation physically provides the required business logic and appropriate data. It is the technical realization that fulfills the service contract. The service implementation consists of one or more artifacts such as programs, configuration data, and databases. The Business logic that is encapsulated by a service is part of its implementation. It is made available through service interfaces. A service can also include data if it is a data-centric service.Web services are emerging as the next generation software systems in distributed computing. They are being widely adopted in implementing and integrating software components both within and across enterprises. Web Services have three basic platform elements:SOAP, WSDL and UDDI. SOAP is a XML based lightweight protocol for exchange of information in a decentralized, distributed environment. WSDL is an XML based document for describing and locating web services. UDDI is a platform-independent framework for describing services, discovering businesses, and integrating business services by using the Internet. In this paper, we consider the problem of interoperability among different web service technologies and web service versions.Adapters are design patterns that allow two classes with incompatible interfaces to work together. Service adaptation refers to the process of generating a service (the adapter) that mediates the interactions among two services with different interfaces and protocols so that interoperability can occur. The need for adapters in Web services comes from two sources:one is the heterogeneity at the higher levels of the interoperability stack (e.g., at business-level interfaces and protocols), and the other is the high number and diversity of clients, each of which can support different interfaces and protocols, thereby generating the need for providing multiple faces to the same service.Windows Communication Foundation (WCF) is Microsoft’s unified programming model for building service-oriented applications. WCF is designed in accordance with service oriented architecture principles to support distributed computing where services are consumed by consumers. Clients can consume multiple services and services can be consumed by multiple clients. Services are loosely coupled to each other. Services typically have a WSDL interface that any WCF client can use to consume the service, irrespective of which platform the service is hosted on. WCF provides the BasicHttpBinding and the WSHttpBinding as two kinds of bindings that use Http as transport protocol. These are the most interoperable bindings that are useable. The BasicHttpBinding provides a high level of interoperability between WCF and the other frameworks. In terms of standards, it is the implementation of the WS-I Basic Profile1.1specification. It supports SOAP1.1as a messaging protocol. The WSHttpBinding, as the name suggests, allows you to use various WS-*specifications such as WS-Security, WS-Reliable Messaging, WS-Atomic Transaction, WS-Trust, and so on.Metro is an open source web services stack developed by Sun Microsystems. It is bundled with numerous applications servers such as GlassFish and Oracle WebLogic Server. Both Sun Microsystems and Microsoft have worked together to ensure interoperability between Metro and WCF and have come up with WSIT. Web Services Interoperability Technology (WSIT) is an open-source project started by Sun Microsystems to develop the next-generation of web service technologies. It consists of Java programming language APIs that enable advanced WS-*features to be used in a way that is compatible with Microsoft’s Windows Communication Foundation (WCF) as used by.NET.To keep up with the advances in technology, software vendors often release new versions of their applications with new features and security fixes. Their customers, however, may not be willing to upgrade to the latest release. The reason could be the cost associated with the new version of the software or the overhead of training their staff.This issue becomes even more complicated when the software is a service oriented application where the vendor hosts the services on its servers. To solve this problem, service providers often host multiple versions of the same service. This can get out of control as more and more services are hosted. In our research, we propose a methodology for solving this problem.Interoperability among web services requires that services use the same (or compatible) protocols, data formats, and semantics. To interact, services must have compatible interfaces (i.e., the set of operations supported by services) and business protocols (i.e., the allowed message exchange sequences). The main objective of our research is to enable a client designed for an old version of a web service to successfully communicate with a newer version of the same service without making any changes on the client. To accomplish this objective, we propose the design of a service adapter-a web service that mediates the interactions among two services with different interfaces so that interoperability can occur. A key ingredient of the adaptation methodology is the use of mismatch patterns.Accordingly, we have developed a WCF service adapter and the corresponding WCF and Java clients as part of our experiment. Our system architecture consists of four main parts:the clients, the adapter, the web service and the database:The clients, written either in C#or Java, are the consumers of the services provided by the web service. They have a user interface to invoke the services. However, they do not include any kind of implementation in their design. The adapter acts as a mediator between old client versions and new web service versions. Internally, the adapter is both a client and a web service. However, the adapter does not implement the methods it exposes. Instead, it calls the methods exposed by the new version of the web service. The web service is the service provider that implements and exposes web methods. The web methods, with the assistance of the database, perform the required calculations and return the results. Additionally, the web service is responsible for checking the credentials provided by the client against the database before granting access to its web methods. The database resides in a database management system and stores all data. It also performs some calculations through the use of stored procedures.In the second part of our experiment, we dealt with interoperability in two of the most widely used web service technologies (i.e. WCF and Metro). We experimented on BasicHttpBinding and WSHttpBinding, which are two of WCF’s most commonly used protocols. We have analyzed and identified which configurations are the most interoperable using our WCF services and Java clients which were developed in our earlier experiments.Finally, to see if our proposed adapter works in a real world application, we made use of an application previously developed. The application, which is an accounting software for an airport management, was not designed to be a service oriented application. To meet our requirements, therefore, we had to convert a part of it into a web service by exposing the main functionalities of the system as web methods.