The concrete bindings of endpoint services to transport-specific network addresses
Technically, WSDL (Web Services Definition Language) isn't essential, and a SOAP-based infrastructure alone may be sufficient for accomplishing an integration solution. WSDL provides a formal notation for defining the endpoint capabilities in an abstract manner, and a format for encoding the concrete bindings for actual interactions - without which the clients of a service would have to fully understand and hard code the service invocation logic. WSDL captures the endpoint capabilities in an abstract manner so the service can be implemented independently and the necessary client-side interfaces can be generated using tools. The abstract nature of WSDL also makes it possible to develop a reusable client program that can bind dynamically to any service provider who offers the same WSDL interface. In addition, other business scenarios, such as discovery or orchestration of services, depend heavily upon the WSDL abstraction.
Similarly, the Universal Description, Discovery, and Integration (UDDI) interface is not essential to Web services integration, but provides additional capabilities that promote the use of Web services. UDDI provides a standard, interoperable means by which applications and organizations make themselves known, and find each other dynamically over the Internet.
Do They Meet the Requirements?
Let's analyze whether these Web services technologies in fact meet the requirements outlined in the previous section. As we noted before, the primary requirement for the integration solution is to support neutrality along various dimensions by establishing an abstraction layer that hides the specifics of the endpoint implementations. WSDL, along with its use of W3C XML Schema for defining data types, is best suited to define, in an abstract manner, the data types and service interfaces of the disparate endpoints. These data types and service interfaces can be mapped to different languages, middleware interfaces, and so on, thereby providing language/platform neutrality.
WSDL also fully supports transport neutrality as it allows separate specifications of the abstract service interfaces and their bindings for each specific transport protocol. SOAP is the key to supporting a transport-neutral infrastructure for the actual production and consumption of messages, as it supports binding to different transports.
The self-describing XML documents and self-describing SOAP messages make it possible to build a loosely coupled, document-style integration environment. The extensibility of SOAP is critical to bridging the disparate security and transaction models of the applications behind the endpoints. SOAP extensibility facilitates the standardizing of constructs that carry the minimal necessary context for bridging these different security and transaction
models.
Web Services
Web services go a long way toward fulfilling the architectural requirements for enterprise integration. They are neutral with respect to object models and types, and provide asynchronous communication of high-level, semantically rich, XML business documents. Web services are based on emerging standards, and have achieved broad acceptance in the industry in a very short time. We note that Web services standards accomplished this much more quickly than other standards efforts (such as CORBA and J2EE), and we believe this trend is likely to continue.
In addition to addressing most of the existing enterprise integration requirements, Web services also provide an opportunity for standardizing certain capabilities that are either supported in a proprietary manner by integration products or completely missing from the other distributed computing technologies. For example, it is commonly accepted that custom integration solutions that bridge endpoints to meet specific integration needs do not offer much flexibility in adapting the solutions to changing needs.
The changing needs may involve integrating with new endpoints or changes in the business logic that controls the integration application flow. A business process management environment - one that supports complex business rules as well as integrated endpoints in a standard manner - is the real solution in this regard. Although traditional EAI solutions support most of the capabilities needed for business process management, there has been little standardization in this area.
Web services offer a great opportunity in precisely this area. While distributed technologies such as CORBA provide excellent support in integrating disparate endpoints, they do not inherently (or at least not easily) support building business process management solutions. Because Web services provide a semantically rich integration environment, they make it much easier to build business process management solutions that:
Provide semantic mappings between multiple XML business documents in a declarative fashion
Web services expose endpoint capabilities in a self-describing and semantically rich manner. The two basic kinds of capabilities are the document types the endpoint supports and the services the endpoint offers. In addition to making it possible to solve many existing integration problems in a standard manner, these semantically rich descriptions open up new avenues for achieving integration efficiencies.
For example, the use of XML for data format description makes it possible to apply XML-based technologies such as XPATH and XSLT to manipulate the data. Powerful tools can be built to enable business-level features such as content-based routing and data aggregation. Similarly, because the service interfaces are defined in WSDL (which is itself an XML application), XML technologies can be applied to interrogate the service capabilities and integrate discovered functions as Web services orchestrations.
Obviously, new uses of Web services pose new challenges, such as a need for developing standards for Web services orchestration and for encoding the routing logic. Substantial effort is currently being applied by standards bodies, consortia, and private companies to investigate these new avenues and standardize the technologies.
Conclusion
Web services and other distributed technologies, such as J2EE and CORBA, are complementary (see sidebar), and the choice of one over another is a matter of choosing the right tool for the right job. While this is a cliché, it is an illuminating one. After all, is a hammer a "better" tool than a screwdriver? Clichés typically contain a nugget of wisdom, and an even more important one to keep in mind is, "If the only tool you have is a hammer, everything looks like a nail."
Although, theoretically, one technology can be contorted to solve problems that are better solved by another technology, such an effort introduces certain complexities. It is critical to understand that no technology can be a panacea, and that a successful technology always has a particular problem domain that guides its design center.
For example, CORBA is better suited for building distributed applications in controlled environments, where it is possible to share a common object model among all distributed entities, where there are no restrictions on the granularity or volume of the communications between the distributed entities, and where the deployment is more or less permanent such that the system may find a benefit in mapping the network addresses directly to object references. However, the integration scenarios described above require a loose coupling, where CORBA may not be the best fit.
The problems that are paramount in one domain may simply not exist in the other domain. For example, Web services deal mostly with the coarser-grained integration interfaces; therefore, Web services technology, as such, does not have to address object modeling. Object architecture and modeling are hidden from the Web services, as these aspects are relevant only for the design and implementation of the applications, of which only some coarse-grained functions are exposed as Web services.
Extending this notion further, it can be argued that Web services technologies are relieved of the complexities involved with handling object life cycle, object persistence, associating properties with objects, and so on. The need to deal with these complexities in the building of an individual service justifies the rich set of services CORBA and J2EE offer to the application developer, so that complex applications can be developed in a portable manner.
In essence, CORBA and other such technologies are best suited for building complex applications requiring detailed object models and their fine-grained interfaces. Web services technologies are best suited for integrating such applications using high-level, coarse-grained interfaces in a neutral manner.
Given that the problem domain of Web services is quite different from that of other distributed technologies, a feature-by-feature comparison won't be helpful. Using such a comparison to establish the overall "superiority" of one technology over another is counterproductive. The sidebar discusses some of the commonly applicable issues and their relevance to each of the two technologies.
It is possible that the problem domain of Web services will eventually grow to require the definition of a new set of services. Although it is too early to make predictions, the nature of new abstractions and services in the Web services problem domain will most likely involve exploitation of the exposed semantics of data and services by Web services applications such as XML search engines and databases, and will be quite different than those existing today in distributed technologies such as CORBA and J2EE.
For example, there are ongoing efforts to standardize the publishing of additional, feature-specific requirements a service may have for security context or transactional context. These standards are primarily based on WSDL extensibility for defining the feature-specific constructs. Once WSDL begins to carry more information in this way, it is natural that applications will start to dynamically query different parts of (one or more) WSDL definitions to make decisions about which service to invoke, how to invoke it, and so on.
Some queries may take the form of applying well-defined business rules, which themselves are candidates for query by design-time tools. Overall, more semantics will be standardized in the form of message definitions and service interfaces, promoting a wider variety of new applications. Fundamental to supporting such a semantically rich environment will be XML and XML technologies. XML is important for representing the various types of information in a self-describing manner, and XML technologies will be important for processing the XML document instances in various ways, such as queries, aggregation, decomposition, and content extraction.
We hope that we provided some illumination on the use of Web services to solve integration problems, and that we have helped you see the overall context and relationship among various distributed computing technologies. The bottom line is that when it comes to integration technology, one size does not fit all. Web services are a welcome addition to the toolbox, and are in no way an attempt to "reinvent the wheel" for distributed computing.
* * *
Once again, note that these differences are useful for better understanding the two technologies and the problem domains in which each one is the best fit.
Acknowledgement
We wish to thank John Parodi, principal writer at IONA, for writing support, technical editing, and asking the right questions to keep the article focused.
SIDEBAR
Web Services and Component Technologies
Distributed component technologies are similar to Web services in many respects, but there are subtle, and not so subtle, differences. In the list below, we use CORBA as a representative distributed component technology, but these points apply to J2EE and DCOM as well.
1. Standardized API vs standardized message: Both CORBA and Web services provide interoperability across programming languages, operating systems, and hardware platforms. However, CORBA assumes that all interacting entities conform to a standardized object model. Web services standardize the messages exchanged by the interacting entities, which can then be mapped to an arbitrary object model.
2. Programming vs declarative paradigms: CORBA follows the familiar programming paradigm while Web services are more declarative in nature. For example, IDL does not explicitly support building applications by combining different IDL definitions, but Web services standards (such as BPEL4WS) support the creation of process flows without any programming.
3. ACID transactions vs business transactions: CORBA's Object Transaction Service (OTS) offers the combined benefits of the transaction and object paradigms, which implicitly require that transactions that access resources like databases are short lived, under the control of the same organization, and connected via a fast, reliable network. In contrast, the "business transactions" implicit in integration scenarios may last days or weeks and may span autonomous business systems, connected over any type of network.
4. Object vs message paradigm: Most CORBA systems use a Factory pattern for object creation, in which a client interacts with an object instance returned by the factory. This pattern is not relevant for the Web services' message-driven model, in which the type and content of the message determine how it is processed.
5. IOR vs URL: CORBA Interoperable Object References (IORs) provide location transparency for objects and are strongly typed. Web services are addressed via URLs, which are not strongly typed. A client sends a message to a URL, which may be a proxy that routes the message to the appropriate application.
6. IDL vs WSDL: Some of the differences are that WSDL combines both an interface definition and an (optional) endpoint definition (i.e., the location of the service on the network) whereas IDL only defines the interface; WSDL uses the W3C schema for a type system, which is richer than IDL's type system (for example, W3C schema lets you specify a valid range of values for a data member); and WSDL provides the ability to bind to multiple transports (while it is possible to bind IDL to multiple transports, IIOP is the only one that is widely supported).
7. Static binding vs dynamic binding: In CORBA, an object reference is bound to a particular instance of the service provider object, making it hard to support proxy patterns that dynamically select and change client binding to a new service. Web services support development of reusable clients based on the abstract service interfaces in the WSDL. At runtime, the client can bind to specific instances of any service that complies with the same WSDL. For developing loosely coupled systems, dynamic binding provides more flexibility, and Web services are therefore a good fit.
8. Naming/Trading service vs UDDI: The Naming service maps a logical name to an object reference. The Trading service lets you find a service based on specified service properties. UDDI is more like a Trading service in that a client can query a UDDI registry to find the technical details of a Web service. UDDI supports categorization of services using multiple criteria, and is a general-purpose registry that can be used to query any kind of service, not just Web services. Finally, UDDI provides access to far more information, such as bindings to the services.
9. Application platform vs integration platform: CORBA and J2EE are best suited for developing distributed object-oriented applications. Web services are best suited as the underlying technology for an integration platform for developing message-oriented integration solutions.
10. Intra-domain vs. extra-domain Integration: CORBA is best for developing complex applications within a domain, with centrally designed roles and responsibilities of all participants in the context of an overall application model, where deployments are less subject to change and static bindings provide higher efficiencies. But it is not always feasible to get an agreement for a shared application model, nor to live with dependency across the domains. In these scenarios, a loose coupling is preferable, whereby domains can independently design and deploy their applications, and the agreement for interoperability can be reduced to message and coarse-grained service definitions.
Author Bios
Sanjay Patil is a distinguished engineer within the Web Services Integration Platform group at IONA Technologies. He is actively involved with many e-business standards; his areas of interest are distributed infrastructure for B2B and enterprise integration, Web services, and Internet technologies.
sanjay.patil@iona.com
Nick Simha is a sales engineer working with IONA's customers to help architect e-business solutions. His areas of interest are application integration, Web services, supply chain management, and security.
nsimha@iona.com
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com
