Shashi Velur’s blog

Web applications are the most common type of deployments on the application servers.

So, if OSGi is going to be a serious contender in the application server market, I would expect it to have great support for deploying web applications using WAR files. So, I looked through the existing documentation on eclipse.org and played with Equinox, Tomcat and Jetty. Here is what I have learned so far:

There are two ways to integrate Equinox’s implementation of OSGi into your server-side environment:

1. Embed your web application server within OSGi server
   • Native OSGi HTTP service implementation of Servlet API 2.4
   • Jetty-based implementation - Also requires the usage of the dynamic OSGi HTTP Service.
2. Embed OSGi server into your existing web application server
   • Equinox Bridge Servlet (Front controller servlet)
   • Dynamic OSGi HTTP Service using the Equinox Bridge Servlet

Option #1 means that the developer is forced to use OSGi HTTP Service. This is great for new web applications built from scratch. The user can programmatically register the servlets and add service listeners to listen for any events (if any one of these instances are started, stopped or updated, we are notified). But, this complicates the development effort required for making an existing WAR file work with this setup. Traditionally, Servlets have been considered “static” - They do not have to be installed/started/stopped dynamically. So, the “dynamic” OSGi HTTP service becomes an overkill in this particular case, IMO. The other disadvantage of this approach is that not all aspects of the Servlet spec are implemented here. For ex., Servlet Filters are not yet available in the native OSGi HTTP service implementation. I am not sure how clustering can be achieved here.

Option #2 uses the standard “Front-controller” pattern and uses the Bridge Servlet as a Front controller servlet. org.eclipse.equinox.servletbridge and the Servlet API are exported automatically to the underlying OSGi framework. So, the modules deployed in the OSGi server have access to the Servlet API to register/unregister servlets. This approach obviously uses the web.xml. So, you can add more servlet mappings for JSPs, if necessary. The other sub-options here revolves around using this Servlet bridge to provide the dynamic OSGi HTTP service.

So, I do not feel comfortable with both of the above options provided by Equinox OSGi implementations. Perhaps, other implementations might have better solutions.

No wonder the folks at SpringSource chose not to implement OSGi HTTP service in their SpringDM server platform for now. They support the standard WAR file deployment within their embedded Tomcat server. This seems like a pragmatic approach to me to support all the existing standard Web Application Archive (WAR) files.

Although I like the other dynamic services (Logging, Configuration, Event Admin Service, etc.) in the OSGi Service Compendium, I am not so sure about the HTTP Service, especially for existing web applications.

What do you think?

Technorati Tags: Equinox, Jetty, OSGi Compendium, OSGi HTTP Service, Servlet Bridge, SpringDM

TopGear is one my favorite TV shows. One of the attractions about TopGear was the suspense about the Stig, especially after the hilarious introductions (”some say…..”) of the Stig by Jeremy Clarkson in almost every show.

Today, this was revealed by BBC. The facts are even more shocking. I just cannot believe it..! He is 80+ yrs old Graham Hill, who won the GP World Drivers Championship in 1962 and 1968 and was reported to have died in a crash back in the 70’s..!

TopGear rocks..!

Here are some more reasons why I love them so much:

• In-depth knowledge & expertise, great reviews of automobiles
• Humorous and Witty
• Camaraderie among the presenters and stereotyped characters (”Captain slow”, “Hamster”, etc..)
• Hillarious & Insane ideas and Challenges involving automobiles

I guess TopGear could not hold back Stig’s identity after all the crazy speculation amongst the viewers.

Technorati Tags: Cars, Stig, TopGear

I am a big fan of the Hibernate’s direct field access functionality. I am not sure why ”property” access is the default instead of “field”. Direct field access allows me to control the number of getters/setters that are actually needed from the DAO Client’s perspective.

I think using property access helps enforce better encapsulation of the data in the mapped/persistent classes. I have seen that most developers just use public getters and setters for all of the properties in the mapped class.

This creates problems for collections, especially. I seldom expose getters and setters for collections. I always use a combination of “addXXX(Obj)”, “removeXXX(Obj)” and “clearXXX()” (depending upon the need) instead of “get/setXXX”. This is for efficiency (as Hibernate uses a custom collection class) and better encapsulation.

