OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp 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
 
-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Monday, April 08, 2002 8:55 PM
To: 'Michael Freedman'; Alan Kropp
Cc: 'wsrp@lists.oasis-open.org'; 'wsia@lists.oasis-open.org'
Subject: [wsia] RE: [wsrp] [wsrp-wsia joint interfaces] Call in numbers for tele con,Tuesday 9 April

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