FrameWork
Hi, I just join a new company and they are following the typical J2ee presentation/business/data/eis tier architecture.However, I am a little puzzled by their framework. Among other things, I am particularly border by the following:
1) Their Action object <has a> Command object which
1.1) does the binding to a Stateless EJB using a local interface and
1.2) <has a> DAO object for data accessing to be invoked by the same Sateless EJB using the execute() method.A typical Command Pattern. Our framework has only this 1 EJB for the our application. Each business function in the application is defined in its own Command Class.
2) The logic in the Command object to do the binding does the following:
2.1) get the LocalHome of the EJB from a HashTable using the name of the Stateless EJB.
2.2) If not found, do a Home.create(). Add new LocalHome to the HashTable.
Item 1) seems to result in the mingling of the Presentation and business layer and item 2) results in the obsoletence of the ejb pooling feature of the appl server.
Do you think our framework is J2ee compliant? Thks
Old_dog
[1164 byte] By [
Old_doga] at [2007-10-2 0:08:25]
> Hi, I just join a new company and they are following
> the typical J2ee presentation/business/data/eis tier
> architecture.However, I am a little puzzled by
> their framework. Among other things, I am
> particularly border by the following:
> 1) Their Action object <has a> Command object which
> 1.1) does the binding to a Stateless EJB using a
> local interface and
> 1.2) <has a> DAO object for data accessing to be
> invoked by the same Sateless EJB using the execute()
> method.A typical Command Pattern. Our framework
> has only this 1 EJB for the our application. Each
> business function in the application is defined in
> its own Command Class.
When you say Action, I assume Struts. The Action class is part of the controller, mapping HTTP request parameters into objects that the Command uses. I rather approve of this arrangement, because it separates the Command/Service from the View tier.The Command/Service is reusable. Yes, it has business objects and persistence classes, but that's what it's supposed to have to do its job IMO.
> 2) The logic in the Command object to do the binding
> does the following:
> 2.1) get the LocalHome of the EJB from a HashTable
> using the name of the Stateless EJB.
> 2.2) If not found, do a Home.create(). Add new
> LocalHome to the HashTable.
>
> Item 1) seems to result in the mingling of the
> Presentation and business layer
I disagree - the Command is keeping the two separate. The Action knows about the Command, but not visa versa. You wouldn't want to do the work in the Action class, because that would require HTTP in general and Struts in particular.Bad idea.
> and item 2) results
> in the obsoletence of the ejb pooling feature of the
> appl server.
I'm not sure what's up in item (2). Sounds like they're caching stateless EJBs to avoid having to do the lookup. I don't see the harm, but I don't see the need, either.
> Do you think our framework is J2ee compliant? Thks
Define "J2EE compliant". A lot of core J2EE patterns are anti-patterns in my mind, so I'm not sure that a J2EE compliant endorsement means much.
The important thing here is layering the architecture. Sounds like you have: Struts for the Web/presentation tier, Commands for the service layer, DAOs for persistence, business object models. Sounds right from what you've told me.
What are you proposing as an alternative?
%
PS - Here's my chance to recommend Spring: http://www.springframework.org.
duffymo. Thanks for the reply. I still not sure about item 1). The Command object is instantiated inside the Action object in the presentation layer and pass as a parameter to a generic stateless session bean in the business layer for execution.This design works if everything is running inside one JVM. If the presentation and the business layer runs on its own JVM, I don't think it will work. What do you think?
old_dog
> duffymo. Thanks for the reply.
My pleasure, olddog. Nice question.
> I still not sure
> about item 1). The Command object is instantiated
> inside the Action object in the presentation layer
Yes, I agree.I'd think of the Command object as the service layer. I'm assuming that Command is an interface.
> and pass as a parameter to a generic stateless
> session bean in the business layer for execution.
This part I neither understand nor like. The Command shouldn't be passed to a session bean for execution. Its implementation should lookup and use the SLSB to do its job. There's no need to pass the Command anywhere.
> This design works if everything is running inside
> de one JVM. If the presentation and the business
> layer runs on its own JVM, I don't think it will
> work. What do you think?
If Command is Serializable, there's no reason it can't be passed to the SLSB. But I still don't think it's desirable.
Does every Command have the same interface?
%
Thanks duffymo. The whole picture is coming together for me now. Yes, all my Command implements the serializable interface. The serializable technology is always a blind spot for me. Correct me if I am wrong. Since the Command object is serializable, it can be instantiated from any JVM and be marshalled across JVM for execution upon request yet maintaining the state of the object. So, the Command object is bounding between my Action object in the presentation layer and the Session EJB in the business logic layer like a ping-pong ball whenever its method is invoked. How amazing! What is the downside of this Command pattern. How does it compare with the more tranditional Facade pattern? Thanks
old_dog
> Thanks duffymo. The whole picture is coming together
> for me now. Yes, all my Command implements the
> serializable interface. The serializable technology
> is always a blind spot for me. Correct me if I am
> wrong. Since the Command object is serializable, it
> can be instantiated from any JVM and be marshalled
> across JVM for execution upon request yet maintaining
> the state of the object.
Your understanding agrees with mine. Either we're both right, or we still have some learning to do. 8)
> So, the Command object is
> bounding between my Action object in the presentation
> layer and the Session EJB in the business logic layer
> like a ping-pong ball whenever its method is invoked.
My question is: why is it important to serialize the Command to be run remotely? Why all these distributed objects? What is the EJB doing for you?
> How amazing! What is the downside of this Command
> d pattern. How does it compare with the more
> tranditional Facade pattern? Thanks
"traditional" Facade? I had no idea.
Command encapsulates a request as an object.
Facade provides a unified interface to a set of interfaces in a subsystem, hiding the details of the subsystems from clients.
Is your EJB the Facade in this case?
I'd have a service interface that the controller would talk to. It might have an EJB implementation, but more likely it would not.
%
