How much control on the servlet, how much on stateful session EJB ?

[Jay Sam]

Hi,

our application is built on Servlet/EJB tech.

we are servicing two types of clients: web browsers, and a java application, basically just differing in presentation, not in business logic. Would you make the java
application client use the same servlet that is responsible for
controlling the jsps ? Is this easily possible ? I would personally like
the solution to access the ejb container directly with the java
application client, not going through servlets. In a scenario where web
server (which is also servlet container) and ejb-container (which has
sometimes no servlet-container, and no webserver) are separated, I would
like the servlets to render only for the web clients, the ejb container
handling all business logic, and being "open" to all sorts of clients,
also non-web-based. In such a scenario, would you use the servlets to
communicate to other than web clients ? Even if they reside on the
webserver tier ? Tell me your opinion. I personally do not know how
portable web servlets are. But I think EJB�s are more portable (are they
??), so servlets should be as web-dedicated as possible, and the
ejb-container should be ready to service multiple kinds of clients.

Regards,

Jay
[ March 09, 2005: Message edited by: Jay Sam ]

[Valentin Tanase]

Hi Jay,

Would you make the java
application client use the same servlet that is responsible for
controlling the jsps ? Is this easily possible ?

Actually this is not possible. Servlets were designed to handle http requests and have business methods that can respond to all these very specific http request like doPost, doGet, doDelete, etc. One cannot write RMI/IIOP clients that can directly interact with servlets. Just fantasizing, let’s imagine that we’d like to build a Java swing interface to a servlet based web app. Let’s imagine that your GUI shows several JTextBoxe(s) for updating the database, making http calls to the servlet back-end. In order to do that the application needs to gather user’s input, instantiate an URL or HttpUrl object, connect to the server and send the http request to the server again; no OOP approach. And things will become 100 times more complicated in order to display the server’s response, because there are no implicit session, request/response objects as they are inside of jsp pages. What a mess!

I would personally like
the solution to access the ejb container directly with the java
application client, not going through servlets.

You touched here a very important point: this is one of the reasons why organizations might choose a much complex EJB-centric solution, over a lightweight web-centric architecture. Sometimes it makes sense for that application to have a web interface with the Internet clients and another swing interface for their local users (security constraints and the reach client interface design might lead to this architecture). EJBs present an OOP model to RMI-IIOP clients and even better, they still offer the same implicit middleware services (transaction, security, persistence, concurrency, etc) to these clients.

But I think EJB�s are more portable (are they
??)

Yes this is one of the J2EE aims. However many of the EJB projects chose to implement vendors specific solutions that are not portable across different containers. However this doesn’t happen very often with web-centric applications, which hypothetically speaking, makes servlets "more portable" solutions.

so servlets should be as web-dedicated as possible, and the
ejb-container should be ready to service multiple kinds of clients.

You got that right