Shashi Velur’s blog

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

I think it is very hard to build any enterprise application without using at least a little bit of straight Jdbc. Even if an application uses Hibernate heavily, there will be situations where using straight Jdbc makes most sense.

We use HibernateDaoSupport (using GenericDAO pattern) and JdbcDaoSupport Spring classes as the base classes for the HibernateDAOs and JdbcDAOs respectively. 

Here are some of the things to be aware of when we mix these 2 techniques for the CRUD operations within the same transaction:

• The HibernateDaoSupport beans and the JdbcSupportBeans should be wired with the same DataSource instance.
• Use HibernateTransactionManager, which auto-detects the DataSource used by Hibernate and transparently uses Hibernate transactions as JDBC transactions for that DataSource (using ThreadLocal connections).
• When using CMT or using declarative transactions using Spring AOP (Spring Transaction interceptors), the connections must be explicitly closed by the Jdbc DAOs. Otherwise, this leads to connection leaks. See Hibernate JavaDocs for Session.connection() method for more info. My favorite way to avoid this problem is to use Spring JdbcTemplate inside the Jdbc DAOs.
• Explicit flush on the Hibernate session may be required wherever Jdbc calls need to read the updates made through the hibernate objects within the same transaction.
• Explicit invalidation or refresh of the Hibernate Session is needed whenever updates are made through Jdbc.
• Hibernate by default uses Optimistic locking. So, the retry logic needs to be implemented in appropriate places.

As you can see it can get very tricky to synchronize straight Jdbc and Hibernate updates. So, I would try to use straight Jdbc only for bulk reads and reads that require complex joins, if possible.

Technorati Tags: Hibernate, Hibernate Transactions, Straight Jdbc

One very important thing that I have learnt from my consulting experience (dealing directly with Clients for building solutions) and in my experience of building exterprise products is:

When you are given a set of requirements, always understand the requirements in terms of what problem of the Customer (an actual client or the product owner) is this requirement trying to solve, instead of just treating the requirement as a feature or an enhancement request.

This may sound very simple, but it has far reaching implications in building great products/solutions. With a good understanding of the inner workings of the product or the architecture or technology or just out-of-the-box thinking, sometimes certain extremely simple alternative solutions might just do the trick with very little or almost no work/re-rework required..!

This was reinforced by one of the examples given by Mary Poppendieck in the Lean Management principles presentation I attended recently:

In the Military/Army, the communication given to the soldiers consists of just 2 things:

• End State
• Command Intent

So, the “Stories” or “Requirements” should specify the “what” and not the “how”.

Technorati Tags: Agile, Lean principles, Requirements, Story

I just found out that my Akismet WordPress plugin has been eliminating some valid comments on my blog by “hard-delete” instead of a “soft-delete”.

I cannot believe this. I just lost over 30 comments some of which may have been some good comments.

So, I now cannot get to those supposedly blocked “spam” comments - they do not exist in the DB tables. I just found that out today. So, had to swiftly deactivate/uninstall it and install another one, ”SpamViewer”.

Hope this one works better.

Technorati Tags: Akismet, SpamViewer

I am in the process of rearchitecting a fairly large legacy web application. Almost all of the classes in the old code base are public classes with the key classes containing mostly public (and sometimes static) methods. I am tasked to modularize this application for various obvious reasons in an evolutionary and progressive manner.

Java package names are used for various purposes such as:

• Namespaces for tiers (web-tier, middle-tier, EIS-tier, etc.)
• Namespaces for layers (service layer, DAO layer, etc.)
• Namespaces for the purpose of the classes (Utility classes, implementation classes, etc.)
• Namespaces based on module structure, deployment architecture, etc.

So, it is not always possible to put the implementation classes and the classes that need to access the implementation classes in the same package for any combination of the above reasons or use inheritance between them. So, the standard Java package-private and protected access specifiers might come up short.

So, one of the consequences of these restrictions in Java is to make the class public, eventhough you may not want this class accessible to every other class in that module/bundle or classpath by default (depending on whether you are talking about OSGi or non-OSGi based applications).

Sometimes, I miss the C++ “friend” Class (not the function) access specifier. However, I think the “friend” class in Java should not have access to all of the private members, instead it should have access to the “friend” or “protected” members of the other class. But, perhaps the designers of the Java language may have decided against this due to fear that the not-so-OO-developers might violate encapsulation by misusing this feature.

I have seen or heard of various approaches to solve this problem:

• Use Delegation and/or Composition
• Use “internal” package names
• JavaDoc them as “for internal use only” (org.springframework.orm.hibernate3.SessionHolder in Spring API)
• Use classloading trickery to simulate “friend” access specifier. This may not work in web applications or OSGi (due to the “modularity” or various classloading architectures))

My preferred way to do this (if I absolutely cannot put them all in the same package and make them package-private) is to use delegation or composition or a factory class (depending upon the type of situation that causes this problem).

What do you think? Are there better ways to do this?

Don’t we need a modified form of “friend” access specifier in Java?

