What is a SOAP Service?
SOAP has received a fairly large amount of hype some based on reality and some not. At it's heart SOAP is simply concerned with processing a class of XML
document with a standard formal structure - this
is called a SOAP message. A SOAP message consists of an envelope containing one or more header parts and a body part. A SOAP service is
simply a process which can deal with the formal structure of a SOAP message.
A SOAP service is bound to a transport in order to receive messages and send responses. The SOAP standard
permits extensible transport bindings, however in reality the HTTP application protocol is used almost exclusively.
Encodings
The formal message structure and transport bindings is really all there is to SOAP. However SOAP also specifies formal encodings which may
be used by certain classes of service.
One significant class of service is the remote procedure call (RPC), in which a message to a service initiates a call on a procedure.
To support such service patterns SOAP specifies a formal RPC encoding to be used for the message content of the SOAP body when requesting an
SOAP-RPC service. With NetKernel's SOAP client it is relatively simple to create a SOAP message with an RPC encoded body and issue this to a remote
SOAP-RPC service.
RPC has a long history as a way to build distributed systems but is increasingly seen as a brittle approach to service oriented architectures.
Increasingly SOAP services avoid using RPC and instead use the SOAP message structure to send application
specific XML documents - this model is called document-based with literal encoding or doc/lit for short. Since NetKernel is a service-oriented operating system
and provides a declarative model for service composition which lends itself to doc/lit processing we have chosen not to support RPC at this time - indeed
NetKernel doesn't really have a concept of a procedure, everything is a service.
Standards Maturity
The vast majority of today's SOAP services are based on SOAP 1.1 - which is an informal, unratified proposal originally made by IBM and Microsoft. In summer
2003 the W3C published SOAP 1.2 as a formal recommendation - this clarifies several ambiguities and allows for more flexibility in the SOAP
message structure.
Some of the objectives for SOAP 1.2 have been separately addressed in a set of conventions called the
Web-Service Interoperability basic profile
or just WS-I. It's fair
to say that most of these efforts have been around fixing RPC interoperability - for which the strong typing of RPC must be guaranteed to work across many
procedural platforms. By comparison, interoperability between doc/lit services is relatively straightforward.
The NetKernel SOAP infrastructure transparently supports both SOAP 1.1 and 1.2 - generally it is possible to create services which support both
versions concurrently and transparently. When creating clients to remote services it is left to the developer to determine if the remote service
supports the latest standard and to create the appropriate message type - however based on the message version chosen the client infrastructure will
automatically use the correct transport binding.
WS-*
So far we have covered the core foundations of what should be understood by the term 'SOAP service'.
In addition to the fundamental SOAP standards the industry has embarked
on a proliferation of higher-level application protocols based on SOAP message exchange - this is the so-called WS-* stack. Given the ongoing annealing of
the SOAP foundations we leave it to your judgement to determine the stability and/or utility of these. We have taken the decision that the implementation of
these protocols are higher-order application-level concerns - as they mature the NetKernel SOAP infrastructure can and will be extended to provide application-level
implementations.
References
Preface
Cron
SOAP
