The
more we discuss on this, I feel the big issues are Rights and License
agreements between the producer and consumer. For example, after
sale/integration consumer support? Who owns what piece ? Assuming that the
consumer offers the bundled services (bundled from various producers)
and acts as a producer - imagine like a Pyramid - if the end user runs into a
problem what happens? And there are issues, like stated below, what if the
consumer alters the service that the producer provided?
Besides Security and Integration standards, soft issues
like ownership and Customer Support (who supports what, and where do you draw
the line) are going to be BIG hurdles before Web Services becomes
ubiquitous. Does it warrant a seperate Working Group? I dont
know.....
Srinivas Vadhri
CommerceOne
-----Original Message-----
From: Sean Fitts
[mailto:]
Sent: Monday, March 18, 2002 9:29
PM
To: Eilon Reshef; 'Greg Giles';
Subject: RE: [wsia] Can a producer make
look & feel changes?
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>
