OASIS Web Services Component Model (WSCM) TC

OASIS Web Services for Interactive Applications
Technical Committee

18th January 2002
teleconference 12:00-1:00pm EST
Minutes

Attendance at roll call

Duration

12:00pm - 1:00pm

Chair

Charles Wiecha

Agenda for 7th Jan

Meeting

• WSDL examples for WSUI in progress,
• aiming to feed Sasha's use cases into the templates that Dan has produced
• merged producer / consumer milestones were produced and sent out by Charlie (who's going to make an even bigger effort at just using HTML instead Word docs and Winzip :) )

• aiming to not have a heavyweight process, just enough representative business scenarios and use cases documented to lead into the April meeting. Proposed timeline (sent out to the group previously but reproduced here):

Friday 1/18

Review example glossary entries

Review strawman overall process for arriving at the Requirements document

Establish three sub-teams to work on refining the glossary, overall process, and Business Scenario template.

Develop business scenarios

Friday 2/1

Review initial glossary to facilitate Business Scenario descriptions

Review final process for arriving at the Requirements document

Review Business Scenarios submitted by TC members

Friday 2/15

Review additional Business Scenarios submitted by TC members

Decide which Business Scenarios to include, based on uniqueness, business value, and relevance to WSIA TC scope

Review strawman Use-case template with an example

Establish sub-teams to study the Business Scenarios and propose

Use-cases that represent selected activities within the Business Scenarios

Develop use cases

Friday 3/1

Review Use-cases submitted by the sub-teams

Review strawman Requirements document template

Friday 3/15

Review revised and additional use cases submitted by the sub-teams

Establish sub-teams to write sections of the Requirements document based on selected Use-cases

Develop business and technical requirements

Friday 3/29

Review Business Requirements section of the document

Friday 4/12

Review Technical Requirements section of the document

TC F2F meeting 4/17-19

Review the draft Requirements document

• suggested that we could do with a complete example to give everyone a clearer idea of the documents, Raman thinking Dan was going to that for us.

12:15  Dan reviews terms and document structure..

1st phase of process is documenting Business Scenarios. A Business Scenario is a real world example describing business and functional needs of the system. Business Scenarios are things like the Chanel and Amex implementations we've been discussing.

Q: Don't care how many business scenarios are initially submitted?
A: Right. We'll write them up and then filter them out later.

2nd phase is to take the Business Scenario and extract abstract definitions of activity, which are the Use Cases we're looking for. Possibly we'll see a many-many mapping between Use Cases and Business Scenarios. So a Use Case might be something like "Consumer aggregating UI content from multiple producers". The Use Case will typically take a perspective of one of the actors trying to achieve a specific result, and describe the flow of events to achieve that, but bear in mind that an actor is not necessarily an end user, it can be a system component. These Use Cases can also be seen as being represented/ manifested by the original Business Scenarios.

3rd phase is to then determine from the Use Cases what overall requirements (technical and business) do these Use Cases imply for an interactive application system.

Q: Not sure of value-add of the 3rd phase, our requirements are a combination of phases 1 & 2?
A: The requirements doc might just be a bullet list roll up of the information apparent from the Business Scenarios and Use Cases. The (Business and Technical) Requirements will be extracts from the Business Scenarios and Use Cases that are more focused towards the necessary deliverables of WSIA.

• suggestion we ensure that the Business Scenarios and Use Cases are not just things that we do today, but also things that we cannot do today - not just an improved stock quote!
• suggestion that when we prioritize the requirements we do so with respect to the priority of the submitted Business Scenarios.
• to get the ball rolling we'll take the Business Scenarios documented in the WSXL paper + Sasha's list + then any others that people want to contribute (bearing in mind that we submit Business Scenarios that are still faithful / oriented towards the WSIA charter). We can vote on the ones we like at the next conference call.

action: Dan to document one from WSXL and send it round so people get the idea of the document usage.

12:35  Dan reviews Business Scenario Report document structure

Q: Makes sense to make it more specific to our needs (in face to face we tried to correllate our presentations to the charter)?
A: When the first doc is circulated (Dan) we can give feedback and suggested improvements.

Q: Must keep in mind that what we do has relevance to other communities (don't descend to making it too specific to ourselves). Someone who works in other areas (military, health) should be able to relate to our work. Our Use Cases should "work" for people in other domains.
A: Yep, also endeavour to get Business Scenarios for diverse communities.

action: Eilan volunteered to also produce the documentation for the Chanel example.

• we may (should) recognise not just technical requirements in the 3rd phase, but also business requirements and relationships and predicates, eg, trust relationships, data sharing between cooperating business entities. These should come out of the Use Cases too.

12:45  Defer on review of Use Cases for now, review glossary

Aim is to populate the glossary as we document the Business Scenarios, Use Cases and then Requirements. It's important to develop an agreed/understood vernacular within the team.

12:50  Change process

Editors:

• Jeff Broberg volunteered to be the glossary editor
• Eilon Reshef and Dan Gisolfi volunteered to co-edit the Requirements document.

Q: Make sure we only define terms as the need arises (discovery) from our own documents.
A: Yes, don't want to get into a big terms and definitions exercise. Also if we're using someone else's definition of something then we should link to it, not copy it, but our glossary might also contain stated definitions that are different to someone elses.

• access controls and access rights should be central to this committee (and will most certainly arise from the Use Cases)

action: Jeff to propose a process for changes/additions to the glossary

• In emails to the wsia distribution we should be consistent in prefixing the email subject line with [glossary] or a specific 4 letter code, etc so items relevant to subactivities can be easily traced and found. (Don't do private mailings to individuals, send everything through the distribution list).

action: Jeff and Eilon to recommend such for their docs.

12:55  plans for upcoming conferences

Looking for volunteers for conferences coming up that WSIA has been asked to attend. - OMG workshop on 3/7, XML Web Services in London, Nextware. At this point the presentation is more about motivations and drivers for the formation of WSCM (WSIA).

• Sean Fitts volunteered to create and present a presentation for OMG.

action: all - send email to the distribution list if you're interested in representing WSIA at one of these events.

Q: For this can we use stuff from the presentations we've seen within the committee, eg, at the face to face?
A: Yes, OASIS is all about openness.

Q: Any progress on relationship between us and WSRP and JSR 162 and 167 (portlet apis)?
A: We still need to nail the interdependencies, but recognise that the basis of WSRP lifecycle, events, actions etc is completely consistent/in common with WSXL.

1:00  adjourn.