[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified
I fully the support the spirit of simplicity you are expressing (no
surprise). XML resource resolution is completely out of hand in this
industry. We can (we are obligated IMO) use contributions to our advantage
to bring some sanity.
Section 12.2.1 "SCA Artifact resolution" [1] indicates there is an SCA
defined resolution mechanism (imports and exports). Are you objecting to
Henning's proposal for a scaLocation attribute (I don't understand
Henning's proposal)? Or are you objecting to the location attribute on the
import element?
Honestly, I've never quite gotten the point of Issue 8. My big concern in
artifact resolution are these vertical industry standard schemas which
don't comply with schema principles and rules....missing namespaces,
duplicate type names, etc. I presume these kinds of problems would be
overcome by the use of schemaLocation or wsdlLocation as described in
section 12.5 "Use of Existing Mechanisms for Resolving Artifacts" [1]. So
then the question is, are there other kinds of artifact resolution that we
need to consider? How about duplicate Java interfaces in the same
contribution? How about duplicate SCA composite defintions? Import/export
as currently defined isn't granular enough to address this kind of problem.
This might have been what Henning was after, but I'm not sure. Since
import.java is left as a vendor extension right now, it's less of an issue
IMO.
A nit: I think there might be some valuable intro text in 12.2.1 that we
could move into 12.2.2....but that's an editorial matter.
[1]
http://www.oasis-open.org/committees/download.php/26724/sca-assembly-1.1-spec-WD-02.pdf.
Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Michael Rowley"
<mrowley@bea.com>
To
02/05/2008 03:32 <sca-assembly@lists.oasis-open.org>
PM cc
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]