[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tamie] A closer look at BPMN 2
I'd be happy to postpone discussion a fortnight of course - could do with time to read/think about the RFP responses. In the meantime a few further comments inline... 2009/1/6 Moberg Dale <dmoberg@axway.com>: > 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? Just the thought that we'd best take care about the IPR if we wanted to explicitly compare the ETSM/TaMIE approaches to, say, monitoring collaborations and events to the approaches in the BPMN 2.0 proposals. If we just make use of the notation however of course that shouldn't be a problem. > > 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. > If the BPMN 2.0 were, say, to be more specific about a message event to BPMN 1.0/1.1 then we might find it more tricky to map it to TaMIE B2B use cases or to use BPMN 2.0 to represent the TaMIE/ETSM monitoring in addition to using it to represent a use case. When it comes to mapping a BPMN 2.0 diagram/XML to TaMIE artefacts (or using the diagram/XML to generate or guide creation of some ETSM, say) then it is not such an obvious issue, perhaps. The kind of scenario where I'd envisiage this definition of message event causing problems is where a service process model (mainly service tasks) separates the task of receiving the message from the several tasks involved in deciding what response message to return: If it models both a task to create the message and a separate task which represents the m0 web service that receives and responds to the message. I'm thinking of where a web service 'wraps' another sub-process (modelled on a separate pool or swimlane). There is the process or task of the wrapping web service and also the tasks involved internally in determining the content of the message. The message gets sent around between these several tasks before being sent by the web service. It isn't actually received until it gets to the web service consumer but each of several tasks could be thought of as acting as inermediate receivers before that. If modelling this is problematic with 2.0 then it could be all the more problematic to turn that into some ETSM - especially determining which tasks are relevant to the monitoring. Just something to watch out for perhaps. > 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? I guess modelling the tasks and events involved in the actual process of the monitoring is tricky with BPMN 1.0/1.1. If this all gets reduced to just an overloading of the message or time event symbols then it goes from being too complex to being too simple perhaps. The monitoring just gets hidden behind the event symbol. Perhaps that is a good thing though. Does the concept of event monitoring in the RFP proposal actually mean this, I wonder? Will monitoring of events be (merely) implicit in the events? How does one determine which events need monitoring? ... > > 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 > > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]