Separating Web Container from Application Container

[logankiefer]

From my readings of Seam it appears it will work very well if the web and app container are in the same process. However, what if any changes would need to occur if the containers are in separate processes for scalability or other reasons?

[gavin.king]

Seam does not work in this case. However, this architecture is always *less* scalable, not more scalable.

[logankiefer]

From your experience, can you think of any reasons someone would want to separate the two apps? The reason I'm asking is because we currently use JBoss and Tomcat in separate processes. I was told that the architect at the time needed to architect it this way a while back (a few years ago) in order to use Tomcat with JBoss. However since Tomcat and JBoss can work in the same process today we are going to look at putting them both back in the same process. At which point Seam would be an ideal candidate. Of course I'll have to defend that we will never have the need to separate the two apps into separate processes again. Based on your input (it's less scalable) that is one good point. The only other reason to separate, that I can think of, is if in the future we choose a web container and application container that are can only be used together in separate processes. Of course I think that is a weak reason to not use Seam since most popular application containers today integrate with popular web containers.

Thanks in advance!

[gavin.king]

Some people claim that there are security advantages to this separation, but I have never found these arguments especially convincing. We always recommend running Tomcat inside JBoss AS.

[tschnoelzer]

Hi folks,

security is the reason why we have to move one of our projects from seam to shale. Financial institutes have a security policy with apache - tomcat - jboss - db. So someone who "reaches" the tomcat can "only" call the remote interfaces on jboss not more.

I vote for something like an "seam-proxy" to connect servlet container to remote enterprice layer, knowing that there are several design issues blocking this.

timo

[gnulp]

you are right - security in financial area is always designed like that, that the web-tier must be (physically) seperated from the business-tier. running jboss as well as tomcat + business-tier in the same "security-zone" is usually not allowed. Usuallay the web-tier should also not have direct db-access at all !

What you can do at the moment is to seperate web-tier and business-tier by adding another layer using "remote-interface"-Services that are directly integrated into seam-sessions and can comunicate to the business-tier. The only thing you should not use is the direct connection to entity-objects + entity-manager, because this requires direct database-access from the web-tier (which will never be allowed in financial area). The more happy we are to have POJO-Objects that can be traversed between web- and business-tier with all its disadvantages - but security is more important than design-simplification ...
The only thing I realy doubt, is the integration of jBPM, because there I have again a direct database-access - and currently I don't see where I can seperate that into a "remote-layer" ... Maybe the suggested seam-proxy would be an idea ...

thx

[gavin.king]

I vote for something like an "seam-proxy" to connect servlet container to remote enterprice layer, knowing that there are several design issues blocking this.

You are confusing two entirely different things.

(1) use of remote EJBs as backend services
(2) use of local EJBs in the webtier (as in Seam)

Of *course* you can still call a remote EJB from the local EJB in the webtier. There is most certainly no reason to ditch Seam in order to achieve this. (Whether this really makes you more secure is debatable.)


security in financial area is always designed like that, that the web-tier must be (physically) seperated from the business-tier.

This is certainly not true, I have worked in major banks with no such policy (and yes, I am talking about *internet* facing applications). But if you have such a policy, simply locate your business logic behind remote EJBs or web services.

[gnulp]

Hmmm - I just know this security policy from several different banks I worked for - may be there is also different approaches.
In other words it is not important whether we think if the security is better or not - there are banks that believe in that way of security. So we should take that into account in our design approach ...

And yes - you can perfectly use local EJBs as in Seam together with remote EJBs to connect to a business-tier, but what about jBPM ? I haven't tried it, but from my point of view it is directly connecting to the database without "developer-knowledge" - it is done implicitly - or am I wrong ?

[gavin.king]

When jBPM is used for pageflow, it does not need any database.

When jBPM is used for business process management, then yes, it needs to connect to its database. The jBPM database does not need to be the same database you use to store financially critical data, however.

[epbernard]

On a side note. Securing the web tier and split it form the DB can be done this way:
Apache <-> FW <-> Java container <-> DB

It has the second advantage to render static content (arguably) more efficiently

[logankiefer]

If you have an architecture (rough picture below) where you have Router/Firewall server that protects and load balances between servers(where web and app containers are in same process on each server) I can see security being met and Seam can be used since Tomcat/JBoss are in the same process thus JSF and Local EJB's can be used. Then Local EJBs can make any remote service calls it needs.


Router/Firewall<->Tomcat/JBoss<->Database, Other Remote Services