-
1. Re: Architecture for large application using Seam
I mean no disrespect but if your building a large app with seam I think you need an architect who knows these things. There ARE many considerations as you said and I'd be surprised if you get any answers to such broad questions.
good luck!
-
2. Re: Architecture for large application using Seam
d sailer wrote on Apr 03, 2009 19:47:
I mean no disrespect but if your building a large app with seam I think you need an architect who knows these things. There ARE many considerations as you said and I'd be surprised if you get any answers to such broad questions.
good luck!How many Seam architects do you know or heard of? Seam is a niche market in JEE.
Here's my take on this. I took the Sun Architect course a while back and learned how important NFRs are (non-functional requirements) and proof-of-concept implementation. What is NFR? Things like performance, fault tolerance, scalability, failover, clustering, etc. Yeah the big problems that architects get paid more to solve/plan/handle/troubleshoot, etc.
Remember that Seam fwk is designed such that there are very minimal requirements for layering when compared to Struts/EJB2.x, and very little
XML hell
like projects that make extensive use of AOP like Spring.Anyways, this means that you will need to decide whether or not you will need a DAO layer (some of the larger apps use DAO). DTO is anti-pattern with Seam/EJB3.
Think about testability; how easy will it be to unit and integration test your large Seam application with dozens or hundreds of classes?
Personally I don't use the Seam application framework although I've heard that approx. half of JBoss' Seam customers use it. I like the flexibility and freedom to
roll my own
solution.Is vendor lock-in an issue? If it is, stick with JPA vs. Hibernate (but do use Hibernate as your persistence provider for JPA). The manual flushMode is a Hibernate extension and is supported in JPA 1.0 or JPA 2.0. However, it is a very useful feature when implementing conversational use case solutions.
Richfaces vs. ICEfaces? JBoss supports RF, not ICEfaces.
Coding to interfaces is important but not absolutely required by Seam. It is a cornerstone of Spring development.
GWT vs. Wicket vs. JSP vs. Facelets?
what about Groovy, Seam supports that.
Will you need to integrate existing Spring beans into your Seam project?
Plan for clustering (minimum 2 node horizontal cluster fronted by Apache httpd).
asynchronous messaging, remoting, web services.
tons of stuff. good luck...
-
3. Re: Architecture for large application using Seam
Arbi, thanks for sharing your thoughts!
We are using Seam to replace one of our existing subsystems that was developed 20 years ago, with continious improvements along the way of course. So, we know for sure that the system we are building now will live for a long long time. Having that in mind, you have to be careful when designing the system. Another issue you have to think about is modulatity, hence we are preparing for redevelop other subsystems in the future if this project turn out well.
We like Seam, the component think, and how to dealing with conversation and states, thats why we choose it after having evaluated frameworks. And that raises the question, when will Web Beans be a cornerstone of Seam? We have that in mind already now...
Our ideas:
1) Don't use outjections. Not a concept in Web beans, and we are afraid that we end up in a mess of context variables that we don't now the orign of.
2) Don't let the entities be stupid. We will put as much logic as we can in the entities.
3) All ui logic and most of the actions will be handled by classes in the web application(s).
4) Use service classes if we have application logic that doesn't fit in the entities.
5) DAO-operations will be handled by the Home and Query classes. We'll use the existing EntityHome and EntityQuery, but we have our own base class between so we easily can modify the behaviour if we want.Just a few brief answers regarding Arbis thoughts:
We are afraid of vendor lock-in. It's a pity that only Hibernate supports the manual flush mode, but I am pretty sure that it will be supported by JPA some day...This causes headaches when choosing the transaction strategy. After all, the conversation scoped persistence context along with Seams global transactions and the manual flushing concept is really powerful.
We are using Richfaces, no doubt about that.
Facelets. No GWT, Wicket or JSP for us.
Groovy is an option
No Spring.We will expose web services. We have a separate ejb dealing with integration issues, that will have an well defined API, using DTO:s, so we don't easily break the API.
We are having a test strategy including both unit- and integration tests, but that is also hard to know how well it scale.
Finally, we are using Maven (of course).
/Thomas
-
4. Re: Architecture for large application using Seam
Hi Thomas,
As somebody who is also starting a major project with seam, I was interested in your deliberations. I thought of some of the issues you have written about and here are my conclusions, I would be interested in your feedback.
1. Don't use outjections - I wasn't aware that webbeans will not have this feature, but it is very useful. It solves two problem, one the lifetime of the component and what it outjects can be separated, hence allowing a stateless/event scoped EJB to outject stuff into the conversation. Second, it can cut down on boilerplate code for EJB's (i.e. getters and setters). I think it is a great feature, but since I have only limited experience I don't have the full picture of why it is being dropped.
2. Make the entities smart. In my new application I will have upwards of 500 entities, if I make them smart then I will have to make each of them components so that I can inject entity managers and the like. Personally, I didn't like the idea of having so many components (also why I am not using EntityHome/Query). Performance is an issue, but also making so many components just seems wrong. But I have to confess I come from a Struts background and am very compfortable with Action components so maybe I am biased.
Other than this I agree with most your comments.
-
5. Re: Architecture for large application using Seam
Robert, great to hear that you also is starting up a major project using Seam, and thanks for commenting my ideas. I'll comment yours as well:
1) My idea is to work mainly with the conversation scope (at least when not listing things), and these should be kept short. Accessor methods are boiler plate code in Seam, but they are clear obvious, and having many developers in the team that is familiar with this concept it is best to keep them. I don't see them as a problem, a few clicks in the IDE and they are generated.
2) By putting logic in my entities I absolutely not mean to make them active records, so we will absolutely not inject the entity manager in the entities. You have a point that there will be many components using the generic home- and query classes, but there will not be one home class per entity due to cascading in JPA.
I think that we should keep sharing our ideas and inform each other about the progess in our projects.
/Thomas
-
6. Re: Architecture for large application using Seam
When I started my project I thought putting logic in the entities seemed like a good idea as well, but it turned into a complete mess. The approach I ended up going with was to split my project into 3 separate jar files, one just with entities, one with business logic and one with UI logic. This way the entities are not dependent on anything, and the business logic is not dependent on the ui logic.
If you put the logic in the entities then you do not have access to all the neat features that seam can bring to the table, such as transaction demarcation and dependency injection. Even though JPA entities can be components, they are instantiated by the JPA provider not seam, and so do not have access to services that are provided via seam interceptors.
I would use EJB's over POJO's, instance pooling and passivation become really important if you have a large number of users, and are not provided by seam POJO's.
There are no problems with having upwards of 500 components if that is what your project needs, the only major downside is increased startup time.
-
7. Re: Architecture for large application using Seam
We have made a few more system design decisions during the last couple of days.
We are using the Home class concept, but our home classes are SFSB:s. I tried without using the home class approach first, but my code ended up doing the same thing as the CRUD framework, so it felt natural too keep them.
We are using the Query class concept, but as SFSB:s. (Tests shows no loss in performance comparing with a Query class as a POJO).
We have defined Action classes as a data feeder and an action interceptor (eg. user clicks a button) to the view. The Home classes are never exposed to the views. They are instead injected in the Action classes.
The Query classes can be used directly in the view, but also injected and operated on in the Action classes.
The entities are smart. We still believe in this idea, but are prepared if it turns out to be a mess.
We also have a type of class called Manager (we need a better name for this one, any ideas? eg. don't mix it up with the ones Seam calls Manager components and it's not really a Service class either). The Manager is stateless and responsible for handling business logic that the entities can't deal with, for instance, changing status of a selection of customers in the system.
We hope this turns out well