I have experience in developing applications in Struts 1.2 and was part of a very large operation. In that we used Struts, Spring and Hibernate.
Now, I have got a client who is investing on developing a very (very) large project which would have a application server cluster and hopefully a database cluster as well. We are expecting 10s of 1000s of concurrent users.
Since it's truly distributed, I was thinking of going ahead with Struts2 and EJB3. I am not very convinced of using Spring and Hibernate for this much of a larger project.
But unfortunately I didn't get a proper tutorial which explains the use of EJB3 with Struts2. Most of them are using Spring and Hibernate, and 1 article was explaining the use of Guice.
What I don't understand is, Struts2 is developed as a web framework for the Java EE platform and why it doesn't directly support EJB3 integration.
Please do let me know whether I am missing something here. Have I not understood something which is obvious.
Thanks and regards, Ransika.
SCJP 1.4, SCMAD 1.0<br />SCWCD, SCBCD (in progress)
...but still don't you think there has to be a way to integrate EJB3 directly to the Actions, with out Spring support?
Struts is a Model-View-Controller-based framework that only has implementations for the Controller and the View parts.
If you need to a Controller, you can use Struts to build it.
If you need a GUI or View, you can use Struts to build it.
In regards to a Model application, you cannot use Struts to build it.
Enterprise JavaBeans exist for building Model applications.
To preserve and enable loose coupling between application components, there shouldn't be any way to integrate Struts and EJB. To do so, will enable application developers to design very poor applications and which then in turn give the frameworks a bad reputation.
In order to effectively use Struts and EJB in a single application, one must learn the Model-View-Controller design pattern and have the ability to integate them in the best possible way for a specific set of requirements. Each situation is different. The "integration" occurs in the code that is written by the application developer, it is not written in the Struts framework or default implementations.
So, there is a way to integrate EJB and Struts ... you have to write the code for it. Note, the Struts Action classes are part of the Controller and should not have any business logic coded in them. Check out the Business Delegate design pattern for more info.
Good luck! [ December 18, 2008: Message edited by: James Clark ]
You make it sound like you can't use EJB's in a Struts application.
To call something a "Struts" application in not really correct. Struts is only a MVC-based framework for building the Controller and View parts of an application. Struts can certainly be a part of an application that also uses EJB components. The point I try to make is that they are different technologies that are used to build one application but they are not inherently coupled with a specific integration.
As I mentioned, the application developer has to code the integration between the two technologies. It should not, and is not, hard-wired in the frameworks.
If you build a business application with a Oracle DBMS, MQ Series message server, EJB, Struts, and a COBOL legacy app. It would't make any sense to simply refer to this as "a Struts application." For that matter, it could also be called a "EJB" application", or an "Oracle" application or a "J2EE" application.
The concrete that is used to build the rooftop parking lot is different than the windows of the building. Both "windows" and "concrete" are used to biuld a single building. However, they are not integrated, or they are no out-of-the-box dependencies that force you to design a certain way.
The same is with Struts and EJB. They both can be designed to work together. This is the creative challenge to the application developer, not something the framework developer forced upon you.
In regards to the J2EE programming model, Struts-based code is on the Presentation tier and EJB-code is on the Business tier. The syntax-level connection never happens between the two components. A Business Delegate is the connection between the two.
Three-tier programming and programming flat, one-level applications are a bit different. Three-tier programming skills are required to build MVC-based appplications. When you start to cram everything in a Struts Action class, you typically will be limited.
Once can certainly cram EJB code in Struts Actions and be ok for small local applications or school assignments. However, in real-world enterprise scenarios, this is not acceptable. [ December 18, 2008: Message edited by: James Clark ]
To call something a "Struts" application in not really correct.
The phrase is in common use. It's an app that uses struts. What should one call it?
Originally posted by James Clark: The point I try to make is that they are different technologies that are used to build one application but they are not inherently coupled with a specific integration.
I tried to make that same point in my first post in this thread.
Joined: Apr 16, 2008
I think it is more concise to "label" or "describe" Struts-based components or modules. Struts is a MVC-based framework. Struts is a skeleton only. An organization uses the skeleton to build a customized web module. At this point the module belongs to the organization. And at this point, the "Model" component which interacts with the "Struts" component really has nothing to do with "Struts."
If I build a business application using EJB or POJO objects, I will not call it a Struts application, even if I also build a GUI with Struts API.
There is often a difference between marketing and Internet hype, i.e. Google search results, and what actually makes sense or is accurate. [ December 18, 2008: Message edited by: James Clark ]