The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: November 18, 2004
Web Services for Remote Portlets (WSRP)

Contents

Overview and News Highlights

Note on TC name: In the original TC Charter, the TC name was "Web Services Remote Portal (WSRP) TC." It was changed to "Web Services for Remote Portlets (WSRP) TC."

[September 11, 2003]   Web Services for Remote Portlets Specification Approved as OASIS Standard.    OASIS has announced the approval of the Web Services for Remote Portlets Specification Version 1.0 as an OASIS Standard, reflecting the collaborative effort of some twenty-five (25) OASIS member companies. WSRP defines the interface and semantics for a web service standard "that allows for the plug-and-play of content sources (e.g., portlets) with portals and other aggregating web applications. It thereby standardizes the consumption of Web services in portal front ends and the way in which content providers write Web services for portals. Scenarios that motivate WSRP/WSIA functionality include: (1) Portal servers providing portlets as presentation-oriented web services that can be used by aggregation engines; (2) Portal servers consuming presentation-oriented web services provided by portal or nonportal content providers and integrating them into a portal framework. The the description also applies generally to non-portal environments. WSRP allows content to be hosted in the environment most suitable for its execution while still being easily accessed by content aggregators. The standard enables content producers to maintain control over the code that formats the presentation of their content. By reducing the cost for aggregators to access their content, WSRP increases the rate at which content sources may be easily integrated into pages for end-users."

[November 10, 2003]   Portlet Open Source Trading (POST) Site for JSR 168 and WSRP Portlets.    An open source web site featuring shared resources for implementation of the JCP JSR 168 and WSRP OASIS standards has been announced by Plumtree Software, Documentum, BEA Systems Inc., and Sun Microsystems. The Portlet Open Source Trading Site (POST) "aims to help companies kickstart their portal deployments, leading to faster time to value for all portal customers by providing open source portlets and a forum to exchange and learn about how these emerging new standards. Separate areas within POST are provided for sharing JSR-168 and WSRP portlets. As with any open-source site on SourceForge.net, any registered organization can contribute portlets to POST, which become available to all other members of the open-source community. Using POST, participants can see lists of newly available portlets, post requests to the community for the development of new portlets, search for portlets, upload new portlets, download available portlets, submit modified or enhanced versions of downloaded portlets, and discuss portlet development best practices, issues and solutions. Both the JCP (ava Community Process) and OASIS, the standard bodies that developed JSR 168 and WSRP respectively, have expressed support for the POST open-source site. The site will help companies learn from their industry peers and share best practices for developing standards-based portlets."

[April 25, 2003]   OASIS Web Services for Remote Portlets Specification Moves Toward Standardization.    The Web Services for Remote Portlets Specification version 1.0 produced jointly by two OASIS technical committees has been approved as a Committee Specification. The specification has also been approved for advancement toward adoption as an OASIS Standard, and enters a 30-day public review period preliminary to its voting phase. The WSRP document has been created by members of the Web Services for Interactive Applications (WSIA) and Web Services for Remote Portals (WSRP) TCs. The goal of the specification "is to enable an application designer or administrator to pick from a rich choice of compliant remote content and application providers, and integrate them with just a few mouse clicks and no programming effort. Typical scenarios include portal servers providing portlets as presentation-oriented web services that can be used by aggregation engines, or portal servers consuming presentation-oriented web services provided by portal or nonportal content providers and integrating them into a portal framework. The design aim is to simplify the integration effort through a standard set of web service interfaces allowing integrating applications to quickly exploit new web services as they become available. The joint authoring of these interfaces by WSRP and WSIA TCs allows maximum reuse of presentation-oriented, interactive web services while allowing the consuming applications to access a much richer set of standardized web services."

[February 03, 2003] Draft WSRP Specification. Web Services for Remote Portlets Specification. Edited by Alan Kropp (Vignette Corporation), Carsten Leue (IBM Corporation), and Rich Thompson (IBM Corporation). OASIS TC Working Draft. Version 0.91. 3-February-2003, printed 2003-03-17. 81 pages. Document identifier: WSRP_Specification-v0.91 (Word). Location: http://www.oasis-open.org/committees/wsia, http://www.oasis-open.org/committees/wsrp. Contributors: Chris Braun (Novell), Jeff Broberg (Novell), Mark Cassidy (Netegrity), Michael Freedman (Oracle Corporation), Timothy N. Jones (CrossWeave), Thomas Schaeck (IBM Corporation), and Gil Tayar (WebCollage). Abstract: "Integration of remote content and application logic into an End-User presentation has been a task requiring 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. The goal of this specification is to enable an application designer or administrator to pick from a rich choice of compliant remote content and application providers, and integrate them with just a few mouse clicks and no programming effort. This specification is a joint effort of two OASIS technical committees. Web Services for Interactive Applications (WSIA) and Web Services for Remote Portals (WSRP) aim to simplify the integration effort through a standard set of web service interfaces allowing integrating applications to quickly exploit new web services as they become available. The joint authoring of these interfaces by WSRP and WSIA allows maximum reuse of user-facing, interactive web services while allowing the consuming applications to access a much richer set of standardized web services. This joint standard layers on top of the existing web services stack, utilizing existing web services standards and will leverage emerging web service standards (such as security) as they become available. The interfaces are defined using the Web Services Description Language (WSDL)." [source .DOC]

[February 19, 2002] On January 21, 2002, OASIS issued a 'Call for Participation' in conjunction with a proposed Web Services Remote Portal Technical Committee. Thomas Schaeck of IBM is initially the TC Chair. An IBM white paper ('Note') of 21-January-2002 describes WSRP thus: "Web Services for Remote Portals (WSRP) are visual, user-facing web services centric components that plug-n-play with portals or other intermediary web applications that aggregate content or applications from different sources. They are designed to enable businesses to provide content or applications in a form that does not require any manual content- or application-specific adaptation by consuming intermediary applications. As Web Services for Remote Portals include presentation, service providers determine how their content and applications are visualized for end-users and to which degree adaptation, transcoding, translation etc may be allowed. WSRP services can be published into public or corporate service directories (UDDI) where they can easily be found by intermediary applications that want to display their content. Web application deployment vendors can wrap and adapt their middleware for use in WSRP-compliant services. Vendors of intermediary applicatios can enable their products for consuming Web Services for Remote Portals. Using WSRP, portals can easily integrate content and applications from many internal and external content providers. The portal administrator simply picks the desired services from a list and integrates them, no programmers are required to tie new content and applications into the portal. To accomplish these goals, the WSRP standard defines a web services interface description using WSDL and all the semantics and behavior that web services and consuming applications must comply with in order to be pluggable as well as the meta-information that has to be provided when publishing WSRP services into UDDI directories. The standard allows WSRP services to be implemented in very different ways, be it as a Java/J2EE based web service, a web service implemented on Microsoft's .NET platform or a portlet published as a WSRP Service by a portal. The standard enables use of generic adapter code to plug in any WSRP service into intermediary applications rather than requiring specific proxy code. WSRP services are WSIA component services built on standard technologies including SOAP, UDDI, and WSDL. WSRP adds several context elements including user profile, information about the client device, locale and desired markup language passed to them in SOAP requests. A set of operations and contracts are defined that enable WSRP plug-n-play..."

From the OASIS announcement 2002-01-28: "OASIS, the XML interoperability consortium, today announced its members have formed the OASIS Web Services for Remote Portals (WSRP) Technical Committee to create an XML and Web services standard that will allow the plug-n-play of visual, user-facing Web services with portals or other intermediary Web applications. These WSRP services will enable businesses to provide content or applications in a form that does not require any manual or application-specific adaptation by consuming portals and applications. 'Once a WSRP service has been published to a public directory, portal administrators will be able to locate and dynamically integrate it with just a few mouse clicks,' explained Thomas Schaeck of IBM, chair of the OASIS WSRP Technical Committee. 'WSRP will enable distributed portal systems where portals share portlets as visual, user-facing Web services for integration with other portals.' WSRP will allow remote portlet Web services to be implemented in a variety of ways, including Java/J2EE and Microsoft's .NET platform. WSRP services will be built on standard technologies including SOAP, UDDI, and WSDL..."

OASIS Web Services for Remote Portals TC [Draft] Charter: "The WSRP TC will an XML and web services standard that will allow for the 'plug-n-play' of portals, other intermediary web applications that aggregate content, and applications from disparate sources. These Remote Portlet Web services will be designed to enable businesses to provide content or applications in a form that does not require any manual content or application-specific adaptation by consuming applications. The TC will work with other OASIS web services TCs and will harmonize WSRP as far as practical with existing web application programming models, the work of the W3C, emerging web services standards, and with the work of other appropriate business information bodies."

Principal References

