Dependency injection while solves many problems and allows projects to be simplistic, it has a very serious shortcoming, that is, it only EASES dependency management but does not ELIMINATE it. Surely people who have worked with such projects have realized and seen how tightly coupled tiers are when building a commercial web application using Java and DI frameworks such as those. The crux of such applications is being driven by how efficiently they manage their dependencies and not how they try and produce a de-coupled architecture so as to eliminate dependencies completely. Lot of people would think that producing de-coupled architecture leads to:
A.) Confusion
B.) Complex architecture that is hard to follow and also needless.

Both those points are agreeable to some extent, but it is also very important to point out how these applications must then be treated as just one application without any future. A big difference in thought process of building a product family vs. a single application meant for a specific (very specific in fact) purpose is that product family attempts to solve family of similar problems or interconnected or chained problems (Not to sound too theoretical), whereas the purpose of a single application is being driven by immediate needs. Both types of applications have their niche, and increasingly the second one is being adopted as a de-facto standard for building applications.

This is True for environments where time constraints are just un-avoidable and care has to be taken to meet deadlines; However it is VERY VERY unfortunate in my opinion. While a single application that “just works” might work and solve a single problem without any scope creep, without a long term software product strategy that allows each of those “single problem solving” applications that “just work” to be added seamlessly to existing architecture (I wont use term SOA here), no organization can survive. (Wow that really sounds like bunch of business folks mumbo jumbo, but its true, or I think it is ).

Hence building de-coupled architecture for each and every application and taking care of the factors that will allow each component to be re-used across several applications will empower an organization to use software tools and applications in a big way. Conceptually De-coupled architectures are not very new, in-fact one of the oldest architectures that exudes de-coupled architecture at its very heart is the concept of Event Driven Architecture.

Let us refer to Event Driven architecture definition on Wikipedia, which is I guess simplest to understand.

Event-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events. An event can be defined as “a significant change in state”. For example, when a consumer purchases a car, the car’s state changes from “for sale” to “sold”. A car dealer’s system architecture may treat this state change as an event to be produced, published, detected and consumed by various applications within the architecture.

Several components of event driven architecture make it a suitable candidate for any and all kinds of applicable fields/domains. Some of those are:

