[USTF] minutes of USTF con call 23-May 2002

USTF con call 23-May 2002

Present:
Gerald Edgar - Boeing
Roger Cutler - Chevron/Texaco
Katya - CMU
Heather Kreiger - IBM
Mark Hapner - Sun
Paul Denning - Mitre
Igor Sedukhin - CA
Dave Hollander - Contivo
Chris Ferris - WSAWG Chair
Martin Chapman - Oracle
Zulah Eckert - HP
Sandeep Kumar- Cisco

Dave H. - chair
Zulah - Scribe

ACTION:
1) Chair develop attendance list. Chris to send his list.
2) Liaison with non W3C groups on future agenda (Chris).
3) Bring up other groups involvement in the task force with the next CG
(Chris).
4) (Chris) add usage scenario editorial work to June F2F agenda.
5) Future action item to review completeness of our usage scenarios.
6) Next agenda -  categorization of the functional use cases. (Hao He -
5/22/2002 email)


Chris: Joint task force with description group has been discussed. We could
have a joint call because there is overlap between groups. We talked about
opening up the call to other members. Chris has also had a discussion with a
WS-I contact who is working on usage scenarios and use cases and they talked
about the possibility of leveraging each others work. Would the group be
willing to open up participation to WS-I people. Thoughts?

Gerald: Would feel better if I knew that they were open. Many members are
W3C members and could participate this way. Because of the current lack of
one major player for web services, this is a problem.

Dave H: Legal and patent policy issues.

Mark Hapner: Concerns because there are a set of privacy requirements that
the organization has and the individuals participating with us may not be
aware of their contractual requirements. Without a clear working
relationship that spells out intellectual property and privacy issues,
working with WS-I would be an issue.

Zulah: Concerned that we haven't yet within this group agreed to the level
of discussion and more groups involved will complicate this.

Dave H: finding a way to formally liaise should become an action item for
future meetings. So that our work is more influential in the industry as a
whole.

Heather: Is it possible to get a formal liaison?

Chris: W3C is dealing with this and we cannot unilaterally create one.

Dave H: Should we take an action to formally take this back to CG? Should we
open an invitation to other experts?

Katya: What is the argument in favor of having all W3C members?

Chris: Adding expertise from other W3C areas.

Katya: What is the goal of other members? To coordinate work? To have more
help?

Chris: To add expertise of area and where it is applicable to the work that
we are doing. For instance if the encryption WG has security use cases we
should incorporate their expertise and any work.

Heather: We are not talking about coordinating usage scenarios for the
entire W3C.

Chris: No. I am just suggesting that there are a lot of related usage
scenarios efforts and that we should leverage expertise.

Mark Hapner: Does OASIS and the ebXML work have any public scenario
documents that we could look at?

Chris and Dave H.: Unsure. Not very organized. (Unpromising sounds)

Dave H.: Review schedule from web page:
	- publish editors draft that has been published
	- snapshots 7/25-26
	- working draft by mid october

Sandeep (?) - any work during the F2F?

Dave H.: No plan for this so far. Take action item. Time is an issue. Even
is Dave gets called away, this work needs to progress. Is anyone willing to
help administer. Please send private note to Chris and Dave.

Dave H: 10 mins discussing goals and objectives for usage scenarios.
Unfortunately Dave O. isn't here and I have a different perspective.
Starting with goals, the goal of a usage scenario is to identify who the
stake holders are what there objectives are and an understanding of what
success is - everything else is negotiable. This means that we need to in
usage scenarios get a clean definition of who the stake holders are and what
the objectives are. Comments?

Dave H: Dave O's perspective is that we need to nail down how things work.
(Dave O may not agree with this perspective)

Mark Hapner: I agree with what you are saying. Scenarios are easiest to
interpret when they are described in a real situation and where you do the
stake holder and success description that describes a particular case but
also links to a general case. But if we try to do most general, its
difficult because we are all just users of the web. So it depends on at what
abstraction level we describe a scenario and from what level we try to
reason back to general. For current doc, these are extremely general message
oriented middleware messaging scenarios. These are not specific to any kind
of a direct business use and it is difficult to describe the stakeholders.
There is an assumption that messaging is the solution with general use cases
for messaging.

Roger Cutler: Has put forth EDI scenarios. He feels like this has dropped
into a well and there has been no plop. Big co. and small co. try to
purchase widgets from each other.

Dave H: Would like to introduce the third item on the agenda which got
started from Hugo and Roger's emails. How do we want to do usage scenarios.
We have to have two tiers of scenarios. A top tier for scenarios that are
rooted with a business need and ends at messaging scenarios. A second set
that says: given the set of requirements that fall out of the first level,
create feature scenarios.

?? : Atomic Tier and then a scenarios that connects to a top tier. The
atomic also connects to the csfs. Would it not also be useful to make a list
of what scenarios connect with what goals?

Sandeep: Goal is clear, review usage scenarios across the board so that we
can come up with a list of technology components that we need to build or
define as part of the architecture. This is the goal. So all of the current
input is good to look at and consider.

Dave H: I don't think that we can ignore this. If we review (adopt?) Dave's
document as it is and simply attach the two use scenarios (hugo and roger)
then we will get significant feed back about apples and rocks in the same
document.

Heather: We all realize the difference between usage scenarios (Dave O.) and
usage scenarios at the business level. We need to make sure that each
business scenarios tests the envelope in some direction.

Dave H: Takes this as agreement that we need to structure these into a
document.

Mark Hapner: Room for middle out, top down, and it will be useful to have a
broad range.

Paul Denning: Should cover all kinds of scenarios. When we put and
architecture on paper we will try to say "does this arch cover enough stuff"
and we will use the usage scenarios to determine this. The same for
requirements.

Mark Hapner: Small concern that we have scenarios that are clearly business
scenarios but there are other things that people want to do than just
transact business over the web. There are lots of information oriented uses
for web services. Can we shake some of these out. We are all commercial
focused. University uses? etc.

Dave H.: We mean business with a little b., as opposed to be big B.

Katya: One might want to find weather information (as an example of little
b).

Dave H: When we talk about stake holders and interests. When the interest of
a stake holder is beyond a web service like thing... There are technical
interests (like Dave O), there may be interests to achieve and end goal that
is not expressed in terms of technology. If you look at the template used by
Hugo and Roger, identifying stake holders and interests. When the interests
are expressed in non-technical terms, this is one level, vs. when the
interest is to perform a technical obligation. Suggesting that the real
identifier is the interest of the stake holders.

Mark Hapner: Web services assumes machines talking to machines but the truth
is that there is always people to people or org. to org. communication.
Organizations have a goal and they are delegating this to programmatic
agents. Scenarios don't well describe the role of programmatic agents and
separate them from people. So that you can get a strong feeling for what the
agents requirements are vs. the people.

Roger (?):When I did the EDI goal, big co and small co have different users
and different requirements because of this - to make something useful for
automated systems vs. a person cutting and pasting.

Mark Hapner: We are assuming that browsers are not part of the web services
picture but I'm not sure that this is the case.

Dave H: The technical details of Rogers scoping statement is interesting to
discuss. If I look at ?? from Dave O's document. He is pointing out a
technical motivation as opposed to a user motivation. EDI case could
terminate in a series of these scenarios.

Mark Hapner: So this would be an implementation vehicle within the larger
scenarios.

Katya: The big scenarios and small technical scenarios can be organized
well...

Dave H: (Describes specifically how we could connect detailed scenarios to
higher level scenarios. By reference.)

Katya: This is not our first duty. Once we have enough of the low and high
level then we can see how they may go together.

Dave H: Would like to spend time on the structure of the document. So last
comments on current discussion.

Sandeep: Have to have at least one more use case that has a higher level
business orchestration. So for example that involves multiple intermediaries
that add value in terms of the middleman - the middleman that does billing,
security, auditing. A broader coordination based plug and play services kind
of use case would be useful as well.

Dave H: I generalize this as completeness? You want complex orchestration
and multiple intermediaries.

Sandeep: yes.

