In part one of this article (Web Services Journal Vol. 1, issue 1), we provided descriptions of what Web Services actually are, including their foundation technologies - WSDL and UDDI - and discussed the fundamental characteristics of distributed architectures in general. Here we use these characteristics to compare Web Services with other popular distributed architectures. Major business applications for Web Services are also presented. We conclude with our analysis of the true readiness of Web Services.

Comparison of Web Services to Other Distributed Systems Implementations
Based on the fundamental characteristics of distributed architectures described in part one of this article, Tables 1-3 compare Web Services (based on SOAP binding) with other popular distributed systems implementations: CORBA, DCOM, and RMI. These tables were compiled based on the structuring discussed.

As we can see from the tables, Web services measure up quite nicely with other distributed systems environments. The main differentiating characteristics are:

• Web services, unlike other distributed systems, support only remote communications, they don't support colocated services.
• Web services are implemented over HTTP, which is a connectionless protocol. Therefore, some important features of distributed systems are not applicable for Web services. Those features include:

  - Remote references are not supported by Web services. A string-based URL, coupled with extra XML information, can serve as a remote reference.
  - Creation of the remote objects is not applicable to Web services. In Web services, a remote object is created by the underlying services for the duration of the request.
  - Synchronization of the life cycles of client and server objects (see above).
  - Since Web services are effectively stateless between invocations (see above), their usage must be based on a slightly different programming model. Every request/reply pair needs to be self-contained. This means that the request has to contain all of the information required for execution and the reply should return back all required information. The Web services programming model is closer to that of message-oriented middleware than programming models of distributed objects.
  - Remote garbage collection in the case of Web services is not required.
  

• Web services use XML as a standard marshaling/unmarshalling mechanism (data representation). This allows their use without stubs/proxies when a client wants to create an XML-based request programmatically.
• UDDI plays a bigger role in Web services compared to that of the naming and trading services in other distributed environments. This is because Web services do not provide for creation of remote objects, and UDDI is the only way to obtain a "remote reference."
• Web services do not support distributed transactions. As such, building complex processes based on Web services requires the introduction of compensating transactions.
• Security and user authentication is a bigger issue for Web services, compared to other distributed architectures, since communications are happening over the public Internet and the number of nonregistered users, based on UDDI advertisement, is unpredictable.
• Web services do not provide event services, but implementing one similar to that of DCOM connection points is very simple.

This architecture promises the following benefits:

• Better interoperability by minimizing the requirements for shared understanding: XML-based Web Services Description Language (WSDL) and a protocol of collaboration and negotiation (UDDI) are the only requirements for shared understanding between a service provider and a service requester. By limiting what is absolutely required for interoperability, collaborating Web services can be truly platform- and language-independent. These limited requirements mean that Web services can be implemented using a large number of different underlying infrastructures.
• Just-in-time integration: Collaborations in Web services are bound dynamically at run time. A service requester describes the capabilities of the service required and uses the service broker infrastructure to find an appropriate service. Once a service with the required capabilities is found, the information from the service's WSDL document is used to bind to it. Dynamic service discovery and invocation (publish, find, bind) and message-oriented collaboration yield applications with looser coupling, enabling just-in-time integration of new applications and services. This in turn yields systems that are self-configuring, adaptive, and robust with fewer single points of failure.
• Reduced complexity by encapsulation: All components in Web services are services. What is important is the type of behavior a service provides, not how it is implemented. A WSDL document is the mechanism to describe the behavior encapsulated by a service. Encapsulation is key to:

  - Coping with complexity. System complexity is reduced when application designers are free from worrying about the implementation details of services they are invoking.
  - Flexibility and scalability. Substitution of different implementations of the same type of service, or multiple equivalent services, is possible at runtime.
  - Extensibility. Behavior is encapsulated and extended by providing new services with similar service descriptions.

• Better interoperability of legacy applications: By allowing legacy applications to be wrapped in WSDL and exposed as services, the Web services architecture easily enables new interoperability between these applications. In addition, security, middleware, and communications technologies can be wrapped to participate in a Web service as environmental prerequisites. Directory technologies, such as LDAP, can be wrapped to act as a service broker. By wrapping the underlying plumbing (communications layer, for example), services insulate the application programmer from the lower layers of the programming stack. This allows services to enable virtual enterprises to link their heterogeneous systems as required (through http-based communications) and/or to participate in single, administrative domain situations, where other communications mechanisms can provide a richer level of functionality.