• Separation of concernsEvent driven applications provide with purest form of separation of concerns as each of the so-called listeners will listen for event or group of events (more on this later) and so are more naturally reactive when compared to traditional counterpart components (especially in java web applications)
• Simplified architecture, oh well it sounds implausible at first, but it is true. True event driven architectures are easier and more systematic to follow, this is primarily because of the fact that there are only two components at each tier or for each tier, listeners and events broadcasters (well mostly, terminology would make it sound complicated but it really is not).
• Business Intelligence friendlyDriven by events allows for application to be more conducive to “learn” (This is primarily true because series of events in a particular order and their result can allow applications to formulate rules or rule-sets that can be applied in future series of events to detect stuff (more on this later)

Now that we have discussed and have sung hymns in praise of Event Driven architecture, let us look at basic structure of an event driven application. An event driven application (This is simplified to make it practical and easier to understand), typically consists of:

• Event(s)
  Events form the heart of an event driven applications, An event in its most basic and simplified form encapsulates a particular state of a particular system or a model that stays immutable (but can be enriched with some additional “resulting” data (typically results from processing of the event by listener). It makes sense that events are immutable because if we think about events, once they happen, well they have happened, we cannot go back in time and reverse those events (unless our application uses a time machine to go back and make those changes, oh and that will drive our applications and its rules crazy ).
• Event Broadcaster(s)
  A broadcaster broadcasts an event to “stream it” (the term that is often used to say to provide the event to the event “sink” or the event engine. A broadcast of an event happens once an event has been triggered, A broadcaster typically hands over the event to an event engine which will do some internal processing and then hand it over to an appropriate event listener / processor.
• Event Engine
  An engine typically uses a context or a placeholder or first level cache of some kind to know what events are being handled by whom, At present I cannot think of a way to make this more dynamic (NOTE: We computer science folks are always driven by behavior of the natural world, I guess in natural world when an event happens if you happen to be vicinity with all sensory perceptions, you will see / perceive … but lets not get carried away by this ). Event engine loads the cache and uses it to dispatch the event to the appropriate listener(s).
• Event Listener(s)
  A listener typically registers itself to the context/cache that is used by the engine to associate events it is registered for. When an event occurs a listener is the place where final processing of the event will be done and the event itself will be “enriched” with the resultset data to provide final results.

Now that we have a fair idea as to what event driven architecture is like, let us try and associate how this can be transformed easily into an atypical three-tiered commercial web application and be converted to a reliable model for software development. In a traditional web application, there are three tiers, namely presentation tier <--> business tier <--> DAO tier. I will not go into details of each tier(s) and their component(s), but if you are curious refer to J2EE Design pattern catalog here: J2EE Design patterns catalog. In essence each tier is dependent on the tier below to get its results and then finally provide results back to the client.

It is this architecture that makes each of the tier highly coupled with the tier below. Lets try and use this paradigm for a moment and transform it into an EDA (event driven architecture). Our sample application will include three tiers as above, but components will change within tiers to use Event Driven programming paradigm to allow for thorough de-coupling of the tiers. The structure will be as follows: NOTE: Just to emphasize, I’ll discuss event engine and other internals and possible coding snippets in next post, I don’t want this blog post to be too long to read)

• Event(s): To add to what is already been explained, several types of events will be assumed:
  
  • Business Events that are handled by business listeners
  • DAO events that are handled by DAO listeners.
  • Auditing events that are handled by auditing listeners
  • Generic events that are handled by pretty much all listeners
• Presentation Tier:
  • Event DTO shuttle: (This needs to be a post in itself, on which I’ll elaborate later), for now we can think of event DTO as a wrapping entity for an Event itself. (typically will contain getter and setter for an event type) and a broadcast method that will use a broadcasting agent to deliver an event. When an event occurs (like a mouse click by user for a purpose, broadcast method is invoked on this DTO shuttle which in turn uses broadcasting agent to broadcast an event.
  • Broadcasting Agent: Essentially responsible for event broadcasts and queue an event for processing by an appropriate event listener that is listening for such an event. In simplified coding terms, this will be as simple as:
eventQueue.add(event);,Note that this happens in a broadcast method.
• Business Tier : Will typically contain business listeners, these listeners will have a method onEvent( ) that takes in the actual event it is being provided, extracts the model out of the event and processes it in some way, puts it back in the event, uses the current event to construct a new DAO event if necessary and broadcasts it, NOTE for now we will assume that DAO events be broadcast by only business listeners themselves and not by client in a direct manner.
• DAO Tier: Will typically container DAO listeners that will do communicate with database either by using native JDBC or with some ORM framework (which is irrelevant to the topic for now) and finally will provide a final result based event that will be again dumped to the queue managed by event engine.

Using above architecture as our basic guide, lets analyze one basic flow for a bit (I am too lazy to draw diagrams so I guess I have to write 1000 words ). Steps are as follows:

1. An event is populated based on request gotten from the client (this could be a JSON string to any web service request … whatever we don’t care for now)
3. Wrap the event onto DTO and call new SomeModelEventDTO().broadcast(new SomeEvent());
4. A call to DTO broadcast results in broadcasting of an event using Broadcasting agent, which will simply dump the event to the event queue.
5. Next, Internally engine takes over and uses context and configurations to call appropriate listener by exhaustively going through queue of concurrent events. This call is essentially achieved by doing new SomeEventListener().onEvent(new SomeEvent())
6. Business listener performs basic validation and uses logic to process events it gets and then finally once everything is ready, calls a broadcast to add DAO events to DAO event queue that is once again managed by event engine.
7. DAO listener for dao events are invoked using the same mechanism by event engine to allow for further processing and persisting the data if necessary. A DAO listener once finished will further make a call to an event (something like event.setResult(new ProcessedResultFromDB()); and then finally add the event enriched to event queue.
8. Once event is added to the event queue, it is then picked up by the engine and dispatched to the DTO (fancy term to say dispatched, a simple new DTO().setResult(new ProcessedResultFromDB()); would do .

Observations

One of the first things that we can notice is that everything is dependent on event dispatching mechanism. But leaving that piece of discussion for the next post for now, one of the basic and very big advantages of the above flow is that no tier is dependent on the next tier or tier “underneath” from a traditional java web applications perspective. This makes for highly customizable applications where tiers can be swapped easily, re-used. For example, if we want to re-use business tier listeners, we can do that easily by simply adding and associating those listeners with another application (this could be done by adding them in either XML or annotating them using some @EventListener(type=Business) kind of annotation, anything). What does this buy me? Well for one thing, nothing is inter-dependent and therefore everything is so highly re-usable, All we need to know from an application development standpoint is what kind of events i want to track/isolate and how do i react to those events.

This makes for easy and highly customizable applications where presentation tier swapping (with a better UI tier) or DAO tier re-use becomes a distinct reality amounting just config changes either through XML or through annotations.

Summary:
We discussed, very briefly what an event driven architecture is, what are its advantages, how it can de-couple tiers and allow for re-usability, Next we discussed a possible sample application and how the hearts and parts of the application would work under event driven paradigm. In the next post, I’ll discuss more about:

• Event engine
• Event engine context / first level cache
• How event based frameworks give way for intelligent systems and perhaps AI?
• How event driven applications be used to still shell out applications really fast
• How does HCIS (my own framework) scale up to the task.
• SOA 2.0 so as to speak where SOA when combined with Event driven architecture makes way for a new paradigm altogether.

Finally, thanks for encouraging emails and queries about when the next post is due … that kept me going. See you next time!.

I am working on several open source framework projects at the moment that are interesting:

1. Influx : The project has become dormant lately because of lack of interest for the most part from the developers, however this essentially formed a precursor for me in the early days to think differently (especially in terms of event driven programming) and architecting the applications on the same ideas or thoughts.
2. hcis-dto : Part of my hcis framework project modules, This was released (first release!) yesterday by me, Lot of thought and work is almost there. I’ll be posting ideas on this one soon!
3. hcis-model : Released next version yesterday, now includes search criteria, filtering, property projection paths and many more exciting type safe features that can be leveraged independently in a project. This definitely deserves a post of its own!
4. hcis-dao : Created and conceptualized a re-thought DAO (very different from the concept of your average DAO), and in process of writing test cases for the same, Development is almost done for the first release. This definitely deserves a separate post on its own.
5. hcis-ui-js : Prepared namespacing, namespace creator and manager, now in process of implementing CRUD operation calls via JSON, AJAX using native AJAX instead of JQuery or Dojo, primarily because I wanted to have more control. Also created an abstraction API for other popular widget based JS frameworks, by creating a widget factory in javascript that loads cross over widgets, still in works. Again, will be posting something on this soon and functional programming in general.
6. hcis-sandbox : This is where I’ll prepare and keep some of the implementation projects giving a generalized idea as to how one can leverage the framework to develop in-house products at a faster and in much more de-coupled fashion. I’ll probably explore using Spring context, or Plexus or other dependency injection containers.
7. CoContainer : No updates, basically I am stuck at the fact that I somehow have to figure out how to create component tree by simply going through packages and checking if a class is annotated with HCISEntity or something similar, if so, the class can be instantiated and its lifecycle can be managed, however, processing packages has loads of caveats and is not a very friendly process, so I am exploring more options and looking for approaches on this one. Any suggestions?

Finally, Most of the framework has been simplified (oh and most of this stuff got working this week itself … before that it was just abstract ideas sitting there … ), concentrating on how it will be “used”. Sometimes re-usability has to be compromised for ease of usage, but in my case, I have been lucky enough to keep it completely re-usable but keep it very easy and intuitive to follow, which has again made working with the framework much more fun!

Aren’t we in exciting times?
Regards
Vyas, Anirudh

]]> http://anirudhvyas.com/root/2009/05/07/updates/feed/ 0 http://anirudhvyas.com/root/2009/03/09/open-source-initiatives/ http://anirudhvyas.com/root/2009/03/09/open-source-initiatives/#comments Mon, 09 Mar 2009 03:47:58 +0000 Administrator http://anirudhvyas.com/root/open-source-initiatives/ Its been a while since I updated the site, so i thought it is best for me to add a page to say what I have been up to. I have been working on an open source project, a result of culmination of thoughts and ideas I derived from my work and a few other people in the past. The project is known as HCIS (pronounced as letter ‘h’ sis) and you can find the details about it here: HCIS

I am also part of another open source initiative called influx hosted on sourceforge; More information on that can be found here : INFLUX. While both the projects attempt to solve business tier woes with similar kinds of ideologies (There are differences in approaches, and the current approach that influx has taken is what i disagree with slightly); HCIS framework more specifically is an attempt to provide a complete stack of solution API along with its own DI container / (or engine in HCIS terminology) that will make assembling a complete three tier application very easy and transparent to developer with minimal configuration, minimal conventions, minimal effort overall.

I have also planned for maven plugin for HCIS project in future, and an eclipse plugin for Rapid application development for the same.

Oh, so NOT Another framework people might ask? well our framework doesn’t provide mere absractions to already existing solutions like other famed frameworks do (take a hint ), but it attempts to shield and provide a completely new and refreshing paradigm of programming and thinking. The ideas culminated in the framework are not new; in fact lots of other frameworks internally are driven by the same ideas, but i think its time that we bring those ideas on the table and make the same de-facto standard for programming in future. When it comes to business tier code, we have tried quadrillion things, but it can get complicated.

I am not trying to re-invent or re-write standards here, In fact the framework will drive and gel very well with EJB model of programming for those of you who are EJB 3 / JPA standards fanatics, but we are providing with and without sides of the coin. HCIS framework (as well as influx) provides type safety, different mechanism for dependency injections, lifecycle management without use of XML files that often get bloated with stuff that should have been done in Java in the first place.

HCIS on the UI tier will attempt to provide generic components to foster re-use and quick turnaround for web applications. More on HCIS soon…

]]> http://anirudhvyas.com/root/2009/03/09/open-source-initiatives/feed/ 0 http://anirudhvyas.com/root/2008/10/20/art-of-defensive-programming/ http://anirudhvyas.com/root/2008/10/20/art-of-defensive-programming/#comments Mon, 20 Oct 2008 18:48:45 +0000 Administrator http://anirudhvyas.com/root/2008/10/20/art-of-defensive-programming/ Its been a while since i wrote my last post; Been busy working on a reporting framework of sorts (that attempts to abstract out all implementation details of various reporting tools like Crystal, Business Objects or JASPER reports, BIRT and work seamlessly without developers using the API being bothered with implementation details.

Building a framework is always a learning curve. I have been involved with building frameworks in the past, each one adding different but consistent experiences over their predecessors and so far the only fixed learning experience I have drawn from is that one must always code defensively while developing any piece of logic or code. That would mean assuming following things:

1. All API users are careless or will get careless at some point
   Meaning most of the framework users will have time crunches and desperate times call for desperate measures. In their desperation they might resort to quick and dirty solution which might not be what the framework was intended to be used for; and although this might work perfectly in use case A, but will most likely cause confusion and break some other piece of code causing chain reaction and finally blame coming down to framework developer.
2. Developers might override the default functionality to fit in their use case
   This is sort of a controversial point but I still standby it. There are times when we must put an end to amount of extensibility even though we live in Object oriented paradigm. As an example; if today i create some class as follows:

   // java docs removed for clarity
   class X {
   
           // bound value.
   	private Integer boundValue = null;
   
   	// sets the bound value ... java docs removed for clarity.
   	public X(final Integer pBoundValue) {
   		setBoundValue(pBoundValue);
   	}
   
   	// gets the bound value ... java docs removed for clarity.
   	public Integer getBoundValue() {
   		// FIXME : Note that this method is not finalized!
   		return this.boundValue;
   	}
   
   	// sets the bound value ... java docs removed for clarity.
   	public void setBoundValue(final Integer pBoundValue) {
   		// FIXME : Note that this method is not finalized!
   		this.boundValue = pBoundValue;
   	}
   }
   

   As you can probably make out methods are not finalized, lets see how that can ruin the whole show …
   

   public static void main(final String[] args) {
   
   		// some long block of code goes here ...
   		final X x = new X(100) {
   
   			// java docs and annotations removed for clarity.
   			public Integer getBoundValue() {
   				return null;
   			}
   		};
   
   		// huge chunks of code here ... and suddenly developer needs x variable afterwards ...
   		// FIXME : Throws a null pointer because some developer decided to play i am the boss 
   		System.out.println(x.getBoundValue().intValue());
   	}
   

   The above scenario might be hypothetical, but things like above (not same events necessarily) can happen, hence importance of making your code protected. However this statement has to be qualified by a big if ; and that means making it protected only when a developer cannot for-see that in near future people might need to override this code for some “legitimate” reason. By legitimate I mean, using it the way it was intended to be used and adding additional functionality to it and not necessarily breaking what the original contract was. An example of such a case might be a state object, which maintains the state of say variable x; in such a case it is always wise to finalize accessors and mutators for x, so that it is only used for what it was intended to be.

To account for all above issues and plethora of others defensive programming is the mantra.Defensive programming techniques are not new, in fact this concept is an old one, referring to wikipedia for for formal definition:

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy’s Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.

Defensive programming helps reduce code unpredictability; makes code cleaner, more consistent and truly re-usable (by true re-usability I mean re-usability based on applicability not intended to break the contract that is set forth by the developer of the API). This becomes a serious issue once we start dealing with multi-threaded environment; where multiple threads deal with shared data; if the shared data is immutable (state wise at least), we can say that it is safe to share the same amongst different threads.

Not only does defensive programming helps in producing cleaner, efficient and more reliable code; but it also helps support team developers. Being a production support developer is not an easy task by any means. Imagine a programmer being called at 2 in the night to fix some urgent issue and he has to sift through ton of code. In such cases, (Even with the tools available today with likes of Rational Application Developer, Eclipse, IDEA etc), it becomes extremely difficult to debug things, especially when they are being used in a particular fashion in each spot. An example of such scenario might be debugging say a method (non-final) that gets overridden (which was NOT intended to be) in 3 places and each in different ways; This would drive me nuts … yea try doing that at 2 in the morning . Needless to say in such cases defensive programming on part of developer helps just a tad bit.

We’ll discuss some of the well known techniques in java world (this should apply to general programming as well) :

1. Finalize methods where-ever applicable / possible
   Use your common sense to allow extensibility or overriding capacity to methods. This should mean that unless we foresee that in near future this method might be used in n different number of ways (in which case this should be an abstract method in the first place ) it would make more sense to finalize it. A non final method is dangling there to be misused, unless there is some future flexibility that we want account for and provide.
2. Finalize parameters as a thumb rule!
   Parameter finalization not only makes intentions of a method published or unpublished clear; but also helps in clear understanding of the underneath code; allows usage by references (unless we are dealing with tiered architectures where some stuff lies on a different JVM… ); If those benefits are not enough, here’s a leaf from Martin Fowler’s book : As a first step to refactor code (refactoring to improve code re-usability), finalize parameters. Need less to say finalization of parameters helps in making the refactoring of the code easy. Imagine going through a long method and watching parameters being re-assigned every third line; needless to say this form of coding practice is horrible, but its not unheard off.
3. finalize classes whenever applicable
   A class finalized will have the same benefits as above, plus will guarantee that the intended functionality is locked and sealed and should only be used and not meant for extension. As an example, take the case of a Shape abstraction that follows non final class Car and a sub class BMWCar and further sub classed to particular model, type etc. (down to very bare specifics); if such a sub specific class is left non final, it could be anonymously subclassed at runtime and the intended behavior would change! imagine a BMW X5 behaving like BMW X3! (i was tempted to say Honda Odyssey but that was probably far-fetched! )
4. Check for nulls, Check the current state, Infer and throw exceptions where-ever possible
   Invariably and this is common practice; arguments might arrive either as being null, or assigned an empty or blank value. In such cases programs can be explicit by throwing exceptions as a thumb rule to ensure that no processing begins without verification of input arguments. Not only input arguments might be null, but even if they are not, they might just be either stale or plain invalid and might leave the state of the entire current instance of class in an inconsistent state, in such cases it would be helpful to throw an IllegalStateException and be explicit about checks. Some documentation as to what might happen on various values being passed always helps in such cases.
5. Use static typing as much as possible
   I am not proposing that Generics is the ONLY way to go; but i am a big proponent of using generic types and defining type parameters at class level. Taking a leaf from our example of getBoundValue( ) above in class X, here’s the modified code:

   class X<VALUE extends Number> {
   	private final VALUE x;
         // getters and setters for x go here
   }
   

   We have done two things in the above code: 1.) we have made the type of the value x, very explicit (helps in code debugging). 2.) we have made this class extremely re-usable (imagine that we don’t have to create a new class now every time, i use a different bound value type, like a Long would warrant a new class if we go by older code, here i just specify the type explicitly while initializing.

6. Favor enumerations for maintaining configurations
   An XML file is all fine and dandy for portability, and I would be happy if XML files had some sort of mechanism of self-validation(in fact they do); but since I come from development world, I would like to see compile time errors better than run time errors especially while parsing the file. How is an enumeration configuration buying me defensiveness? Well simply put (and i will not spend much time on discussing enumerations here, refer to : Enumeration tutorials at Sun Site for more details) enumeration consists of only finite states of a class type. It is 1.) type safe. 2.) Immutable (because it is a fixed state). 3.) You cannot extend an enumeration configuration.

   As an example, take some formatting configuration that a business tier logic dictates. for example setting width, height etc (not a good example, since we don’t want those coupled but still); this configuration could reside in an enum with several states like : DEFAULT, DEFAULT_WITH_HEIGHT_MAXED, DEFAULT_WITH_WIDTH_MAXED etc. By providing an enumeration here we have ensured that API users will always use configurations as expected, and just in case they need an extra configuration, they might have to go in and add it. (But this would be highly unlikely, since at the time of decision making and coding, it is the job of an API developer to account for most common and foreseeable cases for different configurations that are needed.).

