Enterprise JavaBean (EJB) is only for large shops. EJB is a complex technology that is hard to develop with. Web application servers that support EJB are expensive. All of these statements are common misconceptions about EJB.
I see two alternatives when using Java for AS/400 applications: one is to use RPG or COBOL for your business logic and the other is to use EJB. In either scenario, youd use JavaServer Pages (JSPs) and servlets to handle the Web interface. The decision is whether or not you want to code your business logic in a legacy language or go all-Java. If you take the all-Java route, the time and effort required to develop a robust application can be extremely prohibitive. I say it is prohibitive because it takes a tremendous effort to code database persistence, transaction control, and scalabilityunless, that is, you let the architecture of EJB do it for you.
Persistence
With RPG and COBOL, database files drive the processing. But the base Java language doesnt even know what a file is without bringing in additional Java packages to support I/O. Further, even after you access a record, the data from that record is in EBCDIC, not in the Unicode datatypes of Java. That means, if you code your business logic in Java, your programmers will have to tediously add code to fluff and stuff data to the database (i.e., code an architecture for data persistence).
Transaction Control
One application transaction often spans the add, update, and delete of multiple records across several database files. Programmers have to take great care to ensure that if something goes wrong with any one of the records, the updates to the other database files of that same transaction are not committed. AS/400 RPG coders have handled this well with the file locks of record-level access in their do-all monolithic programs. But, in component-based development, you can have dozens of modules that collaborate to perform one application transaction. Without using EJB, your programmers will have to perform complex programming to ensure transaction boundaries are not crossed. But, when using EJB, your programmers will not have to do any coding to maintain database integrity.
Scalability
The slowest part of Java is the creation of all those objects. Senior Java developers know how to code around this problem. But how many senior Java developers are there? EJBs standard architecture allows servers to pool objects for optimal use. Coders think they are creating a new object over and over again, but, behind the scenes, the EJB server continually reuses the same half dozen or so enterprise beans. This work management for Java, as I like to call it, is what allows EJB applications to scale well.
Prototypes, Architectural Standards, and Roles
There are four other advantages of EJB. The first advantage is that EJB applications are easy to prototype. The second advantage is that EJBs standard architecture promotes and all but forces proper component-based development. Each component of an EJB applicationJSP user interface, Java servlet application controller, workflow session bean, and database entity beanis, by itself, simple. By looking briefly at an EJB components interface, a programmer is quickly able to understand how easy it is to use that component and how easy it is to maintain.
The third advantage is that its standard architecture makes it easier to maintain your applications. One of the greatest advantages of the AS/400 is that you could hire anyone with AS/400 experience. The same goes for EJB: Anyone with EJB experience will be able to maintain your EJB application.The fourth advantage is the separation of coding responsibilities. In EJB applications, I see three roles for the application developer:
HTML Developer (uses HTML and JSP to develop and enhance the user interface)
Script Developer (uses Java in JSPs and servlets to interact with the business logic)
Business Logic Developer (codes the EJB components to handle the intricacies of the business application)
But EJB Is Expensive
WebSphere Standard Edition is bundled with OS/400, but the Enterprise Edition (required for EJB support) costs $7,500 per processor. Thats not expensive when you consider the cost of paying several Java programmers to code in persistence, transaction control, and scalability. Further, there are several EJB servers available for free:
jBoss (www.ejboss.org)
JOnAS (Java Open Application Server) at www.openmaster.com/ejb/index.html
Enhydra Enterprise Alpha 2 at www.enhydra.org
Dasein EJB Application Server at www.imaginary.com/Java/Dasein
These EJB servers are all-Java products and run well on the AS/400. And, even though you are using a non-IBM product for the EJB engine, you can still use HTTP Server for AS/400 for Web serving and the bundled WebSphere Standard Edition for JSPs and JSP execution.
Whole Hog with EJB
If you are going to go whole hog with Java, use EJByou cant afford not to. You cant afford to code persistence, transaction control, and scalability. You cant afford to invent your own strategy for coding real-world business applications with Java. Let the architecture of EJB take care of all that for you.
LATEST COMMENTS
MC Press Online