IT opportunities in the current financial crisis?

I'm not optimistic, but here is a fact: For more than 20 years (since the 1987 crash) or in some cases since the usage of computers in companies, the IT budgets of financial institutions (banks, insurance companies, stock markets etc.) ALWAYS go up.
In the meantime, technologies went from Mainframe, to Client/Server, to Web 1.0, to Web 2.0, to SOA, to Virtualization and now Cloud Computing. But in spite of all the technological advances, IT budgets ALWAYS go up. I've given consulting services to many banks and insurance companies, and one thing got increasingly clear: If you're trying to sell a software that will reduce their IT budget... Forget it!

Of course, the financial institutions' needs from IT increased in the last 20 years. They want to setup new services and products (online banking, new policies, new mortgages :) faster than their competitors. But the increase in end user demands is an order of magnitude lower than the technological advances in hardware and software. IT budgets should have gone down, and insurance premiums and bank fees also. But no - IT budgets ALWAYS go up.

I think the main reason is Wall Street. If you are Bank of America, and someone finds out you're reducing your IT budget... Your stock will go down immediately!

A month ago after 20 years of IT budget increases all the CIO and IT department in financial companies have a huge amount of cash fat.
Where the fat goes?

• Buying hard to install and unmaintainable software (you need to keep all these engineers) from BIG vendors.
• Buying low performance hardware for incredible amounts of money.
• Of course, a big team of developers and system engineers to oil down the cranky machines.

And now, for the first time all the CIOs have only one goal: Reduce your IT budget!
IT department in financial companies will never be the same!

From my knowledge, and experience with theses companies their IT budget is about 3 to 5 times bigger than it should be. I don't think they will go all the way and slash 80% of the IT department, but what's for sure, they'll slash the vendors, and contractors.

I think one big software/hardware company will suffer big time from this change because it's living and breathing of this fat. The saying was that a CIO choosing IBM will never get fired for his choice (even he wasted time and money on a failed project). Today that thinking changed.

So, where are the opportunities?
Well, now you can really sell and prove the advantages of modern technological advances to financial CIO. They will be sensitive to TCO, developer productivity, software quality and maintenance.

The issue is that no CIO will start a costly migration project now! So the current state of IT will be frozen for some time. But, some companies will really analyze what's going on and make a decision to go with open source, agile and distributed all the way.

Things will change in banks and insurance companies IT departments, let's hope WebsFear does not blackmail their customers again...

Originally posted on dzone

Web Beans and Modules!

After some good work, the JSR-299 group released an early draft, first published on Gavin King's blog, and now on the JCP site.

The spirit of Web Beans is really good, and the way the annotations came out is very promising. I have nothing to say but compliment the Component Types, Component Bindings, Scopes, Injection, and Interceptors. The Event has the good approach (Event type filter), but looks young at the moment.

Web Beans is really the state of the art "Educational Framework". The technical base is already explored (Guice, Spring, Seam) and is not so complex, but the impact on the developer thinking is really significant. Like every good "Educational Framework" (Struts, Spring, Seam), it makes it harder to do the "bad thing" (hacking, ugly coupling) than the right one (framework driven injection and loose coupling).
I know that if developers start to use these Annotations their code will get cleaner, more readable and manageable.

But, reading through the specs and especially, "4.4.2 Interceptors bindings" and "8. Packaging and configuration", I felt like something was wrong: Where are my Web Beans modules?
I don't want to get into the argument of OSGi or JSR-277, but I was expecting a more modular approach of Web Beans Injection.
What I mean, is that I would like to see a Web Beans "core" defining all the above Annotations for a pure J2SE environment. This would be the specification of how to use Dependency Injection Annotations. On top of that, another specification on how to provide "Components Provider/Injectors" for JEE, JSF, EJB, MDB and so on.
For example, I want to be able to do:

@Log
private Logger log;

just by adding log4j-web-beans.jar in my classpath. In this jar Log4J will provide the Web Beans Component for my class and my environment.
So, with this approach all the EJB, JSF & JEE stuff that really don't have to be there, can be specified separately as: jee5-web-beans.jar, ejb-web-beans.jar, mdb-web-beans.jar, etc.
I think it will make the specifications easier to read and a lot more flexible for all the great future components ;-)

Since I don't like people that complain without proposing something of their own, I tried to see how to do this with the current specification. And, basically it's not missing much.
Today in EJB3 environment, the first thing I do is creating an Interceptor that can inject components from Spring or other sources in my Session Beans. The injection is based on my project level Annotations and it bridges Spring and EJB3 nicely.
So a first solution (not good but...) is to use javax.interceptor.InvocationContext. If the Web Beans container is adding some entry in getContextData(), I can find out the Component Type, the Scope, and other information and decide how to populate all the @Log fields.

A nicer solution will be to have Annotations specified by JSR-299, that will allow me to write something like:

@ComponentProvider
public class Jee5ComponentProvider {

    @Provides(EJB.class)
    public Object getEJB(WebBeansContext wbc) {
        try {
            return new InitialContext().lookup(
                wbc.getDestinationField().getType().getName());
        } catch (NamingException e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }
}

Here I really did not investigate enough, but I know I'm missing @ComponentProvider and WebBeansContext in the current specification.
What do you think?

Annotation Injection Architecture

From AADA to AIA
Anyway Uri Boness has a point here, and AADA was answering it.
My first work on AADA worked around using APT, or pure AOP framework like AspectJ and AspectWerkz. My issue with these solutions were that the tools were way overkill for a simple thing like Annotation Injection. I just wanted something that is dynamically (or more exactly rule based) injecting annotations based on my business annotations.
So, what I needed is to activate some kind of rules when any framework (Hibernate, XFire, EJB3 container, Marshaller, ...) were calling the methods of java.lang.reflect.AnnotatedElement
It was the time of Java getting open source by Sun, so I thought about giving a shot on how it can be done, but dropped it by laziness...

Back on track
Now with Java 7 and the great features for framework like Hibernate:

• erasing the erasure or reify generics
• methods and function pointers
• binding

I think it's time for a new adventure toward Annotation Injection.

How can you make your classes, YOUR classes!

Answer to 'Dude, where’s my class?'
After writing AADA, and starting some applications in some projects, I encountered this blog entry from Uri Boness Dev Thoughts » Blog Archive » Dude, where’s my class?
Here was my answer:
So I read a lot of your Dev Thougths and I'm surprisingly impressed. The subjects are right on today's Java critical issues and your analysis is open minded and fun to read.
But, after a lot of thoughts, I disagree about your bottom line on Annotations vs. XML and JBoss MC vs. Spring.

Spring
Spring is what I call an “Educational Framework”. People ask about Spring: “What does it do?”. Answer: Well, in fact, basically, heuh... instantiating Java classes from names written in an XML file...
WOW, that's a hell of a framework!
You can argue about the answer, but the point is: I like Spring not because of what it does, but because of what it makes me do.
I mean that Spring is educating Java developers to organized their classes and interfaces. It cleans my code from spaghetti plate dependencies, it enables me to play like Lego with my implementations, and gives high level of control of where a specific code should be.
From my experience, the first framework that had this effect was Struts. Before Struts, the amount of very ugly code in Web Application was amazing. But, when I arrive to customers using Struts I'm sure of 2 things:
They will have extended and overridden most of the basic classes of Struts (Action Servlet, Request Processor, Action, ...), reducing to a very thin amount what they actually used from Struts;
They will have some kind of MVC separation in their code.
For more than 3 years now, it proves to be faster and more efficient to write your own small MVC web framework than to use Struts. The main benefit of Struts was that it educated a lot of Java Web users on how to organized their code and architecture.

Today, Spring is on a lot better ground than Struts for one main reason: It was meant and build to be discreet: “Don't pollute my POJO”?
Now, having a good ground like the Spring framework, enables Spring to build additional framework pieces like WebFlow, Swing, Web, Transaction, Remoting, Validation and so on. But here, there is a danger:

• Should I start using Spring for what it does?
• And if I want WebWork?
• And if I want JBoss Remoting?
• And if I want Hibernate Validation?
• And so on...

I know the answers to the questions above but it's not clear anymore for a lot of people.
So, for me, some of these additions are not Spring Framework anymore.
Don't misunderstand me, I really like the Spring classes interfacing Hibernate, JTA, JDBC, the exception handling (Rod Johnson view of no more checked exception is brilliant), and they should be part of the basic Spring Framework.
But, for example:
Spring Web is great but should not be in Spring Framework,
Transaction declarations are perfect, but I saw too many high-end deployment relying solely on Tomcat + Spring Transaction crashing in production.

For me the basic Spring Framework should only be a good Micro Container with interfaces, and it should be clear that it doesn't replace real container services. Adding too much to Spring Framework will kill the motto of Spring: “Spring should not compete with good existing solutions”.

JBoss MC
The amount of code for a basic MC is relatively small (instantiating classes from names) and JBoss cannot build their platform on top of Spring! They need to offer full support on this.
So, they did it again. It's logical, it's good, and let's see other solutions. JBoss MC has completely different constraints and requirements than Spring. They will, can and should provide technical features that competes with other solutions.
JBoss led the POJO concept against the big guys (IBM, BEA, Oracle, ...), and it's not because they won (AS leaders) that the community should stop the support.
The bad guy is IBM WAS, not JBoss. I had the misfortune to look at some WAS Java code, and this is way more pathetic than JBoss MC. Those guys really completely missed the concept of MC and well organize Java code. I will jump with joy when Geronimo and JBoss will throw this ersatz of AS to history...

Annotations vs. XML
I'm thinking about this “Dude, where is my class?” issue for quite some time now (see AADA), and like you did, I went back and forth between XML and Annotations for managing metadata/configuration.

Today I'm sure of what I want: Annotations.
And this is for one simple reason: The XML way is at a dead end.

Everything was already done (and Spring the first) to maximize the capabilities of XML driven configuration/metadata, and it's still not good enough.
On the other hand, we just started with annotations and its teaming with ideas, feature requests, improvements and so on. “.NET” and then Java 5, just open a huge amount of opportunities on how to design and write applications and technical infrastructures.
In all projects using Java 5, it starts with puzzled developer faces but after a while, I'm always amazed by the ideas and implementations coming out of annotation usages. Once the developers gets it, amazing improvements goes on and on. This does not happens with XML.
We are just starting to play with this stuff. And, like you point out in “Java Annotations - We’re not quite there yet!”, Sun needs to add a lot more to Annotation in the language itself.
And here is my big disagreement with your view: Let's not throw Annotations away because of Sun short views. Let's push it forward. Let's keep asking for all the improvements we want, and may be, one day, Sun will give up under the pressure and make Java open source... (Wishful thinking isn't it?).

About the discussion around the “@injected” annotation (Bob vs. Spring). I don't understand the dilemma here. I'm an application developer and I need something that is not under my control (from the infrastructure or from another module/project/application). In Spring XML way, I need to declare injection in a shared XML file with configuration that I don't even understand.
Isn't it simpler just to write “@injected AnotherInterface myMember;” and expect the system to provide it, without going anywhere else than my class.
For me, “@injected” is the most understandable metadata information: This is “out-of-my-juris-dick-tion”, but I need it. Please give it to me.
In one project we refactored a huge J2SE application to be container enable. We used Spring to “Springify” the code so it will be “soft” enough to be inserted into JBoss. During this process we missed a lot the “@injected” annotation feature. The amount of repetitive XML and setter/getter was very tiring.

So, annotations are not polluting your code if you make them yours. And to link your personal annotations to infrastructure annotations is Spring (or other infrastructure) framework job.

About IDE, I'm using IntelliJ and the Spring navigation is amazing. It really gives what I need to write XML and Spring beans. But, I still prefer annotations navigation. Finding usage, controlling AOP injection, reviewing code and all other architect work is a lot easier with annotations then with any XML based system.
Lately, we refactored an application that used expression based AOP (declared in XML of course). The mental mapping (where are my pointcuts?) was giving us headache. We just wrote some well defined annotations, used them all over the code and redefined our expressions to point to them. It was an amazingly refreshing experience. We solved all the bugs related to AOP (mainly wrong cutting) and now the application developers can managed their Aspects without us.
Here also you can go on with “Is a pointcut position metadata?”. Well, I think I don't care about it. Annotations answered our need in a beautiful way, and I will stick to them.

