Integrating Echo into Existing Frameworks

EchoPoint
Helping you build truly dynamic and stateful web applications!

Integrating Echo into Existing Frameworks

By JP Fielding
Wednesday, July 30, 2003

JP Fielding has been actively involved in the Echo community and has been working on a series of commercial applications that use Echo and EchoPoint extensively.

You can preview these applications here.

Why Use Echo

Let me start by saying that HTML and tagging is great for creating documents. However, there are functions of the web that are not document based.   For these Web Applications, Echo's ability to abstract away the complexities of rendering to HTML and digesting back the HTTP, create a liberating framework in which the developer is free to focus on development of the application and it's business model instead of links, rendering and browser compatibility.

You Still Here...?

Since developing in Echo is out of scope of this article, I'll leave out the basics. I will assume you've read the Echo Tutorial, and move on to issues like getting Echo's foot in the door of another application.

Things That Helped Me Dip My Toes In

Beginning with Echo, we needed some examples that would show what could be done, but management was not willing to 'bet the farm' on what they deemed unproven technology. So we searched for a low risk candidate in need of development. An administrative console was the answer. At the time, our current application was completely dependent on another framework, but needed some massive back-end console tools built in. While the application was non-trivial, the development of the application GUI was. With anything like this slow migration, there are some tricks to help get around problems.

Making Sub-Applications

The first part to integrating Echo into an existing application is to write it, the next part is to include it into the flow of the older framework. This presented 3 problems in our application.

Multiple Frameworks Requiring Inheritance

For starters, our application required the sub-classing of a servlet specific to it's framework. This presents an obvious dilemma since Echo requires the same. The solution to this was actually rather simple. Since all servlet scope (without explicit intervention) is equal in the same servlet container, one can simply wrap one servlet with another. More specifically:

public NewEchoAppWrapper extends ExistingFrameworkServlet{

        private MyEchoApplication server = new MyEchoApplication();

        public void service(HttpServletRequest req, HttpServletResponse res)

                throws IOException,ServletException{

                        this.server.service(req,res);

        }

}

In this case, these two servlets would have the exact same scope, and the proxying just sends the message to the echo application. The EchoServer just assumes the request was mapped to it and chugs right along.

Template Based 'Look & Feel' Reuse

Since we were not yet ready to make Echo the top most layer, we had to come up with a means to wrap the existing application 'Feel' around our Echo application.   The solution to this lies in Echo's ability to embed itself within frames, or in our case we used an IFrame.:

<html>

<head>

<title>MyApp - Administration</title>

</head>

<body>



<%mac user_header "admin">





<%mac navheader " " "admin">



<iframe src="/servlets/MyNewEchoWrapper" height="75%" width="100%"></iframe>

<%mac footer>

</body>

</html>

In this case, we just completely stole the look and feel from our existing framework and still got to use Echo.

Errors Invalidating the Entire Session

This last issue is more of a stupid developer issue, but just the same, mistakes happen. In our case, we are doing some hefty integrating with another application out of our control. While error handling is good, it was obviously not complete.   While integrating, someone is bound to miss an Exception (usually a RuntimeException) somewhere, and it should not bring down the entire application.

To handle this, we needed an HttpSession that won't invalidate on us. Once again we just need to override a method, but this time it's EchoServer.process(). Inside of this method, we need to swap out the HttpRequest with a request object the returns an HttpSession whose invalidate() method is no-op'd. Yeah, it's a mouthful, but here's the code:

protected void process(HttpServletRequest request,

                                HttpServletResponse response)

                throws IOException, ServletException {

    // get the real session before i wrap it

    HttpServletRequest req = new RequestWrapper(request);

    super.process(req,response);

    SessionWrapper ses = (SessionWrapper)req.getSession();

    if( ses.isInvalidated() ){

        // do something here since you're application just crashed and

        // is probably in an invalid state

    }

}

Note that the session wrapper is not provided, you have to make it yourself, but that's simply creating a wrapper object that meets the HttpSession interface (Eclipse does this easily). In my case, I no-op'd the invalidation of the session, but I set a variable that I could check afterwards. If it's true, you've got some decisions to make about how to handle it.

JP Fielding has been actively involved in the Echo community and has been working on a series of commercial applications that use Echo and EchoPoint extensively.

You can preview these applications here.

The EchoPoint project is kindly hosted by SourceForge