A new article on information week gives reasonable overview of the J2EE market including: industry acceptance, java web start, resourcing problems, scalability issues, JCP 2.0, XML and more. An interesting excerpt: "Gartner expects the market for application servers and J2EE-related tools to grow to $1 billion this year."
Read Serving Up Java 2 Enterprise Edition
A more interesting excerpt:
"For mission-critical or high-performance applications, JSP servlets don't offer enough scalability, security, and distributed computing capabilities."
This shows Sun's marketing (brain-washing) machine effects in action.
"And Corba was too loose. For example, an object-request broker from Iona Technologies can't communicate with one from BEA."
, no kidding.
When people such as from Gartner group release such "articles" or studies,
you will know what to expect from them.
I wouldn't be wary about unless I knew that such sheer stupidity makes its way into upper management levels, sometimes with disastruous effects.
In Romania everybody knows and can comment about football (soccer for the americans), we might have 23 millions of potential national team coaches,
here in America it seems that everybody knows and can comment about technology.
That isn't an article, it's a joke.
From Article :
But Impetus' Raman reports some interest in EJB-based applications, especially in the insurance and financial-services markets. For mission-critical or high-performance applications, JSP servlets don't offer enough scalability, security, and distributed computing capabilities. "If I'm developing a small Web site, yes, a JSP servlet will do. But not for an enterprise-scale application," Raman says.
However, creating a small-scale JSP servlet and then rewriting it as an EJB later, when more computing power is needed, would cost too much time and money. "Some people would rather do the heavy work now," Raman says. "You might not scale it to an extent where it would take care of 500,000 users immediately. But to write something to take care of 50,000 or 75,000 and then redo it in the future to enable clustering and load balancing--that's a major effort."
I think Raman has a serious problem with his sources. He's got the wrong concepts and he really needs to take some of the middleware courses being offered here at this site.
This article is obviously not written for a technical audience in mind. Most of the people quoted are CTO's (I love one quote: "We're definitely starting to use EJBs, although I will profess I don't know what EJBs are--but I'm trying"!), and most readers of these reports are CTOs and managments.
Hence you cannot discount this article for being technically inaccurate. Its purpose is a marketing push for J2EE, and whatever brings more money to the table so that everyone gets a bigger piece of the pie is always good!
This article definitely falls into the category of
"give me the 'Executive Summary'".
ummm... maybe I'm a little slow here, but what exactly from this article can be classified as "stupidity"?
I don't see any gross inaccuracies in this article, although maybe some oversimplifications and things that are obvious to us techies.
what exactly from this article can be classified as stupidity"?
The things I cited and there are others.
I tend to agree with Mark. I am not sure what the noise is about.
Exactly what are the stupidities?
There is nothing in this article that I would violently disagree with. As stated above - it is not a super-technical article but who cares.
>> "For mission-critical or high-performance applications,
>> JSP servlets don't offer enough scalability, security,
>> and distributed computing capabilities."
Correct. (though, with some qualifying statements)
>> "And Corba was too loose. For example, an object-request >> broker from Iona Technologies can't communicate with one >> from BEA."
So what is the problem?
One thing that you have to understand is that J2EE is not aimed at being the most performant thing there is. That is impossible. As soon as you start abstracting away complexity, you have poorer performance. There is no escaping that. (look at programming languages: compare java to C++ to C to assembler - each with increasing performance and increased complexity, reduced abstraction)
EJB (and to some extent J2EE in general) is a productivity tool - not a performance tool. It abstracts away complexity into containers.
The biggest problem in building any system is not getting enough performance out of it. It is getting your bunch of (usually substandard) developers to finish the thing on time and actually get it to work at all without falling over every 5 min. Good developers are hard to find so the answer is to take as much complicated midlleware work away from them and put it in the hands of people who do middleware all day.
The other part of J2EE is the standardisation. Again standardisation is not going to necessarily aid performance. Completely vertical solutions (you could read here: non J2EE appservers) are arguably much better suited to their chosen niche. But a vertical solution is like a highway, if once you are on it, you realise you have chosen the wrong lane, you have to wait a long time before you can get off and turn around or change course.
The platform/vendor independance is a step towards allowing a team to change their mind mid-project or even 1-2 years after completion of the project (for whatever reason) about their choice of "appserver" or middleware. In the past the wrong choice of vendor (e.g. ORB) would inevitably lead to good money being thrown after bad because the cost of backing out was too unpalateable (after all, who would admit to having made the bad 1st choice).
The API standardisation again helps in our quest for good, experienced developers. If you are going to choose, say, ATG as your chosen appserver - and you have guys with Weblogic experience.... voila you have a team (albeit with a small deployment learning curve). The vendors are different, there is still the quirks to learn but the underlying technology is the same or very similar. You dont have to incur the whole learning curve.
Granted, I did raise my eyebrows at the CTO who did not know what an EJB was.... I hope they are not paying him too much.... (lets hope he was mis-quoted. Blame the media;)
I guess your explication is too long, but the fact is
CORBA ORBs can interoperate with each other using at the minimum IIOP and object_to_string() and string_to_object().
Yes, there was a time when they could not but it was very long time ago and it doesn't grant you to say the same today.
Anyway the affirmation about CORBA is plain stupid.
The reporter made an assessment about something that's obvious he has no idea about.
More, has the guts to throw a statement like "CORBA was too loose", it's like I'd say about Isaac Newton's work that it wasn't on my taste, and I'd have done it differently.
This easyness in being opinionated about nomatter what subject has only one diagnostic, and I said it already.
As to what regards the other thing with performance , scalability and many bla blas, the way he puts it is like JSPs and Servlets stay in the way of performance, scalability and other bla blas, and it suggests that if you throw EJBs in there you'll get your performance and scalability and the other bla blas.
Another obvious example that he has absolutely no idea what he's talking about, not to mention that he's comparing apples and oranges.
>So what is the problem?
>One thing that you have to understand is that J2EE is not >aimed at being the most performant thing there is.
I don't like when I "have to" understand, I am usually able to understand something when it makes sense.
The cited affirmation and many others in this article don't make any sense no matter how much you want to twist them or argue about.
You and others might find the article "good" because it praises EJB and stuff like that.
It is like arguing that if ( p->q ) is always true when p is false, then there must be some truth in p if we like what q says.
Well, you can have your ways.
Do you guys have jobs?
Sorry for that, I'm having a bad day. Please continue.
I'm note quite sure why servlets and jsp's are considered to be not scalable. Our website uses jsp & servlets on WebSphere, and we are one of the busiest sites on the internet. We recently served 32 million pages in one day. In fact it was our image servers that were slowing us down that day, not the java stuff. So for us, scalability has not been a problem.
Yeah, really - why would servlets and jsps inherently be slower than ejb's - I would have thought it would be the other way around!
Dont confuse scalability with performance.
I guess you also confuse both scalability and performance.
Can you explain you vision on how you can have less performance but great scalability.
Judging on the figures Jeff posted, and I know others also, it looks to me that servlets are preety scalable don't you think ?
Or do you think Jeff made an "architectural" mistake by not emplying the "scalable" EJBs.
OK. How about you give us your definition of performance and also your definnition of scalability?
Performance is when things runfast
Scalability is when they support many users.
You cannot have good scalability with not so good performance.
If you have a system that "scales" well but for each user things run slow, then you could have built a system where for each user things run faster so you'd have better scalability in the end.
To say that EJBs are not necessarily built for performance but if you put them behind servlets they make the system scale better, well, this is just a marketing "buzz".
This is a bit of a long post, but bear with me...
Well, firstly, there are two general metrics that are used to define "performance". Costin, you mention one: speed. I think "speed" is a little ambiguous. I prefer "response time". The other metric often used in serverside programming is throughput.
These two metrics can be related but are not necessarily so. You can have an application that has a fast response time, but low throughput. It is possible to have an application with a slow response time but have a high throughput.
Scalability is an over-used term, but generally it means the capacity to deliver better "performance". In most cases, in order for an application to deliver more performance (faster response time / higher throughput) the application must consume more resources (cpu, ram, network bandwidth). It is the ratio of improved performance to increased resources that defines the "scalability" of an application.
You could propose that scalability = %increase performance / % increase resources
So, to answer the point of whether I have confused performance and scalability:
Performance = response time and/or throughput.
Scalability = ability to deliver more performance, given more resources. ie the ability to grow.
If you double the resources an application has, and its performance doubles then you have linear scalability. This is your ideal... In practice, adding more resources adds overhead to your application OS and hardware subsystems and there is a law of diminishing returns. Eventually, you reach a point where adding more resources gives poorer performance. You could say this is the scalability ceiling.
Generally, if any application is inneficient and consumes an inordinate amount of any one resource, then it will reach the scalibility ceiling sooner than rather than later.
Where the confusiom about performance and scalibility often lies is in the assumption that because it is "slow", it wont scale. If the performance is judged on the basis of response time, then things such as network latency and blocking of threads (waiting for external events) will affect performance - but have absolutely no impact on scalability.
Relating this back to the discussion on servlets + JDBC vs EJB:
Well, I am making an assumption here that when we are talking about using servlets, we are talking about 2-tier (physical) apps. JSP/Servlet engine + database. If not, then please let me know.
Lets look at a couple of scenarios where we can illustrate the scalability issues of servlets and where EJB's *may* help:
1) Partitioning of cpu load (parallelisation)
The first obvious limit is the cpu usage. If there is complex business logic, then the JVM running the servlet engine will soon saturate the cpu as load increases. If the processor cost of the business logic could be offloaded to another cpu, then this would help performance. (the cpu cost of not only be the logic, but could also include the transaction overhead and the security overhead)
You could add more and more cpu's in order to scale up, but all these cpu's share the same RAM - and the RAM will eventually become the bottleneck. You could just add more servlet engine boxes, thereby partitioning the total cpu load amongst the individual boxes. For a lot of applications this is a very viable solution. However, if your application is such that the business logic is difficult to partition in this way because, say, each instance of the business logic must share a large amount of (volatile) data (which would mean either inter-vm comms or storing this volatile data in the database), then while paralleling up the stateless servlet code might be very efficient, the paralleling up of the business logic might not be.
Alternatively, if you could offload the cpu load of the business logic to another (perhaps much larger) machine, then this would be better as there is no RAM bottleneck. You suffer some latency over the network and some cpu cost in marshalling but *depending* on how cpu intensive the business logic is, you could actually get better response time and better throughput with this architecture. An EJB *could* be the host of the off-loaded business logic. (notice I said "could" - more on this later).
2) Database / Network Bottlenecks
The second scalability limit that you hit with servlets is the database. Servlets are inherantly stateless, so all your state (not just session state! but persistant state) of your business logic must be stored somewhere. The database is the only reliable place to store this. However, as we try to scale up our application throughput, we may start to saturate the database (both in terms of connections and in terms of cpu/io load) and begin to saturate the network. The answer to this could be for each servlet to begin caching data on the servlet box. However as we do this we can quickly start to saturate the ram on the servlet box. We could optimise the caching by sharing common data - but this leads to thread contention and reduces the parallelisation of our servlet code... and may begin to cripple throughput.
We could just add more ram, but this doesnt help the bottleneck of the throughput of the i/o to the ram - or help the increased cost of the cpu-cache misses.
Another solution might be to move some of the business logic into stored procedures in the database (this one is for you, Costin ;). However, depending on the business logic, here we are just adding extra cpu load to the very machine we are trying to lighten up). Not to mention the maintenance costs of BL in stored procs.
Alternatively, we could perform this "caching" on another machine. Again, we incur the network and marshalling costs but we can offload the caching cpu work and ram consumption to this new box thereby achieving the reduced database and network load.
This cache *could* be an EJB entity bean. Use of optimistic locking control (implemented by the container) would meant that we would limit the number of reads that hit the database.
Basically, with a servlet + jdbc approach, you run into a lot of the scalability issues of 2 tier apps. A lot depends on the nature of the application - in some cases, the servlet/jsp + jdbc solution is perfectly scalable. However, in other cases they are not - and we run into the same reasons why we build n-tier distributed apps.
Now, you would have noticed above, in both problem scenarios, I said that EJB *may* be the solution. It is certainly not the only solution.
You could use a pure socket, CORBA or RMI objects servers. All of these are valid solutions (with increasing complexity from right to left).
However, depending on the nature of the application, with all of these technologies, you are left with implementing your own object lifecyle management, your own object persistance management, your own transaction monitoring, your own threading AND your own security.
This is where another type of "scalability" comes in. The "scalability" of your software/technology solution given the resources of your developers. (here I admit I am guilty of the over-use of the word scalability).
The advantage of EJB is that it simplifies the implementation of the business logic in a distributed environment. Your developers are not going to be able to screw up the transaction management code or screw up the multi-threaded access to common data - that code is already developed and (hopefully) rigorously tested and is given to you in a shiny shrink-wrapped box.
There is a cost though, in that you get all or nothing with EJB. You incur the cost of, say, security checking and transaction managment even when you dont need or want it.
This takes me back to my much earlier point. Compared to CORBA or RMI, EJB is a productivity/reliability tool - NOT a performance tool.
Sooooo, hopefully, (in this epic post) I have explained why I think EJB can (IN SOME SITUATIONS) provide the scalabilty to a servlet+jdbc app that cannot be *EASILY* provided otherwise.
I dont buy the marketing hype - although I have identified some cases where EJB would be a plus, I can name plenty of situations when it would NOT aid either performance or scalability.
I hope also, I have proved that I dont have performance and scalability confused ;-)
Sorry about that, it wasn't necessary for you to prove it.
It was meant just a "retaliation" for a similar statement from you to someone else.
But coming to the subject in more details your argumentaion is a little bit long and essentialy not easy to swallow by our customers, while my definitions were short and conclusive so i stick with mines :)
You're assumption was correct. I was talking about Servelt +JDBC as opposed to Servlet + EJB + JDBC.
But there's some subtle points where your argumentation fails.
Having scalability= throghput / resources, well, it's a little more complicated mathematically we could try in O() complexity notation, if the functional relation between resources and throughput is almost linear we have could good scalability, better than linear is most likely impossible, and less than linear is not that scalable andnobody cared to analyze if it was O(logn) or O(n^1/2) or anything like that, and honestly we have little data, experiments in this regard are too costly, and the variables involved are too many ( CPU, memory model, OS, I/O architecture, software stack etc, etc).
So we have nothing better to do than to forget the theoretical considerations and come back to my simple definition: scalability is the ability to serve "many" users.
More exactly , as many user as the business situation needs, with economically feasible investments in resources (like you know from 4CPUs to 8CPUs system's price is not dubbled but quadrupled so our beneficiary will definitely not care if we scale in CPU and memory terms).
So it doesn't matter to a enterprise customer if we have one of those systems that is kind of wasting CPU in fancy data copying with Java stack, gets and sets and it's kind of slow, but we prove to him that eventually we can throw 8 "middleware" systems in front of our honest database and we solve the business problem.
That is definitely BAD.
Now where could EJB help our poor servlets and our poor database to scale better ?
1) Partitioning of cpu load (parallelisation)
We are not talking about solving linear systems or other engineering problems that can be solved by parallel algorithms.
Even the idea of parallelization is totally false, because we are talking time sharing here niot parallel systems.
Usually the number concurrent end user requests being solved by a business systems is larger then the number of CPU so we have nothing to do in parallel.
If we try to it would be foolish , we'll only create more overhead to be solved by the kernel.
>Alternatively, if you could offload the cpu load of the >business logic to another (perhaps much larger) machine, >then this would be better as there is no RAM bottleneck
No, that's bad from the scaling perspective.
You just moved your problem elsewhere and your Servlet threads will be blocked waiting for the other machine to solve the puzzle.
And EJB model ias of no help for you in parallelizing the business logic.
If I am wrong please show me in the specs to where they talk about their parallel execution model.
2. Database / network bottleneck
>The second scalability limit that you hit with servlets is the database
Wow, I really didn't know that !
>Servlets are inherantly stateless, so all your state (not >just session state! but persistant state) of your business >logic must be stored somewhere.
you're in confusion here , the conversational session is maintained in Session objects, basically in memory for most of the servlets engine.
Only the transactional data is put it in the database and EJBs could just do no better here.
>This cache *could* be an EJB entity bean. Use of >optimistic locking control (implemented by the container) >would meant that we would limit the number of reads that >hit the database.
This is the key word COULD be , if we had a true caching model. But we don't.
So you have to do your ejbLoad() in the overwhelming majority of cases unless you want to shoot yourself in the leg.
Even if you'd say that you could save a database read for certain transactions, this would be a posioned victory because the overhead generated by the bad EJB model and other considerations will have your performance ruined in any case.
As a last argument about the "database bottleneck" please take a look at the latest TPC-C, TPC-W figures
Sorry about the confusion my earlier post started. Actually, though, we have found servlets and jsp to have good performance and scalability (assuming I understand the terms correctly). Good performance: our pages are generally served in 2 seconds. Good scalability: we maintain that 2 second response for 1 millions users up through 20 million users..with no big difference in response time. Again, this is on websphere, so thats the environment we run in.
Your message was short, but hit the definitions (as I have read them) right on the nail. Performance is usually measured as the amount of work for a given slice of time (i.e., frequency in math terms) and scalability is the ability to shrink or contract the system as needed. For example, micro$oft-based solutions aren't very scalable because there is by definition a ceiling of an nt workstation being the highest-performning machine they can run on - that's not scalable. With Java, you can run it on a single-user workstation and. as you need to, you can scale it all the way up to a sun server farm large enough to run the DOT - now THAT's "scalability."
Do I understand then, Costin, that you advocate a 2-tier programming model?
- Servlets + JDBC is not two tier, it is three-tier
- two tier is not a bad per se. Contrary to popular and unfounded beliefs two tier can scale to figures beyond what 99% of IT world needs.
- the much hyped "n-tier" is only generalized client/server at a close analysis, more, contrary to popular beliefs, n-tier architectures are not inherently more scalable than client/server.
- worse in certain cases such as EJB, but also COM+ has its problems, n-tier architectures didn't get their client/server lessons and they hit the wall pretty hard wasting performance and scalability for no good reason.
So it doesn't help you to bash client/server, because, as they say, he who hasn't learnt his history will repeat it.
How is Servlets + JDBC 3-tier?
A good definition of scalability : http://iroi.seu.edu.cn/books/whatis/scalabil.htm
Scale-up (vertical scaling) - e.g. to a stronger server with more processor and/or enhanced operating system
Scale-out (horizontal scaling) - adding more servers (servers farms).
A solution is scalable if it can serve dramatic peaks in terms of number of users and/or longer tasks required by each user while still providing adequate performance for each user.
I agree with you in most of your points in your last reply. The article was somewhat oversimplified - but then again, to the authors defense, it was probably not aimed at technologists.
>> I don't like when I "have to" understand, I am usually
>> able to understand something when it makes sense.
Dont get too caught up in arguing about the choice of English ;-)
In a literal sense it looks wrong to equate JSP/Servlets with EJB. It would have been proper to say that "just JSP/servlets without EJB business tier will not scale well". If architected well, the path would be to have JSP/Servlets with business logic layer separate,first and then in the next phase convert the business logic layer into EJBs. Thats what was missed out in the argument. I am sure some people would have done this mistake of hastily converting CGI code into Servlets with presentation and business tiers clubbed together and face scalability problems and then find it a big task to redesign it. Unless designed well, whatever tool or technology you use, its of no use.