[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Fwd: Re: [wsbpel] abstract process strawman]
There are actually two parts to Danny's concerns. One is simply that we should not focus solely on observable conformance. And as Rania and I clarified, this was not our intention either. The second part is the question of whether abstract processes have *any* syntactic validity constraints and what would such constraints be motivated by. Here Danny's notion is that abstract processes should have no syntactic constraints because at one extreme some people may want to use them just as intermediate forms for editing. My view is that regardless of the variations in the notion of conformance, abstract processes constrain the behavior of conformant executable realizations. They are not meant for arbitrary editing, otherwise they would not be worth talking about. And to constrain behavior meaningfully there are certain things that cannot be left out. For instance, web service interactions in abstract processes must specify the web service interfaces and operations concerned even though they may leave out private variables used in the data handling for those interactions, or the exact conditions that govern the choice of interaction. Variations of conformance notions may constrain visible interactions to, for instance, exactly those indicated by the abstract process, or at least those indicated by the abstract process. Such variation of interpretation is perfectly acceptable so long as it is clearly defined. My 2 cents. Satish -----Original Message----- From: Danny van der Rijn [mailto:dannyv@tibco.com] Sent: Monday, September 27, 2004 9:33 AM To: rkhalaf@watson.ibm.com Cc: Satish Thatte; wsbpel@lists.oasis-open.org Subject: Re: [Fwd: Re: [wsbpel] abstract process strawman] rania - while i understand the objection that you and satish have to my thoughts, i understand. i am just worried, as i attempted to say, that we are tailoring a syntax that serves an immature technology. rkhalaf wrote: > Hi Danny, > > Thanks for your doc. > > Regarding conformance, we make it very clear that there are many > different possible conformance relations that may define them in a > paraallel effort as you suggest - but if we have a good way to define > a useful one that covers important cases, I think it's useful to have > the definition there. If you look at the bottom of the doc you can see > that one of the issues was whether to allow one to relate two > processes together given a defined relation. This would be too early I > think for this version but it shows the direction of the thinking. > > The def is not supposed to yield an algorithm directly, but to clearly > and intuitively explain what this compliance def is checking for. The > algorithm one may use to check "observable compliance" should not a > brute force one from the def, and that's quite obvious to tell (you > could have infinitely many minimum-no-fault-...-completions). Also, > the definition is still being clarified. > > Also, the doc is clear that it allows many uses for abstract processes. > > Regarding partially defined processes as you describe them, my view is > like I explained at the F2F - which is pretty much what Satish's > e-mail says. I'm strongly against this because it hurts the > usefulness of abstract processes. > > regards, > Rania > > Danny van der Rijn wrote: > >> that is very close to the conclusion that i came to as well. except >> that i would prefer that different communities be able to define >> their own standard outside of the core spec. with conformance being >> one of those communities. i just don't get why conformance has >> special standing, especially given its infancy. >> >> Satish Thatte wrote: >> >>> What I heard before is that your customers want to omit anything ? >>> which is almost like an editor?s intermediate storage >>> representation. We don?t need to standardize that because it >>> doesn?t need to have any semantics beyond editing. >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> From: Danny van der Rijn [mailto:dannyv@tibco.com] >>> Sent: Friday, September 24, 2004 12:19 PM >>> To: Satish Thatte >>> Cc: wsbpel@lists.oasis-open.org >>> Subject: Re: [Fwd: Re: [wsbpel] abstract process strawman] >>> >>> >>> >>> that's what we're doing right now, isn't it? >>> >>> Satish Thatte wrote: >>> >>> So then please describe what you have in mind so we can see the precise >>> >>> differences. >>> >>> >>> >>> -----Original Message----- >>> >>> From: Danny van der Rijn [mailto:dannyv@tibco.com] >>> Sent: Friday, September 24, 2004 8:44 AM >>> >>> To: Satish Thatte; wsbpel@lists.oasis-open.org >>> <mailto:wsbpel@lists.oasis-open.org> >>> >>> Subject: Re: [Fwd: Re: [wsbpel] abstract process strawman] >>> >>> >>> >>> btw, the templating that was in the paper didn't really match the >>> templating that i'm describing which is why i called it out. >>> >>> >>> >>> Danny van der Rijn wrote: >>> >>> >>> >>> >>> >>>> i was hoping that i misunderstood the intent. i bothered to be so >>>> detailed so someone could point out the error in my misunderstanding. >>>> >>>> >>>> >>>> as far as a list of features, no i don't have one. they are just >>>> omitting what they please and providing what they find to be usefully >>>> portable. but a concrete example of that that i do know is that they >>>> are leaving out specifics of the WSDLs. "you receive an order here, >>>> and you send a confirmation response." that's all that you need to >>>> know at that point. not what a line item looks like. not even what >>>> an order looks like. >>>> >>>> >>>> >>>> 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. >>>>> >>>>> >>>>> >>>>> 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 <mailto:rkhalaf@watson.ibm.com>; >>>>> wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>; >>>>> wsbpel-abstract@lists.oasis-open.org >>>>> <mailto: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> >>>>> <mailto:dannyv@tibco.com> >>>>> To: rkhalaf@watson.ibm.com <mailto:rkhalaf@watson.ibm.com> >>>>> CC: wsbpel@lists.oasis-open.org >>>>> <mailto:wsbpel@lists.oasis-open.org>, >>>>> wsbpel-abstract@lists.oasis-open.org >>>>> <mailto:wsbpel-abstract@lists.oasis-open.org> >>>>> References: <41507291.3010200@watson.ibm.com> >>>>> <41507291.3010200@watson.ibm.com">mailto:41507291.3010200@watson.ibm.com> >>>>> <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_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]