Use Case Report: News Feed

1. Definition of the News Feed use case

Definition: The consuming application (portlet container) will utilize a refresh mechanism to simulate push behavior from the producer (news feed service). The interaction between the portlet container and the news feed service will use a subscription model. The news feed service is aware of two distinct user roles, the Administrator and the End-User. These roles and the actions they support shall be communicated to the container at bind time. The Administrator actions shall consist of establishing the trust relationship between the service and the container via password authentication, and configuration of default behavior that is exposed to the End-Users. The End-User actions shall consist of setting preferences, and selection of citations to display the corresponding document.

It is assumed that the portlet container will provide the refresh mechanism. Additionally, the simplifying assumption is made that the news service shall persist all relevant preference data on behalf of its constituent users. The goal of this assumption is to abstract the getting and setting of individual parameters and focus on the actions exposed to the users based on their role. Also it assumed that there is an atomic set of actions that are exposed to the roles Administrator and End User. However, it would be a logical extension to define role mappings for each action. For example, rather than considering the End User role as having two interfaces (one for viewing content and one for setting preferences), the Portal Administrator could define the mapping at the action level, potentially splitting the atomic End User role into an “Editor” and “Reader” role as supported by the container role definitions.

2. Actors

There are five actors in this use case:

- News feed web service: producer of content to be displayed within portlet container

- Portlet Container: instantiates and controls interaction with one or more news feed services on behalf of End-Users

- Administrator: a person who instantiates and configures news feed web services on behalf of End-Users

- End-User: a person who interacts directly with the output of the portlet container

- Portlet Administrator: individual responsible for making portlet service available for their portal users. [Note: the Administrator would generally be the Portal Administrator, but exceptions may exist where someone other than the Portlet Administrator is responsible for establishing the business relationship and configuration of the portlet.]

3. Flow of Events

3.1 Basic Flow

3.1.1 Portal Administrator instantiates News Feed Portlet

Portlet Administrator finds remote news feed portlet service in UDDI. The Portlet Administrator shall bind the service to the portlet container. This process shall include the mapping of the news feed defined roles to portlet specific roles. Based on this mapping, a section of the portlet container users shall be defined as News Feed End-Users and a section of the portlet users shall be defined as News Feed Administrators. There shall be metadata provided to the Portal Administrator to aid in the definition of this mapping. This data shall include descriptions of capabilities of each role.

3.1.2 Administrator configures News Feed Portlet

The Administrator invokes the news feed administrative interface. This interface is only exposed to those users defined to be Administrators during the portlet bind process. This interface shall provide two key capabilities

1. Establish authentication information that shall be persisted by the portlet container and passed to the news feed service on all subsequent interactions. This authentication information shall represent the business relationship between the producer and consumer. The non authenticated news web service shall provide sufficient information for the Administrator to establish this relationship, i.e. sales representative contact info for new customers, explanation of subscription requirements for current customers, etc.

2. Configure preference information for the news feed service that shall be persisted by the producer. In order to access and set this data, the portlet container must provide a unique consumer ID, a unique portlet instance ID, and the corresponding authentication information over secure transport to the news feed service. This preference information shall include cache expiration, news topics to be displayed, and formatting preference for the citation and document views.

3.1.3 End-User Interacts with News Feed Portlet

End-User views citations, retrieves documents and sets preferences for the News Feed Portlet

§ News citations will be cached for a predetermined period of time, established via the Administrator interface

§ Upon expiration of the cache, the Portlet Container shall request an updated list of news citations from the new feed service, passing along the End Users ID, the unique consumer ID, the unique portlet instance ID, and the corresponding authentication information over secure transport. The news service shall authenticate the request, retrieve the preference information for the portlet instance ID, retrieve any preference information corresponding to the End Users ID, and supply the appropriate markup to the consumer.

§ End-User can select a given topic citation, this will result in a request to the portlet container to retrieve the document. This retrieval request shall provide End Users ID, the unique consumer ID, the unique portlet instance ID, and the corresponding authentication information over secure transport to the news service provider. The news service shall authenticate the request, retrieve the preference information for the portlet instance ID, retrieve any preference information corresponding to the End Users ID, and supply the appropriate markup to the consumer.

§ End-User can override a subset of the default preferences setup by the Administrator via an End-User preference interface. To access this interface, the portlet container must provide End Users ID, the unique consumer ID, the unique portlet instance ID, and the corresponding authentication information over secure transport to the news service provider. The resulting preference form provided to the consuming application shall allow several parameters to be configured. Some of these preferences may include update frequency, news topics to display, setting up additional news topics, and display formats of topic lists and documents. These parameters shall be passed over secure transport to the news service provider that will persist the data for the unique ID signature.

