Re: [ebxml-bp] RE: BusinessActivityBehavior diagram

["David RR Webber" <david@drrw.info>]

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.