CHANNELS
HOME
TOP STORIES
COLUMNS
OPINIONS
ZEICHICK'S TAKE
EMBEDDED NEWS
TEST & QA REPORT
ECLIPSESOURCE
SPECIAL REPORTS
SD TIMES 100
JOB BOARD
EVENTS CALENDAR
RESOURCE CENTER
WEBINAR CENTER
ADVANCED SEARCH
RSS
ON THE WEB
SITE MAP
ADVERTISE
EDITORIAL
PRIVACY POLICY
CONTACT US
REPORT A BUG
PRINT EDITION
SUBSCRIBE NOW!
CURRENT ISSUE
BACK ISSUES
SUBSCRIBER SERVICES
BZ MEDIA
ABOUT US
NEWS
BZ RESEARCH
SYSMANNEWS
ST&P MAGAZINE
STPCON
ECLIPSEWORLD
ADVERTISER LINKS
activePDF
Alexsys
Altova
Amyuni Technologies
Automated QA
Axosoft
Business Objects
Codejock Software
ComponentOne
Coverity
Data Dynamics
Developer Express
dtSearch
Dundas
Dynamsoft
Hewlett-Packard
IBM
Imagix
Infragistics
InstallAware Software
InterSystems
iWay
Kovair
LEAD Technologies
McObject
Microsoft
MKS
No Magic
nsoftware
Parasoft
Pegasus Imaging Corp
Perforce
Prezza Technologies
Programmer's Paradise
Programming Research
Rally Software Dev
Red Gate Software
ScaleOut
Seapine
Serena
Software FX
Sparx Systems
Swell Software
Syncfusion
TechExcel
Telerik
UrbanCode
WANdisco
Xceed Software
LOADING...
LOADING...
AS OF 8/21/2008 7:26PM EST
Middleware 2.0
By
John Crupi
November 1, 2006 —
Most of us are getting tired of seeing “2.0” added to just about everything these days, but sometimes it’s the best way to describe the next wave. That’s why I’ll use it here to describe what’s coming for middleware. Don’t get me wrong: I know how valuable middleware is, and it will surely be around for a very long time. But I really do think traditional middleware is in trouble. More specifically, traditional middleware is not meeting the needs of forward-thinking enterprises that are Web-enabling their business applications.
A DEPOSED KING
Middleware used to be king, but it is now being relegated to lower-level tasks. The capabilities of traditional middleware just aren’t enough for Web-based computing. The next generation of Web computing needs new capabilities, and this is causing a radical shift in what we think of traditional middleware.
A few years back, Sun Microsystems’ Jonathan Schwartz famously said, “Middleware is dead.” The industry shrugged off his comments, and IBM’s response was to place “Middleware is here” billboards at strategic spots all along California’s US-101 highway in Silicon Valley. The reality today is that middleware is not dead—far from it. However, it is being pushed aside, or in this case pushed down. Let me explain.
Consider this analogy: Java was not originally intended for enterprise computing. Instead, it was designed as a client-side programming language. I was at Sun when J2EE made its debut. We were pleasantly surprised (shocked, really) when customers accepted J2EE and decided to move their business-critical applications to J2EE. Why did this happen? Why did enterprises entrust their business to such a new and unproven technology?
It had to do a lot with the amount of pain it reduced. Specifically, J2EE reduced the amount of middleware developers had to write and let them focus more on writing business applications. The J2EE application servers now handled all the chores of memory and life-cycle management. J2EE became a commoditized part of the Web middleware platform and made a lot of money for many people.
Here we are 10 years later, and a new phase is upon us. We’ve been talking about service-oriented architecture for years, though not necessarily with the SOA acronym, but the concept is making a resurgence and is getting much more press lately. Why? Because of AJAX.
It may seem odd that a RIA/browser-based technology has impact on a server-based technology such as SOA. But in fact it’s true, and here’s why. SOA has arguably done well in the enterprise integration space. Since SOA is an integration architectural style, it made sense to apply it to enterprise integration to ease the architectural costs and complexities of proprietary and peer-to-peer integration.
But now, SOA is increasingly being viewed as a service provider for Web-based applications. AJAX, which enhances the user experience, is driving the desire to connect Web applications with SOA services.
So what does this have to do with the trouble facing traditional middleware? Enterprise IT departments aren’t complaining about their middleware not being good enough (well maybe they are, but not in the context of this article). What is happening is that we’re seeing an end-around by the portal replacements.
TRADITIONAL PORTALS UNDER SIEGE
But there’s a catch: There’s no portal server! That’s right—traditional portals and portal vendors are being threatened by “portal-less portals.” It usually doesn’t happen this way. Players in a new category generally start eating away at an incumbent, and then it’s too late. But, in this case, AJAX isn’t even a category—it’s simply a set of technologies.
Meanwhile, companies are starting to make it easy to create consumer portals using AJAX, and at the same time these new portals provide more flexible user interactions and a better user experience. We’re enjoying all the stuff we had with traditional portals and much more, and we’re getting it without the heavy burden of all that portal software.
The interesting part of this new-portal-replacing-old-portal play is that we probably shouldn’t even call it a “new” portal. It’s actually something very different, especially in the enterprise.
Corporate portals have a whole set of constraints that consumer portals don’t. And as a matter of fact, most portal vendors don’t sell to consumer-facing providers; they sell to enterprises. Corporate portals also don’t have the luxury of interfacing with “clean” data sources like RSS, public Web sites, public blogs, etc. Instead, they have to integrate with all the stuff behind the corporate firewall that’s been around for years or even decades. That’s why a very large integration effort is usually required to get even a corporate portal up and running. Not only that, corporate portals attempt to serve as the “face” to all corporate information. As you can imagine, it is probably more information than you’d ever want or use.
The future so-called portal won’t even look like a portal initially. When a user first logs into a corporate portal, it should be empty. Yep, that’s right—just a blank page with only an “Add Content” button. That’s because it won’t be a portal anymore. It will be the user’s workspace and will be activity-driven, allowing the user to add and run any application that has been exposed and governed by IT. This actually has bigger implications, in that future business applications will be much smaller and driven by business activity. This is much more aligned with how a user works, and much less aligned with how we develop business applications today. Instead of applications getting larger, IT will begin making applications activity-granular (smaller) and design them for integration with other applications on demand.
NEW CATEGORY OF MIDDLEWARE
Of course, this won’t happen magically; it will require a new set of middleware capabilities. Either traditional middleware provides these capabilities or a new category of middleware steps in to do so. Simply put, there are three key service capabilities required: service consumer governance, business activity integration and reliable Web connectivity. Service consumer governance is responsible for governing the exposure of existing services to the application. Don’t confuse this with service implementation governance. The former focuses on governing access to the services, not governing the actual services. Business activity integration provides support for activity-driven mash-ups.
Most talk of mash-ups is about data. But users really require integrated data based on what they’re doing, such as searching, communicating or interacting with an application. Finally, reliable Web connectivity ensures that applications run over the Web in a secure and reliable way. Consumer applications can usually tolerate the unreliable nature of Web connectivity, but business applications must meet higher standards. Reliable Web connectivity leverages the ubiquity of the Web while enabling the connectivity required by businesses.
Taken together, these capabilities will enable the integration of AJAX and SOA to create a whole new class of enterprise applications. Optimally, they will be lightweight, based on open standards, and agnostic to any particular middleware vendor. They don’t replace traditional middleware, but rather run on top of it.
Still, I think there is a strong possibility that these three capabilities will be “just enough” for the next generation of Web applications and will disrupt traditional middleware. That may take a while. But then again, with the speed of change in everything today, it may not. I can’t wait for that to happen.
John Crupi is CTO of JackBe, which sells AJAX solutions for SOA.
EMAIL THIS ARTICLE
SEND FEEDBACK
MORE COLUMNS
 
SUBSCRIBE TODAY!
E-Newsletters:
News on Mon/Thurs.
Test & QA Report
EclipseSource
SUBMIT
 
JOB BOARD
PDF & PRINT EDITION
* Requires Resource Account! 
LOGIN
or
SIGN UP
*
Download Current Issue!
ISSUE 8/15/2008 PDF
*
Need Back Issues?
DOWNLOAD HERE
Receive The Print Edition?
SUBSCRIBE HERE
 
EVENTS CALENDAR
Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software
VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media
Interop New York
9/15/2008 to 9/19/2008
New York
TechWeb
VMworld 2008
9/15/2008 to 9/18/2008
Las Vegas
VMware
Mobile Business Expo
9/16/2008 to 9/19/2008
New York City
TechWeb
REGISTER
MORE EVENTS
GET NOTIFIED!
About all of the latest Resources
SD TIMES 100
6th Annual SD Times 100
It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.