architecture

[measwel]

If you were to start a new webapp project right now, what technology would you choose?
The general requirements are:

- Application has to be able to handle 1000+ concurrent users.
- New developers must be able to learn the technology quickly

Would you choose:

Struts 2.1.6 or JSF 2.0 or maybe something else?

What other technologies would you use to ease development work?

What technologies would you not use?

Thanks.

[Mike Mo.]

Choosing between Struts or JSF is a shallow problem view. It's like deciding
between diesel or gasoline when buing a car. For me it it really a secondary
decision although I like modern turbodiesels. However for real vehicle
performance it's wiser to make decisions on more factors than just those.

I'm not meaning to start wars, I prefer JSF, but JSF itself doesn't solve
much yet. So I use JSF + Facelets + Seam + Spring. Other layers depends on
the project type.

Note that learnability doesn't necessarily mean productivity. IMHO struts
application tend to be a little bit easier to understand because it's
processing model is simpler. JSF promotes better programming patterns but is
more sophisticated. I must admit that when JSF appeared on the scene it
lacked productivity. We produced struts or webwork website much faster.
However after Facelets, Seam and numerous JSF based frameworks and
components arrived JSF's productivity jumped over Struts.

-- Mike


-----Original Message-----
From: measwel [mailto:marek_karczewski@...]
Sent: Sunday, September 06, 2009 7:25 PM
To: users@...
Subject: architecture


If you were to start a new webapp project right now, what technology would
you choose?
The general requirements are:

- Application has to be able to handle 1000+ concurrent users.
- New developers must be able to learn the technology quickly

Would you choose:

Struts 2.1.6 or JSF 2.0 or maybe something else?

<cut>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[measwel]

Thank you Mike,

That is exactly the type of architecture I was thinking about; jsf 2.0 + seam + facelets + spring + hibernate. The only thing I was concerned about, was the scalability of jsf 2.0. I understand, that it should not be a problem, as long as the applicaton is not ill-designed. I am trying to get my IDE set up for using these technologies right now.

Take care,
Marek

[SnowWolf Wagner]

We utilize Struts 2.1.6 with the JSF plugin for when we want some of  
the features of jsf. While it is true that you can produce a jsf app  
faster today than a struts2, the struts app will preform better and  
use less resources. So the question the old one of balancing dev time  
vers long term operational cost.

T SnowWolf Wagner

On Sep 7, 2009, at 6:03 AM, measwel <marek_karczewski@...>  
wrote:

>
> Thank you Mike,
>
> That is exactly the type of architecture I was thinking about; jsf  
> 2.0 +
> seam + facelets + spring + hibernate. The only thing I was concerned  
> about,
> was the scalability of jsf 2.0. I understand, that it should not be a
> problem, as long as the applicaton is not ill-designed. I am trying  
> to get
> my IDE set up for using these technologies right now.
>
> Take care,
> Marek
> --
> View this message in context: http://www.nabble.com/architecture-tp25319857p25328026.html
> Sent from the java.net - webwork users mailing list archive at Nabble.com
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[measwel]

How big is the performance difference in your estimation? Where is it located mostly; speed? memory usage? disk usage?

[Mike Mo.]

Well this is true that JSF builds a sophisticated page model, which may
result in dramatic performance degradation. Many people noticed poor
performance when dealing with large data tables.
JSF compared to ordinary JSP perform noticeably slower. The point is what
differences we talk about. For example - when we moved one of our
applications from webwork/JSP to JSF we noticed that the response time was
sometime 2 times longer, 8ms more CPU processing per request by average. If
we did that on a machine already serving more than 100 requests per second
we would probably feel the difference. However, because we served 3-4
requests per second the difference was barely observable.

On the other hand - making attractive, dynamic AJAX interface was really
much simpler using JSF. Struts AFAIK (I rarely use it now, so I might have
missed something) don't have any notion of UI components. It won't help your
application to deal with UI changes. So building anything AJAX results in
writing two applications: one server side, and one javascript based client
side. And - by the way - this often performs better because you move part of
the application state to the browser and never store it on the server.

IMHO computing power expands much quicker than manpower, that's why less
performing solution often win.
Regards,

-----Original Message-----
From: SnowWolf Wagner [mailto:snowwolf@...]
Sent: Monday, September 07, 2009 12:26 PM
To: users@...
Subject: Re: architecture

We utilize Struts 2.1.6 with the JSF plugin for when we want some of  
the features of jsf. While it is true that you can produce a jsf app  
faster today than a struts2, the struts app will preform better and  
use less resources. So the question the old one of balancing dev time  
vers long term operational cost.

T SnowWolf Wagner

