J2EE Integration
This document serves to answer a few common questions about integration of Turbine with J2EE technologies including Servlets, EJB, Swing, JMS, Transactions, JNDI, XML, JDBC, JSP, and Security. The short answer is that it is all Java code, and you easily can combine Turbine solutions with J2EE solutions in almost any manner. Turbine is increasingly flexible about what pieces you choose to use or discard.
How does Turbine work with ... ?
| Servlets |
Turbine is a servlet. It is also a set of re-usable components assembled into a framework. Most of Turbine's components can be used in your own Servlets. It is normal for projects to start off with a simple servlet, tacking on various components like Connection Pooling, Cron Schedulers, User Management, Services, etc. That is what we have done as well, however we have done with pluggability as a major concern. Mix and match for use what you want, Ignore the rest. |
| EJB |
Turbine provides a framework for developing web applications - specifically the front end. EJB provides a framework for developing n-tier applications - specifically the back ends - thus Turbine and EJB complement each other well at that level. |
| Swing |
Turbine is the for the web - Swing is not - not applicable. Although there is a new technology SwingML which can be integrated within Turbine. SwingML describes itself as "an effort to create a markup language to render in a web browser JFC/Swing based graphical user interfaces." |
| JMS |
Turbine provides facilities for plugging in other Services - and thus JMS could be plugged in as a service. Even if it isn't plugged in through Turbine's Services facilities, you can still put your JMS related methods into your code. Turbine doesn't prevent you from calling other Java code. |
| Transactions |
There is nothing in Turbine explicitly using the JTS/JTA - but can use EJB and hence these technologies. That belongs in EJB's anyways. :-) |
| JNDI |
Turbine provides access to JNDI via a Service facility. You can always choose to implement your own facility as well (ie: if you have an existing code base that you would like to use, Turbine does not stop you from using it). |
| XML |
Turbine provides support for using and working with XML. Again, nothing preventing you from using XML within Turbine or even sending XML out of Turbine. |
| JDBC |
Turbine provides good support for working with JDBC through the Village API, the Torque Object Relational Tool and its connection pooling facilities. The connection pool is not yet fully J2EE "compatible" in that it does not support DataSources. However, at some point we may choose to implement that. Note, again, Turbine does not prevent you from using your own Connection pooling mechanism, we simply created one because at the time, we needed one and ours works just fine. |
| JSP |
Turbine provides excellent support for using JSP in its model of working - which is based on the Model 2 style with enhancements, such as solving the Action portion of the Model. However, we strongly suggest that you do not use JSP and seek out other alternatives. |
| Security |
Turbine was created long before J2EE was created. Therefore, we needed to implement our own Security Model. This model is based on Users, Roles, Permissions and Object Groups. It is an Access Control List (ACL) based security scheme and can grow to support nearly any level of access control people can come up with. It follows our extensible design pattern and you can use Turbine's code as the basis for any additional security your application requires. |
| Container Managed Security |
You can use container managed security if you wish, and Turbine provides you with mechanism for application managed security, in case you need them. The main problem with container managed security is that it cannot be managed from the inside of the application. Whenever you want to add/remove users to your application (or suite of them) or want to modify user's roles, you need to use whatever tool your application server provides for that. Now, this could work just fine for closed-public applications and intranets, but would be really unacceptable on open-public sites, where the users need the ability to register and receive 'accounts' without human interaction. Currently Turbine supports the latter model - application managed security. This is because if it didn't have it, many people would have to write code to provide it. That's why we created SecurityService in a cooperative effort.
On the other hand, you don't need to write any code to use declarative
container managed security. You can restrict access to the Turbine
servlet with the usual web.xml magic. If you wish to use programmatic
container managed security code, there is relatively very little code to write.
You need to create your own SecureScreens (probably extending VelocityScreen)
and SecureActions that contained code that calls the |