Architecture comments for non-browser, non-java clients


General J2EE: Architecture comments for non-browser, non-java clients

  1. Hi,

    we are architecting a service to act as a data-entry engine. We are favoring the backend to service to be a session EJB(s) with POJOs. We expect our clients accessing this service to be a mix of both java thick clients as well as non-java C++ client and a legacy Oracle*Forms client (we currently do not plan to migrate it). Clients interact with the service heavily (on each value entered in the data field, server needs to perform complex validation...) and faster response is very important.

    So, here are the choices i am thinking about:

    1) Put the session ejb behind a servlet and let servlet generate a common XML (will be a single uniform interface for all clients)

    2) Expose EJB as a webservice so that all non-web clients can access it and let web client go directly to the ejb via a servlet.

    3) Let non-java clients call the ejb directly (using corba for c++ client and standard ejb client for java clients)

    Option 1) has the overhead of converting objects to xml and then parsing at the client end. However, it can take advantage of the local interfaces.

    Option 2) has soap overhead, but avoids custom xml of choice 1.

    Option 3) involves the remote interfaces and RMI overhead.

    Appreciate your comments/advice.

  2. First off, I thought that you had no options and all three types of clients would access this service. So you basically have to implement 1, 2 and 3.

    Which brings us to the next question, how to implement the three?

    Assuming that you have to use large scale validation on each and every field entered, you may be better of:
    - Collecting the data entered in a staging database
    - Running batch validation jobs on the data
    - Generating reports on data that is incorrect

    If batch is not an option:
    - Use some middle layer of business services to validate all incoming data
    - This middle layer can (and probably should) use some form of Rules Engine
    - Should be exposed as an API

    The advantage of the above method is that the API can then be used from any other layer (Session Bean, Servlet, RMI etc).

    If you build the above as an API and expose it as a Service, it is even better. You can then implement a Service Locator pattern to look for and use the Service.

    On a different note,if I may ask, what is the business case that requires complex server side calculations on each and every field of data entered?
  3. First off, I thought that you had no options and all three types of clients would access this service. So you basically have to implement 1, 2 and 3.
    I was thinking...just about any client (both a stand-alone thick java client as well as a C++ client) can call a servlet as long as they can make an http call and receive an xml stream back. Then why implementing all 3 is mandatory?
  4. I have done some work using XML over http. Believe me, it is not a path you want to take. Marshalling and unmarshalling XML at each end for every data field that the person enters is overkill.

    You really have to define the business case here before you pick out a design. Good luck if you do decide to use XML over HTTP.
  5. As an added comment to my previous post, if you do use XML over HTTP try to zip the XML (XML compresses very nicely) and send the zipped string over the wire. At the receiving end, you should first unzip and then process the XML.

    Make sure you use the right encoding when you create a zipped string to avoid problems when you unzip the string at the other end.
  6. What is the typical size of messages which will move between client and server? I ask this because we have an application with large SOAP messages, and we found that the bloated messages used unacceptably large amounts of bandwidth.

    It may be best to have your clients make RMI calls to a stateless session bean.