aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Web Container on it's own or with application server Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Web Container on it Watch "Web Container on it New topic
Author

Web Container on it's own or with application server

Martin Donaghy
Greenhorn

Joined: Jun 27, 2005
Posts: 6
Hi there. I've been doing J2EE development for a while. On past projects we have always used the three tier approach - web container for presentation logic, application server for business logic and oracle/sql server as our data storage layer. My current project entails setting up a J2EE architecture for casting votes in an election. It must support multiple access methods like SMS, IVR, web, idtv, kiosk. After alot of research on the web there seems to be a trend towards not always deploying an application server in your setup. The business logic in our application is not too complex so we were thinking of going with apache, tomcat, struts, hibernate as ADO layer, and sql server as the database (this tie in is historical otherwise we would go with Oracle). We plan to separate the layers into xslt/xml presentation, business logic, xml handling, hibernate handling. Apparantly, this setup should be enough. What are your thoughts? I know alot people are against using ejbs just cause they were used in the past. Transaction handling,security, scalibility would be the factors I would be most concerned with. There is a possiblity in the future that other applications may be integrated with this one so that may move us in the direction of using an application server. I just don't want to deploy one unless there is good reason for. Everyone seems divided in the forums. Opinions please??

Thanks in advance.
Martin
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Martin,

I do agree with you: don't deploy an ejb, unless it is really needed. Hibernate is the most desirable choice for the persistence layer at this time as well. From my experience I would tell you that Struts is more trouble than needed. Consider using Spring and its MVC implementation. In my opinion this is much simpler then Struts, while it provides you at least the same benefits.
Regards.


I think, therefore I exist -- Rene Descartes
Martin Donaghy
Greenhorn

Joined: Jun 27, 2005
Posts: 6
Thanks Valentin!

Well I think we are going to stick with struts for now as we have more experience in it. We do plan to avoid ejbs unless absolutely necessary, but one things always worries me - will a web container only implementation scale sufficently for a high volume user base such as an election?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The stock answer always is "EJB gives you more scalability" but I'm not really sure what kind of scalability is meant (vertical in the box or horizontal across boxes) or the reason. Anybody know the details?

For vertical scalability, you could likely write app specific code to handle your needs more efficiently than a generic container. (Of course you could also write much worse code ) Spring and Hibernate are all over the news today; I haven't had any hands-on, but I'd look closely at them for a new project.

For horizontal scalability make sure you can grow your app from a single server into a cluster. Avoid all state, including the session object unless your servlet container can persist it or synchronize it across the cluster.

Any of that help?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704

will a web container only implementation scale sufficently for a high volume user base such as an election?

This is a very good question and you are more than entitled to ask it. If you take a look at the ejb architecture you�ll notice that the strongest assets, with respects to scalabilities are the ejb instance pooling and the ejb-clustering capabilities. As for the first one I really believe that it is more �j2ee propaganda� than real benefits. On the other hand a servlet that is not single threaded can perform at least as good as any pool of ejb instances.
As for the ejb-clustering, at a glance it looks like using cluster aware stubs with ejbs is more efficient than load-balancing web applications, but this is not actually the case. The reasons are many, but the most frequent one is that usually the clients don�t talk directly to the ejb (rmi clients) they mostly go through a web presentation layer. Also very frequently the web server and the ejb container run within the same jvm, which makes web components and ejbs to be collocated. This will force the container to use internal algorithms, specific to collocated objects, which basically will redirect requests coming from the web layer (or other components) to ejb components located on the same computer. This basically overrides (and there is no way to defeat this algorithm) any initial load balancing planning. Bottom line is that in order to provide true load balance, architects are forced to use either a hardware loadbalancer, or configure special web proxies to route web request to every server instance in the cluster. The ejb clustering facilities are practically ignored and all the great work behind the cluster aware ejb stubs is not even used.
Of course this is only my opinion, but nothing can stop you to develop a prototype of your application and use heavy load testing for proving whether your architecture is right what you need or not.
Regards.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Unless you need messaging (one of the most compelling reasons for EJB), transaction management, concurrency, security (down to method level) and some other services, then don't use EJB. You can always upgrade to EJB if the need arises. But do prepare for this: I would ensure that the exception handling strategy is designed to be EJB-compatible, so make sure that you know the differences between application and system exceptions. And check out what the EJB spec says about programming restrictions. For instance, the use of the java.io package is banned, which appears troublesome. But if you just want to read in a properties file, then why not use ResourceBundle to do this. And bear in mind that some of the restrictions are in place to protect you in case your application should run in distributed VMs. For instance, a static variable may work in a single VM but not work in multiple VMs. All of this applies to EJB and non-EJB applications.

