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 can choose to use Turbine's solutions to some things or you can choose to use J2EE solutions to some things. Turbine is increasingly flexible about what parts you choose to use and what parts you don't. The reason is because there has been quite a lot of de coupling of the various Turbine components as a result of years of development and use by people all over the world in various different ways. Wow, isn't that cool?
| Servlets |
It is a servlet. It is also a set of re-usable components assembled into a framework. You can choose to work with just the Servlet, you can choose to work with just the components or you can choose to work with both. In a lot of normal development cases, people start off with a simple servlet and tack on various components (like Connection Pooling, Cron Schedulers, User Management, Services, etc.). That is what we have done as well, however we have done it in such a way that it is very pluggable. Mix and match and use what you want to use. 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. |
| JMS |
Turbine provides facilities for plugging in other Services - and thus JMS could be plugged in as a service to that. 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. 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 |