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

["Rossomando, Philip" <Philip.Rossomando@unisys.com>]

Yaron:

Your example shows me that I understood what you were saying at the
meeting.
I agreed with you then and continue to do so now. Opaque is a place
holder. Your example of the use of empty seems a lot like the use of 0
(zero) in a
Traditional program where the use of 0 can cause confusion as to its
intent. 
One thing I was wondering was also whether opaque could also be used in
the same manner as the value of an element's attribute? One final
question I have the purpose of an abstract process. Need it be used to
produce executable processes or may it be purely stand alone? In one
case we are trying to provide a framework for the construction of an
executable process while in the other it might be used to exchange
structural information between modeling tools. Would the requirements
for opaque be the same in both cases?

Phil Rossomando
 
Research Director, Technology & Architecture
Unisys Corporation
Unisys Way, B-330
Blue Bell, PA 19424 USA
Philip.rossomando@unisys.com
215-986-3998
FAX 413-0215-2043
 

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, April 14, 2004 8:05 PM
To: wsbpeltc
Subject: [wsbpel] Issue - 107 - Extension points and opacity

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_workgr
oup.php.