OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[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