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:] 
Sent: Monday, April 08, 2002 8:55 
  PM
To: 'Michael Freedman'; Alan Kropp
Cc: 
  ''; ''
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:] 
  
Sent: Monday, April 08, 2002 3:14 PM 
To: Alan Kropp 
Cc: ''; 
  '' 
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:] 
  
> Sent: Friday, March 29, 2002 10:24 AM 
> To: ''; 
  '' 
> 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. 
>  
> 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