A tale of two architectures

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to heaven, we were all doing direct the other way – in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only.
Charles Dickens, A Tale of Two Cities

IN THE MINDS of many programmers, the technological layer of any Enterprise Architecture comes down to a choice between J2EE and .NET. Both systems are supposed to offer interoperability, so (in theory at least) the choice should come down to the quality of the implementation tools. But in practice, there are fundamental differences in outlook and philosophy.

Let’s take a look at some difficult and controversial ideas, and how they came to be current.

Java is more than a language

Java started out as a language to be used in embedded machines. It became popular as a way of creating web-page-embedded applets, and gained credibility from the confusion between it and the JavaScript language. For a while Microsoft saw Java as the biggest challenge to its domination of the operating system market – because Java in a browser environment is as good as an operating system. Microsoft’s reaction to Java, the language, is well known and the subject of legal action; what is less obvious is what happened in the second phase of Java’s development.

The most important aspect of Java, and it’s a comparatively recent one, is the J2EE edition. This takes Java beyond just being a programming language with some extra APIs to being a framework for distributed computing suitable for implementing n-tier Enterprise Architecture. Today the Java language comes with three alternative sets of support structures, depending on the environment it is to be used in:

• The Java 2 Standard Edition, or J2SE – this is essentially just the current JDK with no additions or removals.
• The Java Micro Edition, or J2ME – this is the standard JDK minus some classes so that it can work on consumer electronics.
• The Java 2 Enterprise Edition or J2EE – this is an extended JDK complete with extras to allow multi-tier web-based systems to be built.

Microsoft has alternative solutions for all three Java Editions, but the one that interests us is J2EE. In this case the .NET system has to be considered as more than just new languages and a move from ActiveX to class libraries. It is an alternative framework for implementing multi-tier systems, and as such is a direct response to J2EE.

Multi-tier madness

We tend to regard the division of a large architecture into small functional components as an obvious one. From an enterprise architect’s point of view this may well be so. Dividing systems up into components, without a care as to how they work together, where they work, or how many of them work, is a huge simplification and the best approach. However, for the programmers who have to implement this scheme, many of the problems that existed in the high-level view have now been transferred to the implementation. Without significant additional infrastructure it is necessary to re-invent distributed objects, communications, state management, transactions and so on. Without specific tools and IDEs to develop such systems, we have additional problems of testing, debugging, performance analysis and so on. Just when you thought you’d found easy, economic and reliable ways of writing desktop applications, the goal posts are uprooted and moved to another galaxy. This is clearly not good for programmers and possibly represents the worst of times.

The n-tier approach initially seems very reasonable from the programmer’s point of view, because it’s just another example of the divide-and-conquer approach to complex systems, but what very few programmers will ever admit is that building a multi-tier system can be a very complex task. In particular, debugging and testing becomes a big problem, as does system integration. It is often the case that a project reaches a stage where every object compiles and passes basic tests but the entire project fails to build correctly, let alone work! Although the multi-tier approach is often presented as the solution to all our problems, making it work requires additional discipline, careful design, automated testing and deployment. The real question is what might be achieved if the same amount of effort was applied to alternative architectures – peer-to-peer, grid computing or distribute and replicate.

To the next tier

The J2EE system is designed to allow developers to build three-tier (or more) systems, using nothing but Java-based technologies (see Figure 1).

Figure 1: A J2EE three-tier system

At the client level we can either write Java applications or applets which live inside a browser. At the simplest possible level the client may just be the web browser itself viewing suitable web pages. Building Java applications and applets is something which is very familiar to Java programmers and represents nothing very new. If you want to create a user interface then you basically use the standard libraries of controls, and if these aren’t enough you can write yourself a Java Bean. A Java Bean is a class that can be used in a visual editor by dragging and dropping it onto a form. In this respect Beans are the Java equivalent of ActiveX components – now replaced of course by .NET controls and classes.

Most of the extra structure in J2EE, which will be unfamiliar to the J2SE programmer, is to be found in the middle level. There are two middle-level architectures possible under J2EE – web server or EJB container server. The web server approach needs a web server that supports “servlets” and “JSP”, which of course Microsoft’s ISS web server doesn’t. A servlet is like an “applet” that runs at the server. It integrates with the server to deliver information to the web browser. The Microsoft equivalent of the “servlet” was the ISAPI Internet Server API extension module. You had to learn the art of writing servlets or ISAPI modules and they had to be installed before server-side scripts could make use of them.