7. Favor annotations
   I know that this is probably the most controversial of the points, but I still think that making a language less dynamic reduces the code complexity and reduces the production support time. Development time cost is always much less than bug resolution in commercial software world. For example if I have to allow a bean to be managed by container and if i have to specify in what way i want it managed; i would rather have it as an annotation, like @Scope( ) for example. This approach ensures a compile time error given if the scope is not applicable for the class which i want to be managed. In dynamic environment, a runtime exception would be thrown … How would this make my code defensive? well for one thing; if i have my configuration sitting in an XML file or somewhere else, anyone could go in and change things around transparently without me as a developer having any control over it. If I use annotations on the other hand;I would be free of such a worry. The other reason to favor annotations is their documentation ability, An annotation over a class would inject more static information available to a developer to illustrate its intent and purpose; makes their lives simpler and efficient. Josh bloch wrote in his ever so popular Effective Java stating that we should favor annotations vs naming conventions, here’s another instance of why annotations make our code more defensive; because Naming conventions rules are not enforced, but annotations can be compile time enforcing!

I tried to do justice to complex subject of defensive programming; In keeping with simplicity, I tried focusing only on Java programming language, although conceptually they are applicable in almost all of the languages, traditional in some respects, and non traditional in many others. I would love get feedback. Thanks once again for encouraging emails, makes blogging a lot more fun!

