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



Eilon -

1. A syntax like http://foo.com/wsrp?s=weather would at least be more
promising like the former approach. However this relies on the ability to
access request parameters from within a SOAP handler. Unless you override
the SOAP handler this will not be possible as normally your SOAP
environment directly maps the incoming request to a method call in your
prefered programming language. For the method, the calling context is
totally transparent. In SOAP4J and AXIS you could write yourself a hack for
this problem, but in my opinion we should not build our interface and
protocol specification on such assumptions. Furthermore I don't know an
easy way in .NET to do the same thing.
2. We should try to design our data structures, method signatures and WSDL
files such that today's standard tools are able to generate automatic
proxies and stubs (e.g. WSAD and Visual Studio .NET). This will not be easy
and maybe in the end there will be the need of some custom mappings. But I
think that we should not enforce users to hack themselves into their
product's SOAP stack to implement WSRP services. If a portal vendor does
this for efficiency reasons, that's ok, but it should not be required.
3. The approach to put some parameters together in one data entity sounds
good. I would even go a step further and try to make as much information
implicit as possible:
- e.g. the portlet instance implies the portal ID  because it has already
been created in a registration context
- the same is true for instance and type


There is another reason why explicitly addessing portlets in the portal
service might be preferable to using the URL to address them and that is
batch processing. For tasks like staging or deserialization of portals you
can assume that a large number of remote portlet thingies might need to be
generated "simulaneously" from the same consumer on the same producer.
Instead of requiring N request for this we could allow vectors of
information to be passed to the different WSRP methods and such
significantly reduce roundtrips. We should at least do this for the
deletion of handles but why not for their creation as well.

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/28/2002 06:04  |
|         |           AM                |
|         |           Please respond to |
|         |           "Eilon Reshef"    |
|         |                             |
|---------+----------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       Carsten Leue/Germany/IBM@IBMDE                                                                                              |
  |       cc:       "'Alan Kropp'" <akropp@epicentric.com>, "'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                     |
  |                                                                                                                                             |
  |                                                                                                                                             |
  >---------------------------------------------------------------------------------------------------------------------------------------------|



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