Java Server Side Development

The Server Side. Application Servers, Data access and XML

As this page delves into more advanced topics, I'll make some assumptions here that the reader is at least passingly familiar with common Java API's, frameworks and other jargon.



Working with Relational Databases

JDBC requires writing and maintaining a lot of troublesome code that maps objects in the OO Java world to table orientated structures that encompass the essence of the relational database. There are frameworks that provide support for "Object to Relational Mapping" or ORM for short. One of these is JDO, which remains ignored.

The finest ORM solution is Hibernate. Hibernate has greatly influenced the Enterprise EJB model. Consequently EJB 3 entity beans now use the persistent data model, the "Java Persistence API" (JPA). Finally there is iBATIS, which is handy for mapping Java to existing database schemas.



XML

At time of writing XML seems to be overused in Java based systems. The incompatibility between XML and Java is the root cause of XML HELL. XML Hell crops up in several forms: XML is hard for humans to read. XML is hard for machines to parse. XML is an obese monster: it's extremely expensive to feed, it chews up CPU cycles and is a voracious memory gobbler. XML is a cause of run-time errors because, unlike Java, XML message types are not intrinsically checked at compile time. When XML does go bad at runtime, (not infrequently) it oft causes long stack traces to be spewed forth that seldom provide meaningful clues as to what actually caused the fault, leading to much frustration.

XML can make refactoring error prone. IDE's do not usually model Java-XML relationships, let alone provide refactoring tools that help refactor XML. The consequence of this is that developers, especially those that collaborate in teams are often scared to refactor systems that rely heavily on XML for fear of side effects that are tricky and unpleasant to diagnose and debug. In this sense XML is an anathema to efficient agile development.

On the bright side, at least XML is an open standard of sorts, so offers useful options of interoperability between disparate systems. Sometimes XML is a necessary evil. Sometimes XML can be genuinely useful, when handled with great care.

Manifold XML frameworks are available for Java: Xerces for DOM and SAX parsing; Xalan for XSLT, FOP for document generation, especially PDF's, etc. Jakarta Commons Digester is a sophisticated XML parsing framework. Betwixt is a simple object-to-XML wrapper that uses Digester behind the scenes. Alternatively there is XMLBeans that binds XML to Java types, and JAX-RPC, a java standard for XML based RPC. (Think SOAP).

Application Containers

Application containers run JEE java code. JEE itself is a collection of API's designed to facilitate "Enterprise" computing. (Enterprise systems are usually complex software systems that process potentially huge quantities of commercial, financial and other kinds of data commonly used by governments and corporations). JEE (formerly J2EE) systems are very disparate in which JEE API's get used and which do not, for JEE API's can be used optionally, in a pick n mix fashion. "Enterprise Java Beans" (EJB) for example are Java classes that conform to a JEE API that allows an Application Container to access those classes in a standard way. The benefit of this complexity is that the developer can get magical powers for "free" that are crucial for large enterprise software systems.

In general JEE API's exist to allow the developer to delegate to the application container non- "business logic" related features such as any of scaleability, transactions, thread safety, security, asynchronous messaging, resource management, data persistence etc.

A lightweight J2EE "container" is the Spring Framework, which is mentioned further below. Next we tackle the heavyweight application containers.

The most popular heavyweight Enterprise class Application Containers with business and government are BEA's WebLogic, IBM's WebSphere and JBoss ("owned" by RedHat and others). All three are extremely capable and high quality systems. The first two are proprietary and are expensive, the most expensive and most powerful arguably being WebLogic. JBoss however is open source and free, which deters the largest projects from using JBoss for live systems.

Some governments and corporations actually feel reassured by expense when it comes to software, partly because of support options, partly because execs can pass the buck and blame a vendor, and partly because of the delusion and myth that "what you get what you pay for" applies to software. In reality software breaks the laws of physics and economics, at least as intuited by non-technical managers. Although JBoss the software is free (no licence fees, no licence management), JBoss support can easily be purchased and can be as glamorously expensive as for any other software. The official company that supports JBoss is RedHat, the enterprise Linux vendor. Various other organisations will support it too, such as HP, to choose one at random.

On the user interface side, as well as supporting JSP via web application servers (JBoss integrates Tomcat, for example), WebLogic, WebSphere and JBoss all have "portal" development tools, again with the first two portals being proprietary. I mentioned JBoss Portal earlier.

Tomcat, from Apache, can be used as a standalone JSP web application container.

Also worth a mention is that the JBoss guys have created a new application framework called SEAM. The intention is to integrate the presentation, business and persistence tiers, a little like Ruby on Rails (RoR). In particular SEAM integrates JSF with EJB.

For less than very heavyweight professional JEE applications using an application container is probably overkill. Using such a beast complicates Java development. Container managed code is a devil to unit test, for example. Also, to run your JEE code you need to deploy to the container first, which is not as quick as the simple compile and run modus operandi. (Or, using eclipse, just run, as eclipse by default compiles your code in the background).

In fact virtually any JEE app can be created using the Spring Framework. Spring is actually a collection of loosely coupled frameworks, whereby you can choose what you need and leave out the rest. As well as implementing JEE API's, Spring offers many more features, for example, "Inversion of Control" (IoC).

