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

[Eilon Reshef <eilon.reshef@webcollage.com>]

Title: Message

Greg and team,

 

I think that there is an understanding and agreement that allowing Producers to control the modifications offered to the Consumers is an important (and mandatory) requirement, for the reasons you have mentioned and for others (branding being one).

 

From that point on, the discussion seems to split into two areas: enforcement and roles.

 

From an enforcement perspective, there is a realization that it's technically unfeasible to provide technical means to ensure that Consumers don't "illegally" temper with the presentation. Since the presentation eventually passes through their servers, they can physically change it. This doesn't seem to be a major issue, since the Consumer can also practically screen-scrape the Producer's public Web site even if the application at hand is not published as an WSIA Web Service. (And, BTW, there used to be a company called Patkai which I think provided technologies for signing XSL and HTML fragments. However, I assume that this wasn't a large enough business problem, as I think the company is no longer in business). Having said this, we still need to define - as part of the interface - what is it that the Consumer may change and assume that business agreements will enforce the rules specified in this interface.

 

Following from the point above, it remains to decide on the roles of the Producer and the Consumer as it applies to customization, and more technically, on the interfaces between them. We can suggest that the Producer does the customization using a mechanism such as Properties (in which case there's no real issue of control by the Producer) or we can suggest that the Consumer does the customization (in which case some sort of a definition language should be put in place to denote the allowed adaptation). (Naturally, there could also be a combination). As you noted, this question touches on the fundamentals of the interface/contract between the Producer and the Consumer.

 

Based on preliminary discussions within the smaller use-cases group, I think that there is a general consensus that Property-driven customization (i.e., Producer customizes the presentation based on context data from the Consumer) is cleaner and in general preferable. In this model, the Consumer sends the Producer a set of property values, and the Producer morphs the presentation accordingly. Natural implementation questions that come up in this context are how are properties defined (specifically, are they part of WSDL? schema?); how are values communicated (one at a time, all together?); when (statically as property sheets? part of the GetMarkup call? a separate SOAP operation?); what is the lifetime of the values (session? persistent?); etc. Lots of interesting questions - we haven't discussed any of those in depth yet, although several early thoughts have been brought up by different members of the team during the early discussions.

 

There is, however, a significant concern among some members of the team that providing just a Property-based approach may impede turning of existing Web applications into customizable WSIA services, as this may require changing the original applications. (Interestingly enough, I just had a short discussion about that point exactly with Rich from IBM earlier today). Thus, the idea of stream-based manipulation was brought as a potential method to "point" to existing pages (e.g., via XPATH), define a set of pre-defined transformations (as in your suggestion #4 below) so that they can be carried by the Consumer without code modifications by the Producer.

 

At a personal level, I have my doubts whether a Consumer-driven "external" approach is very practical, for several reasons:

==> An external "pointer" language has to be defined, presumably by this committee. Note that the closest thing that we have out there is XPATH, but it only applies to XML (and hence XHTML) and does not apply even to HTML, let alone CSS, Flash, etc.

==> The external "pointer" language has to pretty strong. For example, it has to refer to multiple instances of entities on the same page (e.g., there may be multiple elements on an HTML page that need to be changed when "something" changes to "red"). Also, there's the issue of how a single value is applies across multiple pages, each of which may demand a completely different set of "pointers", what happens if the pages are very dynamic, and what if JavaScript is involved.

==> Even the existing "pointer" language for XML - namely, XPATH - doesn't seem to be adequate for complex XHTML. This is because trying to point deep into a complex XHTML document is impractical to define, let alone maintain as the structure of the document changes. And, XPATH modifications of a document result in a new document which may invalidate other XPATHs that point to the same document.

==> In the end of the day, no matter how rich set of transformation WSIA will pre-define, Producers will always need to be able to provide their own (e.g., when the Consumer selects "red", show all buttons with varying shades of red), so a Property-based approach must be part of the overall solution in any case.

 

Note that some of the issues above can be resolved in different ways. For example, in the XHTML case, one can still use XPATH, yet suggest that Producers to add XHTML attributes to "help" the XPATH locators find elements within the page (Rich told me that this is the WSXL recommendation). However, in either case, introducing stream-based manipulation doesn't come without a cost. First, it significantly complicates the requirements from the Consumer, which has to implement all the pre-defined transformations on multiple output types. And, from an architecture perspective (i.e., a design-by-contract paradigm) it prevents Producers from separating the question of "what" is allowed to change on the pages from the "how", so that when the Producers make changes to their applications (e.g., they rewrite it to support customization as part of its implementation, or use a commercial product for that), the Consumers are naturally exposed to those details, which would otherwise be considered internal. And, finally, my main concern is that the stream-based customization is naturally more complex than the Property-based one, WSIA will spend considerable time on this capability.

 

Naturally, the discussion above follows from the typical balance between a clean interface (Property-based) and a backwards-compatibility requirement (support existing applications).

 

One idea on how to approach this issue is based an interesting observation that Bill Cox (BEA) made today in the WSRP meeting. (Bill: sorry if I am misrepresenting your thoughts). He noted (on a slightly different issue) that the fact that a particular vendor's toolset (e.g., IBM, Oracle, BEA) needs to address a certain business requirement (e.g., support legacy Web applications) doesn't necessarily mean that the protocol at hand must natively address it.

 

For example, it is very conceivable to assume that a certain portal vendor will provide - as part of its portal toolset - both a core Portal Server that consumes "clean" WSIA services (Property based) and also an WSIA Adaptation Server that adapts existing applications to become WSIA Web Services. This WSIA Adaptation Server is the piece of code that can handle XPATH logic, etc., but doesn't necessarily have to be the same actor (server/process/module) as the Consumer itself. In fact, that server may hide all those somewhat messy details from WSIA Consumers, which may be different organizations using different platforms.

 

If I understand correctly, I think this is more or less a variation of what you proposed as approach #2, in which case the enterprise (Producer) uses an intermediary that takes its existing applications and converts them into a WSIA Web Service. Like any adapter/broker, that intermediary can be bundled with a specific Portal offering or provided separately by third-party vendors.

 

Thoughts, ideas, comments?

 

Eilon

 

PS: I am also cc-ing the WSRP group, as in this short period of time until responsibilities between the two groups are decided, this may come up in the WSRP discussions as well.

-----Original Message-----
From: Greg Giles [mailto:ggiles@cisco.com]
Sent: Monday, March 18, 2002 9:02 PM
To: wsia@lists.oasis-open.org
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

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>