Mark Hapner: Soap concept of intermediary is hard to characterize from a
business sense. Intermediaries that are full web services and are doing a
job for you make sense but protocol intermediaries - this is what SOAP is
like.

Dave H: Because of how they (SOAP intermediaries) were introduced there is
at least one company that can provide use cases for them.

Roger (?): there are companies that provide intermediary services today. We
could use them as a template.

Dave H: Would like to go through Roger's EDI use case. To talk about the
structure. One of the symptoms of a good structure is that it made you think
about the problems in different terms.

Roger: what is the difference between stakeholder and interests, actors and
goals?

Dave H: (Cogburn: writing effective use cases) Stake holders and interests
have a vested interest in the system operating as designed whereas the actor
may not be motivated . The store owner is motivated to sell, the cashier is
an actor because they stick money in a drawer. Difference between an
engineer and person responsible for sales of product is the difference
between a stake holder and an actor.

Roger: what did you mean by extensions?

Dave H: You build the basic scenario and then extend it to handle additional
cases.

Roger: Two of the scenarios were extensions - failure of the process and how
to rectify. In talking with the EDI people this is where the real meat of
the requirements from in. There is no way that you can have a technical
system that will prevent people from screwing it up somehow.

Dave H: From scenario 4, this is more of an extension. Primary scenario is
big co orders something from small co. Second scenario is big co brokers
(reverse auction) and small co wins bud in reverse auction.

Roger: Extensions in this case are very important. They have a lot of
structure and their own goals. In fact, the extensions are actually more
important that the main scenario. This is what explains why you need certain
things that otherwise you wouldn't think about.

Dave H: Scenario is one description, one set of stakeholder, one set of
actors, across multiple use cases. Does this make sense?

Katya: Are we trying to define what a scenario and what a use case is?

Dave H: If I look at Hugo's and David's, I see very different things. Next
week we have to make decisions about template and structure that we will
use.

??: Haven't we agreed that we want more than one level and that the lower
(atomic) level wouldn't be served by the structure currently being
discussed.

Dave H: Comments?

Katya: Are you saying that we should adopt the two templates? Have we gotten
the meat settled so that we can have templates? Is this just a case of how
we communicate with each other? One could nit-pick, ...

Dave H: One possible thing is to not worry about structure specifics. Taking
from common practice, all books on use cases will have their own variation
on a template. DO we want one structure or do we want to be agnostic?

??: We should have two structures.

Mark Hapner: Even the messaging level scenarios could benefit from
motivation of actors and what each actor is trying to accomplished. Less
detailed than higher level scenarios but more detail than they are today.
They are very technology specific. This is how you use SOAP. We should try
to cast the scenarios in a less technical specific...

Dave H: Or we could cast them in optionality - Http, SOAP, Etc.

Heather: Do we need to flush out these lower level scenarios? Cant' we just
point up to the higher level use cases?

Dave H: Would like to point down.

Roger: if an atomic solution doesn't point to some higher level (is it
relevant?)...

Heather: Is it enough flushing out to simply point from an upperlevel
scenarios to the lower level scenarios.

Dave H.: Sooner or later we have to do some referential integrity and
determine completeness. If we consider what has to be done first, and start
with the functional level group, then we could work on ratifying the lower
level ones and use the two higher level ones as examples. This is our
fastest way to get to publishable drafts.

Roger?: EDI might demonstrate a missing functional case.

Roger: How do we go about addressing this. There seems to be a need for
something that is less strong than reliable messaging but more than
auditing. Pretty good reliable messaging used for trusted business partners.
There has been a discussion of this where no one seems to own it because it
isn't really reliable messaging or auditing. This is my interpretation.

Dave H: We are out of time. This is a good topic for an ending. How do we
get proposed next steps and plan of action. My straw man for this is to put
a lot of energy into the functional use cases including what to do with
additional capability that is not described in the document and bring along
the higher level use cases slowly. Let's pick this up next week - same bat
time same bat channel.

??: Question, last week we discussed some high level categorization of use
cases.  Are we going to adopt these?

Dave H: This is an action for next week. Please review email before next
meeting. Use USTF reference on email.

Received on Friday, 24 May 2002 19:31:14 UTC