I've been tasked with explaining when and why to use different remote procedure calls at different times. I'm quite familiar with RMI and EJB. My experience with JMS is zero. All of the systems are (or will be) running java. Unlimited J2EE is available. And this is for intranet use. I guess I need to somehow gather more information on the JMS portion of this. Suppose that a server is set up and has one function: you pass in three objects and you get three different objects back. Does JMS handle that sort of thing well? I suppose it could be a point-to-point message. How simple is it to implement?
JMS is pretty simple to setup - comparable to RMI except the JMS server only passes messages around so you would have to have one or more services looking for your input message to appear, grabbing it, and creating the response. There is a message type for serialized Java objects, which is handy. I like JMS because it is loosely coupled and scalable. I used it as an example in my SOAP book - that was a while ago so I don't know what versions are available now. Bill
Bill! Thanks for the response! Remember that chaper I wrote for your servlets book? I'm seriously thinking of that "object pipeline" as a contender for this. It's simple and can be easily distributed. For those that didn't read that book, the idea is that you have a servlet-like class that you extend and implement "Object doObject( Object obj )". Then on the client side, you call a method in the HTTP class "Object send( String url , Object parameter )". Presto! Distributed computing as simple as it gets! I have a need to set up boxes with a collection of services. There might be 20 boxes, each with maybe 40 different services. I could just use the "Object Pipeline" (OP). It would work. Redundancy and failover can be handled with tools that are designed for the same thing for web sites. But I want to consider EJB, RMI and JMS too. I want to try to weigh the pros and cons and maybe even say "By default, use this - and for these cases, use theses technologies." EJB has a lot of overhead, so I'm disinclined to use that. I feel OP would be easier to manage remotely than RMI, but that could just be because I'm unaware of some whizbang tools for RMI. I bet there is a mountain of tools for JMS to see how things are going. Is JMS good for synchronized stuff? So if I call my remote method and I really can't do anything else until I get that message back .... It seems like rather than a simple method call, I might have to set up some kind of listener. Am I wrong about that?
Paul the architecture you are describing is known by the ultra-cool buzzword Service Oriented Architecture. You are on the cutting-edge of buzzwords and you didn't even realize it. Anyways, I plan to respond in full to your other post in our When not to use EJB thread when I have some free time later tonight, I just couldn't resist the urge to reply to this one also. In your case, I don't think that JMS is a very good fit for the architecture that you are suggesting. I don't feel that using RMI is a wise choice either. Now I have read your chapter from Bill's book and the thought of creating your own Remote Object Protocol leaves a very bad taste in my mouth. If your architecture absolutely MUST be distributed (I am not convinced of this yet) then I suggest you go with Stateless Session Beans or Web Services. Both are very easy to layer on top of existing services which could be implemented without the baggage of EJB (or whatever). For Web Services I suggest you checkout Apache Axis. I will respond in greater detail to the other thread later.
Author and all-around good cowpoke
posted 16 years ago
I really should have mentioned the related concept of JavaSpaces, which I also demonstrated in the SOAP book - it is related to JMS but even better for distributed processes. You can download the whole chapter on doing SOAP with messages from this page. It is chapter 8. I specifically included a chapter "SOAP Architecture with Messages" because it seemed to me that people assume that SOAP always implies HTTP, which is totally bogus. I can't imagine what Stateless Session Beans have to do with the problem so I am looking forward to Chris' exposition. We are certainly in cutting-edge buzzword territory here but it is also the most fun area. Bill