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

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

Michael Rowley wrote:
> 
> The assembly spec currently says: "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."
> 
> In my opinion, the SCA BPEL spec should define _how_ to find a component
> type side file for a BPEL process, rather than _where_ to find them.
> This is based on the fact that we don't typically use locations to refer
> to XML definitions.  <implementation.bpel> and
> <implementation.componentType> both refer to their implementations by
> QName, not by a location.
> 
> Therefore, I think that we should say that SCA finds the ComponentType
> for a BPEL process named "foo:bar" by finding any ComponentType document
> that has <implementation.bpel qname="foo:bar">, wherever it might be
> within the contribution.
> 

That would mean that the implementation and CT side file can be 
decoupled with a potential for many side files to exist for the same 
implementation. This would mean that which CT side file gets picked up 
depends on the resolution mechanism used by the implementation. This 
will give rise to portability problems.

The Java C&I says:

"A component type can optionally be specified in a side file. The 
component type side file is found with the same classloader that loaded 
the Java class. The side file must be located in a directory that 
corresponds to the namespace of the implementation and have the same 
name as the Java class, but with a .componentType extension instead of 
the .class extension."

Why can't we have a similar rule for BPEL: that it be located in same 
directory as the bpel file.

Since we'll be discussing this issue on the call today, I thought I'll 
list the subissues that I see within issue 2:

1) how/where the CT side file is found/located
2) extend the /componentType/service and componentType/reference syntax 
to include partnerlinks (providing the ability to override defaults)
3) compatibility between CT side file and introspected CT. This is more 
of an assembly issue, but we need to agree on how defaults are treated.
4) Allow the same info to be specified in a side file as well as 
inlined. This would require new BPEL extensions for service/refs a la 
multirefs and properties.

-Anish
--

<snip/>