Thanks Guillaume, I'll look at this and maybe get back on Fabric8's own mailing list. Wrt to alternative products to Java Serialization there are many products that fix the problem with clunky API when you want to customize or have more control over serialization. I know about JBoss Serialization from the past, but it now looks unmaintained so thought there may be a successor. Kryo looks promising but I haven't had a thorough look yet. Best regards Mike Guillaume Nodet wrote:
2014-02-28 18:36 GMT+01:00 Mike Wilson <[email protected]>: Thanks, Guillaume, pluggable serialization protocol sounds good. Being associated with RedHat/JBoss, do you plan to integrate any of their "improved" serialization products? There's not many plans yet as I'm not aware of any requests on that side at the moment. We've had a request for pluggable class loading strategy though. Do you have any specific serialization in mind ? And what about load-balancing, do you have any possibilities in Fabric8 to combine that with DOSGi? Load balancing can be easily plugged in on the client side, as each remote service will be registered in the client bundle context. So a simple service tracker can take care about getting the list of services, but I understand that it would make things easier. Though I'm not even sure this would be really compatible with the spec ... I looked at the Github repo and I'm confused by the 1.0.0-SNAPSHOT version. Is fabric8-dosgi a new and yet not finished/stable component of Fabric8? Red Hat will release FUSE ESB 6.1 soon and this will be included. We've recently renamed to fabric8 and there is no official release yet of the code. I would advise to try with a nightly build which you can install using the following (on karaf 2.3.x only) * add the http://repository.jboss.org/nexus/content/repositories/ea repository to etc/org.ops4j.pax.url.mvn.cfg * features:addurl mvn:io.fabric8/fabric8-karaf/1.0.0.redhat-357/xml/features * features:install fabric-core * features:install fabric-dosgi We need to trim a bit the dependencies, and most of those bundles are not needed, but it gets you started ;-) Cheers, Guillaume Best regards Mike Guillaume Nodet wrote: The code is available at https://github.com/fabric8io/fabric8/tree/master/fabric/fabric-dosgi Note that the discovery part is using Curator on top of ZooKeeper, so you'll need to deploy both fabric-dosgi and fabric-zookeeper (which includes both). We haven't really tried to make it reusable outside fabric8, so there may be other dependencies, but we welcome patches ;-) Fwiw, the implementation really sticks with pure remote services, i.e. no remote service admin, no intents. That's mostly on purpose, as I tend to agree with Holger in that DOSGi is just a remoting mechanism like RMI. However, it has a pluggable serialization protocol (defaults to java binary serialization, but protobuf is also supported) and uses hawtdispatch (nio) for the IO side. It's really insanely fast. Cheers, Guillaume Nodet 2014-02-28 17:26 GMT+01:00 Mike Wilson <[email protected]>: Thanks Guillaume, that sounds great! We're already running on Karaf so that's a good match. Fabric8 looks ... big. I don't find the DOSGi stuff in the docs but see mentions of CXF and ActiveMQ. Do you know your way around Fabric8 so you could point me at the Remote Service stuff? Thanks Mike _____ From: Guillaume Nodet [mailto:[email protected]] Sent: den 28 februari 2014 17:07 To: [email protected]; OSGi Developer Mail List Subject: Re: [osgi-dev] remote services distribution providerrecommendations? The Fabric8 DOSGi implementation indeed support referential integrity. Guillaume Nodet 2014-02-28 16:31 GMT+01:00 Mike Wilson <[email protected]>: Thanks David, yes I've seen this list. Does any of these implementations support the referential integrity within transferred data I am seeking? And are all mature and being maintained? Best regards Mike David Bosschaert wrote: > Sent: den 28 februari 2014 10:41 > To: OSGi Developer Mail List > Subject: Re: [osgi-dev] remote services distribution > providerrecommendations? > > There is a Wikipedia page that lists all known OSGi spec > implementations, including the Remote Service implementations. You'll > find some more choices there: > http://en.wikipedia.org/wiki/OSGi_Specification_Implementations > > Cheers, > > David > > On 28 February 2014 10:37, Jean-Baptiste Onofré > <[email protected]> wrote: > > Hi Mike, > > > > FYI, Apache Karaf Cellar provides an DOSGi implementation based on > > Hazelcast. > > > > The default service provider lb is round robin by default > (I'm working to > > implement support of other algorithms). > > > > Regards > > JB > > > > On 02/28/2014 10:28 AM, Mike Wilson wrote: > >> > >> We're doing remote calls between OSGi containers on > different servers > >> and I'm looking at Remote Services to do the job. I've noticed that > >> Apache CXF/DOSGi http://cxf.apache.org/distributed-osgi is > the reference > >> implementation. > >> DOSGi's distribution provider is based on SOAP so it seems this > >> implementation will limit the expressiveness in data transferred as > >> arguments and return values, such as duplicating objects that are > >> referenced more than once and not supporting cycles at all. > >> Can you recommend any Remote Service distribution provider > >> implementations that offer better support for keeping "referential > >> integrity" within the data transferred to the remote server? > >> Bonus question: What's a good setup for load balancing > Remote Service > >> calls between multiple remote servers? > >> Thanks > >> Mike Wilson > >> > >> > >> _______________________________________________ > >> OSGi Developer Mail List > >> [email protected] > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > > > > -- > > Jean-Baptiste Onofré > > [email protected] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com <http://fusesource.com/> Blog: http://gnodet.blogspot.com/ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com <http://fusesource.com/> Blog: http://gnodet.blogspot.com/ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com <http://fusesource.com/> Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
