-
1. Re: Component Architecture instead of traditional Layers
brachie Jan 19, 2008 5:34 AM (in response to ruettimac)@Cyrill: Interesting questions! I would also be very interested in an answer, since we are currently using Seam in our project and having a proper architecture is essential. I agree, that the seam examples are a bit too simple as template for real-world application architecture.
In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong.. It would be great if someone with real-world seam experience could give some architectural advises.
The following questions are in my mind:
Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)?
Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page?
Or would it be good to have one SFSB per use case of your application?
What would be the correct approach? Please share your opinions!
Greetings,
Alexander -
2. Re: Component Architecture instead of traditional Layers
pmuir Jan 19, 2008 4:59 PM (in response to ruettimac)"ruettimac" wrote:
a) Injecting stateful session beans into other stateful session beans?
No problem here, just use @Inb) Are there any problems regarding the different seam scopes like CONVERSATION and long running CONVERSTAION scopes beans?
Like what?c) Any patterns to avoid or seam annotations like @Create or @Factory?
I find @Create is less useful in writing apps (it's great for build infrastructure components, like those in Seam). @Factory is great. I'm a fan of using a Seam component and a factory to manage your entites (a la EntityHome/seam-gen) rather than explicitly outjecting objects (but outjection has performance benefits). -
3. Re: Component Architecture instead of traditional Layers
pmuir Jan 19, 2008 5:05 PM (in response to ruettimac)"brachie" wrote:
In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong..
Why?
The following questions are in my mind:Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)?
This seems reasonable, and is the approach we take with seam-gen (using EntityHome for scaffolding).Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page?
This strikes me as a bad idea and hangover from older design patterns.Or would it be good to have one SFSB per use case of your application?
This is, IMO, another very valid approach. It could easily be combined with your first suggestion (an EntityHome for each entity, a component for a use case can call the EntityHome as necessary). -
4. Re: Component Architecture instead of traditional Layers
ruettimac Jan 20, 2008 4:55 AM (in response to ruettimac)Hi,
I tried a small example today (with glassfish) and failed to create it. There is a thread and a JIRA-Issue failed against this problem:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123592
and
http://jira.jboss.org/jira/browse/JBSEAM-2430
What's happening here is, that the beans are not found in JNDI:Caused by: javax.naming.NameNotFoundException: No object bound to name java:comp/env/trainingplatform/CustomerPreferencesAction/local at com.sun.enterprise.naming.NamingManagerImpl.lookup(NamingManagerImpl.java:834) at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:173) at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:396) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.jboss.seam.Component.instantiateSessionBean(Component.java:1287)
But If you look at the startup debug lines, you see that the component is bound to this JNDI-Entry:Component: customerPreferences, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN, class: ch.hcrtraining.trainingplatform.customer.facade.CustomerPreferencesAction, JNDI: java:comp/env/trainingplatform/CustomerPreferencesAction/local
Something strange goes on here. Since I have not Scope.Session, even the proposed @Startup does not work.b) Are there any problems regarding the different seam scopes like CONVERSATION and long running CONVERSTAION scopes beans?
My concerns are regarding the transaction handling of the wired components. Is the transaction management of the caller master? Otherwise, the called component can open and flush the transaction ...
Regards,
Cyrill -
5. Re: Component Architecture instead of traditional Layers
brachie Jan 20, 2008 10:40 AM (in response to ruettimac)@Pete: thanks for the answer! :-)
"pete.muir@jboss.org" wrote:
"brachie" wrote:
In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong..
Why?
I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A.
The following questions are in my mind:Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)?
This seems reasonable, and is the approach we take with seam-gen (using EntityHome for scaffolding).Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page?
This strikes me as a bad idea and hangover from older design patterns.Or would it be good to have one SFSB per use case of your application?
This is, IMO, another very valid approach. It could easily be combined with your first suggestion (an EntityHome for each entity, a component for a use case can call the EntityHome as necessary).
Ok, so I would have to inject the EntityHome into my SFSB implementing the use case?
Regards,
Alexander -
6. Re: Component Architecture instead of traditional Layers
ruettimac Jan 20, 2008 10:47 AM (in response to ruettimac)I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A.
If you look at service oriented architectures (like SOA) - that's the way your software components work together. In seam, you inject the components to each other and in a SOA architecture you have some more intelligent components like the ESB which routes the service calls to the right component (maybe version of a component's interface). But if you break/modify a service, the others have to know that. The same as in the old days of CORBA :-)
Regards,
Cyrill -
7. Re: Component Architecture instead of traditional Layers
mirko27 Jan 20, 2008 11:10 AM (in response to ruettimac)About the NameNotFoundException you got.
Search for my posts on the forum and you will find the solution.
You`ll have to declare ejb-reference in ejb-jar.xml when injection EJB. -
8. Re: Component Architecture instead of traditional Layers
ruettimac Jan 20, 2008 1:00 PM (in response to ruettimac)mirko27,
Thanks, you saved my day (frustrations). I saw your post today but did not realise the impact - thought is was about web.xml bindings. Now it works :-)
Regards,
Cyrill -
9. Re: Component Architecture instead of traditional Layers
pmuir Jan 21, 2008 5:27 AM (in response to ruettimac)"brachie" wrote:
I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A.
Umm. This is why you define an API? I think coupling that loosely is impossible (your components need to interact!).Ok, so I would have to inject the EntityHome into my SFSB implementing the use case?
Yup.