-
1. Re: Seam and granularity
hstang Feb 7, 2007 12:35 PM (in response to viniciuscarvalho)I don't know if you are more concerned about architecture or performance here but I assume the latter. When it comes to performance, you need to be more specific (scalability, response time, etc.) and set realistic goals/targets that can be "testable."
Now I am no EJB expert, but you'll find a better response in the EJB/JBoss forums with this question concerning EJB3 performance. Seam just helps to integrate the technology as you already know. Now it would help make discussions more interesting if you can tell me why you think "having many SLSBs would be a burden for the AS?" -
2. Re: Seam and granularity
viniciuscarvalho Feb 7, 2007 1:15 PM (in response to viniciuscarvalho)"hstang" wrote:
(...) Now it would help make discussions more interesting if you can tell me why you think "having many SLSBs would be a burden for the AS?"
Ok, sorry for the vague question :P
Ok, regarding performance. Its just a guess, but a SLSB with all the interceptors it has (tx,security etc...) is a bit heavy in terms of processing time and memory usage than a simple managed bean.
Regarding architecture, its just a question about the granularity of our apps, we use the approach I was talking before, may not be the best, may not be right, and of course I'm willing to change, it was just a question about how could this shift in terms of granularity would impact on our apps.
Not trying to create any problems, just seeking some orientation.
Regards -
3. Re: Seam and granularity
christian.bauer Feb 7, 2007 1:20 PM (in response to viniciuscarvalho)Its just a guess
\
Exactly. Without numbers, it's a guess and any attempt to "improve" the situation falls under premature optimization. Especially once you consider how costly data access to a remote DBMS is. If you have numbers that show that a few method calls and some interception is a performance, or even a scalability problem, there is something to talk. -
4. Re: Seam and granularity
vladimir.kovalyuk Feb 7, 2007 1:29 PM (in response to viniciuscarvalho)A little bit more ...
http://jcp.org/en/jsr/detail?id=299
...JBoss has submitted JSR 299 - Web Beans to the JCP for review. "The goal of this work is to enable EJB 3.0 components to be used as JSF managed beans, unifying the two component models and enabling a considerable simplification to the programming model for web-based applications in Java. In particular, this work will provide a programming model suitable for rapid development of simple data-driven applications without sacrificing the full power of the Java EE 5 platform. This is a domain where Java EE has been perceived as overly complex." ...
So, I believe it's the right place for the question. Seam implements JSR 299 that inspires developers to create more enterprise beans. (is it correct?)
What to do if simple application based on Seam eventually ceases to be simple? Does it become out of the Seam scope? -
5. Re: Seam and granularity
christian.bauer Feb 7, 2007 2:02 PM (in response to viniciuscarvalho)So, I believe it's the right place for the question. Seam implements JSR 299 that inspires developers to create more enterprise beans. (is it correct?)
What to do if simple application based on Seam eventually ceases to be simple? Does it become out of the Seam scope?
http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/07/29#simple -
6. Re: Seam and granularity
christian.bauer Feb 7, 2007 2:05 PM (in response to viniciuscarvalho)Seam implements JSR 299 that inspires developers to create more enterprise beans. (is it correct?)
JSR 299 has not yet released any work, so nobody implements it (because there is so far no specification to implement). Sure, Seam encourages you to write more Enterprise Java Beans. Now that these are plain Java classes in EJB 3.0, why not? -
7. Re: Seam and granularity
hstang Feb 7, 2007 2:11 PM (in response to viniciuscarvalho)"viniciuscarvalho" wrote:
Ok, regarding performance. Its just a guess, but a SLSB with all the interceptors it has (tx,security etc...) is a bit heavy in terms of processing time and memory usage than a simple managed bean.
There is no doubt there will be additional overhead when you use EJBs, but this is the cost incurred for the additional services your application requires. If you don't need tx, security, pooling, etc., then managed beans would suffice. I would concur with you that processing time will increase, but the burning question: is it real-world noticeable? Could you afford a few more extra clock cycles for the added benefit of services afforded to you by EJB? It really depends on your requirements and your available resources.
As for memory usage, SLSB don't carry any state so they are easier to "scale," at least in theory."viniciuscarvalho" wrote:
Not trying to create any problems,
There are no problems caused=) -
8. Re: Seam and granularity
vladimir.kovalyuk Feb 7, 2007 2:20 PM (in response to viniciuscarvalho)Christian, the problem is in the fact that Seam provides me with a lot of possibilities of designing JSF<->EJB interchanging. Now I have to try out several approaches on my own and work out my best practices. And someone have to do the same on his/her own.
I don't know whether Seam book have a chapter "best practices".
What about creating a Wiki page for "JSF Managed EJB best practices"? -
9. Re: Seam and granularity
viniciuscarvalho Feb 7, 2007 2:28 PM (in response to viniciuscarvalho)"hstang" wrote:
(...) but the burning question: is it real-world noticeable? Could you afford a few more extra clock cycles for the added benefit of services afforded to you by EJB?
good point :)