|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 36
Messages: 36
Messages: 36
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The AJAX effect on Server Load
As new technology is adapted people start to look beyond the initial attraction to understand the true costs and benefits of adoption. This is clearly happening in the AJAX world as evidenced by a discussion thread currently running at Slashdot. In this instance the cost in question is performance.
J2EE application servers provide a means whereby many users can share the same set of resources. In short, J2EE can service thousands of clients because at any given time, a vast majority of the clients are not physically connected to the server. The cost of this strategy of client server interaction is that it is much bulkier, slower and is a very static experience. In most cases using a plain browser as a client provides a very inadequate user experience. Enter AJAX.
AJAX, of course, provides a framework that allows the client to contact the server with finer grained requests. With AJAX there is no need to download an entire page just to update the values in a selection in list in response to selecting a radio button for example. With AJAX the client is free to contact the server for that information on demand. The good is that clients now have a much richer experience. The downside is that AJAX breaks the assumption that clients will contact the server very rarely. Thus we should expect that AJAX will impose a performance penalty on our application servers. The question how much of penalty will be imposed?
As with any question the answer is that all depends on how your application functions. However that is not a very useful answer. Useful answers come in our experiences with the technology experimenting with things that work and things that don't. And it is this experience that is being shared at slashdot. Here are some of the suggestions offered to help keep you clients from bringing your server to it's knees are:
- Strike a balance in the size of the request made to the server
- Use client side caching
- Beware of auto-completion as it will hammer the server
- Get more hardware
The last suggestion is not a facetious as it sounds as we often need to provide added functionality at the cost of needing more hardware. What are your experiences tuning AJAX based applications?
|
|
|
Message #192953
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not really a problem of Ajax itself
I think this is problem for some Ajax frameworks as Echo2
or just badly written Ajax components.
Fine grained ajax components results in decreasing server load and more clean traffic
|
|
|
Message #192954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It's not that simple
Some uses of AJAX can actually _decrease_ your load. If your pages are heavy, e.g., a complex portal page, then judicious use of AJAX can decrease your server load and increase your user-perceived performance.
It's a tool, like anything else. While the total number of requests will usually increase for AJAX web apps, the size of the requests and responses are usually much smaller - they are targeted to the functionality being requested.
The old performance techniques still work for AJAX - you're still dealing with a web app. You can use edge cacheing for AJAX replies in the same way you can for a "normal" web app request.
|
|
|
Message #192964
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
balancing number of requests and request size
While the total number of requests will usually increase for AJAX web apps, the size of the requests and responses are usually much smaller - they are targeted to the functionality being requested.
It's not even that simple :-) While this is the general trend with Ajax apps, remember that lots of small 'chatty' requests will have a high overhead. (The HTTP protocol is pretty heavy - I'd recommend you have a play with Fiddler or the Apache TCP Monitor to get a feel for the number of bytes actually traveling along the wire to transmit a simple 'OK' response, and those overheads are generally independent of message response.)
In some cases, it can make more sense to queue requests on the client and send them down in batches to the server. We discuss this in chapter 5 of Ajax in Action, and the Rico AjaxEngine also provides a working implementation of this technique.
The old performance techniques still work for AJAX - you're still dealing with a web app. You can use edge cacheing for AJAX replies in the same way you can for a "normal" web app request.
Agreed, that approach makes a lot of sense. For a type-ahead suggest that doesn't hammer the server, client-tier caching can be a very good idea too.
Cheers,
Dave
|
|
|
Message #192966
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
bill ball of wax theory is not proven in practice.
As Charles alludes to above, more requests doesn't necessaily mean poor performance. The coarse-grained approach to network transfers has been taken too. The idea is that you should bundle things uip and pass them back instead of sending one int at a time (as an extreme example.) And as with every bit of advice in software development, it has been taken to a ridiculous extreme: wrap 'everything' up into a huge ball of wax and shoot it down the wire.
The theory is that if you do this, you reduce the network overhead. So what? If you are cutting it that close with your resources, you need more resources anyway: you'll never survive a spike in load or having a server come down. Also, saving a few bytes over the wire at the cost of the user experience is penny-wise, pound-foolish.
I know that the bill-ball-of-wax approach is dangerous. It came very close to sinking a project I was on. It took serious kluging and long days to pull it out of it's tailspin. We would have defaulted on (and probably lost) the contract if we hadn't created work-arounds.
|
|
|
Message #192969
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: BIG ball of wax theory is not proven in practice.
Sorry for all the typos above. I have a one-month old at home. It's been that long since I've had a full-night's sleep.
"...network transfers has been taken too far."
|
|
|
Message #192971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The AJAX effect on Server Load
While it is true that a ton of AJAX request on the server will increase overall overhead, since the cost of each connection is high, if you design your client-side app in such a way that it is able to get most/all of the information it needs for its current context up-front, and cache it in the browser (hidden vars?), then you could actually reduce the load on the server.
I would argue that most (but not all) AJAX-enabled applications should reduce the overall number of connections per user session, and if it doesn't, then someone screwed up during technical design.
FWIW, I come from the mentality that AJAX should be used to get data from the server, not just get snippits of UI html (like refreshing the content in a DIV - what a waste!)
-Michael
|
|
|
Message #192974
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX is Delicious
Right now I am developing a project for scheduling Trip Requests for a client(a Fortune 10 MNC) whose requirement was to post changes in the database as soon as the user drags and drops any trip request and the trip requests are ordred by Trip start time. I am posting the changes to database as well as the whole screen is being loaded using responseXML using JavaScript.
Believe me AJAX is very fast and in a blink the changes are posted to database and the pages reloads.
This is much better than the other alternatives which we considered for the project like Swing or even Flash.
Its Just Delicious!!
|
|
|
Message #192980
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX not the answer
I am not quite sure what the question is, but I am fairly confident that AJAX is not the answer. IMO AJAX is a freak of nat..., computer science.
AJAX reliance on ECMA-script seems like a shaky foundation at best. I imagine debugging ECMA-script can be quite clunky and even if tool support might solve this problem at some point, there is no guarantie that browsers will interpret ECMA-script the same way, it seems like an embrace and extend waiting to happen.
I will not venture too far into the dynamically vs. statically typed language discussion other than stating that personally I prefer strongly typed languages.
I get the impression AJAX is a quick-and-dirty solution to a problem that requires something more advanced.
It seems like AJAX is an attempt to overcome the shortcomings of thin clients using the technology that had the widest market penetration, without considdering whether the technology was the appropriate tool for the job.
I am afraid that we will have to live with AJAX for a long time. A tradgedy similar to VHS victory over betamax, where an inferior technology beat a superior one.
I wonder if something like a next generation X-Server browser plugin or a thick client Java framework might not have been better suited for the job. It can't help but feel like AJAX is somehow trying to force a round peg through a square hole
|
|
|
Message #192988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
May be right but...
I get the impression AJAX is a quick-and-dirty solution to a problem that requires something more advanced.
That was also the case of Windows x OS/2, VB programming style x OOP, etc
Some things just survive and even grow, no matter how messy they are. That´s life.
|
|
|
Message #192989
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Refreshing the content in a DIV - a waste?
FWIW, I come from the mentality that AJAX should be used to get data from the server, not just get snippits of UI html (like refreshing the content in a DIV - what a waste!) But it is a less waste than to refresh a whole page, is not it?
|
|
|
Message #192991
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just a tool...
Have you actually looked into ECMAScript? It's actually a pretty nice language, and capable of much more than the usual skript kiddie nonsense. And cross browser scripting is getting easier and easier as support for standards increases. There are some very thin libraries now that unify the JS event model, and with these it really is possible to make cross browser scripts that actually work.
As for AJAX vs plugins, we'll have to agree to disagree. We already have a very capable, almost universally available thick(er) client plugin (Flash). I'd prefer to stick with AJAX.
Getting back to the subject topic, the MortBay blog on Jetty has some of the most interesting articles I've read about AJAX performance, and the architectural changes they're considering to address it. Highly recommended.
|
|
|
Message #192993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX not the answer
I am afraid that we will have to live with AJAX for a long time. A tradgedy similar to VHS victory over betamax, where an inferior technology beat a superior one. Ajax is not that hackish as some think of it. Also, after VHS they released SVHS, and DVHS was released relatively recently, so things are not that bad. Another benefit that comes for free is that you can use VHS cassette as an assault weapon.
|
|
|
Message #193002
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX not the answer - Well might be
I had a chance to work with a few financial applications and they mostly use XML, XSLT for their processing. AJAX can be the very best way for improving the performance in that scenario. Just retrieve the XML from the server, apply the XSL transformation using javasctipt (Google has created a AJAXSLT library in javascript and that can be obtained from sourceforge.net). This would further reduce the load on the server in terms of bytes being sent out as response.
Note: This again has a fair assumption that ppl out there are using decent enough machines in terms of processor and memory.
|
|
|
Message #193008
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Goes both ways (the good, the bad, and the ugly)
I have been using the new echo2 framework that is fully AJAX based and it has been an interesting experience.
Everything that echo2 does is ajax based. This has pros and cons of course like all things. By design echo2 maintains the entire web application in memory which allows for its highly dynamic behavior. Only changes are exchanged between the browser and webserver which makes for very efficient communication and a rich user experience (behaves like desktop app would for the most part). And the API is very natural and completely component based where the developer is overburdened with state management.
The echo2 framework makes it very easy for the developer to keep every screen past and future cached. Now for an internet application this is a scalability problem not to mention session replication/clustering type concerns. But this can be addressed with proper coding patterns. And unlike most web frameworks like Sturts/Tapestry/JSF, which do the opposite and make the developer work extra hard to make application state persistent across requests. You pay for this lighter weight in much more complex code and there is a performance cost in constantly creating lots and lots of objects for every request.
But with good coding conventions using echo2, I only keep the current visible screen in memory which allows me to use the full power of the framework and of AJAX while keeping memory footprint to minimum and allow for high scalability.
With hardware advances these days I believe the restriction on memory and session affinity limitations will go away. For anyone building a new web product, you must choose a web app framework that is fully AJAX capable from the ground up where AJAX is not just a bolt on. Page and form submit type frameworks will go away.
I think frameworks like echo2 will be the wave of the future as web programmers evolve out of the stone age. And this goes hand in hand with both hardware and software technology advances.
-Sam
|
|
|
Message #193042
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Count it
If you will implement same application once with AJAX and once without AJAX then for sure AJAXed version will transfer less data. Both versions with same usage will consist of same number of requests.
Of course if you will put in AJAXed application more user friendly functions then you have to pay for it. However you are responsible to decide how far you can go (that is reason why they call as specialists).
About hardware - it's sometimes cheaper to buy new hardware than investigate and fix some specific performance problems/bugs.
|
|
|
Message #193053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Old C10K problem
It's the old c10k problem. This paper shows you how many requests per second you could get out of any old PC:
http://www.kegel.com/c10k.html
Basically you want do the following:
1) Use a http and servlet runner that uses select/poll. If you are using apache 1.x then upgrade to 2.x. I don't know if tomcat uses nio, but if it doesn't then switch to something else. WebLogic Express does, I think, but you have to pay for it. I don't know if jetty does.
2) Use an os with a scalable scheduler, e.g. linux 2.6 or (I think) netbsd. See "Conclusion" here: http://bulk.fefe.de/scalability/
|
|
|
Message #193064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: about tomcat
on jdk > 1.4 all iostreams internally use nio.
Moreover, tomcat5.5.12 now can use native Apr lib for http1.1 connector.
So tomcat will fit perfectly.
|
|
|
Message #193074
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX is the way we cannot avoid
The question is what drives the demand of AJAX. In addition to connectivity and sharing, end users expect to have richer internet experiences. It's the trend we cannot reverse.
As AJAX gives Web applications a fresh look, the rising cost is challenging its way to success.
Here is a server-centric approach you might take a look. And, it's an open source.
http://zk1.sourceforge.net
|
|
|
Message #193081
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The AJAX effect on Server Load
Hi all,
Have to agree with the comments re: JavaScript, not very pleasant to work with when you start to get lots of it. Cross browser is another problem as is its quirky interpretation (ever seen perfectly good script start to go bad for no apparent reason, I know I have and the cause is usually some obscure bug introduced in some totally counter-intuitive way)?
Having said that as I understand it Ajax is more about using some basic JavaScript to make asynchronous requests which sounds OK although I'd watch out that I wasn't putting too much business logic in the view component.
So long as the app doesn't lean to heavily on JavaScript for UI candy then its probably going to be more reliable and maintainable. I'm currently stuck with an app that has reams of JavaScript on the front end and guess what, no-one wants to touch that bit :-)
|
|
|
Message #193088
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The AJAX effect on Server Load
People really should take a look at the latest ajax frameworks. See Rico, Dojo, Scriptaculous, DWR and other ajax toolkits, all of them shield you from cross-browser problems, and provide a uniform and simpler way of dealing with events, widgets (form controls if you wish), screen updates and client-server communication.
There's no need to hand-code everything in javascript from scratch anymore, just call some framework's API and most of it should work automagically.
|
|
|
Message #193141
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: about tomcat
on jdk > 1.4 all iostreams internally use nio.Moreover, tomcat5.5.12 now can use native Apr lib for http1.1 connector.So tomcat will fit perfectly.
1) I find your assertion about 1.5+ very difficult to believe. Do you have a reference for this?
2) I actually mean using tomcat without apache. If tomcat switched to using nio it could probably serve files with the same throughput as apache.
|
|
|
Message #193145
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
All is right
1. jdk 1.4+ (not only 1.5+)
see jdk source code, for example FileInputStream and like
and you will see usage of nio. So now classic java iostreams is facade over nio.
2. I meant tomcat5.5.12 without Apache httpd, but only with ~800kb Apache Portable Runtime Connector native library which, if found on path replaces Tomcat Coyote Http1.1 connector with apr Http1.1 connector and is recomended for production env (better performance and scalablilty (on windows, linux and other os).
|
|
|
Message #193147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: about tomcat
So basically, usage of Apache Httpd in front of tomcat5.5 is no longer recommended even for static resources.
High performance apr with openSSL and other goodies are in tomcat now.
Benchmarks shows same performance (google if you want)
|
|
|
Message #193176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
but what sense?
It seams that you don't read previous post.
1. Tomcat coyote http1.1 connector DOES USE NIO (explictly or by jdk's 1.4+ iostreams facade). I review sources recently so I'm sure.
2. Tomcat5.5.12+ now has apr native library with full power of Apache httpd 2.0 connector (http & https).
3. Blogs are just thought of some people and while reading those ones I didn't find any useful info, but just stale thought about already known things.
PS. do not promote useless blogs
|
|
|
Message #193179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
but what sense?
It seams that you don't read previous post.1. Tomcat coyote http1.1 connector DOES USE NIO (explictly or by jdk's 1.4+ iostreams facade). I review sources recently so I'm sure.2. Tomcat5.5.12+ now has apr native library with full power of Apache httpd 2.0 connector (http & https).3. Blogs are just thought of some people and while reading those ones I didn't find any useful info, but just stale thought about already known things.PS. do not promote useless blogs
I think what he said is that Tomcat allocates one thread per request, which is probably the case for servlets (as per spec) but is not necessarily the best for serving files. On each workload there is an ideal number of threads reading selectable sockets and an ideal number of threads doing disk reads, and these are independent numbers.
However ajax requests are probably servlet requests so they have to use a whole thread. It's really the whole preemptible threading model which is a problem here. But one can still optimize throughput by keeping the number of these threads bounded, and using linux 2.6 which has an O(1) scheduler.
|
|
|
Message #193189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The AJAX effect on Server Load
Hi all,Have to agree with the comments re: JavaScript, not very pleasant to work with when you start to get lots of it. Cross browser is another problem as is its quirky interpretation .... although I'd watch out that I wasn't putting too much business logic in the view component. ...
We hit the same problems and we have founded an opersource project to handle them. Please take a look of the ZK project's product overview (http://zk1.sourceforge.net/wp/ZK-wp-prodovw.pdf) that mentioned all these AJAX development challenges and how ZK overcomes them. Our aim is to make developing an AJAX web application as easy as developing a desktop application.
|
|
|
Message #193200
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I agree, but
I agree with idea, but my counter argument was againts such a thouht that "Tomcat cannot serve 10K because coyote doesn't utilize nio". I think it is totally wrong thesis,
so my anwser is "No matter whether Tomcat can serve 10K, It is absolutely unrelated to fact that CoyoteHttp does/doesn't use NIO".
|
|
|
Message #193211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Performance Insight Article: Network Latency for Remote Client
Hi,
The following link might be useful in understanding the impact of clients with heavy (and highly interactive) workflow logic that creates a significant number of client-to-server roundtrips.
http://www.jinspired.com/products/jdbinsight/networklatency.html
"This article shows how JXInsight's timeline analysis mode can help development and test teams assess the cost of network latency in applications with excessive client-to-server roundtrips."
Regards,
William Louth
JXInsight Product Architect
JInspired
"J*EE tuning, testing and tracing with JXInsight"
http://www.jinspired.com
|
|
|
Message #193235
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX not the answer -> better technologies
There ARE better solutions than AJAX available in the RIA space already. E.g. light weight client-side Swing apps.
If you combine this with Java Webstart, then you can easily
deploy (even) mission critical rich Internet applications.
One example in this context is ULC from Canoo.com.
This library is based on Swing and enables an almost seemless client server split of Swing components: all listener/event handling code that is known from Swing is executed at the server while the widgets are displayed remotely. I am curious if anyone knows similiar technologies (tell me).
|
|
|
Message #193276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We made the decision decades ago
Remember the age of green terminals? Remember how people argued extraordinary resource requirement for running GUI apps?
No double that more communication bandwidth and server power are required to enable RIA. The bottom line is that users are demanding a better UI for Web applications.
Current RIA appearances might be rough, confusing and counter-intuitive. It will evolve.
AJAX might be a temporary technology. Heading to rich Web won't change:)
|
|
|
Message #193323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX not the answer -> very likely
At least there is some tendency to think about appropriate user interfaces for web applications, as pure HTML is often not sufficient and leads to awkward user experience.
AJAX is currently the hype technology on the RIA market, but has already proven some crucial shortcomings. In addition to the well known problems with: use of back, stop and refresh buttons, book marking, printing, offline availability, browser configuration …… it is especially the maintainability (as with java script) of the application, which will give the biggest headache.
However there may be niche applications, which could benefit from the use of AJAX, but I recommend to do an assessment, as described in: Rich Internet Applications and AJAX - Selecting the best product
|
|
|
Message #193761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX is PERFECT!!! Gresham's Law in action (again)
AJAX is the newest in a depressingly long list of hacked-up solutions to the "web as platform" problem. All it lacks to make it a first-class, undisputed heavyweight contender for "your job is all debugging, all the time" status is the addition of PERL! Indeed, by the time I finish typing this message some wanker will probably have already added that abomination to this one. And pray-tell, where is the PHP? I mean, this crap is supposed to be Web 2.0, right? Hasn't anyone explained to you guys that PHP is the real Web 2.0?
I'm a big Java fan but a Java critic once wrote that it was overhyped. He went on to succintly state what he thought the problems with web programming in general had been during the "bubble phase":
"...It seems to me the 'new economy' that started with the Netscape IPO and ended in April of 2001 was mostly about squeezing productive work out of very poor programmers. The most important languages were thus the ones with the least rigor, the lowest barrier to entry, and trial-and-error debugging methods: Visual Basic, Perl, and Javascript. Compared to these languages, Java failed to meet whatever 'unique business needs' defined this era of atrociously prolific low-quality programming"
quoted from http://web.ivy.net/~carton/rant/java_languageoftomorrow.html
And now Javascript comes round again. Only this time we'll dress it up with XML and make it sexy. Put a dress on that turkey and turn her out to turn tricks and bring me my bling-bling yo' ho'! "Dimpled flesh, what? You get what you paid for!"
Here's the thing - do you want an application or a bunch of speghetti code. Experienced application programmers pooh-poohed the "web as platform" at the start of the bubble, pointing out that adding a network to the equation makes NOTHING EASIER. Ten years on and we are still "...trying to squeeze productive work..." from the 'I'm too busy with my Playstation to get it right so I'll do it with Javscript' crowd.
I guess I can look on the bright side. In 300 years we might have enough horror stories so that a professional standardization effort can put an end to all these self-styled "programmers." I think it more or less took that long with architecture (and the dropping of a cathedral or two on scores of workmen). Last time I looked you couldn't just hang "Architect" or "Dentist" on your front door.
OK - all finished. Going along now to find the PERL port to the AJAX framework...
|
|
|
Message #202630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX is PERFECT!!! Gresham's Law in action (again)
Agree! My clients are impressed with Ajax. It's what my clients need at least.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