Regards
Vyas, Anirudh

]]> http://anirudhvyas.com/root/2008/10/20/art-of-defensive-programming/feed/ 2 http://anirudhvyas.com/root/2008/06/09/constants-maintainence-proposed-solution/ http://anirudhvyas.com/root/2008/06/09/constants-maintainence-proposed-solution/#comments Mon, 09 Jun 2008 00:55:07 +0000 Administrator http://anirudhvyas.com/root/2008/06/09/constants-maintainence-proposed-solution/ Almost all of us have used some sort of a common Constants class which gets piled with huge number of constants, ranging from things like SOME_IMPORTANT_ID to something trivial like INTEGER_VALUE_1. Whatever may be the reason, but the grouping of these things goes right against separation of concerns (as everything is virtually dumped in a single constants class). Some time back a common practice was to use Interface for declaring all constants and then allow for all classes to implement this interface to get all constants automatically. This solution needless to say was fast, but also outrageously wrong. Josh Bloch sums it pretty aptly:

• First of all, it causes a leakage of implementation detail into many unrelated classes in your code base, because any of the defined constant will be available to all of your classes when they implement this interface.
• As it is contained in the exported API of implementing class, clients of that class may get easily confused because it if of no consequence to the users of the class that it implements such an interface.
• Finally, it puts you into a commitment to ensure binary compatibility in the future, even though the class won’t need to use any of those constants.