3.2 Alternative Flows

3.2.1 Portlet Container Forwards News Feed to an external Consumer

The End-User will access the News Feed service via an intermediate Portlet Container, acting as a web service proxy for the originating news feed service.

· This proxy relationship will not be transparent to the originating service, meaning that additional business rules may need to be applied to realize this trust relationship.

· The simplifying assumption is made that a sufficient criteria to realize this additional trust relationship shall be a “republish” flag which shall be passed on all requests to the news feed web service by the intermediary portlet container.

· Other than this additional flag, the communication between the intermediary container and the news feed web service is identical to that described in the Basic Flow, other than the End-User ID now pertains to the End-User of the final consuming application.

4. Diagrams

4.1 Relationship between News Feed web service and Portlet Container

5. PreConditions

5.1 Preexisting business relationship

The Business relation is established before any content is made available to the Portlet Container. This business relationship will be fully encapsulated via a single login, i.e. the news feed web service will be responsible for determining access rights based on its own data store. These relationship rules will include subscription model (billing, data sources, maximum users allowed, preference data, etc.)

6. PostConditions

6.1 Minimal Security Exposure

No information must be exposed to End-User that would allow access to the news feed web service outside of the portlet container environment, (i.e. authentication information which encapsulates the trust relationship will not be exposed to the End-User).

Revision History

Date	Version	Description	Author
06/Apr/02	1.0		Aditi Karandikar

Table of Contents

1. Wireless Stock Trading Service 1

1.1 Description 1

2. Participants 1

2.1 S-Trade (Application Provider) 1

2.1.1 Role 1

2.1.2 Relationships 1

2.1.3 Business Objectives 1

2.1.4 Solution Requirements 1

2.2 EZ Telecom (Mobile Service Provider) 2

2.2.1 Role 2

2.2.2 Relationships 2

2.2.3 Business Objectives 2

2.2.4 Solution Requirements 3

Business Scenario

1. Wireless Stock Trading Service

1.1 Description

The context for this scenario is the need for a Telecom Provider to provide value-added services to its end-users by moving from a pure provisioning model to an intermediation model through Web Services. In a world where network infrastructure and bandwidth are increasingly being taken for granted we think intermediation will play a key role in growing a Telco’s business.

1.2 The Scenario

EZ Telecom is a mobile service provider who would like to provide a stock trading WSRP service for its users. S-Trade is a financial services application vendor who provides the stock trading WSRP service, consumed by EZ Telecom. The scenario describes a stock trading WSRP service ported to different devices with real-time, offline capabilities and alerts. The offline mode would allow a user to store and retrieve pages on his device when the network is down (E.g. – a graph). The service also provides users real-time quotes for stocks and alerts the user of stock updates. Since the service is available on many devices and is multi-modal the user interface requirements for adaptation are different in each of the above-mentioned cases (i.e. real-time, offline, alerts). Since the end-users of this service are mobile and typically own more than one device, it is important to adapt the service in a device dependent manner.

2. Participants

2.1 S-Trade (Application Provider)

2.1.1 Role

S-Trade is a financial applications vendor who provides financial software to ASPs. In order to access multiple distribution channels the company is in the process of migrating its applications to make them available as Web Services. One of these is a stock trading application, which is already available as a WSRP service. The service, provides alerts, and buying and selling of stocks.

2.1.2 Relationships

S-Trade has relationships with other content providers like NYSE whose content S-Trade aggregates.

2.1.3 Business Objectives

· Expose financial services applications as WSRP Services to access multiple channels of distribution.

· Enable the end-user to access the service anytime, anywhere

· Maintain brand control in the provisioning chain

· Provide a better (seamless) end-user experience

· Increase the number of consumers

2.1.4 Solution Requirements

The stock trading service/utility can be easily integrated into the consumer’s environment and is seamless for the end-user.

2.1.4.1 Functionality

· New distribution channels: Allow consumers to easily provision for new channels of distribution & deployment

· Multi-modality: Provide multi-modal capabilities by enabling voice and web access to the stock trading service

· Multi-device support: Support multiple devices, protocols and networks

· Real-time: Support real-time/offline access to the stock trading service

· Alerts: Alerts on stock updates

· Unified Communication Interface: Provide a single interface for multiple technologies like synchronization, speech recognition and messaging

· Seamless Integration: Provide for seamless integration of the service in the consumer’s environment

· Multiple Markup Languages: Support multiple markup languages

· Multiple Data Sources: Support multiple data sources – RDBMS, VoiceXML, XML etc.

· Integration: Allow consumer to easily configure the service to adapt to the user interface of the consumer

2.1.4.2 Usability

· Consumer should be able to easily integrate the service into his own environment/application/service

· Consumer should be able to make changes to the user interface easily and quickly

2.1.4.3 Reliability

· Service should be available 24/7

2.1.4.4 Performance

· Network availability and speed maybe a problem

· Availability of 2G and 3G networks would improve performance of the service

· Unnecessary round-trips should be avoided

2.1.4.5 Supportability

· Services should support multiple data sources (detect and upgrade changes to content instantly).

2.1.4.6 Constraints

· Network speed

· Network availability

· Support for new devices introduced on the market

· Support for thick clients

2.2 EZ Telecom (Mobile Service Provider)

2.2.1 Role

EZ Telecom would like to provide seamless access to a stock trading WSRP service to its mobile users.

2.2.2 Relationships

Content providers can syndicate content directly to EZ Telco’s system using the relevant protocols/standards or they maybe part of an affiliate program.

2.2.3 Business Objectives

· Provide end-users the capability to trade stocks anytime, anywhere thereby reducing the churn/turnover.

· Increase brand awareness

· Allow for co-branding with affiliates

· Alert a user depending on his profile

· Drive business for content providers

· Allow content providers to easily add new channels

· Ability to interact with the user and use his profile for different promotional activities

2.2.4 Solution Requirements

Most end-users of this service are mobile and own several devices. A requirement of this service is the ability to maintain a single user profile for the different devices the user owns. Facilitate device appropriate data transfer (E.g. voice data to a voice enabled device).

2.2.4.1 Functionality

· Wireless interface: Provide a wireless interface to the stock trading web service

· Multi-modal: Provide multi-modal capabilities by enabling voice and web access to the stock trading service

· Multiple devices: Support multiple devices, protocols and networks

· Multiple channels: Support real-time/offline access to the stock trading service

· Alerts: Alerts on stock updates

· Unified Communication Interface: Provide a single interface for multiple technologies like synchronization, speech recognition and messaging

· Multiple markup languages: Support multiple markup languages or multiple templates/DTDs for XML

· Multiple data sources: Support multiple data sources (local & remote)– RDBMS, VoiceXML, XML etc.

2.2.4.2 Usability

· Wireless end-user should be able to personalize this service from/for more than one device.

· Ease of use in different modes – offline, real-time, alerts

· Ability to switch modes easily –voice & data -- ability to toggle between passive and active mode, passive being when a command needs to be executed to fetch an alert, etc.

2.2.4.3 Reliability

· Service should be available 24/7

2.2.4.4 Authentication

· Ability to identify users using a variety of methods, from UID/Passwords to biometrics.

· Ability to make authorization available over the network from multiple devices.

2.2.4.5 Performance

· Network availability and speed maybe a problem

· Availability of 2G and 3G networks would improve performance of the service

· Unnecessary round-trips should be avoided

2.2.4.6 Supportability

· Services should support multiple data sources (detect and upgrade changes to content very quickly).

2.2.4.7 Constraints

· Network speed

· Network availability

· Support for new devices introduced on the market

· Support for thick clients

wsrp message

3.1.2 Administrator configures News Feed Portlet

3.1.3 End-User Interacts with News Feed Portlet

3.2.1 Portlet Container Forwards News Feed to an external Consumer

5.1 Preexisting business relationship

1.2 The Scenario

2.1.4.1 Functionality

2.1.4.2 Usability

2.1.4.3 Reliability

2.1.4.4 Performance

2.1.4.5 Supportability

2.1.4.6 Constraints

2.2.4.1 Functionality

2.2.4.2 Usability

2.2.4.3 Reliability

2.2.4.4 Authentication

2.2.4.5 Performance

2.2.4.6 Supportability

2.2.4.7 Constraints

2.1.4.1 Functionality

2.1.4.2 Usability

2.1.4.3 Reliability

2.1.4.4 Performance

2.1.4.5 Supportability

2.1.4.6 Constraints

2.2.4.1 Functionality

2.2.4.2 Usability

2.2.4.3 Reliability

2.2.4.4 Performance

2.2.4.5 Supportability

2.2.4.6 Constraints