[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified
|
-----Original Message----- 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. <MR>Yes. Although I will also point
out that @location is optional. If it is absent, it merely means that the
named namespace shouldn’t be expected to be found within this contribution, and
so the domain should look for it elsewhere.</MR> > · 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. <MR>The existing specification text says
that QNames only have to unique to their “symbol space”, which is a concept
that WSDL uses. I had neglected to mention symbol spaces in this email
thread.</MR> 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. <MR>I don’t think we need scaLocation
even if we do restrict @location to point only at a contribution.</MR> 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. <MR>If you mean the use of
schemaLocation or wsdlLocation, which points to some non-SCA URI, then I agree
with you. However, I think we should stick to SCA mechanisms for resolving SCA
artifacts.</MR> Michael > · 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 > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]