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

[Yuzo Fujishima <fujishima@bc.jp.nec.com>]

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