[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] A closer look at BPMN 2
If we have some time left at the end of our agenda today (which is already quite loaded), we'll start discuss on BPMN model(s) and how it applies to event-driven scripting. We'll put it on the agenda of the next call. Jacques -----Original Message----- From: Moberg Dale [mailto:dmoberg@axway.com] Sent: Tuesday, January 06, 2009 8:01 AM To: stephen.green@documentengineeringservices.com; tamie@lists.oasis-open.org Subject: RE: [tamie] A closer look at BPMN 2 I can try to expand on a call on your questions on both of the submissions that Jacques has pointed to that are under development for OMG's BPMN 2.0 RFP. Most of the material relating to graphical notations for diagrams derives from earlier BPMN versions. Of course, informal semantic commentary accompanied the earlier versions. The submissions for BPMN 2.0 attempt in differing ways to use OMG style formalization for BPMN semantics. As you might expect, there are several ways to approach that task. An additional major goal of interest to me is to provide an explicit graphical notation for "choreographies" (called interaction protocols in one of the submissions). I am not clear how the presence of RAND will impact us. We would have to consider how implementations of the scripting language or the event description language involve anything from the submissions. I would expect we would only use the graphical notations (once they are accepted by OMG) to describe use cases, right? We aren't going to make the languages "model-driven" in the OMG sense nor make use of MOF and related meta modeling apparatus. My guess is that using the graphical notation for examples will not encumber us at all. Or did you have something else in mind in (3), Stephen? On Stephen issue (1): message can be thought of as an interprocess communication event, as the data packet of that event, or as some specific "content" of the data packet (such as a specific business document), and I am sure much else. Clearly the proposal you refer to is picking out the event sense of "message" and is stipulating that the event of messaging is regarded as ending when it is received. Because the submitted proposal intends to be able to apply temporal constraint relations to the domain of events in a M1 level model (and probably in M0 level instances as well!) it is good to have an idea of "when" an event begins or ends, so that what occurs before or after (or at the same time) can be modeled. We probably want to be able to monitor or test that the temporal constraints so described. So we will need such a concept IMO. You are of course right that the content in the message is extracted and passed around to numerous internal processes, not necessarily as a message but perhaps as a file or as part of a RPC etc etc. (Actually the modeling of this ETL process is not very well handled by either submission IMO because of underspecification of various concepts of "content" involved and how we call it different things, depending on syntax, technical modes of "passing data" (by reference, value and so on) as well as using queues, files, etc. But most of these details are software related, and BPMN is supposedly aimed at a business level of description abstraction level. On SG (2): I am not clear enough on what we mean by monitor to respond to this issue yet. Maybe you could elaborate on the call? On Jacques (1,2,3): I agree that these concepts might be useful in connecting some of our concerns to other related vocabularies. OMG does even have other initiatives for a metamodel for event that are underway, however. We could, once BPMN 2.0 is voted on, make use of the graphics for documenting use cases. (I have used a simple LTS graphic of a directed graph with labels on the transition edges because I have arrived at the view that this is the most generally applicable view of states/actions and their specified or observed transitions...) ==== Stephen Green 1: I think we might have a problem with the concept in proposal '08-11-07' that a message 'ends when it is received'. A message is still being used in the event board after it is 'received' when the message is being monitored. Also the message is 'received' in different ways in multiple Tasks/SubProcesses when, for example, the message gets processed by a web server, then by a back-office system and possibly when the message is forwarded in a process like drop-ship or factoring (also of course many kind of internal process have to pass messages on from task to task). Stephen Green 2: Secondly, it would be interesting to see if the '08-11-07' proposed event monitor maps exactly to what we mean in TaMIE by an event monitor. Stephen Green 3: > We'd better take note that the second is (intended to be) RF on RAND > (the first seems to be RF?) Durand, Jacques R. <JDurand@us.fujitsu.com> 1: >> Interesting event modeling and reusable notations in BPMN2 Durand, Jacques R. <JDurand@us.fujitsu.com> 2: >> http://www.omg.org/cgi-bin/doc?bmi/08-11-07.pdf >> >> - Event models and different event types (see section 6). See also events >> taxonomy in Fig 48 (section 7.7) >> - Event "monitors" (section 7) >> - also useful notations for different kinds of split / merge. >> Durand, Jacques R. <JDurand@us.fujitsu.com> 3: >> Also in a complementary (competing?) submission: >> http://www.omg.org/cgi-bin/doc?bmi/08-11-01.pdf >> >> - See 7.7.7, table 7-2 about different event types and notations. See also >> 8.2.4. and 10.4 >> - concept of Message (8.2.9) and of Correlations of different kinds (8.2.3) >> >> >> >> Jacques > > > > -- > Stephen D. Green > > Document Engineering Services Ltd > > > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]