MDA is dead, long live AADA

With recent additions of powerful language structures to the Java platform, the time is ripe for a fresh development methodology. The promise of design techniques - like Waterfall, Spiral, RUP and MDA - for an agile and efficient Object-Oriented development process is within reach.

Features like Annotations, AOP, Generics and IoC bring upon an opportunity to reevaluate our architecture design strategy. In this article I will introduce AADA (Annotations and Aspects Driven Architecture) a compelling alternative to MDA. AADA is a refactoring-oriented design methodology that effectively eliminates the need for massive code generation.

Present Shortcomings

I've been a software developer since 1992. Since then I’ve had my chances of using almost all methodologies, techniques and consequent buzzwords often mentioned in Information Technologies. Methodologies like Waterfall, Spiral, RUP, MDA, OOP techniques, UML, and other J2EE tools revolved around resolving common design problems.

I really liked MDA and used it in some projects. It proves to work only when doing a bottom-up approach. I mean that once some “kind of” framework or infrastructure was in place, you can build MDA Components that will deliver software for this infrastructure. It enables a high-level OO view of the running system. This view is not a write-only document generated in the early stages of the waterfall cycle, but a view of what is really running. With MDA you can remove the “boilerplate” code a-posteriori by defining MDA components. The problem is that defining MDA components elements (tagged value, stereotype, operations) is a difficult and non-trivial work that is hardly or never maintained, so MDA components proved to have a short usage time.

XP is another great improvement for developers. It focuses development teams on the needed missions, and on the needed missions only. It forces by means of refactoring to analyze and rethink all the “manual code generation” (or monkey programming) that’s been built up underway. XP avoids the trap of overshooting the design and the planned technical features. I find XP refactoring to be the best software design mechanism. What I mean is that refactoring code is actually designing software out of real raw material, like sculpting clay.

The job, simply put, is to find the best way to preserve the running system’s abilities with less amount of code. This is ultimate software productivity. It’s funny, as I was being paid to find the best way to eliminate the maximum amount of developers’ code. Without the code of a previous XP iteration though, it’s impossible to do the refactoring correctly. The argument: “Why didn’t you tell me that before I wrote all this code?” doesn’t hold. Guessing what is needed in a piece of software before writing it (sometimes referred to as Detailed Design) doesn’t make sense – it’s a waste of time. XP methodologies gave a big productivity boost to a lot of teams around the world.

So what’s new?

It seems as if very few exciting or new innovations came about since I started J2EE consulting in 1999. But today software development and consulting is becoming fun again. Nowadays, concepts like eXtreme Programming (XP), Inversion of Control (IoC) and Aspect Oriented Design (AOP) combined with features like annotations and generics (introduced with Java 5) are becoming common to current development environments.

During the last year, I realized that MDA or UML design is no longer needed. The level of expression obtained in an annotated Java class is actually better than it's PIM UML class counterpart. The mentioned advancements present the following advantages:

1. Expressiveness and Extensibility – Java annotations are more powerful than UML extensions defined in MDA (stereotypes and tagged values). Annotations are strongly typed and thus have the advantage of compile-time checks. Modern IDE’s can easily and quickly enumerate all instances of an annotation usage throughout the code, without the need for reverse engineering.
2. Strongly typed class associations – By use of generics, it’s possible to define class associations such as aggregation in a strongly typed manner.
3. Cross cutting concerns – Aspects successfully replace both MDA transformations and UML definitions of pre-conditions and post-conditions.
4. Elimination of boilerplate code – declared aspects remove the need for code generation. Although this is achieved mainly by employing aspects, strongly typed annotations greatly enhance readability.
5. Decoupling technical details from business logic – Strongly typed annotations combined with dependency injection contribute to a clean and efficient configuration setting. Str ongly typed annotations decorate strongly typed elements.
6. Traceability – One of MDA’s strong features is traceability. A good source code auditing is achieved by employing a good Source Configuration Management, as is the custom in an XP environment. Since a class is usually involved in more than one feature, associating a Version Control System commit action (of both implementation and tests classes) with an XP user story provides real traceability.

