Subject: RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution]
Andrew, I believe your example falls into the (intended) "external behavior description" profile which forbids executable completions that add interactions along the partnerlinks in the abstract process since the intent of such an abstract process is to fully specify externally visible behavior. Satish -----Original Message----- From: rkhalaf [mailto:firstname.lastname@example.org] Sent: Tuesday, January 18, 2005 8:46 AM To: email@example.com Subject: Re: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution] forgot to do reply all. -------- Original Message -------- Subject: Re: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution Date: Tue, 18 Jan 2005 11:44:54 -0500 From: rkhalaf <firstname.lastname@example.org> Reply-To: email@example.com To: firstname.lastname@example.org References: <OF401503AA.EA54A512-ON85256F6C.006FAFE9-85256F81.005A9DEC@us.ibm.com> <email@example.com> Hi Andrew, I like to think of profiles as summarized by picking a point on each of the axes that were in my slides from the F2F. An abstract process belonging to a profile really defines a set of executables via these rules. Since exec bpel has full semantics, an abstract process belonging to a profile is completely understood on its own regardless of how it will be used at "runtime"(to generate executables, to generate client stubs, to test compliance, for fill-in-the-blanks-templating, etc ...). For your scenario, your abstract processes must first belong to a profile. The profile would have governed the restrictions/syntax in their creation (example: limits opacity to everything but attributes), and explains the missing information by providing completion rules. (slide 1). The completion rules could be used by tools to aid in creating the executables (slide 2) and in monitoring (slide 3). I don't think the spec will go into the details of how to do that beyond what's above (think WSDL). Perhaps profiles can be allowed to also describe additional information relevant to their use case? Hope that helps, Rania firstname.lastname@example.org wrote: > Hello Colleagues: > > >>1 Every AP instance will always refer to a profile URI to >> >>>define its meaning but we leave it open at this time>whether the core AP definition is a profile. >> > >>2. The TC will rework the 1.1 AP definition into a >>profile with a defined URI. > > > I am unclear concerning how profiles are used. I have > included an abstract process use case scenario. The > scenario also illustrates how I believe abstract processes > can be used. How do profiles fit into this scenario? > > Cheers, > Andrew > > > ------------------------------------------------------------------------ > > 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.