JMS

[Ryan Rawson]

JMS is an API actually - it doesn't really provide much in the way of
anything in terms of implementing or working code straight up.

Vendors like tibco (with their rendevouz product) and others supply an
implementation (usually with some kind of JNI) that allow you to
connect Java to those things.

I've used tibco for a number of years, and at our site it's ended up
not being so great.  The best thing about it, and products like it, is
you get machine-independent addressing.  As in you can say "send a
message to this subject" but you don't need to know who or where is
listening.  The decoupling sounds like a good idea, but in practice
you need to know who is consuming your messages anyways.

I would use JMS for a smaller enterprise, with < 1000 nodes.

-ryan

On 3/14/06, chandru <chandrashekhar.mullaparthi@REDACTED> wrote:
> One of our IT systems wanted to talk to one of my erlang systems using
> JMS. So I thought I can implement the wire protocol of JMS and got
> it's spec from the Sun website. Here is an extract.
>
> <quote>
> 1.1 Abstract
> JMS provides a common way for Java programs to create, send, receive
> and  read an enterprise messaging system's messages.
>
> 1.2.4  What JMS Does Not Include
> Load Balancing/Fault Tolerance
> Error/Advisory Notification
> Administration
> Security
> Wire Protocol
> Message Type Repository
>
> </quote>
>
> Now, what is the point of a f*ng messaging system if the wire
> protocol, load balancing, fault tolerance aren't specified. And then
> users moan that different vendor implementations of JMS do not
> interoperate! Duh!
>
> Sorry about the rant. I'm working from home today and I had to vent my
> frustration somehow :-)
>