[MR: inline]
-----Original Message-----
From: Anish Karmarkar [mailto:]
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 :-(.]
> 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:]
> 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>
>>
