HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

I was asked to stick my neck out and write on the future of Enterprise JavaBeans in year 2000. Just so you know, I was one credit away from a minor in the classics (you know, Greek mythology, ancient Rome and Egypt). However, since I didn't major in this field, nor even minor in it, don't hold me to anything I say for I'm no Oracle at Delphi. I'm just a soothsayer from Boulder, Colorado, and even then I'm only one of many (though most in Boulder foretell fortunes based on constellations, tarot cards or your sign!).

This month I'll give you my gut feelings on what's in store for EJB next year. I hope to enlighten you, but suspect that anyone following the EJB rage over the past year or so has come up with some of the same conclusions.

Y1999 - Where Are We Coming From?
To know where we're going, we need to take a look at where we're coming from. So let's gaze into the past year or so to understand how EJB got to where it is today.

I consider (and I'm not alone) 1999 the year of the application server boom. There were three key catalysts driving this movement: Microsoft's component model COM/DCOM (including COM+) matured, XML's importance for EAI increased and, most of all, Enterprise JavaBeans became the server-side component model of choice for Java developers worldwide. In 1999 it seemed as though any company that had ever done server-side Java in the past became an application server vendor offering an EJB solution.

To my way of thinking, no other technology has influenced the application server boom as much as EJB. The enormous interest derives from the fact that its component model shelters developers from the need to develop low-level services such as distributed object communication and location, transaction support, resource and thread allocation, and even persistence of enterprise beans. In addition, EJB developers work with a fun, portable platform and focus on the business logic of their applications, thereby increasing time-to-market of their products.

In 1999 we saw numerous EJB products released, including EJB servers of varying degrees, third-party EJB containers, and code generators and deployers bundled with various component modeling tools and Java IDEs. With this exciting support for EJB in 1999, it looks as though EJB is on the verge of greatness in year 2000.

Y2000 - Where Are We Going?
EJB is maturing at a rate faster than anyone could have guessed...or hoped for. This pace of growth influences my belief that in year 2000 the following will occur:

  • The flooding of the EJB server market will subside, leaving a few dominant players controlling a large portion of the market.
  • The market for reusable third-party components will be realized (but not fully).
  • The server-side component model wars that began in 1998 and increased in 1999 will escalate to a point at which there may be a declared winner.
  • An increase in demand for Enterprise JavaBeans technology will cause a shortage of EJB talent, fostering a demand for training and skills in distributed computing.
Market Share of EJB Servers
When JDJ editor-in-chief Sean Rhody last counted, 28 companies with application servers were offering EJB support (thanks for the legwork, Sean!). Depending on when Sean counted his beans, this number is perhaps one less: Forte Software, Inc., recently merged with Sun Microsystems. The merger is an example of times to come as more and more small fish in the EJB server sea consolidate with larger, established companies. While the number of EJB servers may continue to increase in the year 2000, I believe that 80% of the market for EJB servers will be controlled by BEA Systems, Inc., IBM, Oracle and Sun Microsystems (the Big 4).

I don't think that all 28 vendors offering EJB support are really battling for a share of the EJB server market. Rather, they include EJB support as a necessary feature to sell their application server, which really may have been built to solve other problems, such as data integration EAI and dynamic Web content management. For example, Novera Software, which used to call its flagship product the Novera jBusiness Application Server, changed its name to the Novera Integration Server. While datasheets mention its EJB support, the NIS is really marketed for its ability to tie disparate data sources together in a unified business component view - not its EJB prowess.

In 2000 those companies that are really battling for a portion of EJB's lucrative server business will gain market share based on three criteria: current market position, technology/implementation beyond J2EE, and runtime monitoring and deployment facilities. Each is discussed in depth below.

1. Current Market Position
The Big 4 win here. As previously stated, the big fish of the EJB server market that I'm referring to are BEA, IBM, Oracle and Sun. These firms hold a major portion of the market now, and will increase their market share through reputation and sales of existing products, or through an acquisition/merger situation with companies offering similar products (e.g., BEA Systems' purchase of WebLogic and Forte's merger with Sun). As a longtime Forteuser, I'm glad to see such exposure for its technology and I believe it will become a key part of Sun's EJB solution offering.

To demonstrate how powerful current market position is in winning the battle for EJB server market share, let's take a look at Oracle Corporation and why I believe it will prosper as a member of the Big 4.

I assume Oracle's server-side Java strategy is to put an EJB server in every Oracle database on the planet. Considering it holds the largest market share of enterprise databases in the world, Oracle could soon dominate the market in EJB servers as well. Not convinced? This strategy is nothing new and may be termed gorilla marketing, a tactic that has made more than one technology company an industry maker. Take Microsoft, for example. It gained major headway in the browser wars by including its Internet Explorer browser free on every PC.

2. Technology/Implementation Beyond J2EE
EJB servers and tools have matured at a rapid rate. All provide the basics such as database connectivity, naming and directory services, life-cycle management and transaction management. These services are being bundled into the Java 2 Enterprise Edition, and, as you may know, EJB is the foundation upon which J2EE is built.

J2EE compliance is a must for any application server serious about competing as an enterprise Java server. Thus, winning market share will be governed by a vendor's offerings in the areas of performance and scalability. The pressure is on for EJB servers to provide load balancing and fault tolerance through clustering or replication of components.

Even then, I don't believe a highly scalable clustering architecture alone will be enough for an application server to dominate the market. The application server must also provide an environment that is easy to develop enterprise beans against and one that makes deploying these components easy. This leads to the last of my three criteria for a successful EJB server in the coming year.

3. Runtime Monitoring and Deployment Facilities
The ability to manage increasingly complex deployment configurations will be a deciding factor in sales of application servers in the year to come. Successful EJB vendors will have to provide rich runtime monitoring tools that are extensible, allowing you to customize them to your application's needs.

For instance, system administrators need the ability to create custom system agents that track user-defined statistics in a graphical console environment. Runtime monitoring capabilities will need to allow system administrators to chart activity, start and stop distributed components, roll new versions of enterprise beans into active servers without downtime, and even add or remove servers from a cluster as performance dictates.

Agents should also be autonomous, acting on system variables automatically for the system administrator. Last, seamlessly tying an EJB server's monitoring capabilities into other enterprise management systems such as Tivoli will be a value-add feature that will set an EJB server apart from the pack in Y2K.

Besides rich runtime monitoring capabilities, I believe EJB servers that demand developers to hand-build UNIX scripts or .bat files for deployment will need to advance their application management and deployment facilities to sucessfully compete in the EJB server race next year. Products with intuitive, graphical deployment environments will be the rage in the year to come as more and more nontechnical Java developers become Enterprise JavaBeans developers and deployers. A graphical deployment environment for components is a strong suit of Forte's SynerJ Application Server and Deployer product lines.

Like the Java platform itself, Enterprise JavaBeans is an expansive playing field with marketable opportunities in servers, containers, code generators, deployers, third-party components and training. Let's take a gander at how a few of these markets will evolve in the year 2000.

Business Components on the Rise in Y2K
My background is a mixture of consulting and product development. For three and a half years before I joined Verge, I worked for the CSC Lynx Group, a product development organization within CSC Consulting. The business model for the CSC Lynx Group was to produce component-based frameworks for distributed, high-volume systems that the consulting arm of the organization would use to rapidly implement business solutions.

The CSC Lynx Group was always ahead of its time, implementing into its frameworks core services such as load-balancing algorithms and custom fault tolerance that weren't provided by the distributed software environments or middleware solutions available then. These services were needed in our frameworks to provide reliability and scalability, and to support heavy transaction volumes. While the frameworks were implemented with various technologies, when it came time to do the same with Java in 1998, EJB seemed to offer most of the value-add that our frameworks had provided in the past. The core services we were used to building were already handled by the EJB server. Finally, the group was able to "get down to business" and provide real value to clients by developing pure business solutions!

I think next year we'll hear much less talk about "distributed frameworks" and more about developing interoperable business components. This includes third-party business components built for a variety of e-business markets such as online banking and securities trading. Companies are already providing business components to rapidly develop EJB solutions. A few to put on your radar screen are The Theory Center (www.theorycenter.com) and, of course, IBM's San Francisco. More names of companies and their components will be added to this list in Y2K.

The demand for third-party components will increase in 2000, and more companies will enter this market as component providers. However, I'm not convinced that these components will truly be considered off-the-shelf software. Business components, no matter what their implementation, are complex to configure and customize without proper guidance. Consulting and professional services groups from the component suppliers will need to provide their expertise to properly configure and deploy their EJBs at your organization.

As server-side business components become more commonplace, perhaps in a few more years, you'll be able to buy a business component at the local software store and install it yourself - but not next year.

Off-the-shelf components aren't a new concept. In fact, a war around client-side components began when the JavaBeans specification was released. JavaBeans became a true contender for Microsoft's dominance of the market with its OCX and ActiveX technologies. Now the war has moved to a new front. It's moved to the server where I predict the war for server-side components will peak in year 2000.

Server-Side Component Model War Escalates
Y2K will be the year that makes or breaks Enterprise JavaBeans as the server-side component model of choice for corporate developers. I believe there are two competitors in this war: DCOM and EJB. I don't see CORBA as a solution for new component development, but rather a way to integrate legacy code into new solutions built around EJB.

I admit I have some reservations about EJB's ability to win the war against Microsoft's COM/DCOM solution. COM offers much of the same functionality as EJB around component-based development, and COM+ includes features such as component replication - and load balancing to provide fault tolerance - allowing Microsoft solutions to scale to an enterprise level. The caveat remains concerning the ability of COM to operate on multiple platforms, which has already been done on Solaris and will soon be done on other UNIX platforms. Regardless of COM's strides in platform portability, it's unrealistic to deploy a COM-based application into production on anything but Windows 95 or NT.

In the end, the server-side component model war won't be measured by the component model with the superior technology that each camp will always claim ownership of. Many top-notch technologies have come and gone with less success than they deserved, considering the competition - the Macintosh, for instance.

Tangible evidence, such as the number of trained professionals and the number of successful business applications in production will be the true indication of a winner in the server component war. That said, I stress the importance of EJB training in year 2000.

Train the Troops
I foresee many doomed EJB projects in the coming year, and not because the technology and tools weren't powerful enough or mature enough. Actually, I suspect that most failed EJB projects will result from a lack of EJB talent (and distributed computing experience in general). Next year, IT managers and developers alike will embrace Enterprise JavaBeans by the hoards for its ease of use and component-based development. A rude awakening awaits anyone who believes distributed components are easy! Often, the blame for missed deadlines or failed projects is placed on the technology rather than on the lack of training or experience in it. Also, remember that training can't sufficiently provide what years of experience building distributed systems can; thus training from vendors on their EJB products may provide a false sense of security. Before starting your first EJB project next year, train your troops and hire experienced developers!

Conclusion
I look forward to seeing the impact EJB will have on organizations and software development as a whole in the year to come. EJB will continue to revolutionize enterprise development, either by itself or alongside other technologies such as XML and CORBA. I leave with one last expectation about EJB in year 2000.... While the Oracle at Boulder may be wrong on all counts above, I am sure of one thing: Microsoft will not embrace EJB as a server-side component model. The war will wage on. Mark my words.

Author Bio
Jason Westra is a managing partner with Verge Technologies Group, Inc., a Java consulting firm specializing in JavaBeans solutions.
He can be reached at: [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.