Re: [wsbpel] Re: [Fwd: Re: [wsbpel] abstract process strawman]

[rkhalaf <rkhalaf@watson.ibm.com>]

Hi Danny,

This is a bit long - but the pieces only make sense when taking in the 
whole so please don't panic on a sentence or two alone :)

I mean the behavior that whoever gets the file cares about (read on, 
this sentence is vague on its own!). I don't mean by publicly visible 
that it's pieces of a process you can "look-at/download", but it's the 
part of the behavior of the stuff on the partnerLinks that I want to 
show you. This behavior of the parts I *do* show you should be 
well-formed  and coherent in itself ( i try to reflect that  in the 
proposal ).

**(ASIDE: Now to move beyond that and explain how that gives a 
consistent view I will make some assumptions of how the rest of the 
stuff on abstract processes can create this. People may disagree here, 
and the specifics will be resolved in the rest of the issues. This is 
for clarification of  what *I* really think - and is done by what's in 
the bullets of the proposal (which are in turn based on 
spec+opaque-activities). However, the bullets give ways out for other 
issues to change this so people don't have to stick to this (ex: 
"currently", ref to 99 in (C), ref to 107 in (E)). Note that in this 
discussion I'm not saying anything about the possibility to have a 
superset syntax-wise as some people have asked for. )**

Taking the abstract process on its own,  you can explicitly hide stuff 
with opaque or "omission just for shorthand" (example: missing variable 
<=> var=new var; var:=opaque;invoke(var)). This is drastically different 
from having  receive with no reply or invoke with no operation. Note 
that what you get now is that you understand exactly what the things 
that are shown to you do because:
- each thing is semantically complete (even w/ dropping variables.. see 
the shorthand) and
- the whole is consistent (ex: can't compensate a non-existent scope, if 
we allow getVariable data then you can't refer to a variable that's not 
defined, etc) and
-you know that there could be (and where) non-determinism in branching 
because it's based on data that's hidden or that you don't have.

The second important point is that it still allows the complementary 
"the-parts-I-don't-want-to-show-you" to be  based on the use case: could 
be lots of stuff but absolutely nothing "observable" all over the place 
and maybe preserving some property like observable conformance, filling 
a mix of observable/nonobservable things in the opaques place-holders, 
nothing at all, etc...

For example:
I can have just partnerLinks and one big opaque activity as my full 
abstract process. On the other hand, I can't have an invoke that talks 
about an undefined partnerLink, etc..

If you're still reading ;) , here's my explanation now of Yaron's examples:
Yaron's example on 82 (using query) may be allowed depending on wether 
we decide to allow getVariableData and query to be used. However, it 
does not contradict with the above explanations. Yaron's example on 107 
however, doesn't have operations and so doesn't fall under this because 
the description of the behavior of the invoke activity is incomplete 
(having an operation="opaque" gives you a syntactic operation - but the 
activity effectively has no operation right..)

I think this is the most consistent and useful view that can handle the 
use cases without introducing infinite flexibility that would lead us 
down the path to random snippets and trying to draw a line between just 
how much stuff can you drop before you get junk. This should also 
clarify my view on the other abstract process issues. I am, however, 
aware that depending on where those go (ex: 107) this view could be 
affected.

Regards,
Rania


