SOAP xml web-services are a 'remoting' mechanism which enables function calls to be made between separate computers (or processes), where data is textually encoded as xml using the 'SOAP' protocol. In principle SOAP is independent of the underlying mechanism used to transport the encoded data, but most often (and in this case) the web's standard http & https transport protocols are used.

Such web-services are now widely accepted and adopted, and since they build on, and leverage off, both xml and http technologies, they are almost de-facto accessible across a wide range of hardware and software environments, and therefore facilitate inter-operability between a diverse range of peers.

Some Advantages of XML Web-Services

Broad Industry Acceptance

SOAP xml web-services have been accepted by a wide range of industry participants and competitors. This is largely because they provide a working solution to the long-running and troublesome problem of genuinely inter-operable service remoting.

For example, components developed using Java and deployed on one platform can easily inter-operate with other components developed using MS dot Net and deployed on a different platform (at least, in principle!). Previous technologies have partially bridged these gaps, but these solutions have often been cumbersome and far from ideal.

XML Message Encoding

Messages are encoded in xml, which has now practically become the ligua franca of data interchange, and for the web. This means that standards are well defined and adhered to, and a wide range of xml processing tools are available for almost all hardware platforms, operating systems and programming languages.

Standard Web Transport Protocols

The SOAP protocol is in principle independent of the mechanism used to transport the messages. However, it is most often used with http & https, with which it works well. These transport protocols are now so well established, that for all practical purposes they are universally accessible and provide a completely standardised data transport mechanism between peers.

WSDL Service Descriptors

Since xml can also be used to form meta-languages, it can also be used to describe web-services themselves electronically. The use of WSDL (Web-Service Definition Language) is particularly powerful and flexible in comparison to the IDL-based descriptors of earlier comparable technologies.

These IDL-based methods, required that an 'Interface' first be constructed using a set of 'lowest-common-denominator' types which had fixed, pre-defined (and not always ideal) cross-context type-mappings.

The wsdl approach is based on a set of encoding rules that allows arbitrarily complex types to be described, ultimately in terms of a set of simple pre-determined 'atomic' types. This means that both simple and complex data-structures can be relatively easily state-serialized to xml for transport, and back again. This provides for a substantial degree of flexibility and extensibility.

Automated Development Tools

Many development environments now include tools which enable xml web-services to be both 'imported' and 'exported' easily.

Such tools often process source code written by a developer, and automatically generate the wsdl and other components necessary to expose the code's functionality as a web-service. Alternatively, such tools will accept the url of a wsdl file, and generate all the necessary 'client-side' code to enable those web-services to be called.

Easier Alignment to Architectural Principles

Assuming, of course, that we do have any underlying architectural principles, and that we wanted to give them a reality outside the world of PowerPoint presentations, some good candidates in the author's areas of activity, might be :

Flexibility.
Adaptability.
Scalability.
Inter-Operability.
Managed Inter-Domain Coupling.

If used correctly, SOAP-based xml web-services can help to deliver these goals in practical terms, and usually rather more quickly and easily than some earlier technologies.

There are, of course, a number of significant issues and problems that need to be taken into account when using such web-services; the author has discussed these in more detail elsewhere.