The only situations where I do not use the direct field access are:

• If the DB schema data type does not directly map to the mapped attribute in Java where a translation is required. This is mostly true for Legacy Database schemas and also where custom introducing custom SQL type mapping is not an option perhaps due to inconsistent use of the same data type in legacy applications.
• If there are dependent (child) tables that have composite primary keys (which include the primary key of the parent table). In this case, for saving a new entity I would need to intercept the setter of the primary key of the parent table to set the appropriate fields in the child tables.
• If I use lazy initialization, I would use property access for the primary key. This allows us to call persistentObj.getId() without completely initializing the proxy. This is applicable only for the “Id” field.
• If there is any other need to intercept the getters/setters for whatever reasons (validation, logging, debugging, etc.). This is very unlikely.

Technorati Tags: direct field access, encapsulation, Hibernate

Backlog is used for prioritizing, tracking and communicating the work (work items) to be done in the future Iterations/Sprints.

There may be multiple teams working from one backlog, but if there are more than 3-5 sprints worth of work items for all teams working on that backlog, then I consider that to be huge. I have noticed that if the product owner is not careful, the backlog can grow and become really huge.

This is not good for several reasons:

• It is depressing for the everyone on the team. This may lead to a belief among team members that this is a case of a large product with not enough resources.
• Priorities change - It is a waste of effort for the product owners to endlessly sort through the work items in the backlog every Sprint to come up with a list of stories for a Sprint.
• Some of the items in the backlog are never worked upon even after months/years. In that case why spend effort prioritizing them?
• It is hard to react to change in the market conditions, when the teams are so focussed on possibly “stale” requirements in a backlog.

So, what are the possible causes for this?

1. Lack of clarity of product vision.
2. Disagreements between the product management and marketing about the importance of features. So, the “unimportant” ones (mostly due to disagreements) find the bottom of the backlog.
3. Product owners unable to decide on the “business value” and ROI on requirements in the backlog. This may be due to the lack of authority (to do so) or communication breakdown or just the organization culture itself.
4. Sometimes, for various reasons, a suite of products might have one product owner per product who do not necessarily agree on everything especially when it comes to the cross-product requirements.
5. Inadequate resources, unstable team, attritions, shuffled team members, not-so-well-performing teams, etc.
6. Treating defects as backlog items. Sometimes, a lot of medium defects are tossed in to the backlog.
7. Poor/Complex Technical Architecture - This means that the features get done much slower than estimated.

Technorati Tags: Agile, Agile Best practices, Backlog, large backlogs

I read so many articles about SOA and they all seem to have slightly different takes on this term. And, there are a few more related acronyms/buzzwords thrown in to the mix to confuse the audience. Sadly, some of this is due to the vendors pushing their own products using certain acronyms.

So, I decided to add to that confusion by using the basic concepts to describe SOA, as I understand it :)

SOA is a style of designing whole or components/sub-systems of Distributed Enterprise Business Systems by utilizing the following principles:

• Encapsulation/Facade: Encapsulate the complexity of the application behind a clean “interface” that forms the foundation of the functionality exposed by the System/Sub-system/Component.
• Design-by-contract/Service specification: The “interface” exposed becomes the “functional” contract for the System/Sub-system/Component. This should be documented very well, including the constraints, preconditions, postconditions, etc. This also needs to be precise.
• Composition of services: It should be possible to compose the services at various levels - System or Sub-system or Components as per the deployment strategy. This allows for the system to be assembled for large-scale or small-scale deployments.

There are other aspects that are determined by how these services are implemented and hosted/deployed (by using various technologies, languages, application server, etc.):

• Performance
• Scalability
• QoS
• Portability & Interoperability of services

SOA helps integration. There are a lot of higher-level abstractions/languages/specifications/frameworks/products for implementing SOA in Enterprise products/solutions - WebServices, ESB, BPEL, JBI, WCF, etc. But, they all are built upon the above fundamental concepts.

Technorati Tags: BPEL, Design-by-contract, ESB, SOA, WebServices, What is SOA