re: Managing interdependencies / was: RE: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC face to face

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Satish,

Thanks for the shared thoughts here.  Yes - we've been grappling
with this same disjointed process for a couple of years now.

I believe we're seeing more agreement on roles, and alignment
of purpose than previously.   Now the W3C has realized they have
to focus their bandwidth on the spec's that count for them, and let
the ebusiness side be handled by groups that are better equipped
to facilitate that - while having input and feedback across the 
process - life in XML land is becoming more clear.

We've also learned a tremendous amount starting from the ebXML
initiative - on just what is needed to be successful and what 
can be achieved collaboratively.

Then there's the simple fact of life that alot of the players are the
same folks, (or are sat in adjacent cube's), on these parallel teams.

OK - so far so good.   Now what I've also learned is that "we have and
will continue to have a deep dependence on...." is probably a "note to
self" that long term that is less than healthy.  What we've definately 
learned is that making technology into a component - that can 
co-exist with / via neutral deployment models - is the win-win-win.

Architecting things so that they can be plugged into by 'whatever' is
the new way forward.  So - especially in OASIS efforts we've learned
that while you do need at times to nail to a specific W3C technology
mast - i.e. XPath V1.0, or XML V1.1, when you do this - aim for the 
lowest denominator - to give the widest buy-in - and also aim 
for something that is very stable.  Self-reliance is better than hoping
on W3C mights-and-maybes.  And this then becomes a design
philosophy - making open components - that fit within the OASIS
family - but can be utilized without tight-coupling.

Which comes back to the "What is BPEL?" document - and being
able to clearly articulate the structure and approach, the boundaries,
and particularly the exclusions.

So what I would be looking for in a successful OASIS BPEL - would
be a component that can be utilized by a broad landscape of 
architectures and XML technologies - and therefore something 
that has very clearly defined interfaces - in simple XML as needed.

To achieve that requires that we are very focused in accepting 
features and capabilities.  Simple and restricted - in your first release -

will be more successful than trying to pack the spec' full of clever and
complex behaviours that will undoubtedly come back to haunt you.

That's not to say your spec' has to be brain-dead - but clearly 
differentiating between what is functional and simple to achieve
in V1.0, while putting aside and tabling options for a V2.0 - makes
IMHO - the best strategy.  

But first of all - understanding what the criteria for including items
or excluding items - from V1.0 - based on business criteria - not
technical 'this would be neat if' - is a painful but necessary step.

It will also make Diane's and John's tasks much easier - the spec'
much easier to read, and meetings alot shorter!  ; -)

Cheers, DW.
===========================================================
Message text written by "Satish Thatte"
>A summary of usage and goals along these lines is something we should
definitely arrive at collectively.  I agree with much of what you have
written.  The one thing I would immediately want to broaden is your
emphasis on composition and interoperation with primarily OASIS work.

For instance we have and will continue to have a deep dependence on
WSDL, which is being done in W3C.  As you know, the current spec has
relationships to other work such as WS-Transactions and WS-Addressing
that is not yet submitted to any standards body.  At this stage of the
evolution of the web services architecture we will be working to find
synergy with a number of moving targets (WSDL 1.2, XPATH 2.0, ..) not
all of which will be in OASIS or even in a formal standards setting.  We
need to find a way to state how we address this need via separation of
concerns to promote composability wherever possible and judicious import
and export of requirements where necessary.

Satish<