Web Services for Interactive Applications (WSIA) Requirements

Last Modified: April 15, 2002 (Eilon Reshef)

Introduction

This document aggregates a temporary list of requirements, as collected by the WSIA group, in particular as part of analyzing the Embedded and Customized use cases.

The requirements are categorized according to their “business” function and according to the technical characteristic they represent. For a taxonomy of the technical characteristics, see below.

Note: this document uses the same requirement numbers as in previous versions, to ensure consistencies in external references. Arbitrary numbers were assigned to some of the new requirements to facilitate easier discussion. It is expected that the requirements are renumbered following the upcoming F2F meeting.

Taxonomy

This taxonomy defined the categories of

Functionality

Requirements ensuring that a high-level need for business functionality is met.

Flexibility

Requirements ensuring that the WSIA standard supports different systems, methodologies, environments, tools and developer capabilities.

Simplicity

Requirements ensuring that the WSIA standard minimizes the limitations on developer capabilities and on the complexity of toolsets.

Expressiveness

Requirements ensuring that Web Services that comply within the WSIA standards can provide as much information about their characterstics and behavior to support robust development methodologies and feature-rich tools.

Privacy

Requirements ensuring that information private to individuals or organizations can be passed between system components implementing the WSIA standard.

Efficiency

Requirements ensuring that the WSIA standard minimizes system resource usage.

1. General Requirements

R101 [Flexibility]

The specification will make reasonable efforts to support (but not define) a broad range of programming models for Producers and Consumers of WSIA Web Services.

R201 [Simplicity]

WSIA Web Services must be reasonably easy to produce, either from scratch or from existing web applications. Further, it should be reasonably easy to publish and consume these services

R207 [Simplicity]

It should be possible to create and consume WSIA Web Services using tools, methodologies and environments similar to the ones used to create standard Web applications.

R202 [Simplicity]

The specification should support the creation of minimal WSIA Web Services, which can be consumed using generic Consumers.

Note: this is trying to capture the “single proxy”, or drag-and-drop requirement also raised in WSRP.

R301 [Expressiveness]

WSIA Web Services must be self-describing, making it possible for Consumers to use them with minimal human intervention.

R501 [Flexibility]

WSIA must not preclude the use of intermediaries connecting Producers and Consumers.

R203 [Efficiency]

The computational demands that are placed on the Producer should be reasonable when creating a WSIA service.

Note: in other words, it is possible for a provider to describe their WSIA service in such a way that a consumer implements and executes the customizations needed.

R204 [Efficiency]

The computational and scalability demands that are placed on the Consumer should be reasonable when using a WSIA service.

Note: it should possible for a Producer to provide support and perform the adaptations needed by the consumer so as to allow a low-entry consumer.

R205 [Efficiency]

The specification should support the creation of WSIA web services with varying degrees of computational and scalabality characteristics while still enabling required functionality such as customization and integration.

R215 [Efficiency]

The specification should make it possible for Consumers and for intermediaries to robustly cache Presentation Fragments returned by the Producer.

R216 [Flexibility]

The specification must not preclude WSIA Web Services from publishing additional operations in its interface. The specification must also not preclude a WSIA Web Service from using other services (including non-WSDL services) as part of its operation.

2. State

R131 [Functionality]

This specification should define the lifecycle management in such a way that a Consumer can access a particular instance of a WSIA Web Service during the lifecycle of the interactions between them.

R129 [Flexibility]

The specification should support (but not mandate) stateful WSIA Web Services.

Note: additional state-related requirements appear as part of the Embedded use case.

R130 [Flexibility]

A Consumer should be able to consume both a stateful WSIA Web Service and a stateless one. If needed, this specification should define the mechanism that allows the Consumer to support both cases.

3. Presentation Formats, Representation

R600 [Functional]

This specification should make it possible for a Consumer to receive Presentation Fragments generated by a Producer, integrate them into a Page, and serve them to an end-user.

R601 [Flexibility]

The specification may specify restrictions on markup types or Presentation Fragments so that Consumers can reliably aggregate multiple Producers into a single page. This specification should make reasonable effort to put as few such restrictions as possible.

R602 [Flexibility]

This specification should support common Presentation Formats, which are in use today in Net-enabled applications. In particular, it should support HTML, WML and XML as Presentation Formats. It must not preclude the use of other presentation formats (Eilon: such as Flash, GIFs, etc.).

R603 [Flexibility]

WSIA Web Services should not be precluded from using scripting elements within Presentation Fragments. In particular, this specification should support Presentation Fragments that contain JavaScript scripts.'

R701 [Efficiency]

This specification should support efficient communication of Presentation Fragments. In particular, it should support communication of an entire Presentation Fragment using a single network operation.

R702 [Flexibility/Privacy]