JSP stands for Java Server Pages and it’s the Java equivalent of Microsoft’s ASP (Active Server Page) technology. A JSP page is an extended web page which includes HTML and Java. It compiles to an HTML page plus a servlet and in this sense it is just an easier way of creating a servlet. However, it has the advantage of keeping the page and the code together rather then separating them. Now that Microsoft has J2EE (and specifically JSP) to deal with, ASP has been improved to ASP.NET. An ASP.NET page compiles to HTML and a range of server-side components – web controls.

The important advantage claimed for ASP.NET is that we now have both server-side scripting and server-side objects that are conceptually the same as form-based programming and objects. The idea is that developing ASP.NET pages should be no different from developing forms-based applications, and there is no longer any need to learn about ISAPI or any other specifically web-based technology. Of course in practice there are differences to be taken into account when developing for the web, and if you don’t do it right, the overheads of having everything on the server side are too much. But this is also true of the J2EE approach.

Application servers

The web-server approach to the middle layer is the more usual, but it carries with it the disadvantage that a web server is optimised to deliver web pages. Using a specially built server for complex requests seems like a better idea, and there are indeed many application servers available. In the J2EE framework the alternative to a web server is an EJB – Enterprise Java Bean – server. This allows the programmer to write a special type of Java bean, an EJB, that runs on the server and responds to the client’s requests. There is a subtle point in that the server actually comes in two parts – the server and the EJB container. The server does the work and the container provides the environment for the bean to run in and deals with things like security and access policies. In most cases both components are bundled into the same software, and can effectively be thought of as an application server that supports EJB.

Of course you need to acquire an EJB server. This is something that you generally have to buy, and it often forms a major component in “enhanced” Java suites such as Borland’s JBuilder and IBM’s WebSphere. This is clearly an opportunity to make some money out of Java at long last!

The advantage of this approach is that it allows the application server to live alongside the web server of your choice, and it separates the web page presentation from the processing logic. You could also say that it complicates matters by creating a division which requires communication and cooperation to make sure that the final entire system works. The J2EE documentation tries to make a virtue out of this division – the bean developer can work without really knowing what the beans are for, and the system assembler can put the whole thing together. The bean developer can also be a subject expert – accountant, database expert, statistician etc. – and the system assembler can be a generalist just knowing what the end result needs to be! Does this idealistic situation seem reasonable to you?

Enterprise Java Beans are themselves just standard beans which have to support specified interfaces so that they can work in an EJB server/container. At the moment there are three types of EJB:

• Session beans – These can be made specific to a particular client. They are used to implement facilities such as shopping carts.
• Entity beans – These provide an object view of data in a database. They represent a row, i.e. a record in a database, and can serve multiple clients.
• Message driven beans – These are written to work as JMS – Java Messaging Service – listeners, and they respond as required to client requests.

Unfortunately you can’t build a complete system with nothing but EJBs. You need some additional components to make the client’s interaction seem natural. These additional components can be Java applications, applets, JSP web pages or servlets.

Of course J2EE doesn’t end with servlets, JSP and EJBs. There are many auxiliary technologies that can be used to build the rest of the system. For example:

• JDBC (Java Database Connectivity) – is the standard used to connect to database servers, i.e. the EIS (Enterprise Information System) tier.
• JMS (Java Messaging Server) – a message routing service.
• JNDI (Java Naming and Directory Interface) – is used to locate distributed objects.

XML and SOAP

The description of J2EE given above is sometimes referred to as “pure” J2EE because since it was invented things have moved on and it has had to be modified to keep up. We hear a lot about the fact that XML is going to revolutionise and standardise the way things are done on the Web, and many programmers think that XML and Java are very closely related. However, J2EE as described, i.e. pure J2EE, is a pre-XML system. If anything, this is the biggest difference between J2EE and .NET, as .NET is post-XML, and as such is XML-based (and was from its very creation).

How important is this? Well as you would expect, J2EE has found ways of incorporating XML and its associated technologies, so to some degree it includes it, but if you want to take an XML-based approach to multi-tier architectures it also contains a lot that you don’t really need. In short, pure J2EE isn’t pure XML, whereas .NET is.

Java 2 can cope well with XML, and it does so in the same way as it copes with every new technology – it adds class library-based APIs to implement them. In this case we have a whole raft of new APIs:

• JAXP – Java API for XML parsing
• JDOM – Java Document Model
• JAXB – Java API for XML binding
• JAXM – Java API for XML messaging
• JAX-RPC – Java API for XML Remote Procedure Call

…and more besides.

