[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified
> 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?
Unless there is more than one classloader per contribution, I'm not
sure this can happen without an error. Are you thinking of a
particular case here?
We will need to support contributions which contain schemas. A developer
should be able to "deploy" these schemas in their own contribution and use
the contribution as a shared resource. We will not be able to get away
with declaring that this is an error situation. I don't think classloader
scope is particularly interesting in this case since there's no Java, just
a big hairy QName resolution problem. I think it's that usually a single
application component or composite will want to use only one of two or more
conflicting QNames. Therefore I think it's sufficient to provide a way for
a developer to point at a specific schema file where that file is in
another contribution.
Is there some way to make this work:
1) Contribution A imports the namespace of a complex type where that
complexType is multiply defined. Contribution B exports that namespace and
is chosen by the deployment machinery to satisfy A's import.
2) a deployment composite in A contains a reference to a WSDL
(<interface.wsdl/>)
3) the WSDL refers to the complex type and contains a schemaLocation which
is a relative URI ending in a file name, that is resolved in contribution
B. This relative URI is resolved from the root of B.
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
Jim Marino
<jmarino@bea.com>
To
02/07/2008 05:53 David Booz/Poughkeepsie/IBM@IBMUS
AM cc
sca-assembly@lists.oasis-open.org
Subject
Re: [sca-assembly] ISSUE 8: SCDL
artifact resolution underspecified
On Feb 6, 2008, at 7:45 AM, David Booz wrote:
> 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.
+1
>
> 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.
I'm not sure I do either but it appears that Henning is concerned
with the performance of using references to QNames which are defined
in artifacts contained in the same contribution. For example,
<implementation.composite name=”foo:BarComposite”/>
Where foo:BarComposite is defined in a file contained in the same
contribution archive. We've implemented this and resolution
performance has not been a major impact. Also, if it does become a
problem, some type of index could be generated when the contribution
archive is generated that would make resolution virtually negligible.
> 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?
Unless there is more than one classloader per contribution, I'm not
sure this can happen without an error. Are you thinking of a
particular case here?
> How about duplicate SCA composite defintions?
In the same contribution or in different contributions? In the same
contribution, this should be an error. In more than one contribution,
this should be o.k. unless a contribution has two or more imports
that resolve to contributions containing composites with the same
definition. I'm inclined to say the latter should result in an error
since at some point people need to write applications correctly and
not abuse QNames :-)
> 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'd be in favor of exploring import.java or an alternative in more
detail. Personally, I'm not sure whether package names are the best
thing to use as opposed to a symbolic name. If we were to specify
semantics of Java, we would need to define classloader semantics for
contributions, which arguably we will need to do at some point anyway.
Jim
>
>
> 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]