Issue 2975: WfRequeste and WfActivity inheritance - The Phanton Menace (wf-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future. I think that the goal of the WMF DTF is to define a standard that could be possible the componentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard. But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. I think that you like to be a kind of Object-Oriented Jake Stripper :-) Resolution: Revised Text: Actions taken: November 1, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 1 Nov 1999 10:49:12 -0200 (EDT) From: Benito Tomas Giordani Message-Id: <199911011249.KAA06498@lencois.dca.fee.unicamp.br> To: wf-wg@omg.org Subject: WfRequeste and WfActivity inheritance - The Phanton Menace Content-Type: text X-UIDL: 0n%!!)T5e9fm7e97O&e9 Dear Dr. OMG WMF DTF, This message is part of a discussion between I and Dan Matenson (DM) about the inheritance relationship between WfRequester and WfActivity that made up the OMG Workflow Management Facility. Let s go. Dear Dr. Dan Mathenson (DM), Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future. I think that the goal of the WMF DTF is to define a standard that could be possible the componentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard. But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. I think that you like to be a kind of Object-Oriented Jake Stripper :-) DM said - The original specification required every WfActivity to also be a WfRequester. This was a mistake. It was not a mistake but a half of a mistake. But first, take a look at some statements at the WMF RFP (document cf/97-05-06). (i) chapter 5, GENERAL REQUIREMENTS ON PROPOSALS, section 5.1.3 - Proposals shall be precise and functionally complete. There should be no implied or hidden interfaces, operations, or functions required to enable an implementation of the proposed specification, (ii) chapter 6, SPECIFIC REQUEREMENTS ON PROPOSALS, section 6.5 - MANDATORY REQUIREMENTS - Nesting of Workflows: Submissions shall provide interfaces that support accessing nested workflows, ... The lack of that inheritance relationship has causing a side effect worst and bigger than with it. Now we can not say that a process can realise an activity in a righ level process (statement (ii) fails). The facility (as it is) left to the implementation plan not only a very important decision but a MANDATORY REQUIREMENT (statement (i) fails). Now we can not say anymore that an WfActivity is a WfRequester (dtc/99-07-05 - page 1-17 Nested sub-process subsection, 2-51 Process Requester subsection, 2-51 Process Steps subsection, page 2-56 Activity Realizations, and many more). DM The standard should force the least constraints on the implementers. We all understand what you what to say here but it is time to converge. And all of us need to understand this and cooperate. Without convergence the facility is going to fail. DM The resolution of this issue was agreed to by all summitters as the best thing to do. I have proves that this is not totaly true, I know some people (inside the commitee) that dont know about this change and liked the ideia of the inheritance. This was my comments. I hope that the group read my arguments and try to reformulate the specification. This facility is very important, ambitious and deserve thoroughness. Cheers, Benito Tomas Giordani - benito@computer.org Date: Wed, 03 Nov 1999 18:57:53 -0700 From: Dan Matheson X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Benito Tomas Giordani CC: wf-wg@omg.org Subject: Re: WfRequeste and WfActivity inheritance - The Phanton Menace References: <199911011249.KAA06498@lencois.dca.fee.unicamp.br> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i:*!!8=W!!ep9!!jg8!! Hi Benito, I have placed some commits with your message. By the way I am not a Dr., just an ordinary software developer. Benito Tomas Giordani wrote: > > Dear Dr. OMG WMF DTF, > > > I think that the goal of the WMF DTF is to define a standard > that could be possible the componentization and interoperability > of a workflow management system. We also know that only the > definition of the interfaces (syntactic interoperability) is > not enough to the componentization. It is also needed to define > the semantic of this interfaces at formal level (and sometimes > is also needed to specify non-functional requirements as part > of the contract but this is a future problem). The last is > very dificult to be achieved but is needed to create an open > standard. > DM said - The original specification required every WfActivity > to also be a WfRequester. This was a mistake. > > It was not a mistake but a half of a mistake. But first, take > a look at some statements at the WMF RFP (document cf/97-05-06). > (i) chapter 5, GENERAL REQUIREMENTS ON PROPOSALS, section 5.1.3 - > Proposals shall be precise and functionally complete. There > should be no implied or hidden interfaces, operations, or functions > required to enable an implementation of the proposed specification, > (ii) chapter 6, SPECIFIC REQUEREMENTS ON PROPOSALS, section 6.5 - > MANDATORY REQUIREMENTS - Nesting of Workflows: Submissions shall > provide interfaces that support accessing nested workflows, ... > The lack of that inheritance relationship has causing a side effect > worst and bigger than with it. Now we can not say that a process > can realise an activity in a righ level process (statement (ii) > fails). The facility (as it is) left to the implementation plan > not only a very important decision but a MANDATORY REQUIREMENT > (statement (i) fails). Now we can not say anymore that an WfActivity > > is a WfRequester (dtc/99-07-05 - page 1-17 Nested sub-process > subsection, 2-51 Process Requester subsection, 2-51 Process > Steps subsection, page 2-56 Activity Realizations, and many more). In all the discussion we had as submitters we talked about WfActvity having many possibilities. One of the most important possibilities is that an Activity object starts another process. For an Activity to do this it must also implement the WfRequester interface. So, we put an inheritance from WfActivity interface to the WfRequester interface. As I said in the previous email this was a mistake. All the submitters and members of the RTF agreed. An OMG standard is about interfaces. Ideally, each interface should represent a single clear concept. The interfaces can be combined into efficient object implementations. The standard should also support a range of implementations. If we had left the inheritance relationship there, then WfActivity would reflect 2 separate concepts. It would also require implementations to support the WfRequester interface in all specializations of the WfActivity interface. Because we are working in the object world we can use standard object techniques such as specialization. The standard should not attempt to enumerate all possible specializations and combinations of the interfaces. I believe that (i) is fulfilled by the RTF approved change, since there are no hidden or implied interfaces. Nothing like this came up in the submitter discussion, the open OMG evaluation of the submission, the AB review or as an issue. I believe that (ii) is fulfilled in that we have the interfaces needed to support nesting of workflows. It is un-necessary to show the obvious combination of the WfRequester and WfActivity interfaces in the UML diagram. In sections 1.5.5, 2.1.2, and 2.3 (bullet 1) we talk about nesting of workflows and that an Activity must also be a Requester. > DM - The standard should force the least constraints on the implementers. > > We all understand what you what to say here but it is time to > converge. And all of us need to understand this and cooperate. > Without convergence the facility is going to fail. This is just the first step. It was the subset that many people could agree on. The next steps are the process definition and the resource assignment. Both of these will probably produce changes to the execution model. There can also be an RFP to extend the current standard. The OMG process is very pragmatic, they want standards that will be implemented. > DM - The resolution of this issue was agreed to by all summitters > as the best thing to do. > I have proves that this is not totaly true, I know some people > (inside the commitee) that dont know about this change and liked > the idea of the inheritance. Removing the required inheritance does not prevent someone from doing the inheritance in their product. The OMG standardization process is a democratic process and a voluntary process. The people that have invested in the standard support the change. We welcome your comments, but as an outside observer you have no direct influence. If the submitters agree, the RTF members agree, the AB agrees and the voting members of the OMG agree, then it is by definition the best thing to do today. You are invited to participate in the process. You can submit issues to issues@omg.org. If your organization is a member you can volunteer to be on the next RTF. > This was my comments. I hope that the group read my arguments > and try to reformulate the specification. This facility is very > important, ambitious and deserve thoroughness. -- Dan Matheson Software Developer, PDM Business CoCreate Software, A Hewlett-Packard Company 3801 Automation Way Suite 110 Fort Collins, Colorado 80525 USA Tel: +1 970 206 8050 Fax: +1 970 206 8025 email: danm@cocreate.fc.hp.com WWW: http://www.cocreate.com From: mts@uk.ibm.com X-Lotus-FromDomain: IBMGB To: undisclosed-recipients:; To: Benito Tomas Giordani cc: "Andreas Kronz" , wf-rtf@omg.org Message-ID: <80256817.00631EE6.00@d06mta06.portsmouth.uk.ibm.com> Date: Wed, 27 Oct 1999 19:03:10 +0100 Subject: Re: WfRequeste and WfActivity inheritance observation Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: Rk+!!>D*e9c?7e9@93e9 There are two main reasons for removing the inheritance relationship between WfRequester and WfActivity. One is (as Fred Cummins points out) that not all WfActivities are WfRequesters (e.g., when the WfActivity is realised by some 'local' application); this could be fixed using your proposal (association with 0..1 cardinality). The other reason is that even when a WfActivity is realised by another WfProcess (a sub-process), it is not necessarily the WfActivity that serves as the WfRequester for that WfProcess. We wanted to give implementers of the WfM Facility the option to choose other entities (e.g., the WfProcess or some other 'observer') as 'callback' for the sub-process. Best regards, Marc-Thomas Schmidt IBM Hursley, MQ Business Integration Architecture phone: +44-1962-81-7193, e-mail: mts@uk.ibm.com Benito Tomas Giordani on 26/10/99 13:47:23 Please respond to Benito Tomas Giordani To: undisclosed-recipients:;, Marc-Thomas Schmidt/UK/IBM@IBMGB cc: Subject: WfRequeste and WfActivity inheritance observation Dear Dr. Marc-Thomas Schmidt, Sorry by my bad English but I think that you will understand the appointed problem. I am following the WMF DTF efforts since early in 1998. Therefore I am a witness of the WMF model"s evolution. Some day ago I read some articles on IEEE Concurrency Magazine. One of them was written by Mark Thomas-Schmidt and I saw in the OMG WMF jFlow model that the inheritance relationship from WfRequester to WfActivity was stripped off. This way I put myself to follow the clues and I found an Issue (number 2042) on the dtc/99-07-04 document where the Dr. Fred Cummnis do the following statement: "Not all activities will also be requesters." This is absolutely true. Therefore I think that this relationship is not mandatory to be used during the execution. Then the RTF Group proposed solution to this problem is as follows: "Remove inheritance relationship between WfRequester and WfActivity and explain that an object that implements the WfActivity interface can also realise a WfRequester." I think this solution is worst than the previous one because this left rooms to different interpretations by the developers during the implementations plan. And more, in the visual model (figure 2-1) there is no clues about "How I can use a process as a sub-process?." The justification to that solution state: "This provides a more generic object model without loss of capability"; but a model should not be too generic because this can cause incompatibility problems. How can a class implements a non-exitent operation"s interface? I think that the current solution causes bigger problems than the old model. A better solution, if it is really needed to strip off the inheritance relationship, could be to create an association (possibly an agregation relationship) with appropriated cardinality between WfRequester and WfActivity. The use of an association to bypass inheritance is well known [Clemens Szyperschy - Software Component] and this solution is less ambiguous than that propose in the dtc/99-07-04 document. A generic model is not good because left room to different interpretations and incompatibility of components. The specification of this problem is needed to the componentization. Looking forward for your comments, Benito Tomas Giordani - benito@computer.org 2975 - replace generalization relation between WfRequester and WfActivity. This person thinks that the generalization relation removed in v 1.2 should be put back. I do not think the relation should be put back. Any other opinions out there. issue text Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future. I think that the goal of the WMF DTF is to define a standard that could be possible the omponentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard. But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. From: mts@uk.ibm.com X-Lotus-FromDomain: IBMGB To: Dan Matheson cc: wf-rtf@omg.org Message-ID: <80256879.002FA6F6.00@d06mta06.portsmouth.uk.ibm.com> Date: Tue, 1 Feb 2000 18:35:39 +0000 Subject: Re: 4 issues for the WF-RTF Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: _?8!!XHhd9\!nd9=aC!! Dan, some comments on the issues: 2100: I like the second resultion; could you please remind me why Fred vetoed it? 2975: I do not think we should re-introduce the generalisation between WfRequester and WfActivity. Not every WfActivity is a WfRequester. I agree with the change you propose to the UML diagram (solid diamonds) - WfProcess 'owns' its WfActivites, same for WfAssigments and WfActivity I think the argument of 'is_member_of_history' should be a WfEventAudit - the 'is_member_of_...' operation is type of the pattern we use to navigate a relationship and always takes the type at 'the other end' of the navigated relationship as input (there are many examples of that pattern). I think this is simply a 'copy&paste' error, not sure whether we need to make this an RTF issue... Best regards, Marc-Thomas Schmidt IBM Hursley, MQ Business Integration Architecture phone: +44-1962-81-7193, e-mail: mts@uk.ibm.com Dan Matheson on 31/01/2000 22:10:00 Please respond to Dan Matheson To: wf-rtf@omg.org cc: (bcc: Marc-Thomas Schmidt/UK/IBM) Subject: 4 issues for the WF-RTF Hi All, The time frame for comments closes tomorow. It appears that we have 4 issues to resolve for this RTF. 2 of the issues are not registered yet. I will take care of that. 2100 - vetoed 2 time during v1.2 RTF process I would like to get a proposal from the RTF members on how to resolve this. issue text With respect to WfExecutionObject and WfEventAudit I am wondering if there has been any consideration for loops in a workflow. E.g. Would it be possible for the same WfExecutionObject to be executed twice because there was a rework loop in the process definition ? How would this impact the state diagram for WfExecutionObject ? There does not appear to be any way to move 'back' from closed to open. How would this be handled by the WfEventAudit records ? first resolution ballot 1, veto by Adel Ghomeny, Fujitsu Section 2.4.3, subsection 'workflow_state state set' add text at end: "An execution object is either in state 'open', i.e., it is active or in state 'closed', i.e., it has finished execution; it cannot be 're-activeted', i.e., once it has entered state closed it will not re-enter state open." second resolution ballot 5, veto by Fred Cummins, EDS Section 2.4.3, subsection 'workflow_state state set' add text at end: "An execution object is either in state 'open', i.e., it is active or in state 'closed', i.e., it has finished execution. An implementation is free to add additional sub-states to any of the standard states. The standard provides the minimum transitions between the states for normal forward operation. An implementation is free to add aditional state transitions. The reuse of a WfExecutionObject, i.e. within a loop, is an option of the implementation." 2975 - replace generalization relation between WfRequester and WfActivity. This person thinks that the generalization relation removed in v 1.2 should be put back. I do not think the relation should be put back. Any other opinions out there. issue text Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future. I think that the goal of the WMF DTF is to define a standard that could be possible the omponentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard. But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. ???? - new issue, submitted by me This is a small UML diagram correction to match the text. issue text The UML diagram from the 1.2 version shows the aggregation between WfProcess and WfActivity and the aggregation between WfActivity and WfAssignment as aggregations with unidirectional navigability (open diamond). These two aggregations should be of typ[e composite aggregation with bidirectional navigability (filled-in diamond). ???? - problem with the 2041 resolution, by Toshiaki Sakaguchi, Hitachi Yes, there is a mistake in the IDL of issue 2041. I think the WfExecutionObject should be a WfEventAudit issue text I found that the resolution text of issue 2041 had a problem. In the text the following operation is added to WfExecutionObject interface. boolean is_member_of_history(in WfExecutionObject member) raises(WfBase::BaseException); I think the argument "WfExecutionObject member" is strange because the operation is named as "member of history". Is it WfEventAudit ? If it is WfEventAudit do we have to raise a RTF issue?