Re: architecture

Struts 2 does support Ajax and rich interfaces. There are several =20
plugins for this. They include dojo, yui, and others. While the yui is =20=

not complete it is very usable. You can write the sturts actions to =20
return json and use whateven Ajax framework you want.

The 2.1.6 release made alot of changes to how struts handles dojo and =20=

Ajax.

As for your numbers, we have seen similar numbers. But the apps I am =20
working have 300-500 request a second during peak times. Further, the =20=

same glassfish server is handling 120-180 webservices calls for 3rd =20
parties. For our webpages to be slowed down and take twice as long =20
would not be acceptible to the client. In fact the client complains =20
about the performance now (2-3 secs per page).

T SnowWolf Wagner

On Sep 7, 2009, at 7:38 AM, Micha=C5=82 Mosiewicz <[email protected]> =
wrote:

> Well this is true that JSF builds a sophisticated page model, which =20=

> 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 =20=

> what
> differences we talk about. For example - when we moved one of our
> applications from webwork/JSP to JSF we noticed that the response =20
> time was
> sometime 2 times longer, 8ms more CPU processing per request by =20
> average. If
> we did that on a machine already serving more than 100 requests per =20=

> 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 =20
> really
> much simpler using JSF. Struts AFAIK (I rarely use it now, so I =20
> might have
> missed something) don't have any notion of UI components. It won't =20
> help your
> application to deal with UI changes. So building anything AJAX =20
> results in
> writing two applications: one server side, and one javascript based =20=

> client
> side. And - by the way - this often performs better because you move =20=

> 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 =20=

> less
> performing solution often win.
> Regards,
>
> -----Original Message-----
> From: SnowWolf Wagner [mailto:[email protected]]
> Sent: Monday, September 07, 2009 12:26 PM
> To: [email protected]
> 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 <[email protected]>
> 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
>> --=20
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>