Needless to say, I completely agree with all the above points, so what was the solution? well the solution was to come up with a common constants class in which you dump all your constants and add comments to group each in a certain way. Needless to say there will be some groupings which are outrageously funny. Like in one of the projects we had to check and constantize all integers, doubles, numbers. (refer to : Magic Numbers), due to lack of time (now thats new ain’t it? ), people were adding things like public static final int INTEGER_1 = 1 !!.

And top that with all things mixed up, one can be assured that the class turns out to be a mess. To top all of this java introduced a feature called static imports. Probably because many lame programmers were complaining that it is “too” much of an effort to precede the CONSTANT_NAME with its class, so it my class that has all the constants is called something like CONSTANTS, i would have to do something like CONSTANTS.CONSTANT_EMPLOYEE_ID or something in those lines to refer to any constant; So basically to solve this, java provides for static imports, all you have to do is import static XXX.XXX.XXX.CONSTANTS.* and viola! you don’t have to do that DOT thing anymore. This is Evil! How am I supposed to know that this constant belongs to this class only and not anywhere else?! needless to say my code gets more obfuscated and hard to read and maintain with static imports.

So where is the solution? Solution my friends lies in creating a common interface, generically tying it up to something and then creating separate place holders for each TYPE of constants. So if you want to group all IDs for example, use IDPlaceHolder which would implement this interface. Lets get started on how to do this. First we will create an interface called IConstantPlaceHolder like this :


// Java docs removed for clarity.
public interface IConstantPlaceHolder<T extends Serializable> extends Serializable {

	// gets the value for the constant
	public abstract T getValue();

        // sets the value for the constant.
	public abstract void setValue(final T value);

}

As you can see IConstant place holder is generically tied to a type "T" (let me know if you think of a better name than just a T ). It has two methods setValue and get value. It is a Common interface for constants that serves as a place holder for all constants grouped in a meaningful way. For example, all ID constants could be placed in one spot. A typical implementation would be something like:


 public enum IDPlaceHolder implements IConstantPlaceHolder<Long> {

       DEFAULT_ID(1008L);

        private Long id;

	 // default constructor sets the value.
       private IDPlaceHolder(final Long id){
          setValue(id);
       }

       // get the value
       public final Long getValue(final Long id){
        	return this.id;
        }

      // set the value
      public final setValue(final Long id){
          this.id = id;
        }

   }

Now all i have to do in client code is IDPlaceHolder.DEFAULT_ID.getValue() and i will have 1008L at my behest. It is expected and recommended that an IConstantPlaceHolder be implemented with the help of an enum, by using an enum one can take advantage of inherent type-safe features in java language. Similar to above we can/may have something like a place holder for all properties or association paths in Hibernate. For our purposes, lets take a simple example of simple string properties like first name, last name etc for an employee.

:


public enum GenericStringPropertyPlaceHolder implements IConstantPlaceHolder<String> {

	// employee's first name.
	EMPLOYEE_FIRST_NAME("Mahadev"),

	// employee's last name.
	EMPLOYEE_LAST_NAME("Shiva"),

	// employee's address.
	EMPLOYEE_ADDRESS("Brahmlok"),

	// employee department
	EMPLOYEE_DEPT("NA");

	// the property value we want to set.
	private String propertyValue;

	// get the value
	public final String getValue() {
		return propertyValue;
	}

	//set the value
	public void setValue(String value) {
		this.propertyValue = value;
	}

	// constructor that sets the property value.
	private GenericStringPropertyPlaceHolder(String propertyValue) {
		setValue(propertyValue);
	}
}




As you can make out, in my client code, I would do something like GenericStringPropertyPlaceHolder.EMPLOYEE_LAST_NAME.getValue() and i will get Shiva as the result. So basically to sum up what we have done in above to implementations is:

• Create an Enum which implements IConstantPlaceHolder<TYPE> which is generically tied to the TYPE of placeholder it is or can be.
• Set the attribute in the constructor and then basically declare the constants with the actual value being passed to them.

Advantages

---

Obviously, lot of you might be thinking at this point what is need for all this? well my justification is that when a project grows larger and larger, we will eventually end up with a file that looks bulky, bloated and all over the place and then at that point we would ask where is the separation of concerns that i love so much here ?. Trust me, even in a small project this can serve a lot of purposes by putting a constant to the place it belongs.

An improvement to the above place holder thing can be adding a MODEL in generic parameters and further restricting constants only specific to a model. I have not come with a final draft for the same, when i do, i’ll try to post it as a follow up. Btw, thanks for your encouraging emails and support, appreciate it and Stay tuned!

Regards
Vyas, Anirudh

]]> http://anirudhvyas.com/root/2008/06/09/constants-maintainence-proposed-solution/feed/ 2 http://anirudhvyas.com/root/2008/05/31/making-generic-dao-operation-specific/ http://anirudhvyas.com/root/2008/05/31/making-generic-dao-operation-specific/#comments Sat, 31 May 2008 02:37:21 +0000 Administrator http://anirudhvyas.com/root/2008/05/31/making-generic-dao-operation-specific/ After a long haul in posts, I am back again. Thanks to all of you for you encouraging e-mails, much appreciated. The Generic DAO pattern became a de-facto of sorts in Hibernate / ORM world some time back. In keeping with my never ending quest for improving upon already existing patterns available at hand, let us make our Generic DAO pattern more “specific” in concerns. For those of you who are not familiar with Generic DAO design pattern, refer to: Generic DAO Recently while working on a testing framework @ Home , It became apparent to me that operational testing warrants that we must separate out the functional/operational aspects for a DAO. Quickly recapturing what a Generic DAO does:

• It is Generically typed to a Model.
• It concerns itself to a Model and can include ‘n’ number of CRUD or combination of CRUD operations
• Each Model (known Persistent Class in hibernate world) is a concern of a DAO




