WEB SERVICES: Beyond Component- Based Computing by Gaurav Sharma Sri Harsha Reddy Meda

The Objective B2B applications are expected to drive business processes that are no longer constrained by computer related or company related boundaries.

Limitations of existing OO middleware Middleware technologies like CORBA, COM, EJB create islands, which remain separated hindering the communication and collaboration between components over the Internet. The naïve combination of component-based middleware and Web technologies has proven insufficient for such integration. Enterprise Application Integration(EAI) solutions are proprietary, complex to use and not interoperable.

The solution: A Web-based Middleware

Overview of the common middleware architecture Client and Servant Proxies Broker Architectures Generation of Glue

Client and Servant proxies Proxy is an intermediate layer between the client and the servant to enable distribution transparency. At runtime proxy acts as an interceptor. One proxy at the servant side and one at the client side for providing location transparency. Method invocation paradigm is used to represent the request, responses and faults. Message passing is used to handle method invocation. Problems: Server activation and deactivation Hard coding of location information on proxies.

Broker Architectures The broker component is Globally available Introduces a central repository to map logical object references to physical ports. Multiple servants reside on the same server. Servers register with central broker component using shared library or central data store. Servers listen on port assigned by broker for incoming requests. Clients access the broker for the servant’s communication endpoint, a dedicated channel is then established for communication. Problems like Generation of proxies Is a tedious process, error prone, time consuming.

Client Proxy Marshal Unmarshal Receive_result Service_P Client Proxy Marshal Unmarshal Receive_result Service_P Broker Srv_registration Srv_lookup Transmit_message Broker Srv_registration Srv_lookup Transmit_message Server Proxy Marshal Unmarshal Dispatch Receive_request Server Proxy Marshal Unmarshal Dispatch Receive_request Client Call_service_P Start_task Client Call_service_P Start_task Servant Service_i Servant Service_i Server Start_up Main_loop Dispatch Server Start_up Main_loop Dispatch

ClientBrokerServer Client ProxyServer Proxy method call locate server server port marshal unmarshal dispatch start_up assign port register

Generation of Glue Generation of glue is automated by using tools. Express structural interface related information independent of platform, communication and also programming language. IDL is used to describe the interfaces in a programming language using coding conventions or a programming language independent way. Generator parses the interface definitions and automatically generates client side and server side proxies.

Why Web-based Middleware? The Broker pattern describes the common architectural concepts behind various OO middleware. But this is implemented differently by each of them. An example of this limitation is that it is almost impossible to invoke a CORBA servant from a Web-based COM client without using proprietary solutions. Technologies like COM, CORBA were not implemented with the Web in mind. Thus, additional efforts are required to transmit CORBA or COM method requests over HTTP. Usage of static glue limits their ability to meet dynamic requirements of the Web. Thus, integrating existing OO middleware into the Web is not the solution to achieve interoperability.

The Solution (Web-based Middleware) Integrate the Web into OO middleware. Implement the Broker architecture using Internet standard protocols and XML.

Steps required Implementing the Communication Protocol Implementing an Interface Definition Language (IDL) Implementing a Service Directory

SOAP - The Communication Protocol SOAP (Simple Object Access Protocol) is used to expose useful functionality through the Web. Defines the syntax, semantics and order of messages exchanged between peers a decentralized, distributed environment. Leverages HTTP. XML (a self-describing data representation) is used as to structure and encode messages, which makes it easier to interpret messages on the fly.

SOAP Message A SOAP message is based on XML and contains the following parts  Envelope: Top-level container to represent the message. Header: Generic container for added features to a SOAP message. Body: Container for mandatory information intended for the ultimate message receiver. Envelope Header Body

SOAP Message (contd) T14:00:00-05:00 Please get the expert

WSDL - The IDL WSDL (Web Services Definition Language) defines an XML grammar for describing the services as collections of communication endpoints capable of exchanging messages. Used to automatically generate the client-side & the server-side proxies.

WSDL structure Types: Provides data type definitions used to describe the messages exchanged. Message: Represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system. PortType: Set of abstract operations. Each operation refers to an input message and output messages. Binding: Specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType. Port: Specifies an address for a binding, thus defining a single communication endpoint. Service: Used to aggregate a set of related ports.

UDDI – The Service Directory UDDI (Universal Discovery, Description & Integration) provides all functionality of a service broker. It is a specification for distributed Web- based information registries of Web Services. UDDI registries are used to promote and discover these distributed Web Services.

Web Services Operation UDDI Service Registry UDDI Service Registry Client Web Server hosting the Web Service Web Server hosting the Web Service Inquire the Web Service Publish the Web Service Transfer WSDL Request over SOAP Response over SOAP

Web Services Operation (contd) Back-end Enterprise System Back-end Enterprise System Web Service Connectors Incoming Requests Web Server

A Broker is not enough For building sophisticated solutions it is not sufficient to provide a stack of protocols. Information & services must be consumable from any device, any place, anytime. Can be achieved using a virtual execution system (JVM or MS CLR) Web Services infrastructure should support context information such as transaction IDs, security & location. Represent gateways to existing back-end servers. This integration can take advantage of the existing OO middleware technologies. Reuse & integration are support by introducing core services.

Integration via Web Services Include virtual execution engines that can be ported to new environments quickly. SOAP, WSDL & UDDI help to easily integrate existing OO middleware into the Web. Web Services can be connected to CORBA, COM, EJB. X-Schema, XSLT used for data representation & transformation across heterogeneous applications.

Drawbacks Web Services is an immature technology. Interoperability cannot be guaranteed since the used standards are still evolving. Web Services lack OO concepts such as inheritance, polymorphism, or even the notion of objects.

Conclusion Existing OO middleware may still be used to implement complex back-end services, but Web Services will be used to connect these islands across the Internet.

References Michael Stal, “Web Services: Beyond Component-Based Computing”, Communications of the ACM, Oct 2002/Vol 45, No. 10 Philippe Mougin & Christophe Barriolade, “Web Services, Business Objects and Component Models”, Orchestra Networks, White Paper - July

Q&A

Thank You