04
Mon, Nov
1 New Articles

EJB3 and WebSphere: A Harmonious Union?

Commentary
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

After stumbling out of the gate, Entity Java Beans return with a whole new attitude.

 

In my most recent article on Service-Oriented Architecture (SOA), I mentioned that I consider Simple Object Access Protocol (SOAP) to be terribly over-engineered. In that same article, I mentioned my longstanding opinion that Enterprise JavaBeans (EJB) was originally in the same category. I in fact once said EJB was one of the first technologies that had "jumped the shark" before being officially released.

 

However, EJB has evolved. Unlike Happy Days, which gently fizzled out after spawning Joanie Loves Chachi (both stars of which ended up in reality TV, but I digress), the EJB community continues to try to get it right, and the latest incarnation, EJB3, seems to have gotten much closer.

 

The problem when technologies such as this go through updates, though, is that sometimes the user community doesn't follow along, and you end up with orphans. For example, there are still a lot of Struts shops out there, even though Struts is clearly on its last legs as a technology. And while Struts may be the largest example, plenty of others have come and gone, particularly in the Java space.

IBM Buy-In Helps

And that's why WebSphere's inclusion of EJB3 support (as an add-on feature pack to the 6.1 version) is important. Love it or hate it, WebSphere is one of the vanguards of the Java EE movement. And while some fault WebSphere for not always moving as quickly as other application servers when incorporating new technologies, when a feature shows up in WebSphere, it can be said to have matured.

 

Certainly, the community has been looking for WebSphere to adopt EJB3, and the availability of the feature pack very late last year definitely gave some extra impetus to adopt this newest technology. The recent adoption of EIM support throughout the WebSphere line has certainly given a boost to the Single Sign-On (SSO) strategy. The Apache HTTP server on the i will now negotiate credentials with Internet Explorer, meaning that a user can log onto Windows and then use WebSphere applications through the browser without having to sign on again. Until this technology was enabled, the idea of SSO was somewhat limited because you could use it for desktop applications but not for browser-based systems.

 

And although EJB3 is more of a programming technology than an administrative one, I think WebSphere support for EJB3 will similarly help with its uptake.

What Is EJB3?

EJB3 is a marked step away from traditional EJB. Whereas EJB up to Version 2 was a very heavy protocol requiring definition of multiple classes and lots of XML configuration, EJB3 uses a completely different approach that relies heavily on annotations and dependency injection.

 

If you're not a Java guru, this might not mean much. But in the long run, it has several major functional ramifications:

 

  1. Beans are Plain Old Java Objects (POJOs).
  2. Persistence is maintained using an Entity Manager.
    (Hibernate users will appreciate this.)
  3. Code is injected at runtime.

 

The tradeoff is pretty major: You no longer need to create big XML files to define your Beans; instead, your code is going to be altered at runtime. The latter point becomes very important when you're talking about deployment and especially debugging.

 

Beans Are POJOs

 

