Chapter 10. Web Services for Remote Portlets (WSRP) - JBoss Portal 2.6 Reference Guide 英文版参考指南文档

To be able to consume WSRP portlets exposed by a remote producer, JBoss Portal's WSRP consumer needs to know how to access that remote producer. One can configure access to a remote producer via *-wsrp.xml descriptors. These files can be dropped in the deploy directory of the JBoss application server or nested in .sar files. It is possible to configure access to several different producers within a single -wsrp.xml file or use one file per producer.

Once a remote producer has been configured in a -wsrp.xml file, it becomes available in the list of portlet provider in the Management portlet on the Admin page of JBoss Portal. You can then examine the list of portlets that are exposed by this producer and configure the portlets just like you would for local portlets.

JBoss Portal's default configuration exposes some of the sample portlets for remote consumption. As a way to test the WSRP service, a default consumer has been configured to consume these portlets. To make sure that the service indeed works, checks that there is a portlet provider with the self identifier in the portlet providers list in the Management portlet of the Admin page. All local portlets marked as remotable are therefore exposed as remote portlets via the self portlet provider so that you can check that they work as expected with WSRP. The portal-wsrp.sar file contains a default-wsrp.xml that configures this default producer. This file can be edited or removed if needed.

Let's see work through the steps of defining access to a remote producer so that its portlets can be consumed within JBoss Portal. We will configure access to BEA's public WSRP producer. To do so, you will need to create a -wsrp.xml file (which we will call here public-bea-wsrp.xml but the name does not matter as long as it ends with -wsrp.xml) as follows:

               
<deployments>
   <deployment>
      <wsrp-producer>
         <producer-id>bea</producer-id>
         <expiration-cache>120</expiration-cache>
         <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
         <registration-data>
            <consumer-name>JBoss Portal 2.4 Test</consumer-name>
            <property>
               <name>registration/consumerRole</name>
               <lang>en</lang>
               <value>public</value>
            </property>
         </registration-data>
      </wsrp-producer>
   </deployment>
</deployments>
            

This producer descriptor gives access to BEA's public WSRP producer. We will look at the details of the different elements later. Note for now the producer-id element with a "bea" value. Put this file in the deploy directory and start the server (with JBoss Portal and its WSRP service deployed).

Let's now look at the Admin page and the Management portlet. Click on the "Portlets" link at the top to manage the portlets. Once this is done, look at the list of available portlet providers. If all went well, you should see something similar to this:

We have 3 available portlet providers: local, self and bea. The "local" portlet provider exposes all the portlets deployed in this particular instance of Portal. As explained above, the "self" provider refers to the default WSRP consumer bundled with Portal that consumes the portlets exposed by the default WSRP producer. The "bea" provider corresponds to BEA's public producer we just configured. Select it and click on "Change portlet provider". You should now see something similar to:

From there on out, you should be able to configure the portlet just as any other, barring the restriction that the (optional) WSRP Portlet Management interface is not yet supported in 2.4. If everything went well, you created an instance of the portlet and assigned it to a window in a page. If you go to that page, you should see something similar to below for this portlet:

Let's now look at which information needs to be provided to configure access to a remote producer.

First, we need to provide an identifier for the producer we are configuring so that we can refer to it afterwards. This is accomplished via the <producer-id> element.

JBoss Portal also needs to learn about the remote producer's endpoints to be able to connect to the remote web services and perform the WSRP invocations. Two options are currently supported to provide this information:

Both <producer-id> and either <endpoint-config> or <endpoint-wsdl-url> are required elements for a functional remote producer configuration.

It is also possible to provide addtional configuration, which, in some cases, might be important to establish a proper connection to the remote producer.

One such optional configuration concerns caching. To prevent useless roundtrips between the local consumer and the remote producer, it is possible to cache some of the information sent by the producer (such as the list of offered portlets) for a given duration. The rate at which the information is refreshed is defined by the <expiration-cache> element which specifies the refreshing period in seconds.

Additionally, some producers require consumers to register with them before authorizing them to access their offered portlets. JBoss Portal currently only supports a very basic subset of in-band registration and it is thus possible to provide required registration information in the producer configuration so that the Portal consumer can register with the remote producer when required.

Registration configuration is done via the <registration-datat> element. We need to provide a consumer name (via the <consumer-name> element) for our consumer and then provide a list of values for the registration properties required by the remote producer via <property> elements. See the example below for more details.

Here is an example of a WSRP descriptor with a 2 minutes caching time and manual definition of the endpoint URLs:

               
<?xml version="1.0" encoding="UTF-8"?>
<deployments>
   <deployment>
      <wsrp-producer>
         <producer-id>MyProducer</producer-id>
         <expiration-cache>120</expiration-cache>
         <endpoint-config>
            <service-description-url>http://www.someproducer.com/portal-wsrp/ServiceDescriptionService</service-description-url>
            <markup-url>http://www.someproducer.com/portal-wsrp/MarkupService</markup-url>
            <registration-url>http://www.someproducer.com/portal-wsrp/RegistrationService</registration-url>
            <portlet-management-url>http://www.someproducer.com/portal-wsrp/PortletManagementService</portlet-management-url>
         </endpoint-config>
      </wsrp-producer>
   </deployment>
</deployments>
            

Here is an example of a WSRP descriptor with endpoint definition via remote WSDL file, registration data and cache expiring every minute:

               
<?xml version="1.0" encoding="UTF-8"?>
<deployments>
   <deployment>
      <wsrp-producer>
         <producer-id>AnotherProducer</producer-id>
         <expiration-cache>60</expiration-cache>
         <endpoint-wsdl-url>http://example.com/producer/producer?WSDL</endpoint-wsdl-url>
         <registration-data>
            <consumer-name>JBoss Portal 2.4 Test</consumer-name>
            <property>
               <name>property name</name>
               <lang>en</lang>
               <value>property value</value>
            </property>
         </registration-data>
      </wsrp-producer>
   </deployment>
</deployments>