The MDA dream was to have one model generating software for multiple platforms, for example, the same PIM can generate a J2EE or .NET application. In practice achieving this goal demands building conforming infrastructures that are compliant with the same model. AADA enables to achieve real platform flexibility - in terms of multiple databases, multiple O/R mappings, multiple UIs, choice of a container (EJB or Servlets) and so on – with a main prerequisite, which is also the driving force: Java 5.

These compelling concepts are well demonstrated in specifications such as EJB 3.0 and the upcoming JEE version. These standards are likely to boost this new development technique.

AADA: The Code IS The Model
So I propose a new development technique: AADA (Annotations and Aspect Driven Architecture). This technique is to actually have full decoupling between the business classes (what used to be PIM classes in MDA) and all kind of technical considerations using Java 5 annotations and AOP. A ADA’s core is to annotate the business classes with project specific annotations that are created following the XP process of refactoring. These domain-specific annotations may potentially use EJB 3.0, Seam and AOP specific annotations.

To demonstrate the process, consider the following sequence:

Analyze the code to find patterns of annotations and aspects usage to obtain a higher level of meta-annotations. For example: “@Stateful @Name("hotelBooking") @Interceptor(SeamInterceptor.class) @Conversational(ifNotBegunOutcome="main") @LoggedIn” found in a Seam example can be replaced with “@MyCompanyConve rsation” which expresses the project’s naming convention, default values and Seam as the conversation state manager.
The basic component of AADA is the Annotation Factory Manager. In MDA a transformation has the ability to add more tagged values, stereotypes and classes based on an original PIM UML model element. This can be more clearly and easily done with a Java based annotation generator, which will contain the architectural logic and can be applied via AOP.

AADA and MDA compared
To illustrate the points made I’ll use one of the most non-trivial common examples, using the following data model:

a person has a list of addresses indexed per type and each address has a state and a country:

The first requirement for managing the above data model is that AddressType, State and Country would be “static/read only” data. This information would be used by whatever underlying framework you use (like persistence manager, data entry UI, marshaller/de-marshaller, etc.). Changing an address from Texas to California, for example, should not change the actual database entry of Texas to California (Although this might be a good idea after all).

In MDA you start by stereotyping or tagging the “static/read only” classes as “My Reference Classes”, and Person and Address as “My Business Classes”. From this simple declaration the architect can begin handling the model:

In Hibernate:

• All classes declared as “My Reference Classes” are cached read only;
• All associations to “My Reference Classes” should have outer-join=”false”;

In Data Entry UI:

• Associations to “My Reference Classes” should be combo box based;
• Changing association to “My Reference Classes” means finding the static entity California and associating it with my address;

In Marshalling:

• When serializing a Person all references to “My Reference Classes” should be passed by ID.
• De-serialization of a Person should link the Reference ID with a matching static reference data.

In an MDA environment, all these issues are managed through different MDA transformations that would generate extra classes, XML files, and so on. When these new elements are generated, reverse engineering becomes a headache.

The next XP iteration might pose a requirement to be able to reload on demand the list of Address Types available. As a developer to do that you just change the Hibernate XML mapping files (and possibly the cache definition also). By now, your MDA transformations are destroyed. From experience, MDA and XP practices don’t go very well together.

How does AADA handle this? Define 2 business annotations “@MyReferenceClasses” and “@MyBusinessClasses” and apply them to your model. Write pure clean Java classes that completely define the above model, using generics. These Annotated Java classes contain the same information (even more in fact) than the previous UML model.

For each annotation write an annotation factory that will inject by using AOP:

1. All EJB 3.0 annotations needed for the classes and their relationships
2. All Seam annotations needed for the State conversation and JSF UI definitions
3. Your specific aspects that manage these 2 annotations

The immediate benefits are evident:

