Feb. 23, 2011, 5:35 p.m.
posted by oxy
Processing is the part of the enterprise system that the middleware can't handle for you, the "meat" of your applications. It goes by many names: business rules, business logic, domain logic, application code, ad infinitum. At its essence, processing is what the business is paying for in the first place: to do things with the data that aren't being handled elsewhere.
A large part of processing in an enterprise system deals with concurrency—for maximum throughput, we need to assume that two things can happen at the same time. No matter how fast the hardware, trying to run a system where everything happens just one step at a time for all users in the system is going to bog down pretty quickly. So as programmers, we need to deal with the fact that multiple threads of execution, whether logical or physical, are a reality. Unfortunately, this is easier said than done.
In an enterprise Java system, concurrency touches on two subjects simultaneously: Java's native object monitor-based synchronization system and the transaction-based synchronization mechanism built into most enterprise resource managers. While it would be nice if we could simply ignore one in favor of the other, at this time that's not possible—the Java language (and/or virtual machine) hasn't got transactional capabilities built into it, and trying to "hide" the transactional nature of resources has proven over and over again to create bottlenecks. As a result, we need to be aware of both aspects of concurrency.
For more details on Java's object monitor-based concurrency mechanism, I highly recommend Concurrent Programming in Java [Lea]. In addition, I assume that you've already read Items 48 through 53 of Effective Java [Bloch]; for example, you will never want to mark a servlet doGet or doPost method as synchronized for the reasons described in Bloch's Item 49 ("Avoid excessive synchronization").
You'll note pretty quickly that many of the items in this chapter deal with transactional processing; any others (like rules-based processing or workflow) take a definite back seat. While this may seem a bit heavy-handed, the majority of enterprise IT systems are, implicitly or explicitly, transaction-processing systems of one form or another, and as such many of these items are directly relevant to your daily life as an enterprise Java developer. Even if you're not currently using EJB, keep reading—not only is it likely that you will in the future (your system, if successful, is quite likely to have to talk to multiple databases simultaneously, thus creating a situation ripe for EJB, per Item 9), but the same concepts apply whether you access the enterprise resources through an enterprise bean or directly, through a Connector or vendor-proprietary API.