Jason Westra

Subscribe to Jason Westra: eMailAlertsEmail Alerts
Get Jason Westra via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: MultiTouch Developer Journal, Java Developer Magazine

Multi-Touch: Article

The Business Advantage of EJB: Part One

The Business Advantage of EJB: Part One

What's all this hype about portability? Portability has been a hot topic since Java's arrival just a few years ago, so I'm going to devote some space toward understanding portability issues centered around the Enterprise JavaBeans architecture and development. This month I'll discuss the various types of portability and Java's relationship to each; then I'll touch on the portability goals of the EJB specification and where EJB portability lacks maturity (and why not to worry). Next month I'll provide tips on EJB portability as well as code examples depicting how you can help achieve the promise of EJB portability through solid design and coding practices.

Competitive Advantage of Portability
Portability is a true concern in the minds of many IT executives who see the need to develop applications with faster times-to-market and across more platforms than ever before. The portability hype is fostered by the need to bring new products to market at ever-increasing rates - products that are as easily compatible with legacy systems as with Web-enabled systems. This mission is heavily reliant on the interoperability of software across a number of areas, including platform/operating systems, resources such as databases and transaction management services, and multiple development languages/component models - most recently, Enterprise JavaBeans components.

Types of Portability
As previously mentioned, there are different types of portability. Applications that are portable across these areas can be quickly modified to meet changes in your business or technology and will be more easily maintainable than nonportable, "stovepipe" applications. For instance, rather than making upgrades to multiple versions of an application for each specific platform, one upgrade is made to one application.

Depending on the focus of your software, you may worry about one or two types of portability while shifting the burden of the others to a middleware provider. Let's take a look at each type of portability and understand which ones will directly impact a Java/EJB developer.

Platform Portability
There's a real need to have operating system portability. The World Wide Web had a profound impact on the need for cross-platform (OS) software because you couldn't tell what platform an Internet user was surfing on. Java combated this problem by providing OS portability via the Java Virtual Machine, which translates operations into the correct OS platform's API. This common concept is called wrappering.

Before I started a career in software development, I thought a wrapper was simply packaging for my chewing gum; however, wrappers have revolutionized more than the candy industry. They're a prime enabler for the interoperability of heterogeneous components in the software industry. Interoperability through a wrapper or "adapter" design pattern is achieved by providing an acceptable interface that a client component expects and can communicate with effectively (see Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al.). Thus an existing component with an incompatible interface may be called by other software via a wrapper, achieving the reuse we've come to expect in component-based development. An example we should all be familiar with: a JVM wraps multiple operating systems in an acceptable common interface, obviating the need for developers to build multiple OS-specific versions of their software for each platform.

The key point introduced here, and one I'll refer to often: the wrapper design pattern is important to software portability (not just a convenient place to put old chewing gum).

Resource Portability
A flexible application is built with an awareness of resource portability. Examples of resources might include transaction management services, naming services, communication protocols or a database management system. For instance, a commercial product built to access a storage resource such as a database should remain as neutral as possible with regard to its persistence mechanisms.

Designing flexibility into this product might include providing a layer of insulation between your business objects and how they're stored. This will allow your customers to decide which database they wish to use with minimal impact to your product. With so many types of storage mechanisms, including RDMSs, object-relational databases, embedded databases and pure ODBMSs, you have to take database portability seriously.

Java provides some degree of insulation against platform-specific database code through its JDBC API. However, JDBC is flexible and powerful enough to allow vendor-specific code to be written through its database metadata features. You still have to use sound design patterns and wrappering techniques to ensure minimal impact when changing storage schemas. As we'll see, EJB specification 1.0 provides further guidance on resource portability.

Language/Component Model Portability
Language portability is the ability to support multiple development languages. This form of portability is provided to the development community through two widely regarded standards: Common Object Request Broker Architecture and Component Object Model. CORBA and COM allow components coded in multiple languages to communicate with each other through an interface definition language. IDL provides mappings between disparate languages such as C, C++, Java, Visual Basic (VB) and even COBOL. These unique languages are wrapped (once again, that valuable wrapper pattern) in recognizable, acceptable interfaces that foster reuse not only of business logic but also of human resources by way of current IT staff. For instance, language portability means you can use an existing COBOL or VB programmer to code a piece of functionality for your application that can be wrapped to look like a CORBA component. As you can see, portability allows quicker time-to-market for your products through the reuse of existing assets, even human assets.

Java provides platform portability, but you're tied to one language, Java. While CORBA and COM alleviate this single-language portability issue, they're still quite different from one another. CORBA objects may be deployed on any platform, while COM components are currently tied to the Windows operating system. Thus CORBA and COM have potentially different markets. While CORBA fits well in heterogeneous environments, COM is ideal for pure Microsoft shops. The EJB specification seriously addresses component model interoperability with CORBA; however, it leaves COM integration up to the EJB server vendor's imagination.

Enterprise JavaBeans Portability
One of the primary goals of Enterprise JavaBeans is to provide a component model for building portable server-side components that addresses Java's lack of language portability and more. For the remainder of this article I'll focus on how the EJB specification lays the groundwork for Java's portable, server-side component model.

Portability Goals in the EJB Specification
"Enterprise JavaBeans will make it easy to write applications: application developers will not have to understand low-level transaction and state management details; multi-threading; resource pooling; and other complex low-level APIs...." ---EJB specification 1.0, section 2.1: Overall Goals

Though not stated explicitly, the net result of this goal is the promise of interoperability between third-party EJB vendor products. This goal implicitly introduces the notion of a component execution environment, the central ingredient in providing EJB portability. In my first "EJB Home" column I described this concept briefly, but I'll review it again as a refresher.

