OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 107 - Extension points and opacity


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. 
> 
>  >>
>  >>
>  >
>  >
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]