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
My responses noted in the attached doc/html.
We can begin to address these in tomorrow's telecon as
well.
Alan
-----Original Message-----
From:
Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Monday, April 08, 2002 3:14 PM
To: Alan Kropp
Cc: 'wsrp@lists.oasis-open.org';
'wsia@lists.oasis-open.org'
Subject: Re: [wsrp]
[wsrp-wsia joint interfaces] Call in numbers for
telecon,Tuesda y 9 April
Alan,
I have read
through the 2 Use Case Reports: Embedded Producers and
Customized
Producers. As tomorrow's
discussion is focused on the Embedded case most of
my
questions pertain to it. However I do
have a general question -- I was
surprised
that "Customized Producer" document reinvented alot of what
was in the
Embedded
Producers
document -- By reinvented I mean tackled alot of the same function
though
at times a little differently
(What's all this stuff about stream oriented
operations anyway?). Am I correct that the "Customized" case is
merely the
"Embedded" case plus the ability of the
consumer to allow a producer to
expose and
manage instance settings? Can you clarify?
As for the embedded case, I need some help
with terminology. What are
properties? Are they "producer meta data"? Are they
arbitrary request
parameters? both? What
are WSIA portTypes?
And then specifically on the
document:
Section 1: Producers do not publish an interface to the
consumer other than
for
invocation with generic arguments. What does this mean? Why
is this
defined?
Section 3.1.1: URL rewriting: Note: <img> tags may
also need to be
rewritten -- If
the portlet lives behind a firewall the only way for a client to
communicate
to it
may be via
the portal even to get basic things like images.
Section 3.1.1: User profile: What discussions are you
having about privacy?
How
does
the consumer know whether the end user wants the producer to have
access to
its profile
information? Or is there a basic set of profile information
that users
give up their privacy
rights over?
Section 3.1.1: Operations/Actions: What are
operations/actions? Why do
they
exist? Are there consumer defined actions producers must be aware
of?
Section 7.1: Lifecyle -- "We therefore introduce the concept
of a 'Handle'
as a
remote
opaque reference to an instance of the service -- this reference may
be
equivalent to session
data.". Can you clarify what handle this is? Is it a
persistent handle? Or merely a runtime handle?
Given that "Embedded"
doesn't
define customizations it would seem to be the later.
Section 7.2.1: URL rewriting: there is a need to insert
an additional
parameter
(wsai:mapKey). Why? The document references a consumer maintained
mapping
table
but doesn't
motivate such a thing -- what specifically is this mapping table
used
for and why is it needed?
Even if its needed, why doesn't the consumer
generate
its own mapKey as its doing the
substitution?
Section 7.4.4: Are you planning on defining names or
types to represent
markup
fragment rules? I.e. I can conceive of two different consumers
having two
different sets of markup rules (one
consumer embeds you in an HTML table
while
another uses frames). In such a world don't the
consumer/producer need to
determine if they are
compatible by discovering each others capabilities?
Section 7.6.4: A producer must specify its supported
properties. Why? or
at least
Why all of them? This goes back to my initial questions
concerning what
properties
are. I understand why you would specify what WSIA properties you
support
but its
not clear why
anything else.
Section 7.7: Output -- Thomas raised the question/need that a
producer may
generate
output
that has to be aggregated into different locations in the markup.
Is
this
something that should
be covered/identified here?
-Mike-
Alan Kropp wrote:
> These call-in numbers are permanent going forward.
>
> USA Toll Free Number:
877-718-0936
> USA Toll Number:
+1-712-923-6878
> PARTICIPANT PASSCODE:
563151
>
> This week's
agenda is to walk through the Embedded use case in detail, and
> pay particular attention to the interface points with
WSRP, especially as
> details are emerging about
WSRP requirements in the following areas:
>
> 1. Property setting
>
2. URL rewriting
> 3. Lifecycle
management
> 4.
Security/privacy/authentication
>
> The current draft is enclosed.
>
> Alan
>
> -----Original Message-----
> From: Alan
Kropp [mailto:akropp@epicentric.com]
> Sent: Friday, March 29, 2002 10:24 AM
> To: 'wsrp@lists.oasis-open.org';
'wsia@lists.oasis-open.org'
> Subject: [wsrp][wsia]
Call in numbers for joint interface telecon,
>
Tuesday 2 April
>
>
Below please find the information for Tuesday's joint interface group
> telecon. If you're calling from outside the US,
could you please send me
an
> email..I'll need a count of international callers in case I need
to
increase
> the number of
slots.
>
> Thank
you.
>
> CALL
DATE: APR-02-2002
(Tuesday)
> CALL
TIME: 09:00 AM PACIFIC TIME
(12:00 Eastern)
>
DURATION:
1 hr
> USA Toll Free Number:
888-677-5736
> USA Toll Number:
+1-630-395-0182
> PASSCODE:
29067
>
LEADER: Mr
Alan Kropp
>
> Alan
Kropp
> Epicentric, Inc.
> akropp@epicentric.com
> 415 995-3512
direct
> 415 974-9821 fax
> http://www.epicentric.com
>
>
----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the
subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
------------------------------------------------------------------------
>
Name: WSIA Embedded Use Case.DOC
> WSIA Embedded Use
Case.DOC Type:
WINWORD File
(application/msword)
>
Encoding: BASE64
>
Download Status: Not downloaded with message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC