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

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

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