Hi All,
Lack of concern or constraint upon look and feel isn't a general
Producer characteristic, just in the LCD Embedded Case. The other
cases, starting with Customized actually assume that when a Producer
publishes their services they can stipulate this and other factors,
and in the case of one of our seminal scenarios presented by Eilon
Reshef of Web Collage, based on a real client, a department store
boutigue,Sephora, I believe, was required by Chanel to make no
changes to the look and feel of Chanel-provided product ads which
Sephora, through Web Collage, repackaged to the minimal extent.
In your example, I believe we would call the enterprise which
customizes the look and feel the actual WSIA Consumer (if this were a
WSIA transaction). This is, in fact, a very apt example of a
customization use case scenario. When the enterprise changes hats,
republishes the service, the enterprise becomes a Producer and has
the option of placing a constraint on the ability of any subsequent
Consumer to make any further adaptations to the new first line
published service.
The list of approaches very neatly encapsulates many of the options
which require some sort of negotiation phase between Producer and
Consumer to come to an agreement or contract. This is where the
partner and the enterprise define their roles more precisely.
Our use cases are derived from scenarios and model the processes we
want to harvest for requirements. The summary I attached goes into
that. I happen to wrestling with another set of requirements, so this
process is getting pretty familiar.
I hope that makes things a bit more clear. When you live with this
for a while, it gets easy to lose track of what the rest of the world
understands about the work in which you're tighttly wrapped. I
suspect Charlie and Sean will have some interesting tales from their
recent presentations.
Ciao,
Rex
At 6:02 PM -0800 3/18/02, Greg Giles wrote:
>Hi All,
>There seems to be an assumption that the producer should not be concerned
>with look & feel changes, this should be the role of the consumer.
>I'd like to present a scenario based on a real world situation that may
>question this assumption (sorry if this is covering old ground which I
>missed during the f2f):
>
>- A large enterprise wants to publish a WSIA service to its partners e.g.
>the memory configurator
>- This is a value added service for which it charges
>- The enterprise also hosts tools that allows the partner to change look &
>feel (colors, URLs, gifs)
>- The partner wishes to display the network design application in context
>with the rest of the page e.g. show additional URLs to data sheets for the
>products being configured
>
>In this scenario, for a fee the partner signs an SLA with the enterprise,
>customizes the look & feel (hosted at the enterprise). Then embeds the
>service inside their system, using the data passed to display the context
>sensitive info.
>Since this is a fee based service the partner expects the enterprise to
>manage all the complexity, also the enterprise wishes to limit look & feel
>changes contractually and by offering a service that supports only
>acceptable changes.
>
>If look & feel is done by the consumer, the output the partner can receive
>is HTML/HTTP.
>However in order to make the context changes it would be far more useful to
>have SOAP/HTTP.
>
>There are at least four potential approaches:
>1. Have the enterprise host both a producer and consumer (consumer, acting
>as an intermediary, makes the look & feel changes). The partner hosts
>another consumer to pull out the relevant info and create the context hooks.
>This requires the consumer to support incoming HTML/HTTP
>2. Have the intermediary support outbound SOAP/HTTP (to easily support the
>context hooks), and continue to have the look & feel modification exist
>within the intermediary (consumer)
>3. Have the producer support look & feel modifications
>4. Have the look & feel modifications as a generic set of functions that can
>be implemented by both the consumer or producer
>
>This also touches on another topic which is the protocol required between
>producer and consumer, which I'll leave to another email :-)
>
>Thoughts or comments?
>Greg
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
--