[wsia] [Use Cases] boundaries + customization

[Graeme Riddell <griddell@bowstreet.com>]

I've been thinking about each of the use cases in terms of customization and
variability. It might change slightly the boundaries between Customized and
Integrated. I wanted to pass on some thoughts and see if what the level of
consensus was. Quoted statements come from the minutes. It might seem like
I'm jumping the gun a bit on some ideas, but it helps me to have some rough
vision of the direction..

Aggregated: "No interaction between service and container / portal. This
maps to WSRP. The emphasis is more on the producer side." So only "minimal"
customization here, enough to make the embedded site functional in the new
container - probably implies link management/interception (it might have
some creative use of span tags to aid that). It's device markup that is sent
from the producer (the intent being to get maximum leverage of the world's
simple sites with minimum effort).

Customized: "Changing the look and feel through what we called "adaptation
points" before. eg, might want to change the menu bar." I see this one as
facilitating much richer customization by the consumer. One suggestion for
the customization mechanism is to call multiple "setter" methods in advance
of the service call, etc. My vote would I think be to allow this consumer
customization by not sending device markup here but sending some richer
XML-based description of the content that can then be interrogated and
massaged by the consumer. Maybe this is where X-Forms comes in. 

Integrated: "Data exchanged at a fine-grained level". So customization might
be achieved here by the calling of multiple fine-grained methods on the
producer who then provides opportunity for "choice" in the resultset. I'd
still argue for descriptive result content which would then accommodate
further customization on the consumer side.

Note - one thought on scalability: The Customized case with rich data
description is probably a more scaleable pattern, since the producers do not
need to cater to all preferences of all users of all consumers. The
consumers handle the output modification accommodating the desires of their
users, the producer does not care. In the Integrated case the producer
chooses to provide additional customization (and finer service granularity)
through additional methods / setters. There's an implication of session and
state in the Integrated case, not necessarily in Customized or Aggregated.

Coordinated: "In page wiring" and aggregation of content from multiple
producers into a consolidated view. Argues for the rich content description,
allowing the consumer to intelligently wire things together. It might build
on Customized and Integrated Use Cases.

Orchestrated: "time based flow" allowing for adaptation of flow on the
consumer side. Also builds on Customized and Integrated.

So I think in all (except the first) consumer customization is implied, and
achieved via a rich data description (and in the Orchestrated case by a flow
language too). I think variability (my other main consideration) is probably
achieved in all of these cases by the separate issue of having a rich
service description (eg, WSDL-based) that allows the consumer to make
intelligent decisions about the services he consumes, and also by choosing
to omit some service calls, include others, etc. 

Also, might it be worth renaming the first (simplest) case to something
other than Aggregated? Maybe "Embedded" or some other description that
suggests that it's minimal change. Aggregated sounds like a much more
value-added case?


:-) gr 
603.559.1556