[wsia-comment] Summary of WSIA Requirements Process 3-17-02

[Rex Brooks <rexb@starbourne.com>]

Hi Everyone,

A couple of working sessions ago I asked for a summary to then of the 
candidate use cases that were under consideration in the WSIA, but these 
changed and then the changed use cases were examined further, and the 
process is on going. Part of the reason for that request was that in the 
HumanMarkup TC we are also in the process of writing a formal Requirements 
Document, and I wanted to show the HumanML TC how the WSIA was going about 
the same kind of work, albeit with different kinds of specs/schemata to 
produce.

I also wanted to set the stage for determining where in the WSIA process 
(not the Requirements Process, but the actual Web Services for Interactive 
Applications Specification) of a standardized set of requests for services 
and responses /delivery of services, HumanMarkup Profiles would be 
requested so that the HumanMarkup TC can prepare its Requirements and then 
its Specification to comply and interoperate as seamlessly as possible.

So, having had the time to work up a summary/history, I am attaching it 
here in two version, Word and ASCII. For HumanMarkup, I will also be 
writing up a comparison between our process, which includes the seven 
months preceding our entrance into OASIS, and the work we have undertaken 
since last October's initial meeting leading to writing our Requirements 
Document by March 31, 2002, and WSIA which held its first meetings in 
January and is scheduled to write and approve its Requirements Document by 
the end of its second series of face to face meetings in mid April.

One thing that both TCs should take into account is that there will be a 
variety of sources of individual profile information for End-Users, from 
basic, legal certification and authentication to greater depth of 
preferential and on-line behavioral information. And there will be issues 
of legal rights for authorized agents. A standard definition that 
distinguishes between an actual human individual and software agents of all 
varieties will need to be found and agreed upon. Of course that applies 
beyond these two TCs, but while we are in the process of determining 
requirements, that one concern is common.

ScenUseRqts .doc

Scenario to Use-Case to Requirements Process Summary

This is a summary of the process used in moving the OASIS Web Services for Interactive Applications Technical Committee toward writing a Specification or set of Specifications for a standard method of organizing and delivering web services in a wider range of media, information and data combinations than currently offered or possible in as wide a range of suppliers and delivery methods as our scope allows.

Specifically, this summary examines the process chosen to do this. For this working process we chose to begin, after setting the scope of our work, by using the concepts of:

? WSIA Producer;
? WSIA Consumer; and 
? End User 

as the primary actors in the exchange of services we want to write an XML Schema/Specification or set of Schemata/Specifications to enable.

To do this, we decided to solicit a set of Business and Institutional Scenarios which could be seen to typify the transactions we want to facilitate. This is an effort to ground our work in concrete, tangible transactions that members could document and use as references from which to derive a set of standard use-cases describing the informational transaction behaviors our language specifications or vocabularies must enable. From these use-cases, we determined that we could harvest the best or most representative set of requirements our Schemata and/or Specifications must fulfill.

This summary is being written as we proceed from having refined our five representative use-cases to the point where we are beginning to pull requirements from them in the final process of readying a set of requirements for inclusion in the formal WSIA Requirements Document. 

It may be instructive to note that we began the process without a predefined set of use-cases from which to pull requirements, but that we did start from a basis of scenarios explored in the first face to face meeetings of the TC. These included the two scenarios from the IBM WSXL paper, Traveler's Cheques 2nd-Party Sell-Through Scenario and Stock Quotes Distribution Scenario, Web Collage's Chanel 2nd-Party Sell-Through, an Airline Ticketing Scenario which would include a cancellation iteration, an Automobile Dealership Scenario detailing information flows from Manufacturer to Financial Institution to Purchaser, and an "Embedded" Mapquest type of inclusion within another Portal Application as an added-value to a combined service.

In the following week, during the TC's first teleconference we adopted a common format for description of the Scenarios derived from Rational Unified Process which outlined the roles of participants, their relationships and the flow of transactions. These have been presented in Word, Word-html and pdf file formats.

In the following few weeks we collected a wide variety of Business Scenarios, including those from the first meetings and one Institutional (Governmental/Educational) Scenario. These included: 

? Beauty Boutique--Chanel-Sephora example from Web Collage Presentation at First Meetings;
? Financial Charting;
? Information Sharing between Portal Servers; 
? Health Insurance Enrollment through Web Services;  
? Adaptation of Traveler's Cheques Purchasing;
? Multimedia Sports Portal; 
? Supply Chain Aggregation; 
? Post Acquisition Services Integration of Regional Bank within Multinational Banking Corporation;
? Wireless Stock Trading Service, and 
     ? Subsequent Modification--Mobility Enhanced Services; 
? Americans with Disabiities Act Educational Studies Information Distribution; 
? Syndication of Mapping Service; 
? Mortgage Center; and 
? an illustrated Buy.com - Kingston Configurator example of the adaptation of web services displayed on a website with callouts to highlight the presentation elements that exemplify selected web services deliveries.

(Note that the automobile dealer and airline ticketing with cancellation scenarios dropped out during this process due to lack of development by volunteer participation. This is noted only because the issue of cancellation has, as of this writing, not yet been readdressed as an inevitable process which this TC will in due course address when event handling is taken up.)

While collecting these scenarios and exploring the issues which they raised we defined an initial set of use-cases which were drawn from these scenarios:

? Aggregated--meaning collection and presentation (Pass-through of information and data) of WSIA Producer's Published Services by the WSIA Consumer as added value presented to End Users upon request without initialization, return of results or synchronization;
? Integrated--meaning Aggregated with initialization, return of results, and customization, but without synchronization;
? Orchestration--meaning Integrated with synchronization of orchestrated flows; 
? Composed--meaning Orchestration with interleaved integration, or customization of flows.

(For non-WSIA readers, flows refers to the sequence of activities, or interactions between actors that results in the transmission of services downward to the End User and Upward to the WSIA Producer.)

The basic idea of working on succeeding levels of complexity was then deemed to be a sound concept, but this set of candidate use-cases proved a bit too simplistic under further examination as the overall group decided to form a smaller task group to focus on developing use-cases in more detail. 

Based on another few weeks of work in the task group we settled on the following set of representative use cases which can be illustrated through examples from existing scenarios for the most part.

? Embedded--was Aggregated--is the simplest case, a lowest common denominator or minimal use case where the consumed services do not interact with each other, but are passed-through as is, and the most basic interactions are required, so the most fundamental requirements for a WSIA-specific set of container/wrapper tags or "handlers" can be derived as requirements. (If that is what we decide is needed.)

Further, this use-case can be used to help refine requirements between WSIA and Web Services for Remote Portals (WSRP) to provide for as seamless an integration of the two efforts as we can manage.

? Customized--sometimes referred to as Customized and Integrated--was Integrated--is the next more complex use-case where the WSIA Producer's definition of its Published Service includes and allows for adaptation modifications with specific information on properties and operations which enable programmatic access by WSIA Published Services on behalf of its End-Users.

? Coordinated--was Integrated--is the next use-case that extends the complexity of Web Services, in this case by allowing for multiple WSIA  Producers' Published Services to be combined by WSIA  Consumers to create a unified presentation to the End-User.  This begins to utilize statefulness in determining what is requested from WSIA  Producers who may know nothing about each other in regard to the combination of services to which their Published Services contribute and what is served to the End User. The WSIA Consumer will be responsible for this coordination of services which must flow in both directions according to states which will change.

? Orchestrated--is the use case in which the WSIA Consumer uses information coming upstream from the End-User or downstream from the WSIA Producer to alter the flow of services in a highly synchronized process in order to produce the unified presentation to the End-User. This is the ultimate combinatorial use case where the WSIA Consumer can insert their own information into a WSIA Producer's stream, combine multiple WSIA Producer's Published Services, or portions from each WSIA Producer's services as needed.

? (Re)Publishing?is the use case where two key factors occur:
      --negotiation of IPR usage, fees and permissions to use and/or modify or adapt a given Published Service--which can take any of several forms which have been mentioned--Web Services Licensing Agreements (WSLA), WSIA Contracts, or whichever combination of legal terms is determined to fit the needs we put forward in our requirements;
      -- a WSIA first line, first class, or first order service is offered as Published Service.

Whether we approach this first or last makes no difference since all of our use cases are examples which delineate discreet processes that can, and will, in reality happen in almost any combination possible. In essence we developed this use case to show how a WSIA Consumer can become an intermediary and a Republisher, (which can be seen as a special case of intermediary), by repackaging the Published Services of other WSIA  Producers and offering it to downstream WSIA  Consumers as a new first order Published Service.

From each of these Use Cases, approached in a standard format and examined as thoroughly as we can, we will pull the requirements which we will submit for inclusion in the WSIA Requirements Document we are about to start writing.