Technorati Tags: encapsulation, friend access specifier, Java friend class

Here are the things every Java developer working on OSGi-based middleware must know, IMO:

Essentials:

• Design-by-Contract & SOA
• Component/Package Versioning
• OSGi Bundle Lifecycle
• Bundle Manifest directives
• Core OSGi services
• Spring DM (especially for simplification of the usage of OSGi services and writing in-container tests)
• BND tool (I cannot think of a better way to create the OSGi manifest files than this)
• Basics of classloading in OSGi

Advanced Topics:

• HTTP Server options in OSGi (OSGi HTTP Service, HTTP Servlet Bridge, etc.)
• OSGi “uses” directive and the “type leakage” problem
• OSGi Services vs. Extensions/Extension points
• Service Trackers
• Concurrency gotchas in OSGi
• The Whiteboard pattern
• The “Extender bundle pattern”
• OSGi Declarative Services and Configuration Admin Service

Technorati Tags: OSGi, OSGi essentials, Whiteboard pattern

Today, during load testing I saw one of those dreaded “java.lang.OutOfMemoryError: PermGen space” errors on our fairly large web application deployed in Tomcat running on Sun JDK 1.5.

We used to use the default (64m) for the perm space. I bumped it to 128 for now, until I can find some time to dig into this using JProfiler and JHAT.

I will be particularly looking at the amount of our classes loaded from WEB-INF/classes dir (we have a lot of generated classes from legacy code), Static references in our legacy code, Spring AOP/Hibernate CGLib usage and ThreadLocal usage in our application.

I found some useful information here:

• http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
• http://my.opera.com/karmazilla/blog/2007/09/29/return-of-the-permgen
• http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
• http://blogs.sun.com/sundararajan/entry/querying_java_heap_with_oql

Technorati Tags: OutOfMemoryError, Performance tuning

I think the Java developers (especially server side developers) have started looking at OSGi as the next-generation Java Middleware technology. This may not come as a surprise because of the adoption of OSGi by the JEE server vendors and Java (server, desktop and embedded Java) community in general.

OSGi technology:

1. Enforces better componentization (separation of concerns) than most existing techniques in JEE (Using one classloader per bundle).
2. Provides versioning of components and the ability to deploy multiple versions of the same components in the same VM, unlike JEE.
3. Unless you use one ”component” for your entire application/product, OSGi enforces SOA for components using dynamic services (or “Extensions”/”Extension points” for those wanting to use the old Eclipse standard).
4. Enforces loose coupling of components (using a publish/find/bind service model).
5. Forces the resolution of application dependency problems (requiring explicit declaration of dependencies between components).
6. OSGi ”fixes” Application server hot-deployment functionality (ability to deploy/undeploy software components without requiring the Server/JVM).
7. There are multiple opensource OSGi implementations available:
   • Equinox / Eclipse
   • Felis / Apache (Oscar)
   • Knopflerfish / Makewave
   • Concierge
8. OSGi implementations are quite stable with many applications/servers using or running on them.
   • Ricoh has been shipping Printers with OSGi since 2005.
   • BMW 5 series cars ship with OSGi.
   • JBoss, IBM WAS and BEA Weblogic servers are adopting OSGi.
   • Sun’s Glassfish uses OSGi
   • SpringSource dm server is built on top of OSGi.
   • Mule ESB
9. The OSGi implementations generally have a small footprint (With OSGi Jars that are less than 500 kb).
10. OSGi has proven itself in the embedded and desktop application world too. The open source Eclipse IDE has been based on OSGi since 2004.

Technorati Tags: Java middleware, next generation technology, OSGi, OSGi middleware

Ferrari has been steadily growing over the last 10 years. Ferrari California is a new model line that will push this further. What struck me is the innovation here:

• This is Ferrari’s first ever V8-powered front-engined car with the first-ever retractable hard-top.
• This car has the lightest and the fastest retractable hard-top in it’s category - it opens and closes in 15 seconds. It weighs less than the soft-top featured on any Ferrari ever created.
• Boasts the lowest ever drag coefficient (0.32) for a Ferrari car.
• First Ferrari to have direct-fuel injection and twin-clutch gear box.
• Most fuel-efficient Ferrari (21.5 MPG), but still revs up to 8000 RPM and still matching the Torque/Engine capacity ratio of the previous generation BMW M3 CSL.
• This is the most comfortable, best balanced, best manner Ferrari ever for everyday driving.

Wow..!

No wonder these cars are sold out until the end of 2010 even if you can shell out over $250,000.00..!

Technorati Tags: Ferrari, Ferrari California, Innovation

I am currently working on performance tuning & refactoring a product. And, interestingly I found some Agile/Lean principles that apply for performance tuning and refactoring:

• Most Lean principles appear counter-intuitive at first
• Aim for system optimization instead of point optimization
• Build prototype and measure (run quick experiments), not just theorize
• Minimize the number and size of things-in-process
• The most predictable performance comes from maintaining options until you have the most information

Technorati Tags: Agile, Lean principles, Performance tuning