Enterprise Java (J2EE)

Java standards continue to evolve at an amazing pace. Enterprise Java is of particular interest to the author who spent many of his early years working on enterprise systems, firstly ICL and then IBM mainframes (those were the days). Mainframes came with a toolkit of powerful technologies that allowed developers to build robust systems that performed to the very limits allowed by the hardware.

A key piece of technology in that toolkit was the TP Monitor, a vital piece of what might be called 'middleware' today. The TP Monitor was responsible for ensuring that on-line activity from a distributed network of terminals was managed efficiently, scheduling all the necessary resources to optimise throughput and user response time. The concept of a 'transaction' was an integral feature of these systems, i.e. the notion of a sequence of actions that together formed a logical unit of work that either succeeded or failed as a whole.

A rich set of programmer API's ensured a high degree of control and configurability.

Where did all this go? Well, hold your breath.We went from mainframe TP monitors, to Distributed TP monitors (mainly on Unix), to the emergence of Object Oriented middleware environments (CORBA message brokers) to application servers (primarily Java based).

Today's Java application servers (of which there are many) are not too dissimilar from the old TP monitors. They attempt to hide the complexities of building transaction processing systems from the programmer by hosting a set of system services that the programmer can take advantage of without having to understand how  they are implemented (e.g. transactions, security, thread management, resource name resolution etal). With the J2EE standard, theses services are also portable (in theory) across application servers from different vendors, and being a Java based technology, customer choice of hardware is also possible.

The J2EE standard encompasses a wide range of technologies that covers anything from http support (servlets), through database access (JDBC) to hosting distributed components (EJB).

The Enterprise JavaBean (EJB) distributed component technology is the J2EE technology with most in common with the traditional TP monitors, except a key difference is that EJB works with software components that are Object-Oriented in nature.

So how easy is EJB to design and program?

Well, despite the hype, the author believes it isn't that easy as some make out. The programming side isn't too difficult once you've cut your teeth on a few examples, the biggest issue is in designing your application to fit onto the imposed 'session' and 'entity' bean concepts that are essential to the EJB framework.

Is a 'session' bean a process, a user role or just an arbitrary collection of workflow related methods that can be grouped into a single image for deployment purposes?

Who indeed knows? All the examples you see in books, Sun publications (blueprints) and resources on the net, tend to focus on explaining a 'session' bean from its place in the EJB framework. In many cases you see examples where metaphors are indeed mixed, which must confuse the many who are trying to get to grips with the concepts.

The author has failed to find any resource that focusses on this whole issue from a business perspective with a clear definition of how to translate business concepts onto Session beans.

How many others out there are also having to work it out for themselves?