camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: ServiceMix 4 as a distributed OSGi spring container....
Date Thu, 11 Oct 2007 09:37:17 GMT
Bringing this thread to dev list

On 10/11/07, James Strachan <> wrote:
> > We need to find a way to discover other ServiceMix instances (through
> > ActiveMQ ? any other idea ?)
> Am pondering if we
> should have a simple POJO based discovery/heartbeat mechanism thats
> transport agnostic so we could use multicast, jmdns, ActiveMQ, HTTP
> etc. Was pondering about making something really simple in Camel/SMX4
> and we take it from there etc.
> e.g. for a heartbeat we really just wanna do a timed send of a status
> message to some endpoint. This could be JMS or a POST to some URI (or
> even an AtomPub entry we POST).
> Then the server side of this thing, keeps a RAM cache of all these
> things and times the entires out after a while so they disappear.
> (Doesn't need any persistence or replication really; as if the server
> side fails, another one can start somewhere and after a few heartbeats
> its back in sync again).
> Then the server side - lets call it a registry (but a simple
> registry); can just expose these heartbeats as data in different
> queries. So folks can query using some mechanism for nodes of a
> certain type or whatnot.

Let's rephrase to check there is no misunderstanding.
The purpose here is to have a discovery mechanism which is somewhat
independant of the protocol.  So there is one server and multiple
clients, each client sending its own information to the server that
keeps track of them.
This implies, that either
  * there is a single point of failure for the master which is
statically configured
  * the client elect a master amongst themselves

Once the master / registry has been identified, the client send
heatbeats to it and can query it for services.  I'm not sure if a push
or pull model is better here: having the master send new information
to the clients, or have the clients  polling for new informations or
simply looking up the service on demand.

The problem with the pull approach is that we won't be able to expose
remote services in the OSGi registry without hacking the registry
itself.  For this particular use case, it would be better to be
notified of new services (or subscribing somehow) so that a client can
register a new remote service in the OSGi registry, which would be
available through a proxy.

> This heartbeat/discovery thing is pretty generic stuff really; it'd be
> nice if the message/data could be anything at all then we can reuse
> the same thing in many circumstances. e.g. we could use this to
> discover AMQ brokers; or CXF services of a kind of WSDL or SMX
> instances or OSGi containers or whatnot.


> The blob of data that is heartbeated; and what kinds of queries on the
> data we need to make is kinda speciifc to different problems. e.g. in
> AMQ we mostly just need to get the URL to connect to the broker. We
> may want to include some kinda network-hop type info so we try to
> connect to the nearest node or something - but generally a URL is
> enough in AMQ-land for discovery.
> For SMX containers, we might as well just expose the URL to talk to it.
> For distributed OSGi stuff we might wanna use more complex data for
> the heartbeat data; so folks could search (rather like the NMR does)
> by service QName, interface name, endpoint name or whatever.
> From a low level I was wondering about a Camel factory bean in spring
> <camel:heartbeat bean="someBeanRef" property="myStatusEventObject"
> millis="2000" uri=""/>
> This would call someBeanRef.getMyStatusEventObject() every 2 seconds
> and send the POJO to the endpoint URI. We could maybe wrap up this
> using some route? e.g. if the bean endpoint allowed for polling we
> could maybe do
> from("bean:someBeanRef?method=getMyStatusEventObject&period=2000").to("")
> though maybe a factory bean (XML element) is a bit easier - it does
> have better smart completion at least :)

I like the idea of using camel to configure the discovery mechanism.
This would be very flexible.

> BTW since servicemix is using activemq; probably the easiest discovery
> we should use out of th ebox is using the JMS network - i.e.  just to
> use a topic for the heartbeats; then each node can have a local
> in-memory 'registry'. Another option is to have a web app which is the
> registry and clients POST heartbeats and then GET data back - which is
> more useful for folks with firewalls or multi-language clients and so
> forth. I guess those are the big 2 implementations; web based or JMS
> based.

Sounds good.  But these are very different topologies, the first one
has no centralized registry, whereas the second one has.  How can we
bridge both approaches transparently ?

> > and thus make the OSGi registries
> > distributed.  Services that are marked somehow would be exported as a
> > service available remotely (I don't think it would be a good idea to
> > make all services available remotely).
> Yeah. We could require "export=true" or something in the service
> metadata or something. Maybe allow custom predicates on the service
> metadata to define profiles of things to distribute.

Sounds good.

> > As for JAXWS, we need some strategies to deploy them (maybe we could
> > rely on spring), as I'm not sure auto-discovering the beans it always
> > a good idea (might be pluggable though).
> Yeah; am thinking if folks use spring to deploy them we could maybe
> hook in to, say, CXF to grok the WSDL bits and expose those on the NMR
> automagically if you see what I mean.


> What would be awesome is if we can deploy various things (JAX-WS, EJB3
> and so forth) using Spring+OSGi and we have a way to auto-discover
> things and expose them on the OSGi NMR type stuff (and so in JBI too).
> i.e. rather than folks having to put their JAX-WS / EJB3 / SCA stuff
> into a service engine; it'd be nice if we had a way of kinda binding
> to them direclty via OSGi. Maybe wishful thinking though - I'm just
> wondering if we can kinda make the OSGiNMR/JBI stuff invisible and for
> it to auto-hook into whatever folks are actually using. Even if we can
> just find a way of getting CXF services when deployed as OSGi bundles
> to be discoverable so we can export 'em on the OSGi NMR thingy it'd be
> a big win for CXF users.

Agreed.  What I was thinking was along those lines.  That's the main
reason why the ServiceMix api does not have any notion of  "component"
as in JBI.  Instead we would create OSGi deployers (baically a bundle
listener or service listener).  For example to activate a ServiceMix
endpoint, it's just a matter of registering it in the OSGi registry.
 For JAX-WS, we could add a spring extension for deploying a bean,
kinda like the jaxws namespace for cxf

So exposing a bean in that way would perform all the necessary steps
to register on as a JBI endpoint and make it available remotely (maybe
we need a boolean to say if we want to export it remotely or not)

> BTW - here's a thought - should the only thing we distribute remotely
> be the entries in the OSGi NMR? i.e. stuff that we have a kinda WSDL
> for and so forth? i.e. rather than any old Java object in OSGi, we
> kinda define a contract of what can go onto OSGi NMR (so there's some
> kinda WSDL port, binding and so forth) then focus our distribution
> stuff on the OSGi NMRs in each vm?

This is a good question.  But going through a common way to distribute
the services as some pros.   But we could easily hide all the
ServiceMix stuff as I described above.  But I agree WSDL and all
should be optional, but they are already in the ServiceMix api.  I
think we can use Aegis data binding for non-jaxws POJOs that we want
to expose internally or externally.

> > Such beans could be exposed
> > on both Smx registry as an endpoint and externally through the above
> > mechanism as a soap http service.
> Agreed
> --
> James
> -------
> Open Source SOA

Guillaume Nodet

View raw message