[MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - The location of queryIDs
Pieter Neerincx
Pieter.Neerincx at wur.nl
Mon Aug 28 14:00:55 UTC 2006
Hi all,
I really like the GetResourceProperty, GetMultipleResourceProperties
and the Destroy methods/services in the new proposal. With the
previous proposal a service provider had to write a service to get
the status, one to get the results and one to delete the results for
each async submit service. The logic to submit a job might be quite
different for different tools, but the logic to get the status of a
submitted job, to get the results or to trash a job can be exactly
the same for many different tools. Therefore I like the idea of
reducing redundancy by implementing only one GetResourceProperty, one
GetMultipleResourceProperties and one Destroy service for all the
async submit services I might want to develop.
There is only one thing that I don't like about the current proposal:
the location of queryID. For our current synchronous services it's an
attribute of the mobyData element. In the current async services
proposal the queryID jumps around the XML taking several identities:
* in <GetResourceProperty>status_queryID01</GetResourceProperty> it
is part of raw text.
* in <lsae:status_queryID01><!-- LSAE block --></
lsae:status_queryID01> it is part of an element name in the lsae
namespace.
(By the way: Should this element really be in the lsae namespace? I
don't think our status_queryIDxx elements are part of the LSAE specs...)
* in <GetResourceProperty>result_queryID01</GetResourceProperty> it
is part of raw text.
* in <moby:result_queryID01><!-- moby:MOBY block --></
moby:result_queryID01> it is part of an element name in the moby
namespace.
* in <moby:mobyData queryID="01"><!-- BioMOBY primary, secondary and
collection articles block --></moby:mobyData> as an attribute.
Although this might work it, I think it is confusing and if I got the
specs correct it also makes life more complicated than necessary.
1.
When I submit an async job, the proposed result contains a
ServiceInvocationID that identifies the complete batch, but the
queryIDs of the individual jobs are not listed in this result. When I
want to retrieve the status, retrieve the results or destroy the jobs
I do need these queryIDs though. This means that as a client I have
to keep track of the queryIDs. I'm not sure how it works for the Java
guys, but as I Perl guy I usually don't have to worry about the
queryIDs. I don't create them myself, they are automatically created
when I submit data to a service using the BioMOBY Perl modules. With
the current proposal I would have parse the XML again to get the
queryIDs, I would have to store them locally and finally merge this
information with the ticket (ServiceInvocationID) I got back from the
service to create a request to get the status or results. It would be
much more convenient if the result from a asynchronous service
invocation would contain both the ServiceInvocationID *AND* the
associated queryIDs. In that case I only have to parse the service
response to create GetResourceProperty requests. Therefore I propose
to supply the queryIDs as wsa:ReferenceParameters just like the
ServiceInvocationID.
2.
WSRF contains an *optional* method to request a resource properties
document. With this method a client can figure out which resource
properties are available and hence what it can request. Although this
method is optional and the current proposal doesn't mention it, I
think it would good to keep the option open to supply such a method.
WSRF does not put any limitations on how a service generates and
provides such a document, so you can generate it dynamically or it
can be a static thing. If we would want to supply such a resource
properties document in the future it would be the easiest if it can
be a static one. However in the current proposal the queryIDs are
part of the resource properties (status_queryIDxx and
result_queryIDxx). This means that the available resource properties
depend on the amount of queries/jobs that were sent to a service and
hence we can not use a static resource properties document. It would
be more convenient if we can strip the queryIDs from the resource
properties and provide them as wsa:ReferenceParameters. In that case
there are only two resource properties (status and result) and we can
describe those in a static resource properties document.
3.
Because of the queryID merged with the "result" resource property,
the result from a asynchronous service contains a bit of redundancy
in the current proposal. The queryID is supplied twice: once in
<moby:result_queryID01> and once in <moby:mobyData queryID="01">.
Furthermore because of the queryID merged to the result resource
property the <moby:MOBY> and <moby:mobyContent> tags have to be
repeated for each queryID. Therefore the results are slightly
different as compared to results from a synchronous service where
<moby:MOBY> and <moby:mobyContent> are present only once. If the
queryIDs are stripped from the result resource property and supplied
as wsa:ReferenceParameters, the results can be more similar the
synchronous service output with only one "result" tag, one
<moby:MOBY> tag and one <moby:mobyContent> tag for one or more
<moby:mobyData> blocks.
Therefore I propose a translocation of BioMOBY queryIDs from the
resource properties to wsa:ReferenceParameters. As far as I
understand, with all the specifications involved this would be legal,
but please correct me if I am wrong. Below I included some examples
of what the XML might look like when the queryIDs are moved to the
SOAP header as wsa:ReferenceParameters. Let me know what you think....
Cheers,
Pi
Response for accepted asynchronous service execution:
<soap:Envelope>
<soap:Header>
. . .
</soap:Header>
<soap:Body>
<servicename_submitResponse>
<wsa:EndpointReference>
<wsa:Address>http://myserver.com/MyService</wsa:Address>
<wsa:ReferenceParameters>
<moby:ServiceInvocation ticketID="123456">
<moby:Job queryID="01"/>
<moby:Job queryID="02"/>
<moby:Job queryID="03"/>
. . .
</moby:ServiceInvocation>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</servicename_submitResponse>
</soap:Body>
</soap:Envelope>
GetResourceProperty request to poll for service execution status:
<soap:Envelope>
<soap:Header>
. . .
<wsa:To wsu:Id="To">http://myserver.com/MyService</wsa:To>
<wsa:Action>http://docs.oasis-open.org/wsrf/rpw-2/
GetResourceProperty/GetResourcePropertyRequest</wsa:Action>
<moby:ServiceInvocation ticketID="123456"
wsa:IsReferenceParameter="true">
<moby:Job queryID="01" wsa:IsReferenceParameter="true" />
<moby:Job queryID="02" wsa:IsReferenceParameter="true" />
<moby:Job queryID="03" wsa:IsReferenceParameter="true" />
. . .
</moby:ServiceInvocation>
. . .
</soap:Header>
<soap:Body>
<GetResourceProperty>moby:ServiceInvocationStatus</
GetResourceProperty>
</soap:Body>
</soap:Envelope>
GetResourceProperty response for polling request:
<soap:Envelope>
<soap:Header>
. . .
<wsa:From wsu:Id="From">
<wsa:Address>http://myserver.com/MyService</wsa:Address>
</wsa:From>
<wsa:Action>http://docs.oasis-open.org/wsrf/rpw-2/
GetResourceProperty/GetResourcePropertyResponse</wsa:Action>
. . .
</soap:Header>
<soap:Body>
<GetResourcePropertyResponse>
<moby:ServiceInvocationStatus ticketID="123456">
<moby:JobStatus queryID="01">
<!-- LSAE Analysis Event Block -->
</moby:JobStatus>
<moby:JobStatus queryID="02">
<!-- LSAE Analysis Event Block -->
</moby:JobStatus>
<moby:JobStatus queryID="03">
<!-- LSAE Analysis Event Block -->
</moby:JobStatus>
</GetResourcePropertyResponse>
</soap:Body>
</soap:Envelope>
GetResourceProperty request for the result:
<soap:Envelope>
<soap:Header>
. . .
<wsa:To wsu:Id="To">http://myserver.com/MyService</wsa:To>
<wsa:Action>http://docs.oasis-open.org/wsrf/rpw-2/
GetResourceProperty/GetResourcePropertyRequest</wsa:Action>
<moby:ServiceInvocation ticketID="123456"
wsa:IsReferenceParameter="true">
<moby:Job queryID="01" wsa:IsReferenceParameter="true" />
<moby:Job queryID="02" wsa:IsReferenceParameter="true" />
<moby:Job queryID="03" wsa:IsReferenceParameter="true" />
. . .
</moby:ServiceInvocation>
. . .
</soap:Header>
<soap:Body>
<GetResourceProperty>moby:ServiceInvocationResult</
GetResourceProperty>
</soap:Body>
</soap:Envelope>
GetResourceProperty response for requesting results:
<soap:Envelope>
<soap:Header>
. . .
<wsa:From wsu:Id="From">
<wsa:Address>http://myserver.com/MyService</wsa:Address>
</wsa:From>
<wsa:Action>http://docs.oasis-open.org/wsrf/rpw-2/
GetResourceProperty/GetResourcePropertyResponse</wsa:Action>
. . .
</soap:Header>
<soap:Body>
<GetResourcePropertyResponse>
<moby:ServiceInvocationResult ticketID="123456">
<moby:MOBY xmlns:moby='http: / /www.biomoby.org/moby-s'>
<moby:mobyContent>
<moby:mobyData queryID="01">
<!--- Standard BioMOBY XML for output -->
</moby:mobyData>
<moby:mobyData queryID="02">
<!--- Standard BioMOBY XML for output -->
</moby:mobyData>
. . .
</moby:mobyContent>
</moby:MOBY>
</moby:ServiceInvocationResult>
</GetResourcePropertyResponse>
</soap:Body>
</soap:Envelope>
Request for destroying the resource:
<soap:Envelope>
<soap:Header>
. . .
<wsa:To wsu:Id="To">http://myserver.com/MyService</wsa:To>
<moby:ServiceInvocation ticketID="123456"
wsa:IsReferenceParameter="true">
<wsa:Action>http://docs.oasis-open.org/wsrf/rlw-2/
ImmediateResourceTermination/DestroyRequest</wsa:Action>
. . .
</soap:Header>
<soap:Body>
<Destroy />
</soap:Body>
</soap:Envelope>
Response for destroying the resource:
<soap:Envelope>
<soap:Header>
. . .
<wsa:From wsu:Id="From">
<wsa:Address>http://myserver.com/MyService</wsa:Address>
</wsa:From>
<wsa:Action>http://docs.oasis-open.org/wsrf/rlw-2/
ImmediateResourceTermination/DestroyResponse</wsa:Action>
. . .
</soap:Header>
<soap:Body>
<DestroyResponse />
</soap:Body>
</soap:Envelope>
More information about the MOBY-dev
mailing list