Re: [wsia] Can a producer make look & feel changes?

[Rex Brooks <rexb@starbourne.com>]

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>


--