- The Basics of Web Services
- A Simple Example: Searching for Information
- The Next Generation of the Web
- Interacting with Web Services
- The Technology of Web Services
- XML for Business Collaboration: ebXML
- Web Services versus Other Technologies
- Additional Technologies
- Vendor Approaches to Web Services
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Web Services versus Other Technologies
Web services are not as much like traditional distributed computing technologies such as CORBA, DCOM, and EJB, as they are like Web servers, HTML, and HTTP, on which they are based. Web services are fundamentally one-way, asynchronous messages mapped onto executable software programs. Web services define a data format independent of programming language, operating system, network transport, and data storage mechanism; therefore data has to be mapped into and out of the independent format. Data typing and structure abstracted from underlying implementations of services.
Web services are often compared to remote procedure call invo-more like adapters cations or software components. However, Web services are more appropriately compared to enterprise application integration adapters. Web services define a canonical message format, as EAI software systems, such as MQSeries, TIBCO, NEON, Vitria, and IONA's Orbix E2A, do and define the way in which the message is directed to a service interface through which the data is mapped or transformed onto an underlying application. In other words, the intelligence for understanding how to map a message into a software program is not contained within the interface itself, as it is in CORBA, J2EE, and DCOM, all of which are based on RPC concepts, which tightly couple the service name to the program being invoked. Rather, that intelligence is contained within the XML processor, which consumes the message and follows associated instructions on how to parse the message and map the data into whatever program implements the Web service.
In addition, Web services do not require or assume the existence of the same software system on both ends of a communication path. EAI adapters similarly accept a canonical message format and map the information in the message to an enterprise resource planning (ERP) or other type of enterprise application. Web services are defined at a similar level of abstraction, which allows the same message type to be mapped to multiple applications, including, but certainly not limited to, RPC-based components.
Unlike RPC-oriented middleware, such as CORBA and DCOM, Web services use unidirectional, asynchronous messaging, which is more naturally mapped to a message queuing system, such as MQSeries or JMS, than to CORBA or DCOM; although, of course, Web services are also often mapped to CORBA-, J2EE-, and DCOM-based products. Web services support a request/ response paradigm typical of synchronous, RPC-style communications through emulation; that is, the XML processor rather than the protocol correlates requests with replies. The HTTP mapping of SOAP, for example, does not support protocol-level request/reply correlation.7 The Web services emulation of an RPC is easily mapped to such traditional RPC-based systems as CORBA, EJB, and DCOM, although qualities of service (e.g., security, transactions, and exception handling), are likely to be very different from those available in traditional distributed computing technologies, which are often tied closely to the transport layer, and are specific to each technology.
Because interactions with Web services are accomplished through the programs and databases to which the Web services are mapped, the user experience is likely to be very different from a typical browser-based experience: Web services are more like traditional applications than like browsers, although, of course, browsers may be used. (As mentioned previously, Web services by themselves are not executable but instead have to be mapped to a program, an object, a middleware system, or a database management system.)