Using EJB in the middle tier for a mixed bag of clients


EJB design: Using EJB in the middle tier for a mixed bag of clients

  1. This has been bugging me the past couple of days:

    Stated summarily: What is the cleanest way to implement business logic in the middle tier while retaining as much flexibility as possible WRT client types that will access and update underlying data via this logic?

    Perhaps I'm missing something, and I'd like to hear what others' thoughts are on this.

    More context:

    It's reasonably obvious that the business logic/validation related to a given data model must be in one place. You can put it in stored procedures or in the middle tier, and the choice between these has been discussed many times and is not the topic of this post. Let's assume at this time that most if not all of the business logic belongs in the middle tier.

    Also assume that this is in the context of a new project or major port, where most of this logic will be (re)written from scratch. And that the preferred approach would be for the middle tier to implement a robust service based architecture that provides and controls access to the underlying data.

    Now add to this scenario that the final clients that use these services to build applications do not form a clearly defined set. Flexible client access should be foreseen as different types of clients could be required to access these data services - from web application servers, to wireless platforms, to custom built enterprise data access applications to vanilla desktop database clients.

    What would be then, in the opinion of those in this forum, the best way to implement such a service based middle tier with flexible client access?

    If I sort the possible clients based on the type of interface they would use to access data/services, I end up with two broad groups; clients that use a more API-like interface such as application servers and custom apps, and clients that use SQL (views/cursors/stored procedures) as their interface, such as query builders or form based rapid app builders.

    Both groups of clients have benefits - for example, form based app builders that connect via SQL can be used more productively for ad hoc purposes, and by a wider group of IS folk in an organization, than a more controlled web or custom application.

    I can't yet come up with a satisfactory middle tier architecture that would satisfy both groups of clients, and at the same time have business logic implemented once and enforced for everyone.

    Do-it-all XML somewhere? Perhaps, I don’t know enough. I'm in early search mode for ideas right now. One possible solution I have at this time is to leverage the ability of the Oracle App Server to wrap Java code with SQL stored procedure call specs. One could conceivably have session beans that return resultsets and manipulate data that are accessible as SQL stored procedures in addition to being accessible directly.

    But since iAS isn't exactly the gold standard for the rest of it…

    Thoughts, anyone?

    All best and TIA,


    peter dot prem at tetrapak dot com
  2. the idea behind business/middle tier services is that they should be decoupled from clients as far as possible. n thats exactly what u wanna do. a change in ur client shud not not trigger a change in ur middle services n vice versa.

    as for the cleanest n best way to do so is thru EJB, sessions beans for sure which will hold ur business logic/flow and entity beans which will represent the business objects/entities in the system u wanna automate.

    once u have implemented a genric business logic(hosted in a App server) for ur system, those business services can be called by any client(servlet/JSP/applet/swing) in a API like fashion.

    well the question bout having those service accessible to SQL clients. now my question is why u wud wanna do that.

    SQL clients are supposed to be clients which work on the raw data. where as ur business services represent the business functions/logic/workflow which perform business tasks which client developers can call on and hence prevent them from hittin the raw data.

    about using XML. well indeed thats a good idea. take for example u r writin both browser clients and WAP clients for ur application. what u can essentially do is make ur business services return XML data. and then once u have XML data u can using XSL write generice clients namely HTML and WML for browser and WAP clients respectively. n since XML is non-binary form of data i m sure u can port it to more clients(front-end/server) that u may not foresee as of now.
  3. Dear Kapil,

    Thanks for the reply. The reason for the SQL based clients is the large number of people in an organization who already know how to use them to flexibly deliver focussed point solutions quickly. This can be important in large organisations such as us, with over 900 IS people involved worldwide.

    Ideally, all access to the data is via the business logic layer, and if that business logic could be wrapped in some way so that SQL style clients can access them as well, you retain maximum flexibility.

    In this case, you would have SQL stored-procedure like calls (or some other mechanism) that forwards the requested data or update to the same business logic used by all the other clients and possibly return results. The SQL style clients would also benefit from the workflow or other functions enforced/provided by the business services.

    Of course, this type of access would not be the primary purpose of the logic encapsulated in the middle tier, but certainly among the possible consumers of the services an organization would like to have.

    This is why I see some value in retaining the ability for clients of this type to connect to the logic, at least in our organization, at least for the next few years.

    Am I missing something?

    All input is appreciated,

    All best,


    [email protected]
  4. Interesting topic.

    IMHO, the answer is depend on the nature of the "business
    if it is OLTP then middle tier/EJB wins.
    if it is OLAP then direct SQL/store procedure may be better
    since they are faster/more flexible.
  5. Qing Yan,

    If it's OLTP and middle tier is the best, how would you expose this logic also to SQL clients that know how to call SQL stored procedures but not EJBs directly?

    All best,


    [email protected]
  6. Peter,

    For OLTP applications, it will be too much trouble if allowing client to do ad hoc SQL access.

    Regarding stored procedure, you got unified access, but I
    doubt it is possible/feasible to implement nontrivial business logic using just stored procedure, not mention losing load balancing,resource pooling,portable ...all these nice features provided by middleware. Last, if you already got middle implementation,you don't want duplicate
    the same logic in the database, which will cause maintainence problems..
  7. Hey Peter,

    Well its something which is really interesting what u r trying to do.

    u might wanna have a look at EJB Query Language. its a interesting language available on BEA Weblogic 6.0 only, as far i know.

    i think this is something which might be interesting.

    lemme know if u come up with something. very keen to know.

    [email protected]
  8. OK:

    How about have a Stateless Session Bean as a facade on your middle tier, that talks to a Stateful Session Bean (use stateful session bean to keep track of the user session - you could use a factory to have stateful session beans for different users and a singleton to which, your stateless session bean talks, to get the client corresponding stateful session bean). Basically all calls hit the stateless session bean which creates corresponding data objects (from XML, http, etc type of requests) and passes the call to stateful session beans. The stateless session bean should of course then return corresponding data type (xml, http response, etc) along with the stateful session bean id for successive calls.

    Any comments, beat-ups on this idea.

  9. Hi, what you try to achive here?
    Plus I don't see the point why stateless session beans
    need to call stateful ones...
  10. oops sorry about that .. stateful session ejb are kept to maintain user state on the server for non-web users where HttpSession is not an option. The stateless session bean actually makes calls to a helper class to perform the requested work. This call to the helper class actually takes stateful session of the user and the data from the (http, xml, etc ) as parameters ..
  11. So why not use stateful session bean directly?
    What's the advantage of your design?
    Sorry..I didn't get it.
  12. Basically stateful session is for holding user session information here and thats it.

    I considered using stateful session bean directly in place of stateless session bean but, would 'nt that make the entry point to the whole application heavyweight ??

    With stateful session being having to worry just about the user session information it may happen (as in many cases) that the stateful session bean will not be used for all the scenarios ... So what I try to achieve here is stateless session which acts as an entry point to the system is more often (on every request) used and stateful session bean is used less frequently .. As I understand stateful session beans are performance issues for heavy loads .. and so I try to make less frequent use of it.

    Overall advantage of the design is: different types of clients can use the system. With stateful session bean being used for maintaining the user session we are not tied to HttpSession anymore and hence the servlet context. But at the same time we can run the application for multiple types of clients within one context. Non-web users can send xml request and web users can invoke a servlet which will delegate calls to the stateless session bean...
  13. Now I got it.
    Sounds good except one problem: how you gonna
    keep track of those stateful session bean? Then you have to pass the handles back and forth between clients and beans..
    looks ugly and exposes the bean's implementation to the
  14. I just finished building a system that faced this exact problem.

    If you choose to use EJB to do "the work" at the back end then design those classes so that they are totally client independant.

    Write a series of facades to deal with the clients. This is the place for dealing with the protocols etc.

    HTTP, EJB, RMI, CORBA etc will all be easy then. They just each talk to your core classes.

    Using XML makes sense, this is what I did on the last project I did. But remember that turning a Java XML object into it's textual representation is not the most computationally efficient thing in the world. String manipulation in Java is not stunningly fast. Use Apache Xerces, it's about the best one I've seen. Quick, free, easy etc.

    The SQL access is harder, but possible. Depends on what database you need to "look" like.

    You can always write things like OpenServers for Sybase, which look like database and can be talked to using CTLib etc. What you do with the SQL is up to your back end. Can't imagine anything as painful as trying to parse it and work out how to call your EJB layer myself.

    On the other hand, design the EJBs to that they know they don't have exclusive access to the database and let the users talk SQL direct to the database. Make sure you get your transaction isolation levels right though!