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