MOBY-S Message Structure

After retrieving a service description (currently in the form of a simplistic, but legitimate, WSDL document) from MOBY Central, client programs will subsequently communicate directly with the service provider, first by sending a request, in the form of an input message and then, if all goes well, by receiving an output message. The communication takes the form of a very simplistic SOAP RPC call: the name of the remote procedure call is the same as that when it was registered in MOBY Central.

The URI (uniform resource identifier) looks like a URL (uniform resource locator), but is subtly different. Where a URL is the address of a document on the Internet, a URI is an abstract identifier which allows the service to be uniquely identified.

At this time, the URI for this procedure call is always, as in:

This is regardless of the URI for the service provider! This is useful because the same service might be available from several providers. If they all use the same URI, then a computer (or human) can infer that they are equivalent, and swap one for the other, based on availability, or other criteria.

(NOTE: This becomes the SOAP Action in a SOAP message and the WSDL document describing it; fill in appropriately for your libraries, as it is different for Perl SOAP::Lite, Apache::Axis, and so on)

For example, the service registered with the following XML would be called as a SOAP-RPC call to the retrieveSequence procedure provided by the script at the URI

      takes a genbank GI number and retrieves the genbank sequence]]>
         <Simple articleName="">
         <Simple articleName="">
             <Parameter articleName='cutoff'>

About Input and Output SOAP messages

Note that the SOAP payload for both input and output to a service (described below) is a fully qualified XML document. To assist XML parsers in rapidly parsing long SOAP messages, it is often desirable to base64 encode this payload prior to sending out the SOAP request/response. This, however, is not compatible with all character sets (depending on the locale settings of the recipient machine). As such, all service invocations and responses are allowed to send either base64 encoded payloads, or simple XML strings. Clients and services must expect either of these.

Specification of