OASIS Web Services Interactive Applications TC

RE: [wsia] RE: [wsrp] [wsrp-wsia joint interfaces] Call in numbers fortele con,Tuesday 9 April

  • 1.  RE: [wsia] RE: [wsrp] [wsrp-wsia joint interfaces] Call in numbers fortele con,Tuesday 9 April

    Posted 04-09-2002 06:47
     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