In-Depth

Application integration enters through the front door

• By Alan Radding
• May 1, 2006

To process claims, staffers at Western Reserve Property and Casualty in Ohio, often signed onto three or four systems ranging from legacy CICS mainframe apps to Lotus Notes/Domino. Integrating those systems, interfaces, data and sign-ons is seldom easy, but Western Reserve found a shortcut through its portal.

“We couldn’t use MQ Series or any other integration middleware because our DOS-VSE mainframe didn’t run it, so we had to write our own messaging middleware and synchronization, sort of a poor man’s MQ Series,” explains Wayne Schmidt, Western Reserve’s manager of infrastructure and technology.

The development team used Java to create stateful connections to the mainframe and CICS, which enabled the team to shuttle between the portal and the back-end legacy systems. The team dropped class libraries, available through IBM’s WebSphere, into its WebSphere portal to create a transaction pipeline. Similarly, the team used CICS Web Services to access CICS transactions. All data was in standard XML. The portal was the hub around which everything revolved.

Western Reserve also gave its users role-specific functionality that was defined in the portal. “Each user gets unique functionality and navigation,” Schmidt says. His team tied the role-specific capability and single sign-on to the company’s LDAP directory, previously set up for Domino/Notes. The Domino address book became the central access control point.

Integration, of sorts
Initially, portals served as a simple front end to complicated back-end systems. The portal gave users a single, consistent interface, which made it easier to find and access information. The data is typically read-only, but some portals permitted users to change data and initiate transactions.

Along the way, orgs realized that portals could not only put a pretty face on backend systems, but also could facilitate what amounted to basic app integration. In this case, integration is defined as a way to share information from disparate, often incompatible systems.

Although it may not be true app integration—systems calling functionality and exchanging data application to application with no manual intervention—it was sufficient for many enterprises.

And, it was faster to set up than conventional EAI. Ball Memorial Hospital in Indiana, took just 6 months to set up its physicians’ portal, says Christina Fogle, manager of eSystem support. Developed using IBM’s WebSphere, the portal provides access to multiple clinical and administrative systems.

The portal approach to app integration is also cheaper than full-blown EAI, which typically requires costly middleware and a small army of consultants to create the necessary APIs, connectors and adapters, and to map data between systems. In addition, organizations still needed portals to provide a consistent user-friendly interface to the integrated systems.

Portals as fast EAI
“If you only want to look at the data and even maybe make light updates to one system, you can do it in the portal,” says Andrew Hoffman, product manager at TIBCO Software. However, “if you want to update multiple back-end systems through the portal, you will want to leverage EAI,” he says.

EAI products rely on adapters that translate requests and exchanges between the systems. Typically, each system requires an adapter, sometimes for each rev of the system. Standard connectors are available off the shelf for the most common apps and systems. With half a dozen systems, each requiring an adapter, the EAI approach can be costly, although less expensive than hand coding connections between systems.

Portals rely on technologies such as SOAP, XML, HTML, and JDBC, to access and exchange information and invoke functionality. Some portals are built on app servers to take advantage of their built-in integration capabilities. They may also revert to screen scraping and other mainframe techniques when legacy apps are involved. This is light integration, for sure, but if the back-end systems support popular protocols like XML and SOAP the resulting integration works and is considerably cheaper and faster than the EAI-based approach. Orgs mix SOAP and XML with whatever EAI they already have in whatever combination works to speed integration. See separate story, “The players behind the door.”

Doorway to SOA
Today, most portals are used for presentation-level integration of data. That means the user can view the data in a normalized context on a single screen. However, orgs can achieve deeper integration if “portals are used as a platform for SOA,” says Joseph Hilger, practice manager, Avalon Consulting in Dallas.

Hilger took this approach in Avalon’s work for a newspaper publisher. “They had an advertising system that they wanted to replace with a fully integrated system,” he explains. “It did order entry, ratings, account receivables and billing,” only it was old and not very well integrated. A new system, however, was costly.

Instead, Avalon turned to Web services through a portal to bring all the pieces together. “Instead of a Big Bang replacement, we could integrate it piece-by-piece through the portal,” Hilger says. “The advent of Web services as a way to integrate systems opens up a lot of new things for portals.”

Everyone on the same page
Intermountain Healthcare in Salt Lake City faced a different challenge. “We have an e-business group that acts as a clearinghouse for our various healthcare initiatives,” says Jeff Johnson, director of internal e-business at Intermountain.

The healthcare initiatives involve patients, enrollees, affiliated physicians, staff physicians, other employees, vendors, suppliers, trustees and brokers who sell Intermountain’s health services. “We need to make our online capabilities available to these key audiences,” Johnson explains.

