[MOBY-dev] [moby] Example of a response message with SOAP envelope

[Javier de la Torre]

Hi Mark,

>
> Because it is illegal to have an <?xml...> tag in the middle of an XML
> document.  (API notes: http://biomoby.open-bio.org/CVS_CONTENT/moby-
> live/Docs/MOBY-S_API/InputMessage.html  and the bottom of
> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-
> S_API/MessageStructure.html)
>

Yes, I know that, but I was wondering why you need to have a full XML  
message as the payload and not rather the normal way of integrating  
your xml inside with a different namespace. You could actually have a  
simple mobyMessage type that defines the mobyContent. And actually  
you go further because, as far as I understood every moby response  
message will have then a mobyData element and then a simple or  
collection element...

(By the way! wouldnt be bad to include at least one full xml  
messages, with the SOAP envelope,  on the documentation)

> we either escape it, or we base64 encode it.  Either way, what you get
> from the SOAP payload is a fully-qualified XML document including the
> XML header such that you can simply pass it to an XML parser verbatim.
> When I wrote that part of the API I was thinking about future
> extensibility into non-SOAP messages, where there would be the need  
> for
> an XML header... it never happened, of course...
>

But this is also possible. In a WSDL file you can define other things  
than SOAP.
For example RESTful services can be described with WSDL files too.
>
> Several years ago, for my own amusement, I constructed a pure-CGI
> version of MOBY, and it worked just fine... so there's no good  
> argument
> for using SOAP (especially since we can't model MOBY messages in XML
> schema, so the WSDL standard isn't particularly useful to us either!)
>

The kind of MOBY services we create can very well described using a  
WSDL file because our outputs will always be the same and therefore  
could be typed with xml schema.
And a way to produce MOBY services in a RESTful way would make it  
very easy to create these kind of MOBY services... In general the  
request services will always accept the same object and parameters  
and produce the same object as a result... and create a service like  
this in any language is really simple! And in some cases you could  
give potential simple-request-service-type moby providers a WSDL file  
that they can implement.


> As such, I don't see that MOBY is any less interoperable with non-MOBY
> web services than they are with each other, with the exception that we
> pass XML rather than raw data.

Well, I see some MOBY services that can be well defined with a WSDL  
file and that someone outside from the MOBY world could be interested  
in using... Someone will maybe want to program an interface to these  
moby services, that are all of the same type (the exact WSDL file),  
and does not want to worry about BIOMOBY at all (apart of using the  
registry for discovery and understanding the little semantics of this  
specific service template).

What I am more interested now is on another topic. If you remeber  
Mark we discussed more than one year ago the need for a paging  
mechanism for our services in BioMOBY. Now that I am implementing  
this I took Martin Singer approach to include this functionality on  
the service: the services always have a two parameters: maxPages and  
startPage that are used for paging...
What is your opinion on this? I think we need an agreement on how  
this work so that future BioMOBY clients could make use of paging. I  
dont know if it would be better to move these parameters somewhere  
inside the MOBY API as they are more operational parameters for lot  
of services than actual parameters only for my specific service.

Is there anybody out there who was implemented paging on any MOBY  
service?

For the time being I am happy with Martin approach and this is the  
way we are doing it.

Best regards.

Javier.