OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Satish,

Good!   But here is the sweet spot that I've also learned the last 
few years - working with OO and Java and XML... blah blah.

It's much easier - when one sees as you say "important work
currently in progress" - to get those folks to subscribe to the
the same modest operandi - so instead of them publishing a 
bunch of complex XML structures with enbedded behaviours
and nuances - that have been tightly coupled - to instead
break those 'switches' open into simple technical notes that are
standalone.  

That way we can relate to it clearly - instead of having to
guess and wonder why "WSDL MEPs" - whatever they
may be - might empign on our spec's - they should not!

This is the power of XML if done right.  De-coupling,
and making it so that any component that can manage the
necessary content within that XML 'switch' can participate
and cooperate.

It makes little sense to nail your foot to the floor - by saying
something like "we're taking advantage of this
really neat feature in WS-foobar-XML that gives us, blah,
blah blah".

Much better to say - as this component here in the enterprise
stack - we have the following controls and interchange 
mechanisms - fully spec'd and clear.   Then any external 
systems that support those will be fully compatible and 
able to effectively interact with a BPEL service component.

We've also seen a lot of worries this week about behaviours
of features of BPEL.  Taking the above approach allows you
to perscribe these behaviours clearly - without getting into
the gnarly stuff of - what if the downstream system does this
or that problem?    This is of course a very well known
and tested engineering method - and as I noted before,
forms the foundation of much of the interoperability today
between OASIS TC spec's.

So - please focus on the functionality we need to provide - 
and let the upstream and downstream work - in, or outside
of OASIS align itself that way - and figure out within their
own spec's how they are going to facilitate the use of the
BPEL - not the other way around, eh?

Thanks, DW.
==============================================

Message text written by "Satish Thatte"
>So that we end up with something that is widely useful the moment we
"ship" it as well as in the longer term via composability.  But there is
important work currently in progress that we *know* we will need to be
compatible with and it is prudent to strive to avoid obstacles to such
compatibility, and in some rare cases, perhaps make changes specifically
anticipating a particular external development (WSDL MEPs come to mind).
 
As usual, principles as easier to state than to put into practice ;-)
 
Satish<



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]