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

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

I think I understand your objection but let me repeat it just to make 
sure I'm right.

Let's say that we introduce the opaque activity. Let's further say that 
someone wants to communicate how their process works so that their 
partner can interoperate with them. In the abstract process the partner 
specifies the following:

...
    eventHandlers
       onEvent ...
          empty

The person reading this abstract process and trying to figure out what 
it says about how their partner will operate is now in a bit of a 
quandary. Did their partner mean to say 'If you send this event I will 
ignore it' or did their partner mean to say 'If you send this event I 
will execute an empty method and then do something else'? The later 
interpretation is possible because in an abstract process its always 
possible to shove in activities anywhere one would like.

But while the later interpretation may be possible, is it reasonable? Is 
it reasonable to look at an event handler in an abstract process whose 
only contents is empty, given the existence of opaque, and from that 
come to the conclusion that the abstract process author actually meant 
to say they would do something with the message?

I believe the answer is no, it is not reasonable. If someone writes an 
abstract process and includes an explicit empty, when they had recourse 
to opaque, then they should mean they just want empty. If they mean 
'empty and something else' then they should have included an explicit 
opaque in order to make their meaning clear. That is the whole point of 
having opaque. It makes it possible to disambiguate exactly this type of 
scenario.

We could, of course, come up with some kind of format that says 'only 
these activities and no others may be included'. That would really make 
things clear but I think it may make things a little too clear. A 
certain level of ambiguity is useful in abstract processes.

For example, the partner who sent the previous abstract process may 
actually have code in the event handler that does things like log the 
incoming message. But that has nothing to do with the externally visible 
behavior and so there is no reason to describe it in the abstract 
process. From the perspective of the person trying to interoperate with 
the system described by the abstract process all that is really 
important is that if they send the specified event nothing will result 
that has any relevance to the business process underway between the two 
parties which is why the single empty activity was specified. It is this 
type of flexibility that I mean by saying that a certain level of 
ambiguity is useful in abstract processes.

I think opaque hits the right level of ambiguity but I fully appreciate 
that this is a matter of taste.

What am I sure of, as I explore in detail in 
<http://lists.oasis-open.org/archives/wsbpel/200404/msg00052.html>, is 
that without opaque the meaning of empty in a situation such as the one 
described above is hopelessly ambiguous and no reasonable level of 
interpretation can make it less so.

		Yaron



Assaf Arkin wrote:

> 
>> Opaque is a very straight forward statement - I am not telling you 
>> what happens in this part of the code.
>>
>> This means that an opaque could be replaced with any possible code 
>> including but certainly not limited to 'empty'.
> 
> 
> But by definition, 'I am not telling you what happens in this part of 
> the [process]' is a possibility anywhere within the abstract, right? Any 
> additional implementation details could be inserted anywhere, since we 
> don't specify that this is precluded?
> 
> Unless you have a way to constrain the implementation against the 
> abstract, the following three are sematically identical and should be 
> interpreted the same way:
> 
> receive
> opaque
> opaque
> reply
> 
> receive
> opaque
> reply
> 
> receive
> reply
> 
> The only case where 'opaque' would actually say something meaningful is 
> where you are required to include an activity but have nothing to say, 
> for example, inside an event handler. The 'empty' activity exists for 
> that purpose. So semantically, they both do the same thing.
> 
> I am ignoring the English meaning of the name used for the activity. I'd 
> favor solving confusing by say picking a different name for the activity 
> rather than adding another one, or maybe managing without either one.
> 
> Assaf
> 
>