. 70
( 87 .)


8. Select sandox3 and sandbox4 and click Synchronize.
9. Expand Applications and select Enterprise Applications. Find your
portlet and click Start.
10. Log in again into the WebSphere Portal http://sandbox1
.rigorconsultants.com/wps/portal using wpsadmin.
11. Go to Administration and click on Portlets icon. Select Manage
12. To activate the portlet, select the portlet application and then the
portlet name and click Activate/Deactivate.

Deploying Themes and Skins into a WebSphere Portal Cluster
Like portlets, you install new theme and skin or modify it, it has to be
synchronized with the other Portal Servers. Speci¬cally, you have to export
the Portal EAR ¬le from Deployment Manager, update the EAR ¬le with
the new or modi¬ed theme and skin directories, and import the EAR ¬le
back to the Deployment Manager cell. Using the example in Figure 21-6,
you would do this by taking the following steps:

1. Log in to sandbox2, open a command prompt, and go to
2. Enter wasdmin -user wpsbind -password wpsbind where wpsbind is
the administrator ID and password we set up.
3. Enter AdminApp export wps c:\temp\wp_old.ear.
4. Enter Quit. Deployment Manager WebSphere Portal EAR will be
exported into the ¬le c:\temp\wp_old.ear.
5. Create the directory c:\temp\wp_expand and expand the wp_old
.ear ¬le by typing the command EARExpander-ear
c:\temp\wp ld.ear -operationDir c:\temp\wp expand\ -operation
WY009-21 WY009-BenNatan-v1.cls May 13, 2004 22:25

Designing High Availability into Your Portal Server 419

6. Copy the new themes to c:\temp\wp_expand\wps.war
7. Copy the new skins to c:\temp\wp_expand\wps.war
8. Collapse the ¬les back to an EAR ¬le by typing the following
command: EARExpander -ear c:\temp\wp new.ear -operationDir
c:\temp\wp expand\ -operation collapse
9. Now you will import the modi¬ed EAR back into the Deployment
Manager. Enter wasdmin -user wpsbind -password wpsbind, where
wpsbind is the administrator ID and password you set up.
10. Enter AdminApp and install wps c:\temp\wp_new.ear. If you are
updating EAR then you add the options -update -appname wps.
Wait for the message that Application wps has installed successfully.
11. Enter AdminCon¬g save, which saves the changes to the master
12. Enter Quit.
13. Next you have to add the new skin and theme to the Portal
Administration page, by doing the following:
a. Log on to http://sandbox1.rigorconsultants.com/
wps/portal as wpsadmin.
b. Select Administration ➪ portal User Interface ➪ Themes and Skins
and click Add New Skin.
c. Enter the Skin name and default locale title.
d. Enter the skin directory name and click Add New Theme.
e. Enter the theme name in Theme Name and default locale title and
enter theme directory.
f. Select the desired skins and click OK.

In this chapter we have touched on some of the challenges in implementing a
highly available WebSphere Portal. We have discussed the various availabil-
ity components that need to be looked at when implementing WebSphere
Portal. We also showed how to implement WebSphere Portal in clustered
But if there is one message that you need to get out of this chapter, it is
that high availability is very complex and costly. You need to have a good
¬nancial reason to put it in place and major commitment from all levels
of the organization. In our simple example we identi¬ed 33 single point of
WY009-21 WY009-BenNatan-v1.cls May 13, 2004 22:25

420 Chapter 21

failures and this did not include organizational, process, or environmental
factors. In a real-life organization there are thousands of elements that im-
pact a major system and addressing every one is cost prohibitive. You need
to focus on the components that have the largest impact upon failure and
are the least costly to ¬x (otherwise known as the low hanging fruit).
As we showed in the beginning of this chapter, most of the problems that
cause outages (or performance degradation that appears as outages) relate
to software bugs or con¬guration errors. If you put a buggy portlet into a
cluster, all that will happen is all the nodes will crash at the same time. If
you miscon¬gure your servers, operating system or WebSphere Portal, the
cluster will probably fail. Remember that putting WebSphere Portal cluster
does not imply that you will get higher availability. It may actually get
The complexity of WebSphere Network Deployment requires a very dis-
ciplined and well-run IT shop with de¬ned processes that staff adhere to. If
you implement clustering in a haphazard mode, the probability of your ap-
plication having frequent outages is quite high. Before you implement high
availability, you have to ¬rst ensure that quality and engineering processes
are in place, metrics are collected, and that there is a high-level organiza-
tional visibility and accountability.
Do not perform a high-availability implementation if your organization
is just giving it lip service or is not prepared to address cultural issues.
Instead, just focus on reducing your failure points and providing better
diagnostic and automated repair processes.
In the next chapter we will discuss a technology preview that was intro-
duced in WebSphere 5.0.2, Web Service Remote Portlets or WSRP.
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53


WebSphere Portal Support
for Web Services and
Remote Portlets

