Spring: Implicit Construction Injection

Over the years, Spring has made a number of enhancements to improve the developer UX. I realize some of these can be too trivial to notice. Today, I present one available since the 4.3 release (over 2 years ago).

Lessons Learned using Togglz

Feature Toggles (a.k.a. Feature Flags) are a common way to test new features in a production environment. I started to experiment with Togglz as a OSS library to implement what I needed. For the purpose of my description, I used Spring Boot as it makes apps development simpler. Here are my findings:

Starting a Project: Data Generator

Sometimes, there is a need to generate data to test your code. While "testing in production" is a sweet spot to be, there are times when you need to "force" (stub) data that reflects certain business phenomena in production. This does not mean "chaos engineering" but rather a finite set that can be ingested into a suite of integration tests to increase confidence in code change.

Distributed Spring Integration

Recently, I was given an opportunity to code a use case that required the need to use EIP in a distributed environment. While trying to use the "Splitter" and "Aggregator" patterns, I had a chance to review the source code implementation of many of the components used to implement these using Spring Integration.

Presentation on Spring Boot

A few months ago, I was invited to speak on Spring Boot and Cloud Native. This was a good discussion. It was fun to build an app from scratch using Boot. For those interested, you can find the app in my github account:

https://github.com/albertoaflores/spring-boot-demo

Slides used for that preso can be found here:

http://www.slideshare.net/albertoaflores/spring-boot-intro

Hope some find this useful.

Spring Boot and CloudFoundry

In this post, I'll discuss my experience with Spring-Boot, how its features are making my "rapid prototyping" abilities shine (making me look good) and combined with a nice PaaS such as CloudFoundry, you can finally see how a true "agile" practice can focus on "innovation".

I added most of a sample code for this in a github repo. Feel free to use it and ping me if you need help or have questions:

https://github.com/albertoaflores/uspto-sample-app

Real PaaS: CloudFoundry

During the last few years in Software Development, I have found myself doing very repetitive tasks regarding deployment of applications. Among them, these are:

• Provisioning of Hardware (or VM)
• Install Application Runtime (Java, Rails, Node, etc)
• Deploying of Binaries (War file, Processes, etc)
• Load Balancer Configuration
• Security Configuration (SSL, Documents, etc)
• Ensure Service Connectivity to external systems (databases, enterprise logs, auditing, etc)
• Update Firewall policies and documentation.

I have scripted most of these in many ways (particularly using Bash,  Puppet, Monit, etc). Most of these are not only done by me, but also prevent me from doing actual real work (developing solutions). If you find yourself in this situation, I'd like to introduce you to CloudFoundry, a PaaS project I have been following for some time. I'll plan on adding more entries on these concepts soon so that I can try to document my learning about this great platform.

STS and XSD

It has been a while since I used SpringSource Tool Suite. This has been a terrible mistake on my side as I was forced to use other IDEs. As I was finally giving a choice to re-start using it, I came across an issue that I thought will write about. I'm sure most people already know about this: XSD (for the Spring beans) are no longer included in the distribution. This means that if you are using STS from version 2.7.0 and above, you have to include the proper jar (including the XSD inside the jar) into the classpath. I think this is a good move on SpringSource as I can see why it would make sense for the IDE to help you resolve based on your classpath (i.e. what you are building).

My thoughts on RabbitMQ

It is no mystery that I have been following the Spring Portfolio for sometime now.  As I continue to observe the business decisions they are making, its exciting to see how SpringSource is positioning itself to be a powerful player in the Enterprise Development arena.  Some months ago, SpringSource announced their acquisition of RabbitMQ and I thought I should get familiar with their choice for messaging solution.

Spring Roo: Persistence Setup

I've found Spring Roo to be a great way to learn how to setup configuration properly.  As I continue to spend time in configuring my home project, I continue to be amazed at the powerful features that Roo brings to the table. I had written a small application for tracking family chores. I spent about 25 minutes drawing the entities in a napkin, then spent 10 minutes writing a Roo script (file with extension "roo"). Then, I opened a Roo shell and run "script myscript.roo". This created my project, including all the scaffolding for my entities.  I had my project running in minutes. After a while, I detected a problem with my entities relationship and wanted to see the persisted data. Of course, I had the the "IN MEMORY" choice, which brought all sort of problems when trying to see the data within.

My Review on Spring-Roo

So I gave a presentation about Spring Roo recently. Hopefully this means I'll get a kangaroo.  I felt it went pretty well. I decided to share some of my remarks as I think I learned more by presenting than by trying it. As I can not put a presentation on my document (yet), I'll show the text of my slides and will explain some of the things I discussed while presenting.

Understading some of Roo's magic

  I must admit that I was among the many developers I know who are very skeptical about Aspect Oriented Programming (AOP).  I've written many aspects myself, some which I now define as "entry-level".  I had not seen a clear use-case for aspects other than the basic "auditing", "logging" or "security" use cases.  So, a few months ago I started to play with one of the latest tools from SpringSource, namely Spring-Roo. To my surprise, Roo was not only meeting my expectations, but also made me a believer on yet another good use case for AOP.  The use case of tooling support.  I'll try to explain some of the magic which Roo brings to software development using AspectJ.

Spring: @Autowired Constructors

Since the introduction of Spring 2.0, I have seen a trend where developers use the @Autowired annotation very often. I must admit, I like a combination of annotations with some XML declaration, however I'm still debating whether making a decision of using @Autowired scales well in the long run. I would like to show how this feature can seem unintuitive.  Furthermore, even tools like SpringSource Tool Suite can get confused at times.

Spring 3.0 and <mvc:annotation-driven />

I have used Struts1 and Struts2 extensively for years.  With that background, I can appreciate some of the things that Spring-MVC brings to the table such as Dependency Injection, clean integration with Bean Validator (JSR-303), smooth Integration with different View Technologies, among others. Furthermore,  Spring-MVC has been making improvements through out each release that has made it a more robust framework, including the latest REST support. Like every framework, there is always a "gotcha" in a feature and such is the case for <mvc:annotation-driven />.

<mvc:annotation-driven /> is a nice feature, however depending on how you are used to organize your Spring-MVC files, it can prove to be confusing. I'll try to explain my findings as clear as I can.

Tiles2 with Spring without Spring MVC

In the process of making my application OSGI enabled, I came to the conclusion that it would help me better to have Tiles2 to be managed by Spring. This is so as to have more control of the Tiles2 configuration instead of the configuration needed in web.xml. This is when I found the TilesConfigurer class from Spring. Here is a snippet of for my configuration.

Generics and DAOs

Since the coming of Hibernate 3, I have started to refactor a lot of code that I simply didn't need anymore. Among these, my data access objects have always seemed repetitive. Repetition (in my opinion) calls for code refactoring. The hibernate tools project aims at fixing this problem by providing a "Dao Code Generator" which can certainly help. Additionally, other tools out there offer similar solutions, however one must understand how much the JVM will have to use in working with our "dao-centric" application. Can we do better?

With the introduction of Generics in Java 5, I found a good way to make good use of this generic approach to DAO's without breaking my application logic. Consider the following code:

Learning about AOP

I was told that once I start writing code in AspectJ and learn in depth Aspect Oriented Programming (AOP), it will be difficult to look at Java source code again in the same way as before. And now, the more I get into it, the more I realize how important it is to have this knowledge as part of your skill set. Until now, I had heard a lot about AOP and, just as anyone else who has used the Spring Framework, I thought I knew all I would ever need from AOP. Then, I was presented with a challenge where Spring support was not enough so I was faced with the opportunity to learn AspectJ's language constructs to address my client's concerns. I was very impressed with the things I was able to accomplish with this extension to the language and in general I highly recommend everyone to take the time to learn it and use it often.

One of biggest goals and hopes of every Software Architect is to design and lead a software development effort that can scale well. This means that maintenance should be more than technically feasible, but rather simple enough within budget. Experience proves that despite every effort of preparing for every change, it is difficult to address every potential concern that will rise in the future. Specifically, when these concerns appears spread out through the code base. This separation of concerns is what is referred to as "cross cutting concerns". AOP provides an API that allows you to write code to address these "concerns" in a desirable manner.

Aspect Oriented Programming (AOP)

Cross cutting concerns are address by way of, what is referred to as, "Aspects". Just as much as an Object models an Entity, an Aspect models a "Cross Cutting Concern". Getting familiar with these concepts takes some time, however as you take the time to write your own Aspects, it will become very easy to follow.

Every Aspect contains an entry point, a Pointcut. This basically describes how is the crossing concern identified. For example, the concern may be "all Constructors calls (from a specified package) must passed through an Authentication process prior to instantiation". So, the Pointcut will be all "calls to the Constructor within the package in question". This Pointcut description, interestingly enough, is one of the reasons where Spring AOP couldn't help me (Spring can not manage objects that are created somewhere else - e.g. Hibernate's Proxy objects). These Pointcuts delegate processing to a handler called Advise which is where most of the logic occurs. An Advise reflects the concern that is trying to be addressed. Continuing with our previous example, the Advise will be "before calling the constructor call check authenticating roles else throw an exception". Additionally, an Aspect may have multiple Pointcuts and each Pointcut will have a minimum of one Advise.

AspectJ

In the Java Programming language, AspectJ provides the ability to use these concepts in terms of objects. In general, AspectJ is an extension to the language. Originally developed by Xerox-PARC, it is now maintained by the Eclipse Foundation. The following code in AspectJ reflects the sample we have discussed thus far (for an object class name Foo):

