Enabling Interactive, Presentation-Oriented Content Services Through the WSRP Standard Richard Thompson Thomas Schaeck
Abstract The Organization for the Advancement of Structured Information Standards (OASIS)Web Services for Remote Portlets (WSRP) v1.0 specification (an OASIS approved standard) defines an interface and the semantics necessary for content services to be rapidly added to the set of available content at aggregating intermediaries, such as portals. By using web services as the underlying infrastructure, the platform and technologies used to produce this content and handle user interactions with it become independent choices of the content producer and consumer. WSRP uses WSDL to define the interface such that consumers will be able to interact with all such content services using generic means that are service independent. This enables the rapid addition of these services to the set of available content that can be aggregated into end-user pages as it only requires administrative set-up rather than developer effort. WSRP defines the semantics and information exchange required for such areas as; producing presentation markup fragments that can be composed into a page with other fragments (e.g. same mime type, character set), production of URLs within the presentation markup, processing the activation of such URLs and state management of various types (e.g. sessions, navigational state, portlet configuration, etc.). The first version of the specification has focused on making these items work in a manner that can run on today's most popular web stacks (in all cases some bugs were reported and fixes made available). In addition, care has been taken to ensure the concepts and available data are aligned with the requirements of the Java community portlet API specification that was being developed during the same time frame. There currently are vendor implementations interoperating using each of the most popular web stacks. A brief glimpse will also be provided into the ongoing work for defining follow-on versions of the specification. Areas of ongoing work include providing mechanisms for the consumer to coordinate updates to multiple portlets from a single user interaction and defining the markup fragment rules needed in order to aggregate various additional presentation markup types.
Table of Contents 1. Introduction ............................................................................................................................... 2 2. Vision ...................................................................................................................................... 3 3. WSRP Actors ............................................................................................................................ 4 3.1. Portlets ........................................................................................................................... 4 3.2. Producers ....................................................................................................................... 5 3.3. Consumers ...................................................................................................................... 5 4. WSRP Functional areas ............................................................................................................... 5 4.1. Producer/Portlet Description ............................................................................................... 5 4.2. Generating and Interacting with Markup ............................................................................... 6 4.3. URLs ............................................................................................................................. 7 4.4. Look and Feel .................................................................................................................. 8 4.5. Namespacing for the Aggregated Page ................................................................................. 8
Proceedings by deepX Ltd.
XSL• FO RenderX
1
Enabling Interactive, PresentationOriented Content Services Through 4.6. Types of State .................................................................................................................. 8 4.7. Security .......................................................................................................................... 9 4.8. Extensibility .................................................................................................................... 9 4.9. Portlet Lifecycle .............................................................................................................. 9 5. Future Work .............................................................................................................................. 9 6. Useful References ..................................................................................................................... 10 Glossary ..................................................................................................................................... 10
1. Introduction Portals provide personalized access to information, applications, processes and people. Typically, portals get information from local or remote data sources, e.g. from databases, transaction systems, syndicated content providers, or remote web sites. They render and aggregate this information into composite pages to provide information to users in a compact and easily consumed form. In addition to pure information, many portals also include applications like e-mail, calendar, organizers, banking, bill presentment, host integration, etc. While different rendering and selection mechanisms may be required for different kinds of information or applications, all of them rely on the portals infrastructure and many operate on data or resources owned by the portal, like user profile information, persistent storage or access to managed content. Consequently, most of today's portal implementations provide a component model that allows plugging components, referred to as portlets, into the portal infrastructure. Portlets are presentation-oriented, interactive web application components rendering markup fragments to be aggregated and displayed by the portal. Often content is provided by external services and displayed by specific local portlets running on the portal. While this approach is feasible for establishing the base functionality of a portal, it is not well suited to enabling dynamic integration of business applications and information sources into portals. As an example, let us consider the following scenario: An employee portal manager wants to include a human resources service calculating estimated retirement benefits for employees and an external weather service providing weather forecasts. One solution for this scenario is depicted in Figure 1 where a human resources portlet and a weather portlet run locally on the portal server and access remote web services to obtain the required information, i.e. the web services provide data and the presentation layer is implemented in specific portlets.
Figure 1. Local portlets using remote web services The HR portlet uses a HR web service to calculate the estimated retirement benefits. By default, it displays a form to query the required input data, e.g. the employee's id. When the employee provides the data to the HR portlet, it invokes the HR web service to calculate the estimated retirement benefits based on that data. It receives the result from the web service and displays it as a page fragment. The weather portlet by default displays weather forecasts for configurable locations and allows the user to select locations in an edit mode. When the weather portlet is invoked during page aggregation, it requests the most recent forecasts for the selected locations from the weather web service and renders a page fragment that displays those forecasts. This approach only works if all portlets are physically installed at the employee portal; the process of making new portlets available is tedious and expensive; the presentation layer has to be re-developed for each portal. To integrate HR information in the portal using local portlets as described above, either the HR department would implement the HR portlet and give it to an administrator of the employee portal to install, or an employee portal developer would implement the HR portlet according to the interface description of the HR web service, similar effort would be required for the weather portlet. In each case, there is significant cost and loss of time.
Proceedings by deepX Ltd.
XSL• FO RenderX
2
Enabling Interactive, PresentationOriented Content Services Through Obviously, it would be much more convenient if the HR and weather web services would include application and presentation logic and directly produce markup fragments that are easy to aggregate at the consuming portal, as shown in Figure 2.
Figure 2. A portal using WSRP Instead of just providing raw data or single business functions that require special rendering on the portal side, WSRP enables remote presentation-oriented, interactive web services. These services are easy to aggregate and can be invoked through a common interface using generic, portlet-independent means that are built into the portal. In addition, re-implementation of the presentation layer on each portal is avoided. The use of generic portlet proxies consuming all WSRP services conforming to the common interface eliminates the need to develop servicespecific portlets to run on the portal. The task of the administrator is also made easier because portlets can be added dynamically to the environment, and users benefit by having more services made available to them in a timely manner. Administrators can integrate WSRP services into a portal using their portal's administration user interface to find and bind these services with just a few mouse clicks. As a result, the portal binds a portlet proxy to the WSRP services so that they are available to users in the same manner as local portlets. The remainder of this paper explains the WSRP vision, the actors defined by the WSRP specification, provides an overview of the basic WSRP functional area and current efforts for follow-on versions.
2. Vision Web services have introduced a standardized means of integrating business logic via the Internet. The WSRP standard leverages this to provide the means for integrating of web service based presentation components. WSRP provides a standard that enables all content and application providers to provide their services in a manner where they can easily be discovered and plugged into all compliant portals without additional programming effort on the portals side. Portal implementations can enable portal administrators to find and integrate WSRP services with just a few mouse clicks, typically by using their portals administration user interface to locate WSRP services and then select some for automatic integration into the portal. Portals act as intermediaries between end users and WSRP services and aggregate services from many different content providers. They often offload significant traffic from content providers by caching content, thereby enabling content providers to serve a huge number of users with little IT infrastructure. This vision is being realized as a number of vendors have been participating in interoperability testing. As these products become deployed and WSRP used to access remote portlets, a number of benefits can be expected to accrue quickly, namely: •
Content sources exposed using WSRP will find larger audiences as they are available to add to a larger set of portal pages.
•
Content sources will be able to better manage the deployment and upgrading of their service by retaining direct control over those processes.
•
Portal server deployments will be able to provide access to a much larger set of content sources without the deployment and maintenance issues of locally hosting a portlet providing access to just that content source.
Proceedings by deepX Ltd.
XSL• FO RenderX
3
Enabling Interactive, PresentationOriented Content Services Through •
Users will find a larger set of content readily available for adding to their portal pages. This will make those pages more valuable to the user as a larger set of the content they normally prefer to receive becomes available in a single place.
3. WSRP Actors WSRP defines three actors for the interchange needed to generate, aggregate and then process interactions with the markup presented to an end-user. These actors are called Portlets, Producers and Consumers and will be discussed individually in the following sections.
3.1. Portlets Portlets are presentation-oriented, interactive web application components designed to be aggregated and to communicate with users through the hosting portal server. Typically, portal servers maintain a catalog of available portlets from which end users can select portlets for placement on portal pages. WSRP enables portal servers to use generic means for accessing portlets not hosted locally. This significantly reduces the cost of moving to a portal server deployment model where many portlets are hosted remotely, often to reduce deployment and maintenance issues. All Portlets, whether local or remote, support a View mode, in which they provide their primary functionality; ranging from rendering static markup to a highly interactive application with a sophisticated screen flow. In addition, portlets may support an Edit mode that provides a portlet specific user interface to edit their configuration data, a Help mode that explains how the portlet should be used and a Preview mode that renders a preview of the portlets appearance. In addition to the different modes, portlets can typically be displayed in different sizes, namely Minimized, Normal, Maximized and Solo. A typical example for a portlet with multiple views that can be rendered in varying sizes is the market report portlet depicted in Figure 3. In the view mode in normal size, it displays stock quotes for a list of stock symbols; if the user wants to view details, s/he clicks on the Market Details link which directs the portlet to display an expanded set of information, but remain in the view mode. In the edit mode, accessed by clicking on the Edit button, the user can customize the list of stock quotes displayed. In the help mode, accessed by clicking on the question mark in this example, the portlet informs the user how it works. By clicking on the minimize or maximize buttons, the user can switch the portlet to a minimized or maximized size, respectively.
Figure 3. Example of a Portlet Portlets can maintain state at different levels: Transient Session State is typically used to reflect conversational state with a particular end user and persistent Configuration State is used to remember settings to reuse in later sessions as well. In the example above, the portlet uses transient session state to remember whether it is in the stock quote list screen or the details screen for each end user and persistent configuration state to store both the list of stock symbols a user is interested in and the stock quotes feed to use. WSRP defines these types of state as well as others related to navigation and interaction. Portlets may be local or remote to a portal server. We envision that typically, portals will use a mix of local and remote portlets depending on individual tradeoffs between proximity to the portal server and ease of integration. Local portlets are usually tightly integrated with the portal server and typically run on the same physical server or cluster of servers. WSRP services run on remote servers at other places in the intranet or the Internet and are loosely coupled to the portal server.
Proceedings by deepX Ltd.
XSL• FO RenderX
4
Enabling Interactive, PresentationOriented Content Services Through Most portal clients access the portal via the HTTP protocol, either directly or through appropriate gateways like WAP gateways or voice gateways. The mark-up languages used by these devices may be very different. WAP phones typically use WML, iMode phones use cHTML, voice browsers use VoiceXML while the well-known PC web browsers use HTML. WSRP defines a required field which carries the possible mime types the Consumer can aggregate into the page it is preparing for presenting the interface to its portlets.
3.2. Producers WSRP models Producers as "containers of Portlets". In additions to any local services the Producer may offer these portlets, it provides a set of web service interfaces for the use of WSRP Consumers, including: •
Self Description: A required interface that allows Consumers to find out the capabilities of the Producer and about the Portlets it hosts, including the metadata necessary for a Consumer to properly interact with each Portlet.
•
Markup: A required interface used to request and interact with markup fragments.
•
Registration: An optional interface used to establish a relationship between a Producer and a Consumer (e.g. for billing or book-keeping purposes).
•
Portlet Management: An optional interface that grants access to the life-cycle of the hosted Portlets. This interface also includes Property Management, which enables programmatic access to a Portlet's persistent state.
In order to allow different levels of sophistication for both the Producer and Consumer, parts of this functionality are optional. Various examples of how a Producer might implement particular functionality for varying levels of sophistication are being developed by the TC in the form of Use Profiles. The Producer optionally manages Consumer registrations. The Producer may require Consumers to register prior to discovering and interacting with Portlets. A registration represents a relationship (often including both technical and business aspects) between the Consumer and Producer. When such a relationship exists, it scopes all the interactions between the Producer and Consumer.
3.3. Consumers A Consumer is an intermediary system that communicates with Producers (and indirectly, the Portlets they host) on behalf of its users. It gathers and aggregates the markup delivered by the Portlets and presents the aggregated page to its user. Because of this intermediary role, Consumers are often compared to message switches that route messages between various parties. One typical Consumer is a portal, which mediates generation of markup and the interaction with this markup between users and presentation-oriented web application components. Since the Consumer is an intermediary, aggregating system, the markup sent for display to the user and most interactions with that markup flow through the Consumer. This often results in situations where the user implicitly trusts the Consumer to respect their privacy and security concerns with regards to this information flow.
4. WSRP Functional areas While the following does not cover all the details of WSRP's functional areas, it does attempt to organize and provide a high level view of what each functional area provides.
4.1. Producer/Portlet Description This area involves means by which a Consumer can discover the capabilities of both the Producer and the Portlets it hosts. This information is made available as metadata which the Consumer can get using either the getServiceDescription (for the Producer's metadata) or getPortletDescription operations. Examples of the available information include: •
Does the Producer require Consumers to register? (the "requiresRegistion" field)
Proceedings by deepX Ltd.
XSL• FO RenderX
5
Enabling Interactive, PresentationOriented Content Services Through •
Does the Producer need assistance in establishing a cookie to be used for routing subsequent requests to the same node within a cluster of servers? (the "requiresInitCookie" field) This piece of metadata was added due to the complexity required of a Producer to properly handle multiple parallel initial requests to a set of portlets using some Producer supplied means for sharing data. Rather than requiring this complexity of all Producers deployed in such a clustered configuration, the Consumer is required to provide a single invocation whereby the cookie typically used in such clustered configurations can be established.
•
What customized data values does the Producer support? These are carried in a variety of arrays of type ItemDescription. Each of these arrays provides for the description of different types of extended data (e.g. custom modes). For those areas where this information is provided, Portlets are not allowed to use extended values the Producer has not described. This restriction allows the administrator of the Consumer to determine a mapping of these values to those supported by the Consumer implementation.
•
What Portlets does the Producer host? (available as an array of PortletDescription structures, each of which describes a single offered portlet)
•
For each Portlet (returned in the offeredPortlets array by getServiceDescription or the portletDescription field returned by getPortletDescription): •
How can the Consumer reference this portlet? (the field "portletHandle")
•
What markup types can this portlet generate? (the array "markupTypes") Note that for each markup type, the supported modes, window states and locales are specified.
•
What does this portlet provide? (the localized field "description")
•
What shorthand can the Consumer use to describe this portlet? (the localized field "shortTitle")
•
Will this portlet generate any (x)html forms which use method=get to submit the input data? (the boolean "usesMethodGet" field) This metadata was added due to the difficulties introduced by the means in which browsers typically handle this situation. The browsers tested all dropped any query string on the URL to submit before generating a query string reflecting the data entered into the form's fields. Since many Consumers will prefer to encode information such as what portlet this interaction should be directed to within the query string, knowledge of whether or not a portlet must be handled in a special manner is needed. While there are a variety of choices available to Consumers for handling these types of portlets, in general some form of encoding this information into the path of the submitted URL is needed. Depending on the infrastructure underlying the Consumer, this might not be possible.
4.2. Generating and Interacting with Markup The basic operation for generating markup is getMarkup. This operation is supplied all of the stateful information discussed below and data needed for generating markup that can be aggregated into the page for the end-user. Examples of this data are: •
What markup types the Consumer can process and aggregate into the markup type of the page be prepared for the end-user.
•
What user agent is processing the markup for presentation to the end-user.
•
What is the order of locale preference for the returned markup.
•
What mode and window state will be used for presenting the portlet's markup.
•
What character sets can the Consumer process into the character set of the aggregated page
•
What modes and window states would it be reasonable for URLs within the markup to request for future viewing of the portlet's markup.
Proceedings by deepX Ltd.
XSL• FO RenderX
6
Enabling Interactive, PresentationOriented Content Services Through When the MarkupContext structure is returned to the Consumer, it may contain information controlling the cacheability of the markup. The basic caching definitions in WSRP v1.0 are that markup can be supplied from a cache provided: 1.
The markupParams that would be used for generating new markup are the same as those that generated the cached markup.
2.
The time specified for when the markup expires has not elapsed.
3.
If the expires time has elapsed, the Consumer may supply whatever validateTag was returned with the markup. The Portlet then has the opportunity to direct the Consumer to use the cached markup rather than generating new markup.
Interactions with markup in general fall into two categories: 1.
Generate new markup. These types of interactions are effectively links to new pages and do not change the state of the portlet.
2.
Logical actions. These types of interactions update the state of the portlet. Markup generated for the ensuing page refresh will then reflect this updated state.
How to specify which of these two types of interactions is discussed in the next section as it involves the "wsrpurlType" portlet url parameter.
4.3. URLs The difficulty with URLs is that in general they need to point at the Consumer so that the Consumer can supply any stateful data needed for interacting with the Portlet and the Consumer then needs to direct the interaction to the proper Producer/Portlet. This results in a scenario where the Portlet knows the details needed for this particular URL while the Consumer controls the overall format and target of such URLS. WSRP defines two solutions to this issue:
Consumer rewriting of URLs. •
This solution uses a specification defined format for URLs that allows the Consumer to easily find and replace these URLs. This solution provides places for all data items that a portlet may write to a URL and expect to receive back when the URL is activated.
URL templates •
This solution has the portlet specify whether or not it is willing to do template processing as the means to generate proper URLs. Portlets making this choice are offloading the need for the Consumer to parse the markup in favor of additional processing on the part of the Producer/Portlet.
Another aspect of generating proper URLs relates to what the Consumer should do when the URL is activated. WSRP defines a portlet url parameter called "wsrp-urlType" to carry this information. This parameter can take one of three values: •
blockingAction: This value tells the Consumer that this interaction is a logical update to the portlet's state and therefore it must invoke performBlockingInteraction.
•
render: This value tells the Consumer that this interaction is a request to render a new page from the portlet and therefore it must invoke the getMarkup operation.
•
resource: This value tells the Consumer that this interaction is a resource to the portlet's markup (e.g. a gif) which the portlet is asking the Consumer to proxy for it. The Consumer is supplied the actual URL for the resource as well and therefore can easily act as this proxy.
Proceedings by deepX Ltd.
XSL• FO RenderX
7
Enabling Interactive, PresentationOriented Content Services Through
4.4. Look and Feel As the markup from a portlet gets included on different pages from different Consumers using different layouts and color/font schemes, a reasonable means for producing markup that adapts to these differences is important. WSRP has defined a set of CSS classes which each Consumer is required to support. Use of these classes therefore allows the Consumer control of the overall look and feel while the portlet retains control of its content and finegrained layout questions.
4.5. Namespacing for the Aggregated Page When a third party (such as a Consumer) is aggregating markup from disparate sources into a single display page, collisions on things such as the naming of JavaScript variables or functions, id attributes, etc can not be ignored. There are a lot of similarities between this and URL generation, namely; the Portlet knows what items within its markup should be namespaced while the Consumer is the one able to generate a unique namespace for each instance of every portlet on a page. WSRP addresses this question in a manner similar to URL generation. The portlet can direct the Consumer to write a namespace value in it markup by using the string "wsrp_rewrite_" wherever the namespace is needed. This value is chosen in a manner that allows Consumers to do this rewriting in the same pass through the markup that is used for URL rewriting. The second alternative is that whenever a portlet says it is willing to do template processing (i.e. potentially eliminating the need for the Consumer to do a parsing of the markup), the Consumer is required to supply a value for the "namespacePrefix" field in the RuntimeContext structure.
4.6. Types of State In the process of defining WSRP, a number of different types of state were defined: •
Registration state: This persistent state holds the data relative to the Consumer's registration with the Producer. It only appears in the protocol if the Producer pushes it to the Consumer for storage. This option was made available such that the deployment needs of a simple Producer could be kept quite small.
•
Portlet state: This persistent state holds the configuration data for the portlet. It appears in the protocol to handle both the case of the simple Producer and Producers that are likely to have unique portlet configurations for every user accessing it. An example of such a portlet would be a stock quote portlet storing the symbols a user has configured in its portlet state.
•
Navigational state: This transient state holds whatever the portlet needs to remember about how the user got to the currently displayed markup. Another way to say that is that this state stores the transient data needed to generate the current markup. As such, it is a rough corollary to the URL for a web page. In addition to navigational data, this tends to be where a "stateless" portlet stores the state it needs in order to properly handle the next interaction.
•
Interaction state: This transient state was added so that portlets would not have to convolute their navigational state with the stateful information needed to process a performBlockingInteraction invocation. The distinction to make relative to navigational state is that this state is only passed to the original invocation and not when regenerating the markup (e.g. upon a page refresh).
•
Session: This transient state is stored on the Producer and referenced via an id. The Producer provides this id to the Consumer when a session is initiated and the Consumer then resupplies it on subsequent invocations.
•
Cookies: Cookies are not directly represented in the protocol, but the WSRP v1.0 specification does recognize that many applications today use cookies to store various types of state. Consumers are restricted by the standard cookie rules as to when and to whom these cookies are to be supplied. One caveat to note is that web applications today use cookies to not just store state for their own use later, but also to share that state with dynamic resources. Consumers are encouraged to supply a portlet's cookies to any referenced resources whenever the cookie domain rules allow such sharing.
Proceedings by deepX Ltd.
XSL• FO RenderX
8
Enabling Interactive, PresentationOriented Content Services Through
4.7. Security As the WSRP Technical Committee examined the security aspects of the protocol, it was determined that there was significant, and likely sufficient efforts happening to define security layers that would operate below to protocol to provide the necessary security measures. For the v1.0 specification, it was determined that the message level security standards (see the OASIS Web Services Security TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss) were still under development and not sufficiently supported by the common web stacks for WSRP v1.0 to require support for them. As a result, the underlying transport level security is the defined means to achieve secure communications for WSRP v1.0 though it is expected that messgae level support will also be specified in a future version.
4.8. Extensibility There are two forms of extensibility for WSRP: 1.
Additional operations: Producers are always free to define a WSDL that contains operations not defined by WSRP. It should be noted that any Consumer using generic means to access WSRP Producers are likely to ignore these additional operations.
2.
Additional data items: Almost every data structure the WSRP specification defines contains an extensibility element that allows Producers and Consumers to supply context-sensitive data beyond that which the specification defines.
4.9. Portlet Lifecycle The portlet lifecycle starts with its declaration in the Producer's metadata to be a hosted portlet. In general these published portlets should be considered to not be configurable, though one could envision a scenario where a unique configuration per Consumer registration is possible (requires pushing the portlet state to the Consumer or doing a multi-key lookup on the Producer). In general, unique configurations happen when a portlet is cloned, either by an explicit invocation of the clonePortlet operation or by the "clone-on-write" semantics of the performBlockingInteraction operation. In either case, once a clone is generated it may be uniquely configured in any of several ways. These include the Consumer invoking the portlet property operations, the user interacting with the portlet in "Edit" mode or normal invocations of performBlockingInteraction causing configuration updates. A cloned portlet's lifecycle ends either when the Producer decides to throw away the clone or when the Consumer invokes either destroyPortlets against the cloned portletHandle or deregister against the scoping registrationHandle,
5. Future Work Even as vendors are working on implementing WSRP v1.0 (eight known implementations to-date) and the TC works on use profile definitions and conformance assertions to help guide both the production and marketing of those implementations, the TC has also started work on a number of areas where time was lacking relative to defining these things in the v1.0 specification. A few of these areas are: •
Other markup types: While WSRP v1.0 does include fragment rules for generating HTML and XHTML that can be aggregated into pages, we recognize that a number of other markup types are in general use as well. Examples include VoiceXML, used by voice browsers, WML by WAP phones and cHTML by i-mode phones.
•
Additional CSS classes: WSRP v1.0 is deliberately light on its definition of CSS classes as it is difficult to remove these once they are defined. The TC plans to monitor uses of additional classes across all vendors willing to share this information as a means of expanding these definitions to a more comprehensive set.
•
Use of Registries: WSRP v1.0 does not address how a Producer may publish information about itself to any of the standard registry types so that Consumers can easily find the Producer when doing a registry search. Work has begun to define what information should be published with the intent to then map that information into specific fields defined by the registry standards.
Proceedings by deepX Ltd.
XSL• FO RenderX
9
Enabling Interactive, PresentationOriented Content Services Through •
Leverage Attachment mechanisms: As the XML Protocol Working Group at W3C and WS-I v1.1 of the Basic Profile define standard mechanisms to attach non-SOAP messages to a SOAP invocation, it is expected that WSRP will seek to exploit those mechanisms for those items in the protocol which can easily get quite large and/or often need significant escaping to include into a SOAP message.
•
Cross-Portlet Coordination: WSRP v1.0 defines what is necessary for Consumers to aggregate a page, present it to the end-user and then process user interaction with that page. While having this common platform for generating aggregated pages is very helpful, there are a lot of scenarios where powerful web applications can be built if the Consumer can also act as an intermediary coordinating information between those portlets.
•
Leverage message level security: As the message level security standards develop and are supported by the common web stacks, it is expected WSRP will exploit those security mechanisms.
6. Useful References The following is a list of useful references for those seeking additional information: •
Overview: An overview presentation on WSRP is available at http://www.oasis-open.org/committees/download.php/3488/wsrp-overview-rev2.ppt
•
Introduction: An introduction to the concepts and philosophy of WSRP is available at http://www.oasisopen.org/committees/download.php/2634/WSRP%20Whitepaper%20-%20rev%202.doc
•
Primer: This document is still under development. The current version can be located through the quick links portion of the Technical Committee's web site.
•
Specification: The WSRP v1.0 specificaion is available at http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf
•
Conformance guide: This document is being planned by the Technical Committee. Check the the Technical Committee's web site for availability.
•
WSRP Technical Committee: The WSRP Technical Committee's web site can be found at http://www.oasisopen.org/committees/wsrp/
•
JSR 168: Since the WSRP Technical Committee and the JSR 168 (Java Portlet API) Expert Group were developing portal related standards in parallel, they worked together to ensure align these standards were well aligned. Information about the JSR 168 standard can be found at http://www.jcp.org/en/jsr/detail?id=168
•
Apache implementation: The Apache wsrp4j project is an open source implementation of WSRP v1.0 and can be found at http://ws.apache.org/ws/wsrp4j.
Acknowledgements The members of the OASIS WSRP Technical Committee have worked hard over the past couple of years to achieve a common understanding of the needs and possible solutions which then drove the production of the WSRP v1.0 specification.
Glossary OASIS
Organization for the Advancement of Structured Information Standards
WSRP
Web Services for Remote Portlets
Proceedings by deepX Ltd.
XSL• FO RenderX
10
Enabling Interactive, PresentationOriented Content Services Through
Biography Richard Thompson Chair, OASIS WSRP TC; Senior Software Engineer, IBM Research IBM Corporation Yorktown Heights United States of America
[email protected] My group at IBM Research is involved in the development and promotion of standards targeting the portal market. I am the chair of the OASIS WSRP (Web Services for Remote Portlets) Technical Committee and serve as the lead editor for the specifications this committee is producing. The v1.0 specification became an OASIS standard 1 September 2003. Thomas Schaeck Architect WebSphere Portal Server, STSM, IBM Software Group IBM Deutschland Entwicklung GmbH Boeblingen Germany
[email protected] Thomas Schaeck is lead architect for for WebSphere Portal and leading portal standards activities at IBM; he initiated the WSRP and JSR 168 standardization efforts.
Proceedings by deepX Ltd.
XSL• FO RenderX
11
