|
Hi Michael,
while performance is an important
aspect, consistency of artifact resolution may well be the more important
aspect.
I believe, you want to make sure that artifact
resolution can be implemented consistently across artifact type (WSDL, XSD,
Java, ..., SCDL) - in a way that is consistent with what is already
common-practice in the given environment.
For example, when bundling more than one Java EE
application in a larger contribution, you would expect that artifact resolution
from with the application packages (i.e. the .ear files) would still be
application package local (or adhere to whatever deviation and mechanism was
implemented in your app server implementation of choice). So in particular, if
those two applications would both contain an equally-named and locally
used composite definition that differ in version, you would not want them to
create an ambiguity just because they are now used in a larger contribution
package. This is no Java EE particularity. I suppose an OSGi based scenario
could be made up similarly.
Therefore, eventually, a resolution mechanism that
involves technology specific ways of artifact handling could be more
appropriate. Unfortunately I am not aware of anything less ugly than a
scdlLocation attribute (as we already have schemaLocation and wsdlLocation) that
links a namespace to an actual artifact, or some XML catalog facility (as in
JAX-WS). I have tried to avoid to deep dark sides of XML ... maybe somebody
out there has a brilliant proposal that would fix it all...
Thanks,
Henning
The key concern here
seems to be w.r.t. performance. In my opinion, if there is only one
definition of an artifact within a contribution (as I think _should_ be the case), then it should not
be necessary for a human to point at it. Searching is one of the things
that computers are good at. Quite a large body of data can be searched
in a very short time.
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
|