ࡱ >
k mj bjbj ~J } } 9d l 4 p( p( p( h ( ) jc + F. . . . /2 7 m9 b b b b b b b $ f ,h b I: +2 /2 I: I: b 3A . . ? b P 3A 3A 3A I: < . . b 3A I: b 3A 3A I 2 +^ c` . x+ >p{% t p( > _ . c` 4 "c H jc _ v h @ h c` 3A SUBJECT \* MERGEFORMAT Requirements Document
title \* Mergeformat Use Case Report: Embedded Producers
Version <1.3>
Revision History
DateVersionDescriptionAuthor05/Mar/20021.0Aggregated ProducerDan Gisolfi, Graeme Riddel, Alan Kropp, Eilon Reshef, Gil Tayar, Rex Brooks, Ravi Konuru, Keven Brinkley, Aditi Karandikar, Monica Martin, Rich Thompson, Charlie Wiecha06/Mar/20021.0Renamed to Embedded ProducerCharlie Wiecha20/Mar/20021.1Updated flows, added requirements sectionRich Thompson22/Mar/2002Added requirementsCharlie Wiecha25/Mar/20021.2Added requirementsRich Thompson29/Mar/20021.31) Rework Requirement section to separate discussion of a requirement from a more succinct statement of the requirement.
2) Incorporate changes from 28/Mar/2002 telecon and followon notes from participants. Rich Thompson
Table of Contents
TOC \o "1-2" 1. Definition of the Embedded Producers use case PAGEREF _Toc4812055 \h 2
1.1 Brief Description PAGEREF _Toc4812056 \h 2
2. Actors PAGEREF _Toc4812057 \h 2
3. Flow of Events PAGEREF _Toc4812058 \h 2
3.1 Basic Flow PAGEREF _Toc4812059 \h 2
3.2 Alternative Flows PAGEREF _Toc4812060 \h 3
4. Diagrams PAGEREF _Toc4812061 \h 4
4.1 Relationship between Producers and Consumers in the Embedded Producers Use Case PAGEREF _Toc4812062 \h 4
4.2 < First special requirement > PAGEREF _Toc4812063 \h 4
5. PreConditions PAGEREF _Toc4812064 \h 4
5.1 < Precondition One > PAGEREF _Toc4812065 \h 4
6. PostConditions PAGEREF _Toc4812066 \h 4
6.1 < Postcondition One > PAGEREF _Toc4812067 \h 4
7. Requirements PAGEREF _Toc4812068 \h 4
7.1 Lifecycle: PAGEREF _Toc4812069 \h 4
7.2 URL rewriting PAGEREF _Toc4812070 \h 5
7.3 Authentication / security PAGEREF _Toc4812071 \h 5
7.4 General PAGEREF _Toc4812072 \h 5
7.5 ServiceDescription: PAGEREF _Toc4812073 \h 5
7.6 Property management: PAGEREF _Toc4812074 \h 6
7.7 Output: PAGEREF _Toc4812075 \h 6
7.8 User interaction: PAGEREF _Toc4812076 \h 6
7.9 WSIAPersistent: PAGEREF _Toc4812077 \h 6
7.10 Basic Look and Feel Adaptation: PAGEREF _Toc4812078 \h 6
title \* Mergeformat Use Case Report: Embedded Producers
Definition of the Embedded Producers use case
Definition: Control over selection, configuration, placement of Producers within a Consumer is under manual (i.e. either Administrator or End-user) control. Producers do not publish an interface to the Consumer other than for invocation with generic arguments (not Producer specific). Arguments may include, among other things, user profile, output markup preferences, language, and device preferences. Producer specific configuration is via separate edit pages, i.e. not reflected in the Producer's interface.
Brief Description
Actors
There are three actors in this use case:
Producer: one or more WSIA web services
Consumer: a container which instantiates and controls interaction with one or more Producers on behalf of End-Users
Consumer Administrator: a person who instantiates and configures Producers in one or more Consumers on behalf of End-Users
End-User: a person who interacts directly with the output of the Consumer
Flow of Events
Basic Flow
While the following discussion is in terms of portlets, these should be viewed as a special (and common) case of embedded WSIA services where the Consumer is a portal. This use of portal oriented terminology is for clarity and not intended to restrict the set of actors to the special cases of portals and portlets.
Admin created portlets
[Traveler's checks] Travelers Checks applications as-is within a corporate portal
[Portlet] Consumer Administrator finds remote portlet service in UDDI, places portlet on a page for all users, uses the portlets edit mode to configure the portlet for the Consumers page, persistently saves the configured portlet. End-User accesses page and views/interacts with displayed output.
Pages should be cached to reduce load on remote portlet service.
End-user entered data is transferred to remote portlet imbedded in parameters or properties of the portlet.
To facilitate the correct mapping of an End-User interaction to the correct instance of a remote portlet, the URLs contained in the page must be rewritten to both refer to the Consumer and provide it with the information necessary to map the interaction to the properties / operations of the correct remote portlet. One possible means to enable this URL rewriting include:
Producer marks all interaction URLs (distinct from reference URLs such as on an in XHTML) with a prefix of wsia:. This makes it unambiguous to the Consumer which URLs need to be rewritten.
Insert an additional parameter (preferably of a well known name such as wsia:mapKey) that will enable the Consumer to locate the correct record in some internal mapping table. This is essential if the Consumer is to correctly identify the Producer for redirecting the interaction. [It has been noted that ebXML has a similar concept throughout much of its API where a UID is passed to enable the lookup of a set of values in a registry. Since the need for this key is entirely internal to the Consumer (though its value is sent to the End-User in the markup and returned on the resulting invocation), requiring an external registry may be more burdensome than useful. Should be reviewed by the committee as a whole.]
The Consumer may also wish to change the operation name to reflect the need to pass through the remapping logic. [OR do the WSIA portTypes want to explicitly expose such an operation and standardize its signature?]
[Is there any utility in defaulting the operationName to invokeAction (from WSXL)?]
User profile transferred to remote portlet in parameters or properties or by reference to an external registry (such as UDDI).
Markup type configured by the Consumer at page load time based on End-User profile or device type in use by the End-User [Requires the Consumer to detect information about the End-User and the device. Is this information hidden by the web services stack in todays implementations?].
Alternative Flows
End-user created portlets
[Portlet] End-user locates a portlet in UDDI or through a search implemented by Consumer, places portlet on a page, optionally uses portlets edit mode to configure its output, persistently saves the configured portlet. End-user accesses page and interacts with displayed output.
The Consumer Administrator may restrict the set of portlets available for placement on a page even when the search is implemented via UDDI. This enables the Consumer Administrator to manage any business issues related to the portlets usage.
Output type configurable for different devices
[Multimedia sports portal, Mortgage center] Consumer must indicate to the Producer the device (mime?) type extracted from the End-User connection. Preference would be for this to be a well-known property of all Producers [Perhaps there are a set of these all using a wsia: prefix]. [Need to define a minimum set of required properties that are adhered to by all web services this may be guided by context see some of the work of ebXML CC just as a reference.]
Non-persistent remote portlets
[Portlet] Flow as 3.2.1 above, but with no persistence at the Producer. Configuration state returned to the Consumer for persistent storage. The Consumer is then responsible for supplying this information on any subsequent connections to the Producer. [Assumptions and business requirements would direct whether performance and loading overheads are acceptable.]
Diagrams
Relationship between Producers and Consumers in the Embedded Producers Use Case
< First special requirement >
PreConditions
[A precondition (of a use case) is a textual description of any constraints or dependencies that must be satisfied prior to entry of the use case.]
< Precondition One >
PostConditions
[A postcondition (of a use case) is a textual description of any constraints or dependencies that must be satisfied after termination of the use case.]
< Postcondition One >
Requirements
Lifecycle:
Both component and collection type services need to manage their Lifecycle and provide Consumers with means to refer to particular instances in subsequent calls (This need is related to the stateless character of WSDL services and should be supplanted with WSDL support for stateful services when that support becomes available). We therefore introduce the concept of a 'Handle' as a remote opaque reference to an instance of the service (though an implementation may choose to make this a reference to the equivalent of session data) and define basic operations to create, and destroy those instances.
Producer services SHALL manage their lifecycle such that a Consumer can access a particular instance during the lifecycle of the interactions between them.
It must be possible to operate WSIA services in a stateless manner as well as stateful. Stateless WSIA services may always return the same Handle from the create operation and will ignore any Handle passed in throughout the remainder of the operations. [How does a WSIA service indicate that it is stateless?]
A WSIA service SHALL maintain its condition, i.e. its state [Discussion question of persistence]
A WSIA service MAY maintain a stateful or stateless condition.
When a WSIA service maintains its condition in a stateless manner, a handle MAY be returned by the lifecycle operations.
Once a handle is returned by a service, no other handles SHALL be accepted by other operations.
Explicit creation of handles is not required. Handles may be created implicitly on requesting output for the first time. Such a handle will be returned along with the output in the response message. While this reduces the overhead of the create / destroy operations, it also requires the Consumer to send a complete set of properties on each operation invocation in order to deal with the possibility that the Producer may have used a timeout to clean up the underlying object. [How does the Producer indicate use of the implicit lifecycle semantics?] [Note: There may be a significant performance impact related to sending the full set of properties on each operation invocation.]
Explicit handle creation SHALL not be required.
If an implicit creation of a handle occurs, that handle SHALL be made available with the associated output.
URL rewriting
URLs need to refer to the Consumer in order to allow the correct state and indirections to be applied when processing an interaction from an End-User. Possible means for accomplishing this include:
Producer modifications during markup generation based on Consumer supplied information [How does the Producer indicate it is willing to make these modifications? Support for a wsia:BaseURL property?]. The Consumer would need to supply the base URL for referring to itself in a manner that allows for remapping user interactions back to the correct Producer. The Producer would then append information onto this base URL indicating how the interaction should be mapped to it (operationName should use a well-known parameter name such as wsia:opName [default value of invokeAction?]) and any additional parameters that the operation requires [Are opaque operations allowed to have parameters, or do they just act on the current state of the service with an update to the services properties being carried with the call?].
Consumer applied modifications. In this case the Producer marks all interaction URLs (distinct from reference URLs such as on an tag in XHTML) with a prefix of wsia:. This makes it unambiguous to the Consumer which URLs need to be rewritten. [IBM WPS team => a longer marker than wsia: with unusual character sets makes for more efficient parsing.]
In both cases there is a need to insert an additional parameter (preferably of a well known name such as wsia:mapKey) that will enable the Consumer to locate the correct record in some internal mapping table. [Does this need introduce a problem for multiple tiered chains of Producers/Consumers using the Producer modifications means?] This is essential if the Consumer is to correctly identify the Producer for redirecting the interaction when it arrives from the End-User. The Consumer will need to store any and all information in this mapping table that is needed to invoke the correct operation on the correct Producer.
A Consumer SHALL provide the capability to redirect invocations back to the Producer that sourced the markup causing the invocation.
An Consumer SHALL provide the capability to include input or additional parameters to the Producer.
A unique identifier SHALL be available to identify the correct Producer, the operation and any additional parameters (where applicable) for processing an invocation.
Authentication / security / privacy
Other standards efforts are underway for the purpose of defining security and authentication protocols for XML and web services. While WSIA will need to be concerned about these issues, it is expected that concern will be addressed by tracking the work of these other efforts., including:
At W3C:
HYPERLINK "http://www.w3.org/Signature/" XML Signature (joint with IETF) - The mission of this working group is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures.
HYPERLINK "http://www.w3.org/Encryption/2001/" XML Encryption The mission of this Working Group (WG) is to develop a process for encrypting/decrypting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intended recipient to decrypt it.
HYPERLINK "http://www.w3.org/P3P/" P3P The Platform for Privacy Preferences Project (P3P), developed by the World Wide Web Consortium, is emerging as an industry standard providing a simple, automated way for users to gain more control over the use of personal information on Web sites they visit.
HYPERLINK "http://www.w3.org/2001/XKMS/" XML Key Management The mission of this working group is to develop a specification of XML application/protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service.
At IETF
HYPERLINK "http://www.ietf.org/html.charters/geopriv-charter.html" GeoPriv As more and more resources become available on the Internet, some applications need to acquire geographic location information about certain resources or entities. These applications include navigation, emergency services, management of equipment in the field, and other location-based services. But while the formatting and transfer of such information is in some sense a straightforward process, the implications of doing it, especially in regards to privacy and security, are anything but. The primary task of this working group will be to assess the the authorization, integrity and privacy requirements that must be met in order to transfer such information, or authorize the release or representation of such information through an agent.
HYPERLINK "http://www.ietf.org/html.charters/cat-charter.html" Common Authentication Technology - The goal of the Common Authentication Technology (CAT) Working Group is to provide distributed security services (which have included authentication, integrity, and confidentiality, and may broaden to include authorization) to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms.
HYPERLINK "http://www.ietf.org/html.charters/xmldsig-charter.html" XML Digital Signatures see bullet under W3C
At OASIS
HYPERLINK "https://www.oasis-open.org/committees/security/" XML-Based Security Services (SAML) - will produce set of one or more Committee Specifications that cover use cases and requirements, core assertions, protocols, bindings, and a conformance suite, all of the aforementioned to be examined with respect to security considerations. The work will take the S2ML specification and the intended submission of AuthXML, along with any other relevant and timely submissions, into consideration.
HYPERLINK "https://www.oasis-open.org/committees/xacml/" eXtensible Access Control MarkupLanguage (XACML) - XACML is expected to address fine grained control of authorized activities, the effect of characteristics of the access requestor, the protocol over which the request is made, authorization based on classes of activities, and content introspection (i.e. authorization based on both the requestor and potentially attribute values within the target where the values of the attributes may not be known to the policy writer). XACML is also expected to suggest a policy authorization model to guide implementers of the authorization mechanism.
HYPERLINK "http://www.oasis-open.org/committees/rights/" Rights Language - The purpose of the Rights Language TC is to define the industry standard for a digital rights language that supports a wide variety of business models and has an architecture that provides the flexibility to address the needs of the diverse communities that have recognized the need for a rights language.
General
Export one or more component interfaces that expose enough information to enable adaptation, aggregation and integration while still allowing the application to evolve. [Not testable do we need to place some parameters around the types of extensibility?]
The WSIA portTypes SHALL provide a minimum set of criteria to enable adaptation, aggregation, and integration.
Do not preclude that applications will be built out of separate presentation, data, and control components using refinements of this embedded level of interface; this helps developers to separate design issues that if left intermixed in more monolithic objects would make integration for re-use in multiple channels more difficult.
The WSIA portTypes structure SHOULD allow for extensions.
The WSIA portTypes structure SHOULD allow for loose coupling to aggregated operations (i.e. [side note] they provide for flexibly exposed interfaces and operations).
To ensure a fit with existing web-based application architectures, generate markup that can be used by conventional browsers and devices through existing formats and protocols.
Producers SHOULD provide the capability to support legacy applications and infrastructure. [m2: This requires further definition or bounding.]
To ensure markup fragments may be aggregated onto a single page, markup restrictions need to be defined for common markup types. Note that the potential to republish makes this a recursive issue and that the wrapper around the composable markup fragment may not be applied until the tier directly communicating with the End-Users device.
Producers MUST comply with any markup restrictions defined for the markup types they generate.
ServiceDescription:
This category of interface provides basic inquiry operations that allow a client to:
Request the WSDL service description document (particularly useful when the service was not discovered through UDDI)
Inquire whether or not a particular portType is supported.
An alternative to UDDI SHOULD be available to request a service description.
Means to request a Producers attributes SHOULD be available. [Has dependencies on rights see 7.3]
Property management:
A WSIAXL service component must implement property management operations whereby Consumers clients can modify properties at times other than initialization. Should a simple form of property management -- perhaps to read and write a fixed set of config properties -- be defined here, and leave the extensible property management requirement for the Customized case?
Producers MUST support property management operations
Consumers MAY modify a Producers properties during the lifecycle of their interaction.
Producers MAY reject attempts to modify its properties. [Access control, read only properties, ]
Producers MUST inform Consumers which properties have actually been modified.
A Producer must specify its supported properties (including that particular properties are readonly) so that Consumer may modify them as neccessary. Preferrably this is done through a schema definition.
Producers SHALL specify their supported properties.
Producers MAY specify their supported properties using XML Schema.
There is a significant set of information that is typically relied upon when a Producer generates its markup (eg. desired contentType) and may be a set of useful properties for controlling the interaction between a Producer and a Consumer.
Define a set of WSIA properties:.
wsia:output/wsia:deviceType The device type that will render the output. [Is there a standard set of these defined somewhere?]
[Does it matter whether the Browser is a Internet Explorer or a Netscape Navigator particularly in issues like enabling cookies etc? Are additional properties required??]
wsia:output/wsia:contentType The type of content requested by the Consumer (WML, XHTML, PDF, )
wsia:output/wsia:supportedContentTypes (from WSRP) The types of content the Producer is willing to supply.
wsia:output/wsia:supportedModes (from WSRP) The modes where the Producer supports generating output.
wsia:baseURL Proposed means of enabling Producer URL rewriting. The Producer would concatenate any name/value pairs for the querystring portion of the URL onto this Consumer supplied baseURL.
wsia:cssStylesheetURL The URL for the CSS stylesheet the Consumer will use when sending the output to the End-Users device.
wsia:user/wsia:locale (from WSRP) The locale of the End-User
wsia:user/wsia:preferredCharacterSet (from WSRP) The preferred character set of the End-User.
wsia:cacheable (from WSRP) Boolean (?) indication whether the Producers output may be cached.
wsia:supportsQueuedOperations (does this get added by another use case?) This property was added for the scenarios requiring offline operations. It indicates that a Producer supports its operations being queued by consuming applications.
wsia:versionNumber This property allows a lighter weight versioning capability than registering a new service in a UDDI registry. It is expected this would be useful when the output of the Producer is changing, but its interface (operations/properties/ ) are not. In general this should be read-only to the Consumer.
wsia:urlRewriter Property indicating whether the Consumer expects the Producer to rewrite URLs based on the baseURL property. Possible values include Consumer, Producer, (Both??).
Output:
Operations related to generating the markup for the service. Returns an opaque representation of the object's output. Consumers must inform Producers of the desired output type. Preferred technique is through a WSIA defined set of properties (deviceType, mimeType, )
Producer MUST export a WSIA defined operation for requesting the output reflecting its current state.
Consumers SHALL set properties on Producers that control output generation.
The output MUST be testable against conformance rules (see 7.4.5).
User interaction:
The need to direct user interactions back to the Producer of the markup sourcing the interaction request can be addressed either opaquely (as per many portal environments today see IBMs WSRP submission) or transparently as unique WSDL operations. In order for Consumers to have no Producer-specific programming, the opaque means is essential.
Producers SHALL support an opaque operation by which Consumers may direct user interactions to the Producer.Operations related to handling actions originating from the end-user. This is a single, generic, action operation for all user interactions.
WSXLPersistencet:
Many interaction between Producers and Consumers occur in well defined contexts (eg. business agreement and/or a configuration preset by an Administrator. This oOptional portType that enables full WSRP interoperabilityprovides operations to create and destroy these persistently stored configurations.
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.
Basic Look and Feel Adaptation:
While a Consumer operating at the Embedded Use Case level is not performing Producer-specific operations, the need to reasonably aggregate the output of disparate Producers requires each to use the same general look and feel values.
Consumers SHALL have the ability to set the values of a standard set of items controlling the appearance of a Producers output.
A standard set of CSS classes MAY be used by a Consumer to control the appearance of a Producers output.
wsiaBackgroundColor
wsiaForegroundColor
wsiaFont
...
For client/browsers that do not support CSS, it will be useful for the Producer to have access to the values of the standard CSS classes for the purpose of generating output that may be reasonable aggregated with the output of other Producers.
Consumers MAY set a property on Producers specifing the CSS stylesheet with the Consumers values for the standard classes.
[m2: Conformance requirement see OASIS TC on Conformance.
Also as a reference example, see HYPERLINK "http://www.ebxml.org/specs/index.htm" http://www.ebxml.org/specs/index.htm.
(ebTA v 1.04 Section 9 on Conformance)]
DOCPROPERTY "Company" \* MERGEFORMAT OASIS WSIA Technical Committee
subject \* Mergeformat Requirements Document Version: <1.3>title \* Mergeformat Use Case Report: < Embedded Producers > Date: <29/Mar/02>
Confidentialsymbol 211 \f "Symbol" \s 10 DOCPROPERTY "Company" \* MERGEFORMAT OASIS WSIA Technical Committee, 2000page ii
Confidentialsymbol 211 \f "Symbol" \s 10 DOCPROPERTY "Company" \* MERGEFORMAT OASIS WSIA Technical Committee, 2000page 11
0 1 2 3 I J [ \ p ~ x I J M N ` a n p { | O P ] i } ~ ӾӾӷ j UmH nH u j UmH nH u mH nH uCJ aJ mH nH uaJ mH nH u
H hc
H hc
H hc
H h\c&
H hZc&
H h[c&
H hc&B*CJ OJ QJ h ph 5CJ j U 4 2 o p ~ $$If a$ . $a$ 9h Yj lj oD i i i i o i i i i o$ i $If $$If l \
$ 0 4
l a
i $$If l \
$ 0 4
l a $If . = I $C$Eƀ [c&