MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] RE: [wsrp] [wsrp-wsia joint interfaces] Call in numbers fortele con,Tuesday 9 April
Title: Message
A couple of clarifications to the discussion
below:
1. The work on the Embedded use case and the Customized
use case within the WSIA group were done in parallel, but with joint discussions
which is the reason for both some of the overlap as well as the
differences.
2. There are (at least) two main difference between the
Embedded and the Customized use cases:
First, is the notion of Properties.
Properties are (at least, see more below) a set of abstract name/value pairs
that the Consumer (= Portal) passes to the Producer (= Portlet), which the
Producer can use to customize its behavior, layout or look and feel. Very
similar to properties in Visual Basic Controls, or even (to a more limited
extent) in EJB. The Customized use case must support the notion of arbitrary
Properties for customization purposes - it's unclear whether the Embedded use
case uses the same mechanism to transfer hard-coded data (e.g., the user id). To
the best of my understanding me (and IBM folks may correct me here) , in both
IBM's WSXL proposal, as well as in WebCollage's IWS proposal, the idea was that
the request the Consumer makes for the Producer includes a semi-structured
argument that is a collection of name/value pairs, the type of which is defined
in a schema that's part of the meta-data of the WSIA Web Service. We never
got to the discussion around the context of the property list - is it dynamic
(i.e., getPropertyList) or is it statically published as part of the WSDL
definition. Just to complicate the matters a bit more, there have also been
discussions around a notion called stream-based adaptation, which means that
along with the existence of properties, the Producer publishes a small piece of
definition/code that allows the Consumer to transform the output instead of the
Producer having to do so.
Another note regarding properties: the idea in the
Customized case is to go beyond an "opaque" state provided by the Producer to a
declarative "collaboratively-managed" state, in which the Consumer can "set"
(and maybe "get") property values, changing the behavior of the Producer in
real-time.
Second, is the notion of additional
Operations (in the WSDL sense = functions = methods). Whereas
in the Embedded case the Producer is completely generic (same WSDL interface),
it seems that in the Customized case, we need to support additional WSDL
operations (= SOAP functions) that are published by the Producer, to allow
out-of-band communication between the Consumer and Producer. Although we haven't
discussed this in depth, this is useful in case a tighter Producer-specific
integration is required (in the general case, the Consumer is not necessarily a
portal and may have custom code executing). Here I have taken the liberty to
call these additional operations operations, following the WSDL
terminology, but we haven't really discussed the relation between them and
actions or events. (So now we got three names)
Finally, I am also quite confused with the portTypes
issue - I am not sure whether it's an implementation detail/suggestion or
whether there's a deeper meaning to it, so it might be worth bringing up on the
call.
Regards,
Eilon