2 Replies Latest reply on Apr 26, 2006 10:51 AM by Andreas Ioanid

    Seam Architectural Questions

    Andreas Ioanid Newbie

      Hello guys,

      we're looking forward into redesigning a set of financial applications and consider the use of sexy new technologies like ejb3, JSF and seam :-)

      So let me first give you a short description of our application/service environment.
      Basically, we have some core services like loan management, customer management, credit decision management, journaling, reporting, print services, user management and many other more. Each of them expose business and management interfaces and some of them have also persistence.

      On top of these core services, we imlement a business workflow layer (you can imagine of coarse grained interfaces, which are used by frontends). For example a business Method "addNewCustomer()" would use the customer management module to add the customer but also journaling for the business logging of that action (who added the customer, etc).

      There are many frontend applications using this business layer, each of them performing different tasks and in different contexts.

      So now - let's go to the questions :-))

      1)How does SEAM actually fit in such a context? However, I understand that seam basically uses a 2-layered architecture. Especially, I would not like to enrich the entity beans of a core service with seam-related information/annotations. The core services should implement their business logic, but not presentation or user interaction aspects...
      But however, it would be nice to use the entity-beans in the frontends as data models ... this is really sexy.

      2)Packaging issues: Is it possible to use 1 ear with serveral ejb3.jar's and war's and not having seam conflicts in the wars? I think about having 1 "naming repository" for seam components in each war application ..

      3)Is it possible to provide design patterns (documentation) for complex seam applications (especially, where multi layering is a must).

      Regards,
      Andreas Ioanid