[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] RE: BusinessActivityBehavior diagram
Martin, David: On the BACK-END ebMS and RNIF may expose a web service interface (send message, getMessage, sendSignal, getSignal kind of thing). These web services would be invoked as part of the BPEL definition. Again, I am just pointing out that if you are looking for an implementation language of the BSI something like BPEL-J would be perfect, all the power of java and all the message orientation of BPEL in one programming language. The business transaction protocol can be defined in BPEL only, but everything that pertains at verifying the collaboration integrity with respect to its definition would be done in Java. JJ- -----Original Message----- From: David RR Webber [mailto:david@drrw.info] Sent: Friday, June 04, 2004 11:15 AM To: martin.me.roberts@bt.com; Jean-Jacques Dubray; Robert.Haugen@choreology.com Cc: ebxml-bp@lists.oasis-open.org Subject: Re: [ebxml-bp] RE: BusinessActivityBehavior diagram Martin, I agree - I think this is more of a conceptual idea - that things like BPEL might be OK in this role. In reality BPEL right now is V1 and narrowly purposed and focused. There are many things it struggles to integrate to since its mostly trying to be a self-contained box of tricks rather than extensible (well - with XML at least - obviously BPELj and just-write-code is always an option - for those who want to sell code to everyone). I had the idea of designing in BPSS and then deploying as BPEL - where something like VisualScript can generate both syntaxes to effect that "glue". Right now though I see BPEL marching to a different drum. There's just too many B2B pieces that are either not there or poorly defined. What might be possible is to create fragments of BPEL that can do partial pieces of the overall BPSS - and this is akin to using WSDL to deliver on descrete steps within a BPSS as discussed previously. DW ----- Original Message ----- From: <martin.me.roberts@bt.com> To: <jeanjadu@Attachmate.com>; <Robert.Haugen@choreology.com> Cc: <ebxml-bp@lists.oasis-open.org> Sent: Friday, June 04, 2004 11:48 AM Subject: RE: [ebxml-bp] RE: BusinessActivityBehavior diagram JJ, If you implemented the BSI using BPEL how would you handle diferent protocols such as RNIF, ebXML MS Martin Roberts xml designer, BT Exact e-mail: martin.me.roberts@bt.com tel: +44(0) 1473 609785 clickdial fax: +44(0) 1473 609834 Intranet Site :http://twiki.btlabs.bt.co.uk/twiki -----Original Message----- From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] Sent: 04 June 2004 16:37 To: Roberts,MME,Martin,XSG3 R; Robert.Haugen@choreology.com Cc: ebxml-bp@lists.oasis-open.org Subject: RE: [ebxml-bp] RE: BusinessActivityBehavior diagram Some precision: I said that a collaboration is merely observed and not executed. But clearly the BSI has to handle the business transaction protocol. So the BSI is a program that "executes". However, it does not "execute" the collaboration. So I think that Martin and I are in perfect agreement. For me, the most important signal in BPSS is the "Acceptance" acknowledgement. The receipt acknowledgement works as a centralized "data scrubber" avoiding sending unnecessary data to the application (but this remains a non critical operation, i.e. BPSS would work just as well without it, it would put more burden on the application, that's all). I like the signals or errors to be explicit. I think that in general timeout should be reserved to identify communication problems (transport, end points, ...), not for generating business errors.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]