RE: XTech 2000 XML protocol BOF notes

Eric Prud'hommeaux wrote:
> 
> On Mon, Mar 20, 2000 at 06:03:54PM -0800, Larry Masinter wrote:
> > Given the larger problem statements in the BOF, I think it is worthwhile
> > for people to look at SWAP (Simple Workflow something Protocol) and also
the
> > WfMC spec (www.wfmc.org) as a source of additional design insights and
> > problem definition.
> 
> FoRK has an EDI thread that touches on SWAP and WfMC. Go to
> http://www.xent.com/FoRK-archive/may98/ and look for "EDI and XML".

   Great pointer, thanks. I should not though, that much has happened since
that time. SWAP is now called Wf-XML, and is a fully transport and platform
independent protocol (because it's purely XML). A copy of the Beta version
of the spec can be downloaded from http://www.wfmc.org, but we're nearing
the 1.0 release and some things are definitely changing.

   The initial version of this spec has been dramatically de-scoped so as to
facilitate interoperability, there will be only 4 basic operations
specified. Subsequent versions will rapidly build on functionality.

   While this spec was created with workflow processes in mind, the intent
was always that it should be equally applicable to any type of remote
process interaction (by changing the names to protect the innocent). I've
been watching this (xml-dist-app) group's activity in hopes of bringing our
worlds to an appropriate meeting point as things develop. I'll encourage
others from the WfMC to do the same.

   While not explicitly intended to implement EDI transactions, an
appropriately specified asynhchronous binding of Wf-XML could certainly do
the trick. In fact one of our members has been working on doing just that
and their feedback is being considered for inclusion somewhere in the spec.

> If we start modeling XML protocols as a series of layers
> [http://www.w3.org/2000/03/15-XML-protocol-Viewpoints.html#pro
> posedRequirements],
> we can take a diverse set of requirements, categorize them, and parcel
> them out to smaller groups. This will allow greater parallel
> development and allow more rapid development of a core which would
> unify most of the functionality of XML-RPC [http://www.xmlrpc.com/]
> and SOAP [http://www.msdn.microsoft.com/xml/general/soapspec-v1.asp].

   The approach taken by the WfMC so far has been to address only the lowest
layer of your proposed series - message serialization and extensibility. All
other layers are left to a given (transport) binding, or implementation.
This is intended to allow for maximum implementation flexibility. For
version 1.0, many of these aspects will need to be specified on a
case-by-case basis in what will be called an "interoperability contract".

> I am now looking for a way to express the categories and inter-layer
> dependencies in a clear way. For example, from the picture in the
> Viewpoints document:
> 
> Authentication (digital signatures)
>   stacks on: core
>    provides: some auth API
> 
> Procedure Invocation
>   stacks on: core
>    provides: RPC
> 
> Transaction Management
>   stacks on: RPC
>    provides: some ACID API
> 
> Object Interface
>   stacks on: RPC
>    provides: object API
> 
> Object Persistence
>   stacks on: object API
>    provides: object API
>    comments: may need Transaction Management and 
>              distributed garbage collection
> 
> What is the relationship between worlflow layers? What are their
> dependencies? Anybody? Bueler?

   Hmm, workflow layers. As noted above, (at least for Wf-XML) only the
lowest layer is considered valuable to interoperability. All issues
regarding security (identification & authorization, encryption, signatures,
etc.), transport (session management, message identification, batch
processing, failure/retry, etc.), object models, etc. are considered to be
implementation specific and will be addressed in appropriate binding
specifications.

   The one category that we consider 'core' from your model is procedure
invocation (and control), which is really the heart of the matter, no? Now,
of course any information over and above these layers is clearly application
specific, and will need to be modeled/handled at the application level.

   Sorry this was long, but I hope it was helpful.

Michael A. Rossi
mailto:mrossi@csc.com
856-983-4400 x4911

Received on Thursday, 23 March 2000 17:47:11 UTC