If you prefers (not using Web Services) for Distributed OSGI, please have a look to FuseSource Fabric (Opensource project) as we use TCP/IP + exchange of java objects
http://fabric.fusesource.org/documentation/user-guide.html#OSGi_Fabric Demo : https://github.com/fusesource/fabric/tree/master/fabric-examples/fabric-camel-dosgi Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Fri, Oct 28, 2011 at 11:00 AM, De Backer Frederik (DBB) <[email protected]> wrote: > Thanks to all for helping me in the right direction. I will try out DOSGI > 1.2 and let you know if I encounter any problems. > > kr, > > Frederik. > ________________________________ > From: [email protected] [mailto:[email protected]] On Behalf > Of Timothy Ward > Sent: vrijdag 28 oktober 2011 10:34 > To: [email protected] > Subject: RE: Exposing Services Remotely > > I have used DOSGi successfully with Aries, and there will be a discussion of > using in Enterprise OSGi in Action (http://www.manning.com/cummins) > > DOSGi is really good for exposing OSGi services as Web Services, and for > consuming Web Services as OSGi services. I would definitely recommend it. > The only thing I would say against it is that I have only been successful > using the single bundle distribution of DOSGi 1.2, and that it can have one > or two funny interactions with the Jetty web container if you have it > installed. > > I have also been working on "Modular EJB" support in Aries, and we have a > working integration with OpenEJB currently sitting in trunk (we won't be > releasing until OpenEJB 4.0.0 is released, and we have some doc). This works > nicely with the Remote Services specification (DOSGi) and also with the more > normal remote EJB model. > > Regards, > > Tim > > ________________________________ > To: [email protected]; [email protected] > From: [email protected] > Subject: Re: Exposing Services Remotely > Date: Thu, 27 Oct 2011 23:00:06 +0200 > > Sorry I forgot to mention Fabric. > > Regards > JB > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://wwx.talend.com > > ----- Reply message ----- > From: "Guillaume Nodet" <[email protected]> > To: <[email protected]> > Subject: Exposing Services Remotely > Date: Thu, Oct 27, 2011 8:08 pm > > > DOSGi is good if you want remoting between OSGi frameworks (that use the > same DOSGi providers mainly). > Else, maybe JAXWS is the easiest way to go. > If you're looking at a very fast DOSGi implementation, you could have a look > at my blog > (http://gnodet.blogspot.com/2011/06/distributed-osgi-in-fabric.html). > > On Thu, Oct 27, 2011 at 17:20, De Backer Frederik (DBB) > <[email protected]> wrote: > > Hello, > I have been playing around with Aries over the last few days and I have been > able to make some services via blueprint framework. However, now I would > like to expose these services remotely (EJB-like via RMI or WS-style via > SOAP). What is the recommended approach to do this? Is there already some > support in the current version of Aries to do this or is this planned in the > future? Should I use an app server like Geronimo and deploy my bundles in > there after which I can use the typical JEE services (such as remoting) > provided by an app server. Or should I go for a framework like the DOSGi > framework of CXF? > Any pointers regarding the possibilities, recommended approaches, > experiences, samples would be very much appreciated. > Thx for the help, > Frederik. > > <pre> > > ------------------------------------------------------------------------- > Dexia disclaimer: > > http://www.dexia.com/maildisclaimer.htm > ------------------------------------------------------------------------- > </pre> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > <pre> > > ------------------------------------------------------------------------- > Dexia disclaimer: > > http://www.dexia.com/maildisclaimer.htm > ------------------------------------------------------------------------- > </pre> >