• Everything is Java – No UML modeling tools are required.
• Readability - The code is properly decorated to add readability. For XP refactoring needs, being able to find all usages of annotations is very powerful and effective.
• Extensibility – Adding new features means to add specific annotations in the right places (for example @Remove or @IdleTime). If used often, these combinations of annotations can be transformed into “@MyNotSoReadOnlyReferenceClass”.
• No reverse engineering – The Code IS the Model.

All this AADA concepts are well demonstrated in the EJB 3.0 specifications and the Seam framework. To gain more flexibility, avoid using framework specific annotations (like EJB 3.0’s or Seam’s) directly in your business classes, as this could limit changes to the architecture after having developed code. For example, choosing a JNDI name by naming convention (not the default one of the Fully Qualified Name) or choosing a Conversation type from a project specific enumeration is something that a standard framework shouldn’t and doesn’t do. This means that in a generic framework like EJB 3.0 or Seam, a lot of annotation associations need to be string based. In a project specific, strings can be replaced by enumerations or a naming convention. This is not strictly an academic point, it really gives the benefit of being able to trace names and design decisions. The framework’s string based annotations may still be used, but they are easily identified for refactoring purposes of the next XP iteration.

MDA enables extending standard components (Corba, EJB etc.) with your own MDA component definitions. Using AADA you should stay clear of importing specific annotations (e.g. avoid importing javax.ejb in your business classes), but still have type safe compliance check, based on your own annotations and the injected ones. Today EJB 3.0 and Seam are the first AADA components that you can extend for the specific project needs. In fact, Seam already uses this concept of meta-annotations.

Adding new technical features or changing the architecture in AADA is XP compliant. Let's take for example an addition of a Web Service interface layer to your Seam conversation, or POJO services that use Inversion of Control in Seam. In an MDA environment the only approach that works, from my experience, is bottom-up. That means integrating a web service framework (like XFire) and at first developing all the Java code inside your actual business classes to be able to test that things work correctly. Once you’re happy with the results (which rarely happens in real life) you create an MDA transformation that represents your final goal. This takes a lot of time and energy, and the resulting transformation is very difficult to refactor.

In AADA such a change would mean adding the web service annotations to the business classes, testing the change and then adding these annotations to the Annotation Factory.
A fully XP process is ensured by allowing permanent testing and refactoring capabilities that don’t block developer decisions.

Summery
MDA focuses the architecture design efforts on an abstract model from which it’s possible to derive an implementation, but with the concurring cost of relying heavily on code generation. XP methodology advocates frequent changes and goes against excessive design. An attempt to adopt both strategies eventually exposes their mutual incompatibility. With recent additions to the development environment, these shortcomings may be efficiently resolved.

AADA introduces a fresh and convincing methodology that is compatible with principles of MDA but is not as cumbersome. AADA is refactoring-oriented and flexible enough to enable agile development cycles a-la XP.

Resources

Java

• Java Tiger, version 5 introduced very powerful constructs to the Java language including annotations and generics.
• Java 5 home: http://java.sun.com/j2se/1.5.0/index.jsp
• New features introduces in Java: http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
• Annotations are the new strongly typed declarative coding facility introduced with Java 5.
• Annotations (JSR-175) Community Process page: http://www.jcp.org/en/jsr/detail?id=175
• Generics (JSR-14) Community Process page: http://www.jcp.org/en/jsr/detail?id=14
• EJB3 is the new standard specification that would greatly simplify developing EJB’s.
• EJB3 (JSR-220) Community Process page: http://www.jcp.org/en/jsr/detail?id=220
• JBoss EJB 3.0 implementation: http://www.jboss.org/products/ejb3/overview

Methodologies

• Introduction to Model Driven Architecture (MDA): http://www-128.ibm.com/developerworks/rational/library/3100.html
• XP is a set of methodologies for an agile development process: http://www.xprogramming.com/xpmag/whatisxp.htm

Frameworks

• The Seam framework ties up the JSF framework for UI with EJB 3.0 standard as the backing model: http://www.jboss.com/products/seam
• XFire is a Java SOAP framework for an easy integration of Web Services: http://xfire.codehaus.org/