Inversion of Control is a convoluted term for a type of "factory" pattern - an alternative name of this pattern, "dependency injection", is more apt. You can use Spring for IoC, i.e. to "wire together" objects without writing factory or lookup subroutines in Java. However this is not good practice for creating most objects in an application. IoC should only be considered for stable interfaces of the most decoupled components, or to instantiate third party components. It can be appropriate for "injecting" framework-like code. Over-enthusiastic use of IoC slows down agile development, as inappropriate IoC can make refactoring painful to do. Treat IoC a little as you might handle optimisation - as the wise man said, Advice to programmers: do not optimise. Advice to expert programmers: do not optimise yet. The important received wisdom is to design the software to have "loose coupling" and "high cohesion" between classes and components. Unindulgent use of IoC is consistent with good design especially as it encourages configuration-like setup to be externalised, which is usually a good idea.

Spring is great for being the framework that integrates other frameworks, e.g. Hibernate, JMS etc. etc. Essentially frameworks tend to require "boilerplate" code that does nothing but set up and configure those frameworks. Spring removes the need for most of this boilerplate, so all you have to do is specify configuration strings in Spring config files. IoC does the rest. This also makes configuration more unified across the application. It is at this level of integrating frameworks and framework-like components where Spring IoC works really well.

Finally, spring provides a mechanism for Aspect Orientated Programming (AOP). Personally I do not recommend AOP, as it breaks good coding principals (in a "goto considered harmful" kind of way). However AOP can be the right tool for the job sometimes. For example, AOP can be used to unobtrusively inject performance diagnostics code, especially during development, or perhaps in live systems it can implement auditing across an application.

Spring is associated with XML Hell. This can be ameliorated though, by using Java "annotations" or even using Java code itself to configure Spring Beans. The horror of XML Hell is an excellent reason to avoid overdoing it with the old IoC. Another downside of Spring is that when something doesn't work, Spring vomits horrible, difficult to diagnose error messages, an XML phenomenon.

Java framework designers really need to fix this problem, if it is possible to do so. Applying polish such as informative error stack traces is very important and highly overlooked, probably because programmers find error-diagnostic code boring to write, and managers do not demand it.

Spring does a nice job (once one can actually figure out how to configure it properly) of providing a "Java Management eXtensions" (JMX) implementation. JMX is rarely used J2EE API compared to EJB, etc. yet it's a gem. JMX allows you to use Managed Beans (or MBeans) that can be used to "instrument", i.e. remotely access and control, your applications. One option is to wire up a HTTP adapter so you can monitor and manipulate beans via automatically generated web pages. MBeans are heavily used by applications such as WebLogic, JBoss etc. When you use the consoles of WebLogic and JBoss you are actually invoking MBeans beneath the surface. WebLogic WLST is implemented with Jython that uses JMX to configure domains, monitor applications etc.

Service Orientated Architecture

Service Orientated Architecture (SOA) is much misunderstood, probably by everyone, myself included. At time of writing (Aug 2007) SOA is still immature, so my opinions, which may be faulty anyhow, may become out of date if I neglect to update his page often. One thing is for sure - overdoing SOA will bedevil your project. SOA means many things to many people, so here let me warn against a flavour of SOA that uses lots of "SOAP" (Simple [sic] Object Access Protocol) based Web Services.

The first thing to be aware of when using SOAP is that performance is the first casualty - an HTTP call is hundreds(!) of times slower than a Java RPC call. SOAP based SOA often entails encoding "contracts" in WSDL XML files. This approach should be used tentatively. If it is overdone then the project can become damned to XML Hell: unforeseen complexity, messy testing, lousy performance, unexpected runtime faults, horrendous deployment issues and a degradation of agile development capability (refactoring WSDL contracts together with associated java code is a painful manual process).

Another cautionary note is that SOA is immature, with Web Services "WS" standards evolving radically. No doubt SOAP based SOA will become more powerful in the future once these standards are ironed out. Any SOA book will blushingly present you long lists of benefits, many real, many illusory.

Potentially appropriate uses of SOA is for talking to components where a faster RPC call is not practical; for processing asynchronous messages between disparate servers; and in situations where a Service Bus pattern is apt. As long as the risks are managed prudently, then SOA can confer benefits and may even be best practice. But even teams of brilliant, experienced developers and architects discover that XML-heavy SOA projects can get bogged down and take much longer than anyone thought - even more than normal! The amount of unexpected additional effort to get SOA working properly can negate its supposed benefits once delays start to bite.

I have seen SOA go horribly wrong, but I have also seen SOA work extremely well, and hopefully so, given that SOA has been around for decades under various names. In my experience, highly successful modern SOA projects, delivered on time and on budget and meeting customer requirements, have an architecture that is relatively simple and relatively (but not necessarily totally) "web services" free: where basic XML messages are passed around via JMS. However that SOA model is less extravagant than the fullblown trendy SOA utopia that many consultants are flogging right now.



Disclaimer:

The opinions presented here are casual, may become dated as tech evolves, and simplistic to keep the text brief on massively complex topics. Each project requires analysis to determine a suitable architecture. There are usually exceptions to rules in this game and your mileage may vary. These opinions are not to be construed as professional advice, use at your own risk. Etcetera!



The author of these light Java analyses is Jim Eadon, who makes a living as a Java/JEE consultant, architect and developer.


See also a fine list of Java related links.



Add your comment to this page

From:	Mighty Whitey	Subject:	Update your terminology	2007-10-02 18:03:20
From:	Eadon	Subject:	Thanks Whitey	2007-11-05 23:18:19

View the comments

help: how to add your comment

Page hits: 212