Web Services for Interactive Applications (WSIA)
Web Services for Remote Portals (WSRP)
Last Modified: September 17, 2002 (Rich Thompson)
This document aggregates the list of requirements, as collected by the WSIA Technical Committee, in particular as part of analyzing the Embedded and Customized use cases as well as the requirements gathered by the WSRP Technical Committee.
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.
This taxonomy defined the categories of
Requirements ensuring that a high-level need for business functionality is met.
Requirements ensuring that the WSIA standard supports different systems, methodologies, environments, tools and developer capabilities.
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.
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.
Requirements ensuring that information private to individuals or organizations can be passed between system components implementing the WSIA standard.
Requirements ensuring that the WSIA standard minimizes system resource usage. I.e. performance & scalability. A new RAS category?
The specification MUST be independent of any specific programming model and SHOULD support (but not define) a broad range of programming models for Producers and Consumers of WSIA Web Services.
WSIA Web Services MUST be easy to produce, either from scratch or from existing web applications. Further, it SHOULD be easy to publish and consume these services.
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.
The specification SHOULD NOT require Producer-specific interactions.
A generic Consumer MUST be able to interact with a Producer with no specific knowledge of the Producer's service.
WSIA Web Services MUST be self-describing and allow use by Consumers 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 set of WSIA-related capabilities. A Consumer MAY determine whether the service supports a specific WSIA-related capability.
The specification MUST NOT preclude the use of Intermediaries connecting Producers and Consumers.
When creating a WSIA Web Service, the computational demands placed on the Producer SHOULD NOT impact (or limit) its use.
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.
The specification MUST NOT preclude WSIA Web Services from publishing additional operations in its interface. The specification also MUST NOT preclude a WSIA Web Service from using other services (including non-WSDL services) as part of its operation.
The specification MUST NOT preclude Producers from providing the capability to support legacy applications and infrastructure.
The specification MUST be independent of any specific service discovery mechanism.
This specification MUST define the lifecycle management in such a way that a Consumer MAY access a particular instance of a WSIA Web Service during the lifecycle of the interactions between them.
The specification MUST NOT mandate stateful WSIA Web Services.
The capability SHOULD exist for a Consumer to consume both stateful and stateless WSIA Web Services.
It MUST be possible for a Consumer to determine the statefulness of a Producer-provided, WSIA Web Service.
The specification SHOULD support both implicit and explicit creation of a stateful connection between Consumers and Producers.
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.
The Consumer MUST interact with the service in the mode (stateful or stateless) that the Producer has specified for the service.
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.
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.
It MUST be possible to combine different Presentation Fragments in a single document. Specification of restrictions MAY be required for supported markup types or Presentation Fragments. When used, any such specification of restrictions MUST be minimized. Restrictions SHOULD be type specific. If a markup type (such as HTML) mandates uniqueness of tokens in a single document, a page MUST be composed in a way that guarantees uniqueness. In particular, multiple Presentation Fragments generated by the same Producer SHOULD be capable of being combined.
1. This MUST support Presentation Fragments in HTML, XHTML, XML and WML.
2. This specification MUST support Presentation Fragments and Actions created by ECMAScript.
3. This specification MUST support embedded elements (e.g., Images, Flash, Applets, etc.).
4. This specification MUST define guidelines on Presentation Fragments in HTML, XHTML, XML and WML so that features mentioned elsewhere in the document such as action routing and adaptation can be performed.
5. This specification SHOULD define guidelines on ECMAScript scripts so that features such as action routing and adaptation are enabled.
6. Functionality offered elsewhere in this specification (e.g., action routing, customization) SHOULD NOT be restricted based on a particular presentation format. However, this specification MAY only provide constructive guidelines for a restricted set of presentation formats
It SHOULD be possible for a Consumer to adapt a Producer output in a manner that is confidential between the Consumer and the end-user. For example, it SHOULD be 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.
The specification MUST define means to identify the correct Producer for routing Actions, etc.
A user interaction with a Presentation Fragment SHOULD be capable of being routed to the Consumer. Note: An End-User interaction MAY include page navigation and form submission. A Presentation Fragment MAY be generated by a Producer and presented to an End-User by a Consumer.
Once routed to the Consumer, an End-User interaction SHOULD be delegated to the Producer.
For the duration of an End-User interaction, the Consumer or Producer SHOULD be capable of routing a Presentation Fragment.
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.
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.
This specification SHOULD provide standard means by which Producers MAY return context data (specific to an individual, organization or system environment) to the WSIA Web Service Consumer.
1. It SHOULD be possible for a Consumer to read multiple context data members of a Producer with one invocation.
2. It SHOULD be possible for a Consumer to batch create, update and delete multiple context data members of a Producer with one invocation. It SHOULD also be possible to perform this operation in conjunction with other operations.
The context data 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:
The context data can be defined statically as part of the WSIA Web Service description document (e.g., WSDL).
A pointer to the context data definition can published statically as part of the WSIA Web Service description document (e.g., WSDL).
The context data definition can be obtained dynamically as a result of an operation defined in the WSIA Web Service.
This specification SHOULD support (but not enforce) rigorous specification of the type of each context data member (which MAY include value constraints) to support type checking in development type. It 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 member of its context data using a standard mechanism such as XML Schema.
This specification SHOULD NOT place any arbitrary limitations on the type or size of the value for a member of a WSIA Web Serviceās context data.
It SHOULD be possible, but not required, for a WSIA Web Service Producer to specify whether a member of its context data is read/write or read-only.
If a context data member 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.
This specification MUST allow a a WSIA Web Service Producer to dynamically verify the validity of each context data member. The Web Service Producer SHOULD NOT be precluded from applying arbitrary validation logic based on a single context data member or on a combination of multiple context data members. The WSIA Web Service Producer SHOULD NOT be precluded from applying different validation logic based on the Consumer.
Producer context data definition SHOULD allow for the specification of validation constraints and/or logic at each of the following levels:
4. Computational constraints among the Producerās context data.
The Consumer SHOULD adhere to whatever validation constraints the Producer has specified. The Consumer MAY specify additional validation constraints.
It SHOULD be possible for the Producer to publish context data metadata and validation description.
A Producer MAY persist subsets of context data. When a stateful connection is established between a Consumer and a Producer, persistence MAY eliminate the need to communicate context data.
It MUST be possible for a Consumer to refer to stored collections of context data persisted by the Producer.
The Producer SHOULD indicate the allowable set of persistent context data.
The authentication state of the End-User MUST be represented in the Producer's context data. This authentication state SHOULD be modifiable by the Producer, Consumer and End-User. For example, the End-User could lower their authentication state to not authenticated.
A Producer SHOULD timeout the authentication state of an End-User separately from any other timeout.
The specification MUST allow a Consumer to offer Single SignOn (SSO) functionality.
The protocol MUST be capable of carrying security information that enable Producers to interact with other systems.
It SHOULD be possible for a Producer to make the communication channels private and/or integral such that message modifications are detectable.
A Producer SHOULD be able to specify Access Control for its context data. Producers MUST generate an error on invalid access attempts.
The capability MUST exist for the Producer to authenticate the Consumer.
A Consumer administrator SHOULD be able to restrict the access controls a Producer exposes for users.
The specification MUST support both in-band and out-of-band means of establishing a trust relationship between a Producer and a Consumer. The specification MUST provide the means to refer to this trust relationship.
The protocol MUST support the transfer of information in a trusted manner.
The protocol MUST support the transfer of user profile information in a trusted manner.
Consumers SHOULD comply with both regulatory and End-User specified restrictions on the transfer of user profile information.
An entity MUST be able to specify that an invocation happen in a secure manner.
Operations that fail for security reasons MUST throw a security fault identifying the reason for failure.
The protocol MUST support binary context data such as an authentication token.
This section covers the requirements from the OASIS WSRP technical committee. This TC is defining an interface for portals to access remote portlets that have been exposed as web services. Since this is a usage for a particular Producer/Consumer pair, there is a joint effort is establish a common interface and protocol in order to maximize interoperability. While the following requirements have been copied verbatim, the reader should substitute "Producer" when the text reads "portlet" and "Consumer" when the text reads "portal" as these are the more general terms used by the WSIA TC.
A portlet service MUST be self-describing. A Consumer MUST be able to interrogate the portlet service directly to acquire its meta data.
Portlet service meta data MUST be available to Consumers before it is activated via Consumer registration.
A portlet service MAY publish some or all of its meta data externally to be accessed by Consumers before becoming known or as an alternative afterwards.
A portlet service MUST be able to describe portal specific meta data in response to requests. I.e. if a portlet is required to provide portal specific meta data to take advantage of portal specific capabilities (extensions), it MUST be able to do so.
To activate a portlet service [for a given portal], a portal MUST register its use. This is a one time event. I.e. during the active state, a portal never needs to reregisters an existing registration.
A portal MAY register multiple times with a portlet service (e.g. to create multiple registrations with different security needs).
The WSRP protocol MUST explicitly support registration.
The portal MUST be able to alter registration properties (e.g. extensibility lists, vendor version, etc) after registration without having to delete and renew an existing registration.
Portals/portlet vendors MAY support additional [non-protocol] registration mechanisms. WSRP will not be concerned with defining such mechanisms.
The portal MUST pass a name for itself that uniquely identifies it.
The portal MAY pass information describing the portal [vendor] type and version. A portlet service MAY use this information for logging/monitoring or other purposes. It MAY also use this information to infer extra portal capabilities [though it is RECOMMENDED that the extensibility list be used for this purpose].
The portal MAY pass an extensibility list. The extensibility list defines the set of portal extensions the portlet service may choose to utilize. This list MAY be empty [null] signifying no extensions are supported. When empty a portlet service MUST NOT utilize any portal specific extensions.
The portal service MUST NOT deny registration because of missing extensions (to enforce plug-and-play among various portal service vendors).
The portal MAY pass a service list. The service list defines a name, location, and description for a set of web services offered by the portal for the portlet services' use. This list MAY be empty [null] signifying no services are provided. When not empty a portlet service need not utilize any or all of a portals services.
The portal MAY pass a list of portal/vendor specific meta data allowing the portal to describe/pass any non-standard information about itself. This list MAY be empty [null] signifying there is no additional meta data. When not empty, a portlet service MAY ignore any or all of this extra information.
Upon successful completion the portlet service MUST return a registration handle to the portal. This identifier must be unique within the context of the service.
Upon unsuccesful completion the portlet service must return a null identifier and a [webservices] error indicating the problem encountered.
A portlet service MUST safely perform deregistration. After receiving a deregisterion, it MUST deny new requests. It MAY either let existing requests complete [i.e. make the deregistration a non-blocking pending operation] or return runtime errors.
After successful deregistration all handles created in the context of the registration MUST become invalid (e.g. the registration handle itself, all transient and persistent handles).
A portlet service MAY release transient and persistent resources associated with the registration once it is safe to do so.
The portal MUST pass the registration ID returned from the registration call for deregistration.
The deregistration process MUST indicate failure or success.
The portal MUST pass the registration ID returned from the registration call for deregistration.
It SHOULD be possible to use a secure transport for portal/portlet communication.
There SHOULD be means by which a portlet MAY authenticate the portal when a service request is made:
1. Authentication could be protocol-based (i.e. http/basic, ssl/certificate)
2. Authentication could be document-based (i.e. digitally signed)
There SHOULD be a means of describing in the portlet's metadata whether a secure transport is required and what the authentication method is.
There SHOULD be a key exchange mechanism for signed documents.
It SHOULD be possible to use a secure transport for portal/portlet communication.
It SHOULD be possible to use document encryption for secure data exchange between the portal and portlet.
It SHOULD be possible for the portlet to require secure communications be used between the portal and End-User.
It SHOULD be possible for a portlet to define roles that describe levels of service access associated with the role.
When the portlet exposes roles in its metadata, the portal SHOULD map portal users to portlet roles.
There SHOULD be a mechanism for the portal to assert one or more roles with a service request.
A portlet SHOULD be able to require the portal to authenticate the End-User.
It SHOULD be possible for the portlet to describe the level of End-User authentication required.
It SHOULD be possible for the portal to communicate to the portlet how it authenticated the End-User.
It SHOULD be possible for the portal to pass End-User profile data to the portlet in a secure manner.
It SHOULD be possible to secure instance parameter data passed between the portal and portlet.
It SHOULD be possible for the portlet to describe in its metadata which parameters are to be passed in a secure manner.
The portlet SHOULD have a means of describing in itās metadata how personal data is to be secured.
The specification SHOULD provide a mechanism for administering portlet configuration and settings.
The specification MUST NOT require that administration of portlet configuration settings be dependent on a particular UI framework.
The specification metadata MAY provide a means to describe the configuration settings of a portlet.
The specification SHOULD NOT impose a specific configuration settings and attributes data model on the portlet.
The specification SHOULD NOT require a portlet to be displayed in order to be administered.
The specification SHOULD allow different security requirements for administration and personalization.
It should be possible for a Consumer to initialize the Producer with context data that is computed dynamically in run-time. (This is different from the Embedded case where all initialization is done off-line) (This may be generalized to allow delivery of data at any point in the interactino).
It should be possible for a Consumer to receive context data from the Producer at the end of its interaction with the end user. (This is different from the Embedded case where no data transfer is available) (This may be generalized to allow receiving of context data at any point in the interaction).
Throughout the interaction with the end user, it should be possible for a Consumer to dynamically receive context data from the Producer, computer corresponding context data, and send the computed context data dynamically back to the Producer. (This represents that data customization to the configuration problem).
The Consumer should be able to send to the Producer context data that affects the Presentation Fragment generated. (And hence must be able to send the data before the presentation is transmitted).
The Consumer should be able to receive from the Producer context data that depends on the last user action. (And hence must be able to receive the data after the action is performed). (And from R403 and R404, must be able to send the data after the action is performed, but before
The Consumer should be able to determine that context data has been generated by the Producer, and act accordingly. (This may be trivial in particular implementations)
The specification shall define the meta-data that the Producer may publish about the context data mentioned above so that Consumers can effectively use the service. (We will need to discuss this: grouping, format and structure, inheritance, descriptions, access-control, inter-relationships. For each such piece of meta-data we need to assess multiple parameters that include value for Consumer, likelihood for being generated effectively, etc. We may also want to discuss whether there are any pre-defined properties specific to WSIA or pre-defined property types specific to WSIA.)
It MUST be possible for a WSIA/WSRP Consumer to read and set a Producer's context data multiple times during a single user interaction.
This specification must define a processing model which defines the valid order of invocation by a Consumer on a Producer of user action, property setting, and fragment generation.
A WSIA/WSRP Producer MUST support metadata on its properties indicating the nature of their changes as reported to the Consumer. Equivalent metadata should be passed from the Consumer to Producer on context changes originating with the Consumer. Changes should conform to the XML DOM mutation types: value change, insert, delete.
A WSIA/WSRP Producer MUST be able to receive and transmit incremental updates to its context data.
A WSIA/WSRP Producer MUST support metadata on its properties indicating their validation state. States include: error, default, valid, null. (Question: Should the Consumer be able to modify these metadata to indicate its own results in property validation? Or, just modify the property value and pass back to the Producer to try to correct/complete it? Neither?)
Both the WSIA/WSRP Producer and Consumer MUST be able to modify the structure of the instance data of its context data during run-time, according to the defined types of that context data. (Thus adding/deleting context data elements in addition to changing their values is supported, provided that those changes are still valid according to the schema of the context data.)
It MUST be possible for a WSIA/WSRP Consumer to address (access metadata, read and write values) a specific Producer entity's context data as scoped both to that Consumer and a specific end-user. All context data relevant to the combination of entity and end-user must be visible through the entity's context data, even if stored in associated session objects across invocations.
A WSIA Producer MAY support Consumer-specified binding expressions for whether properties (or property substructures) are "required" or "relevant", conforming to the XFORMS "bind" constraints language and semantics. Binding expressions may only be provided by the Consumer at Producer instantiation time, though must be evaluated dynamically as their instance data changes.
A WSIA Producer MAY support Consumer-specified binding expressions for computing how properties (or property substructures) are related to each other, conforming to the XFORMS "bind" constraints language and semantics. Binding expressions may only be provided by the Consumer at Producer instantiation time, though must be evaluated dynamically as their instance data changes.
A WSIA Producer MAY support Consumer-specified binding expressions for restricting the valid types of context data (or property substructures) conforming to the XFORMS "bind" constraints language and semantics. Binding expressions may only be provided by the Consumer at Producer instantiation time, though must be evaluated dynamically as their instance data changes.
Do we want to have the "exit" concept explicit in the model? As in:
The Consumer SHOULD be able to determine that the Producer has completed the interaction with the user and determine the state under which the interaction was completed, and returned information.
A WSIA/WSRP Producer MUST be able to accept Consumer-specified binding expressions and modify its context data accordingly? How is the Producer to indicate which context data can be modified and in what way? Does this requirement (and the XFORMS ones above) imply a "context data adaptation language"?
Memory configurator: By reading Producer property values for the manufacturer numbers and setting other property values for the Reseller number at the Consumer before output generation.
Availability: By reading Producer property values and editing those values at the Consumer to remove products which are not available. Alternatively, setting metadata on the context data indicating that some records are not to be displayed (which approach is preferred?)
Add to cart: User action is passed to the Producer which generates final property values, which are passed back to the Consumer in the return message from the action invocation. As in Eilon's question above, do we distinguish any particular actions as "end states"? If so, how are they declared; in documentation, somehow in the WSDL, in an endpoint description?
Personal profile entry automation: By setting initial property values at Producer instantiation time. Whether to skip initial screens is a Producer design choice, perhaps with properties to allow the Consumer to indicate a preference.
Restricting plan enrollment choices: Covered as in the availability scenario above; Producer generates instance data including all plans, Consumer removes those entries that are not required for its use. This decision can be based in addition on End-User specific data as in part 2 of this sub-scenario.
Sports portal: Context sharing for selected indy car driver; in order to keep this as a Customization scenario, assume that the Consumer controls the UI for those elements outside of LiveIndy, i.e. there is only a single Producer. In this case, user interactions with LiveIndy return property changes as above which are then used by the Consumer to compute properties relevant to its own UI.
Sports portal part 2: User interactions on the Consumer's part of the UI may trigger property changes passed in addition to the LiveIndy Producer. The Consumer will then query LiveIndy for its regenerated output before building the entire page to be returned to the End-User.