L.S.,
I really like the way ServiceMix 4.0 will be built around a set of core
technologies (OSGi, ActiveMQ, Camel, CXF). It's a very good idea to
leverage these technologies also for our own 'internal' operations
wherever possible and the Camel snippet that was shown has a very nice
touch of simplicity/readability to it.
I also like the suggestion of sending only a URL of the container in the
heartbeat, thus limiting the size of the heartbeat message, while still
allowing the other node to retrieve the data it needs. Perhaps I'm
completely missing the point here, but ... Wouldn't it be possible to
also include 'update notifications' in the heartbeat message this way?
Whenever a new service (or a bundle of services) becomes available, an
update notification is sent with a URL to allow the other nodes to only
retrieve information about what has changed. This way, the node
receiving the heartbeat can update it's own internal registry to reflect
changes that have occurred in the other nodes.
Gert
James Strachan wrote:
On 11/10/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
I was thinking that ldap may be handy for the registry, but hopefully
Chris will join the discussion at this point... Though camel does
not support ldap (yet).
So your snippet would actually solve the heartbeat problem. But I'm
not sure we can send the whole data at each heartbeat. I guess it
depends how bit this data is, but if we have lots of services in the
OSGi registry, it may not be very scalable. So we would have to
default to send only updates or find another mechanism to send the
data (the heartbeat could just contain the url of our container, and
the data would be retrieved by another mechanism).
Yeah; it does depend on how much data we're talking about. We could
slice and dice the data using URLs.
e.g. the full list of services available could be posted to some, say,
Atom document on some shared server; this list can be updated
incrementally or in total as and when services are added or removed.
Then the heartbeat could just send around a URL to the detailed information.
Or the list of services available could just be dynamically generated
on demand if the container exposed a web front end. (push v pull)
>From a client perspective, it doesn't much care - the heartbeat
message contains a URL to the detailed list of actual services
provided if it wishes to get more information etc.
