[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?
|
[MR: inline] -----Original Message----- 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 :-(.] > 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.] ----- 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] 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.] 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]