public aspect AuthenticatedConstructorAspect {

pointcut constructorCheck() : call(* *.Foo());

before() : constructorCheck() {
// Do some coding (e.g. throw an Exception, etc)
}

}

Conclusion
In general, aspect oriented programming provides a great strength to your development efforts if used appropriately. It can become a strong part of your development efforts if used properly and can scale well since it can be plugged in as a requirement is enforced.

References

1. http://www.ubookcase.com/book/Addison.Wesley/Eclipse.AspectJ/
2. http://www.sable.mcgill.ca/~hendren/AspectJ.html
3. http://www.stepwise.com/Articles/AspectJ/index.html
4. http://www.eclipse.org/aspectj/doc/released/progguide/language-joinPoints.html
5. http://www.javaworld.com/javaworld/jw-04-2002/jw-0412-aspect3.html

Rethinking the Enterprise

Some years ago, I took a "Data Structures" class in college where I felt I received more than what I had signed up for. During my lectures, my professor challenged us to think outside the box constantly. On one occasion, a midterm exam was promising to be hard for the whole class. I was particularly puzzled with a bonus question (worth a lot more than the usual). Although I felt prepared for the exam, I was somewhat troubled, even upset at the question. If I recall correctly, the question was something like:

(x-99)(x-98)(x-97)... (x-2)(x-1)

And we were asked to calculate the product when "X" was 15. This puzzled me for a second since my first reaction was "why do I need to solve this in a Data Structures exam?". To my despair, I made the decision that I would spend 1 minute in trying to solve this question, since these midterms were known for being extremely long and difficult to finish. A few days later, during our next lecture, one of my classmates took the courage to ask the reasoning behind these "absurd" question. Our professor kindly explained that such question was to help us understand a principle that we had to remember if we were to succeed as Engineers. Thinking outside the box is not as simple as you may think and often times it requires a great determination to just do simple things. Although the answer may be simple, too much knowledge can lead us to add complexity to a simple problem, thus our skills are poorly used. By the way, the answer to question above mentioned was zero (if your need a detail explanation, please send me an email).

Simple and Plain concepts
Similarly to the incident I had in college, I attended a seminar not that long ago where the speaker spoke about this same exact principle. The approach he took was probably more eloquent than what I would like to be, but I feel he made a good point. This had to do with Enterprise Applications development. If you have noticed, the first word "Enterprise" is a simple word, yet as soon as one adds the second (Applications), a developer can start associating different technology concepts (EJB, Spring, .NET, Ruby, PHP). Normally, one is biased about a familiar technology, yet no one has even discussed anything about requirements. I met once an Engineer who had already designed (or at least he thought he had) an Application using EJBs without understanding the problem domain and/or requirements. This made me think in how we, as Engineers, are using the knowledge we have to develop simple solutions and avoid adding complexity to a business problem. I really stress this point because there seems to be an untold fear to learn/use different technologies and we seem to prefer to add more complexity over using the appropriate approach to solve a problem.

Facing our Engineering Fear
So why should you use EJBs? Do you fully understand what are the benefits of using these? Is .NET perhaps a better approach to the company's goals? Would you recommend building an application in RoR (Ruby on Rails) over J2EE (or .NET)? If not, could you number such reasoning? What is our real bias about the technology we choose to use when solving a problem?. Interestingly enough, I've found Engineers using a set of technologies that are known well, not necessarily because they are the best, but because is convenient. Engineering staff must understand the tool set available to them when solving problems, and unless required, not "re-inventing the wheel".

From the management perspective, there are very few cases when a developer may start working off a clean repository. This means that there is an existing asset to be maintained and/or extend. Management is skeptical about investing in such a change. In fact, it will take a lot of convincing to help management realize what is the really added value to a product in a potential "re-architecture" phase. Although this is understandable in most cases, an Enterprise Application can certainly benefit from a fresh new code base when situations allow them. This however should not make us believe that such architecture is the only and true way of solving every Enterprise Business need. A simple example is the case when Hibernate may not be the solution to every persistence problem. There are valid cases when JDBC is a perfect example. Or in the case of .NET, is the MS Oracle Client better than the ODP (Oracle Data Provider) for connections to an Oracle database?

The Hope of the Enterprise
To have a broader view of different technologies can certainly help us see an Enterprise Application from different perspectives. Being willing to learn new technologies can only help us and the Enterprise, but ultimately is up to us to drive the effort. So, when thinking about the Enterprise, one must think about the problem domain, and not only the tools available within our domain knowledge, but also what other alternatives available to solve the problem effectively. As scientists, we have a responsibility not only to solve technical problems, but to also use the most effective methods to do so. So read on documentations, download and test many frameworks and prepare yourself for we are the true hope of the Enterprise.