On Sep 7, 2009, at 6:03 AM, measwel <marek_karczewski@...>  
wrote:

>
> Thank you Mike,
>
> That is exactly the type of architecture I was thinking about; jsf  
> 2.0 +
> seam + facelets + spring + hibernate. The only thing I was concerned  
> about,
> was the scalability of jsf 2.0. I understand, that it should not be a
> problem, as long as the applicaton is not ill-designed. I am trying  
> to get
> my IDE set up for using these technologies right now.
>
> Take care,
> Marek
> --
> View this message in context:

http://www.nabble.com/architecture-tp25319857p25328026.html
> Sent from the java.net - webwork users mailing list archive at Nabble.com
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[SnowWolf Wagner]

It depends on the jsf components used. They tend to require more  
memory and CPU than the non-component based counterparts. The problem  
with the compairison is that with struts you have access to  
everything. That means when you find areas that need to be changed, it  
is easy to do it. But with an component framework much of what is  
happining is hidden and can't be changed. Further, the more complex  
the jsf component the more resouses it will take.

As for disk space. Both approches use about the same.

T SnowWolf Wagner

On Sep 7, 2009, at 7:21 AM, measwel <marek_karczewski@...>  
wrote:

>
> How big is the performance difference in your estimation? Where is  
> it located
> mostly; speed? memory usage? disk usage?
> --
> View this message in context: http://www.nabble.com/architecture-tp25319857p25328916.html
> Sent from the java.net - webwork users mailing list archive at Nabble.com
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[SnowWolf Wagner]

Struts 2 does support Ajax and rich interfaces. There are several  
plugins for this. They include dojo, yui, and others. While the yui is  
not complete it is very usable. You can write the sturts actions to  
return json and use whateven Ajax framework you want.

The 2.1.6 release made alot of changes to how struts handles dojo and  
Ajax.

As for your numbers, we have seen similar numbers. But the apps I am  
working have 300-500 request a second during peak times. Further, the  
same glassfish server is handling 120-180 webservices calls for 3rd  
parties. For our webpages to be slowed down and take twice as long  
would not be acceptible to the client. In fact the client complains  
about the performance now (2-3 secs per page).

T SnowWolf Wagner

On Sep 7, 2009, at 7:38 AM, Michał Mosiewicz <mimo@...> wrote:

> Well this is true that JSF builds a sophisticated page model, which  
> may
> result in dramatic performance degradation. Many people noticed poor
> performance when dealing with large data tables.
> JSF compared to ordinary JSP perform noticeably slower. The point is  
> what
> differences we talk about. For example - when we moved one of our
> applications from webwork/JSP to JSF we noticed that the response  
> time was
> sometime 2 times longer, 8ms more CPU processing per request by  
> average. If
> we did that on a machine already serving more than 100 requests per  
> second
> we would probably feel the difference. However, because we served 3-4
> requests per second the difference was barely observable.
>
> On the other hand - making attractive, dynamic AJAX interface was  
> really
> much simpler using JSF. Struts AFAIK (I rarely use it now, so I  
> might have
> missed something) don't have any notion of UI components. It won't  
> help your
> application to deal with UI changes. So building anything AJAX  
> results in
> writing two applications: one server side, and one javascript based  
> client
> side. And - by the way - this often performs better because you move  
> part of
> the application state to the browser and never store it on the server.
>
> IMHO computing power expands much quicker than manpower, that's why  
> less
> performing solution often win.
> Regards,
>
> -----Original Message-----
> From: SnowWolf Wagner [mailto:snowwolf@...]
> Sent: Monday, September 07, 2009 12:26 PM
> To: users@...
> Subject: Re: architecture
>
> We utilize Struts 2.1.6 with the JSF plugin for when we want some of
> the features of jsf. While it is true that you can produce a jsf app
> faster today than a struts2, the struts app will preform better and
> use less resources. So the question the old one of balancing dev time
> vers long term operational cost.
>
> T SnowWolf Wagner
>
> On Sep 7, 2009, at 6:03 AM, measwel <marek_karczewski@...>
> wrote:
>
>>
>> Thank you Mike,
>>
>> That is exactly the type of architecture I was thinking about; jsf
>> 2.0 +
>> seam + facelets + spring + hibernate. The only thing I was concerned
>> about,
>> was the scalability of jsf 2.0. I understand, that it should not be a
>> problem, as long as the applicaton is not ill-designed. I am trying
>> to get
>> my IDE set up for using these technologies right now.
>>
>> Take care,
>> Marek
>> --
>> View this message in context:
> http://www.nabble.com/architecture-tp25319857p25328026.html
>> Sent from the java.net - webwork users mailing list archive at Nabble.com
>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...