MOBY-S Message Structure
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 http://biomoby.org, as in:
http://biomoby.org/#your_procedure_call_name
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 http://serviceprovider.org/getService.pl
script at the URI http://biomoby.org/#retrieveSequence
.
<registerService> <Category>moby</Category> <serviceName>retrieveSequence</serviceName> <serviceType>Retrieve</serviceType> <authURI>services.serviceprovider.org</authURI> <URL>http://serviceprovider.org/getService.pl</URL>; <contactEmail>markw@illuminae.com</contactEmail> <authoritativeService>0</authoritativeService> <Description><![CDATA[ takes a genbank GI number and retrieves the genbank sequence]]> </Description> <Input> <Simple articleName=""> <objectType>Object</objectType> <Namespace>Genbank/gi</Namespace> </Simple> </Input> <Output> <Simple articleName=""> <objectType>Sequence</objectType> <Namespace>Genbank/gi</Namespace> </Simple> </Output> <secondaryArticles> <Parameter articleName='cutoff'> <datatype>Integer</datatype> <min>1</min> <max>10</max> <default>5</default> </Parameter> </secondaryArticles> </registerService>
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