RE: [ebxml-bp] RE: ebBP / BPMN extensions

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Hi David,

I was not trying to influence your product design, of course.

What I was proposing addresses what is a 3.0 topic, namely how BPSS can
be integrated with other approaches to business process description such
as BPMN, BPEL, WS-CDL, and whatever else sprouts up. 

One initial (vague) suggestion had been that we worry about referencing
bits of BPEL or in-lining bits of BPEL. We have not really even made an
extension point in the schema for that as yet, because no one has had a
convincing proposal about where it would make sense! [There still might
be a proposal though.]

I was proposing an alternative approach, trying to leverage JJ's idea of
using BPMN as a kind of neutral process notation that could import BPEL
and BPSS instances. Then the processes involved in the 2 instances could
be put into the same picture. Patrick asked about how alignment of the
public and local process views might occur, and hinted at somehow using
parts of WSDL that was in common between the instances.

I wasn't really thinking about "deriving" BPEL and BPSS from BPMN
diagrams as you seem to indicate, just displaying them. However, it is a
natural question how to add on an editing capability. Are you stating
that an editing/generating function is too underspecified at present to
do that? If so, the value of the integration attained might be not great
from a tools payoff point of view.

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Thursday, August 26, 2004 9:27 AM
To: Dale Moberg
Cc: Patrick Yee; ebXML BP
Subject: RE: [ebxml-bp] RE: ebBP / BPMN extensions


Dale,

I was initial very enthusiastic about the notion of creating a diagram,
and then emitting BPSS and BPEL from it.

I have given up on that now for various reasons.  The current diagrams I
have allow you to call a WSDL-based step from the BPSS.  That seems to
me to be the cleanest and only option at this point.  The WSDL could of
course reference a BPEL-based interaction.

Any other integration at this point would require 

A) BPEL to be much more stable (too many moving targets)
B) BPEL to provide simple contructs of atomic syntax that support BPSS
function
C) BPEL to constrain their current interaction model(s) and handle
context
D) Ability to handle a BSI and transactions interaction architecture
E) A vendor of a BPEL engine to actually want to support this

Frankly I think we're a long way off from this - there are easier,
quicker and more robust ways we can build BPSS-based deployment systems
using existing ebXML components than trying to climb any BPEL
mountain(s).

WSDL support is the right approach - as that does much more than BPEL
alone.

Thanks, DW

Quoting Dale Moberg <dmoberg@cyclonecommerce.com>:

> Yes, I share your assumption that BPMN is at least a graphical 
> notation. The merge is then a merge "into" one picture. Underneath the

> picture, however, there exists a notation instance (of BPSS) that can 
> be used to monitor process and verify that they occur in accordance 
> with the specification, and also
> a notation instance (of BPEL) that can be used as a local execution
> language. 
> 
> Possibly WSDL could provide a common overlap of BPEL and BPSS, _if_ 
> that is needed. [It may be enough that they can be in the same 
> picture.] The OperationMapping construct that JJ is developing will 
> quite likely allow BPSS to indicate that kind of overlap. Or if a CPPA

> 2.1 or above is used, then the CPPA can contain the mapping to the 
> underlying WSDL governing the document exchange.
> 
> Currently BPSS needs to know about the Document type
> (its "envelope" name augmented as needed by arbitrary content checks 
> on the message) in order to relate message traffic to its choreography

> of BTAs. These bits of information correspond to those parts of WSDL 
> having to do with the interface proper, which are
> defined using bits of XML schema in various ways. 
> So the data in the messages would be a point of intersection possibly.
> 
> I think these topics are probably more in scope for the 3.0 version of

> BPSS than 2.0, but it doesn't hurt to begin some discussion about how 
> the notations might be used together.
> 
> 
> 
> -----Original Message-----
> From: Patrick Yee [mailto:kcyee@cecid.hku.hk]
> Sent: Thursday, August 26, 2004 1:53 AM
> To: Dale Moberg
> Subject: Re: [ebxml-bp] RE: ebBP / BPMN extensions
> 
> 
> I am a bit confused here. My impression on BPMN is that it's basically

> a
> 
> graphical location. Given this, when we say we can merge BPSS and BPEL
> using BPMN, does it mean only that we can merge them onto a same 
> picture? Technically, I guess WSDL will be the guy to link BPSS and
BPEL
> 
> up. Am I on the right track? Please comment.
> Regards, -Patrick
> 
> 
> Dale Moberg wrote:
> 
> > I have one initial question.
> >  
> > It seems to me that BPMN could effectively merge a BPSS with a BPEL 
> > (or a choregraphy with an orchestration) because it can cover both 
> > aspects.
> >  
> > Might this not be a way to connect BPSS or WS-CDL with BPEL for the 
> > purposes of a unified display? That way the XML instances could 
> > still be used separately for different tasks, and we wouldn't have 
> > to worry about how to annotate BPSS with BPEL bits to cover 
> > orchestration?
> >  
> >  
> > Dale
> >  
> > PS:
> > I  also need to find a good pointer back to a summary on the BPMN 
> > graphical constructs because some ot the arrows seem funny...
> >  
> > Are the arrow heads just links or do they indicate flow or both?
> >  
> > Is the clock a timer, indicates a possible delay, or ??
> >  
> > Looks promising at a high level though.
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >
> >     -----Original Message-----
> >     *From:* Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
> >     *Sent:* Sunday, August 22, 2004 11:06 PM
> >     *To:* Monica Martin; Dale Moberg
> >     *Cc:* Stephen A White; ebXML BP
> >     *Subject:* ebBP / BPMN extensions
> >
> >     This is my proposal for a few extensions to BPMN to be able to
> >     represent the choreography of collaborations. Here is an example
> >     (Process PO collaboration).
> >
> >      
> >
> >      
> >
> >      
> >
> >     The double line activity represent a business transaction (we
may
> >     want to use special symbols or lining scheme for indicating the
> >     need for or lack of signals)
> >
> >      
> >
> >     The dashed line represent the direction (initiating to
responder),
> >     the response flow is not indicating. When two flows cross the
> >     activity (e.g. Cancel) it means that both parties can initiate
> >     that transaction.
> >
> >      
> >
> >     Optionally, we can represent the message flow (PO / Ack PO).
> >
> >      
> >
> >     The little circle on each side of the BTA represent an endpoint.
> >     The private process connects to these end points (not fully
> >     represented here).
> >
> >      
> >
> >     I had to create a new gateway which acts as both a fork and a
> >     join. This means that change PO and Cancel PO can happen as many
> >     times as we need to, until a time out occurs. Note that the
> >     semantic of a fork gateway in a collaboration means that the BTA
> >     is enabled, not that it is necessarily executed.
> >
> >      
> >
> >     It is start is agreeable, I will do a complete analysis of what
> >     maps and does not map to a collaboration.
> >
> >      
> >
> >     Thanks,
> >
> >      
> >
> >     JJ-
> >
> >      
> >
> >      
> >
> 
> 


http://drrw.net