[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]