OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 107 - Opacity and the meaning of nothingness in abstract processes


I agree with Frank on this.  I want to be able to specify

	Send partnerLink=A

Without saying that the inputVariable is opaque.  Basically, abstract
processes should be schematic.  The fact that you have "abstract" in the
process element alerts you to the schematic nature. As Frank says,
otherwise you have to mimic too much of an executable structure and it
takes away the ease of creation and understanding of the interface like
behavior.

Abstract processes will in any case be human-validated artifacts since
they cannot be tested in the normal sense.  So the difference between an
intentional omission and an error is less of a worry to me.

Satish

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Tuesday, March 23, 2004 3:35 PM
To: Frank Leymann
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 107 - Opacity and the meaning of
nothingness in abstract processes

I think it's a fair question - do we put the burden of making sure an 
abstract process is reasonably specified on the abstract process 
validator or on the person who is trying to read and understand the 
abstract process?

While I agree that the restrictions I propose would make the abstract 
process validator more complex I think it is a reasonable trade off as I

  believe that putting the burden on people to be able to properly 
interpret the difference between an intentional omission and an error is

too much.

In any case I believe that this is very much a judgment call and I am 
open to changing my mind. I look forward to the discussion in Germany.

	Yaron

Frank Leymann wrote:

> 
> 
> 
> I agree on #1, I have to think about #2,  I don't think that we should
go
> towards #3.
> 
> Why would you enforce an opaque start activity in your example? What
will
> break if we don't enforce this?
> 
> My gut feeling is that this will make specifying abstract processes
really
> complicate.  In order to check whether or not an abstract process may
> result in a legal executable process we would also have to introduce
some
> sort of opaque join conditions, maybe opaque links etc..  Somehow, the
> modeler will either have to think about a set of possible alternative
> executable processes and abstract them accordingly to result in
flexibility
> at an implementers side (highly non-trivial), or would significantly
reduce
> alternatives, i.e. nearly prescribing an executable process, thus
reducing
> flexibility of implementing an abstract process (i.e. an "interface").
> 
> 
> 
> Regards,
> Frank
> 
> 
> 
> 
> 
> 
> 
> Please respond to ygoland@bea.com
> 
> To:    Frank Leymann/Germany/IBM@IBMDE
> cc:    wsbpel@lists.oasis-open.org
> Subject:    Re: [wsbpel] Issue - 107 - Opacity and the meaning of
>        nothingness in abstract processes
> 
> 
> I have three goals:
> 
> #1 - To introduce both an <opaque> activity.
> 
> #2 - To introduce a reserved opaque value for use in BPEL attributes
> that don't need to be specified in an abstract process. E.g. <receive
> variable="bpel:opaque" .../>.
> 
> #3 - To make it illegal to specify an abstract BPEL whose structure
> would not be legal in an executable BPEL unless an <opaque> activity
or
> opaque attribute is used.
> 
> So, for example, it would be illegal to create an abstract process
with
> no start activities unless an <opaque> activity was used as a place
> holder at the start of the process. It would also be illegal to
specify
> an operation and leaves off a variable attribute, one would have to
> include the attribute but could use the specially reserved opaque
> attribute value.
> 
> This doesn't stop anyone however in leaving out details that don't
> result in an illegal BPEL structure. For example, imagine I have the
> following BPEL executable process:
> 
> process
>     ...
>     sequence
>        ...
>        assign
>        receive
>        reply
>        ...
> 
> It turns out that the assign is just some internal fix up and really
> isn't relevant to the definition of an abstract version of the
process.
> So when I define the abstract process I just specify:
> 
> process
>     ...
>     sequence
>        ...
>        receive
>        reply
>        ...
> 
> The resulting structure is legal so there is no need to use <opaque>.
As
> you point out, however, one might want to use <opaque> if one
explicitly
> wanted to point out 'hey, put something here'.
> 
>              Make sense?
> 
>                          Thanks,
> 
>                                      Yaron
> 
>  >
>  >
>  >
>  > We need both, i.e. we should not enforce "consistent usage" of the
> implicit
>  > or explicit mechanism.
>  >
>  > (1) Sometimes you want to hide details of on internal process; even
that
>  > fact that "something happens" between two activities in the
abstract
>  > process.  Thus, we need implicit.
>  >
>  > (2) The explicit is not only needed for "error detection" but also
for
>  > "templating" of process models.
>  >
>  > Regards,
>  > Frank
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > Please respond to wsbpel@lists.oasis-open.org
>  >
>  > To:    wsbpel@lists.oasis-open.org
>  > cc:
>  > Subject:    [wsbpel] Issue - 107 - Opacity and the meaning of
nothingness
>  >        in abstract processes
>  >
>  >
>  > This issue has been added to the wsbpel issue list. The issues list
is
>  > posted as a Technical Committee document to the OASIS WSBPEL TC
pages on
> a
>  > regular basis. The current edition, as a TC document, is the most
recent
>  > document with the title in the "Issues" folder of the WSBPEL TC
document
>  > list - the next posting will include this issue. The list editor's
> working
>  > copy, which will normally include an issue when it is announced, is
>  > available at this constant URL.
>  > Issue - 107 - Opacity and the meaning of nothingness in abstract
> processes
>  >
>  >
>  > Status: open
>  > Area: Abstract processes
>  > Date added: 18 Mar 2004
>  > Submitter: Yaron Y. Goland
>  > Date submitted: 18 March 2004
>  > Description: The design of abstract processes requires the ability
to
> omit
>  > information that is not relevant to the abstract process's design.
There
>  > are two general strategies for omitting information - implicit and
>  > explicit.
>  >
>  >
>  > An example of implicitly hiding data is the way that abstract
processes
>  > deal with some of the variables on message operations. If one
doesn't
> want
>  > to specify where a message is recorded on a receive then one may
simply
>  > leave off the variable attribute.
>  >
>  >
>  > An example of explicitly hiding data would be introducing something
like
> an
>  > <opaque> activity. For example, imagine that one is defining an
abstract
>  > process and the start activities of the abstract process are to be
> omitted
>  > since they are not relevant to the functionality the abstract
process is
>  > describing. In that case one could start a process with an <opaque>
>  > activity. By putting in <opaque> one is explicitly communicating to
the
>  > reader of the abstract process 'There is something here but its
> definition
>  > is not relevant to the goal of the abstract process.'
>  >
>  >
>  > The advantage of explicit versus implicit hiding is in error
detection.
>  >
>  >
>  > In an implicit system where one simply leaves off variables or
omits
>  > activities there is no way to tell the difference between an error,
e.g.
>  > the person intended to include the variable or activity but forget
and
> true
>  > omission. This is a well known problem with treating the absence of
>  > information as information.
>  >
>  >
>  > In an explicit system where one would have <opaque> activities and
> special
>  > reserved bpel:opaque place holders for attributes there is no
possibility
>  > for confusion. If an opaque value is specified then one has an
> unambiguous
>  > declaration from the designer of the abstract process as to their
>  > intention.
>  >
>  >
>  > The issue before the group is - should we consistently use an
implicit or
>  > explicit omission mechanism for specifying when information has
been
>  > intentionally omitted in an abstract process?
>  > Changes: 18 Mar 2004 - new issue
>  >
>  >
>  >
>  > To comment on this issue, please follow-up to this announcement on
the
>  > wsbpel@lists.oasis-open.org list (replying to this message should
>  > automatically send your message to that list), or ensure the
subject line
>  > as you send it starts "Issue - 107 - [anything]" or is a reply to
such a
>  > message.
>  >
>  >
>  > To add a new issue, see the issues procedures document (but the
address
> for
>  > new issue submission is the sender of this announcement).
>  >
>  >
>  > 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
> 
>  > .
>  >
>  >
>  >
>  >
>  > 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
> .
>  >
> 
> 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
> .
> 
> 
> 
> 
> 
> 
> 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.
> 

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]