Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. 1 Expert Topic Report-Overview of Web Services Date: January 30, 2003 Submitted by: Fan Chen Submitted for: Professor H. - Arno Jacobsen Course: ECE1770 Abstract—Web Services are new trends in the middleware world. This report synthesizes the literature of Web Service reviewed. It first gives an overview of Web Services by describing its concept, architecture as well as operations. This is followed by a comparison Web Services and CORBA. At the end, a brief discussion on integrating Web Services and CORBA is presented. I.INTRODUCTION T he wide acceptance of Web-based applications make Web the most important user interface ever. In the early stage of E-business, companies mostly dealt with customer- to-business, namely B2C interactions on the front end. With E-business entering a new stage where B2B interactions are required, large corporations face the challenges of integrating  business applications over heterogeneous platforms. Web
  2. 2. 2 Services come to the market as the need for application-to- • Interact: In the interact operation, a service requestor application communications and interoperability through initiates an interaction with the service using the binding generic Internet protocol grows. It has soon become a very details to in the service description tolocate, contact and hot new technology supported by many major vendors in the invok ethe service. market. What is a Web Service? What benefits can this technology bring to the distributed computation Figure 1. shows the basic architeture of Web Services environment? And how does it differ from other middleware platforms? In this report aims at giving an overview of Web Services and provides some arguments to answer questions raised above. It is organized as follows. Sections II gives an overview of Web Services. Section III describes the key protocols of Web Services. Section IV examines the characteristics or Web Services and compares Web Services with CORBA. Sections V summarize some related work to integrate Web Services and CORBA. Conclusion is presented at Section VI. II.DEFINITION AND ARCHITECTURE OF WEB SERVCIES Web standardization World Wide Web Consortium defines Figure 1.Basic architecture of Web Services described by Web Services in [1] as following: A Web service is a [1] software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its To perform the three operations of publish, find and bind definition can be discovered by other software systems. in an interoperable manner, there must be a Web Services These systems may then interact with the Web service in a stack that embraces standards at each level. IBM software manner prescribed group describes a conceptual Web services stack in [3] as Figure 2. by its definition, using XML based messages conveyed by The key standards established to fulfill the functions of internet protocols. This definition shows the Web aspects of this stack are listed at the left side of the stack and will be Web Services, which are XML-based and transmitted by discussed in the following section. The three vertical towers internet protocols. The services provided by software systems of Quality of service, Management and Security must been are discoverable and reusable. addressed in every layer of the stack. [1] describes the architecture of Web Services that fits into the catergory of Service-Oriented Architecture. More information Service Oriented Achitecture can be found in [2]. The Web Services architecture includes two components: • The Service: A service is an interface described by a service description. It is a software module deployed on network accessible platforms provided by the service provider. • The Service Description: The service description contains the details of the interface and implementation of the service. The architecture is based on the interactions between three roles as following: • Service providers -- processes a Web service request • Service requester -- requests the execution of a Web service • Discovery agency -- agency through which a Web service description is published and made discoverable Figure 2. The Conceptual Web Services Stack Correspondingly, [1] describe three operations: • Publish: In oder to be accessible, a service needs to publish its description such that the requestor can III.STANDARDS OF WEB SERVICES subsequebtly find it. • Find: In the find opeartion, the service requsetor retrives The major standardization bodies in Web technologies are a service decsription directly or queries the registry for W3C (World Wide Web Consortium), OASIS ( the type of service required. Organization of Structured Information Standards) and
  3. 3. 3 WS-I (Web Services Interoperation Organization) and digital signatures for WS. . The active members of these organizations are important Although various solutions have been proposed, players in the industry such as IBM, Microsoft, SAP and currently none of them have been widely accepted as Oracle. The standardization of Web Services is still in its standards. Even for the core protocols such as SOAP, there early stage. Currently there are four core protocols have well are implementation level mismatches that make a simple evolved: interaction awkward as described in [4]. In conclusion, there is a long way to go before standardizing Web Services and • XML: The Extensible Markup Language 1.0 standard is making the evolving technologies workable in practical a text-based markup language specification from the business application integrations. World Wide Web Consortium (W3C). Unlike HTML, which uses tags for describing presentation and data, IV.WEB SERVICES AND CORBA XML is strictly for the definition of portable structured Web Services are trendy. The history of distributed data. computing proves that mass support is critical to a • SOAP: Object Access Protocol is an XML-based middleware technology. Web services have the competitive lightweight protocol for the exchange of information in a advantage of being supported by a bunch of big companies decentralized, distributed environment. SOAP defines a over other middleware platforms. However, this does not messaging protocol between requestor and provider guarantee Web Services will become final solutions to objects, such that the requesting objects can perform a business application interactions problems. Nor does this remote method invocation on the providing objects in an assures the idea that other middleware platforms are simply object-oriented programming fashion. obsolete. Recently there is a lot of attention paid to the • WSDL: The Web Services Description Language is an relationship between Web Services and other middleware XML vocabulary that provides a standard way of technologies. As one of the more mature and widely describing services. It provides a simple way for service deployed platform, CORBA receives a great emphasis in the providers to describe the format of requests and response discussion. Some are very optimistic about the future of Web messages for remote method invocations (RMI). Services and some tend to believe Web Services are more • UDDI: Universal Discovery Description and Integration used as a marketing term at the current stage. However, most is a specification for information registries of Web literatures reviewed argue that Web Services and CORBA services. It provides a mechanism for clients to should complement each other. Following synthesizes some dynamically find other web services. comparisons Web Services and CORBA in [5, 6, 7,14] • Data Model These four protocols, however, do not address the CORBA is an object-oriented component framework, technical issues in the areas of business process management, whereas Web Services are centered on SOAP messages quality of service, management and security. [3] discusses exchanging model. CORBA enables object-oriented programs the function requirements that Web Services have to fulfill to seek out and use objects on a remote server so it can be more before they can achieve seamless interoperability among powerful to build and deploy distributed systems. SOAP can participating entities. Major commercial or non-commercial be leveraged to provide data sharing and transformation players in Web Services are proposing different solutions to between applications. This may explain why [6] suggests that above issues. Some interesting progresses are: middleware can be viewed as platform middleware such as • Business Progress Management CORBA, integration middleware such as Web Services. BEA, Sun, Intalio and SAP have released the specification • Client Server Coupling for Web Service Choreography Interface (WSCI) [8]. WSCI Web Services are loosely coupled. In software is an interface description language based on WSDL for development, coupling typically refers to the degree to which describing the flow of messages exchanged by a Web software components depend upon each other. Although Services participating in choreographed interactions with there is no way to avoid coupling, keeping the coupling loose other Web Services. It is an attempt to standardize an XML is valued in a distributed computing environment. Service- based syntax for service choreography. IBM and Microsoft oriented architectures provide built-in mechanisms to are also currently working together on a similar proposal that facilitate loose couplings between services and other would merge IBM’s WSFL [9] and Microsoft’s XLANG components of an application. A Web Service is a typical [10]. The new merged version is BPEL4WS (Business example of how Service Oriented Architecture provides Process Execution Language for Web Services)[13]. loosely coupled benefits. Services are location transparent, protocol independent and can be called synchronously or • Routing asynchronously. XML messages in Web Services have Microsoft has released the specification for a synchronous relatively general meaning, and it is up to the receiver to routing protocol, called WS-Routing, for SOAP messages interpret them. Software systems often simply ignore over a variety of protocols like HTTP, TCP and UDP [11]. unknown in XML messages. On the contrary, CORBA is • Security tightly coupled. It assumes that both of the sender and the IBM, Microsoft and VeriSign defined the specification for receiver agree on the message context. Both the client and Web Services [12]. It defines a set of SOAP headers that the server share the same interface and must run ORB at both could be used to specify security measures like encryption ends.
  4. 4. 4 • Type Checking security and transaction management, and complexity of the CORBA uses static checking as well as runtime checking. platforms. From technologies’ point of view, it is misguided In static invocation via stub and skeletons, IDL (Interface to compare an evolving platform such as Web Services with Definition Language) can provide some static guarantees. In CORBA, which has been around for much longer time, in a dynamic invocation, CORBA Dynamic Invocation above areas. The stack of Web Services will be filled up and Interface (DII) can only provide runtime type checking. By eventually critical features have to been standardized. But contrast, there is no support to static checking in Web then the complexity of Web Services will also increase. What Services. With SOAP, there won’t be type errors until the is likely to be agreed upon is that there will not be one-size- XML message is validated in the server at runtime. This may fit-all solution. Web services and CORBA will have their make debugging harder. own regime and possibly complement each other. Following • Firewall Traversal sections will look at the integration of Web Services and It is crucial for communications between applications can CORBA. traverse firewalls when deploying business-to-business interactions and integrations between enterprises. HTTP is V.WEB SERVICES AND CORBA INTEGRATION the preferable transport layer protocol to convey SOAP Current discussions of integrating Web Services and messages. Since firewalls are usually configured to allow CORBA are focusing on theoretical rationalization other than HTTP traffic to pass though, the presence of Web Services practical implementation experience. [5], [6] and [14] does not require any changes in the firewall. Technically, suggest that Web Services and CORBA are more CORBA’s messaging protocol IIOP (Internet Inter-Orb complementary than competing and they should be used Protocol) can also penetrate a firewall. But at the time when together to achieve the most desired result in distributing IIOP was introduced in 1995, firewalls were configured to computing. Traditional CORBA integration approaches have view IIOP as a new protocol and block IIOP traffic. typically been used to integrate systems within controlled However, [6] overstates the difficulty for IIOP to work with environments. Web services, on the other hand, appear to firewalls by emphasizing some political reasons such as that hold promise not only for integration within an intranet, but the Web community is unwilling to accept IIOP. Actually also integration across the Internet. Despite all the hype since CORBA 2.0's launch back in 1995, IIOP/HTTP gateways around Web Services, without the existence of back-end were launched to enable IIOP tunneling over HTTP. OMG integrated systems based on traditional middleware, such as (Object Management Group) is working on the CORBA CORBA, Web Services has no services to share because it Firewall Traversal specification but currently it is still under alone cannot implement services. development and not supported by ORB (Object Request There are several ways to combine Web Services and Broker) vendors. CORBA: • Performance • Exposing CORBA objects as web services CORBA uses binary coding for data transmission whilst [6] elaborates the pros and cons of this approach. To avoid SOAP represents its message content using text-based XML. simplify the idea of integrating Web Service and CPRBA, [6] This results in a larger XML message size as compared to the raises a point that careful examination is desired to decide optimized formats used by CORBA and hence a larger whether CORBA interfaces should be exposed to Web volume of XML data to be transported over the network. Services before considering how to expose them. [6] argues This can a problem to applications that. Although XML is that not all CORBA interfaces are suitable to expose to Web relatively simple, the system has to extract SOAP envelope Services. For example, a CORBA interface that requires a from the transport packet and parse the contained XML number of calls to access a remote object may become messages. This procedure is processor intensive and requires unworkable in an Internet environment with long latency. more memory and time resources. However, [14] suggests Another example is many IDL interfaces may be at too low a that the degree to which larger messages and Marshaling level of abstraction to be exposed. For example, when two complexity have noticeable impact on an application depends operations for an interface should be called in a certain order, heavily on the nature of the application and the computing it is a good idea to move into a higher level at which a single and networking environment. This is indeed a fair new operation is defined to call the two operations in a justification as compared to some marketing oriented correct order. In a word, too much work to do before arguments. exposing IDL interfaces to Web Services. More impressively, • Stateful Applications Support [14] simply dismisses the approach of exposing CORBA SOAP’s reliance on HTTP as transport protocol makes it objects as Web Services because there are too many unsolved inherently stateless because HTTP is connectionless and issues. For example, how to deal with the Naming Service for dictates a request and response mechanism. [5] argues that en exposed CORBA objects? Would a client of such a web this characteristic complicates the development of service know enough about Naming to be able to navigate it transaction-based applications. By contrast with SOPA, and find its target service? [14] believes this kind of CORBA supports both stateful and stateless. It is expected questions impose obstacles that are hard to overcome in that SOAP will inevitably have a session mechanism to practice. Some projects tend to consider integration and enable transactional requests. mapping at only the transport and protocol levels but ignore application choreographies. Arguably, they are untenable Other comparisons are centered around features such as and may only work well for limited cases.
  5. 5. 5 • Implement CORBA objects using web services. VI.CONCLUSIONS Since by nature CORBA completely hides implementation details, it is straightforward to shield the client from the fact This report summarizes the concepts, architecture and that the object's servant invoked one or more web services to operations of Web Services, and some interesting discussion carry out the client's requests. Such a CORBA object would on the relationship between Web Services and CORBA. Web serve as a wrapper for the web services that implement it, Services are regarded as promising middleware technologies and its primary responsibility would be mapping between that can ease the pain of integrating software systems over CORBA application choreographies and Web Service Internet. However, it is misguided to dictate that one solution application choreographies. can solve all problems. Rather than competing with existing • Implement Web Services using CORBA Objects middleware technologies, Web Services are expected to Due the fact that Web Services cannot be used to complement other middleware platforms as well as benefit implement services, CORBA is an ideal choice for Web from the interoperability. But much has to be done to achieve Service to implement back-end objects that can be accessed this goal. by clients through Web Services. [6] looks into the details of this approach. The major concern is that WSDL uses XML REFERENCES Schema to define data types, which may be too complex to [1] Web Service Architecture, W3C Working Draft 14 November 2002. be mapped into other languages such as IDL. The proposed Available: http://www.w3.org/TR/2002/WD-ws-arch-20021114/. solution is to define a subset of types that can be easily [2] Rakesh Agrawal, Roberto J. Bayardo Jr., Daniel Gruhl, and Spiros Papadimitriou, Vinci: A Service Oriented Architecture for Rapid mapped into other languages. Development of Web Applications, Proceedings of the 10th International [5] examines a real-world value-added service, Mobile Conference on World Wide Web, ACM, 2001,HK. Available: Restaurant Locator, by which a WAP-enable sell phone can http://portal.acm.org/citation.cfm? id=372088&coll=portal&dl=ACM&CFID=7011456&CFTOKEN=7625 locate restaurant in the neighborhood. The conclusion is 4074. CORBA is required to provide a scalable and reliable [3] Heather Kreger, Web Services Conceptual Architecture (WSCA 1.0), solution to bind together the carrier's network elements that IBM Software Group. communicate via different protocols. On the other hand, Available: http://www-3.ibm.com/software/solutions/webservices/pdf/ WSCA.pdf SOAP enables a third party with a web-based, limited access [4] Pradyumna Siddhartha , Shubhashis Sengupta , Web Services to the carrier's telephony network. In order to accomplish Interoperability: A Practitioner's Experience, Lecture Notes in interoperability between Web Services and CORBA, [5] Computer Science Volume 2519, Issue , pp 587-601, Springer-Verlag present a scenario in which SOPA to CORBA gateway is Berlin Heidelberg 2002. Available: http://link.springer.de/link/service/series/0558/papers/2519/25190587.p installed to perform the automatic conversion between SOPA df and CORBA IIOP messages as showed in Figure 3. [5] Aniruddha Gokhale, Bharat Kumar, Arnaud Sahuguet, Reventing the Wheel? CORBA vs. Web Services. Available: http://www2002.org/CDROM/alternate/395/ [6] Sean Baker, Web Services and CORBA, Lecture Notes in Computer Science Volume 2519, Issue, pp 618-632, Springer-Verlag Berlin Heidelberg 2002. Available: http://link.springer.de/link/service/series/0558/papers/2519/25190618.p df [7] Irmen de Jong, Web Services/SOAP and CORBA, Available: http://www.xs4all.nl/~irmen/comp/CORBA%20vs%20SOAP.html1 [8] Arkin, A., Askary, S., Fordin, S., Jekeli, W., Kawaguchi, K., Orchard, D., Pogliani, S.,Riemer, K., Struble, S., Takacsi-Nagy, P., Trickovic, I., Zimek, S. Web Service Choreography Interface 1.0 Specification, BEA, Intalio, SAP and Sun, June 2002. Available: http://ftpna2.bea.com/pub/downloads/wsci-spec-10.pdf [9] R. Leymann, F. Web Services Flow Language (WSFL 1.0), IBM, May 2001. Available: http://www.ibm.com/software/solutions/webservices/pdf/WSFL.pdf Figure 3. Accessing CORBA Objects via Web Services [10] Thatte, S. XLANG Web Services for Business Process Design, Microsoft, 2001 Available: http://www.gotdotnet.com/team/xml_wsspecs/xlang- c/default.htm What the gateway does is to convert CORBA IIOP [11] WS-Routing Specification Index Page, Microsoft, October . Available: http://msdn.microsoft.com/library/en- messages to SOAP messages. Since SOPA messages are us/dnglobspec/html/wsroutspecindex.asp simply XML messages and CORBA services are described [12] Atkinson, B., Della-Libera, G., Hada, S., Hondo, M., Hallam-Baker, P., by IDL, this equals mapping XML to IDL. As mentioned in Kaler, C., Klein, J., LaMacchia, B., Leach, P., Manferdelli, J., Maruyama, H., Nadalin, A., Nagaratnam, N., Prafullchandra, H., “Implementing Web Services using CORBA Objects”, this Shewchuk, J., Simon, D. Web Services Security (WS-Security) Version mapping is currently an open issue to be addressed. So it is 1.0, IM, Microsoft and VeriSign, April 2002. Available: justified to say that the above scenario remains conceptual, as ftp://www.software.ibm.com/software/developer/library/ws-secure.pdf there are no enough practical implementations to evaluate the [13] Business Process Execution Language for Web Services, Version 1.0, IBM, 31 July 2002. Available: performance of the gateway. http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/ [14] Douglas C. Schmidt and Steve Vinoski, Object Interconnections: CORBA and XML-Part 3: SOAP and Web Services, C/C++ Users Journal, 2001. Available: http://www.cuj.com/experts/1910/vinoski.htm
  6. 6. 6