**Considerations for using SOAP as the basis for SSSRMAP v4**

The Scalable Systems Software Resource Management and Accounting
Protocol version 3 is an XML request-response message format over HTTP.
In many respects, the SSSRMAP wire protocol closely resembles the SOAP
Protocol with an HTTP binding. This is justly because SOAP was among the
many protocols studied during the design of the SSSRMAP protocols. Many
of SOAP's desirable qualities were adopted in the SSSRMAP specification.
However, it was not adopted outright as the research appeared to
indicate that existing SOAP specifications and implementations would not
provide the level of scalability required by the Scalable Systems
Software project.

Specifically, the two largest problems were: (1) that existing SOAP
implementations added significant overhead and latency to the
communications, and (2) SOAP did not provide adequate support for large
messages.

First problem:

The SOAP specification is complex and supports many features not
required by SSS components that add overhead to the communications.

\[[Investigating the Limits of SOAP Performance for Scientific
Computing](http://www.extreme.indiana.edu/xgws/papers/soap-hpdc2002/soap-hpdc2002.pdf)\]\[[Latency
Performance of SOAP
Implementations](http://www.caip.rutgers.edu/TASSL/Papers/p2p-p2pws02-soap.pdf)\]\[[Pushing
the SOAP Envelope With Web Services for Scientific
Computing](http://www.cs.fsu.edu/~engelen/icws03.pdf)\]\[[SOAP's too
slow for capital
markets](http://www.australianit.com.au/wireless/ story/0,8256,1-6206060,00.html)\]

Second problem:

It was determined early on that as these standards were being designed
for the largest scale systems over the coming years (including the
possibility of Grid-level scheduling and accounting) that the target
components may well be working with data sets that would be larger than
the available memory on the servers. This would be particularly true for
monitoring, accounting and data-storing services. One of SOAP's
principle weaknesses is that it does not support streaming or chunking
of large messages very well. In fact, boxcarring or batching of messages
was intentionally excluded from the design. SOAP (over HTTP) only
supports a single response for a request. Multiple synchronous or
asynchronous responses are not well supported over the SOAP HTTP binding
(or any other binding commonly available in SOAP implementations that I
am aware of). Existing SOAP implementations usually read messages
entirely into memory before they are processed and this poses a major
resource problem for large messages.

\[[Is soap tough enough for large data
loads?](http://www.xmleverywhere.com/bb/viewtopic.php?p=63)\]

Many enterprise IT shops use custom XML solutions over HTTP instead of
using SOAP. They do this because it is easy to do so, because it often
affords them better performance and because the solutions can be readily
adapted to their specialized needs. This was the direction we chose to
go for similar reasons.

\[[Why Use SOAP? Choosing Between SOAP and Application-Specific XML for
Your Web
Services](http://www.artima.com/webservices/articles/whysoap.html)\]

By implementing communication protocol logic that focus exclusively on
the needs for the SSS components and not supporting the diverse
capabilities within SOAP (including the namespace processing and
validation), SSSRMAP components can achieve reasonably good
communication performance. By modifying the HTTP framing to use HTTP 1.1
Chunking, large message support was enabled for SSS components.

There could be some significant advantages for using SOAP. The SSSRMAP
communication standard might well have a greater chance for widespread
adoption by industry were it to use an industry tried-and-proven
communication standard. Additionally, SOAP communication modules already
exist for the major programming languages and architectures, so it would
be easier for a new component implementer to use the SSSRMAP protocol.
That being said, coding for the existing SSS protocol is not hard and
does not take many lines of code to directly support the SSSRMAP
communication protocol if you exclude the authentication and encryption
routines.

SSSRMAP protocol v3 currently satisfies our needs. There is presently no
large motivation for moving to a protocol that uses SOAP. If it was
determined that the SSS components should be enhanced to use another
version of SSSRMAP based on the SOAP specification, the following
changes would be necessary:

1\) Performance

Not much can be done to increase the performance of SOAP. It may be that
some implementations of SOAP would be fast enough for our scalability
requirements. This has not been adequately tested.

2\) Large messages

a\) We could give up on large message support

b\) We could attach all data as DIME attachments

c\) We could use SOAP over an HTTP 1.1 binding that uses chunking

Although large messages could be supported via DIME attachments (which
supports chunking), this does not seem to be a very desirable solution
because we would rather not handle all of our data via attachments (our
data is currently encapsulated in the response body and we would not
like to handle large data responses differently than small data
responses). Although the SOAP specification appears to allow for an HTTP
binding that supports chunking, the existing SOAP modules and
implementations use an HTTP binding that does not support chunking.

3\) Other protocol differences

Besides that, most of the changes are cosmetic. Both SSSRMAP and SOAP
over HTTP sport a very similar HTTP transport layer (SSSRMAP uses
Chunking while SOAP uses Content-Length to specify the payload size).
Both have an Envelope element at the top layer, although SSSRMAP
presently does not require namespaces as SOAP does. SOAP has an optional
Header element inside the Envelope element that may contain
authentication information while SSSRMAP has an optional Signature
element directly inside the Envelope element that contains the
authentication information. Both authentication mechanisms are based on
XML Digital Signatures (SSSRMAP more loosely). Both SSSRMAP and SOAP
have a Body element inside the Envelope element. In SSSRMAP, The Body
element and the Signature element may be replaced by an EncryptedData
element if the content has been encrypted. SOAP Faults are included in
the Header element while all SSSRMAP failure responses are included in
the Body element (in the Response) and conform to a 3-digit error code
(similar to ftp or http), a status token and a message. SOAP Fault codes
are dot-delimited hierarchically qualified names. The contents of the
Body as defined by the SSSRMAP Message Format would probably not have to
change since just about any XML is allowed as a payload in SOAP. It is
possible that a SOAP RPC mechanism might be better supported by making
simple alterations to the message format. Namespace qualification may
need to be added to the top-level elements in the Body.

-   SSSRMAP would have to add in the SOAP namespace qualifiers for the
    soap-envelope and soap-encoding namespaces.

-   The SSSRMAP Signature would have to be placed in the SOAP Header and
    would have to change to conform to the SOAP Security Extensions and
    XML Digital Signature.

-   SOAP Encryption is going to take some work and more investigation to
    determine if there even is a standard here. It appears the only
    direction is to somehow use the emerging XML-ENCRYPTION standard.

-   SSSRMAP error codes which indicate failure of the connection itself
    or security will have to be moved to the Header as a SOAP Fault
    Code. Business logic errors can still be kept within the Response
    Body.