General Performance concerns on presentation and business la

[phpguy99]

Hi,
My typical application development is the presentation layer, php, mostly does one to two calls to application server using xmlrpc/soap.

Comparing this to Seam/JSF style of very tight integration between presentation and business logic by using backing bean, my current style of presentation layer seems to be more efficient (apart from soap overhead).
So my 2 similar questions:
1. Is Seam/JSF only good when JSF and the backing beans are in the same JVM?
2. Seam provides very tight integration between JSF and business logic, does it mean Seam is promoting the unification of presentation and business layer into a single environment (jvm)?

Thanks.

[christian.bauer]

1. Yes
2. Yes

[phpguy99]

What is your take on commonly accepted practice to physically separate business and presentation layer for reasons like:
- security: presentation layer is the only one that gets exposed to the internet and it take hackers more layer to crack.
- scalability: easier to scale either/both presentation and business layer if they are separated.
- easier division of labor: presentation and business-logic developers only care about their components and they can become more skillful/specialized in their area.

Thanks so much in advance.

[fhh]

Well, I am not a Seam developer but my stance on these issues is this:

- security: presentation layer is the only one that gets exposed to the internet and it take hackers more layer to crack.

Once the machine hosting the view is hacked your are usually lost anyway. You usually need some direct access between the view layer and the database (fast lane pattern, authentification ...). Once they can hijack a machine with a ddatabase connecetion everything is lost ...

- scalability: easier to scale either/both presentation and business layer if they are separated.

In 99% of all projects improving the code has a far more dramatic effect than simply scaling out a poorly designed and implemented project. So it is usually not necessary to distribute the layers over different machines. If it is it is usually possible to cut the application into different functional units that can be distributed over different machines.

Even once these options show to be insufficient the costs of RMI make (IMHO) distributing view layer and business code over different machines hardly worthwhile. Simply scaling out the combined view/business layer is (IMHO) the simpler approach.

- easier division of labor: presentation and business-logic developers only care about their components and they can become more skillful/specialized in their area.

Ease of division of labour is an issue of good design which should take place before the actual implementation is happening. A good design can not and should not enforced by choosing a certain technology.

Regards

Felix

[tonylmai]

Seam may be promoting the unification of presentation and business layer into a single environment but does not limit us to this model. For some application, it may not a bad idea to unify these layers for simplicity sake.

I use a service locator and a facade with RPC to communicate with the my business layer which resides on a different JVM. Call me old school but I still believe in the separation of the presentation and business logic. ;-). And I have no trouble using Seam this way.

And yes I strongly believe it would give me the 3 points you mentioned (security, scalability, easier division of labor or domain expertise separation).

My 2 cents.
-tony

[jim.barrows]

"phpguy99" wrote:
What is your take on commonly accepted practice to physically separate business and presentation layer for reasons like:
- security: presentation layer is the only one that gets exposed to the internet and it take hackers more layer to crack.

But is this really true? Since your business layer must be exposed to the presentation? While it is possible to lock thigns down quite tightly, once the front server is compromised, so are any holes you've opened.
However, I think you're missing something about the design of J2EE apps. J2EE has seperatio of concerns and 3+ layer architecture for quite some time. The backing beans are supposed to talk to your business logic layer.

"phpguy99" wrote:

- scalability: easier to scale either/both presentation and business layer if they are separated.

J2EE can scale in 4 different areas, and with a fairly fine granularity. I can have a particular EJB on a server dedicated to itself, if necessary, or a whole bunch. Same with a web app. Since EJB's carry business logic, I can scale one bit of logic, or lots. I can scale at the database. I can scale the connections to everything.

"phpguy99" wrote:

- easier division of labor: presentation and business-logic developers only care about their components and they can become more skillful/specialized in their area.

Again J2EE has had division of labor for quite some time. It's nice to see someone from the PHP world catch up to us :)
You can't forget that Seam is built on jBPM, Drools, and J2EE. Bringing with it all of J2EE's strengths, while leaving much of it's pain behind. In order understand those strengths, you probably need to go look at all of Sun's J2EE documentation to understand how things are designed, and why SEAM is truly great.

"phpguy99" wrote:

Thanks so much in advance.

Your welcome