Craig thanks for the reply. I guess I was not able to articulate my real
question I'll take another crack. I am out to understand the class of
problems that JSF is good for and what is not good for on it's own.
For example, If I was to write an OS I would probably use C not Java. If was
to write a Photoshop clone C++ would be more practical than Java however
Java would be much nicer to use. Back in 1996 Java was so hot we as
programmers looked at it and fell in love with all the cool features and
promises that Java. AT the time I was working in the Computer Graphics
industry and all of us programmers wanted to and hopped we would soon be
leaving C++ behind to build our cool image processing and 3d graphics apps
in Java because is nicer to use than C++. We did some prototypes that cost a
fair bit of time and found out that Java could not be made to work well with
type of apps that we were writing in fact by 1997 it was clear that you
could not write serious graphics software with Java :)
JSF is a tool like any other tool it works very well in certain situations
and not so well in others. What are the ideal places to apply JSF and what
places look like a good idea to apply JSF but may not be. Here are some
examples situations. I would appreciate comments form the community as to
which scenarios below they would apply JSF for and why and which they won't
and why? If not JSF for a scenario what would you choose?
1. Problem: Develop a web mail system
case a: support a company with up to several hundred users
case b: Hotmail.com or mail.yahoo.com
2. Problem: A Community web site
case a: TheServerSide.com
case b: Slashdot.org
3. Problem: Consumer Web app
case a: Stock trading application example etrade.com
case b: Flight search portal example etrade
case c: ebay.com
3. Problem: Corporate Web app
case a: Sales For Automation example: salesforce.com
- lots of separate companies each company with it's data and database
2 to 100's of users per company
case b: Collaboration Web Group Ware
- lots of separate companies each company with it's data and
database 2 to 100's of users per company
Thanks
Adib
-----Original Message-----
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: January 14, 2005 2:18 AM
To: MyFaces Discussion; [EMAIL PROTECTED]
Subject: Re: JSF - Robust? Scaleable? Ready for prime time?
> On Fri, 14 Jan 2005 00:58:22 -0500, Adib Saikali
<[EMAIL PROTECTED]> wrote:
> I too am trying to making a decision about using JSF or not in a
production
> project. I building an web app that is modular with rich user interactions
> and I want to run the app as an application server provider model. I
highly
> attracted to the component nature of JSF and the fact that JSF ships with
> nice components that I can use right away.
>
> The choice to use Java has been made but I am not sure if should be using
> JSF or some other framework. Is there anything about how JSF works that
will
> put it at a significant performance disadvantage compared to Struts? How
> would the CPU and memory profiles of JSF app compare to the same app built
> in Struts?
>
When I was early in my computer career (the 1970s, ancient history for
many of you :-), the PL/1 language was just coming onto people's
radar. What was interesting is that there was more than one compiler
for the language -- and the code generated by the various compilers
had dramatically different performance on different types of
benchmarks. When you think about it a bit, this is exactly what you
should expect -- different compilers would have different optimization
strategies, focused on different types of use cases. But what was the
predominant press statement?
"PL/1 is slow."
Does anyone appreciate the naivety that is illustrated by such a statement?
What does the specification of a language have to do with whether a
particular compiler implementation sucks or not?
What does the fact that implementation X might suck at particular task
A have to do with the fact that implementation Y might excel at that
task?
Yes, you can make the case that there are features of the particular
technology that are hard to implement efficiently. There are
certainly pieces of JSF's requirements that can create performance
challenges for an implementation. That being said, there is NO WAY to
predict any particular performance characteristics of JSF versus any
other particular technology ... the precise performance implications
are going to be a combination of the particular JSF implementation you
are using, plus the precise way you are using it.
A question like "is JSF scalable" is not possible to answer in any
general sense. You can only rationally ask "is implementation X of
JSF scalable for use case Y". There is no such thing as meaningful
generalizations on the performance of a technology (like JSF) with
multiple implementations (like JSF) in particular use cases (like
yours).
Craig
> -----Original Message-----
> Wrom: UCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXR
> Sent: January 13, 2005 11:49 PM
> To: MyFaces Discussion
> Subject: Re: JSF - Robust? Scaleable? Ready for prime time?
>
> Before trying to evaluate JSF as a potential technology solution for
> your requirements, I would first try to figure out if the webapp
> paradigm (no matter what implementation technology you choose) is
> appropriate to the task. For order entry environments that are
> primarily form fill-in (with little server interaction until the order
> is complete), it is likely that this approach is appropriate. If you
> need *lots* of interactions during the process of filling out the form
> (i.e. making one choice dramatically affects the UI for subsequent
> choices), you need to think carefully about whether a thick client
> approach might be more appropriate.
>
> If a web architecture looks suitable for your requirements, you'll
> find that JSF implementations in general are on the CPU-intensive side
> of the scale on the server side (but it's a *big* scale, with *lots*
> of application specific variations), but this is counter balanced by
> the fact that the client side interactions consume zero server side
> resources. If your primary constraints are database or network, it's
> not likely to matter at all. If your primary constraint is CPU speed
> on the app server (not common, but might occasionally be the case),
> this potentially matters.
>
> As you can see, there's no such thing as a general answer to your
> question. The only true benchmark for your application is running
> your application :-).
>
> Craig
>
> On Thu, 13 Jan 2005 21:59:40 -0600, Aaron Bartell
> <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I am curious to know the different scenarios people have implemented JSF
> > and how intense the applications were. The reason I am asking is I am
> > wondering if JSF could survive the replacement of a 5250 Order Entry
> > application written in RPG on an iSeries. This particular application
> > has 500+ users hitting it with many different database requests. Note
> > that you cannot relate 500+ users using a standard website to the
> > demands of an order entry app. There is just a lot more going on in
> > order entry vs a shopping basket.
> >
> > I understand that a lot has to do with the hardware you are running, how
> > well you are load balanced, memory dedicated to your app server, etc. I
> > am more wanting to know if JSF can perform with the best (the best being
> > legacy systems that support thousands of users off of one server).
> >
> > I am not necessarily skeptical, I just need positive reinforcement.
> >
> > Thanks for any input,
> > Aaron Bartell
> >
>
>
