Are portals windows to the SOA?

Fellow ZDNet commentator Phil Wainewright (author of the recently launched Software as Services Weblog) asks an interesting question (at his LooselyCoupled.com site) pertaining to BEA's planned acquisition of portal vendor Plumtree Software.

Namely, why did BEA, which has a portal product, need another "technology stack" as part of its offerings? BEA sought better portal capabilities for its Aqualogic composite application infrastructure announcement.  Plumtree offered multi-channel and collaboration, "neither of which BEA supported terribly well; whereas these are the sweet spots of the Plumtree offering," Phil observed.

A few days ago, I had the opportunity to speak with Andrew Dunning, manager of product marketing at Plumtree, and I put the question about BEA's dual-portal line to him. Dunning pointed out (in line with Phil's observations) that Plumtree brings collaborative capabilities to the table. "BEA's full product suite is different from Plumtree," he said. "We're very much of a collaborative portal, very much focused on end-user-specific services such as collaboration, content publishing, search, and things like that. Whereas BEA's product is very much a transactional developer type of portal. You'd use Plumtree to build an intranet-style enterprise portal, you'd use BEA to build a transactional Web portal, like a banking site."

What I take away from this is Plumtree: inside and BEA: outside. Now, Dunning also made some interesting connections between the portal world and SOA as well.  This is where Plumtree is aiming.

This is a space I've been watching develop for years, especially as it relates to back-end systems access. Early on, back-end access was made possible through host emulators or Web-to-host tools, which essentially took datastreams coming off a system and presented it as HTML code within a browser, or launched through a separate applet.

The revolutionary breakthrough came earlier this decade, when products such as WRQ's Verastream offered the ability to build components on a middleware tier (Windows, Unix, Linux) that mimicked the processes running on the back-end system, which remained a secure data repository.  For example, a middleware service component at a call center could pull customer data from five mainframe systems and present it in a single interface to a customer service rep.

Middleware is where SOA as we know it today has taken root. By building and running standardized service components in an middleware layer that is accessible across the organization, SOA can begin to do the heavy lifting of the back-end systems behind it.

This all sounds great, but was a tough sell in the early days, Plumtree's Dunning admits. With Web services and SOA, "two banks' systems talking to each other wouldn't have to be based on the same software, as long as they had common services to exchange information," he points out. "The initial response was, 'yeah that sounds great, but right now all of our back systems are already talking to each other.  What is the incentive for us to actually go out and write all of these Web services?'"

The incentive for Web services and SOA comes out in two ways, Dunning says: having a consolidated user interface, and reusability. "At the front end, there's a lot of things that people working at their desks can't do, or things that they can do but take a heck of a lot of time. Users are forced to work across all these different systems in order to get a particular piece of work done."

The reuse potential of SOA is what really gets people excited, Dunning says. "If you build a composite Web app using SOA to enable the hiring process, you can soon find that all of the components you built, all of the services that you built, can be reused in other applications, like approvals, hiring and promotion activity, or grading and performance management. These applications can all leverage all the same services."