All posts by Wandering Mind

IoC vs. DI

1 Comment

How do you exactly define IoC (Inversion of Control) vis a vis DI (Dependency Injection)?

Well, as my first attempt at defining IoC and DI, I made the following statement.

IoC is the concept and DI is the way of implementing that. Pretty neat, huh? But how do I go explaining this to anybody in greater depth?

Now, it seems I do have an answer, according to the book Spring In Action:

“IoC aims to offer a simpler mechanism for provisioning component dependencies (often referred to as an object’s collaborators) and managing these dependencies throughout their lifecycles.”

It further states that “IoC can be decomposed into two subtypes: Dependency Injection and Dependency Lookup.”

Now drilling down further, DL (Dependency Lookup) allows acquisition of a reference to a dependency, whereas in DI, the IoC container itself is injecting or providing those dependencies. One can draw an inference that the former scenario is allowing you to control how and when to acquire the dependency and in the second case the container is having the control over the dependency lifecycle.

So, the statement I made above is validated upto a certain extent.

Any further thoughts/comments on this would be certainly welcome.

Some Maven gyaan

Maven is a project management and comprehension tool and as such provides a way to help with managing:
• Builds
• Documentation
• Reporting
• Dependencies
• SCMs
• Releases
• Distribution
Buzzwords
1) POM (Project Object Model) – The POM is the basic unit of work in Maven. POM essentials:
• project This is the top-level element in all Maven pom.xml files.
• modelVersion This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model. By default, the model version is set to 4.0.0.
• groupId This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plug-ins.
• artifactId This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form –. (for example, myapp-1.0.jar).
• packaging This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). This not only means if the artifact produced is JAR, WAR, or EAR but can also indicate a specific lifecycle to use as part of the build process. The default value for the packaging element is JAR so you do not have to specify this for most projects.
• version This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide.
• name This element indicates the display name used for the project. This is often used in Maven’s generated documentation.
• url This element indicates where the project’s site can be found. This is often used in Maven’s generated documentation.
• description This element provides a basic description of your project. This is often used in Maven’s generated documentation.
More information about POM files can be found in POM reference and POM Introduction.
2) Archetype – Archetype is a Maven project templating toolkit. It provides a standard way to enable creation of sample projects which can be used as a starting point.

• To create a maven project based on archetype, you need to give the following command:
mvn archetype:generate

• Following archetypes are provided by maven:

Archetype ArtifactIds Description
maven-archetype-archetype An archetype which contains a sample archetype.
maven-archetype-j2ee-simple An archetype which contains a simplifed sample J2EE application.
maven-archetype-mojo An archetype which contains a sample a sample Maven plugin.
maven-archetype-plugin An archetype which contains a sample Maven plugin.
maven-archetype-plugin-site An archetype which contains a sample Maven plugin site.
maven-archetype-portlet An archetype which contains a sample JSR-268 Portlet.
maven-archetype-quickstart An archetype which contains a sample Maven project.
maven-archetype-simple An archetype which contains a simple Maven project.
maven-archetype-site An archetype which contains a sample Maven site which demonstrates some of the supported document types like APT, XDoc, and FML and demonstrates how to i18n your site.
maven-archetype-site-simple An archetype which contains a sample Maven site.
maven-archetype-webapp An archetype which contains a sample Maven Webapp project.

• Archetypes are packaged up in a JAR and they consist of the archetype metadata which describes the contents of archetype and a set of velocity templates which make up the prototype project. Archetype contents are as follows:
a) an archetype descriptor (archetype.xml in directory: src/main/resources/META-INF/maven/). It lists all the files that will be contained in the archetype and categorizes them so they can be processed correctly by the archetype generation mechanism.
b) the prototype files that are copied by the archetype plugin (directory: src/main/resources/archetype-resources/)
c) the prototype pom (pom.xml in: src/main/resources/archetype-resources)
d) a pom for the archetype (pom.xml in the archetype’s root directory).
See guide for creating archetype descriptors here for more information.
3) Build Lifecycle & Build Phases – Maven is based on concept of build lifecycle. This allows one to have a clearly defined process for building and distributing a particular artifact.

• There are three build lifecycles- default, clean and site. Default lifecycle is for handling project deployment, clean handles project cleanup and site handles the creation of project’s site documentation.
• Each of these lifecycles is made up of build phases. The build phase represents a stage in the lifecycle. eg. the default lifecycle is made up of following phases:

a) validate – validate the project is correct and all necessary information is available
b) compile – compile the source code of the project
c) test – test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
d) package – take the compiled code and package it in its distributable format, such as a JAR.
e) integration-test – process and deploy the package if necessary into an environment where integration tests can be run
f) verify – run any checks to verify the package is valid and meets quality criteria
g) install – install the package into the local repository, for use as a dependency in other projects locally
h) deploy – done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These phases (and other phases in clean and site phases) would be run sequentially. For example, if the following maven command is issued:
mvn compile
maven would do every build phase prior to compile before compile it (namely validate).
• A build phase is further made up of goals. Even though it may be responsible for a specific step in the build lifecycle, the manner in which it carries those responsibilities varies. This is achieved by declaring the goals bound to these build phases. A goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.

Introductory AOP (Aspect Oriented Programming)

11 Comments

I wrote this piece as part of my work….

Aspect Oriented Programming is one of the programming paradigms where secondary or supporting functions are separated from the main business logic. The major objective is to increase the modularity by separating the secondary functionalities as crosscutting concerns. The main driving force behind the AOP was Gregor Kiczales, who worked on AOP at Xerox Palo Alto Research Center (PARC) and developed AspectJ which is one of the most popular AOP packages available today.
Basic Concepts
The basic concepts involved in Aspect Oriented Programming are:
1) Cross Cutting Concern: This refers to the secondary functionality which needs to be separated from the main business logic. For example, logging needs to be performed by classes in our data access layer and also by classes within our UI layer. Even though the major functionality of classes in UI and data access layer is separate but the secondary concern (i.e. logging) is common to both. So, in this case logging functionality forms a cross-cutting concern (term cross-cutting is used as the functionality needs to be implemented in such a way that it cuts across the main functionality).
2) Advice: The additional code that needs to be implemented whenever a cross cutting concern is involved. For example, this can be the logging code which needs to be implemented.
3) Pointcut: The point of execution in the application where cross cutting concern needs to be applied. For example, pointcut is reached when we need to log information before entering a method and we need to log information after exiting out of method.
4) Aspect: Aspect is simply a combination of the pointcut and advice. So, if we continue with our logging example, then logging aspect involves the advice (logging code to be implemented) and pointcut (point where we need to execute our advice).
Support for AOP
AOP is supported by variety of frameworks, platforms and languages. As of now, nearly every major J2EE platform (JBOSS, Spring, Weblogic, Websphere) is supporting AOP. AspectJ and AspectWerkz are two most popular packages available for AOP for use with Java. Moving apart from Java/J2EE world, AOP is also supported by .NET framework (both C# and VB.NET), C, C++, Perl, Python etc.
Implementation
AOP can be implemented via a process called weaving, which involves the use of an aspect weaver reading the aspect oriented code and weaving it (or simply put as generating) appropriate object-oriented code with all the aspects integrated. The weaving methodology is language independent and the only factors which govern the choice of weaving are 1) implementation and 2) ease of deployment. Weaving process can be done in two ways:
1) Source-level weaving: Source level weaving can be implemented using preprocessors having access to modify source code files. For example, in case of Java programming language, source level weaving can be performed via bytecode weavers which can work directly on compiled .class files. Bytecode weavers can work during codebuild, or during class loading. However, this approach causes problems as some of the third party decompilers or debuggers are unable to process the woven code as they understand the code generated by Java compiler rather than the one generated by the aspect weaver. AspectJ uses source-level weaving to generated aspect oriented code.
2) Deploy-time weaving: In order to avoid the problem associated with source-level weaving, deploy-time weaving use post processing whereby instead of modifying the existing code, we subclass existing classes and any modification is carried out via method overriding. The existing code thus remains untouched. This approach is commonly implemented in Java EE application servers, such as Websphere by IBM.
Problems with AOP
The use of AOP involves proper understanding of crosscutting concerns which sometimes can be a difficult task involving clear knowledge of static as well as dynamic flow of a program. If a developer commits any logical error while implementing crosscutting, the effect may be widespread. Also, if joinpoints are modified again it might lead to breakdown across the application.

Spring Integration: Basic Fundamentals

6 Comments

Looking into spring integration for quite a while now.

Spring Integration is a project of SpringSource(duh). The major aim of Spring Integration is to apply the Spring’s core programming model (IoC et.al) into the messaging domain.

The main components of Spring Integration are:

