Human-facing Web services, Part 3: Build portals with WSRP

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Judith Myerson (jmyerson@bellatlantic.net), Systems Architect and Engineer, Professional Consulting

01 Jan 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.

Introduction

On a portal, you can establish a single sign-on, or personalize and control your access to information, applications, processes, and people. You can get information from a variety of data sources, such as databases, transaction systems, content providers, or remote Web sites. You could, for instance, create a bookshelf of your articles and books on a portal provided by an organization of which you are a member, with the information about your published work stored in a database.

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 (see the Resources section below for a link). This document proposed a standard adapter that vendors can employ to mix, match, and reuse human-facing interactive Web service applications from different sources.

Business scenarios Wondering what real-life portals might look like? The following are some business scenarios for which you might want to use a portal: Information sharing between portal servers. Links to Web applications. A wireless stock trading service. A multimedia sports portal. Details on roles, relationships, business objectives, and solution requirements for each scenario are provided at the OASIS's Web site (see the Resources section below for a link).

Back to top

WSRP dependency on WSXL

Let's take a look at how WSRP depends on WSXL for services. In Figure 1, WSRPService is a special WSXL component service built on Web service standards, including SOAP, UDDI, and WSDL. Through the WSXL component (in the center), WSRP extends WSXL portTypes (at the top) and Advanced Component Services (at the bottom) to WSRP's Remote Portlet Web services. (Figures 1 and 2, as well as Listing 1, are derived from IBM's Note of April 10, 2002, Web Services Experience Language Version 2; see Resources for a link).

As you can see, WSRPService imports two WSRP and four WSXL portTypes through the base WSXL component service, as detailed in Table 1. Each portType refers to schema definitions as specified by WSDL. Table 1 includes a description for each portType with its associated category.

Table 1. portTypes

Back to top

Stock plot application

Figure 2 shows WSRP in action. In it, a portal is used to present to the users a remotely hosted stock plot application, which consists of two separate WSXL applications. Its simple workflow has three parts: an application provider (left), an application distributor (middle), and users (right). The application distributor positions the portal in front of the stock data plot input application. The distributor handles SOAP messages regarding the information provided by the stock plot application, sending and receiving them to and from the application provider. Using HTML, the stock data plot input application and the stock plot application are combined for presentation to the human users, prompting them to enter stock ticker symbols to get the quotes for the day.

If you do not like the green color, or the presentation's font style or size, you can override defaults with adaptation points employed by Adaptation Description Language (see Resources for a link). You can also override defaults for the data, letting you or the application overwrite or add to a value on the output markup. Each point specifies an application-specific adaptation point name, the insert, replace, or lookup operation desired, and the names of pages to be changed.

This adaptation language is part of a WSXL application that may also consist of a minimum of three WSXL components (presentation, data and control), event wiring, and synchronization and flow composition across multiple WSXL components. Listing 1 contains a code example showing how WSXL components can be grouped under a WSXL collection called StockChartCollection. This collection provides an execution and management environment for the individual components.

		
<WSXLCollection name="StockChartCollection"
xmlns:ev="http://www.w3.org/2001/xml-events">

  <WSXLComponent name="ChartUI" role="Presentation"
     href="http://www.StocksRUs.com/StockChart.wsxl"/>

  <WSXLComponent name="CartData" role="Data"
     href="http://www.StocksRUs.com/StockFeed.wsxl" >

      <PropertyList> <!--default propertyType="String" -->
         <Property propertyName="DataService" propertyValue="Tipco"/>
         <Property propertyName="StockSymbol" propertyValue="IBM"/>
         <Property propertyName="TimeFrame" propertyValue="1 day"/>
      </PropertyList>
  </WSXLComponent>

  <WSXLComponent name="ChartController" role="Control"
     href="http://www.StocksRUs.com/ChartController.wsxl">

     <PropertyList>
        <Property propertyName="CollectionContext" propertyValue=
            "name://StockChartCollection"/>
        <Property propertyName="ControlFile"
             propertyType="file" propertyValue=
             "http://www.StocksRUs.com/ChartController.xlink" />

 <!-- if more than one control file is needed, just repeat the
ControlFile property:
<Property propertyName="ControlFile" propertyType="file"
propertyValue="http://localhost/StockChartCollection/controlSetting2.x
link"/>
-->

     </PropertyList>

     </WSXLComponent>

<ev:listener event="CollectionInited" handler="ChartData-InitHandler"
type="javascript"/>

</WSXLCollection>

Back to top

Platform independence

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:

• Get information from data sources.
• Aggregate information into composite pages.
• Provide personalized information to users in an interactive fashion.

Back to top

Conclusion

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.

Resources

• Check out the first installment in this series, "An introduction to Web Services Experience Language," Judith M. Myerson (developerWorks, September 2002) for an introduction to user experiences with Web pages and portals.
  
  
• Check out the second installment in this series, "Building applications," Judith M. Myerson (developerWorks, October 2002) for a discussion on leveraging reusable components, workflows, and business processes.
  
  
• Read about the WSIA TC (previously the WSCM TC), formed to create a Web services component model for interactive applications.
  
  
• The OASIS Web site contains links to concrete business scenarios in with Web Services for Remote Portals plays a part.
  
  
• Read about the WSRP TC, formed to develop Web services standards standard for remote portals.
  
  
• Learn more about the WSXL specification, the WSXL Whitepaper (PDF), and the WSIA-WSRP Core Specification (PDF), which all serve as a foundation for this paper.
  
  
• Get more information on OASIS's WSRP committee.
  
  
• The WSXL specification also contains information on Adaptation Description Language.
  
  
• Read The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
  
  
• Read Enterprise Systems Integration, Second Edition, to provide yourself with the business insight and the technical know-how that ensures successful systems integration.
  

About the author

		Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, distributed systems, component-based technologies, and project management. You can contact her at jmyerson@bellatlantic.net.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top