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

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:] 
Sent: Monday, March 18, 2002 9:02 
  PM
To: 
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>