Modifying a currently held registration
Registration modification for service upgrade
Producers often offer several levels of service depending on consumers' subscription levels (for example). This is implemented at the WSRP level with the registration concept: producers can assert which level of service to provide to consumers based on the values of given registration properties.
There might also be cases where you just want to update the registration information because it has changed. For example, the producer required you to provide a valid email and the previously email address is not valid anymore and needs to be updated.
It is therefore sometimes necessary to modify the registration that concretizes the service agreement between a consumer and a producer. Let's take the example of a producer requiring a valid email (via an email registration property) as part of its required information that consumers need to provide to be properly registered.
Suppose now that we would like to update the email address that we provided to the remote producer when we first registered. We will need to tell the producer that our registration data has been modified. Let's see how to do this. Select the consumer for the remote producer in the available consumers list to display its configuration. Assuming you want to change the email you registered with to foo@example.com, change its value in the field for the email registration property:
Now click on "Update properties" to save the change. A "Modify registration" button should now appear to let you send this new data to the remote producer:
Click on this new button and, if everything went well and your updated registration has been accepted by the remote producer, you should see something similar to:
Registration modification on producer error
It can also happen that a producer administrator decided to change its requirement for registered consumers. GateIn will attempt to help you in this situation. Let's walk through an example using the selfv2 consumer.
Let's assume that registration is requiring a valid value for an email registration property. If you go to the configuration screen for this consumer, you should see:
Now suppose that the administrator of the producer now additionaly requires a value to be provided for a name registration property. We will actually see how to do perform this operation in GateIn when we examine how to configure GateIn's producer in Configuring GateIn's WSRP Producer. Operations with this producer will now fail. If you suspect that a registration modification is required, you should go to the configuration screen for this remote producer and refresh the information held by the consumer by pressing "Refresh & Save":
As you can see, the configuration screen now shows the currently held registration information and the expected information from the producer. Enter a value for the name property and then click on "Modify registration". If all went well and the producer accepted your new registration data, you should see something similar to: 
WSRP 1 makes it rather difficult to ascertain for sure what caused an OperationFailedFault as it is the generic exception returned by producers if something didn't quite happen as expected during a method invocation. This means that OperationFailedFault can be caused by several different reasons, one of them being a request to modify the registration data. Please take a look at the log files to see if you can gather more information as to what happened. WSRP 2 introduces an exception that is specific to a request to modify registrations thus reducing the ambiguity that exists when using WSRP 1.
Consumer operations
Several operations are available from the consumer list view of the WSRP configuration portlet:
The available operations are:
-
Configure: displays the consumer details and allows user to edit them
-
Refresh: forces the consumer to retrieve the service description from the remote producer to refresh the local information (offered portlets, registration information, etc.)
-
Activate/Deactivate: activates/deactivates a consumer, governing whether it will be available to provide portlets and receive portlet invocations
-
Register/Deregister: registers/deregisters a consumer based on whether registration is required and/or acquired
-
Delete: destroys the consumer, after deregistering it if it was registered
-
Export: exports some or all of the consumer's portlets to be able to later import them in a different context
-
Import: imports some or all of previously exported portlets
Import/Export functionality is only available to WSRP 2 consumers of producers that support this optional functionality. Import functionality is only available if portlets have previously been exported.
Importing and exporting portlets
Import and export are new functionalities added in WSRP 2. Exporting a portlet allows a consumer to get an opaque representation of the portlet which can then be use by the corresponding import operation to reconstitute it. It is mostly used in migration scenarios during batch operations. Since GateIn does not currently support automated migration of portal data, the functionality that we provide as part of WSRP 2 is necessarily less complete than it could be with full portal support.
The import/export implementation in GateIn (available since 3.1) allows users to export portlets from a given consumer. These portlets can then be used to replace existing content on pages. This is accomplished by assigning previously exported portlets to replace the content displayed by windows on the portal's pages. Let us walk through an example to make things clearer.
Clicking on the "Export" action for a given consumer will display the list of portlets currently made available by this specific consumer. An example of such a list is shown below:
Once portlets have been selected, they can be exported by clicking on the "Export" button thus making them available for later import:
You can re-import the portlets directly by pressing the "Use for import" button or, on the Consumers list page, using the "Import" action for a given consumer. Let's assume that you used that second option and that you currently have several available sets of previously exported portlets to import from. After clicking the action link, you should see a screen similar to the one below:
As you can see this screen presents the list of available exports with available operations for each.
-
View: displays the export details as previously seen when the export was first performed
-
Delete: deletes the selected export, asking you for confirmation first
-
Use for import: selects the export to import portlets from
Once you've selected an export to import from, you will see a screen similar to the one below:
The screen displays the list of available exported portlets for the previously selected export. You can select which portlet you want to import by checking the checkbox next to its name. Next, you need to select the content of which window the imported portlet will replace. This process is done in three steps. Let's assume in this example that you have the following page called page1 and containing two windows called NetUnity WSRP 2 Interop - Cache Markup (remote) and /samples-remotecontroller-portlet.RemoteControl (remote) as shown below:
In this example, we want to replace the content of the /samples-remotecontroller-portlet.RemoteControl (remote) by the content of the /ajaxPortlet.JSFAJAXPortlet portlet that we previously exported. To do so, we will check the checkbox next to the /ajaxPortlet.JSFAJAXPortlet portlet name to indicate that we want to import its data and then select the page1 in the list of available pages. The screen will then refresh to display the list of available windows on that page, similar to the one seen below:
Note that, at this point, we still need to select the window which content we want to replace before being able to complete the import operation. Let's select the /samples-remotecontroller-portlet.RemoteControl (remote) window, at which point the "Import" button will become enabled, indicating that we now have all the necessary data to perform the import. If all goes well, pressing that button should result in a screen similar to the one below:
If you now take a look at the page1 page, you should now see that the content /samples-remotecontroller-portlet.RemoteControl (remote) window has been replaced by the content of the /ajaxPortlet.JSFAJAXPortlet imported portlet and the window renamed appropriately:
Erasing local registration data
There are rare cases where it might be required to erase the local information without being able to deregister first. This is the case when a consumer is registered with a producer that has been modified by its administrator to not require registration anymore. If that ever was to happen (most likely, it won't), you can erase the local registration information from the consumer so that it can resume interacting with the remote producer. To do so, click on "Erase local registration" button next to the registration context information on the consumer configuration screen:
This operation is dangerous as it can result in inability to interact with the remote producer if invoked when not required. A warning screen will be displayed to give you a chance to change your mind:
