OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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 Spec0.43]createEntity/createTemplate/createPortlet

As an aside to this discussion, could people please delete the individuals
when repling to these emails. Since we all subscribe to the mailing
list(s), it just makes for yet one more copy of each email in the inbox.

The suggestion I had made relative to "Heterogeneous vs Homogeneous"
services was to exploit the power of URL pattern matching that AppServers
supply to reduce these issues to the container always getting the network
invocations, but then using the remaining path information to disambiguate
which hosted object the invocation should be routed to (along wth whatever
other processing was appropriate). While this is clearly doable in a
servlet environment, the 2 other dominate environments that would need to
enable this are Axis (basis of many Java web service stacks) and .Net. I
have explored the Axis environment and can report that this pattern
matching is not available, but rather the match (after the AppServer match
to the Axis servlet pattern) is directly to the name of the deployed
service. As such, here is a suggestion starting with the issue needing to
be addressed through how things could get created in an explicit manner.

   There are scenarios (Portal sharing the portlets it hosts is one) where
   the useful service to deploy is effectively a container for the
   'thingys' that a Consumer may request output from. The degenerate case
   is when there is exactly one 'thingy' at this service endpoint and
   therefore there is no container.

Much of the discussion (in particular the wsxl & iws contributions) are
focussed on this degenerate case as the perspective was that WSDL service
endpoints would be used to disambiguate between the 'thingys' regardless of
whether they were locally deployed in some container or not. I think WSRP
has brought in several scenarios that are quite difficult to manage unless
one explicitly introduces a container-level concept into the architecture.

   1. Once there are multiple types of thingys available at a service
   endpoint, the ability to distinguish between them is critical. I would
   propose calling each thingy a "transient entity". It represents the
   thing that will generate output and process actions according to its
   internal application logic. In general this is a stateful thingy such
   that all calls to getOutput while it is in a particular state will
   return the same markup while any change in state may result in a change
   in the generated markup.
   2. It is useful to support persisting a transient entity such that the
   persistable subset of the current state may be reused when creating
   transient entities in the future. I suggest calling this a "persistent
   3. While 1&2 are Producer oriented, there is also value to transient
   data that is most cleanly associated with the User. I propose calling
   this a "session". I think it is important that the spec scope these to
   the WSDL service endpoint, though we should include simple features (if
   possible) that would allow a Consumer to mediate larger scopes. This
   would allow a container oriented service endpoint great flexibility in
   how sessions are shared by the entities it hosts.

If we have all 3 of these, the next question is what are the relationships
between them:
   Sessions -> Entities:
      A common usage will be that a session is directly related to exactly
      one transient entity which may in turn be directly related to exactly
      one persistent entity. This breaks down for sessions shared by
      multiple entities at the service endpoint as there is now a 1:N
      relationship. This leads me to propose carring the session reference
      separate from any entity reference in the interface.

   Entities -> Entities
      For me this breaks down into 2 questions:
      1. Is a transient entity required to get output from a Producer?
      Deciding yes may simplify Consumer coding (either implicit or
      explicit lifecycle of a transient entity will always be involved),
      but may be an arbitrary requirement on the Producer.

      2. Are all 4 possible relationships interesting?
         a. Persistent from Transient: This seems like a fundamental way to
         persist state.
         b. Persistent from Persistent: This would allow creating a new
         persistent entity by sending deltas from an existing one. The
         relationship between the entities could be either by reference
         (long-lived) or by value (effectively a clone +delta operation).
         Are both interesting? Would the Consumer be able to either read or
         control betweenthem?
         c. Transient from Persistent: This seems like the means to use
         persistent state as a starting point for a set of interactions
         that might be quite independent of the persistent state once
         d. Transient from Transient: Like case b, this is a copy though I
         would think the by reference value is dramtically reduced when
         dealing with transient entities.

The other issue this design raises is how to carry the disambiguation of
the entities available at the service endpoint. I would prefer to see this
as an explicit parameter in the interface.

Given the above, the minimum create oriented calls would appear to be (we
would still need to discuss whether other parameters are required):
   entityHandle createEntity(bPersistent, entityHandle, entityType,
      bPersistent - a boolean to indicate whether this is a persistent or
      transient entity
      entityHandle - reference to an entity to use as a base
      entityType - if no handle is supplied, this identifies the base thing
      the service endpoint should use
      updateValues - opportunity to provide a delta to any values implied
      by the handle/type parameters.

   sessionID createSession(entityHandle, updateValues)
      entityHandle - entity this session is related to (should this be a
      updateValues - opportunity to set values for use within the session

Sorry about the length of this (& the raising of multiple issues in one
email), but I'm just trying to propose an alternative given that the URL
pattern matching when exposing independent service points for a Producer
deployed hierachy isn't going to work on todays infrastructure.

                      Eilon Reshef                                                                                   
                      <eilon.reshef@webc        To:       "'Michael Freedman'" <Michael.Freedman@oracle.com>, "'Gil  
                      ollage.com>                Tayar'" <Gil.Tayar@webcollage.com>                                  
                                                cc:       wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org       
                      05/23/2002 06:35          Subject:  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec    
                      PM                         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?

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

      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

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

Powered by eList eXpress LLC