What is Web Services for Remote Portlets?
Web Services for Remote Portlets (WSRP) is a web services standard created by OASIS that allows for the plug-n-play of visual, user-facing web services with portals or other intermediary web applications. 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.
User-facing web services, or presentation oriented web services, provide both application logic and presentation logic. Standard web services, or data oriented web services, contain business logic, but lack presentation logic thus requiring that every client implement its own presentation logic.
This approach works for the most part, but it is not well suited for dynamically integrating business applications. For example, to integrate an order status web service into a commerce portal you will need to write code to display the results of the status services into the portal. Using WSRP, you have the presentation logic included in the web service. By providing a presentation oriented set of services, the aggregation of applications and services can be done dynamically. You no longer have the 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.
WSRP has strong support in the industry. Some of the companies involved in this standard are: BEA, IBM, Oracle, SAP, and Sun. For complete information on WSRP please visit: www.oasis-open.org/committees/wsrp .
Benefits of WSRP
- Presentation delivered with Web Service, not just data
- Interoperability
- Portability
- Options for deployment
- Support by large players in the industry
WSRP and BEA WebLogic Portal
WSRP introduces the notion of portlet Producers and portlet Consumers. Using WebLogic Portal, you can enable your projects as WSRP Producers and/or WSRP Consumers. By using WSRP customers will be able to expose portlet applications in Weblogic Portal as Producers. Customers will also be able to aggregate application functionality by integrating WSRP compliant portlets into Weblogic Portal as a Consumer. End users will be able to interface with Consumers to view the integrated applications. In short:
- Consumers aggregate WSRP compliant portlets into a portal and also manage the interaction with end-users
- Producers host and manage WSRP based portlets that are invoked by Consumers
Producers are modeled as containers of portlets. The Producers provide services such 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.
Consumers are similar in nature to routers that work on behalf of the end user. The Consumer will route requests from users to the appropriate Producer. A Producer in turn will process the request and send results back to the Consumer. The Consumer will aggregate the results coming from various Producers and send the final result back to the user. Since Consumers proxy for end users there is a lot user-specific information traveling across Consumers. It is expected that Consumers provide separation of traffic and maintain all interactions private to that specific user during the interaction.
One of the most powerful capabilities in WSRP is the ability to dynamically leverage applications from others servers. You can set up a Consumer Portal and dynamically discover and associate different portlets that are available from Producer Portals in the network. The result is a brand new portal that can dynamically integrate new functionality to streamline a business process and empower portal users.
This integrated portal can further personalize and customize the final portal experience and present it back to the user. Consumers make use of portlet handles during the communication with Producers. If a Producer exposes its "Portlet Management Interfaces" it allows a Consumer to customize a particular WSRP based portlet.
The diagram below illustrates the interaction between WSRP enabled portals:
- Consumer discovers a Producer.
- Consumer and Producer relationship is established.
- Consumer learns all the capabilities of a Producer.
- End user establishes a relationship with a Consumer.
- Consumer aggregates pages, often with portlets, for users.
- End user sends a page request to a Consumer.
- Consumer requests information from Producer.
- Producer provides Consumers with logic and data.
- End user sees aggregated page.
BEA Implementation Overview
There are four main steps in WSRP that are present in the BEA implementation:
- Registration: Consumers register with a Producer. Producers identify each consumer with a unique handle. This handle helps identify what portlets are available to a particular consumer.
- Service Description: The description shows what a Producer has to offer. It let's a Consumer discover a Producer and it lists the capabilities and properties that are available from the Producer. It also lists the available portlets. The Producer is the portlet repository.
- Markup and User Interaction: 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.
- Portlet Management: The Producer may allow cloning, customization, and deleting of portlets. Customization allows portal administrators manage portlet preferences for remote portlets.
- At development time:
- Producer side: Developers will be able to leverage Java Page Flows to expose their functionality. Using the .portlet file to portletize the application and configure any related properties. It is not really necessary for a developer to be aware of WSRP.
- Consumer side: Developers must first add a few WSRP jars to enable the application. Next, they declare the Producers that are available to be used in the application. From Weblogic Workshop, they can create a proxy portlet based on the service description file from the Producer. At that point, they can select a particular portlet, configure a few options, and create a new portlet. Then, they can drag and drop the WSRP based portlet to the portal.
- At deployment time:
- Producer side: For pre-existing applications, customers only need to add a few jars to enable WSRP capabilities. There may be some Producer related properties to be configured. This could also be done during development time via the Weblogic Workshop. New applications, after WSRP installation, are automatically configured.
- Consumer side: The experience would be similar to the current Administration Portal today. WSRP jars must be added to support consumer-side WSRP. Two new controls are made available to support remote portlets: ProxyPortlets and ProxyPortletContent.
Additional Topics
- Session Management
- The Producer-Consumer session is tied to the user session. Portlets on a Producer may share data, depending on the configuration.
- The Consumer manages cookies required by the Producers.
- RL rewriting is based on WLP 8.1 URL templates. URLs may be rewritten on the Consumer side or on the Producer side.
- Markup Generation
- URLs may be written by the Producer or the Consumer.
- For producer rewriting, the Consumer supplies URL templates.
- For Consumer rewriting, Producer inserts markers in the markup.
- Security
- The WSRP specification does not address security directly. The specification encourages developers to use existing standards such as WS-Security, SAML, XML Signatures, and XML-Encryption. WSRP 1.0 can be used with protocol level security SSL.
Interoperability
BEA has conducted extensive testing both internally and externally to ensure interoperability with other WSRP standards participants:
- Internal: BEA has tested all areas of offered WSRP functionality.
- External: BEA has hosted a publicly available Producer for testing by other WSRP Consumers. BEA has also built Consumers that use IBM, Oracle, and Citrix Producers.
WSRP Support is available with WebLogic Portal 8.1 SP3
The BEA Weblogic Portal team released a WSRP Preview Technology Kit in March 2004 for folks interested in WSRP to become familiar with the technology. This technology is now part of the WebLogic Portal product, supported, and you should download the latest WebLogic Portal installer in order to use it.
http://commerce.bea.com/index.jsp
We also have made available a public WSRP test server. For more information on using the test server visit the article below.
http://dev2dev.bea.com/products/wlportal81/articles/wsrp_test_server_at.jsp
Summary
The BEA WebLogic Portal team is actively involved with the OASIS WSRP technical committee. WebLogic Portal 8.1 Sp3 can play both Consumer and Producer roles in a WSRP environment. In addition we have made our WSRP libraries available to run with WebLogic Server 8.1 Sp3. This means WebLogic Server can play Producer role in a WSRP environment - you don't need a portal license for this to work. For more details on working with Producer visit e-docs:
http://e-docs.bea.com/wlp/docs81/wsrp/workprod.html#998933
Developers have a complete set of tools in order to create and deploy WSRP resources. Administrators will be able to dynamically integrate portlets and applications. Business users will be able to create their own applications and customize their experience.
Useful Links
Working with the BEA WSRP Test Server
http://dev2dev.bea.com/products/wlportal81/articles/wsrp_test_server_at.html
WSRP Standards Site
http://www.oasis-open.org/committees/wsrp/
WSRP Overview
http://www.oasis-open.org/committees/download.php/1273/wsrp-overview.ppt
dev2dev BEA WebLogic Portal page:
http://dev2dev.bea.com/products/wlportal81/index.html
BEA WebLogic Portal documentation site:
http://edocs.bea.com/wlp/docs81/index.html
BEA WebLogic Portal product page:
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/portal
