[MOBY-dev] WSRF solution to the asynchronous services problem

[Mark Wilkinson]

Hi all,

Well, I seem to have mis-understood and mis-represented WSRF in my  
previous messages.  It isn't the utopea that I thought it was the first  
time I read the spec, but that was my mistake - I was reading it with the  
assumption that it would be clever and elegant.

There are two near-identical specifications in OASIS for dealing with  
stateful services:  WSRF and ASAP.  Neither of them have yet been accepted  
as "standards", so they are still prone to change.  Here's a brief  
overview of the two spec's:

WSRF:  Web Services Resource Framework
	- WS Resources are uniquely identifiable entities
	- One WS Resource is created per Web Service invocation (**NB**)
	- WS Resources have Property Documents (defined by an XML schema)
	- Property Documents contain Properties (duh!) describing the state of  
that WS Resource
	- Using WSRF-defined, predictable API calls it is possible to obtain the  
full Property Document or named parts of the Property Document, and/or set  
the property values
		- the Web Service must implement these API call(s) as method on the  
service
	- a variety of Faults are defined to deal with cases e.g. where the WS  
Resource or property named in the request is unknown
	- [[speculation]] cleanup could be achieved by having one of the  
properties, e.g. "discard", be settable by the client through the  
appropriate API call

ASAP:  Asynchronous Service Access Protocol
	- Specifically for Asynchronous services
	- Server must implement a "Factory" interface
	- "Factory" generates "Instances" of a service upon Service invocation
	- Instances have a variety of API calls to manipulate their parameters  
and check their status, including their current state, the input data, and  
the output data.
	- Instances generate event notifications to the client (**NB**) to tell  
it that it is finished (active notification, NOT passive notification!!),  
as well as when its state has changed, etc.
	- clean-up happens through a server-side, timed event, where one of the  
properties of an Instance is the duration for which it will be held, after  
which it is no longer accessible.
	- it isn't clear from the spec which parts are required and which are  
optional... unfortunately, there are a LOT of API methods described in the  
spec, so this is a bit worrisome as they would have to be implemented for  
every asynch service.


My instincts tell me that ASAP is too complex for our needs, and it would  
be better to work with the more generic of the two specifications anyway  
just in case we need to use it for something other than asynchronicity  
(e.g. message chunking!)

The problems I see with WSRF are the following:
	a)  It doesn't (natively) handle batching the way we do in MOBY  
Collections, so anything we come up with is going to be a bit of a hack in  
that regard.
	b)  It requires that service providers implement one or more of the  
defined WSRF API methods, and this means that there will be messages  
passed between MOBY Client and MOBY Service that are not MOBY messages.


I'm going to try to put together a strawman proposal for how we might  
implement MOBY Services asynchronously using WSRF, but it will take me a  
little while because it isn't entirely trivial nor intuitive to do so...   
We can then compare it to whatever the RFC proposal is and decide if we  
gain any significant advantage from following an existing "standard", or  
if our own proposal is sufficient.

M





-- 
--
Mark Wilkinson
Assistant Professor, Dept. Medical Genetics
University of British Columbia
PI Bioinformatics
iCAPTURE Centre, St. Paul's Hospital