[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] Can a producer make look & feel changes?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC