MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: 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.