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.
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]
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.
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.
6.3 Coordinated
6.4 Orchestrated
6.5 Republished