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

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

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

+1
Although we do need to clarify that 'contribution context' means the 
"home" contribution + location pointed to by the import stmt on a per NS 
basis.
This means that the import stmt pulls in the location only for the NS 
that the /import/@namespace attribute points to (not everything that is 
exported by the pointed contribution).
I assume this is what you meant as well.

> ·         If import/@location refers to a contribution, the identified 
> contribution MUST export the namespace that is being imported.
> 

One of the problems with the import statement as we have defined it is 
that it does not differentiate between different artifact types. For 
example, a WSDL, XSD, SCA composite can use the same namespace. In fact, 
a lot of folks do use the same NS for XSD and WSDL. Further complicating 
this is the fact that an XSD can be inlined within a WSDL and the 
WSDL/XSD don't have to have the same NS. I don't know how to solve the 
latter problem, but for the former either we say that we don't 
differentiate between artifact types (status quo with some added text 
explaining this -- you get everything) or we add another optional 
attribute to the import/export specifying the artifact type.

The location attribute for <import> is not restricted to a contribution, 
if this is kept as is I think this would obviate a need for scaLocation.

There was a opinion expressed (I forget who it was) that all the 
artifacts needed by the deployment must be available in the 
"contribution context". I don't believe we should say that. An 
implementation should be allowed to have predefined artifacts or well 
known artifacts made available to all contributions.

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