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

-----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

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.

-------
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'" |

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

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

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.

      -----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

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.

            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>

wsia message