[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
Steve, Perhaps it can help to point out that I'm currently working on something that allows you to design a BPSS, and then hit a button - and it generates a working BPEL script that can be run on a BPEL engine that executes the collaboration according to ebXML rules and in an ebXML way. Of course that way you need to know nothing about BPEL, just what your business needs are - and how to complete a BPSS and a CPA. This seems to me to be the way to go for SMEs - no coding needed. There's still some missing bits - like the fine detail of a BPEL / ebMS interface - but that's just engineering now that the ebMS is also supporting WSDL - since the BPEL engine should not care about the messaging layer delivery anyway. Cheers, DW. ============================================================================== Quoting Steve Capell <steve.capell@redwahoo.com>: > Dear all, > > Thank you for all your responses. Everyone has a good point, not the > least of which is that I should go away and document a use case.... > > Just to clarify a few things: > > * Yes, I am simplifying things a bit - reason is we need to deploy > something now that works for small & medium businesses and we can afford > to simplify things. Part of the reasons we can simplify things is that > we are in a position to define the "public process" for/with industry > sectors and also to build corresponding "private" process components > (pre-packaged) for specific back-office applications. The idea is that > we can target simple collaborative processes and common back-office > applications. > * I agree that basic WS cannot address QOS for B2B collaborations. > However I see no reason why the extended stack inclusing things like > WS-RM, WS-Security, WS-Transaction, etc - governed by a WS-Policy > assertion cannot achieve the required result. For those familiar with > ebXML, I (perhaps incorrectly) see SOAP+WSRM+WS-Security = ebXML MSH and > that WSDL+WS-Policy = CPP and (I had hoped) "Abstract" BPEL = BPSS. > Lets not get into a discussion about whether things like WS-Policy are > genuinely part of the WS stack (since it is still a vendor > specification)....Also I do realise that WS-Policy itself is just a > syntax to express policies and that some specific semantics (assertions) > would need to be developed to address this need. > * BPEL is certainly an "execution" language first and maybe needs > to stay that way. The discussion is really around the question of > whether or not WS-BPEL is going to "evolve" into another specification > that also addresses the B2B collaboration space. Frankly I'm not too > worried whether it does or not. If not then we'll adopt some other > suitable protocol for that part of the stack. Perhaps as many have > suggested it is better to leave BPEL for what it is designed to do - the > executable "private process" part of our architecture. > * For the short term, the "private process" (essentially a bpel > and associated xsd, xslt, xforms running on compliant runtime engine) > will be hand crafted to bridge the gap between a back-office application > and a public process. I had envisioned a time when I could import a > public collaboration definition and backoffice API into a visual design > time tool and efficiently create the bpel, xslt, xforms etc to bridge > the gap. I have not thought enough about how realistic that is. > Nevertheless, whether hand crafted or created with a nifty tool, our > intention is to try to demonstrate reusability of the private process > schema accross a community that shares the same back-office and "public > process". Even in a small country like Australia, there are communities > like that with member numbers in the 10,000's. Re-use of private > process content can obviously deliver enormous potential savings. > > For those that might be interested to understand what we are trying to > do here in Australia, please take a look at www.bizdex.com.au. Comments > welcome. > > Regards, > > > Steve Capell > RedWahoo > Sydney, Australia > Tel : +61 410 437854 > This email message and any accompanying attachments may contain > information that is confidential and is subject to legal privilege. If > you are not the intended recipient, do not read, use, disseminate, > distribute or copy this message or attachments. If you have received > this message in error, please notify the sender immediately, and delete > this message. Any views expressed in this message are those of the > individual sender, except where the sender expressly, and with > authority, states them to be the views of Red Wahoo Pty. Ltd. > > Before opening any attachments, please check them for viruses and > defects. We do not accept any liability for loss or damage which may > arise from your receipt of this e-mail. > > -----Original Message----- > From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] > Sent: Friday, 24 October 2003 7:33 AM > To: 'Steve Capell'; 'Satish Thatte'; 'Furniss, Peter'; ygoland@bea.com; > 'John Evdemon'; wsbpel@lists.oasis-open.org; 'Dave Welsh'; 'Monica J. > Martin' > Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > > Steve: > > I don't know if I am able/allowed to publish to this list (I just joined > :-). IMHO, you will never be able to have a continuum between public and > private choreography, let alone abstract and executable orchestration. > > Since you mention BPSS, I feel that I might throw some comments about > it. Ancient specifications (based on internet times) like BPSS have long > established that most B2B interactions require a certain quality of > service that only certain protocols can provide. Traditional QOS > protocols, part of the ws-stack are helpless with that matter. > > For instance BPSS offer at least two levels of protocols: what I call a > "business reliable messaging" protocol and a "business transaction > protocol" (Bob feel free to jump in to keep me honest on what I say). > These protocols are essentials to carry some business activities (not > all I grant you, something like the travel agent example does not need > that). Assuming that the private chorerography or the deep orchestration > layer will implement these protocols is not the best use of your > choreography or orchestration resources. These protocols are far better > handled by the "Business Service Interface" concept described in the > ebXML architecture and the ebXML BPSS specification. I can only speak > for myself, but more protocols are needed at the B2B level, I am > assuming that the ebBP group will continue enriching these protocols > that cannot be handled by your private choreography, before it touches > your orchestration layer. > > Hope that helps. > > Jean-Jacques > tel: 425-649-6584 > Cell: 508-333-7634 > > > -----Original Message----- > From: Steve Capell [mailto:steve.capell@redwahoo.com] > Sent: Wednesday, October 22, 2003 11:15 PM > To: 'Satish Thatte'; 'Furniss, Peter'; ygoland@bea.com; 'John Evdemon'; > wsbpel@lists.oasis-open.org; 'Dave Welsh' > Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > Satish > > Are we confusing a "Business Domain" (eg supply chain) with a business > process (eg "purchasing")? In business process modelling (such as the > UN/CEFACT BCF methodology) the collaborative "business process" is > typically quite granular (eg an order and order response). The process > is a small part of a business domain such as supply chain. To describe > the entire domain with an abstract bpel is a huge challenge but to > describe a fairly granual collaboration strikes me as quite do-able and > quite useful. > > >From my perspective, I would like to be able to completely define a > "public process" using machine readable WS schema in a similar way to > ebXML specifications. For example, to describe a simple order / order > response process such as resettaNet PIP3A4 using WS schema I would need: > > 1 An abstract ws-bpel defining the simple collaboration > 2 A ws-policy assertion schema definin the QOS attributes of each > activity (non-repudiation, time to acknowledge, etc) > 3 Two XSD schema (one for each message) representing the order and > > orderResponse messages defined by the model. > 4 Two wsdls (one for each party) with references to the xsd schema > > (import), ws-policy (policyRef extension), and ws-bpel role > (partnerLinkType extension). > > This complete machine readable "public process" can then be used to > configure testing tools (for certification or compliant application, > design time tools (for creating "private process" orchestrations, and > runtime tools (for managing compliance to public process QOS > requirements). > > > On behalf of the Australian government I am certainly hoping that > ws-bpel will provide the capability to describe at least simple > collabroative processes - otherwise we will have to fall back on things > like ebXML BPSS - but then we'd lose the potential to glue together the > "public collabroation" and "private orchestration" in one set of > specifications & tools. > > Regards, > > Steve Capell > RedWahoo > Sydney, Australia > Tel : +61 410 437854 > This email message and any accompanying attachments may contain > information that is confidential and is subject to legal privilege. If > you are not the intended recipient, do not read, use, disseminate, > distribute or copy this message or attachments. If you have received > this message in error, please notify the sender immediately, and delete > this message. Any views expressed in this message are those of the > individual sender, except where the sender expressly, and with > authority, states them to be the views of Red Wahoo Pty. Ltd. Before > opening any attachments, please check them for viruses and defects. We > do not accept any liability for loss or damage which may arise from your > receipt of this e-mail. > > > > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Thursday, 23 October 2003 11:36 AM > To: Furniss, Peter; ygoland@bea.com; John Evdemon; > wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > As I argued during my presentation at the first F2F, the idea that a > neutral description of multi-party interaction is essential for business > protocol definition is erroneous, and worse, too restrictive. In > particular protocols using full duplex communication are almost > impossible to describe without separately describing the external > behavior of each party, because the number of states corresponding to > races becomes unmanageable and incomprehensible. Think of a supply > chain protocol where an order may be canceled at arbitrary points. Most > neutral protocol descriptions tend to be reduced to finite state > machines that are also very poor at describing data dependent aspects, > error recovery protocols, etc. I expect this is what Peter is referring > to when he speaks of "heading towards somehting much like on abstract > bpel". > > I therefore consider Yaron's objection to be groundless and advocate > keeping the paragraph as is. > > -----Original Message----- > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > Sent: Wednesday, October 22, 2003 4:42 PM > To: ygoland@bea.com; John Evdemon; wsbpel@lists.oasis-open.org > Subject: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > Some of Yaron's comments on the FAQ (most of which I agree with) seem to > relate to the power of abstract BPEL > > paragraph from the proposed FAQ: > > <quote> > The Business Process Execution Language is a XML-based language for > formally describing interoperable business processes and business > interaction protocols. It defines how web services are connected > together and in what sequence in order to accomplish a particular task > > </quote> > > to which Yaron comments : > > <quote> > BPEL only provides a description of the behavior of a single player in a > business process protocol. Since protocols require, by definition, more > than one player BPEL is by definition unable to completely describe a > business process protocol or to specify how different processes interact > beyond describing the behavior of a single participant. Therefore I > think this paragraph should be struck. > > </quote> > > which was very much my view until I had a conversation with Tony Andrews > and got a better understanding of his presentation from the first > face-to-face ( > http://www.oasis-open.org/archives/wsbpel/200305/msg00172.html). It > seemed some things I had thought would be necessary, and which I hadn't > seen stated, and so assumed were not in view, were definitely > > intended/expected: > > - there can be multiple abstract definitions for a single > executable, each specifying the dynamic behaviour of one (or set of > > related) interfaces, with the other interfaces handled by opaque > assignment; the choice of how many of these there are, their level of > opacity and the interfaces covered is a design/viewpoint question > > - there can be (and need to be for the "global" picture) > abstract bpel definitions for processes that are never going to be in > bpel - not least because some are "leaf" processes in the web-service > world, and do real work on databases or visible effect on GUIs etc. > rather than just defer to yet another web-service, which is all > executable bpel can do > > - there can be multiple executable processes matching a single > abstract definition - this is just an interface:implementation > relationship > > (Apologies to Tony if I've mis-represented him). They obviously have > some exciting implications for what bpel tools in general might do > (especially the middle one - how on earth do you show compatibility > between abstract bpel and a legacy app written in cobol with a > web-service front end) > > But these don't seem to be in the spec. (last one might be). Should it > be left to interpretation (and, no doubt, some books) ? > > There's also the possibility of stating the rules (guidelines ? > constraints ?) involved in the two abstract bpel definitions that make > up either side of a business protocol. > > > (I should possibly mention that I was for a long time very sceptical > about whether bpel or things like it was the way to do this, and thought > it could be done with a simpler, less procedural approach. but gradually > I found my vague "ideal" was getting necessarily more complex and > needing more functionality - in fact heading towards somehting much like > on abstract bpel) > > > Peter (speaking for himself) > > > > > -----Original Message----- > > From: Yaron Goland [mailto:ygoland@bea.com] > > Sent: 22 October 2003 23:09 > > To: 'John Evdemon'; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] FAQ > > > > > > Some comments > > > > > -----Original Message----- > > > From: John Evdemon [mailto:jevdemon@microsoft.com] > > > Sent: Tuesday, October 21, 2003 12:44 PM > > > To: wsbpel@lists.oasis-open.org > > > Subject: [wsbpel] FAQ > > > > > > > > > <<WSBPEL DRAFT FAQ.txt>> Hello all, > > > > > > A while ago I asked for feedback on a TC FAQ. I have attached a > > > draft that incorporates some initial feedback from Monica and Ugo. > > > Please respond with any additional questions or concerns. > > > > > > If there is no feedback by 10/28 I will assume the TC is happy with > > > the current version (attached) and submit it to OASIS. > > > > > > Thanks! > > > > > > John > > > > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > oup.php. > > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > > oup.php. > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr > oup.php. > > http://drrw.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]