Java EE Architecture

DZone 's Guide to

Java EE Architecture

Learn about enterprise Java in this historical review of Java EE progress throughout the years. It is an introduction from the book on Java EE Architecture.

· Java Zone ·
Free Resource

This article is brief historical review of Java EE progress throughout the years. It is an introduction  from the book on Java EE Architecture.

Years ago, when I started my first IT job, both Java and I were young and immature. I was a senior at the University of Wisconsin hacking C++ and MFC at night in a quest of finishing my CS degree. By day, I was pioneering Java at a large US based IT financial firm which paid for my college. Sun and Microsoft battled Java in Courts. JBuilder and Visual J++ ruled the IDE world. Eclipse Foundation didn't even exist yet, having emerged several years later. Logging was insanely painful with System.out. There were no generics. In absence of JSR-175 (annotations) syntatic source metadata was limited to a few custom compilers. ORM was every JDBC developer's dream who knew they needed some sort of a driver abstraction layer but didn't quite know what. I remember hibernating at night after 12 hours of coding trying to digest in a deep sleep those countless:

try { // to run a sql query
catch { // any exceptions
finally { connection.close(); }

On that note, the DAO pattern was a noble idea that if properly employed, got you a well deserved promotion. Servlets were a great improvement over the CGI1, while a concept of a web framework was only as real as a home grown solution; and, the EJBs were a fast growing beast, heavier than a King Kong.

As for me, I had a dream of becoming a Java Solutions Architect... Learning the Java language and the J2EE ecosystem, even though a slow process, proved far easier than mastering skills needed to properly architect a complete Java solution. It took years of coding, designing, spec writing, performance testing, user interviews, meetings, and even social gatherings to truly get a grip on system architecture. The best I can put it, is this: 

Every architect should be able to perform a developer's job if need be, but the reverse is not necessarily true.

Seems obvious, but you would be amazed how many architects - literally, persons holding such title I've met in the corporate environment; could not implement a Java subsystem when a project was short on developers and required extra brains to speed up the coding process. Note that in other industries this rule does not have to hold. In construction, for instance, an architect, construction worker or a developer do not need to know each other's jobs in detail. In the software business, an architect absolutely must have a prior developer experience. Yes, in the old days enterprise Java was awfully painful, take the EJBs (1 & 2) for instance. I've seen many teams literally split into groups specializing in one J2EE subsystem, but doing it well. There was an MVC team split between UI and Servlet guys. There was an EJB team split into subgroups of its own. I've even seen a dedicated DAO team! With Java having matured over the years, today such team division is not necessary. However, a modern architect should be an all around developer able to deliver a complete solution, from scratch, all by him or herself if need be.

Today's JVMs are faster than anything back in the day, comparable with traditional speed kings such as C/C++, thanks to JIT2, advanced GC3 algorithms, and other optimizations. Annotations and bytecode enhancers4 brought us frameworks and libraries that seem to do magic. Design patterns5 are all around us, and if you can't apply most popular ones you're not even gonna be taken seriously as a developer, much less an architect. Dependency injection is probably the most prevalent one, and boy, has it become elegant. A simple yet gorgeous:

@Inject private MyResource whatever;

You have at your fingertips what in the past required cumbersome XML plumbing code. Of course, depending on the framework, container or specification, the DI6 annotation mechanism varies slightly. In Tapestry IOC for instance, injections are done with @Inject, @InjectPage or @InjectService. Guice does it with @Inject, while the EJB spec gives you the @EJB. So long as we're on a dependency subject, let's not forget the infamous JAR dependency hell horror stories which used to be every developer's deployment nightmare. Then, Maven came like Santa out of a chimney and took the issue by storm reducing it into a relic of the past. Today Maven is a key tool in every developer's arsenal, and a cant-live-without plugin in modern IDEs such as Eclipse or Netbeans. Convention over configuration made coding safer, faster and more pleasant. Modern IDEs are free, powerful and stable. ORMs are here as first class citizens, free, standardized (JPA), with plenty implementations to chose from. As for the EJBs, with version 3 they've evolved lighter yet more powerful than ever before.

On the resource end, we have StackOverflow, StackExchange and other QnA sites which make it easy to search for exceptions and errors. Those tools were not as readily available back in the old days; we seem to take them for granted. Good tutorials were scarce, and while everybody was jumping on a programming bandwagon, old fashioned books were the best means to study. Yet, certain things have not changed. You cannot simply google for "how to become a Java architect" like you could search for LazyInitializationException. While the latter would yield you hundreads of results immediately hinting at the problem, the former would give you few definitions and advanced Java EE tutorials at best. The reason being, of course: 

It's impossible to quantify something like software architecture into a single tutorial which upon completion, all of a sudden would make one an architect.

I am aware this book will not make you an architect either, but it will be a resource on the subject I wish I have had when I needed it most, and one that I cannot find to this day anywhere on the Internet. 

So what does it take to be an architect in the software industry? We will explore this answer thoroughly but as we've already touched on, an architect is a special kind of a developer. An architect to software is like a poet to literature. An architect is capable of writing beautiful code complimented by even more gorgeous JavaDoc that reads like a flow of poetric masterpiece. It is a person with a vision, experience, deep understanding of the Java ecosystem, easy going personality, superb communication - both, written and oral; a motivator, team player, a visionary and a leader. Those are just a few characteristics I can come up off the top of my hat, as you will find out, there is plenty more.

enterprise-integration, java, java ee

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}