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

["Satish Thatte" <satisht@microsoft.com>]

David,
 
I agree completely on the principles of
 
(1)  stay focused -- don't boil the ocean
(2)  take a hard dependency only on stable widely deployed technologies
 
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
 
 

	-----Original Message----- 
	From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com] 
	Sent: Mon 5/26/2003 1:24 PM 
	To: Satish Thatte 
	Cc: Diane Jordan; wsbpel@lists.oasis-open.org 
	Subject: re: Managing interdependencies / was: RE: [wsbpel] Proposed agenda for May 28-29 WS BPEL TC face to face
	
	

	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<