[ER1] It should be able to ensure that end-user requests for external resources referenced by Presentation Fragments returned by the Producer can be requested and relayed through the Consumer.

4. Navigation and Interaction

R900 [Functional]

This specification should make it possible for a user interaction (page navigation and form submission) with a Presentation Fragment (which is assumed to have been generated by a Producer and presented to an end-user by a Consumer) to be routed to the Consumer, and then delegated to the Producer. In this document, such user interaction is named Action.

Note: for this to happen, URLs need to be rewritten – it should be possible to redirect actions to the Consumer and then back to the Producer that sourced the markup causing the invocation.

R901 [Simplicity]

A single, generic, Action signature must be exposed by a WSIA Web Service Producer.

Note: follows from R202 – generic Consumer.

R408 [Functionality] [“Customized”]

It should be possible for the WSIA Web Service Producer to indicate to the Consumer that it has completed its interaction with the end-user, and that the Producer has reached the final state of the Producer's execution.

Note: in this case, the output markup and property values (see below) being returned are “final”.

5. Data Representation

R309 [Functionality]

This specification should provide standard means by which Consumers may impact the look and feel of a Producer’s output for the purpose of controlling the appearance of the Consumer Page. These means may be output type specific. In this document, such customizatoin is assumed to be represented using Properties.

R310 [Functionality]

This specification should provide standard means by which Consumers can provide context data (specific to an individual, organization or system environment) to the WSIA Web Service Producer. In this document, such data is assumed to be represented using Properties.

R311 [Functionality]

This specification should provide standard means by which Producers can return context data (specific to an individual, organization or system environment) to the WSIA Web Service Producer. In this document, such data is assumed to be represented using Properties.

R401 [Functionality]

It should be possible for a WSIA Web Service Consumer to dynamically assign Property Values to each Instance of a WSIA Web Service. Such property values may be assigned at any point of the lifecycle of the Producer, from instantiation through later action invocations and/or output operations.

R407 [Functionality]

It should be possible for the WSIA Web Service Producer to return the current set of property values.

Note: the property values can be returned, for example, along with generated output presentation, if any, resulting from an action invocation or output request.

R302 [Expressiveness]

The list of Properties supported by the WSIA Web Service should be available to the WSIA Web Service Consumer at the development phase.

Below are three alternative/complementary options:

1. The list of Properties can be defined statically as part of the WSIA Web Service description document (e.g., WSDL).

2. A pointer to the list of Properties can published staticaly as part of the WSIA Web Service description document (e.g., WSDL).

3. The list of Properties can be obtained dynamically as a result of an operation defined in the WSIA Web Service.

R303 [Expressiveness]

This specification should support (but not enforce) rigorous specification of the Type of each Property (which may include Value Constraints) to support type checking in development type. It may look to XML Schema or XFORMs constraints as a language for such definitions.

It should be possible, but not required, for a WSIA Web Service Producer to define the data type allowed for a property using a standard mechanism such as XML Schema.

R402 [Flexibility]

This specification should not place any arbitrary limitations on the type or size of Property Values.

R412 [Expressiveness]

It should be possible, but not required, for a WSIA Web Service Producer to specify whether a property is read/write or read-only.

If a Property has a defined structure (for example, as defined by XML Schema), then individual elements within its type may be either read/write or read-only.

R403 [Functionality]

This specification must allow a a WSIA Web Service Producer to dynamically verify the validity of each Property Value. The Web Service Producer should not be precluded from applying arbitrary validation logic based on a single Property Value or on a combination of multiple Property Values. The WSIA Web Service Producer should not be precluded from applying different validation logic based on the Consumer.

R404 [Functionality]

It should be possible for a WSIA Web Service Producer to perform arbitrary modification to Presentation Fragments based on any Property Values. In particular, this specification must allow Producers to apply look-and-feel transformations such as excluding Presentation Fragments, inserting Presentation Fragments, replacing specific Presentation Attributes.

R413 [Expressiveness]

Producer properties should allow for the specification of validation constraints and/or logic at each of the following levels:

1. lexical

2. syntactic

3. semantic

4. Constraints linking two property elements, defining how the value of one may be computed from that of the other.

R414 [Functionality?]

The Consumer should have a means to override property validation constraints and logic at each of its levels.[ER2]

R415 [Functionality?]

Producer property metadata and associated validation descriptions should be able to be delegated to the Consumer for evaluation and execution.

R702 [Performance]

It should be possible (but not necessary) for a WSIA Web Service Producer to persistently store subsets of Property Values to eliminate the need to communicate them upon creation of a WSIA Web Service. It should be possible for a Consumer to refer to such stored collections.

Note: this mechanism is sometimes called Property Sheets, and corresponds to the Portlet Template in WSRP.

R703 [Performance]

