1 / 28

WEB SERVICES : Beyond Component-Based Computing

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.

adonis
Télécharger la présentation

WEB SERVICES : Beyond Component-Based Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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.

  4. The solution: A Web-based Middleware

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

  6. 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.

  7. 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.

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

  9. Client Broker Server Client Proxy Server Proxy register start_up method call locate server assign port server port marshal unmarshal dispatch marshal unmarshal

  10. 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.

  11. 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.

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

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

  14. 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.

  15. 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

  16. SOAP Message (contd) <?xml version="1.0" encoding="UTF-8" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"> <env:Header> <n:someattribute xmlns:n="http://example.org/someattribute"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:someattribute> </env:Header> <env:Body> <m:someinfo xmlns:m="http://example.org/someinfo"> <m:msg>Please get the expert</m:msg> </m:someinfo> </env:Body> </env:Envelope>

  17. 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.

  18. 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.

  19. 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.

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

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

  22. 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.

  23. 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.

  24. 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.

  25. 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.

  26. 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 2001 • http://www.w3.org/TR/SOAP • http://www.w3.org/TR/wsdl • http://middleware.internet2.edu

  27. Q&A

  28. Thank You

More Related