Web Services for Interactive Applications (WSIA) Requirements
Last Modified: April 17, 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. Add a requirement on developer implementation simplicity is more important than toolset implementation simplicity.
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. I.e. performance & scalability. A new RAS category?
1. General Requirements
R101 [Flexibility]
The specification MUST be independent
of any specific programming model and will make reasonable
efforts to SHOULD support (but not define) a
broad range of programming models for Producers and Consumers of WSIA Web
Services.
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.
Describe Intent - evolution and not revolution.
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 (Producer-neutral) Consumers. Debate:
RT and CW.
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. Addition: capture
the idea of a spectrum of self-description. Debate: CW, TJ.
R301 WSIA
Web Services must be self-describing, making it possible for
Consumers to use them with minimal human
intervention. Given a generic
reference to a WSIA Web Service, it must be
possible for a Consumer to
obtain a description of its full WSIA-related
capabilities. It must also be
possible for a Consumer to determine whether the
service supports a specific
WSIA-related capability.
WSIA must not preclude the use of intermediaries
Intermediaries connecting Producers
and Consumers.
R203 [Efficiency]
The computational demands that are placed on the Producer
should be reasonable when creating a WSIA service. Debate
Content: SF & SR & SA
& WC
& ER & RK.
Same for R204-5.
Remove "reasonable" everywhere.
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. Debate: SR and ER.
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 MUST
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 (butMUST
not 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.
Rewrite as one simple requirement: SR, RT, MM, TC, GT. Do not use "session", no recursive "lifecycle" definitions - instead "for the duration of..". Allow for Consumers that consume only stateful or stateless services.
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. Debate on second sentence only: ER, MM, WC.
R602 [Flexibility]
This
specification should support common Presentation Formats, which are in use
today in Net-enabled applications. In particular, it should support HTML, XHTML,
WML and XML as Presentation Formats. It must not preclude the use
of other presentation formats (Eilon:
such as Flash, GIFs, etc.). Debate on last
sentence: AK, CW.
(last
sentence) It SHOULD NOT preclude
the use of other presentation formats, although
these
(e.g.,
Flash, GIFs, etc.) shall be considered opaque in the markup
stream.
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.'
Debate: GT, SR, SF, TC, RT, RK.
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. Debate: GR, SR, SV.
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. Rewrite: SR, MM, AK.
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.
R900A [Functional]
This
specification should make it possible for a user
interaction
with the generated presentation to be routed to the Consumer and
optionally delegated to the Producer.
R900B [Functional]
This
specification should make it possible for a user
interaction with the generated presentation to be
routed directly to the
Producer, bypassing the Consumer.
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. Debate: GG, SR, ER, SB, RK.
Note: in this case,
the output markup and property values (see below) being returned are “final”.
Should
we add another requirement about knowledge of state of Producer
by Consumer.
5. Data Representation
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 ProducerConsumer.
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. Rewrite: Change Properties to customization/data, change instance to duration/lifecycle. TC, SA, SR, SF, MM, CW. Define more precisely what we mean by lifecycle/duration.
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 MUST
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. Debate: CW, SR, AK, SF, SA. Also 414-415
No consensus yet on a reword
of #4
R414 [Functionality?]
The
Consumer should have a means to override property validation constraints and
logic at each of its levels.
Some debate on MUST vs. SHOULD
adhere..
R414 The
Consumer MUST adhere to whatever property validation constraints the
Producer has specified. The Consumer MAY specify
additional property
validation constraints.[ER2]
R415 [Functionality?]
Producer
property metadata and associated validation descriptions should be able to be
delegated to the Consumer for evaluation and execution.
Some debate on MUST vs. SHOULD
have access..
R415
[Functionality]
The Consumer
MUST have access to the Producer property
metadata and associated
validation descriptions.
R702 [Performance, Functionality]
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.
Add: Also state how the producer indicate what is the subset and how the Consumer can refer to it.
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
Producer 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 or knowledge of the
inserted markup. Debate: MM, RK, GG, SR, GT, RS.
Also - what about the reverse: producer+end-user confidentiality.
6. Additional Requirements from Specific Use Cases
6.1 Embedded
E901
The specification must provide means for
Consumers to determining determine
if a Producer is a stateless WSIA Web Service. Debate: ER, SA, R,
TJ.
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. Debate: SR, GT,
SA, AK, RT. Also, E903-4.
E902
The
specification should support both implicit and explicit creation of a
stateful
connection between Consumers and Producers.
The Producer
signifies
that
a connection is stateful by creating and returning a Handle, an opaque
reference
for use by the Consumer to refer to the stateful interaction
between
an End User and the Producer.
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.
E903
When a Producer has returned a Handle in
response to a Consumer
invocation,
the Consumer must ensure that Handle is supplied as a parameter
in
any future invocations involving the Consumer and this Producer.
E904
This specification should include operations and
semantics related to persisting stateful information for use in later
interactions between the Consumer and Producer.
E904
This
specification SHOULD include operations and semantics related to
persisting
and using stateful information by instances of the Producer's
service
(e.g. "handles").
E905
The specification must provide a means by which
Producers may indicate tokens which need to unique to its output.
Debate: SR, AK, TC, SF, SA, ER,
RT.
E905
This
specification should provide a mechanism that ensures that different
presentation
fragments can be "safely" combined to a single document. In
particular,
if a presentation formats (such as HTML) mandates uniqueness of
tokens
in a single document, it should be possible to compose a page in a
way
that guarantees uniqueness. In particular, it should be possible to
compose
presentation fragments generated by the same Producer.
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 batch
update the multiple properties
of the Producer with a minimal number of one
invocations. Debate: GT, PQ, TC, SR, WC, RT. Debate whether
this is true for all WSIA operations.
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. Strike 908-913 -
but delegate to lifecycle group.
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.
Delegate 915-916 to Lifecycle.
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. Rewrite: RT,
AK, SR.
(Rich T.)
I think this
is trying to say that a Handle is not always enough. We should
try working
through a scenario where a Producer's markup specifies invoking
an application unique operation (exported in its
WSDL) which a Consumer
chooses to rewrite as a generic
action invocation on itself. What encoding
is required in order for user
interaction to trigger the correct
invocations?
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. Debate: GG, ER, DG, SB,
TJ.
E922 The specification MUST NOT preclude
Producers from providing 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. Rewrite to be
discovery-agnostic: RT.{R201, R301}
E924
The specification MUST be independent of any specific discovery
mechanism.
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} Delegate to Lifecycle and persistence.
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.1.defined set of typed arguments which may correspond
to defined properties of the Producer
3.1.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.1.changed property values as a result of the action
execution
3.1.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
6 Glossary
A Acknowledgments
B References