All of these new APIs give a great deal of new power to the Java programmer, but what does it do for the overall J2EE framework? There is an argument that Java now has so many APIs and solutions that it is difficult to know what to take seriously.

There is a very real argument that .NET is a reaction not to Java but to J2EE. In particular, the adoption of SOAP-based web services seems like a really good way of short circuiting many of the advantages that J2EE offers. Not every web server supports JSP or servlets – Microsoft’s IIS for example – but SOAP (Simple Object Access Protocol) is an open protocol and as such every web server is expected to support it – including IIS.

As far as J2EE is concerned the real killer is SOAP – which is the XML way of a client making use of a server object. It is Microsoft’s chosen approach to client server architecture. It doesn’t need an application server to support it, but, as in the case of EJBs, application servers that support SOAP can be advantageous in terms of improved efficiency. One small point is that all of this has been happening just at the time when Microsoft’s efforts to bring distributed objects to the real world were bearing fruit in the form of DCOM+. The role of such pure object-oriented technologies including CORBA are a matter for another article, but it is fair to say that these are dull and uninteresting approaches judged by today’s buzzwords.

SOAP and web services are almost, but not quite, synonymous in the current documentation, and another way of looking at the problem is to ask the question “how does J2EE implement web services?” The answer is that you have to throw away a lot of the existing infrastructure – servlets, JSP, EJBs and so on, and work instead with SOAP. Initially the only choice was to work with JAXM to implement SOAP messaging, and with JAXR to implement UDDI etc. Now there is the rapidly developing Java Web Services Developer Pack (Java WSDP), currently at version 1.3, which includes many of the other Java XML APIs. Of course, there is nothing stopping you mixing pure J2EE and XML J2EE together, but the whole thing is beginning to look very messy.

The simple fact is that at the time .NET was announced, Java just wasn’t equipped to handle XML J2EE and SOAP J2EE. Is this just a coincidence? Consider for a moment the full situation. J2EE has EJB and servlets, technology that Microsoft cannot support easily due to its “problems” with Java. J2EE, on the other hand, doesn’t make much of XML or SOAP support. By strongly adopting both, Microsoft takes the lead in a technology race that it was losing.

Some application servers are building in support for SOAP along with EJBs, and it looks as if Java is going to be a mixed environment at this level of the architectural hierarchy for some time. Some say that this is all to the good, as it provides choice. If you pick .NET then you are opting for ASP.NET and SOAP web services. If you pick Java then you can choose either the EJB/JSP or SOAP implementation of your design.

But it’s still early days and it’s difficult to say if we are really watching the start of a complete paradigm shift, or a long drawn out co-existence of approaches.

The rough guide to n-tier architecture Until relatively recently, we built applications in a fairly straightforward way. If a job needed doing you wrote a program to do it. This model suited the centralised mainframe environments well, and it even survived the transition to the new desktop machines of the 1980s. Until, that is, the desktop machines started to communicate and then a different model was needed. The needs of shared centralised databases made it clear that we needed to think in terms of servers (i.e. the databases), and clients (i.e. the programs that accessed the data and presented it). The split between what the client and the server actually did slowly moved more and more of the active processing to the server software, the idea being that the server should contain all of the processing code that is common to the clients (see Figure 2). Figure 2: A single application working with a database evolved into a separation of concerns we now call “client-server” This client-server architecture allowed a great simplification, and it naturally led on to distributed and remote implementations. You can have many clients accessing multiple servers all running on different machines and all communicating via the Internet. This configuration is in principle easier to construct and maintain, and it is scalable. When the Web came along this principle proved to be good. Web servers provided huge quantities of data to end users all using simple (and later not so simple) clients. Few developers were prepared to notice or comment on the troubles that were caused by the non-interoperability of the different implementations, the impossible to maintain website structures, the broken URLs, and the generally terrible quality of implementation. This was client/server architecture in action, and it mostly worked. The next step in the evolution of distributed systems can just be thought of as more of the same. If it is worth splitting things down into client-server why not split it down even further. The idea is that by dividing things up into smaller modules you can make the whole system more robust and more scalable. This is the start of multi-tier client server architecture, and of big problems for many programmers. In this case the client is made to interact with as many layers of server objects as necessary. Each layer of objects acts as clients for the next layer of servers. Usually this results in a minimum of three layers – a client that deals with presentation and user interface issues, a middle layer that does most of the work, and an Enterprise Information Server (EIS) which manages the database (see Figure 3). Figure 3: A typical three-layer hierarchy