Re: data parameter elements

Hi James,
  My feeling is that, yes, this is a way to accomplish this,
but I would classify your suggestion in the category of "Wwhy don't
we just use {IPP, XML/RPC, HTTP, WebDAV...}?  There's a tradeoff
at work here.  SWAP needs to define a common set of goals that
almost all workflow tool vendors need from theirs and other 
systems.   Communicating across the network you have any
number of transport mechanisms.  the Goal of SWAP is to provide
richer transport and simpler notification than existing 
network interfaces that can be standardized.   One one end of
the spectrum, you can simply use HTTP(/1.1) and embed all
or your smarts into an XML form.  This is similar to the WfMC's
Mime bindings.  While the transport is simple, the overhead
of computing smarts on the receiving end to accomplish a task
requires a) a lot of agreements and understanding between the
two sites, and b) a fairly complex component to interpret
the swap and data calls.  On the other end of the spectrum
is the full WfMC interface specs (or the OMG's Joint Flow).
It's a very rich, powerful, and robust set of interfaces, 
but requires even more of a computing overhead on the
receiving and sending end.  The SWAP effort appears to be taking
a little different approach.  WebDAV has shown the benefits
to having a little more powerful set of transport primitives.
SWAP wants to incrementally add just a few more to better
support cooperation and control.  By having a little more
robuts transport mechanism, you can have a much simpler
method for cross-platform workflow control, invocation, management, 
monitoring, etc.  The benefit being that the required infrastructure
on the sending and receiving side can be simplified when
comparing the requirements of supporting other workflow 
interfaces and standards across the network.
 

Take your example and write out the complete call.
I am assuming your are invoking a remote workflow service.
Write out, what does the  URI look like, how are the parameters
and data encoded, is the message synchronous or asynchronous,
what are the side-effects and results, what are the message
and error codes, what are the return values, how do you 
use these values to accomplish the other goals?  The
devil's always in the details.

Anywys, these are just my opinions and understanding.

Greg


 > hello,
 > 
 > i'm looking at the 9807 version of SWAP and ask why the data element in
 > messages is encoded as a list of name value pairs. why not just specify
 > 
 > <!ELEMENT swap (interfaces, ..., data?) >
 > <!ELEMENT data ANY >
 > 
 > and leave it to the respective processes to decide whether a list of pairs
 > suits them or whether a more structured encoding is better?
 >

Received on Wednesday, 14 October 1998 12:53:43 UTC