Re: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified

[Scott Vorthmann <scottv@tibco.com>]

As promised, I'm including the text of Henning's issue 24 discussion  
and proposal (since we closed 24 as a duplicate of 8 and 17b).

I completely concur with Henning.  Describing inclusion in this way  
achieves its goal, and makes moot all questions of QName (and other  
name!) resolution.  I would, however, propose alternative text for the  
description of composite include, and I'll do that on a subsequent  
email.

http://www.osoa.org/jira/browse/ASSEMBLY-24

Scott

---- from issue 24:


On the one hand SCDL artefacts may be re-used across contributions  
(see SCA deployment) and SCA's domain concept relies on inclusion to  
implement a cross-contribution assembly mechanism, on the other hand  
many SCDL declarations refer to artefacts that may not be resolvable  
within the includer's resolution scope.

For example, implementation type declarations such as  
<implementation.java/>, <implementation.bpel/>, <implementation.spring/ 
 > refer to artefacts such as Java classes, bpel process descriptions,  
and application context XML files, that may not resolvable across  
contributions and much less on the domain.

PROPOSAL:

Describe sca:include over the assembly model of SCA rather than a  
textual operation - similarly to how <implementation.composite/> is  
described today.

For example (simplified and using terminology that requires more  
explanation)

All services, references, properties, and component elements of the  
included composite lead to services, references, properties, and  
component elements by the same name (resp.) in the including  
composite. Any other content of the included composite is ignored.  
Resulting component elements are opaque to the includer, that is, all  
artefact resolution required to evaluate the component declaration  
must be performed in the resolution scope of the included composite.  
This algorithm is recursively applied in a depth-first traversal.


On Feb 19, 2008, at 8:50 AM, Michael Rowley wrote:

>
> I just want to reiterate points made elsewhere on this thread, a  
> little closer to the original proposal text.  The following points  
> should be made in addition to the points made in this proposal text:
> ·         All SCA definitions (composites, binding types, intents,  
> etc) should all be unique within a single “contribution context”,  
> which is a contribution and the exported definitions of all of its  
> dependent contributions.
> ·         If import/@location refers to a contribution, the  
> identified contribution MUST export the namespace that is being  
> imported.
> ·         When an exported definition is imported by another  
> contribution, any QNames that exist in the definition of the  
> exported definition will be resolved in the context of the installed  
> contribution in which the export occurs (not in the context of the  
> importing contribution).
>
> Note that this last point was discussed on the thread discussing the  
> resolution to issue 17, but on today’s call, we agreed to move the  
> discussion to the topic of issue 8.  I’ll also note that this rule  
> is contentious.  Others believe it should be the opposite.
>
> Michael
>
> From: Michael Rowley [mailto:mrowley@bea.com]
> Sent: Tuesday, February 05, 2008 3:33 PM
> To: sca-assembly@lists.oasis-open.org
> Subject: RE: [sca-assembly] ISSUE 8: SCDL artifact resolution  
> underspecified
>
>
> The current specification says a few things about resolving QNames  
> to SCDL artifacts.  One of the most explicit is the following:
> 12. 6.4 get QName Definition
> In order to make sense of the domain-level composite (as returned by  
> get Domain-Level Composite), it must be possible to get the  
> definitions for named artifacts in the included composites.  This  
> functionality takes the supplied URI of an installed contribution  
> (which provides the context), a supplied qualified name of a  
> definition to look up, and a supplied symbol space (as a QName, eg  
> wsdl:PortType).  The result is a single definition, in whatever form  
> is appropriate for that definition type.
>
> Note that this, like all the other domain-level operations, is a  
> conceptual operation.  Its capabilities should exist in some form,  
> but not necessarily as a service operation with exactly this  
> signature.
>
>
> The sentence that I’ve made bold is the most relevant.  However, the  
> spec does not say what QNames that you should be able to find the  
> definition for (i.e. when it should return non-null).  I believe we  
> should add the following sentence to this section:
>
> Any XML definition that is present in the identified contribution or  
> is one of the exported definitions from its dependent contributions  
> is available in this way.
>
> Another section that deals with artifact resolution is the following  
> (included here, so you don’t have to fish around the spec):
>
> 12.3 Installed Contribution
> As noted in the section above, the contents of a contribution should  
> not need to be modified in order to install and use it within a  
> domain.  An installed contribution is a contribution with all of the  
> associated information necessary in order to execute deployable  
> composites within the contribution.
>
> An installed contribution is made up of the following things:
>
> ·         Contribution Packaging – the contribution that will be  
> used as the starting point for resolving all references
>
> ·         Contribution base URI
>
> ·         Dependent contributions: a set of snapshots of other  
> contributions that are used to resolve the import statements from  
> the root composite and from other dependent contributions
>
> o         Dependent contributions may or may not be shared with  
> other installed contributions.
>
> o         When the snapshot of any contribution is taken is  
> implementation defined, ranging from the time the contribution is  
> installed to the time of execution
>
> ·         Deployment-time composites.
> These are composites that are added into an installed contribution  
> after it has been deployed.  This makes it possible to provide final  
> configuration and access to implementations within a contribution  
> without having to modify the contribution.  These are optional, as  
> composites that already exist within the contribution may also be  
> used for deployment.
>
>
>
> Installed contributions provide a context in which to resolve  
> qualified names (e.g. QNames in XML, fully qualified class names in  
> Java).
>
> If multiple dependent contributions have exported definitions with  
> conflicting qualified names, the algorithm used to determine the  
> qualified name to use is implementation dependent.  Implementations  
> of SCA may also generate an error if there are conflicting names.
>
>
> Again, I’ve put the most important sentence in bold.  For clarity,  
> we should add the following to the end of the section:
>
> If a qualified name is uniquely defined for a symbol space within an  
> installed contribution then no additional information SHOULD be  
> required in order to resolve that qualified name to its definition.
>
>
> I believe that the section titled “Artifact Resolution” can be  
> deleted, as I believe that everything that it says is already said  
> in the “Installed Contribution” section or the section titled “12.5  
> Use of Existing (non-SCA) Mechanisms for Resolving Artifacts”.
>
> RATIONALE:
>
> I believe that SCA should do whatever it can to simplify the life of  
> an application developer.  Unfortunately, many XML technologies have  
> complex QName resolution rules and as a result, the maintenance of  
> the many wsdlLocation, schemaLocation and similar attribute values  
> becomes untenable for the average application developers.
>
> One can see how the industry got into this situation.  The existing  
> XML specifications didn’t have anything like SCA’s concept of an  
> “installed contribution”, so they could not define a scope in which  
> logical QNames could uniquely resolve to definitions.  However, we  
> do have such a concept, and we should take advantage of it to make  
> life easier for our users.  They should be able to use logical names  
> only.  Physical names are brittle.  Finding things is what computers  
> are good at (and fast at).  Users shouldn’t have to.
>
> Naturally, we don’t live in isolation so we have to honor the XML  
> mechanisms that already exist.  And we do (in the section about  
> “Existing Mechanisms”).  But we can discourage their use within an  
> SCA domain, since we have a simpler alternative.
>
> Michael
>
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Monday, October 08, 2007 9:48 AM
> To: sca-assembly@lists.oasis-open.org
> Subject: [sca-assembly] ISSUE 8: SCDL artifact resolution  
> underspecified
>
> Logged: http://www.osoa.org/jira/browse/ASSEMBLY-8
> -----Original Message-----
> From: Blohm, Henning [mailto:henning.blohm@sap.com]
> Sent: Friday, October 05, 2007 8:01 PM
> To: sca-assembly@lists.oasis-open.org
> Subject: [sca-assembly] NEW ISSUE: SCDL artifact resolution  
> underspecified
> TARGET: Assembly specification, section "SCA Artifact  
> Resolution" (1.10.2.1)
>
> DESCRIPTION: Resolution of SCDL artifacts is currently specified  
> only as far as cross-contribution export/import is concerned. As far  
> as QName to SCDL artifact resolution within a contribution is  
> concerned the specification does not say what is the exact scope of  
> such resolution nor how to extend/modify that scope.
>
> Choosing the whole contribution as resolution scope may be  
> prohibitive considering that contributions may be large and  
> distributed (across different execution environments) so that deep  
> traversal of all contribution resources for scdl artifacts may  
> easily introduce a severe performance problem and easily get out of  
> control from a developer perspective.
>
> As an analogy, suppose the group would perceive a contribution  
> format that would encompass java ee applications together with OSGi  
> bundles. Chosing a contribution wide resolution scope would  
> correspond to chosing a contribution wide class loading scheme  
> (which I assume all agree is highly undesirable).
>
> On the other hand, if the resolution scope is not the whole  
> contribution, it is necessary to allow specification of locations  
> within a contribution.
>
> PROPOSAL:
>
> - use sca-contribution / import as a means to implement a namespace - 
> > location mapping also for contribution-local artifacts
>
> - support an scaLocation attribute to be used for namespace ->  
> location mapping from within SCDL artifacts
>