Welcome!

SOA & WOA Authors: Jeremy Geelan, Aditya Banerjee, Chris Wiborg, Carmen Gonzalez, Udayan Banerjee

Related Topics: SOA & WOA

SOA & WOA: Article

WSRP: Dynamic and Real-Time Integration

An introduction to WSRP, its usage, and implementation

Termination Section
Registration relationships are not permanent in nature - either of the two WSRP producers or WSRP consumers can terminate the registration. The termination process can be triggered because:

  • The WSRP consumer no longer wants to aggregates the portlets provided by the producer in consideration
  • The WSRP producer is no longer interested in providing the services to the WSRP consumer.
  • There is need for re-registration because of the changes in the WSRP consumer environment.
  1. The WSRP consumer sends a request for the deregister operation of registration interface to the WSRP producer.
  2. In response to deregister request the WSRP producer sends the deregisterResponse after performing the cleanup process i.e., releasing the resources/states created for the WSRP consumer.
  3. Upon receiving deregisterResponse the WSRP consumer is advised to perform the cleanup process i.e., releasing resources/removing the registerationContext from the repository, etc.
Note: Termination doesn't mean that the WSRP consumer can't re-register with the WSRP producer, but earlier states can't be restored.

States Management
As we know, the WSRP protocol operates over connectionless technologies, so there is a need to maintain states that span across the different requests of an end user. WSRP provides support for two major types of states (See Figure 14).

Transient state
This represents application-level state. There are two types of transient states.

  • Navigational State: WSRP Producers require some data to generate markup for a given portlet several times during its interaction with a WSRP consumer. This state encapsulates data required and avoids the need to keep track of the interaction that caused the current state of the portlet. During the navigation the WSRP producer state doesn't hold transient state locally and even the user can store/bookmark the portlet navigation state. A Web application's URL plays key role in this because state is stored with the URL only so that both page refresh and bookmarked pages will generate what the end user expects. The WSRP producer returns this state to the WSRP consumer as navigational state so that it may satisfy these expectations of the end user.
  • Session state: It is maintained with the help of sessionID, which is generated when portlets initialize the session. This sessionID moves to and fro in between WSRP producer and WSRP consumer.
Persistent state
As the name suggests, this persistent in nature and will exist until either the WSRP consumer or producer explicitly discards it. Persistent state could be properties exposed by the WSRP producer via the portlet management interface, or some opaque state. There are two types of persistent states.
  • Consumer Registration: It is a representation of a relationship between a consumer and a producer. Registration state is maintained with the help of registrationHandle generated during the WSRP consumer's registration process.
  • Portlet State: The WSRP consumer allows creating unique configuration for portlets for its own use. Portlet state is maintained using portletHandle.
How Can We Create, Use, and Test WSRP?
Various application server vendors and open-source projects provide support for WSRP (e.g., WebLogic 8.1, Oracle, Apache's WSR4J, etc.). As a practical example, to create a portal page that aggregates WSRP from different WSRP producers with WebLogic Workshop, you would take the following steps:

1.  Open WebLogic Workshop.

2.  Create a new Portal Application - enter the application name as TestWSRPApp.

3.  Create a new Portal Web Project - right-click the TestWSRPApp directory in the Application window, choose New ->Project, and enter the project name as TestWSRPProject.

4.  Create a new Portal - enter the portal name as TestWSRPPortal.portal in your project.

5.  Create a new Portlet - enter portlet name as TestWSRPPortlet.portlet in your project.
a.  Select Portlet Type - Remote Portlet
b.  Find Producer (WSRP producer) - enter WSDL associated with the producer, for example:

c.  Select Portlet from List - select the portlet from list appears
d.  Proxy portlet Details - to enter Portlet Title say BEA:eWorld, to enter Producer' handle say TestBEAHandle

6.  Select created portal and insert the selected remote Portlet, for example, select TestWSRProject -> TestWSRPApp->TestWSRPPortal.Portal in left pane and insert the BEA:eWorld portlet in the portal page.

7.  Start/run the project - this will open WebLogic's test browser, in which you can see your portal page. The URL for your portal page would be http://localhost:7001/TestWSRPProject/TestWSRPPortal.portal.

If we want to add some more portlets from the same producer, repeat steps 5c, 5d, and 6. If we want to add remote portlets from some other WSRP producer then repeat steps 5b, 5c, 5d, and 6.

What Are the Limitations of WSRP?
We have read some great thing about WSRP - does that means this technology doesn't have any limitations? No, this is not true. WSRP also has some limitations, some of which are listed below.

  • Security - WSRP doesn't provide any standardization for security and it only relies on the lower-level protocol. All security mechanisms applied for Web services are applicable for this also. For example, for secured transmission it has to depend on HTTPS. WSRP producers are responsible for authentication and authorization, etc. Keep one thing in mind: "Threats to Web services involve threats to the host system, the application, and the entire network infrastructure."
  • Transaction Handling - There is no standard mechanism defined for handling the transactions.
  • Response Time - There may be issues in response time. As portal page may aggregate portlets from different WSRP producers, and if any one of the WSRP producers is not on par with the others in terms of responsiveness, it definitely would effect response time.
  • Reliability - Fault tolerance issues need to be handled at both the WSRP consumer level and the WSRP producer level. Normally, if some WSRP producer goes off then error is displayed in the portlet window. However it would be good if the WSRP consumer would define its own fault tolerance policy so that in case any of the WSRP producers goes off the portal page can still be rendered properly.
.  .  . 

Many thanks to my colleagues Nitin Khare, Saurabh Bhatnagar, and Atul Singh Chauhan for their valuable contributions as reviewers and for their technical input in this article.

References

More Stories By Rahul Gupta

Rahul Kumar Gupta has more than seven years of experience in the IT industry with core expertise in designing and developing enterprise applications and middleware based on JAVA, J2EE, and Web technologies. He works with Indian IT giant HCL Technologies Limited, NOIDA (INDIA). He is also a co-technical reviewer for the Wrox Publications books Professional Java Ecommerce, Professional EJB, and Professional JSP Site Design, and is involved with other technical writings as well. He has eight certifications, including Sun Certified Enterprise Java Architect and Java 2 Programmer.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.