Re: FW: [wsbpel-abstract] RE: Strawman for discussion

[Diane Jordan <drj@us.ibm.com>]

Rania,
I think the problem you were having
posting to the list should be solved (I also don't think you were getting
the email so you might want to look at the archives for the subgroup).
 I apologize - it was due to an oversight on the part of the chair!
  

Regards, Diane
IBM  Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709

"Trickovic, Ivana" <ivana.trickovic@sap.com>

08/27/2004 10:22 AM

To	"'wsbpel-abstract@lists.oasis-open.org'" <wsbpel-abstract@lists.oasis-open.org>
cc
Subject	FW: [wsbpel-abstract] RE: Strawman for discussion

fyi

-----Original Message-----
From: Rania Khalaf [mailto:rkhalaf@us.ibm.com]
Sent: Freitag, 27. August 2004 16:02
To: Trickovic, Ivana
Cc: 'Nickolas Kavantzas'; 'Satish Thatte'
Subject: RE: [wsbpel-abstract] RE: Strawman for discussion






Hi all,

I'm having trouble posting to the list :(  I get :
"Sorry, only contributing members may post. If you are a contributing
member, please forward this message to administration@lists.oasis-open.org
(#5.7.2)"

But here's my recap of the mail I had sent that Nick was referring to.
Feel
free to forward to the abs proc list. The frequency/flexibility to using
opacity is not  mentioned in Satish's doc so I see this mail as more
of
food-for-thought than an addition to the doc. I think it's confusing to
the
doc but nice clarification.

---------
To understand how abstract processes are used and how one would use
opacity:

There are three concrete use cases that drove the patterns that you see
in
the doc, and are seen as examples of them:

A: A company has an exec proc Pe and wants to provide an abstract one Px
to clients/partners.
B: A company provides an abstract process for its partners to implement
if
they want to do business with it.
C: A company makes an abstract process for a certain proc  that is
then
refined down to an exec by someone within the company with more detailed
expertise.

In all of the above, you may use opaque stuff but you will use more/less
in
some than in others.

In A, an example of opaque stuff is to do a join that's not properly
reflected by an "empty" or to hide a choice based on an internal
algorithm
for example but this is not mandatory and will be less frequent than in
B
and C. Omission will be the most common thing in A.

In B, one has no control over what the partner/client does.

It is important to understand that opaque is not the only extension point.
These are mandatory extension points but not (necessarily) the only ones.
In C, extending at the opaques is mandatory, but one may also want to
extend elsewhere. However, tooling/design could want to restrict to only
extending opaques.

In summary: using abstract BPEL, you can go from no opaque to lots of
opaque, from complete flex to strict enforcement. More of a spectrum whose
main points are: No opaque, all flex(such as some cases in A), Opaque with
flex (such as example B), Opaque varying (possibly none) flex (such as
example C).

To feel like I fit in NYC, I attempt to see whether I have any consulting
skills by making a matrix to illustrate this. The examples on the different
quadrants. From that, nothing comes to mind  for the bottom left corner.
If
you don't have opaques and you don't have flexibility you're nearly at
an
executable I suppose. Perhaps the zero point there is an executable proc.

Flex(Diff bet Impl and Abs)
|
|          A          
                     B
|
|
|                    
                     
  C
|_________________________
                    
                Num of Opaques

-----------------------------------------------
Rania Y. Khalaf

Software Engineer
Component Systems Group
IBM TJ Watson Research Center
Hawthorne, NY
Tel: (914) 784-7603
http://www.research.ibm.com/people/r/rkhalaf/