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