A couple of comments to the points raised by both Elion and
Greg.
As Elion outlines, the roles of Producer and Consumer are separate from
the topology of the software being used and the choices of what tasks to
perform where. I believe that the goal is to keep the roles as
clean as
possible. Within those roles, the Producer defines what may be
changed
and the Consumer decides what changes to actually make. How
this
works is an issue to be decided in defining the interfaces between the
two.
There was (as I read it) an implication in Greg's question that the
choice
of what tasks to perform where would influence the protocol used to
communicate between Producer and Consumer. I don't believe that
this
is the case (at least not in my understanding). The interface
between
Consumer and Producer will be defined using WSDL and may be bound
to any number of protocols (including, but not limited to
SOAP/HTTP). I
expect that we will not have them talk using HTML/HTTP, though the
messages may contain markup intended for display to the end-user.
Greg,
if I misread your question, just ignore this.
Lastly, on the issue of property driven adaptation vs. markup
driven
adaptation, I wasn't present at the smaller group discussion, so I may
be
covering old ground. However, I have significant concerns about the
property
driven approach that extend beyond back-compatibility. To me, the
property
driven approach implies that the producer must predict all of the changes
that
a consumer may want to make (since they are responsible for implementing
them). This may seem attractive from a Producer control standpoint
(which
I agree is an important issue), but I think it will have the effect of
limiting the
re-use of services. Certainly our experience to date suggests that
it is very
hard, if not impossible to predict the ways in which Consumers may want
to
adapt services and so I would argue we should err on the side of
flexibility.
I understand the complexities that Elion outlines, but I think it is
possible to
balance them and achieve both our goals. It is also worth noting
that many
of the same issues must be addressed to allow Consumers to describe
changes
to the internal flow and behavior of services they are using, so I don't
think we
will be able to avoid them entirely anyway.
As an aside, I also have concerns about the property based approach from
the
standpoint of how work is distributed. This is a minor concern, but
I would
prefer to see a design which is less centralized.
That's my $0.02. Thoughts/comments?
Sean
At 11:39 PM 3/18/2002 -0500, Eilon Reshef wrote:
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>
