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

I've got some comments..

> 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.
>

I don't quite understand this concern from a WSA side.  If WS-I has a
privacy issue, that's their issue and not a W3C issue.  If they decided to
say something, why wouldn't we accept that?


> 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.
>

I've repeatedly heard the W3C say that they want lower level liasons, and
not formal high level liasons.  I don't understand why we could just say
that we will listen to WS-I input, and treat it as representative of a
significant group in the web services arena.

> 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.
>

The current doc does general message oriented messaging scenarios because
the original work is for SOAP messaging.  I've place skeletons of non
messaging aspects, particularly description and discovery, in the document.

A great thing about lower level usage scenarios is that they can be used to
generate requirements for working groups, and show paths through an eventual
architecture document.

> Dave H: Would like to introduce the third item on the agenda which got
> started from
> 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.
>

I agree.  Hence why I suggested the "business usage scenarios" should be
termed sample applications.   I believe that we will have many "technical
usage scenarios" and fewer "sample applications".  Another reason why I like
the term "sample application" is that it can be shipped as a sample with a
product.  If we do 3 sample apps - travel/stock quote/edi - then vendors can
ship these 3 sample apps.  Whereas if we call them "business usage
scenarios", it will be strange when we ship them as sample apps.  As an
example, "Check out the sample apps directory for the business usage
scenarios".

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

Strongly agree with middle-out approach.

> 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.
>

I think I agree.  The way I looked at it, was that we would relate the
sample applications to the usage scenarios to the arch document.  So a
sample application would use a variety of usage scenarios, that are met in
various aspects of the architecture.

> 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.
>

That's certainly what the TAG is saying ;-)

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

We could do it automatically, but I'd prefer to not try to do a whole bunch
of cross-referencing in the document.  That makes the doc very fragile.

> 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.
>

Oh no, the endless template discussion :-(  I have been part of this
discussion soo many times.  I think the biggest problem that occurs, and it
seems to occur every time, is that the template always grows in size.  And
so to create a simple usage scenario, there's a huge amount of often
irrelevent information and then the usage scenario gets filled with
irrelevent stuff and becomes unusable.  I don't know how many 250 page use
case documents I've seen rotting on somebody's bookshelf.  I am in favour of
a very loose template, where only relevent information is required.  The
saying that I like, "relevence is the test of intelligence".

> 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.
>

Where did the term "functional" come from?

If I understand the comment correctly, it's suggesting that we shouldn't
focus on the "technical usage scenarios" as they currently exist, that we
should move to a higher level ala the amazon/travel/ebay sample
applications.

I do NOT agree with this approach.  I don't think the group needs to spend n
months waiting for sample applications to find out *surprise*, we need
security in messaging.  We have customers who are developing *real*
applications, and they are telling us the scenarios that they are missing -
"I must guarantee exactly once delivery for my trade orders", "I must have
message integrity for my trade orders", "I must have signatures for my trade
orders", "I must be able to specify that after a trade order is received, a
poll message can be sent".  etc.

We have a choice to make on our process.  We could do the standard waterfall
approach: 1) figure out all the sample apps we want to solve over the next n
years; 2) figure out all the detailed usage scenarios for those; 3)
determine the requirements for all the usage scenarios; 4) figure out an
architecture that meshes all these requirements together; 5) create working
group charters for each of the pieces in the architecture.

And how long do we think this will take?  I figure 2 years minimum.  And
that is far too long, and completely unnecessary.  I think we all have
applications in our minds, a number of high priority usage scenarios and
rough idea of requirements, a variety of specs that meet certain usage
scenarios and requirements.

I can, and have, sat down and talked with many people in the WSA.  I've said
things like "why don't we work on reliability, workflow, security.  By
security I mean x, y, z".  And people typically say "yup, I tend to agree on
security, though I might want a little more.", etc.  The very fact that we
can have these discussions means that we have a shared understanding of the
requirements, usage scenarios, and sample applications.

I agree that we should use sample applications and have them.  But we should
not wait for the sample apps before working on usage scenarios and
requirements, nor proposing charters for working groups as DaveH suggests.
We are in danger of falling into the "completeness" and "linear order of
specification" trap, and I want to avoid both of those.  I think those are 2
of the key anti-patterns that make architecture committees fail by
delivering too much too late.

Cheers,
Dave

Received on Tuesday, 28 May 2002 03:26:15 UTC