Why Generic DAO is not perfect?

---

For starters a simple justification would be separation of operational concerns; we want our “operational” aspects for that Model / Persistent class be separated. So for example in a DAO if i am doing a SAVE operation, i should only be concerned with doing a SAVE in DAO and nothing else, If i have a DAO method which deletes a model, then DAO should only be able to handle DELETE and nothing else.


Using a Generic DAO can reduce clutter, but to truly separate out operational aspects would make the code even cleaner (off course it adds a “tad” extra burden of writing more classes/interfaces but it also would make the code more robust IMHO), the code needs to be functionally separate as well or operationally separate to make it a better suited candidate for writing robust test cases.

Let’s Get Started!

---

Continuing with my philosophy of “lets get down and dirty” in code, lets get on with seeing somethings in action. I will start out by creating bunch of interfaces on which I would then elaborate to give an idea as to what I meant when i said “separation of Operational Concerns”. Lets pull out a common Generic DAO interface.

 public interface IGenericOperationDAO<OPERATION extends IOperation<TYPE>,
                                           TYPE extends Serializable,
                                          MODEL extends AbstractModel<>,
                                          ID extends Serializable>{

	/**
	 * Performs operation on a model.
	 *
	 * @param operationType
	 *            operation to perform
	 * @param model
	 *            model to be operated upon.
	 * @see IOperation
	 */
	public abstract void performOperation(final OPERATION operationType,
			final MODEL model);
}

Lets examine this interface a little to get a glimpse of what i am talking about. IGenericOperationDAO is tied to a MODEL (an AbstractModel is just an abstract class that extends Serializable and serves as a common model for our Models that match the tables in Database). Our GenericOperationDAO interface has one method, that is well apparently very "Generic", it just says performOperation takes in an IOperation type and a model. an IOperation type interface is basically something like this:


   	/**
	 * Gets the operation type.
	 *
	 * @return the operationType
	 */
	public abstract TYPE getOperationType();

An operation type can be DELETE, CREATE, READ, UPDATE or anything of that sort. An implementation for this operation is as follows. (For simplicity’s sake, lets assume that we need to do only a deletion (C-U-D operations will be the same).:


public class DeleteOperation implements IOperation<String> {

	/**
	 * {@inheritDoc}
	 */
	public final String getOperationType() {
		return "Delete";
	}

}

As you can make out that operation type simply returns a delete “string” (this can be useful in comparing operation types within a DAO), a string is not very robust approach IMHO, if someone has better ideas, feel free to share !

Now since perform operation is perhaps too generic, lets extend this interface to incorporate our deletions. Here is an example of a generic Delete interface:


public interface IGenericDeleteOperationDAO extends IGenericOperationDAO<DeleteOperation, String, AbstractModel<Long>, Long> {

	/**
	 * Deletes a model.
	 *
	 * @param model
	 *            model type to be deleted.
	 */
	public abstract void processDelete(final AbstractModel<Long> model);
}

Notice that our generic delete DAO is generically typed to DeleteOperation type.
As we can make out from the above, the generic delete dao inherits performOperation from its generic counter part and extends it by adding processDelete which basically takes in the model and deletes it. All implementing classes (Concrete that is) are expected to implement this method. But as we can make out that we probably don’t want to do certain kinds of things that are in here by implementing this interface directly. Implementing this interface has to be discouraged here since it does NOT directly enforce me going and implementing performOperation unfortunately. To avoid that from happening, lets create another abstraction (i.e. an Abstract Class which implements certain parts of this functionality), see below:




// java docs left out for clarity
public abstract class AbstractGenericDeleteOperationDAO implements IGenericDeleteOperationDAO {

	/**
	 * Default constructor. Calls perform
         * operation which in turn calls process
         * delete to delete the model given.
	 */
	public AbstractGenericDeleteOperationDAO(final DeleteOperation operationType, final AbstractModel<Long< model) {
		performOperation(operationType, model);
	}

	// javadocs left out
	public abstract void processDelete(final AbstractModel<Long< model);

	//javadocs left out
	public void performOperation(DeleteOperation operationType, AbstractModel<Long< model) {
		if (!operationType.getOperationType().equalsIgnoreCase("delete")) {
			throw new UnsupportedOperationException("No other operation except DELETE supported");
		} else {
			processDelete(model);
		}
	}

}

Quickly the above code will do this:


• Constructor calls the default implementation of perform operation to account for any other operations if any being passed in, for example if a user manages somehow to pass in something other than a Delete Operation
• calls in process delete which is an abstract method, all extending classes (Concrete) will be Required to implement this method (if they are a Delete DAO type)

So basically a simple implementation of a DAO from a client perspective would look like this:


/**
 * Employee delete dao. Concerns itself with just the delete operations for an Employee Model.
 *
 * @author Anirudh Vyas
 */
public class EmployeeDeleteOperationDAO extends AbstractGenericDeleteOperationDAO {

	/**
	 * Full constructor.
	 *
	 * @param operationType
	 *            delete operation type.
	 * @param model
	 *            model type to be operated upon.
	 */
	public EmployeeDeleteOperationDAO(DeleteOperation operationType, AbstractModel<Long> model) {
		super(operationType, model);
	}

	/**
	 * {@inheritDoc}
	 */
	@Override
	public final void processDelete(final AbstractModel<Long> model) {
		// perform Hibernate Deletes here...
	}

}

Now at real client side for this DAO would be a simple matter of doing something like new EmployeeDeleteOperationDAO(DELETE, employeeModel); and viola! we are done! … similar pattern can be followed for Creation, Reads, Updates. For combination of CRUD operation, a perform operation should be enough. Later we will see how we can improve upon the operation type to make it a little more dynamic than just comparing it with a string or returning a simple string “delete” or a “create” in operation type, so stay tuned and thanks for reading!

Addendum : understandably there can be improvements done in this; refinements etc. If you have any feel free to comment out here, instead of mailing them. That would keep it consistently here. I will try my best to post whenever i get any emails about the refinement.

Regards
Vyas, Anirudh

]]> http://anirudhvyas.com/root/2008/05/31/making-generic-dao-operation-specific/feed/ 0 http://anirudhvyas.com/root/2008/05/19/maven-basics/ http://anirudhvyas.com/root/2008/05/19/maven-basics/#comments Mon, 19 May 2008 00:57:38 +0000 Administrator http://anirudhvyas.com/root/maven-basics/