Use of Web Services
Web services applications can be grouped into three major categories:

• Business Information: Web services can be used to share information with consumers or other businesses. Examples of these types of services include weather reports, news feeds, airline schedules, stock quotes, and product catalogs.
• Business services: Web services can provide transactional, fee-based services for customers. A global value of suppliers can be created that can be leveraged for conducting commerce. These types of services include auctions, marketplaces, credit checks, and ticket reservations.
• Business Process Externalization: Web services allow for the aggregation of internal processes with those in another enterprise, thus creating business processes spanning multiple enterprises.

• Portals aggregate information statically from a fixed URL. They provide optimization technologies, like page caching, to minimize the number of HTTP requests. Modern portals have built-in security and personalization and frequently offer community services such as chat.
• Web services, combined with UDDI, allow for the dynamic aggregation of information. They can query UDDI Yellow Pages to find the most appropriate service, and then include content of this service in the presented information.

Business Services
A service-oriented business founded on Web services is a promising proposition. This approach is very similar to the thin-client revolution. Instead of multiple installations and integrations with other enterprise systems, with the need to keep track of distribution for maintenance and updates, software companies may host their products internally and provide their usage for a fee. This requires:

• Software companies to either have strong alliances with hosting companies or get in the hosting business themselves.
• A very high degree of reliability for these Web services.
• A very high degree of security for these Web services.
• A change in the company's attitude for outsourcing potentially business- critical applications.

• Inability of companies to customize applications in order to better fit their needs.
• Intermediate data in these applications, which might be useful for other applications within the company, is not readily available.

Business Process Externalization Business process externalization and b2b integration are some of the most prominent requirements for today's enterprise. This area is dominated by B2B server products. These tools provide communications over HTTP, guaranteed delivery features, XML parsing support, back-end systems integration, process automation, and more. Web services can have a very strong role in the actual message delivery, coupled with back-end systems integration. Back-end systems can be wrapped into Web services so that they accept messages over the Web. In reality, this does not solve the whole problem of true B2B integration. Web services may serve as an ideal implementation of public business processes, however, private business processes must be implemented on both sides of the firewall. In this case, as in the previous one, use of UDDI is questionable. Key business relationships typically remain intact for long periods of time. Also, we see mostly XML-based communications in this case, adhering to one of the available XML standards (cXML, xCBL, etc), rather than IDL-based communications.

Conclusion
Web services is a great proposition, and may make an excellent addition to the established distributed component platforms, but there is a long way to go to make it a reality for use in mission-critical business applications. As the Web services framework continues to solidify, here are a few things to keep in mind:

• In order for them to really take off, the reliability of Web service and UDDI server implementations has to increase dramatically. These machines have to be up and running all the time.
• Another prerequisite for widespread adoption of Web services is the complete "Webification" of computers. Users can connect to Web services only if they are on the Web. Today, many people still use their computers as disconnected boxes.
• Absence of distributed transaction support presents a serious obstacle for implementing mission-critical business processes based on Web services.
• The UDDI specification as it stands today does not guarantee proper taxonomy of Web services for Yellow Pages. This is left for the implementer to complete. Choice of the proper, universally accepted criteria here is crucial for the viability of UDDI.

Author Bios:
Boris Lublinsky is a Regional Director of Technology for the Central Region at Inventa, where he oversees engagements in EAI, B2B integration, and component-based development of large-scale Web applications. Previously, he was a Technical Architect at Platinum Technology and SSA, where he developed execution platforms for component-based systems. Boris has over 20 years of experience in software engineering and technical architecture. blublinsky@hotmail.com

Michael Farrell Jr. is a Senior Engineer at Inventa Technologies in Chicago, where he serves as technical leader on B2Bi, EAI, and component-based application development projects. Michael is also a certified trainer and delivers courses on a number of systems integration and enterprise applications. Prior to Inventa, he was a Systems Engineer at Intel Corporation, where he implemented distributed applications to support the semiconductor fabrication process. Michael has two degrees from the College of Engineering at The University of Iowa. mfarrell@iowa.dhs.org