[wsrp][all] WSRP Bi-Weekly Phone Call May, 2nd

[Thomas Schaeck <SCHAECK@de.ibm.com>]

Dear WSRP TC Members,

here is the Agenda for the WSRP TC Call at May, 2nd, 9 am PST / 12 pm EST /
6 pm CET.

Attached, you find the relevant documents.


Accept Minutes from the last Call
---------------------------------

Duration: < 5 min

(see 4-18-2002 attachment)

(See attached file: 4-18-2002.txt)

Sasha, thank you for the minutes !


Business Scenarios
------------------

Duration: 45 min

- Content for Portals (Carsten) 15 min
  (see WSIASCenarioWebServicesForRemotePortals.htm and .doc)

(See attached file: WSIAScenarioWebServicesForRemotePortals.htm)
(See attached file: WSIAScenarioWebServicesForRemotePortals.DOC)


- Wireless Stock Trading (Aditi) 15 min
(see WSRP Business Scenario - Wireless Stock Trading.htm / ,doc)

(See attached file: WSRP Business Scenario - Wireless Stock Trading.htm)
(See attached file: WSRP Business Scenario - Wireless Stock Trading.DOC)

- Multimedia Sports Portal (Aditi) 15 min
(see WSRP Business Scenario - Multimedia Sports Portal .htm / .doc)

(See attached file: WSRP Business Scenario - Multimedia Sports Portal.htm)
(See attached file: WSRP Business Scenario - Multimedia Sports Portal.DOC)


In the next call, we can then review the remaining scenarios.

After the discussion in the group, everybody should update their scenarios
based on the feedback of the group, and especially update the list of
requirements resulting from the scenario.

We need to discuss the remaining Business Scenarios in the May 16th call
and finalize the Scenarios as of the May 30th call.


Comments on WSRP Overview Presentation
--------------------------------------

I've updated the presentation based on comments I got so far.

Duration: 5 min

(See attached file: WSRP Overview.ppt)

(See attached file: WSRP Overview.ppt)


Conference call details:
     In the US: 877-302-8255
     Outside US: +1 303-928-2609

When you dial in you will be asked for a "conference id".

The conference id is:  8814427


Best regards,

Thomas

Thomas Schaeck
Chairman OASIS WSRP TC
Attendance:

Angel - IBM
Alejandro - Sun
Mark - Netegrity
Carsten - IBM
Mike F - Oracle
Greg - HP
Dave C - Sybase
Adam & Jon - Lexis Nexis
Nigel - Factiva
Takao - Fujitsu
Charlie - IBM
Alan - ePICENTRIC
Sasha - Plumtree
Pete Quintas - Divine
Gil T. - WebCollage 
Eilon - WebCollage
Rich - IBM
Taer - Lotus
Madako - Fujitsu
Adrian Fletcher - BEA


Agenda (Carsten)
	First thing - summarize sub-groups
		Joint Interfaces - Alan
		Interface & Protocols
		PFBM
		Security etc

Common Interfaces (Alan)
	Have identified common areas worth discussing
		Security
		Markup/Rewriting
		Properties/Preferences
		Lifecycle
	Discussion was largely around the WSIA Embedded Use case
		Likely to be some commonality with Customized use case
	We will have a more firm group of requirements on Tuesday to go over

Interfaces & Protocols (MikeF)
	Been putting together a portal usage scenario
		How does it work and operate on portlets
		Will drive our requirements for the first version of the spec
	Taking the operations we're talking about, prioritizing, and trying to frame discussion around them
	Carsten: do you want to talk a little more about the open questions?
		I'm hoping to get that list together today, there are some ongoing discussion threads (personalization data location, what are actions vs. events (are the valuable), terminology)
	Jeff: Where are the definitions for the things we talked about?
		Sasha: look at the minutes from our F2F

PFBM (Mike)
	We've not had telecons, just doing preliminary discussions
	Trying to identify scope of what to look at first
	Major work will be in bind and metadata definitions
	Publish/Find is secondary issue
	Haven't made progress on requirements for bind or metadata
	Waiting for interfaces & protocols to be created to try and decide what metadata is important; also waiting to see what groups like JSR168 are doing

