Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
7 replies Latest Post - ‏2012-02-02T20:27:29Z by KeithPrescott
KeithPrescott
KeithPrescott
11 Posts
ACCEPTED ANSWER

Pinned topic name conflicts

‏2012-01-28T00:34:39Z |
Hi,

I want to deploy different versions of the same asset/composite/component to the domain. Also, over time I don't want name conflict problems to occur. Is there a way in WebSphere SCA to manage this through some type of a name space solution? What I have noticed is that the following needs to be unique to successfully install a CU from an asset.

  • composite-name
  • composite-targetNamespace
  • component-name

In terms of deploying the asset, there is no restriction as long as the asset name is unique, but when the asset is added to the BLA creating a CU these three names need to be unique. Is this true? Do they need to be unique for the domain, or server/cluster?

I have considered adding namespace and version to these three items, but that doesn't seem right.

Thanks,
--Keith
Updated on 2012-02-02T20:27:29Z at 2012-02-02T20:27:29Z by KeithPrescott
  • SystemAdmin
    SystemAdmin
    126 Posts
    ACCEPTED ANSWER

    Re: name conflicts

    ‏2012-01-28T06:32:15Z  in response to KeithPrescott
    Hi Keith.

    You might want to take a look at this link of the WAS infocenter. It is for WebSphere Application Server 7.0 but also applies for v8.0
    http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.soafep.multiplatform.doc/info/ae/ae/csca_deploypkg.html

    In there, you can see this statement in Deployment of JAR or ZIP files section

    "One specification requirement is that the names of top-level components must be unique. Thus, the product validates top-level component name uniqueness."

    Hope this helps a bit.

    ________________________________________________
    "If you prefer to speak in Spanish, please contact me directly"
    • SystemAdmin
      SystemAdmin
      126 Posts
      ACCEPTED ANSWER

      Re: name conflicts

      ‏2012-01-30T16:25:58Z  in response to SystemAdmin
      Keith,

      To answer another part of your question, it is the domain that the names must be unique across (not the server/cluster). In WAS the domain is presently simply the ND cell.

      Though it should be possible to have three composites, the first:

      {TNS1}CompositeA

      and another with:

      {TNS2}CompositeA

      and another with:

      {TNS1}CompositeB


      I'm not sure what else I could suggest to help your versioning issues.

      Maybe you could explain a bit more about what aspects of the composite you are trying to reuse in wanting to deploy two similar version of the same composite (with contained components).

      I.e. what's different about your different versions and what is the same about them?

      Scott
      • KeithPrescott
        KeithPrescott
        11 Posts
        ACCEPTED ANSWER

        Re: name conflicts

        ‏2012-01-30T20:19:13Z  in response to SystemAdmin
        Hi Scott,

        In your example are you suggesting a naming convention something like the following?

        
        <?xml version=
        "1.0" encoding=
        "UTF-8"?> <composite xmlns=
        "http://www.osoa.org/xmlns/sca/1.0" autowire=
        "false" name=
        "com.dm.sdm.MyComposite.1.0.0" targetNamespace=
        "http://sdm.dm.com/1.0.0"> <component name=
        "com.dm.sdm.MyComponent.1.0.0"> <implementation.java class=
        "com.dm.sdm.MyCompImpl"/> <service name=
        "MyService"> <interface.java interface=
        "com.dm.sdm.MyCompService"/> </service> </component> </composite>
        


        I am envisioning a domain with hundreds of services. Many services will have multiple versions deployed simultaneously. In this scenario multiple services have the same composite name with the same component name within the same namespace (with different versions).

        Thanks,
        --Keith
        • SystemAdmin
          SystemAdmin
          126 Posts
          ACCEPTED ANSWER

          Re: name conflicts

          ‏2012-01-30T20:40:17Z  in response to KeithPrescott
          Keith,

          No, I wasn't trying to suggest a particular naming convention... just to rephrase the current restriction a bit more clearly.

          But that didn't get to the heart of your question.

          For that I was hoping you could explain a bit more about how your different-versioned components and services differ (and how are they otherwise the same)?

          Are you trying to, say, develop and deploy different versions of Java classes (with both versions using the same package)?

          (If so, it sounds like impl.osgiapp might provide some value over impl.java if you're interested in pursuing that approach. I'm not even trying to suggest that but simply putting this out as an example to help understand what you're doing better).

          When using the default and WS bindings the component name is typically tightly coupled to the endpoint the service is addressable via. So the requirement for component name uniqueness helps fulfill the need for endpoint uniqueness.

          Scott
          • KeithPrescott
            KeithPrescott
            11 Posts
            ACCEPTED ANSWER

            Re: name conflicts

            ‏2012-01-30T23:34:40Z  in response to SystemAdmin
            Scott,

            Between different versions of the same service everything is the same except the version:

            • asset name
            • cu name
            • composite name
            • composite namespace
            • component name
            • implementation and service - regardless of type, but in the case of impl.java the same class and interface name are the same just likely enhanced in some way, or there might be interface updates

            --Keith
            • SystemAdmin
              SystemAdmin
              126 Posts
              ACCEPTED ANSWER

              Re: name conflicts

              ‏2012-02-02T14:46:34Z  in response to KeithPrescott
              Keith,

              So the point I was sort of getting at before is that, given that we don't provide any versioning of endpoints, you will need a unique component name in order to achieve endpoint uniqueness.

              Now.. say you had a relatively complicated assembly (i.e. complicated SCDL with a lot of intra-composite wiring), which you wanted to deploy multiple versions of that differed only slightly (say you had two versions of the same Java package/class). In this case, you could use something like the composite include mechanism or even implementation.composite in order to separate the unchanging part of your assembly (e.g. the included composite files or composite implementation files) from the portions which will be unique for each component service (to provide endpoint uniqueness).

              But for a more simple example using implementation.java it might not be easy to achieve something like this or worth doing so. So all you might be able to do is to use a naming convention.

              Also I'll just re-suggest that if you are maintaining multiple versions of Java classes that you consider looking at the OSGi support and the SCA/OSGi integration, since a key feature is robust support for versioning Java classes over a range of complicated scenarios.

              Scott
              • KeithPrescott
                KeithPrescott
                11 Posts
                ACCEPTED ANSWER

                Re: name conflicts

                ‏2012-02-02T20:27:29Z  in response to SystemAdmin
                Scott,

                I think you are explaining what I would like to be able to do - maintain a consistent composite that does not contribute resources/names/endpoints to the domain (private), then include this private composite (using @include) into a second composite that does expose selected components from the private composite. Is this what you are saying is possible; I should be able to do this through an include or impl.composite?

                In terms of using the OSGi integration, this is on our radar. We have implemented full solutions using this approach already. We get version capability at the implementation layer, but we still need the version-ability at the SCA layer for the services provided to the SCA Domain.

                Thanks,
                --Keith