Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Assurance Dilemma
Building a high-assurance system means building a system for scalability, reliability, availability, maintainability, security, and perhaps safety. Using EJB can actually buy you a lot because you can accomplish this goal much easier than without EJB. However, the standard mechanisms for doing so in a practical matter are few and limited.
In a sense, scalability and availability are provided to the application developer in terms of thread, instance, and communications resource management that is transparent to the bean implementation. However, other mechanisms, such as clustering, can lead you into vendor-specific design considerations. For example, creating clustered EJBs will not only require tweaking vendor-specific deployment descriptor parameters, but it also will involve employing certain design restrictions and considerations within an EJB implementation and client so that EJB clustering is even possible.
Security is also another area in which creating truly secure EJB applications can rely on many vendor-specific features. As you saw in the previous article, authentication is one such area in which standards have been weak. I've actually even encountered situations in which a vendor associated a security identity with an EJB client by associating client identity with the thread in which the client was initially authenticated. A call from the same end client but from within a different thread would require reauthentication. Needless to say, this was a problem when the clients were accessing the EJB tier from within a servlet/JSP Web tier in which subsequent client requests often occur from within different thread contexts. Also, very often the true security of an EJB application is driven by vendor-specific deployment descriptor and vendor-specific server configuration parameters—not to mention being driven by sound application design for security.