> What I'm looking for is to call an endpoint > transparently on another container. > Per example : > > Endpoint_OSGI_1 -> CAMEL ROUTING -> Endpoint_OSGI_2
Hi Grégory, Mediation by Distributed OSGi is triggered via OSGi service registry lookup. So as long as Endpoint_OSGI_2 is retrieved from the service registry, and the appropriate config and setup are present, then it should work fine. See the dOSGi samples for details, but the main config required is a small number of properties on Endpoint_OSGI_2 in container A (to indicate which interfaces are being exposed remotely, and also optionally to specify a URL if the default address isn't suitable). In addition, some discovery mechanism must be available in component B (either provided statically via OSGI-INF/remote-service/remote-services.xml or dynamically via the ZooKeeper-based discovery service). One thing to watch out for, depending on what version of SMX you're using, is the possibility of a CXF version mismatch. The recent CXF dOSGi 1.1 release[1] was based on CXF 2.2.4, whereas the latest CXF dOSGi 1.1-SNAPSHOT is based on CXF 2.2.5. The latest SMX 4.1.0-SNAPSHOT on the other hand is based on CXF 2.2.5, so if that's the version of SMX you're using, make sure you get the latest CXF dOSGi snapshot as opposed to the 1.1 release. Cheers, Eoghan [1] http://cxf.apache.org/dosgi-releases.html 2010/1/8 Grégory Le Bonniec <[email protected]> > Eoghan, > > Yes, you're totally right. What I'm looking for is to call an endpoint > transparently on another container. > Per example : > > Endpoint_OSGI_1 -> CAMEL ROUTING -> Endpoint_OSGI_2 > > What I want is to call OSGI_2 without knowing where it is located (local or > remote). From the container 1, the message would be saved in a persistent > queue (still transparently) and send to the container 2 at the final > endpoint. I don't know if I am clear. > > Grégory LE BONNIEC > blog : http://java-soa.blogspot.com/ > mail : [email protected] > tel : 06.28.40.94.35 > > > 2010/1/8 Eoghan Glynn <[email protected]> > > > > In pure OSGi, it's maybe possible to use OSGi Remote Services > > specification via CXF. > > > Basicly, it provides distributed services (like RMI-IIOP in the JEE > > world). > > > Like this, you can use a bundle service remotely. > > > It works fine from point A to point B but I never tried to define > cluster > > or load-balancer > > > with this mechanism. > > > > Grégory, > > > > Jean-Baptiste is correct, CXF distributed OSGi may be used to > transparently > > invoke on remote OSGi services. We thought about writing a CXF > > FailoverStrategy for dOSGi that would mediate with the OSGi discovery > > mechanism to transparently locate alternate targets and retry failed > > invocations if the original service disappears, but this has not been > > implemented as yet. > > > > However I get the impression from your question that its the > > *transparency*of the remote invocation that's of most interest to you, > > as opposed to high > > availability provided by replicated endpoints, right? If so, distributed > > OSGi may be exactly what you need. > > > > Cheers, > > Eoghan > > > > > > 2010/1/8 Jean-Baptiste Onofré <[email protected]> > > > > > Greg, > > > > > > with NMR Clustering engine, you have right, it's totally transparent > and > > > valid whatever the endpoint's component is. You can use it for HTTP, > > SMPP, > > > etc endpoints. > > > If you compare the SMX4/NMR cluster engine with the SMX3 one, it has > been > > > completely rewritten. > > > It's not only load-balancing but really clustering with the rollback > and > > > redelivery when a JBI exchange fail, the pause of new exchanges > > processing > > > when the number of concurrently processed messages reach a given > > threshold. > > > > > > Charles uses a karaf/smx instance. In this instance, he deploys camel, > > > camel-jetty and camel-http. It's only load-balancing (not really > > > clustering). > > > > > > In pure OSGi, it's maybe possible to use OSGi Remote Services > > specification > > > via CXF. Basicly, it provides distributed services (like RMI-IIOP in > the > > JEE > > > world). > > > Like this, you can use a bundle service remotely. > > > It works fine from point A to point B but I never tried to define > cluster > > > or load-balancer with this mechanism. You can find some informations > > here: > > > http://cxf.apache.org/distributed-osgi.html > > > > > > Maybe Gert or Guillaume have more informations about this. > > > > > > > > > Regards > > > JB > > > > > > Grégory Le Bonniec wrote: > > > > > >> Jean-Baptiste, > > >> > > >> What I understand is : > > >> > > >> - I we want to call an endpoint transparently we have to use JBI > > >> - I we want to non-JBI cluster, we can use HTTP (like in Charles' > > example) > > >> or JMS, but it's not transparent > > >> > > >> Am I right ? > > >> > > >> Regards > > >> > > >> Grégory LE BONNIEC > > >> blog : http://java-soa.blogspot.com/ > > >> mail : [email protected] > > >> tel : 06.28.40.94.35 > > >> > > >> > > >> 2010/1/8 Jean-Baptiste Onofré <[email protected]> > > >> > > >> Hi Greg > > >>> > > >>> It's not really component but endpoint. > > >>> > > >>> The cluster engine is a feature not active by default in the NMR. You > > >>> need > > >>> to add it manually. > > >>> > > >>> This cluster engine is in the NMR so only applicable for the JBI > world. > > >>> But > > >>> if you have an OSGi bundle that uses a JBI endpoint via the > > >>> EndpointExporter, it works. > > >>> > > >>> The explanation is here: > > >>> http://servicemix.apache.org/SMX4NMR/13-clustering.html > > >>> > > >>> If you want clustering/load-balancing without JBI, you can use > > SMX/Camel. > > >>> Charles has already make some samples of load balancing: > > >>> http://issues.apache.org/activemq/browse/CAMEL-2286 > > >>> > > >>> Regards > > >>> JB > > >>> > > >>> > > >>> Grégory Le Bonniec wrote: > > >>> > > >>> Hi, > > >>>> > > >>>> Concerning ServiceMix 4 Clustering, will it be possible to call a > > >>>> component > > >>>> A on a container A from a component B on a container B transparently > > >>>> without > > >>>> using JBI ? > > >>>> > > >>>> Regards > > >>>> > > >>>> Greg > > >>>> > > >>>> > > >>>> -- > > >>> Jean-Baptiste Onofré (Nanthrax) > > >>> BuildProcess/AutoDeploy Project Leader > > >>> http://buildprocess.sourceforge.net > > >>> [email protected] > > >>> PGP : 17D4F086 > > >>> > > >>> > > >> > > > -- > > > Jean-Baptiste Onofré (Nanthrax) > > > BuildProcess/AutoDeploy Project Leader > > > http://buildprocess.sourceforge.net > > > [email protected] > > > PGP : 17D4F086 > > > > > >
