OASIS Web Services Interactive Applications TC

 View Only

RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]Terminology

  • 1.  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]Terminology

    Posted 05-22-2002 21:58
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    wsia message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]Terminology


    Title: Message
    A taxonomy question mainly to the WSRP folks (Thomas, Mike, ...).
     
    I think everybody is pretty much on the same page with regards to the term "session" which identifies the transient state. (And, as Rich noted, to people that come from an OO background, this would be the same as an object instance).
     
    The tougher one is the persistent key, which in WSRP is typically referred to as "instance", but as Rich noted this may be non-intuitive to people from an OO background (who think of transient object instances), and hence the need for a new term.
     
    Would you find the following, radically simplified, suggestion for an operation name intrusive:
     
    createPortlet
     
    Along those lines, a portal would call the operation createPortlet, would get back a (persistent) portletID and then (optionally) call createSession with the portletID.
     
    Note that using this taxonomy, a portlet is the "last persistent instance". So, multiple instances of the same mail portlet are multiple portlets.
     
    A few justification points:
    1. IBM's RPWS proposal used the term createInstance. However, clearly the term "instance" is meaningless by itself - an instance is always an instance of something, in this case I assume the intent was a shortcut for createPortletInstance. Hence, createPorlet conveys a similar meaning.
    2. The ability to create a persistent key seems to be only under the scope of WSRP and not under WSIA. WSIA supports a persistent key to create sessions and to subsequent operations, but wouldn't probably deal with how they are created and management (with all the associated issues that are well described in Mike's latest summary). Hence, the motivation to use a portal-specific name.
     
    Any thoughts from hard-core portal people?