- 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
Vendor Approaches to Web Services
Software vendors, both large and small, are providing Web services implementations as product add-ons or as entirely new products.
Web services do not fundamentally change existing software systems, although they can change how software systems are put together. The differences in implementation usually follow the differences in philosophy, or approach, of the vendors: Are Web services a fundamental enabling technology? Or are they simply entry and exit points to and from existing software systems? In other words, vendors vary in their approach to Web services, depending on the extent to which they view Web services as impacting existing software system architectures. For example, do Web services invalidate J2EE, or are they complementary? The answers to these and other similar questions can be discovered in a vendor's approach
The five basic approaches to Web services are to map them
Into and out of a database management system
Into and out of an application server
Into and out of an integration broker
Between technology domains
To architectural software building blocks or functional components
In other words, Web services implementers fundamentally distinguish between Web services technologies and underlying software implementations. Web services, therefore, are either incidental aspects of existing software systems or a required part of the infrastructure.
Can an application server, object request broker, or database management system successfully continue to exist without support for Web services? Or can Web services exist on their own?
Thus the question is, where does the value lie? With application servers, database management systems, and integration brokers, leaving Web services to be merely a means of mapping data into and out of existing software systems? Or does the value lie with the Web services themselves, as fundamental to a new category of software systems?
Vendor implementations tend to be divided among these varying views of the value of Web services. Not surprisingly, Microsoft has its own view, whereas Sun Microsystems, IBM, BEA Systems, Oracle, and others are taking an alternative view. To some extent, this divergence of vendor views, or initiatives, represents a continuation of the Visual Basic/Java developer battle, but Microsoft is taking a very bold and aggressive stance on Web services, even breaking current Visual Basic applications to ensure that the future version of VB will support Web services as fundamental enabling technology. The Java community is taking a less radical view, extending Java APIs for Web services rather than requiring a rewrite to incorporate them.
Industry business consortia, such as ebXML and OASIS, as well as integration broker products from such vendors as IBM, Microsoft, IONA, and WebMethods, tend to focus on the business process, or document-oriented type of applications for Web services. Other vendors' products, such as the Web services toolkits shipped with BEA's WebLogic and IONA's J2EE Edition, tend to focus on the RPC style of interaction. The same XML-based technologies and standards can generally be used for either, but initiatives and products tend to focus on one or the other because the paradigms are so different. In general, application servers tend to support the RPC style of interaction, whereas integration brokers tend to support the asynchronous document-oriented style of interaction.
What Are Web Services Good For?
The answer to this question may well vary by vendor, depending on the particular approach to Web services implementation. Web services are generally not replacements for any existing technologies but rather are complementary, another tool in the toolbox, as it were. Web services represent loosely coupled interactions, which are better suited to integrating disparate software domains and bridging incompatible technologies, rather than heavy-duty, high-performance applications. Web services are also very good for submitting documents to long-running business process flows, which seem in any case to be a good way to start with interactions over the Internet.
Integration broker vendors, such as WebMethods, Vitria, SeeBeyond, Software AG, and Mercator, typically view Web services as an extension of classic enterprise and business-to-business integration technologies and have built adapters for Web services as they would build adapters for any other technology with which their products have to integrate. Other vendors, such as IONA, take a more neutral and encompassing view of Web services as both enabling technology for extending existing application server, CORBA, and COM mid-dleware and as fundamental to the next generation of enterprise and business integration standards. IONA's Orbix E2A product line provides not only Web services adapters for asynchronous, document-oriented processing and RPC-oriented Web services interfaces for CORBA and J2EE-compliant objects but also fundamental Web services building blocks. The IONA business process engine, XML conversion and transformation engine, packaged application adapters, and business protocol framework all export Web service interfaces. The IONA products support a consistent approach to application integration, using Web services technologies inside and outside the firewall.
Finally, a number of vendors view Web services as an interesting and potentially profitable technology in their own right and have developed "pure-play" Web services products. These products, based entirely on Web services technology, typically require use with other technologies and products. For example, Cape Clear markets a Web services product aimed at bridging J2EE and .NET. Shinka markets a product that presumes that Web services are a fundamental design center and that programs will be developed to map into them, rather than vice versa, which is what most other vendors appear to believe.