Some approaches of extending Web application

February 23 2007No Commented

Categorized Under: Software Engineer

There are many lead open source standalone projects as Eclipse, Netbean etc provide the extension mechanism that can help end user can write the plugin by themselves. User can extend the existing features or create the new ones base on these platform. However, we do not see the similar cases on web application. Because the limitation of stateless http protocols also the more complicated environment that is shared by multiple applications also multiple users that make extending web application features is more complex than the standalone one.

I have piloted a lot web application like blog, management, erp etc but almost these product vendors have the closed application, they can d more features by themselves or I must understand deeply on infrastructure and invoke the application. In web application, we also apply the Open-Close principle and any enhancement meaning in this post means we enhance web application without changing the existing code base. In general, we have three kinds of enhancing a Web application:

  1. Extending the existing features:
    This type of enhancement is applied in many projects especially open source ones. Wordpress, the blog site I am using, has the excellent plug-in mechanism that allow users can extend the existing features. For example, if you want to enhance one feature relate post such as paging a long post into many smaller posts. You only need to write a simple php file that get the content of post and divide it into smaller ones. After that, copy your php file to defined plugin folder, then activate the plugin and that's all.
  2. Add more view for additional module:
    We have many features that can operate independently, for example we have a portal web application contains the blog, bookstore etc and these modules do not have any relationship to other. So, we only need to build a portal site that can integrate views of these application in one site. No further effort needed for integration!
  3. Add additional module to existing application, that can impact or not to existing features:
    It is the complex problem even on desktop application. Let's investigate the simple use case in the enterprise project:
    "The Open Web Service (ows) system need two modules that can run independently or together, they are the resource management and project management system. Resource management module allows user book members into projects they are working for. And project management help user can manage the project schedule. The relationship between these modules are described in the following:
    - If resource management module is existed: the project management module will get all projects in resource and manage schedule of these projects.
    - If resource management module is not existed: user must create the project and resources correspond with them by themselves."

For those, who already has implemented additional modules on standalone application like eclipse, Netbean, jdeveloper etc, they can tell us the common workflow of writing a plugin:

  1. Follow the standard of API extension provided by software vendor.
  2. Packaging it and install to defined folder.
  3. Activate the plugin (some case, this step is not needed).
  4. Re-start the application and use it!

It is rather simple workflow, right? But it is harder than in Java web application because the following reasons:

  1. Production server can not easily to start/stop.
  2. Shared jar files issue: the most common jar file is added in common folder. We can not use the same jar file but different versions in multiple applications because the class loader will use the class is loaded first (Java standard does not care the version of class, module. It is a weakness of Java if we compare with .NET). For example, I can not put two implementations of JSF are JSF-RI (JSF version 1.2) and My Faces (JSF 1.1) in the common library.
  3. Limitation of Class Loader mechanism:
    3.1 Class Loader is complicated to use especially in web application. Due to the class loader is not defined in any JSR so we have no common class loader mechanism for all web applications. Stick to class loader of specific web container will make your web application can not be portable.
    3.2 Bad managing jar version mechanism: I have analyzed the root cause in Shared Jar file issues. That also lead we are hardly sure library consistency among modules.
  4. Stateless protocol: we manage the states of web application on various modules mostly use session variables, cookies or database value (it is the same with session variables). It also be a limitation if we compare with desktop environment when we are freely control the whole application.
  5. Multiple Users: usually the desktop application only serve for one user. There is the different story for web application that serves for multiple users. Isolate data, handle transaction and avoid the dirty data when adding more modules can cause your system become unstable!

Due to we have many difficult on net environment that limit the extending of web application, most inter-relationship among modules are Single-Sign-On (SSO) though it is very difficult because almost application choose the specific authentication-authorization service. If you only write a simple web application that serve for some purpose and it is maintained by your team, you do not need to think about creating a plugin mechanism on web application. If you need to write an application that can be extended in future like Eclipse platform, that can integrate all modules in one application (like portal but portal only integrate the views only, I have heard some inter-porlet communication is implemented in Jetspeed project but I do not know so far) you should need a framework. Some organizations like Eclipse and Spring have investigated the way of applying Osgi in web application and I strongly hope that Java developers can easily extend, manage the web application easier than now.

Subscribe

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • BarraPunto
  • Bitacoras.com
  • blinkbits
  • BlinkList
  • blogmarks
  • BlogMemes
  • BlogMemes Cn
  • BlogMemes Fr
  • BlogMemes Jp
  • BlogMemes Sp
  • Blogosphere News
  • Blogsvine
  • blogtercimlap
  • Book.mark.hu
  • Bumpzee
  • co.mments
  • connotea
  • De.lirio.us
  • Design Float
  • DotNetKicks
  • DZone
  • eKudos
  • email
  • Fark
  • Faves
  • feedmelinks
  • Fleck
  • Furl
  • GeenRedactie
  • Global Grind
  • Gwar
  • Haohao
  • HealthRanker
  • Hemidemi
  • Identi.ca
  • IndianPad
  • Internetmedia
  • kick.ie
  • Kirtsy
  • laaik.it
  • Leonaut
  • LinkaGoGo
  • LinkArena
  • LinkedIn
  • Linkter
  • Live
  • Ma.gnolia
  • Meneame
  • MisterWong
  • MisterWong.DE
  • muti
  • MyShare
  • MySpace
  • N4G
  • Netvibes
  • Netvouz
  • NewsVine
  • NuJIJ
  • Ping.fm
  • PlugIM
  • Pownce
  • ppnow
  • Print
  • Propeller
  • Ratimarks
  • Rec6
  • Reddit
  • SalesMarks
  • Scoopeo
  • scuttle
  • Segnalo
  • Shadows
  • Simpy
  • Slashdot
  • Smarking
  • Socialogs
  • SphereIt
  • Spurl
  • StumbleUpon
  • Symbaloo
  • Taggly
  • TailRank
  • Technorati
  • ThisNext
  • Tipd
  • Tumblr
  • TwitThis
  • Upnews
  • Webnews.de
  • Webride
  • Wikio
  • Wikio FR
  • Wikio IT
  • Wists
  • Wykop
  • Xerpi
  • Yahoo! Buzz
  • YahooMyWeb
  • Yigg

Leave a Reply