[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 107 - Extension points and opacity
No, it would not. Please see the other mails on this thread as this specific topic got a lot of discussion. Thanks, Yaron Assaf Arkin wrote: > Will the specification of an abstract process state that all > implementations are only allowed to add behavior where /opaque/ exists > in the abstract and are otherwise obliged to contain the same activity > flows as defined in the abstract? > > Such a statement would clearly point out the difference between /opaque/ > and /empty//nothing. > > But then I would like to also have a specific definition of what that > added behavior consists of. If implementation details that are not > observable to my partner (not their business) have to be masked by > /opaque/, then all of a sudden everything I do that is not observable > by/of concern to my partner has to be opaqued, which means /opaque > /before and after each activity. > > Is there any precise definition of what needs to be opaqued so that we > can decide whether or not an implementation is consistent with the > abstract? > > Assaf > > > 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]