|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 31
Messages: 31
Messages: 31
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Comparing the Google Web Toolkit to Echo2
The Google Web Toolkit (GWT) is being compared to Echo2 quite frequently. Some of these comparisons have been fairly accurate, while others contain bits of misinformation. This article, written by the lead developer of Echo2, discusses the similarities and differences between these two frameworks.
Overview
The Google Web Toolkit and Echo2 definitely make for an interesting comparison. Both of these frameworks take a non-traditional approach toward web application development, even considering the latest crop of "AJAX-based frameworks" available today.
The most obvious similarity between GWT and Echo2 is that they both enable the developer to create dynamic, AJAX-driven web user interfaces using only Java. In both projects, UIs are developed in a fashion similar to SWT or Swing: by assembling hierarchies of components and registering event handlers. Neither project requires the developer to work with HTML, JavaScript, or XML.
The most obvious difference between GWT and Echo2 is that all of your GWT code is executed on the client, whereas your Echo2 code is executed on the server. There are advantages and disadvantages to both of these approaches, which will be highlighted throughout the article.
GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing.
Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser.
User Interface Performance
With GWT, all of your user interface code exists on the client browser. In operations that do not require server communication--that is, that do not require retrieving data from the middle tier--this configuration results in response times that are not dependent on the server. When data must be retrieved from the application's middle tier or business logic layer, the response time is subject to the same criteria as any other AJAX application, i.e., network latency, bandwidth, and server performance.
Echo2 application code is run on the server, so for each user interaction that requires a call to the middle tier or immediate execution of the application's Java code, an AJAX connection is made to the server. Echo2 components are designed to minimize the client/server communication as much as is possible, limiting it to times when the server must be notified immediately of events. For example, simple events such as user input to a TextField component will not result in server contact. The server's response is the minimum set of instructions to incrementally update the client to reflect the new screen state.
GWT applications are served to the client as a single HTML/JavaScript file, containing the entirety of the user interface. The size of this file will be proportional to the size of your user interface code and the toolkit libraries used by your application.
Echo2 JavaScript modules are lazy-loaded to the client, and thereafter cached. A module will be retrieved when a component first appears on-screen that requires it. Application code is never sent to the client, only the state of the user interface.
Middle Tier / Data Retrieval
To access business data or perform a business process, a GWT user interface makes a remote procedure call (RPC) from the browser to a Servlet. GWT provides a mechanism to make the RPC invocation transparent to the developer, allowing the developer to build the application with "Plain Old Java Objects" (POJOs). However, any application that provides an RPC capability is a distributed application -- even when the RPC is accomplished transparently to the developer. Distributed applications in businesses and enterprises usually have security considerations and the remote objects serving the GWT clients must be designed with a focus on security to deflect attacks from imitated or hostile client applications.
Echo2 applications support, but do not require, the use of distributed application logic or a Service Oriented Architecture (SOA). Alternatively, Echo2 applications can be built to run entirely within a single JVM instance, backed by a POJO-based middle tier. This allows Echo2 developers to build applications without the security concerns of distributed application logic -- and leverage the many strong frameworks built around POJO development such as the Spring Framework and Hibernate. Echo2 accomplishes this by keeping the state of a user's web interface on the server so that no remote objects need to be exposed.
Performance Under Load
The Google Web Toolkit is a thick-client UI technology (applications run on the client), whereas Echo2 is a thin-client UI technology (applications run on the server). A thick-client will inherently place less load on the server as the number of simultaneous users increases. This advantage of GWT is most pronounced in cases where applications are simple and data store access is limited, and less so with more complex applications that require more frequent inquiries to the data store. In a typical environment though, either framework will saturate available network bandwidth before server resource utilization, i.e. processing power and memory, becomes an issue.
Run-time Environment
GWT has some limitations due to the fact that applications are run on the client browser. First, GWT applications are limited to using a subset of the core Java class libraries, consisting of 27 classes, 11 interfaces, and 18 exception types found in the java.util and java.lang packages (as of GWT 1.0.21). This limitation prevents GWT applications from linking to most existing Java libraries. Additionally, all Java code must be compliant with the Java 1.4 specification; 1.5 is not supported. Localization-related portions of the Java API are not provided.
Debugging
GWT provides an alternate deployment environment for applications to facilitate debugging. The environment, called "Hosted Mode", allows a GWT application to be run as Java byte code in a local JVM, to which an IDE's debugger can be connected. In this mode, the application's user interface is displayed in a special web browser (a Mozilla/Firefox derivative).
Echo2 applications may be debugged in the conventional manner, by connecting an IDE's debugger to a JVM running a Servlet container.
Licensing
The primary component of GWT, the Java-to-JavaScript cross-compiler, is proprietary, binary-only software. The Java API libraries are open source software, distributed under the Apache License. The API libraries have essentially no value without the proprietary compiler. The (non-critical) hosted-mode browser is also under the proprietary license. GWT is provided free of charge.
Echo2 is open source software, licensed under the Mozilla Public License, and provided free of charge.
Applicability
GWT can be used as a means of creating AJAX components to embed in traditional web applications (or even in static web pages) as well as for creating complete application user interfaces. There are some issues to using it for the creation of large applications, where downloading an entire application to a client web browser in one shot would not be practical. The lack of localization and full Java API support also presents a problem for larger solutions.
Echo2 is practical for creating web applications of any size. It is however not intended to scale downward to function as a platform for simply creating AJAX components in traditional web frameworks (or static web sites).
More Information
Google Web Toolkit:
Home Page, Example Applications, Getting Started Guide, Developer Guide
Echo2:
Home Page, Example Applications, Tutorial
|
Threaded replies
| · |
IDE
by
no no
on Thu Dec 20 10:27:08 EST 2007
|
|
|
Message #210725
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice, balanced comparison
Nice comparison of GWT vs Echo2. Although I have no
experience with GWT, and very little experience with
Echo2, if I needed to pick one versus the other for a project,
I would probably go with Echo2, simply because it does
not limit what Java classes and libraries can be used to develop the application.
The fact that the online Echo2 demo is very impressive doesn't hurt, either.
A couple of Echo2 reviews can be found at:
A Review of the Echo2 Framework
and
A Closer Look at the Echo2 Framework
Disclaimer: I wrote both of the above reviews.
|
|
|
Message #210756
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GWT is not a thick client, is it?
> GWT applications are served to the client as a single HTML/JavaScript file, containing the entirety of the user interface.
> The Google Web Toolkit is a thick-client UI technology (applications run on the client)
> To access business data or perform a business process, a GWT user interface makes a remote procedure call (RPC) from the browser to a Servlet
There's something about your explanation of GWT I don't understand. If the client served up to the browser is all HTML/Javascript, how is the application a think client?
> GWT has some limitations due to the fact that applications are run on the client browser
But GWT is all HTML/Javascript -- ther is no "applicaton running in the browser", that is, there's no Applet or thick client. It's just HTML that talks Javascript to Servlets on the server, right?
Please elaborate.
|
|
|
Message #210757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why not?
The best thing would be if Swing could access an "HTML layout manager", so that real Java code could replace JavaScript on the client.
I'd like to see some discussion, on this thread, of the various barriers to this architecture. I mean, isn't what we all want to be able to do "just write java code" on the client. Well, we can do that with an applet, but the applet can't interact with the browser the same way Javascript can. So, what would have to be done to make it possible?
Here are some wacky possibilities:
1)Java interpreter ships with the browser, allowing Java to be executed like a script. HTML "layout manager" interface is provided by browser's java interpreter, and you can access the layout manager via standard "import" statement.
2)Java-to-Javascript bridge allows standard Java class, in an applet, to execute Javascript calls. Would again require some support in the browser. Somebody implements an HTML layout manager on top of the bridge.
3)A Java-centric browser. I really think it's time to try this again! So when is Google's web browser going to be released?
-geoff
|
|
|
Message #210790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Advantages and Disadvantages
I have done a bit of work with both frameworks, both are very well thought out and tackle the same problem in very different ways.
It really comes down to which one has limitations that irk you the most :-)
Echo 2 has two large limitations as I have discovered. One is events. Since the framework runs entirely on the server, the client side script will only send events to the server under very specific circumstances. For example, the click of a button.
Meaning that if you want to create something like an auto-complete form field, or have something occur on a mouseover, you have to make custom components. Which is a pain.
The second large limitation is server affinity -- which makes echo2 much harder to scale out in very large programs. Though this is a limitation Echo 2 shares with almost every other Java web framework.
Echo 2 compares favorably to GWT in terms of having the entire power of java available and a *lot* more components available at the moment.
GWT has its share of big limitations as well. Your client code can't make use of reflection, java.text, regular expressions, and a few other utility classes I have found to be very useful in GUI programming.
On the other hand, it has a much better event system (events happen on the client, you can hook up to just about anything), better support for custom javascript, and can do rather crazy amounts of scaling.
All said, I think both frameworks are better than pretty much everything else I have seen for java. But between the two it just depends on what you need more.
|
|
|
Message #210799
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT is not a thick client, is it?
First let me define "thick client" and "thin client"...or rather let me quote Wikipedia's definition of them:
A thick client (also known as a fat client or rich client) is a client that performs the bulk of any data processing operations itself, and relies on the server it is associated with primarily for data storage. Although the term usually refers to software, it can also apply to a network computer that has relatively strong processing abilities.
A thin client is a minimal client. Thin clients utilize as few resources on the host computer as possible. A thin client's job is generally just to graphically display information provided by an application server, which performs the bulk of any required data processing.
With Echo2 the client is being used primarily as a display. The server is contacted when the user performs any event that requires the immediate execution of an application's code. For example, when the user clicks a button, the server is contacted in order to process the button's ActionEvent, as the ActionEvent-handling code exists on the server. (NOTE: operations which do not require immediate execution of server-side user interface code will not result in server contact.)
With GWT the Java user interface has been compiled to JavaScript and is actually running on the client. When a user clicks a button, the code to process the resultant event actually exists on the client (as it has been compiled to JavaScript). The server is only contacted when the user interface needs to contact the middle tier to retrieve or manipulate data. Even though GWT is not using Applets or Plugins and all GWT code is HTML and JavaScript--this design falls under the category of thick client.
"Thick clients" sometimes have a negative connotation, in that many associate the term with the requirement that IT folks will be installing client software on each workstation (either by pushing installations from a central server or even manually visiting each workstation). Obviously this is not the case with GWT--the client software is automatically "reinstalled" (if necessary) each time you visit a web page containing a GWT application.
|
|
|
Message #210803
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Nice, balanced comparison
I would probably go with Echo2, simply because it does not limit what Java classes and libraries can be used to develop the application.
that statement makes me really question your understanding of GWT. What GWT provides is the possibility to move parts of your application logic, together with the display logic, to the client in the form of JavaScript, where it is both obvious and completely desirable to not have every conceivable library available. If you need access to, say, hibernate, then, please, delegate back to the server.
After all, we're writing a rich - not fat or thick - client.
This is by no means a limitation but an architectural feature. I dont think Echo can really compete in that space (although I dont deny it can create slick and highly interactive web apps)
|
|
|
Message #210821
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Response to GWT comments
When GWT was first released, I spent a solid week investigating it and writing a small application. I'd like to response to a couple of the points made here based on my experience.
all of your GWT code is executed on the client
This is very misleading. Yes, GWT takes care of translating your client-centric Java code to HTML, JS, and CSS but you still use your existing server-side code (think Spring, Hibernate, business logic, etc) to drive the client code. Google has done a great job of making GWT flexible enough where you can write a full blown client with GWT or a simple "widget" placed in an existing HTML page with the addition of a div tag.
GWT limits the developer to a subset of the Java 1.4 libraries
Again, this is somewhat misleading and not entirely true. I was able to write a GWT app using Java 1.5. The only limitation is that the client portion of the GWT code must use 1.4 conventions. You can still use Java 1.5 for most of your service/middle tier.
There are some issues to using it for the creation of large applications, where downloading an entire application to a client web browser in one shot would not be practical.
I don't think this is a limitation of GWT but calls into question how you design the application. Having several "entry points" to the application may be an option.
I found GWT to be a refreshing change to the AJAX library landscape where there are tons of small and some useful (Prototype) libraries:
- GWT provides a nice abstraction which most Java developers can pick up quickly.
- This abstraction also promotes reuse so you can easily use a "widget" from one app in another with minimal effort. This alone is huge in the AJAX space and lowers the barrier to developers that haven't been able to effectively incorporate AJAX into their apps.
- Enabling the development cycle to happen using Java byte code is also huge. I would guess that this would reduce the development time of the app a minimum of 30%. No more app server restarts (for client-related code) and debug your client code using your favorite debugger.
BTW, I'm not a Google employee but...shameless plug coming...I do have a little website called AJAX Matters for more information on GWT and other AJAX resources.
|
|
|
Message #210842
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How about Java interpreter and markup language
Programming UI in Java is great, but can we do it in a markup language like ZK and Backbase.
IMHO, there are two kind of architectures: client-based and server-based. GWT, DOJO, DWR and Backbase are all client-based. Echo2 and ZK are server-based. Client-based has better control of the browser, but easy to become fat-client as replicate app codes at the server. Server-based are easy to develop and communicate with backend, but hard to fail-over.
When coming to programming language, there are three approaches: JavaScript, Java and markup language. DOJO is JavaScript. GWT and Echo2 are all-Java. Backbase supports markup language. ZK is the most interesting (actually we are using it to develop an inhouse project): it supports pure-Java, markup language and event, scripting in Java (with BeanShell). With markup language and scripting, we can store UI in database!
ZK Demo: http://www.potix.com/zkdemo/userguide/
Nowadays, all Ajax demo, unless immature, are impressive!
|
|
|
Message #210858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GWT + Echo2 together? Maybe the Best of both worlds
Roma Framework (http://www.romaframework.org) is a metaframework with the main aim to build cross-framework application. Current version allow to generate Ajax web application with database and CRUDs in less than one hour.
Now the unique rendering plugin available is for Echo2. Echo2 acts very well and using additional components (NextApp's Extras and EchoPoint NG) allow to write very complex web application without write one HTML tag...
A new Feature Request in Roma is to support the GWT along with the current Echo2 and decide by configuration what POJO to render with GWT (client-side only) or by Echo2 (client+server side).
bye,
Luca Garulli
Blogging on: http://zion-city.blogspot.com
http://www.RomaFramework.org - The new way to build applications
http://www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
http://www.OrienTechnologies.com - Light ODBMS, All in one JDO solution
|
|
|
Message #210872
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Response to GWT comments
Upon hearing your concerns, I think I need to provide a bit more clarity with regard to these statements. The terms "your GWT code" and "your Echo2 code" are not referring to the entire application, but rather to the application's user interface layer. The same applies with regard to the statement that GWT is limited to a "subset of the Java 1.4 libraries." Additionally, after reading your complaint, I now believe this last statement could have been better termed a "subset of the Java 1.4 API specification".
I don't think this is a limitation of GWT but calls into question how you design the application. Having several "entry points" to the application may be an option.
I do not believe the large-application-problem is a show-stopper. I do think this is rightly called an "issue" though, as it does create additional work for the developer. As an example, take the case where those multiple entry points need to share information at the UI level. It can most certainly be done, but it does require more work than if one were able to create a single "application" unit.
I found GWT to be a refreshing change to the AJAX library landscape where there are tons of small and some useful (Prototype) libraries:
1. GWT provides a nice abstraction which most Java developers can pick up quickly.
2. This abstraction also promotes reuse so you can easily use a "widget" from one app in another with minimal effort. This alone is huge in the AJAX space and lowers the barrier to developers that haven't been able to effectively incorporate AJAX into their apps.
3. Enabling the development cycle to happen using Java byte code is also huge. I would guess that this would reduce the development time of the app a minimum of 30%. No more app server restarts (for client-related code) and debug your client code using your favorite debugger.
The numbered points here apply equally to Echo2.
Please don't read me wrong here, I'm not trying to knock GWT--I actually think it's pretty cool. Both frameworks have their advantages and disadvantages though.
|
|
|
Message #210940
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Testing and spring support
What I'm missing from this comparison is the support for Spring. I tried Echo2, but it lacks spring support and I can't find the right place to integrate spring.
The other thing I would like to know is how easy it is to write unit tests using these toolkits.
|
|
|
Message #210946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Testing and spring support
What's wrong with just plain old using Spring? What integration is needed?
|
|
|
Message #210950
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JS Spring?
What I'm missing from this comparison is the support for Spring. I tried Echo2, but it lacks spring support and I can't find the right place to integrate spring.
What? You want Spring in your JavaScript now, too?
You know, I don't have any issues with Spring or DI, but the number of developers that blindly throw it in to every little bit of code they write is quite disturbing.
As far a GWT goes, I imagine most users will implement the true business logic on the server and expose it as services. In that regrard, all you are really doing is writing a servlet, so using Spring/Hibernate/<insert favorite framework/library here> is no problem.
Chris
|
|
|
Message #210963
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Testing and spring support
What I'm missing from this comparison is the support for Spring. I tried Echo2, but it lacks spring support and I can't find the right place to integrate spring.
I can't speak to Echo2, but Spring 2.0 integration with GWT can be done in much the same way as the AspectJ 'dependency inject your domain model' technique. GWT creates its RPC endpoints internally based on the classnames you supply in an XML file, so it's easy to write a simple aspect that performs DI on advised objects and apply it after the constructors for relevant GWT-managed classes execute.
I've written a bit more in-depth about the process here, since most of the other techniques I've seen so far for Spring/GWT integration have a 'workaround' feel to them.
|
|
|
Message #210977
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Comparison
Both frameworks have their merit, however, I
like the Echo2 model.
You can debug your GWT app while developing
in Java.. but how about debugging your app
when it's running in the browser, in Javascript?
Seems that there would be less overall Javascript,
and browser compatability issues with Echo2.
The framework also looks more complete in terms
of the number of components, etc.
D Pat
Digital Vastoo - For All Your iPod Needs
http://www.digitalvastoo.com
|
|
|
Message #210978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Anybody planning to shelve JSF bassed approach for GWT
I would like to hear from early adopters of GWT ? Any plans of pushing GWT into actual projects ?
<rant>
JSF has a steep learning curve . But I am yet to find productivity gains. GWT concepts, on the other hand, is familiar to anyone who has ever written a "hello world" Swing application.
</rant>
|
|
|
Message #210988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Anybody planning to shelve JSF bassed approach for GWT
I'm in the process of creating a rather large website with GWT. It was timed pretty well with the start of my project.
My reasons for choosing GWT:
- I have a lot to do, and basically 0 time to be fooling around in javascript, GWT seems to do the best job of taking care of it for me
- I know I can scale GWT out without worry, and failing over to another server is very easy
- It is fairly quick (relative to other javascript-hiding frameworks)
- If I need the power of java, it is but a RPC call away -- and I can generally get away with doing it infrequently enough that it isn't a problem
- Full event system, that isn't slowed down by having to communicate with the server
- The vast majority of what I need in the GUI is buildable with the blocks GWT provides, the rest is worked around easily enough
- I am not a fan of building GUI's from markup languages, or any of the more conventional Java web frameworks
The application will be large in size, fairly small in load, and will require high standards for both security and reliability.
So there's at least one company out there actively developing an app based on GWT. :)
And for what it is worth, if GWT hadn't come out, I would be building the app in Echo 2.
|
|
|
Message #211599
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE:
I'd like to use ECHO2 for intranet application and choose GWT for internet application.
for gwt can integrate with existing html, some tranditional web design tools can benifts for it. for example, use dreamweaver template to maintain overall style.
echo looks more like swing, for it is a PURE java app, app will be reliable. compiling time check, refactor, and so on...
echo runs a little far from HTML, it will be easier for swing developer. gwt api is flexible, html block can be set as a link text.
on the other hand, echo2 may reder output's to flash, or xaml in the future. maybe gwt add some mechanism to let controls work like a server side control.
for now, I believe Echo/GWT will lead the future web devlopement.
|
|
|
Message #216103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
+1
I'm just starting out to learn about both Echo2 and GWT, and I am leaning towards this same observation. Anyone know of an "autocomplete" implementation in Echo2? That appears to be a component that is fast becoming a "standard" requirement for UI frameworks, but I did not find it in the demo.
|
|
|
Message #216104
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Comparison
Both frameworks have their merit, however, I
like the Echo2 model.
You can debug your GWT app while developing
in Java.. but how about debugging your app
when it's running in the browser, in Javascript?
Seems that there would be less overall Javascript,
and browser compatability issues with Echo2.
The framework also looks more complete in terms
of the number of components, etc.
D Pat
Digital Vastoo - For All Your iPod Needs
http://www.digitalvastoo.com
+1
I'm just starting out to learn about both Echo2 and GWT, and I am leaning towards this same observation. Anyone know of an "autocomplete" implementation in Echo2? That appears to be a component that is fast becoming a "standard" requirement for UI frameworks, but I did not find it in the demo.
|
|
|
Message #227819
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Testing and spring support
I've written a bit more in-depth about the process here, since most of the other techniques I've seen so far for Spring/GWT integration have a 'workaround' feel to them.
Mark, did you figure out how to modify Eclipse .launch file to debug GWT + Spring in hosted mode?
Valery
|
|
|
Message #244056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IDE
What is the best combination of an WYSIWYG IDE + debugger ?
IDEA is having its own UI designer, which is pretty neat for a Swing, all what it does it automatically generates XML layout for you components and bind them to Swing classes with proprietary Layout managers all these is simple and easy, also event listeners.
But echo2 has its own set of classes, libraries -
One might really question the quality of that product it might be good, but by taking a look at it at glance maybe not perfect - too java oriented.
For ex, I could not really instal Eclipse plugin for echo2, some tiny things didnt work etc. You cannot go to production with such a library .. can you?
there are other frameworks like opelazzo, etc, they are TOOOO xml oriented. Doesnt anybody want to code everying in XML ?? heh ? even control flow?
In echo2 why have a set of parallel classes of swing ?? why not to do some BCEL to existing Swing classes? and provide a decent support for a couple of layout managers as in IDEA. and translate them to Javascript or whatever during the build transparently .. I dont want to work with parallel classes honestly..
So in the end what is the best tool to do UI designs WYSIWYG and have very simple java binding in web preferably from the same product suite? to have really COST cost effective/ high testability/ fully debugged/ application? ANY commercial products that worth money?
hey gooruuus?
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, 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)
|
|