It should be possible (but not necessary) for a WSIA Web Service Producer to temporarily store subsets of Property Values per Instance to eliminate the need to communicate them on each request to the Web Service.

R411 [Privacy]

It should be possible for a Consumer to adapt a provider’s output in a manner that is confidential between the Consumer and the end-user. For example, it is possible for a Consumer to insert additional markup into the Presentation Fragment output stream without the Producer having access to the inserted markup.

6. Additional Requirements from Specific Use Cases

6.1 Embedded

E901

The specification must provide means for Consumers determining if a Producer is a stateless WSIA Web Service.

E902

The specification should support both implicit and explicit creation of a stateful connection between Consumers and Producers. Means by which the Consumer gains access to the stateful connection must be well defined.

E903

The specification must specify the means by which a Producer indicates which actions, events and operations are to be redirected to the stateful connection between the Consumer and Producer.

E904

This specification should include operations and semantics related to persisting stateful information for use in later interactions between the Consumer and Producer.

E905

The specification must provide a means by which Producers may indicate tokens which need to unique to its output.

E906

When a Consumer requests a Producer to set a Property Value, the Producer must return the set of changed properties (includes rejection of attempt and possible side effects on other properties).

E907

It should be possible for a Consumer to update the properties of the Producer with a minimal number of invocations.

E908

A WSIA service SHALL maintain its condition, i.e. its state [Discussion – question of persistence

E909

A WSIA service MAY maintain a stateful or stateless condition

E910

When a WSIA service maintains its condition in a stateless manner, a handle MAY be returned by the lifecycle operations.

E911

Once a handle is returned by a service, no other handles SHALL be accepted by other operations.

E912

Explicit handle creation SHALL not be required.

E913

If an implicit creation of a handle occurs, that handle SHALL be made available with the associated output.

E914

A WSIA service MUST indicate whether it operates in a stateful or stateless manner.

E915

The Consumer MUST interact with the service in the mode (stateful or stateless) that the Producer has specified for the service.

E916

If the Producer has specified more than one mode, then the Consumer MUST select one of the supported modes, and use it for the duration of the interaction or session.

E917

A Consumer SHALL provide the capability to include input or additional parameters to the Producer.

E918

A unique identifier SHALL be available to identify the correct Producer, the operation and any additional parameters (where applicable) for processing an invocation.

E919

The WSIA portTypes SHALL provide a minimum set of criteria to enable adaptation, aggregation, and integration.

E920

The WSIA portTypes structure SHOULD allow for extensions.

E921

The WSIA portTypes structure SHOULD allow for loose coupling to aggregated operations (i.e. [side note] they provide for flexibly exposed interfaces and operations).

E922

Producers SHOULD provide the capability to support legacy applications and infrastructure.

E923

Producers MUST comply with any markup restrictions defined for the markup types they generate.

E924

An alternative to UDDI SHOULD be available to request a service description. {R201, R301}

E925

Producers MUST inform Consumers which properties have actually been modified.

E926

A Producer MUST specify its supported properties (including that particular properties are read-only) so that Consumer may modify them as necessary. Preferably this is done through a schema definition.

E927

The output MUST be testable against conformance rules (see 7.4.5). {R601} [Not capturing that there will be conformance rules]

E928

Producers SHALL support an opaque operation by which Consumers may direct user interactions to the Producer. {R202} [This is more detailed …]

E929

Producers MAY support a WSIA portType providing Consumers the means to request the persisting of the current state for use in later interactions as well as the destruction of such persisted states. {R702}

E930

Consumers SHALL have the ability to set the values of a standard set of items controlling the appearance of a Producer’s output. {R401} [Not fully captured]

E931

A standard set of CSS classes MAY be used by a Consumer to control the appearance of a Producer’s output.

E932

Consumers MAY set a property on Producers specifying the CSS stylesheet with the Consumer’s values for the standard classes.

E933

A WSIA Web Service Provider may define specific operations for the Actions associated with its presentation or data. Input arguments to such operations include:

1. optional session handle

2. defined set of typed arguments which may correspond to defined properties of the Producer

3. standard arguments from the generic action signature, including user profile, device context, markup preferences

The output returned from an Action includes:

1. optional session handle if created for the first time

2. changed property values as a result of the action execution

3. updated presentation output either to the original or a new page

6.2 Customized

C001

WSIA Web Service Producers may associate adaptation metadata with a property describing how that property may be changed by the Consumer. Adaptation description metadata defines the "permissions" which control which aspects of the property are open for change by the Consumer, including:

1. deletion of a data element defined by the property

2. addition of new data elements allowed by the property's type definition

3. overriding of values within a given data property by restricting, extending, or replacing the set of defined values within the allowed range of the property's type definition - perhaps accomplished by narrowing the original type definition of the property.

4. overriding of validation constraints and/or logic

5. addition or modification of relationships defined across elements in the property

6. if a data property, whether it is relevant or required in the Producer's presentation output

C002

WSIA Producers which provide adaptation metadata must also provide a mechanism to accept instances of adaptations conforming to the permissions granted in the adaptation description. The format for Consumers passing adaptation instances to the Producer may be via interface operations, an XML markup, or both.

C003

WSIA Web Service producers who provide adaptation description metadata must also maintain a queryable list of which adaptations are currently in effect, and their values.

C004

WSIA Web Service Producers may enable a simple call-return form of customization. The consumer instantiates the Producer, initializes it with data, allows it to communicate with the end-user, and then queries it for final return data, perhaps after receiving a null output markup indicating end of dialog with the user. Essentially the Producer is a black box component but has support for initial and final values. Look and feel customization are carried out as in the Embedded case.

C005

WSIA Web Service Producers may enable customization of the output presentation as a special case of property adaptation. The Producer may define adaptation points for the "output" property, where elements in the output can be deleted, inserted, modified, and read using the Adaptation Description metadata defined in C001.

Note that in this simple case, there is no associated data model so no bindings between this new markup and that created by the Producer on its own. There may be support for defining a set of CSS styles to be used to coordinate look and feel between Producer and Consumer (who decides? Perhaps two alternative flows here).

C006

WSIA Web Service Producers may enable customization of a data model for presentation using the property adaptation metadata defined in C001. Properties for data elements associated with a presentation are defined, along with optional type definitions.

The consumer is able to query for the type definition of a set of properties defining the data model of the Producer. XML schema would be used as the preferred type definition language.

Given the content model defined by a Producer's schema, the Consumer would be able to remove data elements, add data elements, and change the values initialized in elements.

The Producer must be able to generate an output presentation that adapts to the customized data model in appropriate (as determined by the Producer) ways.

C007

WSIA Service Producers may enable customization of their output presentation with association to a data model. The data model may be either that defined by the Producer, or one created on the Producer by the Consumer.

WSIA Web Service Producers may use XFORMS-like binding expressions between elements in output property and data model properties.

Customization of the output presentation (as in req 2, above) now are able to refer to elements in the existing Producer's data model. In addition, the Consumer should be able to insert additional data model elements to support the output presentation elements it is adding. For example, if the Consumer is adding a new form to the output presentation of the Producer, the data elements supporting that form would be added to the Producer's data model as well.

C008

WSIA Web Service Producers may enable customization of their controller logic. Using Adaptation Description metadata on data properties, WSIA Consumers may add constraints among a Producer's data elements to customize how their values are calculated.

As in the mortgage calculator scenario, the Consumer would be able to define expressions between Producer data elements to alter the way in which they are calculated to adapt to Consumer-specified logic.

C009

WSIA Web Service Producers may enable their property adaptation descriptions to be exported for delegation of execution to a WSIA Consumer without provider intervention.

C010

WSIA Consumers should be able to use the adaptation description metadata to employ a combination of local capabilities (no producer intervention) and producer capabilities to perform a desired set of customizations.

C011

The Producer must be capable of generating Presentation fragments corresponding to adapted data properties that are valid according to the original property type definitions.

C012

The WSIA Web Service Producer may define adaptation description metadata with a distinguished "output" property associated with its presentation specifying:

1. where named items may be read from the presentation, or "lookup" points

2. where additional presentation content may be added, or "insert' points

3. where optional presentation content may be removed, or "delete" points

4. where presentation content may be modified, or "modify" points. Presentation content may be modified through attributes of the adaptation point which may allow for style specific controls such as formatting options.

It should be possible for adapted presentation content to adhere to a Producer specified namespace for conformance to the look and feel defined by the Producer, or for style to be fully specified by the Consumer.

C013

The property description exported by a WSIA Web Service Provider should be rich enough to support the execution of an adaptation by a WSIA consumer without provider intervention.

C014

WSIA Consumers should be able to, with an appropriate property description, employ a combination of local capabilities (no producer intervention) and producer capabilities to perform a desired set of customizations.

C015

A WSIA service description and associate guidelines must be sufficient for a consumer to create an integrated form from multiple providers and on a submit event from the user must be able to send suitable parts of the information to the corresponding provider. For instance, the adaptation information should have sufficient information remove redundant submit buttons either at the producer or the consumer. For example, the consumer may need to perform disambiguation of form fields to create an integrated page. Further, an interaction such as submit must be parsed at the consumer to send the right fields to the right provider.

wsrp message

Introduction

Taxonomy

1. General Requirements

2. State

3. Presentation Formats, Representation

4. Navigation and Interaction

5. Data Representation

6. Additional Requirements from Specific Use Cases

6.1 Embedded

6.2 Customized

6.3 Coordinated

6.4 Orchestrated

6.5 Republished

6 Glossary

A Acknowledgments

B References