Posted by Ajay
I came across an interesting problem when working on an interesting feature for our web mapping application. Let me first give you a very brief background about our application. Our web mapping setup uses Mapbuilder/OpenLayers as the client side Javascript API, A custom WMS/WFS server, geowebcache as our caching intermediary and PostGIS/PostGRES as our geospatial database. Every web mapping software will have a set of layers that are rendered. Every web mapping software will also have a basemap which defines the projection and bounding box for the model.
Read more…
Posted by Ajay
I have been working on implementing an interesting application to manage all the photographs (I will talk more about this project in a later post). In the process, I have been thinking about a feature I want to add to my application which involves alerting users using my web application to be alerted as and when new additions are made to my photo repository. I came across Grizzly Comet and felt an inane desire to try this out on my application, so here is my technical knowledge sharing about this experience
Let’s talk NIO
Before we talk about Grizzly and Comet, let’s try to understand where this whole concept started. Java 1.4 introduced a collection of Java programming API’s called New I/O with features for intensive I/O operations and was developed as part of JSR 51. The main purpose of NIO is to have an implementation that would allow use of the more efficient underlying platform implementation of I/O. A single thread can operate on a bunch of connections instead of having one thread per connection, which provides high degree of performance. This API provides variety of features that include buffers for primitive data types, character set encoders and decoders, pattern matching features, channels. Details about NIO is probably for another post.
Introducing the “Comet” philosophy
Another interesting concept is what is called Comet application model. The basic idea is that a web server would push HTTP data to a browser without the browser requesting the data. The Comet approach typically uses Ajax with long polling to achieve it’s task.
A simple diagram to illustrate the Comet methodology as opposed to the web application model is as below
Web applications have evolved through various stages, as depicted in the following diagram
In the Page by page model, that most web applications started off from and a model that many still follow, every new browser page would send a request to the web server. So essentially we had to refresh the whole page every time a small bit of data on the page changed, which started to become a real pain.
Thus began the era of Ajax where any new information would take the form of Ajax requests to the server to update the web page asynchronously. Web apps would poll the servers periodically for new information, but still the point of the matter is that users have to periodically hit the server to request information.
Finally Netscape introduced the concept called web server push that has evolved into the comet programming model. Essentially imagine having the benefit of server to client messaging without issues of fat clients.
Imagine a real time event like a baseball game or the stock market scenario, when users would want to be kept informed of events happening during the game or certain stock market events. Such scenarios cannot be implemented using traditional web application methodologies. This is where Comet or Reverse Ajax methodologies fit in.
Comet is a collection of technologies that provides the functionality of web server push through persistent HTTP connection. Comet can be implanted using Streaming where the browser opens a single persistent connection to the server for all server events or long polling. Many applications use the comet model, some of them include Meebo, Gmail chat, Jotspot, ICEFaces JSF framework. The Comet approach involves a departure from the usual web based platform approach. It may involve storing some kind of state information about the clients who wish to receive notifications on the server., similar to messaging systems. This is the reason most Comet based approaches rely on custom adapted application servers. In Java Jetty and Grizzly have support for Comet based approaches. This type of design is also being introduced through the continuation concept in other platforms. But how does the browser itself stay in contct with the server applications? Some approaches include long polling, dynamic script tags and Iframes which are all non standards. Many client side Comet designs rely on frameworks to iron away incompatibilities, Dojo for example is an Ajax/Comet implemntation
What is Grizzly?
Writing scalable server application has been a big task always. Threading issues caused issue with scaling. This prompted Grizzly to make it’s appearance. It is a HTTP Connector based on NIO that ships with Glassfish. It is designed to replace Apache Tomcat’s Coyote connector. All Java based web connectors have scalability limited by the number of available threads. This is where Grizzly improves by providing plug ability of any kind of thread pool.
Grizzly essentially is based on a task based architecture where each task represents an operation. Every task executes on it’s own thread pool or a shared one. The main entry point is Pipeline which has nothing in common with the Catalina Pipeline. The Grizzly Pipeline is essentially a Thread Pool Wrapper and is responsible to execute a task. The SelectorThread is another important component where the NIO selector is created. When processing a request, the SelectorThread will create Task instances and pass it on to the Pipeline. There are three types of Tasks - Accept Task - to handle NIO OP_ACCEPT, ReadTask/AsyncReadTask/ReadBlockingTask - to handle OP_READ, Processor Task - to handle OP_WRITE. This SelectorThread can either create one Pipeline per Task or share a Pipeline among tasks.
Grizzly has introduced Comet support and is implemented on top of the Asynchronous Request Processing extension of Grizzly.
So thats that for my technical sharing session for today, in my next post I will give a brief intro to the Comet API and talk about how I used it in my project. Ciao, for now!
References
http://alex.dojotoolkit.org/2006/03/comet-low-latency-data-for-the-browser/
http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html
http://www.pathf.com/blogs/2006/06/infrastructure_/
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1301487,00.html
http://weblogs.java.net/blog/jfarcand/archive/2006/01/introduction_to.html
Tags: comet, grizzly, java
Posted by Ajay
Servlets in Brief
A Servlet is a Java technology that allows a container to generate dynamic content. These containers are called servlet containers. Tomcat is one good example of such a servlet container. The basic Servlet interface defines a service() method to handle client requests. The web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads. A servlet will also have a variety of methods like doGet, doPost, doPut, doDelete and doHead which is a specialized version of doGet returning only a header. The use of a SingleThreadModel interface will guarantee that only a single thread will execute in a given servlet’s service method.
Most Java web frameworks build on the Servlet API and require configuration of Servlets, Filters and Listeners. The JSR 315 will be a part of Java EE 6
Some of the proposed changes
- Support for continuations. The general idea of continuations is that you can save the current state of an object and return back to the saved state at a later point of time in your execution lifecycle. It is almost like taking a hiatus from your hectic work schedule, going on a trip around the world and coming back to find that everythingis as you left, no catching up, no making up work, just consitnue on as you were before your hiatus, how cool would that be. This is a concept that was popularized by Scheme and also is a major part of Jetty as Jetty Continuations. Now with JSR 135, the request object will now have a suspend() and resume() to suspend and resume execution from a later thread.
- Plugability - Today all deployment artifacts are defined in web.xml, which can at times just become large and unmanageable. So multiple frameworks can lead to having us define all the servlet mappings in this web.xml file. But imagine if each framework coems withit’s own web.xml that defines only the components that framework needs, and if we leave the job of assembling the components together to the container, our task would be so much easier, and our project would be so much easier to maintain. This spec introduces web fragements that does exactly this task. In addition to this kind of plug ability the new JSR also provides a feature where servlets can be inserted into the container dynamically at runtime using the servletContext.addServlet() and servletContext.addServletMapping(). One drawback of this feature is that there could be potential security risks since JARS can register their own servlets.
- Annotations - I am sure many of you are familiar with annotations, a technique to try to eliminate configuration files by introducing the configuration details in the source code file. JSR 135 introduces POJOS for servlets, so no more extending from HttpServlet. Just use the annotation @Servlet(urlmapping = {’mapping‘}, name=“abc” } and then use @GET, @POST, @PUT, @DELETE, @HEAD. Servlet Filters are defined using @ServletFilter and @FilterMapping. Unfortunately this Annotations methodology is not as hunky dory and cool as it looks, there are lots of potential problems that Roy van Rijn has mentioned on his post on theserverside.com which include potential issues with having two methods with the same annotations like @GET, there are no IDEs that are setup to detect Servlet using annotations. Also with annotations what we lose is that previously we could just override the methods, now you cannot do that.
- Programmatic entry - Potentially there might be support for programmatic login and logout as part of the HttpServletRequest and HttpSession.
- HttpOnly Cookies - Ability to prevent client side scripting code from getting access to cookies by defining HttpOnly cookies.
References:
http://www.theserverside.com/tt/articles/articles.tss?l=PonderingAboutJSR135
http://weblogs.java.net/blog/mode/archive/2008/04/servlet_30_jsr_1.html
Tags: jsr 135, servlet
Posted by Ajay
Once upon a map…
I have been working on geoserver for the past few days and it has been an amazing experience. Let me tell you the circumstances that led me to investigate geoserver.
We have a system that had web mapping capabilities. We provide decision support service and our GIS map enables us to visualize the service that we provide to the customers. Users of our product will be able to see multiple layers on the map, visualize many diffrent layer features and use this to make certain decisions for managing emergency. Our technical setup involved using PostGRES/PostGIS to serve spatial data, a custom built WMS/WFS server that would consume the spatial data and render geotagged PNGs, and a Mapbuilder/OpenLayer based client that would take the WMS/WFS data and render a map on the front end web page. Our setup looked something like this:
One fine day our client wanted us to design some really cool basemaps, and so there we were in the next step of the evolution of our application, We got our GIS designers to produce awesome looking geotiffs, all looking nice and sexy. But one thing about these geotiffs files was that they were huuuuge!!. Some of them at our highest level of resolution were running into 4-5 GB. Then came the next step of setting our WMS/WFS server to render these geotiffs. Using a GeoTiffReaderWriter, we were able to successfully accomplish this, but with a great drop in performance when rendering the images on the UI. So the think tank got together to solve this problem, and a brilliant young engineer (oh thats right that was me!!) of course with some help from others came up with an interesting solution to cache the WMS/WFS server.
We decided to use some of the functionality of a great open soruce caching APi called GeoWebCache. We could not use the API directly since our WMS/WFS server could not send request into geowebcache in the format that it supported (This basically tells you that we were not following the WMS/WFS specification…how cruuude!! …this of course will be remedied in a few weeks when we switch to geoserver..but thats a story for another day)
Who dat wanna cache some maps!!
Web caching is a concept used to improve server performance. The general idea of GIS web caching is to cache extents that would be executed very often, and which entitles high overhead in terms of network bandwidth, and then retrieve these extents from the cache instead of a WMS query to the server. Web caching can be implemented only for layers that do not change often. If they do change, a cache expiration policy can be implemented.
Geowebcache (http://geowebcache.org/trac) is a WMS tiling caching client that works to cache WMS data. In essence what geowebcache does is that it acts as a proxy between the client and the server helping to divide dynamic maps into static tiles. It also takes requests for each of the tile , checking to see if a particular tile that is requested is already stored on disk (the cache) if so it returns that instead of hitting the server. GeoWebCache not only turns any dynamic mapping server in to a high performance cache for the WMS-C recommendation, but the tiles are also instantly available for direct use in Google Maps, Virtual Earth and as Super-Overlays in Google Earth.
Other features include pluggable caching backends, like JCS and a pure disk cache, and support for ‘MetaTiling’ for better labels across tiles.
It works somewhat like this:
- GET request is intercepted and the layer requested is extracted and checks to see if the layer supports the request.
- The bounding box or envelope of the current request is extracted and an internal grid of the form (x,y,z) is created. This grid forms the index. Any further requests, if they fall i n the range of this grid, would make it a cache hit.
- Once the grid is created a cache key is generated for the grid. If this cache is empty, the WMS server is hit to populate the cache, if not the image is rendered straight off the cache.
Now to visualize it,
So all in all our experience with geowebcache was incredible. We got an almost halving of our rendering time for our basemaps, and let me tell you, our clients were Haaappyyy!!.
Some good references
http://cholmes.wordpress.com/2008/03/05/letting-everyone-remix-web-maps/
Tags: caching, gis
