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

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

Yaron, Yuzo, Phil and others,

It struck me that whether one was inclined to use opaque or not (if it
becomes available) might depend on which way one was going.  If one is
starting from requirements / sketches of the process then one would tend to
just focus on the sending and receiving of messages and just use elements
that achieve that.  So opaque would not feature at all (and only if some
tool insisted that one be put here to satisfy a syntax requirement would one
be put in.

On the other hand if one is working from a full 'executable' BPEL process
and wanting to turn it into an abstract one then one might feel a little
uncomfortable about just cutting out elements and being able to replace some
of the removed material with an opaque might help psychologically.

With regard to the ambiguities you highlight, these seem to be more with
regard to giving indications as to what needs to be done if the opaque is
ever removed / the process expanded.

If this is the case (and there may be further points to make here) then
would it not be just as good to use a comment rather than a new element?
(The comment could be an XML comment or in a standard <documentation>
element.  In principle a comment could be used to resolve any ambiguity more
precisely than opaque without the committee having to think out all the
possible cases now).

However, I am sure this approach has some disadvantages as well so I wonder
where the balance lies?  For instance comments will always be optional.  Are
there cases where the use of opaque will be required e.g. used to replace a
required element or attribute in its entirety or just the value of the
element or attribute?

Best Regards     Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH  IP3  8QW
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 amfletcher@iee.org     (also tony.fletcher@talk21.com  &
tony_fletcher@btopenworld.com)
 


-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: 15 April 2004 20:17
To: Yuzo Fujishima
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue - 107 - Extension points and opacity


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