Non-RPC Client-Server Communication design question

Discussions

EJB design: Non-RPC Client-Server Communication design question

  1. Hi everybody,

    I recently started to learn about J2EE, so I am definitely a newbie. Before posting I searched for hints to my problem, but I did not find anything and therefore hoping for some help now :)

    So here is my situation:
    I have a Client Appication written in C++/QT4 (written by a friend of mine) and a "Server" which implements the business logic written in Java. They are communicating with a self-designed protocol that uses Sockets to send/receive data. It is not just a simple request/response communication, but also an asynchronous publish/subscribe communication that is used by the client.
    What I want to do now is, to implement my Server as EJBs inside a J2EE Server.

    My question is, how I should I handle the communication between my Client application and the EJBs?
    As I understand it, the J2EE spec does not allow multi-threading or the use of ServerSockets.
    On the other hand I can not use a RPC mechanism because, I need the server to have a possibility to send data asynchronously to my Clients.
    I also considered JMS/Message-driven-beans, which sounds good, but as I said above, the Clients are programmed with C++ and I could not find a JMS implementation for C++.

    I also considered the possibility to split up my application into a network layer (which is basically doing the same as in my Client-server implementation; passing headers, segmenting data, etc.) and into the business logic which could be implemented with EJB. The Network Layer Process should communicate with the Local Interface of the EJB by passing the network layer payload to EJBs.

    In that case my question would be, "where" (which environment) should my Network Layer Process run? It has to be the same JVM as the J2EE Server, if I want to access the Local Interface of an EJB. Would it be alright to put the Network Layer Process into a Servlet Container? I guess I could open Sockets from a Servlet and start Threads, but eventually I would have to block a Servlet indefinitely (socket.accept()), which would also mean the the Servlet container can not "manage" this Servlet anymore. It feels wrong to do that, because I think this is not the purpose of a Servlet. So the question remains: can I start a Process ouside the EJB-container and outside the Servlet container, but inside the same JVM as the J2EE Server?

    I know this have been a lot of questions, but I would happy if you could help me a little on this.

    Thank you,
    Jannis

    Threaded Messages (7)

  2. How about this?[ Go to top ]

    Here is one idea I wanted to throw out.

    How about have a file/database - and the C++ program writes out the data it needs to send into this file/database. Then you could have a Java program (can use quartz scheduler to schedule jobs periodically) that sends the data over to the queues/topics. Message driven beans can listen on these queues and do whatever they want to do. That way - later on when the time comes, you could re-write the c++ layer in java and everything will be seamless. I thought that is a viable option because the client communication is asynchronous - and the client does not care to get the reply immediately. This is similar to what is called the "store and forward" pattern that most messaging systems do internally.

    Having the network layer in the J2ee server and having socket communications between the c++ layer and the server layer - involves a lot of coding - and this will eventually transfer messages over to the queues anyway... Why add all that complexity. If the java process on the server side is bogged down with lot of messages, there is a possibility that you can really loose messages. The store and forward mitigates this risk and also allows u to log and audit the messages the c++ client is sending - just in case u needed that.

    Hope this helps!
  3. thank you, but...[ Go to top ]

    Hi,
    thank you for replying. Your proposed idea could have been a solution, but can not be used in that case. It seems, that I forgot to mention (:/), that there are certain time constraints which bound the server to "fast" response times. Basically there are two cases:
    1) the client requests/sends data to the server in a typical client/server paradigm. (synchronously)
    2) the server will cache certain messages and put them in a queue for futher processing. Those messages will be sent to every client connected to the server (asynchronously).
    Furthermore, there is data traffic which is used only to synchronize all clients which are connected to the server.
    This protocol implementation is already working, but as a wrote in my other post, I need to separate the protocol layer from the rest (the rest, which would be the business logic running on the EJB-Container).

    I recently heard that I could just put my Protocol implementation into a servlet which would communicate with localInterfaces with the EJB. I am not sure if this is a good idea, or if the Servlet-Container was meant to do this. After all, the protocol process would "block" the servlet all time, and there would also be a thread pool for accepting and assembling protocol data.
    Any ideas?
    I would be happy for any other suggestions.

    Thanks,
    Jannis
  4. Wow![ Go to top ]

    I think I kind of understand what you are trying to do. I am not really sure whether a servlet is the best thing to use to solve this problem. If I understand right, the servlet will open up a server socket and the c++ client will communicate with this socket. I am not sure how the container would behave. Most implementations use some kind of a pool - and having multiple instances of these servlets - can cause bind problems because more than one servlet would try to open a server socket at the same host/port. Not sure how that would work.

    Another option could be to use a startup program that starts as soon as the server starts (we use weblogic and can configure a startup program) and host the "network layer" in that. This program will work in the same JVM as that of the server and can access ejb's via local interfaces.

    Out of curiosity, are these client server communications conversational? If that were to be the case, you should have some kind of a session id to identify which client is talking and all that.... that would be very hard to implement.
  5. interesting...[ Go to top ]

    Hi,
    thank you for responding once again.
    I think I kind of understand what you are trying to do. I am not really sure whether a servlet is the best thing to use to solve this problem. If I understand right, the servlet will open up a server socket and the c++ client will communicate with this socket. I am not sure how the container would behave. Most implementations use some kind of a pool - and having multiple instances of these servlets - can cause bind problems because more than one servlet would try to open a server socket at the same host/port. Not sure how that would work.

    That's it! That is what I am trying to do.
    Another option could be to use a startup program that starts as soon as the server starts (we use weblogic and can configure a startup program) and host the "network layer" in that. This program will work in the same JVM as that of the server and can access ejb's via local interfaces.

    Now that sounds interesting. That would do it, I think. Now the question remains, if the JOnAS J2EE Server gives me the possibility to specify a startup program. If not, I may try the "servlet way".
    Out of curiosity, are these client server communications conversational? If that were to be the case, you should have some kind of a session id to identify which client is talking and all that.... that would be very hard to implement.

    You are right. In fact, we do not only need SessionIDs, but also TransmissionIDs (for message segmentation). Furthermore, the protocol supports to resume data transfers.
    It was a lot of programming :)

    Jannis
  6. Considered http?[ Go to top ]

    Hi,

    the idea of creating a servlet in a J2EE server that
    realizes a complete server (!) for some different
    protocol seems a little weird... (The only way
    reasonable seems to create new subclass:
    XyzProtocolServlet instead of HttpServlet.)

    Why not take the standards path and use the protocol
    J2EE is best prepared to handle the outside
    communication? That is, transport your special
    protocol through http.

    For that, you'd either have to teach your client
    http, or create a server component to translate -
    the latter of which I'd prefer: Create a Java server
    program, standalone, much like you though doing in
    a servlet, but keep that out from J2EE and the
    servlets. This server translates your special
    protocol stuff into some http messages, which you
    create servlets for to understand and process in
    your J2EE.

    This seems the best way to me to connect these two
    mutually foreign worlds.

    Webster
  7. ..I thought I did[ Go to top ]

    Hi,

    thanks for replying.
    I thought that I can't use http because it's a request/reply protocol which does not give the servlet the possibility to send messages to a client, without a prior query. The Servlet ("server") must have the means for asynchronous communication similar to an Observer Pattern. I do not see how to realize this without sockets and using a polling mechanism(which I seriously don't consider).

    Jannis
  8. how about another client?[ Go to top ]

    How about having another client(may be an applet) running on server which listens to uar c++ client & converts it to servlet specific request again handles the response from servlet & forward it to uar c++ client...just like mediator between your c++ client & servlet.