It's hard to over-emphasize just how important this is. Prior to EBJ3, all Entity Beans had to implement the rather cumbersome EntityBean interface, which in turn required implementing a range of methods designed to support the persistence process. Even if you didn't use these methods (and most Beans didn't), the developer had to create all of them, which meant a whole lot of unused and useless methods. The developer had to create support classes, such as the Local and LocalHome classes, and then had to describe pretty much the entire database definition of the class in XML in the deployment descriptor. This included everything from the individual fields in the table to the class that defines the primary key to the methods that are used to find instances of the entity. Add to that the definitions of relationships between tables, and as you might imagine, the definition of large databases became quite involved and generated huge files.

 

With EJB3, all of this goes away. You simply define your Bean as an everyday POJO and then you add annotations as needed to describe the database natures of the object. It's an example of the complexity of the previous approaches that Java developers even needed the term POJO, but the truth is that class definitions especially for EJBs were spiraling out of control. With EJB3, you return to the simplicity of defining an object whose fields represent the actual attributes of the object. You add the annotations to then describe the Object-Relational Mapping (ORM) characteristics.

 

    @Column(name="DBANAME")

    public String getDoingBusinessAs(){

        return doingBusinessAs;

    }

 

This simple example shows how the attribute name in the class is not necessarily the same as the column name in the table (and in fact, depending on your database schema design, these may nearly always be different). Here's another example:

 

    @Column(name="ORDER_COST", updatable=false,

            precision=12, scale=2)

    public BigDecimal getCost() { return cost; }

 

I took this right from the Java EE 5 documentation, but look at what you see: updatable=false tells you that this value is not directly modifiable by the application (in this case, it's the total order cost, which is calculated based on other values in the database). Notice also that the annotation provides additional definition elements such as scale and precision, which are beyond the simple object type of BigDecimal. These elements are used during the ORM phase to help move data between the database field and the corresponding Java object.

 

EJB3 supports the EJB Query Language (EJB-QL) to define the syntax of queries and has made it very easy to define not only primary queries but also additional queries to support other access techniques. One of the things I've always found frustrating with some types of code generation facilities is the fact that database access is limited to the primary key, when in the real world we need to access rows in a table in a variety of ways.

 

Also, EJB3 has support for inheritance, and it seems to be done intelligently. When you use a database to create types and subtypes, you do it in two distinct ways: One is to have a single table and then use a flag to determine the type; the other is to have common data in one table and then create additional tables to hold specific information for each subtype. EJB3 has direct support for both. That's one of the really nifty things about the annotation syntax; since annotations are keyword/value-based, developers can add a lot of capability without having to change the syntax, so they can focus on this sort of usability. Contrast this with the overwhelming amount of work that went into adding generics to the base language and the resulting complex (some would say overly complex) syntax. Let's hope that the annotation designers and the EJB3 folks in particular continue to stick with the KISS principle.

 

Entity Managers Provide Persistence

 

The actual persistence part of the specification is done via something called an Entity Manager. I keep bringing up this term, but it's important. The Entity Manager is to high-level persistence as a JDBC driver is to a database. An Entity Manager is a class that implements a specific interface (javax.persistence.EntityManager), which in turn is part of the Java Persistence API introduced with Java EE 5. This interface has a number of high-level abstractions that have to do with managing beans and was built with a lot of attention being paid to existing frameworks such as Hibernate and TopLink. And in fact, both Hibernate and TopLink have Java Persistence API (JPA)-compatible interfaces so that you can use either one as your persistence engine and thus use any database they use.

 

It's an interesting double layer of abstraction, but it seems to work well. You define your Beans at the business level, and through annotations, you describe them to the persistence engine. The persistence engine itself is defined in the deployment descriptor, along with whatever information is need to identify the database to be used.

 

One of the things that I need to spend a little more time on is the concept of security. I know security is at least addressed in the JPA specification, but I don't know exactly how it's implemented. Specifically, I don't know how user credentials are passed from the active session to the database layer. It seems to me that it will be very important as part of the overall concept of EJB3 to be able to pass the user ID that was initially used to authenticate the session down to the database layer and use that to authorize data-level transactions. It's one thing to have a single user ID and password that you use for standard database requests (such as you might have for a storefront catalog), but it's another thing entirely to ensure both row- and column-level security based on the user ID.

 

Further along those lines, with the increasing use of SSO technology, it would make sense that the identity token, whether it be Kerberos or EIM, would also need to be supported.

 

Annotations?  Dependency Injection?

 

Yeah, this is a little scary. The concept of annotations is complex, and while it provides powerful capabilities to the Java language, it removes it one step from the world of nuts-and-bolts programming. In essence, an annotation is a syntax element that doesn't actually generate code; it is more of a comment that affects how the compiler works--or even more scary, how the code is processed at runtime.

 

The compiler-level annotations are pretty simple; they allow you to log messages or even create additional source files for later compilation, but they don't actually affect the code. Runtime annotations, on the other hand, can be used by other parts of the system to affect how your code works.

 

In the simplest scenario, let's take the concept of the Entity Manager. With an interface like this, prior to the concept of annotations you would get the Entity Manager from a factory of some kind:

 

      EntityManager em = createEM("aParm", "anotherParm");

 

The parameters could come from a configuration file or could be determined based on user ID or application or any number of things. The perceived problem with this approach was that you might have to change that line of code whenever you wanted to add a new implementation of EntityManager, and that would not be configurable. The new technique the designers came up with was the annotation. It works like this:

 

      @PersistenceContext

      EntityManager em;

 

Yes, I know what you're thinking. What's that odd "at" sign (@), and how is this going to create an Entity Manager? Well, in the world of annotations, one of the things that can happen is that code can be inserted at runtime to do things. In this case, the annotation is @PersistenceContext, and it will insert ("inject") an EntityManager instance (a "dependency") into the field em when it is needed. I'm a little bit hazy as to when this occurs. Is it when the class is first loaded, or is it whenever the class is instantiated, or does it perhaps depend, for example, on whether the variable is a static, dynamic, or temporary variable?

 

This can be a little unsettling at first. There is no code to debug; you just have to rely on the dependency injection to work. And that in turn depends on the "container," the environment that the application runs in. This is something above and beyond the Java Virtual Machine (JVM); this is a set of JAR files that control how the application executes, forming yet another virtual layer upon which the application runs. In the Web world, it's pretty easy: You add this sort of support code in your servlet container. However, once you step away from the Web environment, it becomes a little trickier, especially for standalone Java applications. Somehow, you have to create the same sort of container that surrounds servlets, and that's not always intuitive.

 

Issues also exist for IDEs such as Eclipse or Rational; not only do they have to support the basic annotation syntax (which is part of Java 5), but they also have to understand what the annotations do. For instance, in the second example above, if you tried to use the variable em, you would normally get an error in the editor telling you a field was not initialized. The editor would have to not only accept the @PersistenceContext annotation as valid syntax, but also realize that it will initialize the em variable so that later references are not flagged as errors. This seems to me to be no small feat!

 

Despite my ignorance, however, the stuff works. So I suppose I should just bag my pessimism and move on, because the benefits of this approach are quite substantial.

So Does EJB3 Finally Make EJB Usable?

Yes, I think so--at least, as soon as all the pieces are in place. My biggest problem right now is making sure that the tools will directly support the code injection. Currently, the JavaServer Faces (JSF) tooling in Eclipse and Rational won't support the EJB3 annotations. This means that if you had to do some tricky bits of Java within your JSF, you'd have to manually mimic what the annotations do.

 

Another stumbling block is non-Web applications. While the authors of EJB3 seem to have some idea of how you can get around this by using an Application Client Container, the concept that your application has to run inside a container at all may be off-putting to some developers. However, like JSF coding, the non-Web applications seem to have some ability to get around the issue temporarily by using manual code to manage the interface to the Entity Manager. I'm just not sure how much needs to be added to a standalone Java application in order for it to take advantage of the EJB3 capabilities.

 

Which brings us back around full circle to WebSphere. Because WebSphere does have full support for EJB3, I think people will be interested in trying it out. The quicker Rational builds all the needed support into its supplemental tooling, the more rapid the uptake of the technology.

 

And once that happens and it's proven that the EJB3 concept works well in Web applications, I think you'll see both the use of EJB3 for non-Web applications as well as an acceptance of the application-container technique. And finally, at that point, we may just see the ability to start to create good business applications using Java, since EJB3 will have removed much of the plumbing from the database side of the application.

Joe Pluta

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i Developing Web 2.0 Applications with EGL for IBM i
Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform.
List Price $39.95

Now On Sale

WDSC: Step by Step WDSC: Step by Step
Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction.
List Price $74.95

Now On Sale

Eclipse: Step by Step Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: