Skip to main content

WSRP Specification

Introduction

The WSRP specification defines a web service interface for interacting with presentation-oriented web services. Initial work was produced through the joint efforts of the Web Services for Interactive Applications (WSIA) and Web Services for Remote Portlets (WSRP) OASIS Technical Committees in September, 2003.

It is an interoperability standard. It’s platform- and language-neutral. It’s all about requesting and transmitting chunks of HTML using SOAP.

The purpose of the Web Services for Remote Portlets protocol is to provide a web services standard that allows for the "plug-n-play" of remote running portlets from disparate sources. Many sites allow registered users to personalize their view of the website by turning on or off portions of the webpage, or by adding or deleting features. This is sometimes accomplished by a set of portlets that together form the portal.

WSRP defines how a portal can connect to a diverse set of information service providers using a single, generic protocol that requires only one type of portlet (a WSRP consumer portlet). This has the potential of greatly easing the integration burden associated with portal deployments.

The Key capabilities of WSRP

  • Allow portals to publish portlets so that other portals can consume them without programming.
  • Make the Internet a marketplace of visual Web services, ready to be integrated into portals.
  • Allow anybody to create and publish his or her content and applications as user-facing Web services.
  • Allow line-of-business portal administrators to browse directories for WSRP services to plug into their portals without programming effort.
  • Enable interactive, user-facing Web services to be easily plugged into standards-compliant portals.

WSRP v1 and v2

WSRP v1 provides a limited interoperability platform. So that effort could be concentrated on WSRP v2. WSRP v2 will augment the initial standard with cross-portlet coordination and access management features.

This major update to the standard will permit for a more useful integration of multiple of content sources, regardless of whether they are local or remote, into a new web application.

In addition, WSRP v2 may support some subsets of Web 2.0 technologies, such as AJAX and REST, without requiring them.

WSIA (Web Services for Interactive Applications) will extend the concepts in WSRP to a range of distributed Web applications, not just portals.

Comments

Popular posts from this blog

Convert an InputStream to XML

For that we can use DocumentBuilder class in java. By using the method parse(InputStream) ; A new DOM Document object will return. InputStream input; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder parser = factory.newDocumentBuilder(); Document dc= parser.parse(input); In the above code segment,by using the created Document object,the corresponding XML file for the inputStream can be accessed. References: http://www.w3schools.com/dom/dom_intro.asp http:// download.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html

CORS support from WSO2 API Manager 2.0.0

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources  on a web page to be requested from another domain outside the domain from which the first restricted resource was served. For example, an HTML page of a web application served from http://domain-a.com makes an <img src >  request for a different domain as 'domain-b.com' to get an image via an API request.  For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts as in above example and only allows to make HTTP requests to its own domain. To avoid this limitation modern browsers have been used CORS standard to allow cross domain requests. Modern browsers use CORS in an API container - such as  XMLHttpRequest  or Fetch - to mitigate risks of cross-origin HTTP requests.Thing to  note is it's not only sufficient that the browsers handle client side of cross-origin sharing,but also the servers from which these resources getting need to handl

[WSO2 AM] APIStore User Signup as an approval process

In previous versions of WSO2 APIManager before 1.6.0, it was allowed any user who's accessible the running APIStore come and register to the app.But there will be requirement like,without allowing any user to signup by him/her self alone,first get an approve by a privileged user and then allow to complete app registration.Same requirement can be apply to application creation and subscription creation as well.To fulfill that,we have introduced workflow extension support for  WSO2 APIManager  and you can find the introductory post on this feature from my previous blog post on " workflow-extentions-with-wso2-am-160 " . From this blog-post,I'll explain how to achieve simple workflow integration with default shipped resources with  WSO2 APIManager 1.6.0 and WSO2 Business Process Server 3.1.0 with targeting "user-signup" process. Steps First download the WSO2 APIManager 1.6.0[AM] binary pack from product download page . Extract it and navigate to