Web services have become the preferred method for Internet-based integra-
tion and have been adopted by all vendors. This widespread adoption has
made Web services a technology that any Web developer needs to under-
stand and use”and portal developers are no exception.
In this chapter you will learn to use Web services with WP. You will see
how to make Web service calls from portlets using the various wizards
available within WebSphere Studio. We will show you how to discover
existing Web services using UDDI registries and how to use them from
within portlets you develop and deploy from within your portal. In addi-
tion (and perhaps more importantly) you will learn about the Web Services
for Remote Portal (WSRP) standard and the concept of portal proxies. Us-
ing WSRP support in WP you will see how to publish your portlets for use
by other portals and how you can use remote portlets from within your
own WP instance. This integration metaphor allows you to bypass all de-
velopment efforts and use existing portlets (including both the functional
layer and the presentation layer) within your portal. You will learn how to
enable your portal for WSRP, how to produce remote portlets, and how to
use them within a portal.
We think it is important that you understand these two main methods
for using Web services within WP. The ¬rst method uses core Web service
functionality”for example, calls to remote functions that are described by
WSDL and that are formatted using SOAP over HTTP. This is the most
general-purpose use of Web services and one that can be utilized in every
environment. The second, using WSRP, is more limited to remote portlets
but allows you to integrate the function as well as the presentation with
little or no development effort.

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

422 Chapter 22

A Quick Review of Web Services
and Remote Portlets
A brief review is in order for those who have not recently used Web services.
The goal in this section is not to teach you all about Web services but rather
to ensure that the concept is well understood by all readers of this chapter.
Web services are functional elements deployed on a node on the net-
work and accessed over the Internet. This description is quite generic and
doesn™t say too much; what makes such a service endpoint a Web service is
the “how,” not the “what.” Web services are based on a set of standards”
speci¬cally the Simple Object Access Protocol (SOAP), the Web Service De-
scription Language (WSDL), and Universal Description Discovery and Inte-
gration (UDDI). SOAP is a protocol by which a remote client can invoke the
functionality implemented by the Web service. Developers of Web services
use WSDL to de¬ne the metadata describing the Web service, and remote
clients use WSDL to learn what arguments are required for invoking the
Web service (as well as other things required to make the remote call). Web
service providers use UDDI to publish their Web services, and clients of Web
services use UDDI to discover where these Web services, and the metadata
describing them, reside. For an overview of SOAP, WSDL, and UDDI see
Executive™s Guide to Web Services by Eric Marks and Mark Werrell and for an
in-depth discussion see Java, XML, and Web Services Bible by Mike Jasnowski.
SOAP, WSDL, and UDDI form the core of the Web services stack, and Web
services are not specially made for portal deployment. Using Web services
within the context of portlet development is no different than making use of
Web services when developing servlets, JSPs, or any other Java programs.
But Web services do not stop with SOAP, WSDL and UDDI”in fact, there
are over 100 higher level protocols and de¬nitions within the world of Web
services. One of these “extensions” is very much speci¬c to portals and
portlets”remote portlets and the Web Services for Report Portlets (WSRP)
WSRP is an OASIS standard that was created to simplify the integra-
tion of remote applications and content into portals. OASIS (www.oasis-
open.org) is a not-for-pro¬t global consortium that drives the develop-
ment, convergence, and adoption of e-business standards and is responsible
for much of the work in areas such as XML and Web services. The purpose
of WSRP is to allow exposing content from third-party portlets in portals
with zero programming effort. This is possible because WSRP de¬nes an in-
terface for presentation-oriented Web services rather than basic functional
Web services.
WSRP allows a portlet”both its functionality and its presentation”to be
packaged as a reusable component using Web service technologies. Web ser-
vices allow you to take a function, describe and publish it in a standard way,
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WebSphere Portal Support for Web Services and Remote Portlets 423

Figure 22-1 Multiple portlets calling a Web service.

and allow others to ¬nd and invoke it in a standard way. The inventors of
the remote portlet concept have taken a viewpoint of a portlet as a “reusable
function.” Instead of requiring you to separate your application function-
ality from the presentation layer, it allows you to embed both function and
presentation inside a single reusable component that uses Web service in-
frastructure such as SOAP and UDDI registries to perform the plumbing.
The difference between using Web services from within a portlet and the
use of remote portlets is best exempli¬ed by the implementations shown
in Figures 22-1 and 22-2. In Figure 22-1 a portlet makes use of a Web

Figure 22-2 Multiple proxy portlets using a single report portlet.
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

424 Chapter 22

service. While the same Web service implementation can be used by many
portlet instances, there are still multiple portlets that can either be the same
packaged portlet deployed on multiple portals or, as is more likely, involve
separately developed portlets that deliver similar functionality into the por-
tal. In Figure 22-2, a single portlet makes calls to the published Web service
and multiple proxy portlets embed this portlet within multiple portals. The
proxy portlets in this case are artifacts of WP that are automatically created
and that do not need to be developed”saving you work in building portlets
that do the same thing anyway.

Using Remote Portlets in WP
WSRP is a relatively new initiative support for WSRP within WP. Version 4x
of WebSphere Portal supported Web services and remote portlets through a
proprietary IBM implementation. Version 5 of WP still supports this propri-
etary method but we highly recommend that you do not use this method.
This implementation is being phased out by IBM and is being replaced by
the WSRP-conformant implementation. At the time of writing this chapter,
WP did not yet fully support the WSRP speci¬cation for production envi-
ronments; WSRP support within WP 5.0.2 was supplied as a Technology
Preview by IBM. However, this implementation is fairly mature and it is
likely that by the time you read this chapter and use Web services within
your portal, WP will fully support WSRP. Therefore, we will cover only the
WSRP support within WP and suggest that if you use remote portlets you
use WSRP.
Figure 22-3 shows the full life cycle support provided by WP for remote
portlets. Starting off with a portlet, which you wish to make available to
other portal servers, the major steps in the life cycle are as follows:


. 70
( 87 .)