Re: [ebxml-bp] RE: BusinessActivityBehavior diagram

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

Jean-Jacques,

Alternately an ebMS server can have a bridge and ability to
interface via WSDL into backend applications via BPEL.

This is less problematic as a backend integration solution
since there are much less QoS issues and configuration
and interchange control is all inside the firewall.

DW.

----- Original Message ----- 
From: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>
To: "David RR Webber" <david@drrw.info>; <martin.me.roberts@bt.com>;
<Robert.Haugen@choreology.com>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Friday, June 04, 2004 2:21 PM
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.