Basics, Installation

Maven is a project management tool. I am going to be practical about this page, since there are numerous books/pages/documentation out there explaining maven and I don’t want to be a “me-too” kind of a tutorial on maven. In keeping with my basic philosophy “lets get down and dirty”, lets install and get you up to speed on maven.Now before starting I would assume you have Eclipse IDE, Java 5 or higher installed on your system. Lets start, first lets get maven and install it on the system. This one’s a no-brainer, go to Maven Download site! and get it up and running. follow all the instructions of setting paths correctly. should you miss somethings go and consult documentation again.

Now lets get the Maven eclipse plugin, Use the following steps :


1. Click on help on upper right corner of eclipse IDE. use Help to go to Software updates > Find and Install > Search for New features to install > new remote site
2. Plugin M2Eclipse in URL and give it a name.

Once you get the plugin, it will ask you to restart Eclipse, do so.

Now lets get down to doing some stuff with maven. First we will create a maven project, a maven project will have a particular setup with it (You will see how it is once you create a maven project), so lets execute our first maven command:


mvn archetype:generate

The above will give you a series of options, usually till 36, each of the option is a type of project you want to generate with basic structure and libraries in built for you. select the most basic one which is option 15 which is maven-archetype-quickstart (). Next it will ask you punch in group-id, artifact-id, version, package. Use below values: (this is just a sample, you can enter whatever you want to ):


• groupId : om.shiva.application.payroll
• artifactId : payroll-sys
• version : 1.0
• package : om.shiva.application.payroll

Well, first off all those four things are what will identify your project for maven, they are in most simple terms maven project coordinates.Next, maven will as you to confirm all the settings, just hit enter or enter “Y” to confirm all the settings, and viola! you have your very first maven project. Now, once you go inside the project you will notice that there is a file that is called POM xml, this file is where all the settings are for maven. (Lets not talk in details about it for now, we will explore this in detail later). Now that our project is made, lets try and import it to eclipse … WAIT!


Take a deep breath! The project is NOT ready yet to go and become a star Eclipse project . Let us enable it to be imported to eclipse workspace. First to do so, you have to set M2_REPO variable.

mvn -Declipse.workspace=”ENTER PATH TO YOUR ECLIPSE WORKSPACE HERE WITHOUT QUOTES” eclipse:add-maven-repo




Additional Note : (Thanks to Sanjay Patel @ Oracle ) You can also add M2_REPO variable by browsing to: Window – Preferences – Java – Build Path – class path Variables adding new M2_REPO variable that points to maven repository folder so created in Eclipse IDE.

Next up, run the following command:

mvn eclipse:clean eclipse:eclipse

Nothing special here, For now ignore the messages that maven gives about javaDocs and sources. Now we are ready to do a formal import. use File > Import > Existing Projects in the workspace.

Use browse to select the project we just made. And viola! we are done. Finally you should see something like this :
Click here to see the Project setup!

You are good to go. Some of the other important things / commands to remember are :

mvn compile

The above will compile the project.

mvn test

The above will compile, and run all the test cases of a project. (Notice the ordinance, Maven executes everything in phases, like for example if you write, mvn validate then just validate phase is executed. But if you give something like mvn compile, then first maven will run validation and then compile the project, similarly mvn test would result in validation –> compilation –> test). There are other phases after this too, like Integration-test, verify, install, deploy (In ordered form respectively). So for example if you give a command like mvn deploy (deploy is the last phase), maven will execute all the preceding phases starting from validate. Maven also (thankfully) allows you to get Javadocs and source code for the dependencies you are downloading, this can be helpful when you are debugging an application that uses other frameworks like Hibernate, Spring or JSF implementations out there or Wicket. (Forgive me if i forgot tapestry and other ones … cant give the whole shopping list here ). so for that you simply do mvn eclipse:clean eclipse:eclipse as we did before but add -DdownloadSources=true and -DdownloadJavadocs=true to it and there we go Ladies and Gentleman, complete maven project.

So summarizing things, we can now import a simple maven project to eclipse workspace, we know how to compile, run test cases (using command line, I’ll talk about doing this with the eclipse plugin later, Shouldn’t be that hard) and finally we know how to generate sources for our dependencies (like Hibernate for example).

In next part, we’ll talk more about POM xml and go into details of maven. For now, you can play with maven (or at least have enough to fool around with it).

Thanks for your time!

Regards
Vyas, Anirudh

]]> http://anirudhvyas.com/root/2008/05/19/maven-basics/feed/ 0 http://anirudhvyas.com/root/2008/05/04/ever-controversial-and-sometimes-annoying-code-reviews/ http://anirudhvyas.com/root/2008/05/04/ever-controversial-and-sometimes-annoying-code-reviews/#comments Sun, 04 May 2008 20:32:52 +0000 Administrator http://anirudhvyas.com/root/2008/05/04/ever-controversial-and-sometimes-annoying-code-reviews/ A long haul in posts (at least by my standards) was basically due to combination of work schedule, “other things” (don’t ask ). For past couple of weeks I have had my code reviewed by some people, which interestingly evoked emotional response in me to write this post. I have been around long enough (hopefully ) to know what code reviews can do to a developer whose code is being reviewed. More often than not, it turns out that code reviews are a one-on-one sparing match between reviewer and the developer him/herself.

Keeping in my traditional approach, lets define what a code review is, (taken from Wikipedia off course):

Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

Types of Code reviews :

1. Fagan Inspections:

   This was more or less formalized by Michael Fagan. The essence of Fagan inspections lies in comparing output of minuscule operation to the so called “exit-criteria” already defined or comparing with output requirements as defined earlier in requirement gathering process. This kind of review makes a lot of sense in keeping the code on track for the end result software product. More often than not, in their ever increasing quest for developing “cool” software developers tend to overlook requirements specifications. The idea is to verify (at each step in an iteration) functional aspects of what is being developed, assigned to individual developers. For example if Sam is working on “search” aspect of the system (I am using Non Programming language on purpose), Is he following what is “required” ?, Is the requirement being “met” by what he has written? … by asking those kinds of questions and validating the code; the end product becomes bug resistant (It obviously can never be Bug free ). The important piece of the puzzle is to do this in smaller iterations and not at the end of development iteration, where developer has worked on a size able block of code already. If the code written is working and is meeting the functional requirements, it seems that fagan inspections would pass through. In “real” world this is off course only one side of the story. More often than not the requirements are not the ONLY factor in doing inspections; sometimes inspections can yield a “possible” crack through in the code which off course leads to more rework. A typical Inspection process involves Planning —> Overview —> Preparation —> Inspection —> Rework —> Follow up.

