glassfish
  1. glassfish
  2. GLASSFISH-18973

Integrate the OSGi Remote Services implementation(eg. Apache CXF Distributed OSGi)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: future release
    • Fix Version/s: None
    • Component/s: OSGi
    • Labels:
      None

      Description

      [BackGround]
      [Reference By https://issues.jboss.org/browse/JBOSGI-322]
      The Enterprise OSGi Spec describes OSGi Remote Services which is a way to Distribute OSGi Services.
      An implementation on top of Web Services and REST is available at the CXF Distributed OSGi project (http://cxf.apache.org/distributed-osgi.html).

      Integrating this in the JBoss OSGi distribution would provide it with support for this important OSGi spec.

      [Requirement]
      In a distributed soa/cloud enviroment, in order to decouple the whole system and use the subsystems dynamicly, user can use osgi. However, because subsystems/modules can be distributed across the whole system, as a framework of publishing/consuming services, glassfish should have an capability to support Distributed OSGi.

      [Integration Example]
      "Deploying CXF-DOSGi to JBoss AS7"
      https://community.jboss.org/thread/174136

        Activity

        Hide
        TangYong added a comment -

        Now, DOSGI-114 [1] has been fixed and next week, DOSGi 1.4 will be released. This release is a big release and I will integrate DOSGi based the release.

        [1]: https://issues.apache.org/jira/browse/DOSGI-114

        In addition,

        >2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...).

        In the future, there is a plan to use OSGi/CDI to import OSGi Service from distribute OSGi runtime, So integrating dosgi has turned very important.

        --Tang

        Show
        TangYong added a comment - Now, DOSGI-114 [1] has been fixed and next week, DOSGi 1.4 will be released. This release is a big release and I will integrate DOSGi based the release. [1] : https://issues.apache.org/jira/browse/DOSGI-114 In addition, >2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...). In the future, there is a plan to use OSGi/CDI to import OSGi Service from distribute OSGi runtime, So integrating dosgi has turned very important. --Tang
        Hide
        TangYong added a comment -

        Consider deferring implementing this feature for now for the following reasons:

        1) need to consider start level because of dcxf self
        Maybe need to combine with GLASSFISH-18945

        2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...).

        3) need to consider integration with other osgi platform related dosgi framework, not only is dcxf, because glassfish also supports other osgi runtime as equinox.

        4) integration way is still in progress and maybe needs to be combined with ondemand obr deployment.

        Show
        TangYong added a comment - Consider deferring implementing this feature for now for the following reasons: 1) need to consider start level because of dcxf self Maybe need to combine with GLASSFISH-18945 2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...). 3) need to consider integration with other osgi platform related dosgi framework, not only is dcxf, because glassfish also supports other osgi runtime as equinox. 4) integration way is still in progress and maybe needs to be combined with ondemand obr deployment.
        Hide
        TangYong added a comment -

        Thanks for your deeper experience very much.

        >Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613)
        Indeed , Apache DCXF still needed to be improved on some aspects.

        >Don't we need a different (much simpler) TopologyManager for GlassFish Clusters?
        >Can the existing GMS provide a TopologyManager? Could avoid the extra-cost of ZooKeeper and similar.
        Maybe shoal team can explain the point, and about whether ZooKeeper(Nowaday, I only know Zookeeper has been used on Remote Service Discovery) can do the same thing or not, if having more time, we can investigate it and maybe provide a better solution!

        >Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port?
        Yeah, this is a problem and I will investigate it if having more time. Thanks your suggestion!

        >Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF (http://wiki.eclipse.org
        >/ECF/Distributed_OSGi_Services) or FuseSource Fabric (http://fuse.fusesource.org/fabric/index, example here: >https://github.com/fusesource/fuse/tree/master/fabric/fabric-examples/fabric-camel-dosgi)

        About the point("quite heavy-weight"), I think that Eclipse ECF and FuseSource Fabric maybe will bring more coupling with other framework, and of course, if having more time, I will try to invesitigate and try them.

        Show
        TangYong added a comment - Thanks for your deeper experience very much. >Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613 ) Indeed , Apache DCXF still needed to be improved on some aspects. >Don't we need a different (much simpler) TopologyManager for GlassFish Clusters? >Can the existing GMS provide a TopologyManager? Could avoid the extra-cost of ZooKeeper and similar. Maybe shoal team can explain the point, and about whether ZooKeeper(Nowaday, I only know Zookeeper has been used on Remote Service Discovery) can do the same thing or not, if having more time, we can investigate it and maybe provide a better solution! >Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port? Yeah, this is a problem and I will investigate it if having more time. Thanks your suggestion! >Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF ( http://wiki.eclipse.org >/ECF/Distributed_OSGi_Services) or FuseSource Fabric ( http://fuse.fusesource.org/fabric/index , example here: > https://github.com/fusesource/fuse/tree/master/fabric/fabric-examples/fabric-camel-dosgi ) About the point("quite heavy-weight"), I think that Eclipse ECF and FuseSource Fabric maybe will bring more coupling with other framework, and of course, if having more time, I will try to invesitigate and try them.
        Hide
        ancoron added a comment -

        While I think remote OSGi is something that is really useful there are some other things to look at, as I already have some deeper experience with Apache D-CXF in GlassFish 3.1:

        1. Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613)
        2. Don't we need a different (much simpler) TopologyManager for GlassFish Clusters?
        3. Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port?
        4. Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF (http://wiki.eclipse.org/ECF/Distributed_OSGi_Services) or FuseSource Fabric (http://fuse.fusesource.org/fabric/index, example here: https://github.com/fusesource/fuse/tree/master/fabric/fabric-examples/fabric-camel-dosgi)
        5. Can the existing GMS provide a TopologyManager? Could avoid the extra-cost of ZooKeeper and similar.


        From my point of view also the following question matters in production environments:

        1. Use local (same-JVM) service or always go remote (TCP)?


        Usually all projects work nice with their published demos but it turns out that most of them just don't work if you have existing services leveraging recent language constructs and "just" want to export them remotely.

        Show
        ancoron added a comment - While I think remote OSGi is something that is really useful there are some other things to look at, as I already have some deeper experience with Apache D-CXF in GlassFish 3.1: Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613 ) Don't we need a different (much simpler) TopologyManager for GlassFish Clusters? Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port? Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF ( http://wiki.eclipse.org/ECF/Distributed_OSGi_Services ) or FuseSource Fabric ( http://fuse.fusesource.org/fabric/index , example here: https://github.com/fusesource/fuse/tree/master/fabric/fabric-examples/fabric-camel-dosgi ) Can the existing GMS provide a TopologyManager? Could avoid the extra-cost of ZooKeeper and similar. From my point of view also the following question matters in production environments: Use local (same-JVM) service or always go remote (TCP)? Usually all projects work nice with their published demos but it turns out that most of them just don't work if you have existing services leveraging recent language constructs and "just" want to export them remotely.
        Hide
        TangYong added a comment - - edited

        Now, Glassfish with Apache DCXF 1.2 has integrated successfully!

        Using Way is as following,

        1 make a sub-directory called "apachedcxf" under glassfish\modules.

        2 copy apache dcxf-related bundles[1] into "apachedcxf" directory.
        [1]https://github.com/tangyong/gf-dcxf-integration/tree/master/apachedcxf

        3 copy and override glassfish\config\osgi.properties using modified osgi.properties[2]
        [2]https://github.com/tangyong/gf-dcxf-integration/blob/master/osgi.properties

        4 start GF domain and telnet GF Felix Shell

        5 According to Distributed OSGi Greeter Demo Walkthrough[3], install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-impl-1.2.jar

        6 access "http://localhost:9090/greeter?wsdl" and you can see the wsdl description of exported remote service

        7 start another osgi framework with Apache DCXF 1.2(or GF with Apache DCXF 1.2), install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-client-1.2.jar, then input "foobar" on popuped dialog, and you will see the following info,

        greetMe("foobar") returns:
        Hola foobar
        Bonjour foobar
        Hoi foobar
        Hello foobar

        Show
        TangYong added a comment - - edited Now, Glassfish with Apache DCXF 1.2 has integrated successfully! Using Way is as following, 1 make a sub-directory called "apachedcxf" under glassfish\modules. 2 copy apache dcxf-related bundles [1] into "apachedcxf" directory. [1] https://github.com/tangyong/gf-dcxf-integration/tree/master/apachedcxf 3 copy and override glassfish\config\osgi.properties using modified osgi.properties [2] [2] https://github.com/tangyong/gf-dcxf-integration/blob/master/osgi.properties 4 start GF domain and telnet GF Felix Shell 5 According to Distributed OSGi Greeter Demo Walkthrough [3] , install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-impl-1.2.jar 6 access "http://localhost:9090/greeter?wsdl" and you can see the wsdl description of exported remote service 7 start another osgi framework with Apache DCXF 1.2(or GF with Apache DCXF 1.2), install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-client-1.2.jar, then input "foobar" on popuped dialog, and you will see the following info, greetMe("foobar") returns: Hola foobar Bonjour foobar Hoi foobar Hello foobar

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            TangYong
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: