Seam Architectural Questions

[asioanid]

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

[gavin.king]

1) Not quite: Seam makes simpler architectures *possible*, and essentially lets you layer your application however *you* like. You can certainly follow whatever architectural patterns you prefer, and in particular you can certainly have your entity beans have no Seam dependency. Up to you to weigh the costs and benefits.

2) Should be. I've certainly used multiple ejb jars. Have not specifically tried multiple wars, if you do that you will need to be careful about classloader issues, the wars will need their own classloading scope, I suppose.

3) The design patterns are your own design patterns, that's the whole point: to give you flexibility. My example apps mostly concentrate on simplicity at the cost of all else.

[villo]

This is a topic I have been thinking of opening as well.
It is still unclear to me to which extent using Seam pays off when you have to deal with multiple presentations for example.
I would like to see something like sun's blueprints for scoping and injecting Seam into a layered application.

For example from one side it is appealing to annotate a data model to use it directly in the presentation, but conceptually the data model should remain
independent from higher level layers. I agree, annotations are not as intrusive as interfaces but they still create dependencies.

Personally I find diffucult to estimate costs and benefits for technologies like Seam for anything more than really simple contexts

[asioanid]

gavin, thx for the quick answer, this sounds really good ..
being free to choose and design the overall architecture and not being inforced by a particular framework is a basic requirement in my opinion.

however, i fully agree to drVillo, it would be great if you could provide some more documentation or examples, how to build a seam based application using a multi layer architecture. I think of the dvd application example of being a good candidate for such a purpose. actually, there is only one org.jboss.dvd.seam package with "everything" inside..
this might be good for simplicity purposes, but acceptance would greatly increase in my opinion, if you would also provide more architectural blueprints. in real live applications you wouldn't have only one package (or one layer).

since seam is a brand new framework and also introduces some new paradigms, it's very easy to run into traps while dealing with complex situations.

regards,
andreas

[elfuhrer]

drVillo, I think once you are really familiar with Seam, extending it to cover complex situations is a more or less straight point.

Seam manages pretty well to solve most of the dependencies.
I would agree with you if you were talking about advanced application configuration, but again that's a matter of design. Every architect has his / her own design patterns.

I view things from a different perspective, if you have complex situations then your design is complex and no matter what framework you use the outcome will always be complex.

In any cases, I have been working on implementating a framework that resembles to Seam to a large extent, however I used WebWork and other frameworks and different patterns for source code generation. the stuff generated by Seam is really huge, it's a boost of at least 40% of your time and your developers time once they're familiar with the new concepts (not really new, except for the conversations)

To make this discussion a short one I believe that Seam is on its way, a lot is still pending but the architecture, the vision and hopefuly the resources are there. This project is worth a remarkable success that will show off in a while.