Our system has many synchronous TCP/IP socket clients. I'm converting from J2SE to J2EE and considering using JCA 1.5 and Message Driven Beans to handle these clients. Our whole rationale for upgrading is to achieve greater scalability.
I have a few questions I'm optimistic about getting some help with. :)
Q1. Are MDBs strictly a one way operation or will they have a way to reply on the socket?
Q2. Are there other options I should be considering?
Q1) MDBs aren't connected to a socket, so no, they cannot respond to a socket. What happens is that your client connects to a queue/topic server that gets the data from the client. When the client finishes sending the connection is terminated and the server then assigns an MDB to the message just sent from the client.
The only way to have the client get info back is to have the MDB post a reply to another queue/topic or write to a database - and then have the client poll the other source at regular intervals to see if it gets something back.
Q2) I guess this depends on what you want to do - what functionality you're converting. Why do you want to go from synchronous to asynchronous if you still rely on a reply? If your client can continue processing that's fine, but if it's just hanging waiting for a response this is not the way to go.
Thank you for the reply. With JCA 1.5 and EJB 2.1 is sounds like there is a way to invoke an MDB providing it with a message taken from a socket as opposed to a queue. This is a new functionality. However, as you've indicated, there seem to be limited options for the MDB to return a reply to the socket client.
Unfortunately, we must use TCP/IP socket communication and reply on the same socket that the request came in on. Our clients are unable to listen to a queue or receive any kind of callback. Clients wait on the socket for a response. Transactions are synchronous and short lived.
Perhaps JCA and MDB aren't the correct j2EE choices for me.
I'm unable to find any options for the MDB to return a reply to the same socket the message originated on.
Why would you want to use a technology that is specified to be asynchronous to do synchronous work? If you need to get a response back, why can't you either create a servlet (if you can use HTTP) or a socket listener that looks up a standard session bean to do the work - and then responds back to the caller?
You are correct, this doesn't seem to be a helpful technology for my problem. I'm trying to think of why I should switch from J2SE to J2EE. Obviously, I don't need a J2EE AS for servlets or POJOs.
I would need to switch to J2EE to use session beans. So I guess now I need to decide if the advantages of session beans make converting to J2EE worth it.
I know my servlet of POJO listener can use JNDI to lookup a session bean to do the work, that's not terribly exciting to me. I know the J2EE AS will contain and manage beans for me. Is that a big advantage over something I could do with J2SE?
An J2EE server will supply you with declarative transactions, database connection pools, thread management and a general infrastructure which you of course can build yourself - but there it is, ready to use. If you have a small application with limited amount of (concurrent) users, limited transactions etc. it might not give you that much. But if you want to build a system that can easily scale to loads of users (just add computing power), then this is the way to go.
Thanks for your input regarding my posting. I am leaning towards gaining these functionalities from frameworks as opposed to J2EE containers. I think frameworks will provide me with more control and independence from contianer implementations.
Although, EJB 3.0 does look pretty cool.
Clarification: I mean a J2EE solution which uses frameworks in lieu of an EJB container. I do like some of the other technologies provided by J2EE such as JNDI, JMS, and vendor clustering.
Frameworks I'm looking at inclued Hibernate, Spring, Middlegen, Xdoclet, and Torque.
Quite often i have used a jini satellite service that acts as a "protocol converter" between whatever socket protocol is being used and the beans etc in the J2EE application.
This has worked very well so far, jini looks after the interface and makes sure is persistent, and we can use jini in the service to find the application server too.
JCA wasn't really around then, so I don't know how applicable that could have been.