1) Message: It is a generic wrapper for any Java object combined with the metadata to be used by the framework to handle that object. The message is further consisting of header and payload. Payload can be of any type(basically a Java object) and header is for holding the information required for the message to be processed.

2) Message Channel: Message Channel forms the mode of communication between the message producer and consumer. It decouples the message production logic from the message consuming logic. The key point to be noted is that the message channel supports both Point-to-Point and Publish-Subscribe models (for the uninitiated, Point-to-Point model basically means a message has only one consumer processing it even though other consumers might also exist for the same message and Publish-subscribe model basically means a message has multiple consumers processing it simultaneously. To summarize, Point-to-point is unicasting the message whereas Publish-subscribe is broadcasting it). Another important point to be noted here is that while these two models describe how many consumers would ultimately process the message, Spring Integration also allows you whether to have message channel to buffer messages or not. This is important in the scenarios where it might be prudent not to overload the consumer with the messages.

3) Message Endpoint: Message endpoint connects the message and the application code in a non invasive manner. In other words, application code and message need not know the implementation details of each other.

2 CAME, PIZZA HUT SAW, GANG-STIR CONQUERED

Well, the title might sound a bit off track, there’s some story behind it. As all “Gang-Stirs” following this blog have read RK’s earlier post Somethings cooking! (stir-ring) me and RK met at Pizza Hut @ CP today (that explains 2 CAME, PIZZA HUT SAW part) and had a meeting of sorts (that explains GANG-STIR CONQUERED part). Without much further ado, I hereby put the minutes of the meeting (or discussion whatever one would love to call it):

Three broad points were on our agenda as outlined below:

  1. WHAT DO WE HAVE TO DO?

One of the important points is what are we going to do as a team if we become one. The discussion was centered around:

  • Get or identify guys from varied backgrounds and technologies together. Already few “Gang-Stirs” have been identified for ownership of various tracks:
      • Mobile: GG
      • JAVA (ranging from middleware to front-end): JC/RK/NA/HKA
      • Rails: SD
      • Database/Backend: AP

 

  • Find/search for ideas that click. You can think about anything under the sun, but the implementation of the same should be possible for you and other “Gang-Stirs” to implement.
  • A website has to be put up containing a small description of our work/ideas. RK is driving this effort and will update once done.
  • Search for a hosting solution that supports JAVA/J2EE and we badly need this to be in place to proceed further.
  • Ruby hosting solution has been found. Check out justhost.com for more info.
  • Finally, need UI experts to design nice layouts for our ideas. I know most of “Gang-Stirs” (if not all) struggle at it.
  • R&D was also discussed, but it’s more of an individual rather than collective effort.

2. WHAT WE HAVE BEEN THINKING OF DOING?

The second which we discussed about. Few ideas which came out:

  • BIKE-ASSIST: Kind of a GPS/navigation system which would assist bikers/motorists find next option in case of breakdown. For starters, might be implemented on mobile/web platform. More info would be available once we actually start on this.
  • A RUBY PROJECT: Something similar to National UID started by Govt. of India under Mr. Nilekani. But the difference would be the identity of the person would not be based on data like ration card or gas connection etc. rather it would be on his own individual identity. SD can work on this.
  • E-Commerce Engine: I have been thinking about this for long, but it involves lots of effort and R&D from initial plan to final product. Hopefully, would start on this and come up with more details.
  • Work on improving and contributing to open-source projects under Apache preferably. This can vary from developing eclipse plugins to working on actual source code. Apache Maven has been identified for starters to work on the same.

3. THE PREREQUISITES BEFORE WE START WORKING

I think this is the most important part one needs to focus on before doing actual work. Few prerequisites have been identified for starters:

  • Complete ownership of the identified track is a must. Apart from doing the actual coding this would include mentoring the new guys, taking additional roles/responsibilites etc.
  • Each track would be responsible for their deliverable. By deliverable we mean a final product which we just need to deploy or copy and it would work without much additional rework. Apart from the deliverable, each track should have an extensive documentation on wiki or any documentation platform explaining features/known issues or bugs related to their respective deliverable.
  • Most importantly, need to stick to best practices and standards while going about our job/passion.

Well, that’s the whole summary of our discussions. Please feel free to comment and suggest further so that we might have a better perspective while going about our passion.

Apache Maven-A review

What is it?

Simply put, I would say its sort of build tool, similar to another Apache project Ant. The Apache page for maven here gives a more detailed description:

” Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information.”