2. Informal / Traditional Code reviews :

   Developers meet one on one, and sit down side by side, to inspect each line of code, and review happens by asking questions; like “Why is this being done in this way and not “that” way? … Often these kinds of reviews evoke emotional responses from both the developers involved. ( for more read this great article : Code Reviews without much pain!). In most cases developers involved are emotionally involved with the code that they write, hence it becomes very important to criticize their code very carefully and not to go overboard about the cynicism. As you would read in the link, More often a senior developer will be reviewing a junior developer’s code, if that is the case, it is of paramount importance that senior developer shoulder’s the responsibility of reviewing code in a “constructive” manner drawing a line between what is “required”, what is “right” way, what is officially “correct” way of doing things. In many cases, (as I have seen in the past and seeing now) developers will often be asked to rework their stuff for the sake of being “consistent”. Understandably that makes the code more readable and maintainable, but more often developers will be reluctant to refactor their code to more OO unless it is absolutely necessary, therefore when i say “Careful” i really mean careful in the sense that review should not hinder the overall project time lines. It is very easy to sit there and be an architect stating what could have been done in a better way, than actually refactoring it (by refactoring I meant making it Object oriented yet not breaking functional aspects of the system). Utmost care has to be taken to pass on judgments on what others are writing or doing. In XP world, code reviews form an essential aspect for each iterations to allow a healthy product to move forward. Under pressure deadlines, it is very important to have a few quick sessions (without laying out all the things that “You” want as opposed to what “ALL” people would agree upon) in which decisions are taken about what is acceptable and what is not. It is VERY VERY important that decision is made by keeping at least 80% of the team happy. This I am speaking from experience; Before my current project, the place where i worked at, code reviews were done at a very late stage, there was an excel sheet that was sent out to the entire team to make changes at Class level. (stating Line Number, methods where the problem is). This is obviously not a good approach, since it can be very annoying for developers who will have to refactor their code at such a late stage in the game, when “functional” aspects are already covered.

Needless to say, code reviews form an important aspect in software development. In doing code reviews aside from emotional aspects, utmost care has to be taken to avoid being “obsessive” about style of the code. You can enforce a formatting standard by using common XML or something similar ( depends on platform, I am speaking from Eclipse /IDEA/ Rational Application Developer perspective off course), but that should be the end of it. I have seen this happen in many code reviews where some people prefer somethings written in some ways , for example I usually prefer my If-ELSE constructs leave a line in between (I took this approach from someone just a year back, because that made my own code readable); Now this still adheres to the coding standards / format of the common formatting XML, but reviewers who have their own style of writing the code will often want to enforce that style in the code that they are reviewing. This is obviously a nuisance in the code review process. As i said earlier, utmost care has to be taken to draw a line as where you would want to stop and look at what would be advantages of doing things in such a way. In my experience, If a developer writes code in a certain way, but is a stickler for certain types of constructs (still adhering to a common formatting standard), he/she should be allowed to be at that. Enforcing things that “YOU” as a developer want can prove to be decisively spoiling relationships in team dynamics. (I have had this kind of experience in almost every project now, where a senior developer wants code to look in a certain way and then he goes over board in enforcing it.).

Code inspection and reviews can be enforced with some of Version Control systems. Especially with products like “All Fusion Harvest Change Manager” (now it is renamed to something else), where packages are assigned to be promoted to other stages in a project (for example DEVELOPMENT —> QA / TEST stage) only when they have passed code reviews assigned by developers. Again, developers developing the code might want to check in their code and test it out on the live server without wasting their time waiting on code reviews (if the reviewer is not available), in such cases , they would still be able to do so with systems like Harvest. In my experience and opinion version control system should be used for checking in “functional” code until you reach a logical point where things are working. A non working code or breaking code checked in can be hazardous to the team. In projects where maven is used, Test First (TDD) approach can be very annoying. especially when developers write test cases which off course are broken because the functional pieces for which tests were written are not in working condition. So a simple mvn clean install (used for building projects, more on Maven later). would not work for the entire team, because test cases are executed and they would be fail, off course one can skip the tests altogether but still. In this respect, a checked in functional piece, however small it might be, can be guaranteed to work since it passes the test. In such cases a code review for such piece of code becomes irrelevant, unless off course as i said in my previous passages people want to play one-on-one tag matches with each other.

Teams working on projects with stringent deadlines often tend to overlook importance of code reviews. Code reviews can go a long way in eliminating certain kinds of errors / bugs and make code look more consistent and maintainable, provided off course a well thought off plan is executed. Cynics have often pointed out to me that in XP world, code reviews are not needed at all, since doing pair programming can eliminate the need for that. True only for 1% times in my opinion. I am not a pair programming basher, but i do feel sometimes that senior developers will often do almost most of the coding or thinking part, which means that junior developers will not think or grow while writing their code. Constructive pair programming means listening to others and pointing juniors out in right direction … This off course is too generic or subjective and almost always doesn’t work. In my experience, pair programming will only help those developers who are “just starting out”, for people who have been working for sometime, if and when paired with people who have been in the business for years can be disastrous. Disastrous in the sense that it can often create friction between two passionate programmers who know their stuff and turn pair programming into knowledge matches; this is obviously not good for the team and for the future efforts.

All in all code reviews form crux of every organization, they help in fixing issues that might arise in maintenance phase which off course are costlier and time consuming to fix than in development phase itself. Beyond not meeting functional requirements, code reviews can help in finding out potential performance bottle necks as well.

]]> http://anirudhvyas.com/root/2008/05/04/ever-controversial-and-sometimes-annoying-code-reviews/feed/ 0