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

The End of Middleware
by Jonathan Schwartz Executive Vice President, Software Group, Sun Microsystems

The marketplace tells you that "middleware is everywhere" when all along it should wise up and recognize that "middleware is dead." Because that's the new reality of enterprise computing today, according to Sun's software czar Jonathan Schwartz.

What's more important: Running your business or integrating middleware?

Should be an obvious answer, right?

Then why is the marketplace spending so much energy wallowing in the history of "middleware is everywhere"? Habit. A habit to which thousands of IT professionals devote their lives. But integrating middleware to build one-off business systems is about to perish with the rise of shared services - the services you'd like to build once, then execute on behalf of all your business systems.

As an example, when's the last time you hired someone? Remember what it was like getting them "badged" and into the company? You had to grant them access to payroll, benefits, a desktop login, e-mail, the CRM, and forecasting systems, then assign them an office and a phone.

Most likely, your company built a unique provisioning mechanism for each of the systems I just cited. One for HR, one for the sales force, one for information security, and yet another for physical security. And then you likely created even more redundancy by building one set for your intranet employees and another for your Internet customer or supplier systems. That's inefficient, and in the world of Sarbanes-Oxley, a real problem - who has access to what? And why did you build 17 different systems?

Because it looked like a good idea at the time.

The same is true for most services that now make far more sense in a shared environment, from portals (how many does your company have?), to e-mail and application services, down to clustering and Web servers. There's no real utility in having multiples of these services, as Nicholas Carr would point out, where your implementation doesn't generate a competitive advantage. How you authenticate users and provision them with access to your systems is an unlikely competitive advantage. So why build a one-off solution instead of relying on an integrated system?

Good question.

Our belief is that the vast majority of Web services are better run as shared services. What's the holdup, then? When we looked into this a year ago, we found three challenges:

1.  Roadmap sprawl
There's no coordinating force causing all the required elements of shared services (from authentication to portals, Web services to clustering) to coalesce around a common release, interoperability, or support matrix. So you have no choice but to build your own.

2.  Pricing
Middleware pricing is anything but shared - per CPU, per identity, per mailbox, per portal, per cluster node - pricing opacity obscures the real savings in running shared services. And if you can figure it out, you probably can't afford them.

3.  Licensing
The industry relies on "common access licenses," often tripling prices for services that touch the Internet - that's clearly an obstacle to shared services.

So here's how we solved the problems:

1.  The rise of Sun's Java Enterprise System
Sun's Java Enterprise System offers all the basic components, from directory and identity management to Web services, even e-mail and clustering. All in a single deliverable, prequalified, tested, and supported on multiple platforms.

2.  Pricing goes to a $100/employee subscription
Why buy software differently than how you buy office furniture - by the employee? If your workforce decreases, you pay less, and vice versa. The ultimate in predictable, transparent pricing.

3.  Licensing - infinite RTU
If the distinction between the intranet and extranet is disappearing, so should the distinction in our licensing. So $100/employee buys you the right to use (RTU) all these services on all systems. At infinite scale - once you've paid for your employees, your customers are free. Free. It's your software.

The vendors who believe hardware is commoditizing suggest the same forces won't affect software. We believe it affects both.

And as the world moves to recognize the value of a shared services infrastructure, it's our belief that middleware is history. Long live the system. The Java Enterprise System.

Author Bio
As executive vice president of Sun's Software Group, Jonathan Schwartz spearheads the company's unified software business and focus and leads one of the largest software organizations in the industry. His market-leading group is responsible for the Solaris Operating System, defined by Sun as "the most secure, most scalable, most reliable operating environment on the planet"; the Java platform, which Schwartz and his team call "the gold standard for compatibility and security from the cellphone to the desktop to the datacenter"; a complete portfolio of highly integrated, highly affordable, interoperable, end-to-end software for every environment; the N1 operator platform ("for dynamic and utility computing"); developer tools; and Sun's entire family of middleware and software solutions. This essay was written exclusively for JDJ.

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.