I would strongly recommend designing a three-layer architecture which is as close to ideal as possible. Each layer needs to be clearly separated. I personally favour the use of certain key design patterns: the Business Delegate pattern to shield the client (your Struts Actions) from the Business Logic layer, the Service Facade pattern to hide the implementation of the business logic and the DAO pattern to hide the persistent layer. Other patterns can often be usefully employed, don't go wild - just use the ones which you need.

Make sure that your business objects can work with any client and know nothing of the persistent layer. And I would ensure that only objects are passed into, and returned from, the business objects. (So do your XML marshalling, unmarshalling and rendering via XSLT stylesheets in the Presentation layer.)

So, your layers might contain these:

Presentation
------------
Struts
Use cases (if any)
Business Delegate
JSPs
Servlets
XSLT
Browser, SMS, etc

Business Logic
--------------
Service Facade
Business Objects

Data Storage
------------
DAO
Hibernate


Your web application should scale very well, you do not need EJB for this. I am not too familiar with Tomcat as I haven't touched it for three years, but I believe that you can cluster using JavaSpaces technology.

One last thought: if you think that there is a fair chance that you will finish up with an EJB application, then life will be easier in the end if you start out with a server such as WebLogic Server as it includes both a servlet container and an EJB container.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Martin Donaghy
Greenhorn

Joined: Jun 27, 2005
Posts: 6
Thanks guys! All very useful opinions! One thing does worry me. Transaction management and concurrency is mentioned quite a bit when dealing with these questions. Our system needs to support between 1000 and 10000 concurrent users casting votes. The cast vote process will entail selecting a candidate on the front-end, submitting vote which will be sent to an electronic ballot box (to external system in xml using web services), and finally marking the voter as having voted in our local database. The more I think about it we need strong transactional support as all parts of this process must complete successfully before the votes is deemed as 'cast'. What do you think? Can you code this support in POJOs? Or is that too much hassle that would be easier done by Spring or EJB container?
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Martin,

Generally speaking, with regard to transaction management you can use either JTS/JTA or JDBC transactions. As much as I can understand your system it occurs to me that you don’t really need to implement global transaction and therefore using JDBC transactions looks like a pretty optimal choice in your case. If you chose this path, then the transaction management will be entirely controlled by your underlying database and the right question to ask is actually whether or not your database has such OLTP capabilities. If the answer is yes then you can use POJOs for your implementation. Otherwise you either have to change the database, or to look at your container and check what other type of concurrency strategies provides (like read-only EJBs) that you can use to improve the performances of your system. However this requires more work for you to do. On the other hand using Hibernate you can easily configure the transaction manager you need.
Regards.
Martin Donaghy
Greenhorn

Joined: Jun 27, 2005
Posts: 6
Hi Valentin,

What if the web service invocation to send the vote to an electronic ballot box (external system) must be part of the transaction? This would surely be outside what Hibernate does? If the vote is not cast on this external system we can't mark the voter locally as having voted. What do you think?
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Are you saying that the sending of the message and the local update are part of the same transaction? If so, should the local DB update fail you will want to rollback both the DB update and the sent message. But if that message had already caused some update in the ballot box, is this of concern to you? If so, then you need to take some form of compensating action as the ballot box update cannot form part of your ACID transaction.

Have you figured out how to do all of this from within Tomcat? As I've said, I'm not that familiar with this product, so I can't offer an opinion. I'll confess that, being mostly interested in EJB, I'd probably invoke the web service (probably via an RPC call) and DB update from a stateless session bean. So, this means a JTA transaction under the covers.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Looks like things are little bit more complicated than they seem to be. Hibernate could be configured to support global transactions with session ejbs and you might like taking the advantage of this nice feature. You might also considering asynchronous message processing and use a message fa�ade as well. Either way it looks like an ejb container could be very useful in your case.
Regards.
Martin Donaghy
Greenhorn

Joined: Jun 27, 2005
Posts: 6
Yes after considering all the options we have decided to use an ejb container. The primary driver of this is the need for high volume user concurrency, transaction management and the ability to performance tune the container setup (not sure how much can be tuned via the web container only). Anyway, a future requirement will be to integrate one of our other applications with this platform application processing layer so it makes sense to have the application server in place now. We have opted for JBoss which should also make it easy to expose ejbs as web services. We still intend to use hibernate for our DAO layer.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Web Container on it's own or with application server