He continues: “Basically we needed a strategic way to serve all these audiences in an integrated fashion, a way to ensure everyone was on the same page as an organization.” This required the organization to pull together data and functionality from multiple systems of varying types and ages and diverse, often incompatible, apps and do it quickly and easily.

Intermountain turned to the Vignette portal. “We have a lot of Web-based applications,” Johnson says. “One of the things we liked about Vignette was its support for standards, especially Java [portlet] specifications like JSR 168.”

Like Western Reserve, Intermountain relied on its existing LDAP directory as the master directory and for authentication. Personalization capabilities came built into the Vignette portal. It also took advantage of APIs provided by the app vendors, especially for Oracle apps.

Today, Intermountain Healthcare offers hundreds of reports through the portal. It creates the reports primarily in Business Objects’ Crystal Reports. Developers built three portlets to access the reports, which are stored in a single repository. What users see first is the master index of reports. From that, they can view a thumbnail of the report along with key metadata or access the actual report. Another portlet, called “My Favorite Reports,” provides the reports each user views frequently.

Standards unleash portlets
As Intermountain Healthcare discovered, the power of portals comes not from the portal itself, which at its heart is simply a GUI data collection and display mechanism, but from portlets. Portlets are Web components, much like their Java server counterparts, servlets, and, ultimately, are intended to be used with other portlets on a composite portal page.

Portlets can be difficult to write. “You can create portlets using standard Java tools,” says Bill Swatling, product manager for IBM’s WebSphere Portal, but it is not always straightforward.” IBM is adding Portlet Factory, a portlet dev tool it picked up for its Rational dev tools lineup through its acquisition of Bowstreet. Only a handful of portlet dev tools are currently available from Sun, BEA and Kapow Technologies, as well as from the open-source community.

Combining different portlets outside the portal can be tricky. The industry defines portlets through JSR 168, which states: “Portlets are invoked in the single request of a portal page. Each portlet produces a fragment of markup that is combined with the markup of other portlets, all within the portal page markup.”

Portlets are the small apps invoked from a portal page and used in conjunction with other portlets within the page to pull in and display the appropriate information. JSR 168 enables interoperability between portlets and portals by defining a set of APIs addressing aggregation, personalization, presentation and security.

JSR 168-compliant portals should be able to run any JSR 168-compliant portlet. Most major portals already support JSR 168; those that don’t most likely will on their next rev. “What JSR 168 does is foster reusability of portlets,” says Gene Phifer, VP and distinguished analyst at Gartner.

Where JSR 168 is Java-centric, another portal standard, Web Services for Remote Portlets follows the SOA approach. WSRP specifies a Web service interface for accessing and invoking interactive presentation-oriented Web services. WSRP is the product of joint efforts of the Web Services for Interactive Applications and WSRP OASIS Technical Committees.

WSRP allows for the building of portals and portlets as industry standard Web services and for the leveraging of all current and future Web services standards, including WS-Security and WS-Policy. “WSRP allows a portal to use a portlet from another portal as long as it speaks WSRP,” Phifer explains. “The newest revision, WSRP v.2 will let you link into another portal in an on-the-glass composite.”

Another version of the Java portlet standard, JSR 286, is underway. “JSR 286 really is the second version of JSR 168 and should be out in 2007,” Phifer says. JSR 286 is intended to align with J2EE 1.4, integrate other new JSRs relevant for the portlet, and, most importantly, align with the WSRP specification v.2, according to the latest spec.

Composite pages
Phifer sees orgs getting the most benefit from app integration through composite portals, which often entails a composite framework.

The composite framework provides inter-portlet communications. In this way “the organization can link together various portlets into a process, such as a call center process,” Phifer explains. The various portlets would access different back-end systems, such as a customer management system and the billing and payment system along with a built-in search engine, and pull in the specified data using a parameter-based approach.

By adding a little business process orchestration using something like Business Process Execution Language, orgs can create sophisticated composite apps, Phifer adds. These composite apps would run either on the end-user portal interface or inside the portal itself.

Composite portal pages, like composite apps in the SOA world, tap numerous portlets and portal functionality to create what amounts to complex, often individualized screens consisting of data and functionality from multiple back-end systems. “A page of portlets becomes a composite application,” IBM’s Swatling says. “It is an easy way to deliver an integrated application.”

Portals can enable composite apps and achieve app integration faster and more easily than other approaches. Orgs are turning to portals for app integration both at the presentation level and, increasingly, for deeper integration. Java and Web services standards make portal-based app integration more feasible today than ever, and SOA will give portal-based integration an even bigger boost. Although portals are unlikely to replace EAI middleware completely, it is just as likely that your next app integration effort will focus on the portal.