Solved

Messaging for a Distrubuted Application

Posted on 2004-04-18
18
233 Views
Last Modified: 2010-03-31
Hi,

The company I am working in recently started thinking about creating a fully distributed version of one of its products. In order to facilitate communication within our cluster I am looking for a distributed MOM. That is, without a central server - so that there isn't a single point of failure in the system. Instead of developing some in-house solution to this problem I much prefer to use a commercial product which will take care of the messaging issues and leave me free to take care of the business logic part of the application (which is hard enough...).

The problem is that I haven't been able to find a messaging solution which is fully distributed - all the products I've looked into rely on a central server (or a highly-available cluster of servers, but that's not good enough).

My question is this: Is anyone familiar with a fully distributed messaging infrastructure?  Naturally, we need it to interface with our Java code.

Thanks in advance
0
Comment
Question by:urish
  • 6
  • 4
  • 3
  • +3
18 Comments
 
LVL 9

Expert Comment

by:vzilka
ID: 10853904
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.
0
 
LVL 1

Expert Comment

by:manifoldronin
ID: 10856088
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.
0
 
LVL 9

Expert Comment

by:vzilka
ID: 10856762
That's true. GigaSpaces is also a good alternative.
0
 

Author Comment

by:urish
ID: 10857309
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.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 10857563
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.
0
 

Expert Comment

by:cptnimo
ID: 10857786
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.


0
 
LVL 16

Expert Comment

by:krakatoa
ID: 10857877
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.
0
 

Expert Comment

by:cptnimo
ID: 10857907
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.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 10857987
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. :)
0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Expert Comment

by:cptnimo
ID: 10858041
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.
0
 
LVL 16

Expert Comment

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

Author Comment

by:urish
ID: 10858159
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?
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 10858341
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.
0
 

Author Comment

by:urish
ID: 10858404
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.
0
 
LVL 16

Expert Comment

by:krakatoa
ID: 10858568
>> 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.
0
 
LVL 9

Expert Comment

by:vzilka
ID: 10858630
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.
0
 
LVL 9

Expert Comment

by:vzilka
ID: 10858977
Of course, that's not to say that the serverless solutions are not stable enough.
0
 
LVL 1

Accepted Solution

by:
BaneBane earned 125 total points
ID: 10866518
Guys,

I happened to spot this topic and in a way I was glad to see that it caused so much controversy...
My name is Yuval and I am one of the founders of Coridan, Coridan’s product is called a DMF (Distributed Messaging Fabric), and the next 5 lines can be thought of as a marketing scheme:
The DMF is the world’s first fully distributed, server-less, embedded and lightweight messaging Fabric, (and as far as we are concerned) a fundamentally new and profoundly more powerful and efficient approach to distributed application and solutions messaging. The DMF provides Service Oriented Architecture messaging based on enhanced distributed standards. We believe that it is a clear advancement from traditional messaging systems such as brokers, buses and homegrown messaging solutions.

Let me set a few things straight,
Urish, I agree with you on the shortcomings of Jini, a short search on the web reveals many problems with the technology..
manifoldronin, regarding persistency of message, the Coridan's DMF supports persistency of messages even though we are FULLY distributed and have no single point of failure.
vzilka, although server-less solutions have not been around for as long as the centralized solutions, one should not brush them away lightly. The concepts behind distributed systems have been around for many years. Distributed algorithms have been with us for many years  and have grown into a mature field of study in computer sciences. There are many examples of distributed networks out there... and lets not forget the Internet itself, which is a network of networks. Many of the mechanisms which make the Internet a resilient network (such as BGP and RFD) influenced our solution.

Anyway as this  site is not a promotional site I'll stop here.
Urish and any one else (of course), you may check out our site in order to learn more about what I talked about. http://www.coridan.com
You can also contact me at yuval [AT] coridan.com

Thanks
0

Featured Post

Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

Join & Write a Comment

Are you developing a Java application and want to create Excel Spreadsheets? You have come to the right place, this article will describe how you can create Excel Spreadsheets from a Java Application. For the purposes of this article, I will be u…
Introduction This article is the second of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers the basic installation and configuration of the test automation tools used by…
This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

23 Experts available now in Live!

Get 1:1 Help Now