Non-indexed foreign keys

Let me start my first accepting a misconception which I had till very recently. I sort of always assumed that foreign keys are always indexed. A little more digging revealed that Oracle, DB2 and even SQL server does not create an index for a foreign key automatically. So it has to be explicitly done.
We all know indexes has cost associated to it. Apart from using the storage space, it has to be maintained by the database on inserts and updates but still it is very good idea to create an index for a foreign key and especially when

• We have a use case where deletion of the parent row cascades into deletion on the child table. Otherwise it will lead to a full table scan of the child table for each parent row deletion.

• We frequently join parent and child tables. Otherwise it will have a performance impact.

So basically a little bit of a trade off as what we really want to do but in general it is always a good idea to have an index on a foreign key.

But does all this have any impact on how we do our Hibernate mappings, yes for sure. So for example if we decide to not index a foreign key, then

• Be careful while using : on-delete=”cascade” even though the database has a support for it

• Always specify lazy=”true” to prevent a join and eager fetch of the child rows.

Package Structure

It might get very interesting and tricky to layout the packages, no I am not talking some skeleton directory structure which is generally created when we create a new eclipse project or run maven, it is more about the way packages should be structured to avoid cyclic dependencies.

When we start we start out with a very basic bare minimum structure but it starts to get ugly as code evolves and we start to unknowingly and unintentionally start creating cyclic dependencies.

What are they : Package A depends on package B and package B starts to use a class of package A

Why Not: Hard to maintain code where a change in package A leads to change in package B which in turn might again need a change in package A. So a small change starts to propagate throughout the module or may be beyond. Hard to reuse code as it will not possible be to take out a package and convert it into a module due to high dependencies across packages.

How to measure it: There are certain static analyzing tools which help in finding out the cyclic dependencies and a free and very popular one is JDepend.

If already in it how to get out: Common set of classes spread across packages into a single utility package or may be in a full blown module.

Rule of thumb: Packages should have one-way dependencies

Architecture Sins

Top ones on my list

Rigid : The more rigid the architecture is, harder it is to change as very often an architecture has to adapt to changes and it might very well go much farther then it was initially designed for. When making a change in a component cascades changes in many more components, then we know we are in trouble. To break the rigidity always design to an interface, inject the dependencies, design the classes to do one thing and do it right so that they are enthrusted with single responsibility all the time. Follow the open-close principle keeping the pieces of architure which is going to change often (like configuration, data etc) from the ones which seldom changes.

Application Availability

Availability should be defined not just at the application level scope but also at each functionality level. It should be further quantified in terms of acceptable response time.

Availability of an application is increased by getting rid of single point of failure and this is done by converting this point into a pool of points so that if one goes down, the request is served by another point. Pooling the point is more commonly referred as horizontal scaling and building for it requires load balancing the requests hitting the application plus a provision for fail over support.

Load balancing and fail over support is done through deploying the application in a clustered environment. Clustering not only ensures high availability but also make the application more scalable. Clustering is the term which describes the was to provide redundant servers to ensure high availability.

Clustering is OK but what to cluster, anything where we are calling a distributed object, so need to cluster those components that can be deployed in a distributed way.

How to scale a J2EE application?

Some quite simple and basic points.

• Get rid of single point of bottleneck : There can be any point across the whole architecture of a layered lava application which can act as a constraint from the application to scale . This point is know as the single point of bottleneck, Single point of bottleneck can be any service, resource or server that all the request shares and goes through, examples can be connection pools, singletons, databases, JMS queues, web services etc. First we need to identify that constraint and then identify the ways to remove that constraint. This should be done till we end up finding another constraint.

 

• Do not use databases for everything : Do not persist high volume stuff which is of very little return like logging info, http session state (there are much better performing options for caching stuff like these) into the database. Put only those things which are persistent and transactional.

 

Architecture vs Design

How different they can be? Most of the time when we talk about one we meant another.

Design is local and Architecture is global : When we are trying to design something it is very local in scope say interfaces for our classes while architecture is much broader like layering out the tiers and how they relate to each other. Architecture provides the blue print of the system.

Architecture is more about system behaviour : As opposed to design, architecture reflects business needs and quality attributes of the system, like the different ‘ilities’ such as modifybility, testability, upgradability, reliability, scalability, availability etc etc.

What SOA?

I have heard and read so much about it that I finally decided to put in words what I make out of all this hype and myths

SOA is an architecture or an architecture style that builds on components or software agents called services which embodies a core piece of an enterprise’s business logic for general consumption directly from the network

These services have following characteristics.

* Loosely coupled : Not bound together
* Interoperable : Diverse in nature but works together
* Composable : Self contained and stateless
* Protocol Independent
* Are exposed through message interfaces
* Coarse grained

These services can then be choreographed or orchestrated to realize the business processes