[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
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<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]