General: Articles, News, Papers, Reports, Presentations

  • [November 18, 2004] "PeopleSoft Demonstrates WSRP Portal Interoperability at XML 2004. First Enterprise Application Vendor to Support the OASIS Standard for Application Content." - "At the XML Conference and Exposition 2004, PeopleSoft Inc. demonstrated that the PeopleSoft Community Portal and PeopleSoft applications seamlessly interoperate with other leading portal vendors by leveraging the Web Services for Remote Portlets (WSRP) standard. As part of the demonstration, PeopleSoft portal content was displayed in IBM WebSphere, BEA, Sun Microsystems and other leading portal solutions. PeopleSoft will be the first enterprise applications software vendor to integrate content from core business applications with third party portals using the WSRP standard. 'Companies increasingly need to aggregate data across multiple portal platforms and Web applications, and provide an intuitive user interface,' said Roy Satterthwaite, vice president of marketing, PeopleSoft Tools & Technology. 'PeopleSoft continues to embrace open standards such as WSRP to allow customers to effectively address their portal and Web services integration challenges.' As a founding member of the OASIS Technical Committee on WSRP, PeopleSoft is actively involved in refining the WSRP standard as well as collaborating with other vendors to help resolve the inability to interoperate across multiple portal platforms and applications. WSRP simplifies integration by allowing a portal administrator to select desired services from a list and integrate them into their portal. Like other Web service standards, WSRP provides seamless integration between disparate technologies such as .NET and Java. PeopleSoft Community Portal will provide support for WSRP in the 8.9 release scheduled for Q1 2005. PeopleSoft is the world's second largest provider of enterprise application software with 12,750 customers in more than 25 industries and 150 countries..."

  • [August 30, 2004] "Web Services for Remote Portlets 1.0 Primer." Edited by Subbu Allamaraju (BEA Systems) and Rex Brooks (Starbourne Communications). Draft Version 0.9. August 30, 2004. 53 pages. A Public Review Draft for review through October 2, 2004; use the WSRP TC comment facility to provide feedback to the TC. Produced by members of the OASIS Web Services for Remote Portlets TC. Contributors: Atul Batra (Sun Microsystems Inc), Clinton Davidson (Plumtree Software), Alan Kropp (Vignette Corporation), and Gil Tayar (WebCollage). Web Services for Remote Portlets (WSRP) is a web services protocol for aggregating content and interactive web applications from remote sources. The WSRP specification uses the terms Producer and Consumer to describe parties implementing the specification. The Producer is a web service that offers one or more portlets and implements various WSRP interfaces/operations. Depending on the implementation, a producer may offer just one portlet, or may provide a runtime (or a container) for deploying and managing several portlets. The Consumer is a web service client that invokes producer-offered WSRP web services and provides an environment for users to interact with portlets offered by one or more such Producers. You can use WSRP to implement a very broad range of portlet Producers and Consumers. The purpose of this non-normative Primer is to provide a tutorial-oriented explanation of the main concepts of the WSRP 1.0 specification. Its tutorial approach is intended as a guide for implementers and other technical readers. The document explains the abstractions of the specification using sample scenarios, and provides guidance and best practices for implementers and advanced users of the WSRP Specification..." [source PDF]

  • [August 23, 2004] "Web Services for Remote Portlets 1.0 Primer." Edited by Subbu Allamaraju (BEA Systems) and Rex Brooks (Starbourne Communications). Draft Version 0.8. August 22, 2004. 53 pages. Produced by members of the OASIS Web Services for Remote Portlets TC. Contributors: Atul Batra (Sun Microsystems Inc), Clinton Davidson (Plumtree Software), Alan Kropp (Vignette Corporation), and Gil Tayar (WebCollage). "Web Services for Remote Portlets (WSRP) is a web services protocol for aggregating content and interactive web applications from remote sources. Web Services for Remote Portlets 1.0 Primer is a non-normative document intended to help interpret the WSRP 1.0 Specification with usage scenarios and typical interactions that must happen to achieve such aggregation... The WSRP specification uses the terms Producer and Consumer to describe parties implementing the specification. The Producer is a web service that offers one or more portlets and implements various WSRP interfaces/operations. Depending on the implementation, a producer may offer just one portlet, or may provide a runtime (or a container) for deploying and managing several portlets. The Consumer is a web service client that invokes producer-offered WSRP web services and provides an environment for users to interact with portlets offered by one or more such Producers..."

  • [August 09, 2004] "Microsoft Continues Commitment to XML Web Services With New SharePoint Products and Technologies Toolkits." - "As part of Microsoft Corp.'s ongoing commitment to enterprise application interoperability, customers and system integrators today can begin taking advantage of two new Web Part toolkits and a Web services toolkit for Microsoft SharePoint Products and Technologies that enable them to connect systems from multiple vendors using XML Web services standards. Available at no charge on GotDotNet.com, and complete with source code, the two Web Part toolkits represent powerful additions to Microsoft's array of XML Web Parts by facilitating the integration of Microsoft Office SharePoint Portal Server 2003 and Windows SharePoint Services sites with information line-of-business applications from SAP AG and other vendors. Microsoft's WSRP Web Part Toolkit for SharePoint Products and Technologies leverages the Web Services for Remote Portlets (WSRP) specification created by the Organization for the Advancement of Structured Information Standards (OASIS), of which Microsoft is a member, to enable developers to build portlets that interact with other portal sites, regardless of the business system they use. This toolkit complements a variety of already available standards-based integration technologies, including the XML Data View Web Part. The WSRP Web Part Toolkit includes a ready-to-install 'consumer' component that displays WSRP portlet services provided by a variety of vendors within Web Part pages hosted by Windows SharePoint Services and SharePoint Portal Server 2003. For developers interested in making SharePoint site content available over WSRP Web services, Microsoft also is providing a WSRP Web Services Toolkit for SharePoint Products and Technologies that explains and provides examples for creating and deploying WSRP-compliant producer Web services, making it even easier for businesses to leverage SharePoint application functionality and content within third-party portals. Adding to the several means already available for integrating SAP functionality into SharePoint Portal Server environments, Microsoft is also releasing today its Web Part Toolkit for SharePoint Products and Technologies for SAP iViews. This toolkit provides Web Parts that display SAP NetWeaver iViews, and do so in a way that is easy to deploy and configure. This capability is especially useful for developers and system integrators creating composite applications that combine SAP resources with other application, people, team and knowledge resources within SharePoint sites and enterprise portals..."

  • [May 01, 2004] "WSRP and the Enterprise Portal. A Strong, and Important, Start." By Edward Anuff (Vice President of Product Strategy, Vignette). In Web Services Journal (April 30, 2004). "WSRP (Web Services for Remote Portlets) is an OASIS standard whose goal is to provide Web service-based access capability for portal servers. Up to this point, most efforts to add capabilities or features to portal servers have involved the use of proprietary APIs and protocols that differ from vendor to vendor. WSRP will standardize the way that portals communicate remotely with remote services that can extend the portal's core capabilities. At this stage in the evolution of WSRP, the specification addresses some very basic use cases for integration of portlet services through the use of Web services. Chief among these are the proprietary standards for integrating remote content, as described earlier. Standardizing the protocol enables developers and end users to more easily populate their portals with content from a variety of sources, with very little or no custom programming required... As with all first versions of a specification, there is always a laundry list of items that couldn't be fit in; otherwise, 1.0 would still be in committee. The 1.1 version is scheduled to be completed sometime in 2004, while 2.0 is likely to arrive toward the end of 2005 or the first half of 2006. Security was not addressed at all in the 1.0 specification, other than allowing a portlet to be marked as requiring the connection be secure... The current plan is to incorporate support for WS-Security along with guidelines on how it should be used within WSRP to ensure interoperability among vendors... UDDI support will allow producers to post information about their services on UDDI servers to make it easier for consumers to search for and find their offerings when the location of the server that hosts these servers is not known. Version 1.1 will add simple support of UDDI so that a producer can describe its presence as well as each of the services it offers. This is essentially a subset of the data that is found in the service description. Version 2.0 is expected to introduce more detailed structures to provide support for categorization, among other things. There are still some questions among the technical committee as to what role the specification should take in describing how UDDI should be used by producers. Cross-portlet communication is the next large feature planned for introduction in WSRP 2.0. It will provide a mechanism that allows portlets to broadcast event information to other portlets spread across multiple producers if required. The key use case for this feature is so that portlets can post contextual information about their interaction, and other portlets can use that information to tailor the content that they generate..."

  • [April 15, 2004] "WSRP and JSR 168: Will These Portal Standards Matter to You?" By Penny Lunt Crosman. In Transform Magazine (April 15, 2004). "WSRP is a communication protocol that allows 'portlets' (packaged content and/or computing capabilities) from one application to work within another (notably, but not only, portals). JSR 168 is a Java programmatic interface that lets Java-based portlets work within WSRP-compliant applications. In the absence of these standards, any consuming application requires individual integration points to be hand-built between every application and information source. With WSRP and JSR 168, compliant portlets are transformed into fungible business objects that can be brought into many different applications and combined into various combinations of content and capabilities. Thus, these standard protocols allow user-driven integration, while leaving content and information to be managed at its native source. Integration costs are reduced without jeopardizing the integrity of information and content repositories... In the future, WSRP and JSR 168 should benefit customers in two ways. First, as the standards become adopted, portal developers will need less platform-specific training; their skills will become portable, making them easier to find and less expensive to hire. Second, as firms' portal strategies mature, they'll start to expose internal portal components — such as collaboration spaces and order-entry systems — to partners. JSR 168 will let companies share portlets by sending each other code; WSRP will let them share a centrally-hosted portlet..."

  • [February 06, 200] "Plumtree Reins in Diverse Web Applications. Portal Package Oversees Security, Content, Collaboration, and Search." By Mike Heck (InfoWorld Test Center). In InfoWorld (February 06, 200). "Does your organization often turn to portals in an attempt to manage the sprawl of Web-based applications? If so, you may be all too aware that these projects can fail to deliver their anticipated ROI. That's because IT managers overlook the need to extend core functions — content management, search, and security — to the applications that appear within a portal. As a result, companies often settle for a portal that provides a decent user experience for a few locally hosted functions. However, the portal doesn't provide an overarching administration framework, nor does it help you lower development and maintenance expenses... Plumtree Enterprise Web Suite includes major updates to every Plumtree product. Plumtree Corporate Portal 5.0 offers new community, knowledge management, and administrative functions, most notably the ability to index content and broker security from many systems. Complementing the portal are the Plumtree Search, Collaboration, Content, and Studio (portlet development) Servers that better integrate with the portal. Equally important, you get an architecture based entirely on Web services (either Java or .Net), which simplifies creating portal applications and customizing the user interface. Plumtree's implementation of WSRP (Web Services for Remote Portlets) and JSR (Java Specification Requests) 168 is strong. Plumtree Corporate Portal communicates with a container that holds the JSR 168 portlet so the portlet can run on any J2EE or Windows application server. The other advantage with this approach is that Plumtree Corporate Portal can handle a larger number of portlets than if the portlets were running on the Plumtree portal server..."

  • [February 6, 2004] "Vignette First To Announce Self-Certified JSR 168-Compliant Portal. Vignette Application Portal 7.0 Also Supports Comprehensive Localization and Standards for Universal Access." - "Continuing to deliver on its mission to drive enhanced business efficiency, Vignette Corp. has announced initial availability of Vignette Application Portal 7.0, part of the Vignette V7 family of products. Vignette Application Portal 7.0 has been certified by Vignette on the Sun Microsystem's Test and Compatibility Kit (TCK) for compliance with the recently adopted JSR 168 portlet interoperability standard. With this move, Vignette believes that it has become the first independent software vendor to announce a self-certified JSR 168 portal. The release of Vignette Application Portal 7.0 reaffirms Vignette's leadership in delivering standards-based portal solutions that scale and evolve from department level to enterprisewide deployments. As a founding member of both the Java Community Process's JSR 168 Expert Group and OASIS' WSRP Technical Committee, Vignette has played a pivotal role in helping define JSR 168 and WSRP since their inceptions in January 2002. By driving innovation through the usage of Web services and portal standards, Vignette enables customers to increase efficiency and reduce the complexity and cost of sharing information across organizations by supporting their evolving enterprise portal strategies. 'JSR 168 represents a significant milestone for the industry and will play a key role in advancing an organization's ability to integrate portal deployments and provide a single, consolidated view for end users,' said Craig Roth, vice president, Web and collaboration strategies at Meta Group Inc. 'Organizations should look to vendors that are showing a commitment to industry standards as a means to increase developer productivity and significantly reduce deployment costs.' In conjunction with its support for JSR 168, Vignette will provide plug-ins for the leading integrated development environments (IDE) to provide developers with a seamless experience when deploying IDE-developed JSR 168 portlets within Vignette Application Portal 7.0. In addition, the latest release of Vignette Application Portal provides enhanced localization of portal administrative consoles and multibyte support for compliance with Section 508, enabling disabled administrators to easily manage portal sites, and i18N, allowing diverse administrators in multidialect regions to access a shared portal console that is localized for each individual administrator's dialect..." See also: (1) JSR 168 Portlet API Specification 1.0 Released for Public Review"; (2) "Portlet Open Source Trading (POST) Site for JSR 168 and WSRP Portlets."

  • [January 05, 2004] "Will Standards Turn Portals into Commodities? Two Approaches That Work." By Rickland Hollar. In Web Services Journal (December 2003). "WSRP defines portal services as interactions between consumers and producers, where consumers are applications and portals that 'consume' portlet services and producers are portal frameworks (or Web services applications) providing those services. WSRP defines portlets as Web services that generate markup and permit consumers to interact with that markup, and WSRP producers as containers containing Web services portlets. In this model, portlet containers expose their framework and the local portlets it supports through four types of Web services interfaces: Service description: Enables consumers to learn about the producer's capabilities and its portlets Markup: Allows consumers to request and interact with markup fragments and to convey information about window modes and states Portlet management: Gives consumers access to portlet state and property information and influence over portlet life-cycle events Registration: Allows consumers to create relationships with producers; and to register, deregister, and modify relationship information WSRP builds on Web services standards for publishing, finding, and binding services. Its goal is to enable any application, including portal frameworks, to publish their content as portlets, which portals can consume. JSR 168 and WSRP are complementary: one's focus is on the local portlet code and its interactions with the framework while the other's is on remote interactions. Once both standards mature and appear in products, you will be able to develop portlet applications to the JSR 168 standard and depend on portal frameworks to provide WSRP services, when appropriate... JSR 168 and WSRP focus on core portal functionality (aggregation and personalization) rather than advanced features (search, content management, knowledge management, and business intelligence), meaning they only address a subset of portal framework functionality. This opens the possibility for multiple classes (a high and a low end) of portal frameworks. Both standards distinguish between portlet containers and portal frameworks (leaving aggregation to the framework) and focus on defining the interfaces between portlets and portlet containers. This distinction opens the door for vendors to incorporate portlet containers, but not portal frameworks, into their products (similar to Web servers today where some Web servers are also J2EE Web containers)... You should ensure you are working with vendors that have been part of the JSR 168 and WSRP standards efforts with strong commitments to integrating the standards into their products. Once the standards appear in the products you use, you should focus on writing portlets using the standards' defined APIs and interfaces, avoiding to the maximum extent possible any proprietary extensions. This should allow you to develop 'write once, run anywhere' portlets, provided you stick with standards-based products. What if the prediction is wrong? How would this strategy change? It wouldn't! That's the beauty of standards and one of the benefits of the JSR 168 and WSRP efforts..."

  • [December 10, 2003] "OASIS Interoperability Demos Showcase ebXML, SAML, UBL, WS-Reliability, and XACML at XML 2003. Adobe, BEA, Citrix, Cyclone Commerce, Drake Certivo, Fujitsu, Hitachi, IBM, Korean National Computerization Agency (NCA), NEC, US National Institute of Standards and Technology (NIST), Oracle, Sun Microsystems, Vignette, and Others Demonstrate Interoperability of Standards." - "Companies, users, and government agencies from around the world collaborated on four separate interoperability demonstrations of OASIS Standards and specifications at the XML 2003 conference this week. In scenarios as varied as epidemic management, weather portal aggregation, supply chain operations, and messaging, the practical usage of OASIS Standards was shown. 'These demonstrations provide more evidence that e-business, security and Web services standards are being deployed to solve real-world challenges,' said James Bryce Clark, OASIS Manager for Technical Services Development. 'The excitment here is not limited to what is being demonstrated. The types of participants -- vendors and end users, large and small, government agenies--as well as the geographic span they represent clearly indicates buy-in from all stake-holders.' Demos: (1) Achieving Interoperability Using Test Frameworks: Drake Certivo, NCA, and NIST implemented a real-world ebXML test scenario involving a supply chain in which a buyer tests an upgrade with their solutions as well as with their customers' solutions. The enhancements were then integrated into production operations. The demo also provided access to services via an ebXML Registry which supported the supply chain operations. (2) OASIS WS-Reliability Interoperability Demonstration: Fujitsu, Hitachi, NEC, Oracle, and Sun Microsystems demonstrated their independently developed implementations of the OASIS WS-Reliability specification. WS-Reliability is intended for use in mission critical applications that require guaranteed delivery, duplicate message elimination, and/or message ordering within a transaction. These three fundamental properties of the WS-Reliability specification were demonstrated utilizing a use case derived from a commercial scenario. (3) Epidemic Management Using OASIS ebXML, UBL and XACML: Adobe, Cyclone Commerce, NIST, Sun Microsytems, and others demonstrated an end-to-end data transmission process using OASIS Standards for ebXML Registry, ebXML Messaging, ebXML Collaboration Protocol Profile and Agreement (CPP/A), ebXML Business Process Specification Schema (BPSS), Security Assertion Markup Language (SAML), Universal Business Language (UBL), and eXtensible Access Control Markup Language (XACML). In the demo, a public health care entity for disease control, uses a registry to manage epidemiological data. Laboratories, emergency rooms, and airports send periodic reports on persons that may be carrying communicable diseases to the registry. (4) Web Services for Remote Portlets (WSRP): BEA, Citrix, IBM, Oracle, and Vignette showcased a common use case for WSRP in which a weather site was configured as a portal. Pages on the site were aggregated by the portal and all of the application components used to produce the forecasts and other data were implemented as portlets. These portlets were then reused on other portals via WSRP rather than requiring the portals to separately install the complete set of portlets. WSRP was shown to maximize both control and availability for the weather site while minimizing costs for the remote portal sites..."

  • [November 21, 2003] "Oracle Readies Portal-Building Tools." By Martin LaMonica. In CNET News.com (November 19, 2003). "Oracle has released an early version of its software toolkit that allows developers to create standardized applications to run in Java-based Web site portals. The company said that its portal-building tools adhere to two recently completed Java portal and Web services standards, called Java Specification Request (JSR) 168 and Web Services Remote Portlets (WSRP). The early version of Oracle's portal tools works with Oracle's portal server software, which delivers information to business users via a browser. The Oracle toolkit includes two components. A 'portlet container' acts as an add-on to Oracle's Application Server to run portal applications, or portlets, that comply with the JSR 168 standard. A 'portlet wizard' runs with Oracle's JDeveloper programming tools to speed up the process of constructing portlets..." See also the announcement.

  • [November 19, 2003] "Oracle Application Server Supports Latest Industry Portlet Standards With New Tools." - "Oracle Corporation today announced the availability of preview releases of new Oracle Application Server tools supporting Java Specification Request (JSR) 168 and Web Services Remote Portlets (WSRP). The two portlet standards were developed by the Java Community Process (JCP) and OASIS, respectively. Today's businesses implement numerous applications spanning the organization and multiple lines of business, and portals play an important role in integrating applications and providing a single, consolidated view for end-users. Industry standards such as JSR 168 and WSRP make it possible for an increasing number of applications to be accessible via a portal, increase developer productivity and significantly reduce development costs. The preview release of Oracle's tools supporting JSR 168 and WSRP standards include: (1) Portlet Container for Java: A container that implements the JSR 168 APIs, allowing developers to build interoperable portlets using Java code; (2) Portlet Wizard for Java: An Oracle JDeveloper extension, which provides a wizard-based user interface that quickly defines various characteristics of a portlet such as display modes, customization, translation, security, initialization and caching. Additional portal development resources are available in the Portal Developer Kit, which includes documentation and more than 15 code samples of JSR 168-compliant portlets running in WSRP containers... Prior to the introduction of JSR 168 and WSRP, developers created portlets using proprietary APIs for a single portal platform — requiring a lot of time and greatly limiting the number of portlets available to other portal platforms. For example, developers and portlet resellers who built portlets for one platform had to rebuild the same portlet for each portal platform they supported. JSR 168 and WSRP ensure interoperability among different portal platforms, enabling developers and portlet resellers to build their portlets once with confidence that they will run in all portals that support the standards. The JSR 168 specification defines a standard application programming interface (API) for aggregating several content sources and front-end applications into a single portal. The WSRP standard enables portals to consume portlets from remote locations. Compatible and complementary to each other, the standards enable portal components to be deployed across any platform..."

  • [October 03, 2003] "WSRP Re-Ignites Interest in Portals." By Hitesh Seth (ikigo, Inc). In XML Journal (October 03, 2003). "Web Services for Remote Portlets, or WSRP, was recently approved as a standard by OASIS. Although a number of Web services standards are being worked on by different OASIS technical committees (TCs) — around Web services orchestration, management, security, reliable messaging, and ebXML - WSRP is particularly interesting as it brings out the benefits of open standards-based Web standards to the world of enterprise portals. To understand what WSRP is all about, it's important to understand portals. Consider a financial services company, for example your bank. You typically have a savings and/or checking account. Once you've developed a decent relationship with your bank, you usually end up using additional services such as credit cards, bill payment, mortgage/student/auto loans, and so on. With the advent of e-business computing, a number of these services are available online through your bank's Web site. Typically, since these applications serve an individual purpose, they stand alone and have their own user interfaces. But wouldn't it be nice to have all the applications available in a single application as a bunch of modules, under a common look and feel, using the same user profile information (including user IDs and passwords)? Also, if the various applications were available as 'pluggable modules,' it would be really nice to be able to personalize your view of the bank. The three Ps - presentation, profile, and personalization - are where portal technology began. A portal is a framework that allows a company to create a unified presentation mechanism that is used to deliver key applications in a personalized manner to its users. The users can be customers, employees, business partners, or investors. The mini-applications launched from a portal are specialized views of the main application, providing key information that would be of immediate interest to the user within a unified portal. These mini-applications, or views, are called portlets..."

  • [September 25, 2003]   Web Services at Apache Hosts WSRP4J Open Source Project for Remote Portlets.    The OASIS Web Services for Remote Portlets (WSRP) Specification recently approved as an OASIS Standard is now supported by an open source WSRP4J project organized through the Apache Software Foundation. WSRP "defines a standard for interactive, presentation-oriented web services. It simplifies integration of remote applications/content into portals so that portal administrators can pick from a rich choice of services and integrate it in their portal without programming effort. As a result, WSRP becomes the means for content and application providers to provide their services to organizations running portals in a very easily consumable form. One of several projects in the Apache Web Services area, WSRP4J is a technology donated by IBM and designed to facilitate quick adoption of the WSRP standard by content and application providers and portal vendors. WSRP4J provides the WSRP4J Producer, which allows implementing such WSRP compliant services based on a free, open source software stack consisting of Tomcat, Axis and WSRP4J which in turn includes Pluto, the JSR 168 reference implementation. In addition, the WSRP4J project provides a generic proxy portlet written to the Portlet API, the WSRP4J Consumer. The WSRP4J Project provides two different provider components as well as two WSRP consumers. Each of these components can be installed separately and has different prerequisites."

  • [September 06, 2003] "Portal Vendors Rallying Around Standards." By Dennis Callaghan. In eWEEK (September 5, 2003). "Vignette Corp. became the latest portal software developer to announce new products built on the Web Services for Remote Portlets standard 1.0, which was ratified this week by the Organization for the Advancement of Structured Information Standards (OASIS). WSRP 1.0 can be used for interoperability between .Net and Java-based portal elements. Plumtree Software Inc. announced earlier this week new products that support WSRP 1.0, as well as Java Specifications Requirements (JSR) 168. Vignette plans to deliver beta-level support for WSRP consumption in its Vignette Application Portal during the second half of 2003, company officials said. In the first half of 2004, Vignette expects to continue with support for WSRP consumption and add support for WSRP publishing in Vignette Application Portal and Vignette Application Builder. This support will allow the software to publish, consume and manage remote Web services as portlets within the Vignette portal administration framework, officials said. In Vignette Application Portal, this means organizations will be able to subscribe to compliant Web services, provision those services for any number of portals and deliver visual, user-facing portlets to end users. Vignette Application Builder support for WSRP will allow organizations to produce customized portal applications that take advantage of existing enterprise application data and can be consumed by any compliant portal server, Vignette officials said. Plumtree earlier this week released the WSRP Portlet Consumer, a software component that acts as the intermediary between the portal and the raw WSRP portlet, or WSRP producer. The Plumtree WSRP Portlet Consumer can run on the same platform as the producer, on the portal, or on a middle tier between the portal and the WSRP producer, so that customers can scale the portal deployment to many business units, each with their own portlets... Both Plumtree and Vignette are also supporting JSR 168, which is nearing completion by the Java Community Process. The proposed standard is designed to establish a common interface for portlets to enhance efficiency of application delivery through portals..." See also: (1) OASIS Web Services for Remote Portlets TC website; (2) "JSR 168 Portlet API Specification 1.0 Released for Public Review."

  • [September 3, 2003] "Plumtree Ships Products to Fully Support WSRP and Proposed JSR 168 Portlet Standards. Plumtree's Standards Implementation Consumes Portlets from BEA, Citrix, IBM, and Oracle." - "Enterprise Web leader Plumtree Software today released new software to support Web Services for Remote Portlets (WSRP) from OASIS and the proposed final draft of the Java Specification Request 168 (JSR 168) portlet standard. Plumtree is one of the first software vendors to release products for supporting the new WSRP and the proposed JSR 168 portlet standards, and one of the only vendors to build and test those products for use on application servers from several different vendors. For both standards implementations, Plumtree's support extends to versions 4.5, 4.5WS and 5.0 of the Plumtree Corporate Portal. The standards are important to Plumtree because they free customers from basing technology decisions on whether a vendor's proprietary conventions will prevail in the market: a customer investing in Plumtree's industry-leading Enterprise Web software can now develop industry-standard portlets, and ensure that the investment can be put to work within virtually any portal..."

  • [August 01, 2003] "Portal Standards Take Flight. Vendor Frameworks to Support JSR 168 and WSRP." By Cathleen Moore. In InfoWorld (July 30, 2003). "As two key specifications approach final status, portal vendors are stitching in standards-compliant APIs for delivering content and applications into the portal framework. Both JSR (Java Specification Request) 168 and WSRP (Web Services for Remote Portals) are on pace for final release between mid-August and early September [2003]. JSR 168, shepherded by the Java Community Process, was created to establish a standard portlet programming API. The Organization for the Advancement of Structured Information Standards' (OASIS) WSRP specification, meanwhile, leverages Web-services standards to integrate remote content and applications into portals. Sun Microsystems, IBM, Vignette, Plumtree Software, and BEA Systems are outfitting support into their portals... Leading the pack, Sun last month kicked off the beta release of its Sun ONE Portal Server 6.2, which includes support for JSR 168 via an early-access version of the Sun ONE Portlet Builder 2.0. The final release of the portal, due in September, will include the full JSR 168 implementation, and support for WSRP will be added in the first quarter of 2004, Sun officials said. IBM this month plans to roll out Version 5.0 of its WebSphere Portal featuring an open source implementation of JSR 168. After the JSR 168 and WSRP specs are finalized, IBM will furnish support for both via an incremental update..."

  • [July 22, 2003] "WSRP: The Web Services Standard for Portals." By Lowell Rapaport. In Transform Magazine (July 2003). "Let's say you have a Web portal that distributes data originating from a remote third party. If the remote application is a Web service, then the portal application can address the service's API. Formatting and displaying the data returned from the Web service is the responsibility of the portal. This is fine if you have just one or two remote Web services to incorporate into your portal, but what happens if you have a dozen? The greater the number of Web services, the higher the cost of integration. Web Services for Remote Portals (WSRP) is an emerging standard designed to simplify integration. WSRP is expected to cut portal development costs by standardizing the way a remotely executed portlet integrates with a portal. WSRP specifies how a Web service downloads its results to a portal in HTML via simple object access protocol (SOAP. The specification's goals are similar to JSR 168: both promote the standardization of portlets. 'JSR 168 and WSRP are closely related,' says Carol Jones, chief architect of the WebSphere Portal at IBM. 'Portlets written in JSR 168 will be WSRP compatible. 168 deals with the life cycle of a portlet -- what gets called when it's time for it to render itself. WSRP addresses how you take a portlet and use it on a different portal. Once WSRP is adopted, users should be able to take a portlet from one company's product and install it in another.' JSR 168 integrates portals and portlets at the application layer while WSRP works at the communications layer. Based on XML and SOAP, WSRP portlets are transferred over the Internet using hypertext transfer protocol and don't require any special programming or security changes to a consumer's firewall. If a JSR 168 portlet is run remotely, the consumer's firewall has to be modified to support distributed Java applications. WSRP is inherently distributed..." See: (1) OASIS Web Services for Remote Portlets TC; (2) WSRP specification advances toward an OASIS Open Standard; (3) "JSR 168 Portlet API Specification 1.0 Released for Public Review."

  • [July 18, 2003]   JSR 168 Portlet API Specification 1.0 Released for Public Review.    The release of the JSR-000168 Portlet API Specification 1.0 Public Review Draft has been accompanied by announcements for a Sun ONE Studio Portlet Builder beta and a pre-release of Oracle9iAS Portal's WSRP Portal. The JSR-000168 Portlet Specification has been distributed as a PDF Portlet Specification with code and reference in Portlet API Specification Interface Classes and Portlet API Javadoc Documentation. The Portlet Specification defines a proposed standard for the Java portlet API as outlined in the JSR 168 Java Specification Request, designed to "enable interoperability between portlets and portals by defining a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security." A portal in terms of this specification is a web based application that "provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users, and portal pages may have different set of portlets creating content for different users. A portlet is a Java technology based web component, managed by a portlet container, that processes requests and generates dynamic content. Portlets are used by portals as pluggable user interface components that provide a presentation layer to Information Systems." The intended audience for this specification includes "portal server vendors that want to provide portlet engines that conform to this standard, authoring tool developers that want to support web applications that conform to this specification, and experienced portlet authors who want to understand the underlying mechanisms of portlet technology." The Portlet Specification Public Review Draft has been edited by Alejandro Abdelnur (Sun Microsystems) and Stefan Hepper (IBM) with input from the JSR 168 Expert Group. The public review period ends 16-August-2003.

  • [March 17, 2003] "WSRP an Oasis for Portal Deployment." By David Rubinstein. In SD Times (March 17, 2003). "An industry specification for the consumption of Web services in portal front ends, as well as to standardize the way in which content providers write Web services for portals, is advancing through the OASIS standards group, with the technical committee finishing up its work sometime this month... The specification, Web Services for Remote Portals (WSRP), seeks to define a way for Web services to plug into portals, according to Thomas Schaeck, IBM Corp.'s architect of the WebSphere Portal Server and chairman of the OASIS technical committee. Some 25 companies are working through OASIS (www.oasis-open.org) on the effort. 'Perhaps you want to display weather information or stock quotes in a portal,' Schaeck said. 'You would need to write portlets to display each of these. Also, the portals themselves have different APIs, and content providers have to write seven or eight versions of the same portlet for each portal vendor.' Before this effort, he explained, special adapters had to be written to allow portlets to be compatible with numerous portals. Among the goals, Schaeck said, are creating directories of WSRP services that allow services to be plugged into portals without any coding needed, and to allow portals to publish portlets for use in other portals. 'WSRP will create a standard set of operations, and define how to use the operations in a certain order under the WSRP protocols.' Further, he explained, WSRP will establish markup fragment rules that must be adhered to for aggregation within a portal to maintain the correct look and feel. Definitions for HTML and XHTML are the first priority, with WML and Voice XML coming later on, according to a document provided by the OASIS WSRP technical committee. Kinzan Inc., which is on the OASIS committee working on WSRP and Web Services for Interactive Applications (WSIA), believes the standards will help define how a portlet installed in one server can be rendered in another without having to deploy it to the second server, according to director of product marketing James O'Leonard. WSRP also seeks to define how a service is published to a UDDI directory, where it can be found and bound into a portal, Schaeck said..."

  • [January 30, 2003] "Human-Facing Web Services, Part 3. Build Portals with WSRP." By Judith M. Myerson (Systems Architect and Engineer). From IBM developerWorks, Web services. January 2003. ['In the first two articles in this series, Judith Myerson examined business users' collective viewpoints on how Web pages and remote portals should be presented, and looked at how the WSIA specifications can be used to build human-facing applications. In this third installment, you'll learn how you can use Web Services for Remote Portals (WSRP) to extend the functionalities of the WSXL component services. You'll see sample code that demonstrates how to aggregate interactive applications into a single portal using one standard adapter for different interfaces and protocols.'] "Web Services for Remote Portals (WSRP) is a standard for XML and Web services that allows the interactive, human-facing Web services to be plugged into portals with a minimum of fuss. These services can be published, found, and bound in a standard way. In the days before the advent of WSRP, vendors often wrote special adapters to accommodate different interfaces and protocols and integrate applications into a single portal, which created a confusing environment for developers. In January 2002, the Organization for the Advancement of Structured Information Standards (OASIS) formed the WSRP Technical Committee as an effort to standardize an adapter for these vendors. In that same month, OASIS also formed the Web Services Component Model Technical Committee; it aimed to create a standard component model under which developers could put together visual presentation and portal components. In May 2002, OASIS changed the name of this group to the Web Services for Interactive Applications Technical Committee (WSIA TC) to better describe the purpose of its work. The renamed committee has broadened its focus from the appearance of applications to the applications' complete interactive, human-facing experience. On September 30, 2002, the WSIA and WSRP technical committees jointly announced the WSIA-WSRP Core Specification, Working Draft 0.7. This document proposed a standard adapter that vendors can employ to mix, match, and reuse human-facing interactive Web service applications from different sources... WSRP lets you use an adapter code you can plug in to applications from any Remote Portlet Web Service. With this standard, you can implement a Remote Portlet Web service as a Java/J2EE-based Web service, a Web service implemented on the Microsoft .Net platform, or as a portlet published by a portal. To help applications, clients, and vendors to discover and display your Remote Portlet Web Services, you can publish them into public or corporate service directories (that is, UDDI). Remote Portlet Web Services are the key to portals, since they can be consumed by intermediary applications across platforms. With these remote Web services, during an operation a portal can: (1) Get information from data sources; (2) Aggregate information into composite pages; (3) Provide personalized information to users in an interactive fashion... WSRP provides a single adapter for different interfaces and protocols for human-facing Web services. The recent WSIA-WSRP Core Specification is indicative of the trend toward user control standards for human-facing interactive Web services. These standards, for example, could aim at the behaviors (such as color or font size) that users might want to control in a standardized way..." Also in PDF format.

  • [November 02, 2002] "Building Interactive Web Services with WSIA and WSRP." By Eilon Reshef (WebCollage). Draft article posted to the OASIS WSRP-WSIA list. 5 pages. ['Draft of document to be a WSJ feature. Provides background on the upcoming WSIA/WSRP standards. The article was written prior to the formal closing of the spec, so one may eventually expect minor discrepancies between the two, although the article does not go into the level of detail in which current issues are being debated. I tried to present the topics as objectively as possible, although naturally also to present my own views on the protocols and how they fit into what organizations are doing today.' - author's note in post] "Web Services for Interactive Applications (WSIA) and Web Services for Remote Portals (WSRP) are standards for user-facing, presentation-oriented, interactive Web services intended to simplify the creation of distributed interactive applications. With WSIA and WSRP, Web services include presentation and multi-page, multistep user interaction. This lets service users plug them into sites and portals without custom development and to leverage new functionality available in future versions of the service without the need for additional custom development... WSIA and WSRP stem from parallel efforts initiated in the middle of 2001. Portal vendor Epicentric spearheaded the Web Services User Interface (WSUI) initiative to address the lack of a standard user-interface layer as part of the Web services stack. IBM initiated its own effort: Web Service eXperience Language (WSXL). WebCollage, a software vendor providing a platform for integrating interactive Web applications, wanted to standardize its customer implementations based on an initiative called Interactive Web Services. In parallel, many portal vendors recognized the need to address the same problem in the context of portal toolkits: how to quickly plug remote interactive services (called "portlets") into a portal without custom programming for each remote service. The efforts were consolidated into two working groups under the umbrella of OASIS, the organization behind ebXML and other XML-related standards. WSIA focuses on the framework for creating interactive Web services, and WSRP defines the interfaces to include portal-specific features. Today the working groups include more than 30 industry-leading vendors from different industry segments: application server vendors (BEA, IBM, Oracle, Novell, Sun), pure-play portals (Epicentric, Plumtree), interactive application integration vendors (WebCollage, Kinzan, Citrix) and enterprise application providers (Peoplesoft, SAP). Version 1.0 of the specifications includes the interfaces common to the two groups, and is currently in a review process... WSIA and WSRP define a set of APIs that allow developers to produce and consume remote interactive Web services. They define three types of actors: (1) Producer: Represents the service provider hosting the remote interactive Web service (for example, weather.com as a weather service provider). (2) Consumer: Represents the entity integrating the remote service into its Web application, oftentimes using a portal toolkit (for example, Yahoo Weather or a corporate portal). (3) End User: Represents the person that comes to the Consumer Web site to use the Producer's application in the Consumer's context. In a nutshell, WSIA and WSRP fulfill the following roles: (1) Define the notion of valid markup fragments based on the existing markup languages such as HTML, XHTML, VoiceXML, cHTML, etc. (2) Provide a set of standard calls to enable a Consumer to request these markup fragments from a Producer based on the existing state. (3) Supply a set of calls that support the concept of multi-step user interaction and preservation of state across those calls. There are four central parts to the WSIA and WSRP APIs: (1) Retrieving markup fragments (encapsulated in the getMarkup() call). (2) Managing state (3) Handling user interaction -- encapsulated in the performInteraction() call; (4) Supporting customization and configuration..." Source: see the posting and mail archives URL.

  • [July 12, 2002] "Overview of WSRP and JSR 168 Standards. An interview with Michael Freedman." Oracle Corporation. July 12, 2002. ['Oracle is playing an important role in the formation of industry standards through two standards initiatives, OASIS WSRP (Web Services for Remote Portals) and JSR168(Java Specification Request for portlet API). You may have heard about this, and may be wondering like many others, what all the hue and cry about industry-wide standards is for? What is WSRP and how is it going to effect you? How do WSRP and JSR168 relate to each other? How is Oracle9iAS Portal providing an open framework and what can you expect in the future? To answer your questions about the standards initiatives that Oracle Corp. is participating in, read on and find out what Michael Freedman has to say. Michael Freedman, Oracle's representative in the two standards initiatives, WSRP and JSR168, designed and implemented the original Oracle 9iAS Portal web provider. A consulting technical staff, Michael has over 20 years of development experience in a variety of industry environments including Xerox, Sun Microsystems, and the startups GO and Slate. He has worked at Oracle for 8 years on a variety of projects including interactive television, the application server, and the wireless portal.'] "...WSRP provides interoperability between differing vendors portals and remote portlets written to run in a web services environment. Specifically, WSRP is defining the web services standard for communicating between a portal and remote portlets. Oracle9iAS Portal's web provider infrastructure currently relies on web service technology for this communication, however because there hasn't been a standard, it relies on its own proprietary protocol. This means that portlets developed in Oracle9iAS Portal's web provider environment don't run in non-Oracle9iAS Portals. Likewise, remote portlets developed for non-Oracle9iAS Portal remote environments don't run in Oracle9iAS. The interoperability of a standard such as WSRP overcomes these limitations. From an Oracle9iAS Portal architecture perspective, WSRP fits where the current web provider SOAP interface sits. It defines the set of [SOAP] calls made from the portal to the remote portlet. Like our current web provider SOAP interface, it is designed for efficiency and scalability vs. usability. Again, like our current implementation, it expects developers interfaces to be layered on top of the SOAP service that implements this interface providing a simple, convenient, and usable portlet API to developers. In this sense portlet developers should never see [or need to learn] about WSRP as they will be insulated from it by another API... JSR168 defines the portlet interface Java developers will use to build portlets. When used in a remote environment, it is the standard interface a Java based WSRP service exposes. It is the equivalent of the current Oracle9iAS Portal's web provider Java API. This means that of the two specifications developers should focus on JSR 168. It will become the standard Java programming interface for portlets. WSRP is more of a concern for Portal developers that want to support interoperable remote portlet development in various [language] runtimes..."

  • [June 18, 2002] "IBM Submits Mobile Standard to OASIS." By Ephraim Schwartz. In InfoWorld (June 17, 2002). "The mobile infrastructure may soon have its own Web services protocol defining standard methods for presenting enterprise applications on handhelds. IBM submitted to the OASIS (Organization for Advancement of Structured Information Standards) Web services standards body earlier this month a protocol called WSRP (Web Service Remote Portal) to allow wireless devices to access portlets. A portlet is any application launched from a portal server, according to Rod Smith, vice president of Internet Emerging Technologies, at IBM in Raleigh, N.C... When a device calls a portal server, WSRP will tell the server how much screen real estate is available, for example. The portlet aggregates information to build a page and generates it in XML. WSRP would sit on top of SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language) layers. 'The idea is to make a portlet Web service-ized, and in this way I can generate XML interfaces for voice or other interfaces,' said Smith. But while Smith admitted that WSRP and many of the other middleware protocols are still maturing, one ISV sees the lack of 'mature' standards as a major worry for ISVs..."

  • [April 10, 2002] "Web Services For Remote Portals (WSRP)" - Section 3 in the IBM document Web Services Experience Language (WSXL). See also Appendix D: "WSXL and WSRP Dependency Diagram."

  • [March 08, 2002] "Portal Standards." By Thomas Schaeck and Stefan Hepper. In TheServerSide.com (February 2002). "With the emergence of an increasing number of enterprise portals, a variety of different APIs for portal components, so-called portlets, have been created by different vendors. Similarly, different mechanisms for invocation of remote visual components are being introduced by various vendors. The variety of incompatible interfaces creates problems for application providers, portal customers, and portal server vendors. To overcome these problems, the Java Portlet API and Web Services for Remote Portals (WSRP) standards will provide interoperability between portlets and portals as well as interoperability between portals and visual, user-facing web services. With these standards in place, application providers or portal customers can write portlets, or visual, user-facing web services independent of a specific enterprise portal product. The Java Portlet API will be compatible with WSRP and therefore allow to publish portlets as web services... Web Services for Remote Portals (WSRP) are visual, user-facing web services that plug and play with portals or other applications. They are designed to enable businesses to provide content or applications in a form that does not require any manual content- or application-specific adaptation by consuming portals. As WSRP includes presentation, WSRP service providers determine how their content and applications are visualized for end-users and to which degree adaptation, transcoding, translation, etc. may be allowed. WSRP services can be published into public or corporate service directories (UDDI) where they can easily be found by portals that want to display their content. Web application deployment vendors can wrap and adapt their middleware for use in WSRP-compliant services. Vendors of intermediary applications can enable their products for consuming WSRP services. Using WSRP, portals can easily integrate content and applications from internal and external content providers. The portal administrator simply picks the desired services from a list and integrates them, no programmers are required to tie new content and applications into the portal. To accomplish these goals, the WSRP standard will define a web services interface description using WSDL and all the semantics and behavior that web services and consuming applications must comply with in order to be pluggable; it will also define the meta-information that has to be provided when publishing WSRP services into UDDI directories. The standard allows WSRP services to be implemented in very different ways, be it as a Java/J2EE based web service, a web service implemented on the .NET platform, or a portlet published as a WSRP service by a portal..."

  • [March 26, 2002] Standards for Portals." By Demir Barlas. In Line56 (March 26, 2002). ['IBM, Sun lead efforts to create standard portal API; OASIS working on 'plug-and-play' portals; Oracle tries to put standards into practice.'] "As any e-business application area nears maturity, the question of open standards versus proprietary solutions is bound to arise. In the portals marketplace, the debate is already underway, as IBM and Sun have decided to champion Java-based standards for creating portal APIs (known as 'portlets') while other vendors continue to pursue the proprietary approach in certain aspects of their strategy. Meanwhile, at the very highest level, the OASIS Web Services for Remote Portals (WSRP) Technical Committee, is working on an XML-based Web services standard that could eventually make portals 'plug-and-play,' allowing portlets to interoperate not only across Java-based portals but across Microsoft's .NET platform as well. At the JavaOne conference, IBM and Sun announced that several other portals players -- including Oracle, SAP, BEA, Epicentric, HP, Vignette, and Plumtree -- were part of the Java Portal API initiative, which is known as Java Specification Request (JSR) #168. Furthermore, IBM and Sun intend to use the specification in their own portals... Analyst Mike Gilpin of Giga points out that this addresses the reality faced by enterprise customers, many of who 'may not choose to have multiple portal environments but have them anyway.' This is why, he adds, open standards versus proprietary is a significant issue. 'Sometimes, when [portal customers] move outside a standards-based application server into the portal, standards no longer apply. They can't re-use work done in the portal across different environments or switch to a different environment as easily.' Today, also at JavaOne, Oracle announced that its latest release of Oracle9i Application Server Portal Developer Kit (PDK) 'adheres to the design principles' of WSRP and JSR #168, giving a possible answer to the conundrum faced by enterprises in Gilpin's example. On the WSRP front, PDK uses Web services to power portlets, and it also claims to make it easier for developers to turn Java-based components into portlets. With both the Web services and Java bases covered, Oracle says that PDK effectively allows 'any portlet to be used in any portal,' in the words of John Magee, director of Oracle product marketing..."

  • [March 25, 2002] "OASIS Hones Web Services Standards." By Tom Sullivan and Ed Scannell. In InfoWorld (March 22, 2002). "Looking to take Web services protocols higher up the interoperability stack, two groups within the Organization for the Advancement of Structured Information Standards (OASIS) are developing specifications for content delivery and end-user interfaces. Known as Web Services for Interactive Applications (WSIA) and Web Services for Remote Portals (WSRP), which met this week, the groups were created to advance user-facing Web services and enable Web services and other applications to plug and play with portals and portlets. Building on this momentum, Sun Microsystems and IBM plan to announce on Monday at JavaOne a portlet specification submitted to the Java Community Process (JCP) that complements Billerica, Mass.-based OASIS' WSRP group. Thus far, the core Web services standards -- SOAP (Simple Object Access Protocol), XML, UDDI (Universal Description, Discovery, and Integration), and WSDL (Web Services Description Language) -- have focused on system-to-system interoperability. The standard expected to emerge from the WSIA, however, would improve any service that requires users to fill out online forms, for example, said Dwight Davis, an analyst at Summit Strategies in Kirkland, Wash... recognizing this need, a host of companies have backed the WSIA initiative, including IBM, BEA Systems, Bowstreet, divine, Documentum, Epicentric, and Plumtree. And the lineup of WSRP supporters looks similar, with Documentum, Epicentric, divine, IBM, Sun, Hewlett-Packard, Iona, and Oracle all on board. 'There is a certain set of base functions that we are trying to do jointly between the two committees, and then WSIA will try to go beyond that and do some things that are not required for portals,' explained Charles Wiecha, manager of the next-generation user experience frameworks department at Yorktown Heights, N.Y.-based IBM Research and chair of the WSIA committee. The technologies expected to drive the WSIA standard include IBM Research's WSXL (Web Services Experience Language) and the combined work on Web services graphical interfaces done by Epicentric and divine. IBM has also included in its WSXL proposal plans for XLink (XML Linking Language) to be used to hook together a patchwork of Web services to make them appear as a single application..."

  • [January 30, 2002] "New OASIS Technical Committee Addresses Portal Provisioning." From DelphiWeb.com. 01/30/2002.

  • [January 28, 2002] Announcement "OASIS Members Form Technical Committee to Develop Web Services Standard for Remote Portals. Bowstreet, Divine, Documentum, Epicentric, Factiva, Fujitsu, HP, IBM, Interwoven, IONA, Oracle, Plumtree Software, Reed Elsevier, Reuters, SilverStream Software, and Others Collaborate to Standardize Integration of Visual, User-Facing Web Services in Portals."

  • Web Services Remote Portal TC. Call for Participation 2002-01-21.
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/wsrp.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org