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/earepository 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 >> 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 > 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 Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
