Java Reference
In-Depth Information
6.3.4. Using BMT effectively
CMT is the default transaction type for EJB transactions. In general, BMT should be used
sparingly because it's verbose, complex, and difficult to maintain. There are some concrete
reasons to use BMT, however. BMT transactions need not begin and end in the confines of
a single method call. If you're using a stateful session bean and need to maintain a transac-
tion across method calls, BMT is your only option. But things get complicated because you
can't call a bean that uses CMT, and one BMT bean can't pass one programmatic context
to another bean. In addition, it's easy to ignore exceptions and not roll back or commit a
transaction. This is illustrated in listing 6.3 where the last exception doesn't issue a roll-
back method.
One argument for BMT is that you can fine-tune your transaction boundaries so that the
data held by your code is isolated for the shortest time possible. Our opinion is that this
idea indulges in premature optimization and you're better off refactoring your methods to
be smaller and more specific. Now that you have a firm grasp of transactions, let's turn our
attention to security.
6.4. EJB security
It's hard to overemphasize the importance of security in an Enterprise application. Whether
the application is hidden behind a corporate firewall or accessible via the web, someone is
always interested in causing mischief or worse. Security falls into two modes: making sure
users have access only to data and operations for which they're credentialed and ensuring
that hackers can't circumvent application security mechanisms.
Security must be approached from both the view and the business layer. Just because a user
can't access a page doesn't mean that the business logic couldn't be invoked. Hackers have
successfully queried many AJAX web services that were meant only for restricted pages or
for users with different roles. One of the benefits of EJB is that it has an elegant and flex-
ible security model. Using this security model, you can not only lock down the view but
also ensure that methods on an EJB are restricted.
The approach taken with EJB security is similar to the one taken with transactions: you can
choose from either declarative or programmatic security. It's not a binary decision; you can
Search WWH ::




Custom Search