• Web Services processing is loosely coupled. Earlier attempts to address cross-domain interoperability often assumed a common application environment at both ends of a transaction. Web Services allow the subscriber and provider to adopt the technology that is most suited to their needs to do the actual processing.
• Web Services use XML-based messages. Web Services using XML have a flexible model for data interchange that is independent of the computing environment.
• Participating in Web Services does not require abandoning existing investments in software. Existing applications can be used for Web Services by adding a Web Services front end. This makes possible the gradual adoption of Web Services.
• Software vendors are coming out with tools to support the use of Web Services. Organizations can use currently available tools from vendors such as IBM, Microsoft, Sun, and others. There is no delay between interest in the technology and the availability of tools to implement and use Web Services.
• There is a lot of emphasis on the interoperability of Web Services. Web Services tool developers are working to demonstrate interoperability between implementations. It’s likely that this will pay off and allow developers to choose tools from one vendor and be confident that they will be able to interoperate with other implementations.
• The modular way Web Services are being defined allows implementers to pick and choose what techniques they will adopt. Other than having a basis in XML, SOAP, UDDI, and WSDL, the building blocks of Web Services have related, but independent capabilities. They are not tightly coupled and don’t depend on each other to function.
• Use of Internet standard protocols means that most organizations already have much of the communications software and infrastructure needed to support Web Services. Few new protocols need to be supported, and existing development environments and languages can be used.
• Web Services can be built and interoperate independently of the underlying programming language and operating system. In organizations where there isn’t a single standard, Web Services make interoperability possible, even when one part of the organization uses .NET, while another portion uses Java, to build their Web services, and other organizations use other technologie

Reservations about Web Services fall into two categories. First, Web Services are not proven technology; there is some suspicion that Web Services are the fashionable solution of the day. That is, some think that Web Services are the current fad, and like many other solutions to the distributed processing problem from the past, they will not deliver. While we cannot disprove this, the advantages that Web Services have over past solutions are significant.

The second reservation about Web Services centers on its reliance on XML. While there are many advantages to XML, size is not one of them. Use of XML expands the size of data several times over. The size of a SOAP message translates into more storage and transmission time. The flexibility of SOAP means that more processing is needed to format and parse messages. Do the advantages of XML outweigh the additional storage requirements, transmission time, and processing needed? The answer is a qualified yes. The flexibility offered by XML is required when trying to connect two dissimilar processing environments in a useful way. Spanning processing domains requires a flexible representation. However, once a message is within a single environment, on either side of the connection, implementers must decide the extent to which XML is required. XML will not always be the choice to represent data within a single processing domain.