Using WSRP with WebLogic Portal
Web Services for Remote Portlets (WSRP) is a web services standard that allows you to "plug-n-play" visual, user-facing web services with portals or other intermediary web applications. It allows you to create a repository of services that users can reference to surface applications in their portlets or to consume applications from WSRP-compliant Producers, even those far removed from your enterprise.
BEA WebLogic Portal 8.1 SP4 includes an implementation of WSRP that allows the framework to use WSRP portlets.
This section includes information on the following subjects:
BEA's implementation of WSRP is based upon the WSRP 1.0 standard created by OASIS. BEA Systems has been an active member of the OASIS technical group for WSRP 1.0 and continues to work as part of this standard effort for future enhancements to the specification.
You can read the current version on the WSRP standard at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
You can create WSRP-enabled portlets for these portlet types:
WSRP also supports backing files on complex producers
This version of WebLogic Portal supports only homogeneous portlets, therefore, the portlet modes must be compatible with the portlet; for example:
WSRP is an attractive option for web development for three main reasons:
You can surface new applications on your portal, independent of release schedule and where and when the code is physically deployed.
For example, perhaps you have a portal on machine X and another on machine Y. To get a portlet from machine X to machine Y, currently your only method of doing so is to copy the portlet's code, JSPs, and so on, from machine X to the destination machine (Y). By using WSRP, you can access and display that portlet on machine Y simply by referencing it through the Producer's Web Service Description Language identifier (WSDL).
As a "user-facing" web service, WSRP portlets provide both application and presentation logic. This is different from standard web services, or data-oriented web services, which contain business logic but lack presentation logic and thus require that every client implement that logic on its own.
While the data-oriented approach works well in many implementations, it is not well suited for dynamically integrating business applications. For example, to integrate an order status web service into a commerce portal, you would need to write code to display the results of the status services into the portal. Using WSRP, with the presentation logic included in the web service, you can achieve the aggregation of applications and services dynamically. You no longer need to develop the presentation logic in order to do the integration; you can simply request the order status service to show up as a portlet inside the commerce portal at a predetermined location.
You don't have to do a lot of programming to make a portlet remote. In a non-WSRP compliant implementation, integrating remote content and application logic into an end-user presentation usually requires a significant custom programming effort. Typically, vendors of aggregating applications, such as a portal, write special adapters for applications and content providers to accommodate the variety of different interfaces and protocols those providers use.
WebLogic Workshop 8.1 SP4 provides tools that allow you to pick from a rich choice of compliant remote content and application providers, and integrate them with just a few mouse clicks—without writing a line of code. Additionally, applications created with WebLogic Workshop 8.1 SP4 are, by default, WSRP-compliant, which means they can be leveraged into other user's portlets with little or no additional programming required on your part.
In addition to those listed above, WSRP provides these additional benefits to developers:
WSRP introduces the concepts of Producers and Consumers. By using WSRP, you can aggregate application functionality by integrating WSRP-compliant Producers into WebLogic Portal as a Consumer. Your end users thus will be able to interface with Consumers to view the integrated applications.
Figure 1-1 Web Services Between Producer and Consumer
Producers host portlets and provide such services as self-description, mark up, registration, and portlet management. Producers can optionally manage the registration of Consumers and require them to pre-register prior to interacting with portlets. A registration establishes a relationship between Consumers and Producers.
Producers are further classified into either simple or complex Producers.
A simple Producer is a non-portal web application that contains portlets . It does not depend upon any portal features (for example, customization), nor does it require registration, support URL rewriting in the Consumer, or support a management interface.
Using WSRP in a Basic WebLogic Server Domain describes how to configure a (non-portal) WebLogic Server environment as a WSRP producer so that you can expose portlets based on Struts or Java Page Flows. The exposed portlets can then be consumed as remote portlets running in a regular WebLogic Portal Domain.
A complex Producer requires registration, does support URL rewriting in the Consumer, and does support a management interface. By default, all portal web projects created with WebLogic Workshop 8.1 SP4 are created in complex Producers.
Table 1-1 lists the features available under complex Producers and simple Producers.
Consumers are web applications that aggregate information from Producers and surface it in other portals. Consumers route requests from users to the appropriate Producer, which, in turn processes the request and sends results back to the Consumer. The Consumer aggregates the results coming from various Producers and send the final result back to the user. Consumers provide separation of the traffic flowing between them and the Producers. They also ensure that all interactions are kept private to that specific user during the sessions.
Note: Consumers are web applications. A given consumer can have multiple desktops associated with it. Furthermore, there can be multiple consumers in an enterprise application.
In WebLogic Portal Administration Console, you will notice that producer registrations are scoped to individual consumer web applications. Because there can be multiple consumer web applications in an enterprise application, it is possible that a given producer will need to be registered multiple times within an enterprise application (that is, registered for each consumer web application in which it is used.)
In addition to complying with the OASIS WSRP standard, BEA's WSRP implementation adds some additional features to provide you with greater control over remote portlet usage. These features are described in Table 1-2
Remote portlets can be easily implemented by using the Portlet Wizard that comes with WebLogic Workshop. You can create and install robust remote portlets with a few simple mouse-clicks and a Producer's WSDL. |
|
The WebLogic Portal Administration Portal allows you to easily deploy and manage Producer and Consumer portlets for your enterprise from a central location. |
|
Portal web applications created with WebLogic Workshop 8.1 SP4 and later are, by default, created in Producers. You don't need to do any special coding or add additional content on these projects to make them available as a Producer. Note: For non-portal web applications, you need install a WSRP Producer in WebLogic Workshop to make that application a Producer. |
|
Consumers might be required to register with a Producer. Registration allows Producers to identify each Consumer with a unique, Consumer-provided handle. This helps identify what portlets are available to that Consumer. |
|
The service description shows what a Producer has to offer. It lets a Consumer discover a Producer and it lists the capabilities and properties that are available from the Producer. As a portlet repository, the service description also lists the portlets available from that Producer. |
|
Request time operations to initiate or terminate a session. It gets markup for a portlet, which is returned in the body of the message. It submits user interaction request for a portlet. |
|
The Producer may allow cloning, customization, and deleting of portlets. Customization features allow portal administrators to manage portlet preferences for remote portlets. |
Figure 1-2 illustrates the WSRP process, including handoffs from end user to Consumer to Producer and back.
The portlet lifecycle for a WSRP-compliant portlet includes both development time and deployment time capabilities.
Producer side (complex Producer) Developers will be able to leverage Java Page Flows, JSP, JSR 168, and Struts applications to expose their functionality in remote portlets. They can portletize the application and configure any related properties. Since all portal projects created with this version of WebLogic Workshop 8.1 are, by default, Producers, developers don't need to be aware of WSRP.
Consumer side Developers declare the Producers that are available to be used in the application. By using the Portlet Wizard in WebLogic Workshop, they can create a remote portlet based on the service description file from the Producer. They will need to:
See Building a Remote Portlet in the WebLogic Workshop online help system for a detailed description of this process.
Producer side For applications not built with this version of WebLogic Portal, some changes are required:
New applications, after WSRP installation, are automatically configured.
Consumer side Deployment is similar to the current Administration Portal deployment, since remote portlets look like local portlets.
In service pack 4 of WebLogic Portal 8.1, you cannot localize remote portlets. This feature will be available in a subsequent release of the product.