Danny van der Rijn wrote:
> rania-
> 
> if by "publically visible behavior" you mean that if i publish my BPEL 
> file ("publicly visible") then i would agree.  but i think that it's a 
> somewhat useless definition at that point.
> my understanding of "publicly visible behavior" was that it was the 
> behavior that one can observe from an engine that is running stuff that 
> i can't look at.  more like the definitions leading up to the observable 
> conformance definitions.  in which case i disagree that this covers the 
> templating (bad word in this case, maybe?) area of use cases that i 
> would submit that yaron's example falls into.
> 
> danny
> 
> rkhalaf wrote:
> 
>> Hi,
>>
>> I think that "publicly visible behavior" covers both templating and 
>> observable stuff because it's the behavior that you make visible to 
>> the recipient of the file. In case of templating, that is the 
>> template-filling-person and he/she sees the part of the behavior that 
>> is expressed in this process. In the case of giving a description of 
>> your behavior to a third party (to implement, or to know how to 
>> interact with you etc) it's a complete description of what you will be 
>> doing.
>>
>> Perhaps later in the spec we can have a use cases section similar to 
>> the one in the circulated doc with templating and observable behavior 
>> scenarios explicitly mentioned. Could also be touched on in 107, to 
>> say "for example, in a templating scenario one would use opaque as an 
>> explicit fill point" .
>>
>> -Rania
>>
>> Nickolas Kavantzas wrote:
>>
>>> Satish Thatte wrote:
>>>
>>>
>>>> Danny,
>>>>
>>>> I think your description of the challenge response metaphor for 
>>>> proving conformance represents a misunderstanding of the intent 
>>>> (brute force search among lots of randomly generated possibilities 
>>>> was not the idea).  Moreover, the templating case is explicitly 
>>>> supported in Rania's paper I believe.  Rania and I will address that 
>>>> separately.
>>>
>>>
>>>
>>>
>>> There are two definitions of an abstract process in the first page of 
>>> the document.
>>>
>>> The first one is the first paragraph of the doc.
>>>
>>> The second one is A on the 'Semantics of AbsProcesses' section.
>>> I am assuming that this is a potential use of an Abstract Process. So 
>>> the text should then be:
>>> A. An abstract process may describe the publicly visible behavior of 
>>> the services exposed by the process....(rest of the text in A)
>>>
>>> The other potential use of an Abstract Process is for 'templating' 
>>> and I would assume that this should be included in
>>> this section too as B (put the text for that).
>>>
>>>
>>> -- 
>>> Nick
>>>
>>>
>>>>
>>>> But I am very curious about the specific details your customers 
>>>> would want to omit while still preserving the meaningfulness of the 
>>>> "process IP" they would be selling.  Do you have a list of features 
>>>> that ought to be allowed for omission?
>>>>
>>>> Satish
>>>>
>>>> ________________________________
>>>>
>>>> From: Danny van der Rijn [mailto:dannyv@tibco.com]
>>>> Sent: Thu 9/23/2004 8:57 PM
>>>> To: rkhalaf@watson.ibm.com; wsbpel@lists.oasis-open.org; 
>>>> wsbpel-abstract@lists.oasis-open.org
>>>> Subject: [Fwd: Re: [wsbpel] abstract process strawman]
>>>>
>>>> you don't see that every day.  i remembered the attachment, but 
>>>> forgot the inline text.
>>>>
>>>> the enclosed document is my quick reaction to the abstract 
>>>> presentation from yesterday.
>>>>
>>>> -------- Original Message --------
>>>> Subject:        Re: [wsbpel] abstract process strawman
>>>> Date:   Thu, 23 Sep 2004 20:52:21 -0700
>>>> From:   Danny van der Rijn <dannyv@tibco.com> <mailto:dannyv@tibco.com>
>>>> To:     rkhalaf@watson.ibm.com
>>>> CC:     wsbpel@lists.oasis-open.org, 
>>>> wsbpel-abstract@lists.oasis-open.org
>>>> References:     <41507291.3010200@watson.ibm.com> 
>>>> <mailto:41507291.3010200@watson.ibm.com>
>>>>
>>>> rkhalaf wrote:
>>>>
>>>>        Hi everyone,
>>>>
>>>>        As promised, here is the abstract process strawman document I 
>>>> have been putting together. This work aspired to define a consistent 
>>>> view of abstract processes  and their use as the basis for 
>>>> continuted discussion and concrete proposals/resolutions.
>>>>
>>>>        According to the Agenda, tomorrow or Thursday will be when 
>>>> the abstract proc stuff will be discussed.
>>>>
>>>>        Regards,
>>>>        Rania
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>>        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. 
>>>>
>>>>
>>>> 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. 
>>>>
>>>
>>>
>>>
>>
>>
>>
>> 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. 
>>
>>
>>