Removing CORBA, switch to JMS?


General J2EE: Removing CORBA, switch to JMS?

  1. Removing CORBA, switch to JMS? (3 messages)


    I've got some newbie JMS questions that I would like to get some feedback on. In my curent application, we have implemented all of our communications with CORBA. We just recently removed all non-Java code from our system, thus negating one of the most fundamental pros of CORBA (the language interoperability).

    Since we're now in an all Java environment, I'd like to move over to JMS but had some basic questions. Here are my issues:

    1. We use CORBA for Publish/suscribe communications. It looks like JMS is an ideal candidate for this.

    2. We us traditional client/server communcations (i.e, request, response, repeat). Is JMS ideal for this? This is synchronous communciations. My initial impression tells me JMS is good for asynchronous communicaitons.

    3. CORBA allows us to easily keep communications local if need be. For example, our server can broadcast messages out to multiple listeners. But in many situations, the only listener will be within the same JVM. This was done so our code could be easily re-architected to be distributabed. CORBA (at least out implementation) allows us to do this communications without creating a socket. This is a big deal for us. Although there is overhead with marshalling/unmarshalling requests everytime, it is very convienent for us since we can write our application in a distributable-ready fashion with relatively small penalty. Does JMS have any concept of doing this?

    4. Are there any good free JMS implementations out there? How good is OpenORB, Joram and JBossMX?

    Thanks in advance for any input.

    Threaded Messages (3)

  2. Removing CORBA, switch to JMS?[ Go to top ]

    for #4, i mean OpenJMS, not OpenORB
  3. Removing CORBA, switch to JMS?[ Go to top ]

    I'll try to help a bit on this one!

    You don't say whether you are a J2EE shop now or just a Java one, there are different options available depending.

    JMS is only the interface, and you do need a MOM implementation , but you know this, see point 4.

    SonicMQ is supposed to be very good. I'm sure I read an article a few weeks ago on the comparative strengths & weaknesses of the most common MOM products. I can't seem to find it though. Anyone able to point us in the right direction?

    JMS is great for asynchronous messaging and provides for both Publish & Subscribe and Point to Point messaging. However, when you think about P to P remember this is still async p to p.

    I don't think that JMS (or MOM for that matter) is ideal for request/response messaging. I believe that it does have some synchronous capability, but this mainly revolves around blocking until the response becomes available.

    I would have thought that if you are in an all Java environment, RMI would be better. This allows distributed object invocations. CORBA still remains the best way of doing heterogenous RPC (http/SOAP Ugh!!!).

    A prediction - Web Services are going to fail if http/SOAP remains the way of doing it!

    MOM still allows the user to be unaware of target location. This is determined by MOM configuration. The sender just places the message in a queue. The queue manager uses configuration to determine whether to leave the message there for local retieval or to send via a channel to another queue manager residing in a different JVM or on a different machine.

    I can't really help in the assessment of MOM products. Our company is in bed with IBM, so we use MQ-Series. This is very reliable, and scored highly in the review I was alluding to above.

    If I can find this review, I'll point you at it.

    I have to ask. I appears that you have a perfectly working system at the moment. Why do you want to destabilise it?

    All the best
  4. Removing CORBA, switch to JMS?[ Go to top ]

    We are looking to destabilize mainly because of business reasons. There are only a handful of our guys that understand CORBA well because it is very complex. We need to move the weight off of these guys for business reasons. So JMS would be ideal because it is very easy to use and write code for.

    I also believe that JMS has a methodology for forcing all communications through one port (please correct me if I'm wrong). With out current CORBA implementation, we create new sockets on different ports frequently. This makes it difficult to poke through firewalls.

    RMI is way to slow. It uses Java's Serializable interface, which is painfully slow.

    So based on your response, MQ-Series has optimizations for intra-JVM JMS clients and servers, right?

    Thanks for your help!