. 71
( 87 .)


Figure 22-3 Report portlet life cycle with WP.
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WebSphere Portal Support for Web Services and Remote Portlets 425

1. Using WP, you publish your portlet metadata to a UDDI repository.
This can be either a private UDDI repository that you have set up or
a public repository available on the Web. Throughout the chapter, we
will mostly use a public test UDDI repository but we will also discuss
about using a private repository.
2. As a portal administrator who wants to embed a certain function
packaged as a portlet in your own portal, you use the UDDI browser
to search the UDDI registry for available portlets.
3. Once you ¬nd the desired remote portlet, you use the Web services
manager to create a portlet proxy based on the published portlet. You
can then add the portlet to any page(s) on the portal.
4. When the portlet proxy is opened on a portal page, it communicates
with the remote portal running on your portal to retrieve not just
data but also the entire portlet content. The mechanics of these steps
are interesting. The portal server calls the portlet proxy passing it the
normal PortletRequest and PortletResponse objects”for the
portal server the portlet proxy is just another portlet. The portlet
proxy marshals all arguments into a SOAP request and invokes the
remote portal. The remote portal makes use of the information in the
request to ¬nd the remote portlet and then unmarshals all the
information from the original PortletRequest. When the response
is received by the remote portlet, it is marshaled into a SOAP
response and returned to the portlet proxy that returns it to the local
portal server.

We now turn to the details of using Web services within WP. While for
most part, the chapter focuses on remote portlets, we will start with the
most basic scenario”using a regular Web service from within a portlet.

Using Web Services as “Back-End” APIs
There is nothing special about using a Web service call from within a portlet.
It merely involves two development tasks: developing the portlet and using
the Web service. Because we have already discussed portlet development
extensively, our focus in this section will be on how to make use of an
existing Web service from your Java program (your portlet code).
Use of a Web service from Java code is supported within WebSphere
Studio by the Web Services wizard. The Web Services wizard allows you
to use the UDDI explorer to search for a UDDI registry for a Web service,
¬nd the service you need and the WSDL ¬le describing the Web services,
and then import the WSDL de¬nitions. This import process creates a Java
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

426 Chapter 22

Figure 22-4 Generating and using the Web service proxy from a Java portlet.

proxy object that has the same interface as the object implementing the Web
service, allowing you to make calls from within your portlet code to the
Java proxy, which then communicates over SOAP to the implementation
routine as shown in Figure 22-4.
In the following subsections we walk you through the process shown
in Figure 22-4, including registering with a public registry, discovering
the Web service, generating the proxy, and invoking the service using the

Using the IBM UDDI Business Test Registry
UDDI registries allow you to publish businesses and services. Once you
publish your Web services to a UDDI registry, they can be discovered and
used by potential customers. UDDI registries can be partitioned into pri-
vate and public registries. A private UDDI registry is one that you can set
up and manage yourself. It is usually used to set up a UDDI-based discov-
ery scheme within a company or an organization”an example is the IBM
WebSphere UDDI Registry that comes on the CD set of WP. Publishing your
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WebSphere Portal Support for Web Services and Remote Portlets 427

Web service onto a private registry makes it visible only to those who have
access to that registry. The IBM UDDI Business Test Registry is a public
UDDI registry that can be used to register businesses and services to the
public. It is most commonly used to test the publishing and discovering
aspects of Web services in a development and test environment.
Before you can publish your Web services to this registry, you will need
to set up a user account. Open your browser and navigate to https://
uddi.ibm.com/testregistry/registry.html. Then click the Get an
IBM User ID and Password link. Fill in the registration page; the most
important values to remember are the ID and password. Make sure you
have the spelling of your e-mail account correct because you will need to
receive an activation e-mail.
Once you have a registered user in the IBM UDDI Test Registry, you can
proceed to search for a Web service that you would like to use. We will
show you how to do this based on a Web service that is already published
to the IBM UDDI Business Test Registry as part of the IBM Speed-start Web
services program and the Speed-start community. The service we will use
is a simple one”merely providing the server clock time or the server on
which the Web service is deployed.

Discovering a Web Service
The ¬rst thing you need to do is discover the service. Within WebSphere
Studio you use the Web services explorer to search a UDDI registry and
import Web service de¬nitions. Bring up the Web services explorer by se-
lecting File ➪ Import from the menu bar. This brings up the Import wizard
where you need to select Web Service and click the Next button. Check
Launch the Web Services Explorer to ¬nd a Web service from a UDDI Reg-
istry and make sure that the IBM UDDI Test Registry is selected. Click the
Finish button to bring up the Web services explorer in import mode. Once
you are in the explorer, click the Find tool in the top-right pane. Then select
Businesses from the drop-down list and SpeedStartExample as the name of
the business you wish to ¬nd and press Go, as shown in Figure 22-5.
The results will include the SpeedStartExample registry entry and you
can proceed to import WSDL into your WebSphere Studio environment.
Click on the business that is retrieved by the search. Expand the query
result entry in the UDDI Navigator pane and click SpeedStartExample.
Click the Get Services tool in the pane™s toolbar. You will see the details
for the RemoteServerClock service as shown in Figure 22-6. Click the Get
Service Interface tool and then the Import WSDL to Workbench tool. Select
a project name and click Go. This imports the WSDL de¬nition into a ¬le
within your project from which you can go ahead and generate the Java
proxy that will enable you to make the remote call.
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

428 Chapter 22

Figure 22-5 Searching for the Web service.

Generating a Java Proxy
To create the proxy, you also use the WebSphere Studio Web Services wizard.
Follow these steps:

1. Select File ➪ New ➪ Other from the menu bar.
2. Select Web Services in the left pane and Web Service Client from the
right pane.
3. Select Java Proxy from the drop-down menu and check Test the
Generated Proxy. Click Next.
4. Enter the WSDL binding document.
5. Click Finish.

This will generate a proxy that you can use from your local programs to
invoke the service remotely. The wizard also asks you if you want to gen-
erate a test application. The test application comprises a set of simple JSPs
that provide a simple UI making calls to the proxy and the remote Web
service”it is a convenience to allow you to test that everything is function-
ing correctly.
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WebSphere Portal Support for Web Services and Remote Portlets 429

Figure 22-6 Importing the WSDL.

This simple process is all you need to follow in order to make Web service
calls from your own portlets. While this is indeed quite simple, remote
portlets and WSRP eliminate even this small amount of work.

Using WSRP within WP
WP support for WSRP services is based on producers of content and con-
sumers of content. Producers are portals that implement WSRP services
and that offer one or more proxy portlets. These services are used by remote
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

430 Chapter 22

portlets”the consumers. A consumer is a portal that uses WSRP interfaces
to incorporate and consume content supplied by producers. The consumer
receives markup from the WSRP service and presents it as a native portlet.
In order for this to occur, producers need to provide enough information
about the services they provide. This is done through a set of WSRP inter-
faces that are used by consumers; note that not all of these interfaces are
mandated by the WSRP standard for remote portlets to be able to work:
Service description. A producer must provide an interface through
which a consumer can interrogate which portlets are available for
use. WP supports the service description interface.
Markup. A producer must provide an interface through which a
consumer can request markup fragments forming the content of the
remote portlet. This interface must support the various states a
portlet may be in. WP supports the markup interface.
Portlet management. A producer may allow consumers to manage
state of the proxy portlet including its persistent state. WP supports
the portlet management interface.
Registration. A producer may provide registration capabilities for use
by consumers. WP does not support the registration interface.
In the technology preview provided in version 5.0.2, con¬guration is done
using the XML con¬guration interface. This is the only tested and supported
method or con¬guration WSRP services at this time.
The XML con¬guration interface includes updates that are required for
con¬guring WSRP, including a new portal resource type called wsrp-
producer allowing you to browse and integrate remote portlets using the
producer interface. You can also access WSDL documents describing the
remote portlets by using another added element: the wsdl-url element
within the wsrp-producer element. The WSDL description itself will be
accessed at runtime by using the http://<host>/WP_ROOT/wsdl/wsrp
URL where WP ROOT is the root directory of your WP installation. Fi-
nally, a new con¬guration element called preferences has been added
to the XML con¬guration interface allowing you to de¬ne which user at-
tributes you want transferred in the WSRP communications with the pro-
ducer. Preferences is an extension of the name-value element supporting
multivalued names. This allows you to associate one or more child elements
with portal resources such as wsrp-producer, which is important given
that you will typically have many consumers per producer.
In addition to these added elements, some existing resource types have
been changed in the XML con¬guration interface:
portlet. WSRP-based portlets will not reside within your existing
WAR ¬les. Therefore, this XML con¬guration interface element has
WY009-22 WY009-BenNatan-v1.cls May 11, 2004 14:53

WebSphere Portal Support for Web Services and Remote Portlets 431

been changed, allowing you to specify a handle attribute and
specify that a portlet is being implemented as a remote portlet using
a new ¬‚ag called provided.
portlet-app. Similarly, when a portlet application containing
multiple portlets is provided from a remote implementation, the
application needs to provide a group-id attribute corresponding to
the concrete-portlet-app tag normally found in
WP provides WSRP support for both producers and consumers. On the
producer side, WP allows you to take an existing portlet and expose it as
a WSRP producer, which can then be used by a remote consumer. On the
other side, WP allows you to take existing WSRP services and include them
as local portlets within your portal.

Con¬guring WP for WSRP
Regardless of whether you want to set up producers of WSRP services or
consume WSRP services, you ¬rst need to enable WSRP within your portal.
In order to support both of these functions, you need to perform the fol-


. 71
( 87 .)