On the work of the task force

After Wednesday's hectic teleconference, I wanted to take a moment to
clarify my perspective, and also to clarify why I have that particular
perspective.

I have two roles in relation to the work and the outcome of the MEPs
task force.  

First, I am one of the designated scapegoats^Weditors of part two of the
WSDL specification (the patterns spec).  From that perspective, I very
much want the work of the task force to be grounded in the patterns
spec.  I would like to see explorations of the patterns definition and
the defined patterns in that spec, leading to criticisms of either.  I
hope that these criticisms will be well-founded enough to make it clear
that, for instance, "without the addition of the magic-word property to
all pattern definitions, it is impossible to build appropriate tools for
room-to-room teleportation.  Note that in the following example WSDL,
although the author wishes to specify xyzzy, nothing happens."

Second, I am a representative of TIBCO Software, which has had strong
representations from customers to provide web-services capabilities in
publish/subscribe systems.  From that perspective, I want to make
certain that the definitions and defined examples of patterns include
the necessary flexibility (and even complexity) to handle pub/sub
idioms.  I've chosen to do this, thus far, primarily through the vehicle
of the multicast solicit/response pattern, but could just as easily have
used a multicast notification pattern (with the triggered faults
ruleset).  The networking paradigms used are significantly different
than those commonly encountered when using HTTP, and this tends to lead
me to emphasize some characteristics that are unsuited (sometimes
radically so) for implementation over HTTP or similar synchronous,
connection-oriented protocols.

Given those perspectives, I very much want to see the work of the group
start from an analysis of the weaknesses of the current patterns (those
that have been designated input/output patterns or IOPs), in order that
we can determine the following:

1) do we need two different definitions of pattern, to correspond with
the two operation elements?  An abstract, and a binding-specific?

2) is the current definition of IOPs adequate for an abstract
definition?
   a) is it adequate for authors of standalone WSDL instances?
   b) is it adequate for developers of WSDL toolkits (for instance,
code-generation tools)
   c) does it provide an adequate vocabulary for choreo languages to
build upon?
   d) does it allow new bindings to reuse existing pattern definitions?

The tension that I see between detailed specification of patterns and
more abstract specifications (such as what we currently have) is that
greater detail means, potentially, more patterns, and less reuse of
patterns, even when they are substantially similar.  I am not at all
certain that we have achieved the proper balance in the current patterns
document (spec part two, that is), and I hope that this task force can
define whether it is adequate or not, and if inadequate, specify what
additions and modifications need to be made.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 30 May 2003 13:29:49 UTC