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

["Yaron Y. Goland" <ygoland@bea.com>]

Per your questions, my proposal does include a special reserved 
attribute value to be used in attributes whose settings are meant to be 
opaque.

An abstract process is a means to an end, which is the production of an 
executable process. So I'm not sure what 'stand alone' would really 
mean. However it is clear that abstract processes will be independent 
artifacts that are edited, exchanged, etc. on their own terms.

	Yaron

Rossomando, Philip wrote:

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