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