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: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]createEntity/createTemplate/createPortlet


Title: Message
We are on the same page with the approach.
 
Three questions I might have:
 
1. Would URL parameters (e.g., http://foo.com/wsrp?s=weather) be more natural to those environments? (Still no need for an explicit parameter)
2. The problem we are trying to solve is a single service serving multiple portlet types (otherwise, there's no issue with either approach). Do we expect such services to use .NET out of the box or would it be reasonable to expect such service to implement custom SOAP-to-object mapping?
3. Would it make sense to assume that the function
createTransientThingy (...)
accepts a persistentThingyID as an argument, i.e.,
createTransientThingy (persistentThingyID)
and that persistentThingyID can be assumed to include <portlet type, portlet instance, [portal id]>
and leave the question whether we want to separate those components into explicit variables to a WSRP-specific discussion?
 
Eilon
-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Monday, May 27, 2002 6:36 AM
To: Eilon Reshef
Cc: 'Alan Kropp'; 'Gil Tayar'; 'Michael Freedman'; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet


Eilon - I would discourage the URL path approach because it seems as if
this worked only in a servlet world. The SOAP servlet intercepts the
request, interprets the remaining portion of the URL and addresses the
internal service according to this URL. E.g. a request to
http://foo.com/wsrp/weather would be intercepted by the
"htttp://foo.com/wsrp" servlet with the service identifier "weather". Do I
understand this approach correctly?
The problem is that this won't work in AXIS or in .NET. That's why I would
prefer to have a single service and do the dispatching using a class
identifier that is passed as an explicit parameter.


Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+----------------------------->
|         |           "Eilon Reshef"    |
|         |           <eilon.reshef@webc|
|         |           ollage.com>       |
|         |                             |
|         |           05/24/2002 07:33  |
|         |           PM                |
|         |           Please respond to |
|         |           "Eilon Reshef"    |
|         |                             |
|---------+----------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|

  |                                                                                                                                             |

  |       To:       Carsten Leue/Germany/IBM@IBMDE, "'Alan Kropp'" <akropp@epicentric.com>                                                      |

  |       cc:       "'Gil Tayar'" <Gil.Tayar@webcollage.com>, "'Michael Freedman'" <Michael.Freedman@oracle.com>, <wsia@lists.oasis-open.org>,  |

  |        <wsrp@lists.oasis-open.org>                                                                                                          |

  |       Subject:  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet                     |

  |                                                                                                                                             |

  |                                                                                                                                             |

  >---------------------------------------------------------------------------------------------------------------------------------------------|



Carsten,

Clearly there's a need for a single servlet to handle multiple portlet
types. Why do you feel there's a need for a single service (in the WSDL
sense) to handle multiple portlet types? Why not map multiple services,
each representing a different portlet type, into a single servlet using
WSDL techniques, such as URL paths, etc.?

Eilon
      -----Original Message-----
      From: Carsten Leue [mailto:cleue@de.ibm.com]
      Sent: Friday, May 24, 2002 10:48 AM
      To: Alan Kropp
      Cc: 'Eilon Reshef'; 'Gil Tayar'; 'Michael Freedman';
      wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
      Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec
      0.43]crea teEntity/createTemplate/createPortlet




      Alan -


      from my point of view there are a couple of advantages introducing
      the
      concept of a service container (at least for WSRP):


      - for WSRP all services are of the same type, so handling them (life
      cycle,
      invokation framework on the server, addressing) will be the same. In
      that
      case it is much easier to handle the request centrally at one single
      access
      point.
      - a portal might expose a large number of portlets. If there was no
      container the service would need an entry point (e.g. soap servlet)
      for
      each of the portlets. This is not only difficult to setup but may
      also
      consume a lot of resources (depending on your app server)
      - conceptually a portlet is something that runs inside a portlet
      (that
      manages access, lifetime etc) . So it makes sense to adpot this model
      to
      the remote case by introducing a service container.





      Best regards
      Carsten Leue


      -------
      Dr. Carsten Leue
      Dept.8288, IBM Laboratory B÷blingen , Germany
      Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401






      |---------+---------------------------->
      |         |           Alan Kropp       |
      |         |           <akropp@epicentri|
      |         |           c.com>           |
      |         |                            |
      |         |           05/24/2002 01:32 |
      |         |           AM               |
      |         |           Please respond to|
      |         |           Alan Kropp       |
      |         |                            |
      |---------+---------------------------->
        >
      ---------------------------------------------------------------------------------------------------------------------------------------------|


        |
      |


        |       To:       "'Eilon Reshef'" <eilon.reshef@webcollage.com>,
      "'Michael Freedman'" <Michael.Freedman@oracle.com>, "'Gil Tayar'"
      |


        |        <Gil.Tayar@webcollage.com>
      |


        |       cc:       wsia@lists.oasis-open.org,
      wsrp@lists.oasis-open.org
      |


        |       Subject:  RE: [wsrp][wsia][wsrp-wsia joint
      interfaces][Draft Spec 0.43]crea
      teEntity/createTemplate/createPortlet               |


        |
      |


        |
      |


        >
      ---------------------------------------------------------------------------------------------------------------------------------------------|






      Mike,


      Along the lines of Eilon's question, I'd like to have a better
      understanding as to what the WSRP Producer Container is for.  I
      confess to
      not being well-informed on the motivation for introducing this
      concept in
      the early interfaces/protocols discussions.  My hope has been that it
      is
      entirely a WSRP-specific construct, and therefore not something that
      needs
      to be accounted for in the joint interface.  But I'm not convinced
      one way
      or the other, yet.


      In the interests of furthering this discussion, if you could run down
      the
      main points behind the container, for both groups, I think it would
      be
      beneficial.


      I think Mike's outline of the lifecycle interfaces from a "pure" WSRP

      perspective, in relation to Gil's and Rich's latest rev of the joint
      interface specification, represents the clearest illustration yet of
      the
      "gap" we need to close.  This is good progress.


      Alan





            -----Original Message-----
            From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
            Sent: Thursday, May 23, 2002 3:36 PM
            To: 'Michael Freedman'; 'Gil Tayar'
            Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
            Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft
      Spec
            0.43]createEntity/createTemplate/createPortlet


            Mike,


            Per the tension you mentioned, and your previous e-mail with
      the
            "Container" interfaces (C1-C4).


            This is a question that Rich referred to as "Heterogeneous
      versus
            Homogeneous" services. The question is whether the "container"
            behavior should be an explicit part of the interface (as you
            suggested in C1-C4 = "heterogeneous") or can be implicit in the

            interface by providing different "services" (in the WSDL
      sense), each
            representing a separate portlet type (= "homogeneous").


            Why do you feel that WSRP needs the heterogeneous service?
      Couldn't a
            single container/server provide different services for
      different
            portlet types, and use WSDL techniques (mainly, URL paths) to
            differentiate between the different portlets?


            Eilon
                  -----Original Message-----
                  From: Michael Freedman [
      mailto:Michael.Freedman@oracle.com]
                  Sent: Thursday, May 23, 2002 5:51 PM
                  To: Gil Tayar
                  Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
                  Subject: Re: [wsrp][wsia][wsrp-wsia joint
      interfaces][Draft
                  Spec 0.43]createEntity/createTemplate/createPortlet


                  I don't think we want to give up so quickly on this.  As
      I
                  think all calls (after createEntity) need to be passed
      the
                  entity handle -- and would find each to be unnatural if
      we
                  defined they took an optional "bind" key.  Also, I don't
      think
                  entities are WSRP exclusive things.  Rather I think the
      tension
                  is WSRP needs (generic) container model while many
      components
                  will be happy running as standalone services.
      Personally, I
                  wonder if we will end up with two APIs -- one for service

                  simple and one for service container -- much like I
      depict in
                  the e-mail sent earlier describing different component
      types
                  needing to be modeled.  Though containing by and large
      the same
                  API the difference is the need for createEntity and
      passing the
                  return handle in all subsequent operations -- i.e.
      getFragment,
                  etc.





                  -Mike-





                  Gil Tayar wrote:
                         In the interest of sanity and progress, I have
      broken up
                        Rich's, Michael's, Monica's and Eilon's emails into
      four
                        subjects - "Shared Transient Information",
      "Persistent
                        Information Scope",
                        "createEntity/createTemplate/createPortlet",
      "session and
                        entity handles", and "Property lists". This email
      will
                        deal with
      createEntity/createTemplate/createPortlet, and
                        the relevant quotes from the emails and my reply to
      them:
                        Rich wrote:> Presuming the 2nd case to get dropped
                        relative to the previous set of
                        > emails, I would propose this section call out how
      we
                        will refer to these
                        > things throughout the remainder of the
      document/API. In
                        particular, I would
                        > suggest:
                        >       Session Information - This is carried
      opaquely in
                        the interface as a
                        >       "sessionID".
                        >       => goes away
                        >       Persistent Information - This is carried
      opaquely
                        in the interface as
                        >       a "handle".> > Rather than "Manifestation",
      I
                        would propose using "Entity" to describe the
                        > thing from which markup may be requested. I think
      it
                        has the right level of
                        > opacity (Consumer has no idea what kind of entity
      it
                        is) while carrying
                        > appropriate semantics (a thing that may be
      interacted
                        with). Using these
                        > terms, there was also an open question at the end
      of
                        our last call related
                        > to whether there were both persistent and
      transient
                        entities ... > > If we are going to support
      explicit
                        lifecycle for both of these, I would
                        > propose:
                        >    handle   createEntity(handle, propertyValues)
                        >    sessionID   createSession(handle,
      propertyValues)
                        Michael wrote:> 1) createEntity (aka
      createTemplate). In
                        WSRP we have discussed requiring
                        > consumers register with a producer to "activate"
      it.
                        Registration returns an
                        > 'activation' handle used in subsequent calls to
                        identify the consumer.  How can
                        > we account for this with the createEntity (and
      other)
                        APIs?  I really, really,
                        > really, don't want this to be an property value.
      Also
                        what is the actual
                        > intent of these property lists?  Gil implies they
      are
                        persistence presets.  If
                        > so should we have a separate list parameter that
      allow
                        the consumer to further
                        > qualify the Entity being created?  I.e. in WSRP
                        portlets aren't the direct
                        > producer -- they are managed/contained by the
      producer.
                        We will want to use
                        > the createEntity call to create/be tied to these
                        subtypes -- hence need someway
                        > to qualify it in the call.  Finally, are we
      assuming
                        the service never wants to
                        > programmatically authorize this operation?  If
      not,
                        don't we need to pass User
                        > identity and roles as well?> > 2) destroyEntity
      (aka
                        destroyTemplate).  Since we seem to want to support

                        > creating new entities from existing one's do we
      want to
                        support cascading
                        > delete?  If not we likely should support bulk
      deletes.
                        [Note: should we
                        > consider bulk create as well for
      import/export/publish
                        purposes?]  As with
                        > create entity the consumer ID should be
      passed.Eilon
                        wrote (and I condense...):[...]> 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.
      [...]>
                        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.So now Gil writes:It seems
      that
                        Michael, Eilon, and myself believe that the
                        createEntity/Template/Portlet operation is
      particular to
                        WSRP (Rich, I even remember adding the
      "templateKey"
                        thingie as a shot in the dark to where WSRP is
      going - it
                        seems the shot missed!).I suggest then, dropping
      this
                        from the joint interface subcommitee, and leaving
      it in
                        the hands of the WSRP. Having said that, we must be
      able
                        to support some type of connection between the
                        template/entity/portlet and the "session handle",
      so what
                        I propose is that the createSession/Instance
      operation
                        (outlined above) will accept an unspecified
      "bindingKey",
                        i.e.:sessionHandle/ID =
                        createSession/Instance(bindingKey).The "bindingKey"
      will
                        be an opaque string to be defined either by the
      WSIA
                        service, or defined by specs above WSIA (i.e.
      WSRP). One
                        can argue that this is similar to JDBC's
      "connection URL"
                        (in getConnection) which is an opaque string
      specified
                        when "connecting". WSRP could also use it to
      specify the
                        "sub-service/portlet" of the container, if WSRP
      decides
                        to go the heterogenous.My suggestion is to drop the

                        createEntity/Template/Portlet, and
      leave:sessionHandle =
                        createSession(bindingKey) [bindingKey is an
      opaqueString,
                        which will be used in the future by WSRP binding

      specifications]getMarkup/performAction....(sessionHandle,
                        ...) [i.e. all operations within the session will
      receive
                        the sessionHandle]destroySession(sessionHandle)And,
      as
                        Michael suggested, resolve timeout and implict
      session
                        creation and deletion issues ASAP.(I specifically
      dropped
                        the "propertyList" arguments as they are not the
      issue
                        here, but that doesn't mean that I don't support
      them).
                        Gil TayarWebCollage







      ----------------------------------------------------------------
      To subscribe or unsubscribe from this elist use the subscription
      manager: <http://lists.oasis-open.org/ob/adm.pl>








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


Powered by eList eXpress LLC