[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified
|
Dave kindly informed me that my first
attempt at sending this didn’t include mailing list. :-( From: Although Jim provided some insights, I thought I'd answer as well... -----Original Message----- 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)? Yes, I don’t think an “scaLocation” attribute should
be necessary. Or are you objecting to the location attribute
on the import element? No, that one is OK. The definition
for @location currently says: “It may point to another
contribution (through its URI) or it may point to some location entirely
outside the SCA Domain.” Note that this does not appear to admit
the possibility that it points at something _within_
a contribution, but rather it must point to the entire contribution. This
is clear because it says “point to another contribution” not
“point into another contribution”. I suppose we could add the
following sentence. “If the location refers to a contribution, the identified
contribution MUST export the namespace that is being imported.” This would further clarify that it is a contribution that is referenced
and not an individual artifact. I think it also states a valuable rule
that we previously forgot to mention. 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. I believe that SCA definitions
(composites, binding types, intents, etc) should all be unique within a single
“contribution context”, by which I mean a contribution and the exported
definitions of all of its dependent contributions. If others agree,
I’ll add that text. For XML Schema and WSDL definitions that
are found by QNames, I think they can be ambiguous, but we can use the standard
__Location attributes. I think that should cover the practical issues
with existing badly behaved artifacts. I don’t know what to do about Java.
I’m inclined to continue to say very little. We currently say
that “the installed contribution provides the context” in which
fully qualified classnames are resolved, but it doesn’t say _how_ they are resolved (in fact it says
there may be multiple ways). I think we should continue along those
lines. 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. Sure. Michael [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" e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"
<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]