Professor Martin Healey comes clean on Soap
It is a historic fact that technologies which evolve are more often
accepted than those that are revolutionary. Evolution has been the
success story behind Microsoft's distributed architecture (DCA). It
started with the simple Windows Ole model and has evolved through
Com into the distributed Dcom model. It is still far simpler than
Corba, but the only thing which has halted its progress is the
dependence on Windows 2000. Distributed systems must leave the door
open for inter-working of various platforms. A 'middleware'
architecture is far superior if it is multi-platform, which is the
key strength of Corba.
The arguments over the need for pure object models with
inheritance and polymorphism, compared to the simpler component
model, which only supports encapsulation, will rage for years. But
before we commit to the distributed models of Corba or DCA, it is
worth noting that remote procedure calls, with a thin client PC
calling stored server-side procedures is simple, and has a lot
going for it for some years yet. RPC mechanics need a connection to
be established, and are not suited to complex systems in which
components or objects can be distributed across multiple nodes.
Corba goes further, in using a broker to establish the location
of components at run time, while DCA uses internet addressing
mechanisms based on URL's. These models are thus more dynamic than
the simpler RPC techniques, and can cater for situations in which
resources are moved, added, or removed (load balancing for
example). But while such systems are needed, there are an awful lot
more that are simpler! In particular, the RPC model can be used to
call the execution of procedures in legacy applications, without
the complexity of adding Corba or DCA nodes.
XML has also added a degree of confusion. XML is only a mark-up
language, and it is ideally suited to constructing self-defining
messages from raw data. It is therefore of importance to any system
which interchanges messages. Messages can contain data or commands
or both, XML supporting the meta-data needed to create the
flexibility of modern multi-discipline systems. XML then is simply
the language to add meta-data to data messages, defined for
specific applications by relevant schema.
The Java community is also defining standards which enable Java
components to be distributed. Sun's RMI is a common technique in
which a Java applet in a browser can invoke an object in another
JVM. There is also (and obviously) strong support for Corba through
IIOP, which enables a Java applet to invoke any Corba compliant
object.
But now there is a new and very interesting initiative for
distributed systems called the Simple Object Access Protocol
(Soap). To quote, 'Soap is a lightweight protocol for exchange of
information in a decentralised, distributed environment'. The
accent is on lightweight and if history is repeated this is the key
to a major acceptance of Soap. Soap uses XML to define messages,
which have three basic parts:
l. An envelope which defines what is included and what to do
with the message;
2. A set of encoding rules (schema) for application defined
data, and;
3. A convention for representing remote procedure calls and
responses.
The latter will enable programmers to interface with other
systems, making Soap applicable to a very wide range of
applications, both new and legacy.
A very surprising feature of Soap is that it derives from a
Microsoft development (a big XML supporter), but the proposal,
which I hope will become a standard, has been drawn up by a team
which includes IBM and Lotus representation. According to reports,
the IBM input is serious, and has been welcomed by Microsoft.
Soap is a message based protocol, but it supports either
back-to-back messages or simple response protocols to exploit
interactive applications, so that it could be married to both
asynchronous and synchronous systems. The key feature of the Soap
protocol is that it is independent of underlying protocols. The
proposal document
(http://static.userland.com/xm1RpcCom/soap/SOAPv11.htm) only
defines bindings to HTTP, but the intention is obviously to bind it
to MSMQ, MQSeries, and a host of RPC subsystems, probably including
TP monitors such as Cics, MTS, and Tuxedo.
The simplicity of Soap is extremely attractive, and unlike DCA
it is not tied into Windows 2000. Microsoft, and to a lesser extent
IBM, deserve praise for such an aggressive and realistic solution
to the needs of the bulk of simpler multi-disciple, multi-platform,
distributed systems. I have a feeling Soap will be a major
success.