[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 107 - Extension points and opacity
Yaron, I don't see how <opaque> can be useful in preventing "mistakenly omitting something". It seems to me that the likelihood of "mistakenly omitting something" is roughly equal to that of "mistakenly omitting <opaque>". Yuzo Fujishima NEC Corporation. Yaron Y. Goland wrote: > It is true that your proposal would remove ambiguity but at the cost of > making abstract process definitions very fragile. Mistakenly omitting > something would end up being interpreted as intentionally omitting > something. By introducing opaque we remove that sort of error and > therefore make abstract process definitions more robust. > > Portability of definitions is always going to be hard and every > opportunity we leave for honest mistakes will cause those mistakes to > happen. The tighter we make the definition, the less room we leave for > errors, the more likely we are to get portability. > > Yaron > > Yuzo Fujishima wrote: > >> >> >> Yaron, >> >> My opinion is as follows: >> >> If the event handler has some observable behavior, >> the behavior must be explicitly expressed using receive, >> invoke, and so on. >> >> If an event handler has no content in an abstract process, >> it must be interpreted as no observable behavior, i.e., only >> private behavior. >> >> Put in another way: >> "An abstract process must express all the observable behavior. >> Absence of description must be interpreted as >> absence of observable behavior, not as omission of description." >> >> Then there is no ambiguity. >> >> Just in case: >> If you are saying "there is some behavior that are >> observable but cannot be expressed explicitly with current >> BPEL activity set", then we should elaborate and clarify what >> they are and introduce new activities, if necessary. >> >> Yuzo Fujishima >> NEC Corporation >> >> >> Yaron Y. Goland wrote: >> >> > Even if we only supported #1, which I think would be a mistake, we >> still >> > need opaque. >> > >> > For example, let's say I'm specifying in my abstract process that in a >> > certain scope I have event handlers that allow me to accept events >> from >> > my parents, so in the abstract process I write: >> > >> > ... >> > scope >> > eventHandlers >> > onEvent ... >> > ... >> > >> > In this example the onEvent handler is null. There is no content. >> So now >> > my partner has to wonder, did I intentionally leave the event handler >> > blank because what I do with the event is not germane to my observable >> > behavior or did I forget to put in code that describes something >> > important about what I do with the event like immediately respond >> with a >> > 'confirming I got your event' message? >> > >> > A possible solution would be to specify >> > ... >> > scope >> > eventHandlers >> > onEvent ... >> > empty >> > ... >> > >> > Now my partner has to wonder 'did Yaron put in the empty in order to >> > tell me that while he is willing to accept the specified event he >> won't >> > ever do anything with it so I might as well not bother to send it >> or did >> > he mean to tell me that he will handle the event but not specify how?' >> > >> > On the other hand if I specify: >> > >> > ... >> > scope >> > eventHandlers >> > onEvent ... >> > opaque >> > ... >> > >> > Then my partner knows that I explicitly meant not to communicate >> what I >> > was going to do with the event. There is no ambiguity. >> > >> > So I think opaque is necessary for #1 and #2. >> > >> > Yaron >> > >> > Yuzo Fujishima wrote: >> > >> >> >> >> >> >> Yaron, >> >> >> >> >> >> * As for abstract process usage * >> >> >> >> I agree that there CAN be two kinds of usages for abstract process. >> >> >> >> I believe Usage #1 is useful. Hopefully nobody in the TC disagrees. >> >> >> >> I am yet to be convinced of the usefulness of #2. >> >> I don't care how, for example, my trading partner implements >> >> the service as far as the implementation adheres to the agreed-upon >> >> interface. >> >> I believe standardizing on template should require more effort and >> >> time than >> >> standardizing on interface. I guess the extra effort and time cannot >> >> be justified >> >> against the merit expected in most cases. I see 80%-20% principle >> here. >> >> >> >> >> >> * As for putting <receive> into <opaque> * >> >> >> >> I think we agree on this. I should have clarified what I meant "in >> >> most cases" >> >> in my original statement: >> >> >> Therefore, I think putting <assign> in the place of <opaque> >> >> should be >> >> >> acceptable (at least in most cases, I believe) while putting >> >> <receive> is >> >> >> >> If putting <receive> does not change the public (in other words, >> >> observable- >> >> to-the-outside-party) behavior, it is legal. This is true for all >> other >> >> activities. >> >> >> >> >> >> * As for the two examples of ambiguity * >> >> >> >> What I had in mind was Usage #1. >> >> Do you agree that if we are to support only #1, we don't need >> <opaque>? >> >> >> >> If we are to support #2, it seems reasonable to have a measure to >> >> specify where in the process one can/must put his/her own >> implementation >> >> details. I agree that <opaque> is a good candidate as the measure. >> >> >> >> Yuzo Fujishima >> >> NEC Corporation >> >> >> >> >> >> >> >> Yaron Y. Goland wrote: >> >> >> >> > I actually see abstract processes being used in two different >> >> contexts. >> >> > >> >> > #1 - To define the externally visible contract for a protocol. >> That >> >> is, >> >> > system A wishes to work with system B. System B publishes an >> abstract >> >> > process. System A writes its code to work with System B's abstract >> >> > process and so is able to interoperate with System B's executable >> >> process. >> >> > >> >> > #2 - To provide templates for those wishing to provide >> implementations >> >> > of standardized services. For example, the International >> >> Association of >> >> > Widget makers provides a standard for a widget request service. As >> >> part >> >> > of that standard they provide an abstract process definition that >> >> > specifies how someone implementing the widget request service >> is to >> >> > behave. So when a widget maker decides to implement the widget >> request >> >> > service they will validate their executable code against the >> abstract >> >> > process definition. In other words, they must make sure that their >> >> > executable process does the same thing the abstract process >> definition >> >> > specifies. This is the inverse of the previous example. >> >> > >> >> > To your point about being able to put in an assign but not a >> >> receive, I >> >> > would offer the following as a counter example. Imagine that a >> widget >> >> > maker implementing the widget request service adds in a receive to >> >> their >> >> > implementation of the widget request service that waits for >> up-to-date >> >> > information from the widget factories as to the current number of >> >> > available widgets. This receive not be specified in the abstract >> >> process >> >> > definition since it is not relevant to that definition how the >> widget >> >> > request service knows how many widgets are available. So in this >> >> case it >> >> > is completely reasonable for the executable process to add in a >> >> receive >> >> > that was never specified in the abstract process definition. >> >> > >> >> > Finally, as to your assertion that opaque is not necessary it >> is very >> >> > difficult to respond to an assertion. In my original e-mail >> below I >> >> > provide two examples where the use of either nothing or empty >> causes >> >> > ambiguities and then show how opaque resolves those >> ambiguities. If >> >> you >> >> > could illustrate that the ambiguities I describe don't actually >> exist >> >> > then it would seem likely that you would have made the case that >> >> opaque >> >> > is unnecessary. >> >> > >> >> > Thanks, >> >> > Yaron >> >> > >> >> > Yuzo Fujishima wrote: >> >> > >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> I believe that an abstract process defines the behavior of a >> >> process that >> >> >> is observable from outside. In other words, an abstract >> process is a >> >> >> contract to outside parties. In addition, I assume that an >> abstract >> >> >> process must be unambiguous as a contract although it does not >> >> restrict >> >> >> implementation details. >> >> >> >> >> >> In my opinion, the executable process corresponding to an >> abstract >> >> >> process >> >> >> can be implemented in any way the implementor like as far as the >> >> contract >> >> >> is satisfied. At the same time, any implementation that does not >> >> satisfy >> >> >> the contract should be deemed incompliant. >> >> >> >> >> >> Therefore, I think putting <assign> in the place of <opaque> >> >> should be >> >> >> acceptable (at least in most cases, I believe) while putting >> >> <receive> is >> >> >> in many cases illegal because it does modify the observable >> behavior. >> >> >> >> >> >> That being said, my conclusion is that I don't see the >> necessity of >> >> >> introducing <opaque>. One can derive an executable process >> from an >> >> >> abstract >> >> >> process definition by inserting any activity anywhere as far >> as the >> >> >> contract >> >> >> is satisfied. >> >> >> >> >> >> Yuzo Fujishima >> >> >> NEC Corporation >> >> >> >> >> >> Yaron Y. Goland wrote: >> >> >> >> >> >> > One of the big concerns that came up on today's discussion of >> >> issue >> >> >> 107 >> >> >> > was how the opacity proposal altered the ability to extend an >> >> abstract >> >> >> > process. >> >> >> > >> >> >> > For example, imagine the following abstract process that uses >> >> opaque: >> >> >> > >> >> >> > process >> >> >> > opaque >> >> >> > receive >> >> >> > reply >> >> >> > >> >> >> > If someone wanted to build an executable process based on this >> >> >> abstract >> >> >> > process would it be 'legal' to write something like the >> >> following and >> >> >> > still have it be considered valid against the abstract >> process? >> >> >> > >> >> >> > process >> >> >> > ... >> >> >> > receive >> >> >> > assign >> >> >> > reply >> >> >> > >> >> >> > In other words, could the executable process programmer >> insert the >> >> >> > 'assign' activity between the receive and reply activity >> and still >> >> >> have >> >> >> > their executable process be considered valid against the >> abstract >> >> >> > process definition? >> >> >> > >> >> >> > In my proposal the answer is - yes. In my opinion one is >> free to >> >> >> extend >> >> >> > an abstract process at absolutely any point one wants. The >> >> purpose of >> >> >> > validating an executable process against an abstract >> process is to >> >> >> make >> >> >> > sure that the executable process does 'at least' what the >> abstract >> >> >> > process does but it is free to do much more. >> >> >> > >> >> >> > The purpose of opaque is not to restrict where one can >> extend an >> >> >> > abstract process when creating an executable process. The >> >> purpose of >> >> >> > opaque is to specify where the abstract process is >> intentionally >> >> >> leaving >> >> >> > out data in situations where the absence of information >> could be >> >> >> ambiguous. >> >> >> > >> >> >> > For example, let's say that an abstract process has the >> >> following code >> >> >> > snippet: >> >> >> > >> >> >> > process >> >> >> > scope >> >> >> > eventHandlers >> >> >> > onEvent ... >> >> >> > ... >> >> >> > >> >> >> > In this case the onEvent handler in the abstract process >> has no >> >> >> content. >> >> >> > >> >> >> > So now the reader of the abstract process is left with a >> >> quandary. Is >> >> >> > the onEvent handler empty because the definition of the event >> >> >> handler is >> >> >> > left up to the implementer or is the event handler empty >> >> because the >> >> >> > programmer of the abstract process screwed up and forgot to >> put >> >> in the >> >> >> > definition for the event handler? >> >> >> > >> >> >> > One way around this ambiguity is to do the following: >> >> >> > >> >> >> > process >> >> >> > scope >> >> >> > eventHandlers >> >> >> > onEvent ... >> >> >> > empty >> >> >> > ... >> >> >> > >> >> >> > By inserting empty it is clear to the reader that the onEvent >> >> handler >> >> >> > was intended to not have any definition. The only problem >> is that >> >> >> empty >> >> >> > has its own very specific meaning - do nothing. So now >> there is >> >> >> another >> >> >> > ambiguity. Is the abstract process author telling the >> executable >> >> >> process >> >> >> > author 'Write your own code for this event handler' or are >> they >> >> >> telling >> >> >> > the executable process author 'You are required to catch the >> >> messages >> >> >> > identified by this event handler but then you should do >> nothing >> >> with >> >> >> > those messages'? >> >> >> > >> >> >> > This is where opaque comes in. >> >> >> > process >> >> >> > scope >> >> >> > eventHandlers >> >> >> > onEvent ... >> >> >> > opaque >> >> >> > ... >> >> >> > >> >> >> > Now there is no ambiguity. The abstract author is explicitly >> >> >> telling the >> >> >> > executable author 'You must catch the messages identified >> by this >> >> >> event >> >> >> > handler but how you handle them is up to you.' >> >> >> > >> >> >> > It is only necessary, however, to use opaque if its absence >> >> would lead >> >> >> > to ambiguity. So, going back to the example, that started this >> >> mail, >> >> >> > there is no need to specify >> >> >> > >> >> >> > process >> >> >> > opaque >> >> >> > receive >> >> >> > opaque >> >> >> > reply >> >> >> > >> >> >> > In order to tell the executable programmer "You MAY insert >> >> activities >> >> >> > between the receive and reply". >> >> >> > >> >> >> > It's fine to just specify: >> >> >> > >> >> >> > process >> >> >> > opaque >> >> >> > receive >> >> >> > reply >> >> >> > >> >> >> > The right to insert additional activities between the >> receive and >> >> >> reply >> >> >> > is always implicit and unambiguous so opaque is not needed. >> >> >> > >> >> >> > I hope this clarifies things, >> >> >> > >> >> >> > Thanks, >> >> >> > >> >> >> > Yaron >> >> >> > >> >> >> > >> >> >> > To unsubscribe from this mailing list (and be removed from the >> >> >> roster of >> >> >> > the OASIS TC), go to >> >> >> > >> >> >> >> >> >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> > >> >> > >> >> >> >> >> >> To unsubscribe from this mailing list (and be removed from the roster >> >> of the OASIS TC), go to >> >> >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> >> >> >> >> > >> > >> > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]