When to use Echo and EchoPoint
By Brad Baker
Wednesday, August 21, 2002
Have you had experience with Echo or EchoPoint in a real life project? We would like to here from you, especially about any trials and tribulations you might have encountered.
Please e-mail brad dot baker @ candle dot com with your story.
Like all technologies, EchoPoint and Echo should be used when they are relevant. Some applications are not suited to Echo while others are begging for such a solution. This article outlines when you should consider Echo and when you should not.
I should point out that these are merely the musings of the author. While I have over 13 years of commercial software development experience, these are simply personal opinions. You should always evaluate technologies in light of your own unique requirements and situations.
When to use Echo and EchoPoint
The main feature of Echo web applications is the strong event support, complete state management and pure Java language development environment.
1. You require strong Event Management and State Management
If you are building a web application that has many functions that the user can use, you will require a lot of event and state management. This can be quickly summarized as "....when the user clicks here, then find this information and present it. If they decide to look up a value, save where they are, let them lookup there value and put them back where they were. At any time they can cancel the whole operation and never return to where they started."
Building complex web applications in other technologies such as pure JSP or JSP with taglibs consists of creating many "web pages" and spending an inordinate amount of development time in building state "saving" code. The events generated are simply HTTP gets or puts with page parameters. While some taglib libraries do go to some lengths to put in a parameter parsing framework, a lot of code is in place simply to link together web pages.
You are forever thinking along the lines " if the user has come to this page from there then the parameters will be thus, however if they come here from this other page then we don't have this parameter and must account for that."
All this effort does not deliver any application functionality, like hitting databases and presenting massaged data to the user. Or performing extensive validation on the data users are entering.
Echo web applications on the other handle have very strong event and state management. Once components are placed within top level containers, then all the events they might generated are handler for you by the framework. You simply register a listener with the component to be informed when certain events have occurred.
For example if a user selects a value from a combo box (SelectField) and you want to change the list of sub options available to them, you would add a listener to the combo box. If you are not interested, then don't attach a listener.
As an optimization, Echo will not wire up the client side event management support if no listeners are attached to a component. If you don't not attach a listener to a button, for example, then no event will be raised and hence not HTTP request will be sent back to the server. This ensures the web application can run as fast as possible.
For certain components like TextFields and SelectFields this make sense. You might not be interested in events from them. For others, such as Buttons, you would always attach a listener, since what is the point of pressing a button if no one can hear it scream?
You can remove a component from view within the application and it still retains it state. It is simply invisible and hence will not be rendered. The parent/child relationships of components make this all the more powerful. Hide a parent and all its children are invisible. Remove a component from its parent and it will no longer be shown, however it still retains it values.
With components like the EchoPoint TabbedPane component, this can be done very easily. You can click anywhere on the TabbedPane and the previous tab keeps its state. Click back to the old tab and you will see that components within it are still them same.
Echo web applications are not built as a series of "web pages". In fact it is almost the opposite of this. You must think in terms of events and components when developing an Echo application, much like you would when developing a client side Swing application or even a Windows GUI application.
The major difference to a Swing or Windows GUI, its that an Echo application is delivered via a web browser, with all the deployment capabilities and server side processing efficiencies that entails.
2. You prefer pure Java Development
Want to dynamically create a 3D image? Go for it.
Want to send an CORBA call to a 3rd party system? Good luck.
Want to perform a complex insurance actuary calculation? You are in the right place.
Want to have a chance of maintaining the code 2 years from now? Contrast
Contrast this with scripting languages such as Perl or ASP. They are good for basic flow control, some string manipulation and that's about it. Any more powerful stuff have to be written as language extensions via C/C++ or via standard COM objects such as Advanced Data Objects (ADO). So in affect you still have to do "the hard stuff" in a proper 3GL language.
I'd argue that Java is a 3.5GL language. It retains the low level power of older languages like C but with the object orientation. However it does not abstract you too far away from the computer itself nor impose unwieldy object libraries like some 4GL and scripting languages do.
Once you have invested the time in becoming proficient in Java, you want to use it as much as you can. Echo web applications allow you to do this because all the components require you to write Java code to wire them together. And since the components themselves are written in Java, you can use the same development tools and debuggers with them as well as you own code.
The problem domain for an Echo web application falls squarely into the Java camp. You need Java skills and Java tools to develop and debug them. And because the problem domain is in only one place, it reduces the total effort to create applications.
3. You require an application not a web page
Applications that require lots of end user functionality and rich input validation are well suited to the Echo web framework. Business applications where users are capturing or reviewing lots of information fall into its domain.
If virtually all of you application is dynamic generated (and I mean compared to traditional static web sites) and will change from one moment to another, then Echo fits the bill.
Intranet applications are particularily well suit to Echo web applications. Older ideas for intranets where as a corporate information base. Where do I find my terms of employment? What is the policy on travel? But reviews of this idea have revealed that users wont use intranets unless they ofgfer them real functionality.
These days, intranets are more and more becoming part of the applications the users drive every day. Intranet applications such as HR help desks, timesheet recording systems and project issue tracking systems are all well suited to the Echo web framework.
And if you want to make them look and act really snappy, then use the EchoPoint library.
When NOT to use Echo and EchoPoint
Echo and EchoPoint are not without their drawbacks. They impose a framework that might not fit with the environment that is available or the audience to whom the application is targeted.
The following are not hard and fast rules. It maybe that you have some of the following requirements but you are still able to use the Echo framework. BUt its worth considering them before choosing this technology.
I have tried to keep the argument as balanced as possible, however I must admit, I am a huge Echo and Java fan.
1. You require constant content updates.
If the web application you are building requires constant content updates, from many sources, then the Echo framework is probably not for you. Echo are applications that will go through a traditional development maintenance lifecycle. They are not "content" in the publishing sense.
If you have this requirement you might be better to look a Content Management System (CMS) and use of "page based" technologies such a JSP, PHP or ASP.
2. You require precise design layout
If you require precision layout with pixel exact placement on the screen then perhaps the Echo framework is not for you. Web sites like this tend to be created as "brochure" sites looking to sell products or market ideas.
Whilst the EchoPoint HtmlTemplatePane component will go some lengths towards allow fine HTML layout control, you might be better to produce a series of pages using traditional web ways. For more detailed information on the HtmlTemplatePane see this article.
3. You don't have a J2EE server available
This is a basic infrastructure problem. If you are not running a J2EE web application server, capable of Servlets 2.2 Specification, then you cant run Echo web applications. Its as simple as that.
4. The client browser support must be as wide as possible
This means that older browsers such as IE 4, Netscape 4 and Netscape 3 are not supported. Having said that, as the web matures, more and more people are running the later browsers and this become much less of a problem.
5. You or the team don't have a strong Java skills
Echo is all about Java. If you don't have the skills, it may not be worthwhile using the Echo web framework. I would recommend getting Java skills. It is the way of the now and of the future.
6. You require seamless integration to existing web page applications.
Echo web applications have a definitely life time. Once the base servlet is invoked, an EchoInstance object is maintained per user that may connect to the server. The web application must be "exited or suspended" before another web URI can be shown.
If you have existing web pages or servlets that need to be seamlessly integrated into Echo, you may want to seriously consider whether to use Echo.
Having said that, I believe the development benefits of Echo will, in many cases, be worth the integration effort. You might find it better to retrofit previous functionality into new Echo applications.
7. You can't use open source software.
Some employers and clients have aversions to or prejudices against open source software, regardless of the licence in place. You must consider the licensing when using Echo and EchoPoint.
Echo and EchoPoint are released under the GNU Lesser GPL licence. This is a very flexible licence but it still retains some of the free software ideals.
As NextApp state in their FAQ :
Echo is licensed under the terms of the open-source GNU Lesser General Public License (LGPL). The terms of the LGPL license provide software developers with the ability to use the product royalty free to develop both open-source and closed-source (proprietary) applications. Developers may also modify the source code to the Echo framework itself, but in this case are required to submit their changes back to the community.
...proprietary applications can be created using the Echo framework. Echo JAR files may be distributed with proprietary, closed-source applications. Echo is licensed under the GNU LGPL which does not impose any licensing requirements on applications that dynamically link to it. If you have any concerns over creating commercial software that uses LGPL libraries, please feel free to contact us.
Echo and EchoPoint are great software frameworks for developing web applications. In fact we believe that EchoPoint combined with the Echo provides one of the simplest and richest frameworks for Web application development.
However you must always consider your unique requirements when considering whether to not to use these software technologies. I hope this article has help you in evaluating Echo and EchoPoint.