Introduction

More and more business users from large enterprises, medium-sized companies, and small businesses are playing an important role in the development of integrated, interactive, human-facing applications for Web services on remote portals. Through standards bodies, they are collaboratively voicing their user preferences in an effort to standardize how Web services should be integrated, processed, and presented alongside one another on portals via wired and wireless multiple-tier networks.

With the ongoing expansion of distributed network systems, there is an increasing need to standardize interpretations of how emerging Web services should be implemented. The Web development industry giants, for example, have periodically met to resolve differences in the interpretations of SOAP implementations, so as to improve interoperability among systems running on diverse platforms. SOAP interoperability is an important issue in making e-business applications and e-commerce available to a wider range of business users. As SOAP interoperability issues are being resolved, business users have begun to express a new set of concerns, this time regarding problems with the interoperability between interactive, human-facing Internet applications.

IBM has contributed to the development of two specifications on human-facing interactive applications. They are Web Services Experience Language (WSXL) and Web Services Remote Portals (WSRP). WSRP is currently part of WSXL; it defines special WSXL components called Remote Portlet Web services. Both specifications reflect the growing trend toward collaborative efforts to standardize human-facing applications for Web services.

In this article, I will look at the benefits of WSXL. I'll address the details of developing human-facing applications using this specification in a future article; a further article on the benefits of WSRP will follow.

Back to top

OASIS drives human-facing apps

The Web Services Interactive Applications Technical Committee (WSIA TC), led by IBM, is a relative newcomer to the Web development world. On January 17, 2002, the Organization for the Advancement of Structured Information Standards (OASIS) 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 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.

A close examination reveals that the WSIA committee has literally adopted many of the goals behind WSXL. The WSIA committee is now using WSXL as the vehicle to pursue its aims. Let's take a look at some of the goals of this group in more detail.

Primary goals

WSXL's chief goal is to allow businesses to distribute applications through multiple revenue channels. For instance, each telecommunications provider has separate sets of usage charges for each equipment type it offers (for example, broadband versus DSL), and sets of rules on credits to be returned to customers if the terms of a service-level agreement (SLA) are not met. By standardizing Web services presentation on a portal, telecommunication providers could mix and match the components of their service offerings as the business requirements and processes change and new technologies emerge, rather than needing to rework each customer's entire package.

The second primary goal is to create new services by leveraging existing infrastructure. The WSIA TC aims to allow application programming models to blend with W3C standards (for example, XForms, XML events, XPath, andXLink), Web services standards (for example, SOAP and WSDL), and businesses processes (for example, WSFL). Such integration would, for instance, allow a telecommunication provider to offer customers high-speed Internet cable service by leveraging its own cable infrastructure.

Secondary goals

The initiative's third goal is to widen the scope for deployment channels to which Web services are delivered. Traditional channel types are direct, indirect, and embedded; examples of each type are shown in Table 1. WSXL aims to add a virtual channel type to the scope, reflecting the progress of Web Services toward such external collaborative efforts as audio conferencing, video conferencing, instant messaging, virtual banking, virtual shopping, and other virtual reality mechanisms.

Table 1. Channel types

Another goal is to mix and match presentation technologies to create fully interoperable and fully interactive Web services applications and to develop, integrate, deploy, and implement services. This can be done anywhere at anytime from any place in any enterprise at any n-tier network. For instance, one presentation style may be suitable for a business customer, and another style for a corporate decision maker. A designer located anywhere on the network should be able to add a third presentation style for, say, a manager. The application home page should provide a choice of presentation styles so the designer can see if a style needs to be updated or added. h

Back to top

WSXL: An introduction

WSXL is a Web services-centric component model for interactive Web applications. This model is encapsulates the aims of the WSIA committee, and focuses on user experiences with remote portals via interactive human-facing applications running on multiple distribution channels.

To accomplish the goals I described in the previous sections, all WSXL component services implement a set of base operations for life cycle management, accepting user input, and producing presentation markup. More specialized forms of these services represent the data, presentation, and control components.

For a WSXL service, a more effective and appealing user experience, rapid reconfiguration, and infrastructure leverage are the three most important requirements imposed by a business model. Rapid reconfiguration allows, for example, new distribution channels, such as portals, browsers, and third-party Web sites; these new channels, in turn, make new business models and cobranding possible. WSXL also requires support for easy changes, to keep up with changing business models; easy adaptation, to deliver an application through new channels; and easy aggregation to group several application together in a portal or another single point of access. Support for easy integration and full interoperability among the applications and Web services are also required.

WSXL component model

The WSXL component model consists of Advanced WSXL Services and, at the second level, a WSDL description. The Advanced WSXL Services extend the WSXL Base Components (also called the Base WSXL Components) at the third level by adding event-oriented portTypes and XML events, as well as WSXL collections (more on which in a moment). To get the presentation components to work, you need the control component to implement portTypes so that you can bind data components to presentation components. Examples of event-oriented portTypes include listeners for notification and the connection of events between components.

The WSDL description is concerned with the schema definitions referred to by portTypes for each category of the Base WSXL Component interfaces. The WSXLComponent interface imports the four portTypes detailed in Table 2 below.

Table 2. portType examples

A more specialized form of WSDL, Adaptation Description Language (ADL), is used to adapt the output of a WSDL component without invoking it. This language employs the notion of adaptation points for the data, presentation, and control components. For instance, changing a page's background color is a presentation adaptation, while adding to a value in output markup is a data adaptation and changing the consequence of pressing a button is a control adaptation.

WSXL can change a user's experiences with interactive, human-facing pages via WSXL collections. A collection instantiates a particular set of three components -- data, presentation, and control -- in order to implement a single function that is loosely analogous to a page. In each page, functionality flows from one component to another according to a flow model, described by a system such as Web Services Flow Language (WSFL). Since this flow model is used to describe a logical flow of components in the collection, each WSXL component has a well-defined WSDL life cycle interface.

Back to top

Conclusion

WSXL applies to interactive, human-facing applications from different perspectives. The benefits of using WSXL far outweigh any disadvantages introduced by the complexity of the WSXL component model. One of WSXL's primary benefits is that it offers flexibility to reconfigure and adapt a Web service as its components change. In addition, WSXL component services offer a set of base operations for life cycle management. WSXL's model reflects business users' collaborative viewpoints, as expressed through the WSIA TC, on how Web pages should be presented to humans.

When the WSCM TC was renamed as the WSIA TC, it reflected two realities. One is the trend toward consideration of the interactive, cognitive aspects of user experiences. The other is the recognition accorded the business users as important participants in the development of interactive, human-facing applications. Users can only benefit from both of these points.

About the author

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• OASIS drives human-facing apps
• WSXL: An introduction
• Conclusion
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
• Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
• Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
• Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers