[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bpel] Issue 2 - Does the spec allow a componentType side file?
One comment inline ... > -----Original Message----- > From: Michael Rowley [mailto:mrowley@bea.com] > Sent: Thursday, Jan 10, 2008 9:37 AM > To: Anish Karmarkar > Cc: OASIS BPEL > Subject: RE: [sca-bpel] Issue 2 - Does the spec allow a > componentType side file? > > > > The assembly spec currently says: "The location of the component type > file depends on the type of the component implementation: it is > described in the respective client and implementation model > specification for the implementation type." > > In my opinion, the SCA BPEL spec should define _how_ to find > a component > type side file for a BPEL process, rather than _where_ to find them. > This is based on the fact that we don't typically use > locations to refer > to XML definitions. <implementation.bpel> and > <implementation.componentType> both refer to their implementations by > QName, not by a location. > > Therefore, I think that we should say that SCA finds the ComponentType > for a BPEL process named "foo:bar" by finding any > ComponentType document > that has <implementation.bpel qname="foo:bar">, wherever it might be > within the contribution. I think it is optional for a ComponentType side file to include an <implementation.xxx ...> element, which makes me wonder if the proposed mechanism for 'how' to find a side file will always work. -- Sanjay > > Michael > > > -----Original Message----- > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > Sent: Thursday, November 01, 2007 2:45 AM > To: Michael Rowley > Cc: OASIS BPEL > Subject: Re: [sca-bpel] Issue 2 - Does the spec allow a componentType > side file? > > Comments inlined below as [AK: inline]. > > -Anish > -- > > Michael Rowley wrote: > > > > > > [MR: inline] > > > > > > > > > > > > -----Original Message----- > > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > > Sent: Friday, October 19, 2007 3:48 PM > > To: Michael Rowley > > Cc: OASIS BPEL > > Subject: Re: [sca-bpel] Issue 2 - Does the spec allow a > componentType > > side file? > > > > > > > > Michael Rowley wrote: > > > >> One thing a side file might be used for is to override the default > > > >> algorithm that decides on which partnerlinks are services > and which > are > > > >> references. Do you agree? > > > > > > > > Yes I do agree. That is why I raised the issue. > > > > If the side file is present then the default does not apply. > > > > > > > > [MR: Unfortunately, the assembly spec says that "Component type > > information found in the component type file must be compatible with > the > > equivalent information found from inspection of the implementation." > If > > we "override the default", then we are not compatible with the > > information found from inspection :-(.] > > > > [AK: I view what is said in the assumbly spec differently. The > information found in the BPEL process must be compatible with > the info > in the CT side file. So, if there are sca extensions in the > BPEL process > > (eg: sca:property attribute) then that must be compatible > with what is > in the side file. Such a BPEL process is SCA aware. I would > image that > we would have extensions for everything that one could specify in the > sidefile. I don't think defaults should apply to sca-aware processes. > Otherwise there is no way to override defaults. If the process is not > sca-aware and there is no side file than the defaults kick in. If the > process is not sca-aware and there is side file, then the side file > rules.] > > > > > > >> If so, I think the side file would have to > > > >> have a way of pointing from a service or reference > declaration to a > > > >> partnerlink. > > > > > > > > To do so would require extending the <componentType> defined by > > > > assembly. We have already done that in section 2 by introducing > > > > <implementation.bpel process="xs:QName" .../>. > > > > > > > > [MR: I think this may have been a mistake in a recent editing pass. > In > > the 1.0 version of these documents, it showed a <component> element, > not > > a <componentType> element.] > > [AK: Ok, I'll raise a separate issue for this] > > > > > > > > > ----- sidebar ----- > > > > BTW, a separate issue: why is that needed? The other C&Is do not do > > > > this. Furthermore, the assembly spec says: > > > > "A component type file has the same name as the implementation file > but > > > > has the extension ".componentType". The component type is > defined by a > > > > componentType element in the file. The location of the > component type > > > > file depends on the type of the component implementation: it is > > > > described in the respective client and implementation model > > > > specification for the implementation type." > > > > So what we need is is not an <implementation.bpel> element in the > > > > componentType file, but the location of the componentType file (or > raise > > > > an issue against the assembly spec). > > > > ----- side bar ----- > > > > > > > > So your suggestion would be to extend /componentType/service and > > > > /componentType/reference elements to include the partnerlink. Right? > > > > > > > > [MR: A reference to a partnerlink, yes.] > > > > > > > > A subissue (or perhaps a different issue) related to this > is: we would > > > > need additional SCA BPEL extensions in section 3 to mark > services and > > > > references (in addition to properties and multirefs). This > would allow > > > > one to specify equivalent information in a side file or in the BPEL > > > > process itself (similar to what Java has done). I.e., side > file would > be > > > > optional as far as provided functionality goes. > > > > > > > > [MR: I agree] > > > > [AK: ok, will raise a separate issue for this] > > > > > > > Yet another subissue is: if my BPEL process is SCA aware, > for example > it > > > > has sca:property or sca:multiReference in it (and potentially > > > > sca:service, sca:reference elements if we add it -- see subissue > above), > > > > do the default rules still apply? > > > > > > > > [MR: I don't understand. The default rules would be for the > > partnerlinks that are not so marked.] > > > > [AK: if my process is sca-aware I can mark all the > partnerlinks that I > want to expose as services/references. I don't need > defaulting. I want > to have control. Default should apply when there is no SCA-specific > mark-up and no side file. Otherwise I don't have a way to say > -- don't > expose this partner-link as an sca ref or service] > > -Anish > -- > > > > > > > Michael > > > > > > > > Comments? > > > > > > > > -Anish > > > > -- > > > > > > > >> > > > >> Michael > > > >> > > > >> -----Original Message----- > > > >> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > > > >> Sent: Thursday, October 18, 2007 1:58 AM > > > >> To: OASIS BPEL > > > >> Subject: Re: [sca-bpel] Issue 2 - Does the spec allow a > componentType > > > >> side file? > > > >> > > > >> Proposed resolution: > > > >> > > > >> In section 2, line 194 add -- > > > >> It is also possible to have a component type file that is > associated > > > >> with the BPEL component implementation. When such a component type > file > > > >> is present, as specified in [SCA-Assembly], it provides component > type > > > >> information in addition to what is found by introspection. > > > >> > > > >> > > > >> Do we need to define compatibility between what is found by > > > >> introspection and what is available in the side file? > > > >> > > > >> Comments? > > > >> > > > >> -Anish > > > >> -- > > > >> > > > >> Alex Yiu wrote: > > > >> > Issue entered: > > > >> > http://www.osoa.org/jira/browse/BPEL-2 > > > >> > > > > >> > > > > >> > > > > >> > Anish Karmarkar wrote: > > > >> >> Title: Does the spec allow a componentType side file > > > >> >> > > > >> >> Target: BPEL C&I spec > > > >> >> > > > >> >> Description: The spec does not say whether a componentType side > file > > > >> >> is allowed. If it is allowed then it should override the default > > > >> rules > > > >> >> specified in the spec. > > > >> >> > > > >> >> Proposal: > > > >> >> <none> > > > >> > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all > your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]