. 73
( 87 .)


future versions will provide the following support:
Complete implementation of JSR 168
More comprehensive implementation of the OASIS WSRP
Use of UDDI for discovering WSRP services
Better tools in addition to the XML interface including
administration portlets for WSRP con¬guration

UDDI and tModelKeys
Now that you understand how Web services are used from within a portal
in both a pure Web service scenario as well as in a WSRP scenario, it is time
to merge all of these concepts. We mentioned that WSRP is a standard that
is layered on top of the core WSRP layers (SOAP, WSDL, and UDDI). This
means that all producers of WSRP services use the core Web service layers
and that consumers create report portlets by using core UDDI and WSDL
features. The key to all this is the tModel.
UDDI allows you to describe Web service not only in business and service
terms but also in technical terms. The tModel structure provides the ability
to describe the speci¬cation to which the Web service adheres to including
a description of how the service behaves, what conventions it follows, and
what standards the service is compliant with. The tModel represents a set of
technical speci¬cations including wire protocols, interchange formats, and
sequencing rules.
The tModel is the part of the UDDI framework that allows decoupled
software components that need to communicate with each other to adhere
to a preagreed speci¬cation. Such speci¬cations are not dependent on a
particular Web service (in fact, it is the other way around). The designers of
such speci¬cations can establish a unique technical identity with a UDDI
registry, which can then be used by multiple service publications. Each
one is registered with the UDDI registry while referencing the appropriate
tModel identi¬er (tModelKey).
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WebSphere Portal Support for Web Services and Remote Portlets 437

This is also true for WSRP and report portlet support within WP. A special
tModel de¬nes the technical structure for any Web service that is used as
a remote portlet, allowing WP to generate the appropriate portlet proxy
based on this speci¬cation.

Web services are becoming the mainstream in terms of system integration.
Given that portals are often the main integration platform, you need to be
able to use Web services from within your portal. This includes both core
Web service integration and WSRP-based integration. Initially, you are more
likely to use low-level Web services given that WSRP is still in its infancy.
However, WSRP has the bene¬t that it allows you to reuse a complete
function including the presentation layer, as opposed to using just a remote
function. While the usage of core of both types of Web services is the same,
the mechanics within WP are different. In this chapter we showed you how
to perform development and setup in both cases so that you are prepared
for all types of Web service integrations.
In the next chapter we will tackle the broader issue of integration. We
will show you the various methods and tools that you have at your dis-
posal when integrating applications and content to be delivered through
WP. Because portals are becoming the “uber-application” for most organi-
zations, application integration is certainly one of the most important topics
you will come across when using WP.
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53


Integrating External
Applications with
WebSphere Portal

In this chapter you will learn about the various options you have for inte-
grating external applications using a WebSphere Portal infrastructure. We
will describe a number of approaches to achieve such integration and for
each one provide you with enough tools to start doing some of the integra-
tion work. We will try to keep the discussion at a generic level that is true
to all such applications including integration of custom-built and home-
grown applications as well as commercial off-the-shelf (COTS) application
suites. Because custom applications will involve custom APIs and integra-
tion, our examples will focus on integrating packaged business applications
such as SAP, PeopleSoft, Siebel, J.D. Edwards, Oracle, and so on.

Why Discuss Integration?
Portals are about integration. A portal is really just an integrator and an
aggregator of information and applications. In an enterprise environment,
portals are quickly becoming the new “corporate desktop” through which
functions related to human resources applications, ¬nance applications,
and corporate communications are delivered to all employees. As another
example, consumer portals try to be a one-stop-shop for all activities and
offer links to many other applications, Web sites, and easy-to-use search
Figure 23-1 is a conceptual depiction of what portals try to accomplish.
Some people call this aggregation and others call this uni¬cation”but what-
ever your preference, it is really all about integration of other applications,
systems, data stores, and so on. Without robust integration capabilities, a

WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53

440 Chapter 23

Figure 23-1 Integrated applications delivered through the portal.

portal is just an empty shell that allows you to manage a Web user interface.
With many applications integrated into the portal infrastructure, the portal
becomes the application delivery platform. To exemplify this further, the
personalization features of WP would be meaningless without integrated
environments. What exactly would you personalize?
Portals deliver Web-based content to a user. Applications generate con-
tent that needs to be used by users. Therefore, any portal platform needs
to provide good integration tools for allowing you to expose application
content through your portal. This is why integration is such a crucial topic
for any portal platform and why we devote this chapter to an overview
of WebSphere™s (and speci¬cally, WP™s) integration capabilities. We should
mention that integration, and WebSphere integration speci¬cally, is a very
broad topic”one on which numerous books can be (and have been) writ-
ten (for an excellent reference see Enterprise Integration: An Architecture for
Enterprise Application and Systems Integration by Fred Cummins). Therefore,
we do not provide a comprehensive discussion on integration within Web-
Sphere. Instead, we focus on what kind of integration approaches you can
use speci¬cally within WP and provide you with tools to help you decide
which integration pattern is right for you and how to start such an integra-
tion project.

What Options Can You Choose from?
When looking to integrate your applications into the portal, the ¬rst thing
you need to do is determine which of the many options is most appropriate
for your speci¬c case. We will therefore ¬rst outline the possibilities you
can choose from and provide a simple classi¬cation that can help you un-
derstand the big picture before delving down into the details. Throughout
the rest of this chapter we will provide more details on each of these inte-
gration patterns. At the end of the chapter we will summarize with some
WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53

Integrating ExternalApplications withWebSphere Portal 441

Figure 23-2 Classi¬cation of integration patterns within WP.

basic guidelines for choosing the right integration pattern based on some
simple characteristics.
As Figure 23-2 shows, we chose to classify the major WP integration
patterns based on two dimensions. The ¬rst dimension is developed versus
packaged. Many of the tools we will show you in this chapter allow you to
make calls into enterprise information systems and applications but require
that you develop the code that makes these calls and the portlets that display
the information returned by these calls. Other integration options include
using prepackaged portlets created by IBM or by third parties”portlets
that package not only the logic for interfacing with applications but also
the presentation layer. It should be clear that such portlets can only exist
for applications with a large installed based”greater chances are that there
will be no packaged portlets for custom-built and proprietary applications
used by your company.
Our classi¬cation makes use of a second dimension: back-end versus UI-
based integration patterns. In back-end integration patterns, adapters are
used by your code to make remote invocations or send messages to the ap-
plication. This allows you to retrieve information and make changes to the
data stored within the application. These patterns are called back-end inte-
gration because the application is front-ended by your code. In our context,
the application sits in the back-end and is front-ended by portlets deployed
on the portal. Because these patterns make use of application adapters, we
will sometimes refer to these patterns as adapter-based integration patterns.
WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53

442 Chapter 23

UI integration patterns are fairly recent and make use of the fact that
Web-based applications use a consistent interaction model between the Web
browser and the application server. All these systems make use of HTTP re-
quest/response pairs, URLs, and various markup languages such as HTML
and WML. This commonality allows WP to introduce a new breed of inte-
gration patterns”patterns that make calls on the front-end of the system
and script the UI rather than make use of APIs based in the back end. These
patterns can often offer you very quick results in terms of exposing existing
Web-based applications on your portal.

Which Tools Are Available to You?
The integration patterns described above can broadly be classi¬ed into
portlet-based integration methods and adapter-based integration meth-
ods. Each of these methods is supported by a different set of tools within
the WebSphere world. For portlet-based integration, the major tool you will
use is the WebSphere Portlet Catalog available on the IBM developer dom-
ain (for example, at www7b.software.ibm.com/wsdd/zones/portal/
catalog). The catalog includes many portlets that you can download and
use”many of which include prepackaged integration options with major
application providers such as SAP, PeopleSoft, and Siebel. In addition, a
number of special portlets are really integration tools packaged in a way
that assists you in exposing other applications as portlets. The most impor-
tant such tool is the WeSphere Portal Application Integrator.
Adapter-based integration makes use of existing APIs exposed by appli-
cation providers. Adapters are tools that make use of these APIs and allow
you to easily call these APIs from your code. They handle issues such as
session handling, calling procedures, and transaction handling so that you
don™t have to deal with each application provider and its proprietary inte-
gration methodology. This makes integration simpler and more consistent
and if you master the use of adapters you will ¬nd that integrating with
one package is not all that different than integrating with another.
Adapter-based integration is based on a different set of tools”a set of
tools that is part of the broader family of WebSphere products and not spe-
ci¬c to the portal server. An adapter can broadly be classi¬ed as Java Con-
nector Architecture (JCA) based or messaging middleware adapters. JCA
adapters are deployed on WebSphere Application Server (WAS), in your
case on the server that forms the underlying platform for the portal server.
The latter category includes adapters used within WebSphere MQ (formerly
MQ Series) and adapters used within the CrossWorlds architecture. The ac-
tual adapter that you choose will depend on your overall environment and
your familiarity with these platforms. In addition to these infrastructures,
WY009-23 WY009-BenNatan-v1.cls May 11, 2004 14:53

Integrating ExternalApplications withWebSphere Portal 443

you will ¬nd that WebSphere Studio Application Developer Integration
Edition (WSADIE) is a useful tool for developing the integration code.

Developing Portlets Using Adapters
Integration of external applications using adapters appears in the lower
left-hand quadrant of our taxonomy shown in Figure 23-2. This integration
pattern involves quite a bit of development because it requires two distinct
implementation/development tasks. The ¬rst involves writing code that
makes use of an adapter to connect to the APIs exposed by the external
application and the second involves writing the portlets that make use of
this information. While both parts of this integration code are written in
Java, they are distinct pieces of code and should be viewed in this manner.
They could (and probably should) be developed by different individuals or


. 73
( 87 .)