Chapter 12. Web Services for Remote Portlets (WSRP)
Prev |  | Next

## Chapter 12. Web Services for Remote Portlets (WSRP)

### Julien Viet

`<julien@jboss.org>`

### Chris Laprun

`<chris.laprun@jboss.com>`

## 12.1. Introduction

The Web Services for Remote Portlets specification defines a web service interface for accessing and interacting with interactive presentation-oriented web services. It has been produced through the efforts of the Web Services for Remote Portlets (WSRP) OASIS Technical Committee. It is based on the requirements gathered and on the concrete proposals made to the committee.

Scenarios that motivate WSRP functionality include:

- Content hosts, such as portal servers, providing Portlets as presentation-oriented web services that can be used by aggregation engines.
- Aggregating frameworks, including portal servers, consuming presentation-oriented web services offered by content providers and integrating them into the framework.

More information on WSRP can be found on the official website for WSRP. We suggest reading the primer for a good, albeit technical, overview of WSRP.

## 12.2. Level of support in JBoss Portal

The WSRP Technical Committee defined WSRP Use Profiles to help with WSRP interoperability. We will refer to terms defined in that document in this section.

JBoss Portal provides a Simple level of support for our WSRP Producer except that out-of-band registration is not currently handled. We support in-band registration and persistent local state (which are defined at the Complex level).

