This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am considering the pro's and con's of allowing an application client to access either the web or the ejb container as both are possible under the J2EE spec.
The benefits of connecting to the web tier is that only the web tier needs to be exposed to the outside world in the DMZ while the application tier can remain buried within the organisations security infra-structure behind inner firewalls. Of course this is a benefit only if the application client connects accross the internet - if it connects across a secure intranet I don't think it is a benefit as there is no exposure to the outside world.
The advantage of connectivity directly to the ejb container is that of greater performance (as the overhead of the web container is gone) and greater availability. If the web servers crash application clients can still access the system.
Does anyone have any thoughts on this (ie as to whether my reasoning are correct or not) and/or can throw any other light on this dilemma?
I have in fact taken up the idea of a J2EE Application Client as opposed to a Java stand-alone client - it does all the work for me and is configurable through its deployment descriptor. It also can use RMI-IIOP/SSL without any additional work.
I think also there is a good adavantage of increased availability if you access the ejb container directly - if the web servers crash the client application can still access the application. You can easily use Java Web Start. The drawback is that the ejb-container must be in the DMZ if the application client is accessing it across the internet.
I think this sounds right, but any thoughts are good.