OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]