Web Services Architecture

Posted on by : admin Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Web services are self-contained, modular applications that may be described, published, located, and invoked over a network, generally over the Web [2]. They are rapidly emerging as important building blocks for business integration. They are also finding important applications in business-to-business, business-to-consumer, and enterprise application integration solutions[5]. Important factor in this approach is the independence of interactions from the platform, programming language, middleware, and implementation of the applications involved.

Web Services Functioning

The basis of Web Services is the runtime server. The runtime server processes SOAP messages and provides a runtime container for Web Services. The runtime server can operate as a stand-alone application, or can run within existing servers, such as IIS, iPlanet and Apache. The runtime server listens for SOAP requests from the client. Upon receiving the request, the server then determines how to handle the message that is associated with the request. For example, the server must determine if the message contains attachments, or if security has been implemented, etc. Once the server determines the appropriate way to handle the message, the runtime server processes the SOAP message and translates the XML data into the native language of the service. The server then invokes the service. When the service completes its work, the runtime server translates the return value (anything from a simple type to a cyclic object graph) into XML, packages it into a SOAP response message, and sends the message back to the calling application. Figure 2 depicts the Web Services runtime environment. The Web service concept, is intended to provide standard way of discovering and then using computer programs across the internet and therefore, there are no standard services to perform useful business functions or any consideration as to how a service should be built, and there is no attempt to show how web services might be integrated into an existing application. The mechanism of service description is one of the key elements in Web Services architecture.

Components and Web Services Integration Model

The CBD workbench may be used with Web services to seamlessly integrate both homogeneous and heterogeneous components. Both homogeneous and heterogeneous components in this model would use SOAP as the medium of communication. The integration model to be used in the integration of the Component Based Development workbench and Web Services is depicted in Figure 3. This integration model of CBD and Web services has 5 subsystems:

  • Provider subsystem
  • Component repository
  • Consumer subsystem
  • Main Web service
  • UDDI registry

These subsystems are enumerated as follows:

Provider Subsystem

The provider is the developer, Independent Software Vendor(ISV) or company, which develops and provides functional components, either homogeneous or heterogeneous. The Provider uploads the components in the Component repository. The attributes of the component are simultaneously stored in the database. The provider may create a web service for his/her component and register the web service in the global Registry (UDDI).

Component Repository

The repository search criteria will be matched against the attributes stored in the database and when the user finally chooses a component, the corresponding Web service Description Language (WSDL) Document for that component is sent to the user after dynamically generating a web service for that component functionality.

Consumer Subsystem

The client contacts a web service to search for the component having the desired functionality. The client application retrieves the desired functionality from the web service in either ways:

  • If the component is found in the repository, then a web service is dynamically generated for the component functionality and the WSDL document for that service is returned to the client.
  • Using the component functionalities as a web service already registered in the UDDI registry

Main Web Service

The main web service searches for the client desired functionality in the Component repository that is on the server. If the functionality matches the component in the repository, then a web service is generated dynamically for the component to be used by the client. If the component is not available in the repository, then the main web service lookups the service in the UDDI registry. The details of the service matching the search criteria are returned to the client.