Hi Greg,
no problem :)
Regards
JB
Grégory Le Bonniec wrote:
Thank you everybody for your help
Greg
2010/1/8 Eoghan Glynn <[email protected]>
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
--
Jean-Baptiste Onofré (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
[email protected]
PGP : 17D4F086
