2 Replies Latest reply on Oct 14, 2007 6:30 AM by fhh

    Some thoughts about abstracting everything from everything

    Oleg Puzanov Newbie


      For the last 3-4 months I've been picking JBoss Seam as the framework for my Java EE projects,
      before this I was using some plain EJB3 + JPA approaches.
      The overall stack of technologies looks like this (from Presentation Tier downto Resource Tier):


      ....with Seam being present somewhere throughout all these technologies.

      Everything seems to be cool - the need for introducing some "glueing" components such as DAOs, DTOs, Service Locators etc.
      seems to evaporate and all layers seem to cooperate pretty much well. BUT....
      I really need (have) to keep a certain level of independence and loose coupling among the technologies used throughout the application tiers.
      To my opinion the main issue with JBoss Seam seems to be the following:

      The common practices assume the presence of Seam-specific annotations and JPA invocations in Session Beans,
      which are being later called by JSF
      Considering that Session Beans contain almost all the business logic of our application (for the case of Seam application),
      this means that this business logic is coupled with both Seam by using at least its context management services
      (e.g. @In @Out annotations for injecting/outjecting Seam components) and JPA by calling EntityManager methods directly
      inside the methods of Session Beans

      What I really need (have to) is the following:

      Independence from the technologies in Persistence Layer (EIS Integration Tier):
      My "data feeders" can be anything the human mind can imagine: RDBMS, XML Database, Plain Files, Legacy Systems via Proprietary Protocols etc.
      Independence from Seam in my CORE business logic.
      At the same time - keeping all the infrastructural services provided by Seam and EJB3

      From my side I can suggest the following solution to this architectural problem:

      To keep Session Bean sublayer dependent on Seam - there is no other way out,
      I will call this sublayer "Seam Business Logic Integration Layer".
      It's main purpose will be to integrate Business Logic Tier with Seam and EJB3 infrastructural services.
      To move the core business logic into POJI/POJO implementations,
      which will not use Seam/EJB3 annotations or other services + they will also not use JPA invocations.
      Considering that we will not use @Name annotation for these POJOs and
      that we will still need to inject them into Session EJBs, all these POJOs will be configured in components.xml as Seam components.
      To introduce something called "Domain Model Facade" - abstraction from the underlying persistence technologies.
      This facade will be presented as POJI for the core business logic (implemented as POJOs) and will provide
      the basic methods related to data access operations (e.g. save, load, find etc.).
      The underlying implementations will provide JPA, XML or JCA versions according to the configurations.
      I will call this sublayer "Seam Domain Model Integration Layer".

      Domain Model itself will be exposed to the core business logic as POJI/POJO combinations.
      While at the same time - these classes can be configured in components.xml as Seam components
      for enabling the context management services provided by Seam + referencing them in JSF pages.

      What I really want to ask is the following:

      Will this work?
      For the case if it will work - maybe there are some existing and better approaches to this issue?
      For example: something with Spring integration into all this mess for enabling the loose coupling between layers?
      Or maybe it will introduce some much bigger mess...

      Thanks in advance,

        • 1. Re: Some thoughts about abstracting everything from everythi
          Pete Muir Master

          Seems like you are on the right course, its perfectly possible to introduce more layers into a Seam app - we just find its normally not necessary.

          You will loose some of Seam's nice features if you remove persistence too far from it (e.g. conversationally scoped persistence contexts).

          I would avoid dragging Spring in unless you have to.

          • 2. Re: Some thoughts about abstracting everything from everythi
            fhh Expert

            I think one think should not be forgotten:

            The dependency on Seam is different than the dependency on another library. True, if you use annotations the Seam lib has to be present at build time (You can actually work araound this by using XML). But Seam is not required to use these components if you do not rely on Seam in your own logic.

            So it is perfectly possible to reuse a JPA data model or session beans that are Seam annotated in an application that does not use Seam.