OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Title: Message
 
Michael,
 
Are you asserting that since we have the concept of 'installed contribution' for scoping the resolution of a QName, no additional information should be required to resolve a QName to its definition?
 
I guess Henning's point is that although no additional information may be strictly necessary, a lot of performance and ambiguity concerns would be addressed by being explicit about where in the contribution any given QName should be resolved (e.g. via scaLocation). I would be interested to hear opinions about whether these concerns are valid or not?
 
-- Sanjay


From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Tuesday, Feb 05, 2008 12: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

 

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]