Issues, Shortcomings, Gotchas...

Issues, Shortcomings, Gotchas…

Now for a dose of reality. Web services hold great promise as a means to help businesses improve efficiency and effectiveness, but they still have some growing up to do.

On the positive side, the fundamental Web services architecture is sound. The standards that have been developed are generally simple to implement and consist of a common means to create content and formats (XML) that can be shared between disparate systems. UDDI is becoming a registry standard; WSDL is adequate for helping applications figure out how to work together; SOAP is useful for enabling applications to talk to each other; and HTTP (a transport protocol) is well known in the industry and makes a good default common protocol.

On the negative side you will find that:

• Few public UDDI directories exist. Hence, getting your Web service "known" will be difficult.

• WSDL needs to be made richer to allow for more automated program-to-program negotiation. For instance, WSDL needs to include the ability to negotiate payments for services delivered (because this is how many Web services providers will make money).

• More work needs to be done by the standards committees to address messaging reliability, security, routing, and the handling of complex transactions.

In other words, Web services standards need to become more mature, particularly in secure transactional environments where reliability, availability, and performance are key considerations if a system is to be used in mission-critical computing situations.

Alternatives

These "gotchas" have been identified to make you aware of current shortcomings of the Web services architecture. Later on, this book discusses some of the standard committee activities that will help remedy them. Meanwhile, be aware that the shortcomings of existing Web services standards do not necessarily prohibit their use for a variety of light-transactional or heavily message-oriented applications where requirements for reliability, security, and manageability may be less stringent than those of mission-critical application environments. Also, it is my position that Web services architecture can be augmented by various third-party hardware and/or software products. In doing so, issues such as security, reliability, transaction handling, performance tuning, and the like can be readily overcome.

There are two ways to "work around" current Web services shortcomings:

1. Use a similar architecture such as CORBA or COM to create Web services type applications (see Figure 0-3); or

   Figure 0-3. Using Other Architectures until Web Services Mature.

   

2. Augment existing Web services protocols with other products that help fill in the gaps.

Figure 0-3 illustrates how many early adopters are implementing Web services today. In this example the object is to move XML data between two points (on the right and left). If an enterprise has strong requirements for reliability, security, and manageability, other architectures such as EDI and CORBA can be used to move XML data. If an enterprise has a lower priority, light-transactional, message-oriented application that does not have those strong requirements, the Web services SOAP protocol can be used.

Another approach that can help remedy some of today's shortcomings is to supplement Web services standards with "point" product (other hardware and software combinations that supplement Web services protocols). For instance, if a Web services administrator required additional security for a particular application, she could install add-on security software. IBM, Hewlett-Packard, RSA, Forum Systems, and others provide such security software. And if an enterprise wished to enhance the manageability of its Web services, third parties such as IBM, HP, webMethods, and others offer Web services management software. Routing shortcomings could also be handled by specialized hardware and software available from a number of suppliers. (Supplier offerings are discussed later in the vendor comparison chapter.)