A component execution environment typically consists of an EJB server and one or more EJB containers (see Figure 1). While JavaBean client components typically run within a visual container, EJBs execute within server-side containers. The container shelters your EJB component from its runtime platform by managing all of its interactions with the operating system. Together, an EJB server and its containers provide your components with access to distributed runtime services such as state management, distributed transaction management, multithreading and resource pooling, as stated above.

The Enterprise JavaBeans specification provides guidelines to encourage EJB server and container providers to build their products in a portable manner (see section 17 of specification). Figure 1 shows how an EJB server is making use of a third-party EJB container. Because the third-party container was built according to the EJB specification, it's portable to any EJB server and runs seamlessly within this component execution environment. EJB's component execution model is a prime example of how portability cuts time-to-market for products. An EJB server provider lacking skills in certain areas, such as object databases, could license a third-party EJB container that maps entity beans to an object database and viola! - it's in the EJB server business!

"Enterprise JavaBeans applications will follow the 'write-once, run anywhere' philosophy of the Java programming language. An enterprise bean can be developed once, and then deployed on multiple platforms without recompilation or source code modification." ---EJB specification 1.0, section 2.1: Overall Goals

This EJB portability goal is easy! It simply reiterates Java's approach to providing OS portability from the standpoint of EJB. The very nature of EJB means it should run on any Java-compatible platform via the JVM. The benefit of "write-once, run anywhere" on the server is the ability to easily scale your application from a lowly workstation to a high-end enterprise server as volume demands. Compare that to the time it would take to rewrite a nonportable application from one server platform to another! By the time you finished, your dissatisfied customers would have given their business to a company that could meet their business needs sooner.

"The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime." --EJB specification 1.0, section 2.1: Overall Goals

EJB specification 1.0 defines two types of contracts: between enterprise beans and their client and between enterprise beans and their containers. The enterprise bean-client contract ensures that the enterprise bean provider (e.g., enterprise bean developer) and container provider must collaborate to offer unique object identity, method invocation capabilities and an EJB home (e.g., factory interface and class). In a perfect world upholding this contract provides client-side portability with respect to various EJB server vendors.

A second component contract is defined between the enterprise bean and its container. By upholding this contract, an enterprise bean will be deployable within multiple vendors' tools, and will be able to use the runtime services of any vendor's EJB server. This lists a number of services, such as lifecycle management, that the container must offer an enterprise bean, as well as the interfaces that allow the container to manage the bean in a component execution environment.

"The Enterprise JavaBeans architecture will provide interoperability between enterprise Beans and non-Java programming language applications. The Enterprise JavaBeans architecture will be compatible with CORBA." ---EJB specification 1.0, section 2.1: Overall Goals

Portability across multiple languages is important in developing software applications. The creators of the EJB specification, understanding the importance of portability, defined the Enterprise JavaBeans component model to allow for the interoperability with other component models such as COM/DCOM (Distributed COM) and CORBA. A separate specification describes the mapping of EJB to CORBA. It is available for download at www.javasoft.com/products/ejb/docs.html.

The implementation of component model portability in EJB is vendor specific. An example implementation might have a COM or CORBA component "wrapped" in an EJB container, providing a client with EJB interfaces just like a normal enterprise bean (see Figure 2). You can see the business advantage of EJB's component model portability - existing and new business logic written in other component models will be reusable from your EJB application.

EJB Portability: Myth or Reality?
While the EJB specification 1.0/1 has laid the foundation for building portable enterprise beans, there is much left to be specified before true interoperability will be a reality. The EJB specification is vague in a number of areas important to EJB portability, including a container provider's responsibilities, multiple-vendor EJB server integration, CORBA and EJB security models, distributed/asynchronous event notification and mappings for COM integration. Without addressing these areas in future drafts of the EJB specification, EJB portability will be compromised. Am I worried? No. Fortunately, JavaSoft and a contingent of EJB proponents are working on these issues as I write.

Portability offers tremendous business advantages by enabling quicker time-to-market for new products that don't need to be rewritten for each platform in question. Portability also reduces maintenance costs of your applications and promotes reuse across disparate technologies, allowing you to use existing hardware, business logic and even software development talent.

Enterprise JavaBeans will soon be trusted to help build portable, server-side components and applications, providing the business advantage IT managers seek. The EJB specification addresses key issues around the integration of disparate component models and portability between multiple EJB vendors, providing early EJB adopters with a competitive advantage in the marketplace. Furthermore, EJB vendors are offering increasingly powerful tools to build EJB applications.

However, even though the recently released EJB specification 1.1 addressed issues around entity bean compatibility (i.e., entity beans are now mandatory), there is still much to be fulfilled concerning EJB's portability promise. It is lacking in critical areas, including security, system management and EJB server compatibility. While the specification defines the need for compatibility on numerous fronts, it doesn't qualify the means to this end. As vendors pump out new EJB products, how can you be sure of the portability promised by the specification?

In Part 2 I'll cover tricks, traps and techniques in designing and coding portable Enterprise JavaBeans. Expanding on what you've learned in this article, the code examples in Part 2 will give you an understanding of how to apply the wrapper design pattern to your development repetoire to ensure EJB portability. Until next time....

More Stories By Jason Westra

Jason Westra is the CTO of Verge Technologies Group, Inc. (www.vergecorp.com). Verge is a Boulder, CO based firm specializing in eBusiness solutions with Enterprise JavaBeans.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.