Messaging for a Distrubuted Application

Try coridan - a new startup that might give you just that - http://www.coridan.com
They work with all app servers or stand alone mode.

Also, of course, Tibco's messaging is serverless (to my knowledge - no experience with this one), but it is expensive.

Have you looked at Jini?
http://wwws.sun.com/software/jini/jini_technology.html

If you need your messages to be persisted, the storage (e.g. a DB server) would be a single point of failure anyway.  If transient messages suffice, Jini does not require a central server - it's more of a "federation of services" kind of concept.

That's true. GigaSpaces is also a good alternative.

Hey,

 

I have checked out Jini before posting this question, as far as I am concerned Jini falls short delivering on its promises.

Let me share my finding/thoughts on the matter:

 

   1. As manifoldronin said “If you need your messages to be persisted, the storage (e.g. a DB server) would be a single point of failure anyway.” – This is a single point of failure which is a show-stopper as far as our requirements go.
   2. As far as “…it's more of a "federation of services" kind of concept….” – Jini was designed for federations of less than 1,000 resources. That maybe all right for home or for small offices, but what about large scale enterprise applications?
   3. Speed has always been a touchy subject with Jini and while on the matter of speed, Jini dose not support SOA (As far as I know).
   4. Jini’s lookup service is a bottleneck. If the lookup goes down, no service can be accessed. What happens when the location of the lookup service changes? How are the resources going to rediscover it?
   5. Jini itself needs a fair amount of configuration and administration. All components needed to provide a service need to be up and running. The application I am talking about assumes that not all services are up and running all of the time.
   6. Jini is too Java-centric (RMI…). It was designed with Java and only Java in mind. My application includes end-points written in C++ and C#.

I will check this coridan solution out, but any other suggestions will be appreciated.

Thanks.

A system of the kind you are looking for would effectively make each client a server with its own housekeeping requirements and services, one crucial one of which is that the failure of any individual client must be detected by each remaining client separately - effectively meaning continuous multilateral polliing. This model has network performance implications for one thing. And since clients are more likely to be run in environments where individual robustness is not catered for to the same extent as it would be for a server, so the likelihood of a client failure is that much greater.

This is not entirely true, is it?
I mean - you are partly correct about the part of having each client act as a little server - but that's not necessarily a bad thing. It depends on how the software is implemented.
This sort of client doesn't have to have individual robustness - on the contrary, the way I see it, you can probably write something that will use a normal desktop computer (like your endpoints are likely to be anyway) and save you the need to get an expensive server.
I beg to defer your opinion of individual client's failures - your description doesn't have to be accurate - first - suppose that you don't care if the other clients are up or down? you may leave that to the network altogether, and you may tackle it in other ways. You don't have to continuosly poll your whole network as well, you can use statistical network affiliations so that you create multi linked subnets or stuff like this. I can think of other ways to do that as well which will not effect the network very much.

On the other hand - I see some advantages here. Each client is as good as you need it to be (the hardware it's running on is as good as the budget allows for), I don't think there's a single point of failure here, because if a client is down - then only the communications between this client and its peers are down - and they will be up again when the client is back up.
I also think that when you're talking scalability - this kind of solution will probably give better results than the server-oriented one, since when you have a server - everything has to go through it. Now, you're going to say 'cluster' - but that's a lot of extra hardware to buy, and there's a limit to the number of irons in a cluster - whereas in my opinion - if you have a true serverless solution - then you can scale up indefinitely - your communication-lag should be very close to the network-lag.

The whole idea of having a network is that you know who is on it - if you don't know that information then the network's not worth much. Network OSs themselves poll individual clients. Perhaps ask yourself why the human brain and nervous system constitute one central command centre, and not that we have organs each with its own separate brain.

I agree with you on the 'whole idea of having a network..' however - as I said - ideally, I would happily leave that for the network layer. If the client is intelligent enough - it would know (using the feedback from the network layer) what's happening with the other clients it tries to comm with. I could think of a situation where you would (as a client) try and send the message a few times, see that the you're not getting attention, and declare the other side down.
Suppose that the other client comes back up - it can notify its availability, and then the previous client may resend messages.
This shouldn't be much of a problem to code. I guess.

About the brain - well, that's not entirely true. It is well known that the brain consists of at least two central command centres. Also, there is a theory I've heard of that data is accumulated in cells all over the body, and not only in the brain, but that's probably not in the scope of this discussion...

Cheers.
Nimo.

Nimo :

You are living in cloud cuckoo land I'm afraid. I shouldn't have mentioned the brain, but your cell theory is old wives' gossip. The body is under the command of a brain and I have never seen a headless body walking about any place.

As for networks, you haven't thought it through properly I think : if each client's presence on the network is unimportant then the message you send them is equally unimportant, since they may never receive it. More important than either the message itself, or whether the client receives it himself or not, is your knowledge of what happened to it.  If you don't have even that information, then the network itself ceases to have any relevance. :)

Well, when I was a boy we had a henhouse. I can personally testify seeing a body walks without a head.

As for networks -
You are partly correct - because you are relating only to the lower network layers. However, you are forgetting that we are talking about clients here.
Now, the client X needs to send a message to another client - Y. This Y guy happens to be down right now, and X, after a few attempts, understands that.
Now, after a few {time-particle} - Y comes back up, and announces it. X finds that out, and resends the messages that it accumulated in the meantime - Y acks them, and there's no problem.

What I was saying, is that I can leave it to the network to give me (as the client) the information about the state of the target client, but that doesn't mean that I do not know my goals: that I need to pass this message within a specified timeframe, and that I need to get it acked by the target client and so forth. Yes, the target client may never receive it - but that's always true when there's a permanent failure, or when I am dealing with short-lived messages that are invalid after a little while.

I don't agree with you that the unimportance of a single client up-status on the network yields the unimportance of messages sent to it. This is not the way you want to code a system like this. I meant it in the narrow meaning: It is unimportant whether a single client is up or down, cause the system as a whole continues to function (whereas when a server is down in server-oriented MOM - nothing happens).

have fun.
nimo.

Have fun too - although remember, you never saw this message, and I dont know whether you've received it or not. :P

Krakatoa & Nimo:

An interesting discussion, especially the part about the chickens :-)

Let me just clarify a few things: the whole point of having a distributed application is that you don't care where a service resides, you just need the function it provides.  Nodes can be up or down - the app does not need a specific (physical) node, but rather a (logical) service.  This is a model that scales very well, and indeed this is what I'm looking for.

The problem is, most messaging infrastructures I've looked at, have a central server which orchestrates everything (e.g. where to find which service).

I can write my distributed app with these MOMs, but it wouldn't be fully distributed, now would it?  If the server crashes - the app cannot continue.

Any other comments?

Chickens ... and then there is the chicken and egg situation, which is kind of like the one you are facing here. ;)

>>  most messaging infrastructures I've looked at, have a central server which ...

which goes to show that a truly distributed app is not really possible - the individual nodes may not care where the service comes from, but as nice as all that sounds they have to reside somewhere, and if that somewhere is unreachable, then the network is shot. All that peer-to-peer networks do is to shunt the reponsibility off to each other, but if you never know where or who carries that responsibility then the only answer is for everyone to be responsible.

Krakatoa:
But how does a central server solve this problem?  

Or are you saying that distributed appliactions are not feasible *in general*?  Because that's not true, in my opinion.

Also, some p2p networks work with a central server (or servers) - napster (rip), fasttrack - but some try to manage without - gnutella, kademlia.  Still, I'd say that they are all examples of distributed applications - some more "pure" than others.

>> But how does a central server solve this problem?   ...

you can't really "accuse" a servercentric topology of being remiss in not solving a problem that it was not designed to solve. Peer networks will have to solve their own problems.

I don't know what you mean really by distributed application. These terms are bandied about as if merely using them was a cure for the problems they are supposed to address. Even if you leave the concurrency of the data aside for a moment (ie ignore that multiple copies of the database for example are not perfectly synched), then you are still left with the question of where an individual client obtains its data from. There are only two answers to that : from itself, or from somewhere else. If it's the former, then it needs a copy of the data; if the latter then it's effectively obtaining service from a server elsewhere, so I guess this is not as distributed as you mean it to sound.

If you consider the backbones of the internet as virtual servers, then you soon start to see that distributing that burden over all the peers is not possible nor desirable. In your scenario, losing backbones that were not interdependent would leave some of the internet still functioning, which is partly ok if you happen to reside on the part that is still live, but no good for the rest of the internet, which no longer has any service. So yes, in theory a smaller and smaller universe of clients might be physically possible, but as an incomplete Captain on these issues, IMO, not a very useful one unless you have access to all the data you need from the former WAN.

I was gone for half a day, and look what happened here ;-)
Anyway, I am against philosophical debates on chickens and brains, but I do think that the products I mapped to above are relevant to you urish.
But if you don't want to use central servers because you fear for their failover - there are enough servers that offer 5 9's of availability, much better than what you would get from a serverless environment, simply because it hasn't been around enough.

Of course, that's not to say that the serverless solutions are not stable enough.