On 11/10/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Bringing this thread to dev list > > On 10/11/07, James Strachan <[EMAIL PROTECTED]> 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
Yeah. I guess the two common approaches would be; * use a web server as the server via a URL (which you can have some kinda DNS/IP load balancer to deal with the master failing - though we really don't want to load balance across the master and slaves; all traffic should go to the master server at all times). On failover from master to slave it would just look like all the services died and came back again shortly afterwards. * use a JMS topic - so the 'server' is in RAM in each client (e.g. a List of the non-expired heartbeat POJOs) The latter is probably much easier to do; the former has the benefit of being able to be RESTful and so work across languages and corporate boundaries etc You could always add a RESTful facade ontop of the latter too - which would support load balancing and failover :) > 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. Yeah. I can see both being useful in different circumstances > 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. Yeah > > > > 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. > > +1 > > > > > 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="http://someServer.com/cheese"/> > > > > 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("http://someServer.com/cheese";) > > > > 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. Yeah; am thinking we could do content based routing or message translator stuff to format the POJO of the heartbeat data into different formats, sending it to different locations etc > > 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 ? I guess the main thing to figure out is; how would folks query this registry of beans? e.g. if we used some query language (EL, OGNL, Groovy/Ruby, maybe even XPath/XQuery on POJOs) then we could add that query to a GET URI for the REST/web based version - or just apply the query to in RAM POJOs in a collection. I guess from the Java client perspective we probably just need some simple API to be notified of things appearing or disappearing matching some filter; so we can respond (e.g. add/remove connectors in an ActiveMQ client or broker - or add/remove service proxies in OSGi or whatever the use case is) Then how that API is implemented (watching in memory POJOs populated from a JMS topic or polling a RESTful service etc) shouldn't matter to the developer. > > > 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. > > > > Yeah. > > > 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 > (http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html). > > 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) Great! -- James ------- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
