[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 5/15/2005: BPMN Next Version and Next Steps
In Tuesday's call, we discussed upcoming BPMI Think Tank that includes BPMN session. Below is the interchange between Stephen White and I regarding the addition of a collaboration activity to support our business requirements. [1] If any team member has any comments or questions, please let me know. I'll bring any questions to the meeting Tuesday and Wednesday (17-18 May 2005). Thank you. Regards and thanks to Layna for keeing our team informed. [1] Public BPMN minutes found at: http://www.bpmn.org/Meeting%20Minutes/NWG-2005-04-01%20Conference%20Call%204-14-05.htm Think Tank event: http://www.bpmi.org/events_pr.htm#BPM_Think_Tank_Task_Group_Meetings > Monica, > Thanks for the input, and see some responses inline. > > We have made some progress, but I admit we have been slow. Partly > because my time is being divided up between other projects and I can't > spend as much time as I would like. > > I think we don't have a problem with the shapes outside the Pools any > more, since BPMN already allows a "central" Pool that doesn't require > a solid boundary. Having a Pools that are placed in between shapes of > the central Pool is a bit of stretch maybe, but I think it is > allowable. We just have to look at the properties of a Pool and make > sure we are covering this situation properly. Thus, all the issues > around shapes outside the Pools just go away. > > The key issue, then, is the inclusion of a new type of activity--the > collaboration or joint activity. Some of the discussion below relates > to this. The new type of activity is probably required because of the > way Message Flow connects to these types of activities. Message Flow > (MF) must act in pairs where there is one incoming MF matched with an > outgoing MF, each carrying the exact same Message. This type of > behavior does not apply to activities within an internal, managed > process. > > There is also ongoing work within the OMG for BPDM, which is looking > closely at choreographies and orchestrations. This work should also > influence where BPMN will go with this. > > *Monica J Martin <Monica.Martin@Sun.COM>* > > 05/09/2005 01:42 PM > > > To > rob.bartel@igrafx.com, Stephen A White/Irvine/IBM@IBMUS > cc > Jean-Jacques Dubray <jeanjadu@Attachmate.com>, Dale Moberg > <dmoberg@cyclonecommerce.com> > Subject > Bartel/White 5.9.2005: BPMN Next Version and Next Steps > > > > > > > > > > Rob and Stephen, > In preparation for the meetings next week (as a followup to the Think > Tank), I'd like to get an update on BPMN progress. I've extracted the > public meeting snippet from April 2005 and added a few comments. Perhaps > you can give me some additional detail so I can think about before next > week's meeting. Dale may also be attending. Thanks. > > ========== > We did discuss the topics regarding the addition of > collaboration/choreography modeling within BPMN. When looking at an > example, such as this > <http://www.bpmn.org/Samples/ebXML_Business_Process/ebXML%20Example2.jpg>, > > it becomes clear (to us) that the current BPMN specification does not > provide the capabilities to create the example. Conceptually, the > diagram is creating a conceptual one rather than an actual process--that > is, the actual activities are being performed within the confines of the > seperate participants. > > [mm1] Actually there is an actual shared business collaboration process > that includes shared expectations. They have a collaborative view of > activities, the state, etc. > > We discussed that the diagram is defining a series of states that the > participants expect to occur. The states are conceptual in that they can > never really be tested or verified. There are actually separate states > being held individually by the participants. > > [mm1] There is a shared state that is understood and states (potentially > many state machines) held individually by the parties. > > <saw>Yes the process is shared and each participant would have its own > view of the state of the process, or an activity within the process, > but it is possible that the participants may have different views of > the states. The general idea is that there is no specific (or > centralized) holder of the state of the process. > > Both choreographies and orchestrations are business processes, but we > were trying to illustrate that they have different characteristics > (which need to be dealt with graphically and/or semantically).</saw> > > > One change would be to add a new type of activity, a "collaboration > activity." This activity would exist in between the Pools (and not > within the Pools). Because the activity is between the Pools, other > elements will also have been exist within the Pools also, e.g., > Gateways, Sequence Flow, etc. We discussed whether these other elements > are actually the same as their internal process counterparts, and > whether they should be named or shown differently (e.g., with a > different line style). If they are different, then this creates a whole > new set of shapes to describe. If they are the same, then it becomes > more complicated to describe how they behave. We haven't resolved this > yet. > > [mm1] Requires more discussion. I'd interject that not all visualization > or design of processes realizes itself in an executable process. > > <saw>As mentioned above, most of this goes away except the new type of > activity.</saw> > > Relatedly, we discussed whether or not any changes should be defined in > a new diagram or as part of the current BPD. We seem to be leaning > towards extending the current diagram, since looking at the example > <http://www.bpmn.org/Samples/ebXML_Business_Process/ebXML%20Example2.jpg>, > > it seems very likely that one of the participants may want to see their > internal or abstract process within their Pool, making it all in one > diagram. > > The usage of BPMN, with the proper documentation, for the purposes of > choreography or internal processes, should be clear (at least we think > so). > > [mm1] This is inline with our discussion thus far.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]