[no subject]

The analogue is to drawing a structure heirarchy diagram - I create the tree,
and the branches, and nodes, and give them names and properties.  Then once the
model looks right - then I can generate DTD, XSD, XML, CAM, HTML, xhtml, etc,
from the diagram - just using the right set of production rules for each.

I was looking at this use of BPMN from that angle - create diagram - generate
BPSS.  Now unfortunately that is not going to work for BPEL too - without some
fundamental hacking at BPEL itself - because while BPMN and BPSS can be seen as
close cousins - BPEL is marching to an entirely different drum.

Anyway - the best we can do here is have a BPSS call a BPEL component - like
check_credit_status - thru a WSDL. Where the whole thing is significantly
constrained - and there are no issues around error handling, time-to-perform,
transaction handling, signals, yadda, yadda.

I believe for 99% of our user community - this is more than acceptable. 
Reaching out to the BPMN world with BPSS is again smart, and I think we will
find people receptive.  We definately do not want to do work that is not going
to address needs of our constituents.

Cheers, DW.
============================================================
Quoting 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
> 


http://drrw.net