Re: [sca-bpel] Issue 2 - Does the spec allow a componentType sidefile?

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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>
>>