Discussions

EJB design: iBATIS/Session Facade Architecture

  1. iBATIS/Session Facade Architecture (6 messages)

    I am considering an architecture for the model portion of an application that consists of using a Session Facade pattern with an iBATIS data access layer. In essence, the idea is to use EJB Session Beans to provide business logic and enforce business rules as well as to provide transaction demarcation. This Session Facade would use iBATIS -- primarily SQL Maps -- to provide database access and mapping to simple JavaBeans. The iBATIS layer would be configured to use a JNDI datasource as well as the JTA transactions provided by the application server. Therefore, any work done using iBATIS would be done within the context of the transaction provided by the EJB Session Facade layer.

    Has anyone ever considered this approach? What are the pitfalls, both in terms of architecture and performance?

    I do not mean for this discussion to become a debate on the merits of true ORM versus those of a simplified data mapping layer. The application I am designing is very data-driven, and relational in nature. In addition, the team I am working with (primarily mainframe developers new to the Java world) is quite used to driving application design based on the database. Therefore, it is highly likely that the database design will be done well before model design really even gets into full swing. Just the nature of the beast, I'm afraid.

    Thanks in advance for any insight.
  2. Hi Aaron,

    I'm working as an architect/developer in a huge project using Swing, EJB (only Session Beans) and iBatis as persistence layer (using both DAO and SQL Maps).

    I'm using iBatis because this project is a port of an existed Delphi application with SQL Server Database.

    The architecture of this project is :

    Swing Clients (accessing EJB through Business Delegate) <> Session Beans EJB (I've applied the Remote Facade Design Pattern) <> POJO Business Layer <> (Command Design Pattern with business logic) <> DAO ( Using iBatis DAO and SQL Maps, the transaction is controlled by iBatis DAO)

    I think do you need 2PC, don't you ?

    If not so, the JTA transactions is not necessary.

    Also, I think the business logic within Session Beans is a bad idea, it is difficult to test.

    If you prefer, you may contact me at douglasfsbr(at)yahoo(dot)com(dot)br for change any idea.

    Regards,

    Douglas
  3. I think do you need 2PC, don't you ? If not so, the JTA transactions is not necessary.

    Unfortunately, due to political reasons, we may be making a transition from DB2 (OS/390) to MS SQL Server or perhaps DB2 UDB. This will happen over time, with data slowly moving from one RDBMS to the other as new applications are written. In the meantime, new applications will need to be able to access old data while working on the new database. So... there's a good chance we will need 2 Phase Commits. In the very least, we can't at this time rule them out as a possibility. Besides, I am quite happy with the EJB ability to operate under transactions more or less transparently, rather than having to explicitly begin and commit my transactions.

    I am unfamiliar with the "Command Design Pattern" you mentioned, but will be looking it up when I have some time (thank God for Google). Other than that, this is very much the pattern I had envisioned. Compared to a Session Facade pattern with EJB entities as the persistence layer, how does this perform for you?

    Also, does this architecture seem conceptually simpler to understand and code? One of the issues I am looking at is a development team that will (understandably) have some level of trouble with all the complexities inherit in EJB programming -- especially when BMP entity beans become necessary. One of the biggest advantages I see with iBATIS is that I only need to know XML, SQL, and simple JavaBean conventions to use them. These are concepts my team can pick up quickly (they are already accomplished SQL writers).
  4. Compared to a Session Facade pattern with EJB entities as the persistence layer, how does this perform for you?

    I don`t understand your question, in wich case (performance, learning curve, maintenance, testing) ?

    I don`t like entity beans, it`t difficult to test, port and code. I think that Hibernate or iBatis (depends on the situation) are more appropriate.
    Also, does this architecture seem conceptually simpler to understand and code?

    Yes, sure. My main challenge was designed a simple architecture that not depends of EJB, my Session Bean is a simple remote layer to the Swing frontend, without business logic, it only calls my POJOS (that contains my business logic).
    One of the biggest advantages I see with iBATIS is that I only need to know XML, SQL, and simple JavaBean conventions to use them. These are concepts my team can pick up quickly (they are already accomplished SQL writers).

    Yes, of course, the iBatis is easy to understand, and the length of learning is low.
  5. I don`t understand your question, in wich case (performance, learning curve, maintenance, testing)?

    Actually all of these. I guess what I'm trying to get at, however, is this:

    In any technology/design pattern, there are usually pitfalls -- things that don't really work as nice as you'd like, or are harder to deal with. In this case, I am curious as to what the pitfalls would be with this sort of architecture vs. with an entity bean backed architecture.

    I appreciate your replies on this. They've given me quite a bit to think on.
  6. I don`t understand your question, in wich case (performance, learning curve, maintenance, testing)?

    The performance is ok, but depends of your decision in some layers, for example, in my case with iBatis i've configured the "cache model" to avoid database calls in queyrs that will not changed, it is a way of improving performance.

    The learning curve is low, because I'm using POJOS (Command) for business logic and SQL/XML/Dao Pattern (iBatis) for object persistence (both without the complexity of EJBs).

    The maintenance and test are easy because of POJOS, I don't need to start my application server to test my business logic.

    I'm using XDoclet for working with Session Beans (to generate deployment descriptors and remote/local interfaces).
    In this case, I am curious as to what the pitfalls would be with this sort of architecture vs. with an entity bean backed architecture.I appreciate your replies on this. They've given me quite a bit to think on.

    I think the pitfalls with entity bean backed architecture would be test (tight coupled) , learning curve, maintenance and I've "heard" that not scale well, mainly CMP.
  7. Thanks for all your help, Douglas.