On the Consumer side, JBoss Portal provides a Medium level of support for WSRP, except that we only handle HTML markup (as Portal itself doesn't handle other markup types). We do support explicit portlet cloning and we fully support the PortletManagement interface.

As far as caching goes, we have Level 1 Producer and Consumer. We support Cookie handling properly on the Consumer and our Producer requires initialization of cookies (as we have found that it improved interoperabilty with some consumers). We don't support custom window states or modes, as Portal doesn't either. We do, however, support CSS on both the Producer (though it's more a function of the portlets than inherent Producer capability) and Consumer.

While we provide a complete implementation of WSRP 1.0, we do need to go through the Conformance statements and perform more interoperability testing (an area that needs to be better supported by the WSRP Technical Committee and Community at large).

## 12.3. Deploying JBoss Portal's WSRP services

JBoss Portal provides a complete support of WSRP 1.0 standard interfaces and offers both consumer and producer services. WSRP support is provided by the portal-wsrp.sar service archive, included in the main jboss-portal.sar service archive, if you've obtained JBoss Portal from a binary distribution. If you don't intend on using WSRP, we recommend that you remove the portal-wspr.sar from the main jboss-portal.sar service archive.

If you've obtained the source distribution of JBoss Portal, you need to build and deploy the WSRP service separately. Please follow the instructions on how to install JBoss Portal from the sources. Once this is done, navigate to JBOSS_PORTAL_HOME_DIRECTORY/wsrp and type:

    build deploy

At the end of the build process, portal-wsrp.sar is copied to JBOSS_HOME/server/default/deploy.

### 12.3.1. Considerations to use WSRP behind firewall

WSRP is built upon the JBoss WS web service stack. There is a known issue with the version 1.0.0.GA of JBoss WS (bundled with JBoss Application Server 4.0.4.GA) that prevents the complete deployment of JBoss Portal's WSRP service if the user is not online or behind a firewall/proxy. For this reason, we recommend that you deploy Portal on JBoss Application Server 4.0.5.GA. Alternatively, you can also perform a manual upgrade of JBoss WS, in which case we recommend that you use JBoss WS version 1.2.1.GA (and later). Please follow the instructions on how to upgrade JBoss WS as found on JBoss Portal's wiki.

### 12.3.2. Considerations to use WSRP when running Portal on a non-default port

If you have modified the port number on which Portal runs, you will also need update the port information for WSRP as found on JBoss Portal's wiki.

### 12.3.3. Considerations to use WSRP with SSL

It is possible to use WSRP over SSL for secure exchange of data. Please refer to the instructions on how to do so from JBoss Portal's wiki.

## 12.4. Making a portlet remotable

JBoss Portal does NOT, by default, expose local portlets for consumption by remote WSRP consumers. In order to make a portlet remotely available, it must be made "remotable" by adding a remotable element to the jboss-portlet.xml deployment descriptor for that portlet. If a jboss-portlet.xml file does not exist, one must be added to the WEB-INF folder of the web application containing the portlet.

In the following example, the "BasicPortlet" portlet is specified as being remotable. The remotable element is optional.

    <?xml version="1.0" standalone="yes"?>
    <!DOCTYPE portlet-app PUBLIC "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
              "http://www.jboss.org/portal/dtd/jboss-portlet_2_6.dtd">
    <portlet-app>
       <portlet>
          <portlet-name>BasicPortlet</portlet-name>
          <remotable>true</remotable>
       </portlet>
    </portlet-app>

It is also possible to specify that all the portlets declared within a given jboss-portlet.xml file have a specific "remotable" status by default. This is done by adding a single remotable element to the root portlet-app element. Usually, this feature will be used to remotely expose several portlets without having to specify the status for all the declared portlets. Let's look at an example:

    <?xml version="1.0" standalone="yes"?>
    <!DOCTYPE portlet-app PUBLIC
       "-//JBoss Portal//DTD JBoss Portlet 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-portlet_2_6.dtd">
    <portlet-app>
       <remotable>true</remotable>
       <portlet>
          <portlet-name>RemotelyExposedPortlet</portlet-name>
          ...
       </portlet>
       <portlet>
          <portlet-name>NotRemotelyExposedPortlet</portlet-name>
          <remotable>false</remotable>
          ...
       </portlet>
    </portlet-app>

In the example above, we defined two portlets with a default "remotable" status set to true. This means that all portlets defined in this descriptor are, by default, exposed remotely by JBoss Portal's WSRP producer. Note, however, that it is possible to override the default behavior by adding a remotable element to a portlet description. In that case, the "remotable" status defined by the portlet takes precedence over the default. In the example above, the RemotelyExposedPortlet inherits the "remotable" status defined by default since it does not specify a remotable element in its description. The NotRemotelyExposedPortlet, however, overrides the default behavior and is not remotely exposed. Note that in the absence of a top-level remotable element, portlets are NOT remotely exposed.

## 12.5. Consuming JBoss Portal's WSRP portlets from a remote Consumer

WSRP Consumers vary a lot as far as how they are configured. Most of them require that you either specify the URL for the Producer's WSDL definition or the URLs for the individual endpoints. Please refer to your Consumer's documentation for specific instructions. For instructions on how to do so in JBoss Portal, please refer to Section 12.6, “Consuming remote WSRP portlets in JBoss Portal”.

JBoss Portal's Producer is automatically set up when you deploy a portal instance with the WSRP service. You can access the WSDL file at `http://{hostname}:{port}/portal-wsrp/MarkupService?wsdl`. You can access the endpoint URLs at:

- `http://{hostname}:{port}/portal-wsrp/ServiceDescriptionService`
- `http://{hostname}:{port}/portal-wsrp/MarkupService`
- `http://{hostname}:{port}/portal-wsrp/RegistrationService`
- `http://{hostname}:{port}/portal-wsrp/PortletManagementService`

The default hostname is `localhost` and the default port is 8080.

## 12.6. Consuming remote WSRP portlets in JBoss Portal

### 12.6.1. Overview

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 using WSRP Producer descriptors. Alternatively, a portlet is provided to configure remote producers.

Once a remote producer has been configured, it can be made available in the list of portlet providers 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, check 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 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 WSRP Producer descriptor (default-wsrp.xml) that configures this default producer. This file can be edited or removed if needed.

### 12.6.2. Configuring a remote producer walk-through

Let's 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. We will first examine how to do so using an XML descriptor then see how the same can be accomplished using the configuration portlet.

#### 12.6.2.1. Using a WSRP Producer XML descriptor

We will create a public-bea-wsrp.xml descriptor. Note that the actual name does not matter as long as it ends with -wsrp.xml.

    <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
    <?xml version="1.0" standalone="yes"?>
    <deployments>
      <deployment>
        <wsrp-producer id="bea" expiration-cache="120">
          <endpoint-wsdl-url>http://wsrp.bea.com:7001/producer/producer?WSDL</endpoint-wsdl-url>
          <registration-data>
            <property>
              <name>registration/consumerRole</name>
              <lang>en</lang>
              <value>public</value>
          </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).

#### 12.6.2.2. Using the configuration portlet

As of Portal 2.6, a configuration portlet is provided to configure access to remote WSRP Producers grahically. You can access it at `http://{hostname}:{port}/portal/auth/portal/admin/WSRP` or by logging in as a Portal administrator and clicking on the WSRP tab in the Admin portal. If all went well, you should see something similar to this:

This screen presents all the configured producers associated with their status and possible actions on them. A Consumer can be active or inactive. Activating a Consumer means that it is ready to act as a portlet provider. Deactivating it will remove it from the list of available portlet providers. Note also that a Consumer can be marked as requiring refresh meaning that the information held about it might not be up to date and refreshing it from the remote Producer might be a good idea. This can happen for several reasons: the service description for that remote Producer has not been fetched yet, the cached version has expired or modifications have been made to the configuration that could potentially invalidate it, thus requiring re-validation of the information.

Next, we create a new Consumer which we will call "bea". Type "bea" in the "Create a consumer named:" field then click on "Create consumer":

You should now see a form allowing you to enter/modify the information about the Consumer:

Set the cache expiration value to 120 seconds and check the "Use WSDL?" checkbox. The form should now morph to:

Enter the WSDL URL for the producer in the text field and press the "Refresh" button. This will retrieve the service description associated with the Producer which WSRP is described by the WSDL file found at the URL you just entered. In our case, querying the service description will allow us to learn that the Producer requires registration and that it expects a value for the registration property named "registration/consumerRole":

### Note

At this point, there is no automated way to learn about which possible values (if any) are expected by the remote Producer. Please refer to the specific Producer's documentation.

Enter "public" as the value for the registration property and press "Refresh" once more. You should now see something similar to:

The Consumer for the "bea" Producer should now be available as a portlet provider and is ready to be used.

#### 12.6.2.3. Configuring access to a remote portlet

Let's now look at the Admin page and the Management portlet. Click on the "Portlet definitions" tab at the top. 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". You should now see something similar to:

From there on out, you should be able to configure WSRP portlets just as any other. In particular, you can create an instance of one of the remote portlets offered by BEA's public producer just like you would create an instance of a local portlet and then assign it to a window in a page. If you go to that page, you should see something similar to below for this portlet:

### 12.6.3. WSRP Producer descriptors

A WSRP Producer descriptor is an XML file which name ends in -wsrp.xml and which 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 descriptor or use one file per producer, depending on your needs. The DTD for the WSRP Producer descriptor format can be found at portal-wsrp.sar/dtd/jboss-wsrp-consumer_2_6.dtd.

### Note

It is important to note how WSRP Producer descriptors are processed. They are read the first time the WSRP service starts and the associated information is then put in the Portal database. Subsequent launch of the WSRP service will use the database-stored information for all producers which identifier is already known to Portal. More specifically, all the descriptors are scanned for producer identifiers. Any identifier that is already known will be bypassed and the configuration associated with this remote producer in the database will be used. If a producer identifier is found that wasn't already in the database, that producer information will be processed and recorded in the database. Therefore, if you wish to delete a producer configuration, you need to delete the associated information in the database (this can be accomplished using the configuration portlet as we saw in Section 12.6.2.2, “Using the configuration portlet”) AND remove the associated information in any WSRP Producer descriptor (if such information exists) as the producer will be re-created the next time the WSRP is launched if that information is not removed.

#### 12.6.3.1. Required configuration information

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 mandatory id attribute of the <wsrp-producer> 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 WSRP invocations. Two options are currently supported to provide this information:

- You can provide the URLs for each of the different WSRP interfaces offered by the remote producer via the <endpoint-config> element and its <service-description-url>, <markup-url>, <registration-url> and <portlet-management-url> children. These URLs are producer-specific so you will need to refer to your producer documentation or WSDL file to determine the appropriate values.
- Alternatively, and this is the easiest way to configure your producer, you can provide a URL pointing to the WSDL description of the producer's WSRP services. This is accomplished via the <endpoint-wsdl-url> element. JBoss Portal will then heuristically determine, from the information contained in the WSDL file, how to connect appropriately to the remote WSRP services.

  ### Note

  It is important to note that, when using this method, JBoss Portal will try to match a port name to an interface based solely on the provided name. There are no standard names for these ports so it is possible (though rare) that this matching process fails. In this case, you should look at the WSDL file and provide the endpoint URLs manually, as per the previous method.

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

#### 12.6.3.2. Optional 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 attribute of the <wsrp-producer> element which specifies the refreshing period in seconds. For example, providing a value of 120 for expiration-cache means that the producer information will not be refreshed for 2 minutes after it has been somehow accessed. If no value is provided, JBoss Portal will always access the remote producer regardless of whether the remote information has changed or not. Since, in most instances, the information provided by the producer does not change often, we recommend that you use this caching facility to minimize bandwidth usage.

Additionally, some producers require consumers to register with them before authorizing them to access their offered portlets. If you know that information beforehand, you can provide the required registration information in the producer configuration so that the Portal consumer can register with the remote producer when required.

### Note

At this time, though, only simple String properties are supported and it is not possible to configure complex registration data. This should however be sufficient for most cases.

Registration configuration is done via the <registration-data> element. Since JBoss Portal can generate the mandatory information for you, if the remote producer does not require any registration properties, you only need to provide an empty <registration-data> element. Values for the registration properties required by the remote producer can be provided via <property> elements. See the example below for more details. Additionally, you can override the default consumer name automatically provided by JBoss Portal via the <consumer-name> element. If you choose to provide a consumer name, please remember that this should uniquely identify your consumer.

### 12.6.4. Examples

Here is the configuration of the "self" producer as found in default-wsrp.xml with a cache expiring every five minutes:

    <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
    <?xml version="1.0" encoding="UTF-8"?>
    <deployments>
       <deployment>
          <wsrp-producer id="self" expiration-cache="300">
             <!--
             we need to use the individual endpoint configuration because the configuration via
             wsdl forces an immediate attempt to access the web service description which is not
             available yet at this point of deployment
             -->
             <endpoint-config>
                <service-description-url>
                  http://localhost:8080/portal-wsrp/ServiceDescriptionService
                </service-description-url>
                <markup-url>http://localhost:8080/portal-wsrp/MarkupService</markup-url>
                <registration-url>
                  http://localhost:8080/portal-wsrp/RegistrationService
                </registration-url>
                <portlet-management-url>
                  http://localhost:8080/portal-wsrp/PortletManagementService
                </portlet-management-url>
             </endpoint-config>
             <registration-data/>
          </wsrp-producer>
       </deployment>
    </deployments>

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

    <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
    <?xml version="1.0" encoding="UTF-8"?>
    <deployments>
       <deployment>
          <wsrp-producer id="MyProducer" expiration-cache="120">
             <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:

    <!DOCTYPE deployments PUBLIC "-//JBoss Portal//DTD WSRP Remote Producer Configuration 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-wsrp-consumer_2_6.dtd">
    <?xml version="1.0" encoding="UTF-8"?>
    <deployments>
       <deployment>
          <wsrp-producer id="AnotherProducer" expiration-cache="60">
             <endpoint-wsdl-url>http://example.com/producer/producer?WSDL</endpoint-wsdl-url>
             <registration-data>
                <property>
                   <name>property name</name>
                   <lang>en</lang>
                   <value>property value</value>
                </property>
             </registration-data>
          </wsrp-producer>
       </deployment>
    </deployments>

## 12.7. Configuring JBoss Portal's WSRP Producer

### 12.7.1. Overview

You can configure the behavior of Portal's WSRP Producer by editing the conf/config.xml file found in portal-wsrp.sar. Several aspects can be modified with respects to whether registration is required for consumers to access the Producer's services.

### 12.7.2. Default configuration

Let's look at the default configuration:

    <!DOCTYPE producer-configuration PUBLIC
              "-//JBoss Portal//DTD WSRP Local Producer Configuration 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-wsrp-producer_2_6.dtd">
    <?xml version="1.0" encoding="UTF-8"?>
    <producer-configuration>
       <registration-configuration fullServiceDescriptionRequiresRegistration="true">
          <registration-property-validator>
          org.jboss.portal.registration.policies.DefaultRegistrationPropertyValidator
          </registration-property-validator>
       </registration-configuration>
    </producer-configuration>

The top element <producer-configuration> contains a single <registration-configuration> element that defines a fullServiceDescritpionRequiresRegistration attribute with the value "true". This configuration specifies that the WSRP producer requires registration to access its services but does not require any specific registration properties (apart from what is mandated by the WSRP standard). It does, however, require consumers to be registered before sending them a full service description. This means that our WSRP producer will not provide the list of offered portlets and other capabilities to unregistered consumers. The <registration-configuration> element contains a <registration-property-validator> element. We will look into property validators in greater detail later in Section 12.7.4, “Registration configuration”. Suffice to say for now that this allows users to customize how Portal's WSRP Producer decides whether a given registration property is valid or not.

### 12.7.3. Minimal producer configuration

Requiring registration is optional: if you don't need your producer to require consumer registration, the only thing you need to do is to provide an empty <producer-configuration> element in portal-wsrp.sar/conf/config.xml.

### 12.7.4. Registration configuration

In order to require consumers to register with Portal's producer before interacting with it, you need to configure Portal's behavior with respect to registration. This is done via the <registration-configuration> element. This element is optional as previously noted. It can be empty if you don't require registration properties. You can also specify whether or not registration is required in order for consumers to access the Producer's full service description, as noted in our discussion of the default configuration, above. This is done via the fullServiceDescriptionRequiresRegistration attribute, which is optional. Acceptable values for this attribute are "true" or "false", defaulting to "false" in which case the Producer will always return the full service description, whether the consumer asking for it is registered or not.

#### 12.7.4.1. Customization of Registration handling behavior

Registration handling behavior can be customized by users to suit their Producer needs. This is accomplished by providing an implementation of the RegistrationPolicy interface. This interface defines methods that are called by Portal's Registration service so that decisions can be made appropriately. A default registration policy that provides basic behavior is provided and should be enough for most user needs.

While the default registration policy provides default behavior for most registration-related aspects, there is still one aspect that requires configuration: whether a given value for a registration property is acceptable by the WSRP Producer. This is accomplished by plugging a RegistrationPropertyValidator in the default registration policy. This allows users to define their own validation mechanism.

Please refer to the Javadoc for `org.jboss.portal.registration.RegistrationPolicy` and `org.jboss.portal.Registration.policies.RegistrationPropertyValidator` for more details on what is expected of each method.

Defining a registration policy is required for the producer to be correctly configured. This is accomplished by specifying the qualified class name of the registration policy via the <registration-policy> element. Since we anticipate that most users will use the default registration policy, it is possible to use the <registration-property-validator> element and provide the class name of your custom property validator instead. Since specifying a property validator only makes sense in the context of the default registration policy, both elements are mutually exclusive.

### Note

Since the policy or the validator are defined via their class name and dynamically loaded, it is important that you make sure that the identified class is available to the application server. One way to accomplish that is to deploy your policy implementation as JAR file in your AS instance deploy directory. Note also that, since both policies and validators are dynamically instantiated, they must provide a default, no-argument constructor.

#### 12.7.4.2. Registration properties

You can also specify that consumers wishing to register with your producer provide acceptable values for one or several registration properties. This is accomplished by providing a <registration-property-description> element per required registration property. This element lets provide information about a given registration property such as its name, its type, the hint and label that will be sent to remote consumers.

### Note

At this time, only String (xsd:string) properties are supported. If your application requires more complex properties, please let us know.

### 12.7.5. Example

Here is an example of a producer configurations requiring registration, barring consumers from accessing its complete service description until they are correctly registered and requires consumers to provide acceptable values for two String registration properties named "name1" and "name2" respectively. The registration service will use the `com.example.portal.SomeCustomRegistrationPolicy` class for its registration policy.

    <!DOCTYPE producer-configuration PUBLIC
              "-//JBoss Portal//DTD WSRP Local Producer Configuration 2.6//EN"
       "http://www.jboss.org/portal/dtd/jboss-wsrp-producer_2_6.dtd">
    <?xml version="1.0" encoding="UTF-8"?>
    <producer-configuration>
      <registration-configuration fullServiceDescriptionRequiresRegistration="true">
        <registration-policy>com.example.portal.SomeCustomRegistrationPolicy</registration-policy>
        <registration-property-description>
          <name>name1</name>
          <type>xsd:string</type>
          <hint xml:lang="en" resourceName="resource.hint1">hint1</hint>
          <label xml:lang="en" resourceName="resource.label1">label1</label>
        </registration-property-description>
        <registration-property-description>
          <name>name2</name>
          <type>xsd:string</type>
          <hint xml:lang="en" resourceName="resource.hint2">hint2</hint>
          <label xml:lang="en" resourceName="resource.label2">label2</label>
        </registration-property-description>
      </registration-configuration>
    </producer-configuration>

Prev | Up | Next
Chapter 11. Clustering Configuration | Home | Chapter 13. Security