Markup Rules (Carsten)
	Are trying to define set of valid tags for the markups
	First step: try to concentrate on (X)HTML
	Discussion around whether we should create "positive" or "negative" lists
		"Positive" list might restrict functionality
	Angel: have you talked about combination of attributes?
		Carsten: no, just elements
	We've also talked about maybe having different sets of tags allowed depending on whether it's embedded in an IFRAME or a TABLE
	Has WSIA defined tags?  
		Charlie/Rich: not really
	Angel: There is a spec (that didn't make it to spec) to specify XML fragments, but it's a hard problem
	Sasha: have we talked about whether the list of tags would be dynamically negotiated?
		Carsten: It's been proposed, but I think there are problems with it.  It's still on the table, though.

Security, Identity, SSO (Mark)
	Decided to focus on three areas
		Portal's identity to the portlet/trust identities
		End-user identity/credentials
		Securing transmission of data
	A few use cases, need to extract requirements
	There are going to be security implications on metadata
	Also have looked at what standards efforts intersect/fit with WSRP; found 3 important ones
		XML Signature @ W3C
		XML Encryption @ W3C
		SAML @ OASIS (recently been frozen)
	Next step is to create a working requirements documents
	Carsten: what are the commonalities of this & WSRP?
		Alan: things are at a high level right now.  It's unclear to me if these things are shared or not.
	Carsten: we have talked about a binding context for security that 
	Sasha: have you looked at WS-Security?
		Mark: we're putting it on our next con call.
	Mike asked if this group should also look at things like caching; I think it shouldn't.  What do others think?
	Sasha: I agree; also, are you explicitly not doing things like data integrity?
		Mark: That falls into secure transmission

Business Scenarios (Carsten)
	Posted two scenarios: Content for Portals & Portals sharing Portlets
	Portals sharing Portlets
		One of the most important scenarios
		A large company has within its intranet multiple portals (maybe one for US, one for European branch)
		Parts need to be shared among/between portals (like a message of the day)
		One of the Portals could "assemble the content and publish it"
		The portal could put this info in a UDDI registry and make it available
		Easy to maintain: mods on the origin portal will propagate easily
		Alan: are you considering extranet case?
			Carsten: this use case is just intranet; you could have an extranet case among vendors as well.
		Actors are server portal admin, business reason is to manage portlet centrally & be able to make it easier to manage.
		Must be easy for other portal admins to access the content; should not have programming effort.
		Must have some sort of caching applied; central portal server should be able to cache the information
		Mark: Is the way the central and slave portals interact an important part of the use case?  May not want to have centrally managed in distributed case.
			Carsten: central is only important for this use case; not required for everyone.  Distributed
		Sasha: Have you looked at how we translate user info across portals & where we store personalization info?	
			Carsten: this is an intranet case where presumably you have a central user info store, so it doesn't deal with translation of user info.
		Also, slave portal passes along markup desired, locale, & language so that the master knows what to serve up
		Requirements
			Directory to locate common portal
	`		Standard interface to be used by client portal and central server portal so client portals are plug-and-play
			Definition on user data/preferences/locale/markup type/natural language
			Local Portals would allow users to personalize portlets, would need to be remoted so that users would need to be able to remote preferences
		Sasha: I don't understand that last requirement.  why would portlet personalization need to be remoted?
			Carsten: they don't for this use case, but it would be nice to have the preferences stored centrally.
			Sasha: from the slave portal perspective, it's not centralized
			Carsten: yes.
		Jeff: I'm nervous about this master/slave terminology vs. Producer/Consumer.  Can we rescope this 
			Carsten: the intent was not to do this; it was just to give a special case.
		So the client portal would only act as aggregator
		Business requirement is decreasing maintenance effort; code doesn't have to be deployed on client portal
		Must be easy to integrate with just a few clicks
		Client portal would have to suppy caching to take load off of server portal
		For client, it's important to be able to get markup and propogate user info back to the server portal
		Adam: Is the fact that there is an intermediary transparent to the end user?
			Carsten: this is out of the scope; all these portlets belong to the same company.
			Adam: we have relationships with companies where we have many contracts.  Just because it's behind the firewall doesn't mean that it can be used
			Carsten: i understand this, but it's not in this scope.
		Mark: Is this any different than the basic case of Portal/Portlet?
			Sasha: no, except for user translation
			Carsten: there is a difference because there is an intermediary.
			Sasha: that's an implementation detail, portal/portlet communication is the same
			Rich & Eilon: the interface won't change, the client portal doesn't really know about the implementation
			Sasha: it won't affect our interface over and above the portal/portlet default scenario, although user scenario would add a lot
			Carsten: I agree that this would not affect interfaces very much.

Wrapup (Carsten)
	Ok, we're running out of time; let's move discussion of biz scenarios to next call.

Title: Business Scenario: Content for Portals

WSRP Business Scenario

Business Scenario: Content for Portals

 

Version 1.1

 

 

 

 

Revision History

Date	Version	Description	Author
27 January 2002	1.0	Initial Draft	Thomas Schäck
21 February 2002	1.1	Revision	Dr. Carsten Leue

 

Table of Contents

1.       Web Services for Remote Portals 1

1.1     Description      1

2.       Participants          1

2.1     ContentForPortlets Inc      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     WESEREPOCON      2

2.2.1         Role            2

2.2.2         Relationships            2

2.2.3         Business Objectives            2

2.2.4         Solution Requirements            2

2.3     End-User      3

2.3.1         Role            3

2.3.2         Relationships            3

3.       References 3

Business Scenario: Content for Portals

1.                  Web Services for Remote Portals         

1.1               Description

ContentForPortals.com is a provider of visual, user-facing web services that plug-and-play with portals. ContentForPortals.com provides several visual, user-facing web services including functions like weather forecasts, stock quotes, news, sports results, airport flight schedules, etc. This scenario describes the kind of business relationships that will become possible with the introduction of the Web Services for Remote Potals (WSRP) standard.

The subject scenario pertains to the proliferation of visual, user-facing web services that can be integrated and aggregated by portals in order to redistribute them to the users of those portals. This document will focus specifically on the consumption of  visual, user-facing web services by portal servers.

2.                  Participants

2.1               ContentForPortlets Inc

2.1.1          Role

ContentForPortlets.com offers a variety of visual, user-facing web services including functions like weather forecasts, stock quotes, news, sports results, airport flight schedules, etc.

2.1.2          Relationships

ContentForPortlets.com offers their content to companies running portal servers either within corporations or on the Internet. Customers who want to use ContentForPortlets.com’s visual, user-facing web services to add value to their portals select the desired services and bind to them to make them available to the users of their respective portals.

In the subject situation, a big corporation known as WESEREPOCON wants to make some of visual, user-facing web services provided by ContentForPortlets.com available for their corporate users.

2.1.3          Business Objectives

ContentForPortlets.com wants to make their services available in a form so that portals across the world can find their services and bind to them with minimal effort so that the hurdle of using and buying their services is low.

2.1.4          Solution Requirements

§         Effective Publication: Allow ContentForPortlets.com to publish their services to a directory where all portals can find them easily.

§         Easy Integration: Allow portal administrators to find and bind to the visual, user facing web services of ContentForPortlets.com or similar providers with just a few mouse-clicks in their portal server’s administration UI.

§         Caching: Appropriate caching must be used at client portals to optimize response times for the end users and avoid excessive load on the services provided by ContentForPortlets.com.

2.1.4.1     Technology Requirements

§         Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist.

§         Standard, pluggable Invocation Interfaces and Protocols..

2.1.4.2     Functionality

Here are the main functionality use cases that are required in this scenario:

§         Development and Publication

o        Develop visual, user-facing web services and generate meta data describing them

o        Publish visual, user-facing web services to a directory that can be accessed by many portals, along with metadata describing them

2.1.4.3     Usability

Ownership of Usability issue resides with the StockPlot client.

2.1.4.4     Constraints

Non-modifiable fields TBD.

2.2               WESEREPOCON

2.2.1          Role

WESEREPOCON runs a corporate portal for their employees. They develop and run custom portlets for business tasks specific to their corporation on their portal platform as well as personal information management portlets. In addition to these local portlets, they want to make external content available to their employees, including airport schedule information and the current stock quote for their company.

2.2.2          Relationships

WESEREPOCON licenses the desired content from ContentForPortals.com for use in their portal.

2.2.3          Business Objectives

WESEREPOCON wants to make relevant external information (flight schedules, current stock quote of WESEREPOCON, local news) available to their employees by just plugging it into their portal, without wasting any time for integration or even programming effort for special portlets to visualize the information.

2.2.4          Solution Requirements

§         Easy Integration: Allow WESEREPOCON portal administrators to find and bind to visual, user facing web services of many providers with just a few mouse-clicks in their portal server’s administration UI.

§         Caching: Appropriate caching must be used to optimize response times for the users of WESEREPOCON’s portal.

2.2.4.1     Technology Requirements

§         Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist.

§         Standard, pluggable Invocation Interfaces and Protocols..

2.2.4.2     Functionality

Here are the main functionality use cases that are required in this scenario:

§         Finding and Binding

o        Find suitable visual, user-facing web services in a directory using appropriate portal admin UIs

o        Automatically integrate them into the portal as portlets (e.g. through portlet proxies)

o        Allow portal users to select portlet proxies representing visual, user-facing web service like local portlets

§         Run-Time Invocation

o        Invoke visual, user facing web services as appropriate

2.3               End-User

2.3.1          Role

As the final endpoint and actual Consumer of the ContentForPortlet’s visual, user-facing web services, the end-user represents the actual human user of the airport flight schedule and stock quote services. In this case they are users of WESEREPOCON’s portal.

2.3.2          Relationships

The end-user performs the actual interaction with the various visual, user-facing web services and is the ultimate trigger of all Run-Time use-cases associated with this business scenario.

3.                  References

 

 

Attachment: WSIAScenarioWebServicesForRemotePortals.DOC
Description: Binary data

Title: Use Case Report: <Use-Case Name>

Requirements Document

Business Scenario Report: Wireless Stock Trading Service

 

Version 1.0

 

 

 

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

 

Attachment: WSRP Business Scenario - Wireless Stock Trading.DOC
Description: Binary data

Title: Use Case Report: <Use-Case Name>

Requirements Document

Business Scenario Report: Multimedia Sports Portal

 

Version 1.0

 

 

 

Revision History

Date	Version	Description	Author
07/Apr/02	1.0	Initial Draft	Aditi Karandikar

 

Table of Contents

1.     Multimedia Sports Portal                                                                                                                                                        1

1.1      Description                                                                                                                                                                   1

2.     Participants                                                                                                                                                                               1

2.1      Multimedia content providers (ESPN, Ford etc.)                                                                                                    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      X Company (Service Provider/Aggregator)                                                                                                            1

2.2.1    Role                                                                                                                                                                      1

2.2.2    Relationships                                                                                                                                                      1

2.2.3    Business Objectives                                                                                                                                          1

2.2.4    Solution Requirements                                                                                                                                      1

Business Scenario  

1.                  Multimedia Sports Portal

1.1               Description

X Company is a multimedia services company that focuses on sports event coverage. The company would like to syndicate content from several content providers to create an integrated multimedia portal for Indy Car racing. This integrated service will allow a user to interact in an ongoing car race, by providing live, interactive videos of the circuit with a clickable map alongside. It will also provide videos and info. about the features of the participating cars and interviews with drivers. This scenario describes the use of multimedia in web services not yet possible with existing technology.

2.                  Participants

2.1               Multimedia content providers (ESPN, Ford etc.)

2.1.1          Role

Multimedia content providers like Sports video providers, Circuit map providers and Car manufacturers make their content available as WSRP services. These services (portlets) are listed in X company's private registry.

2.1.2          Relationships

Content providers deliver content to intermediary web applications and portals that aggregate content on a unified User Interface. By enabling their content as a WSRP service, aggregators/portals can add them easily. Web Service enabling their content also allows access to multiple distribution channels. Content providers may subscribe to affiliate programs to leverage customer bases.

2.1.3          Business Objectives

·          Add new channels of distribution

·          Leverage large consumer base through affiliate programs

·          Allow for co-branding with affiliates

·          Increase the number of consumers

·          Maintain brand control downstream

2.1.4          Solution Requirements

The consumer should be able to easily integrate multimedia content in his environment. For certain content providers like map providers, it is important to maintain brand control (copyright included) down the chain of consumers.

2.1.4.1     Functionality

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

·          Real-time: Support real-time syndication of content where relevant (E.g. race in real-time) 

2.1.4.2     Usability

2.1.4.3     Reliability

2.1.4.4     Performance

2.1.4.5     Supportability

·          Support direct client (HTML,WML,etc) or a Web Service, MPEG-4, Flash etc.

2.1.4.6     Constraints

2.2               X Company (Service Provider/Aggregator)

2.2.1          Role

X Company syndicates multimedia content from different content providers to create a multimedia portal service for Indy car racing.

2.2.2          Relationships

Content providers make content available as WSRP services, which are syndicated on X Company’s platform. X Company has relationships with other service providers too. These 3^rd party services are aggregated by X Company on its portal.

2.2.3          Business Objectives

·          Create a highly interactive multimedia portal for Indy car racing

·          Allow for co-branding with affiliates and content providers

·          Increase the number of end users

·          Use the best viewer available on the client side.

2.2.4          Solution Requirements

Since the service involves syndication of interactive content from different sources the synchronization aspect is important. Different media such as pictures, video clips, sound and data need to be synchronized to provide a high level of interactivity and a seamless end user experience.

The service would be able to be displayed on the client side by any renderer/player compatible with WSRP interfaces. This would allow the user to interact with an HTML, Flash or Mpeg-4 content.

2.2.4.1     Functionality

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

·          Plug – n – play portlets: Allow remote portlets to easily plug into web applications and portals

·          Real-time: Support real-time syndication of content where relevant (E.g. car race in real-time)

·          User profile: Maintain a user profile that tracks user interest and provides relevant info. based on user profile

 

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

 

 

 

 

Attachment: WSRP Business Scenario - Multimedia Sports Portal.DOC
Description: Binary data

Attachment: WSRP Overview.ppt
Description: Binary data