Re: [wsrp-wsia] Issues agenda for 9/26

[Michael Freedman <Michael.Freedman@oracle.com>]

My take on Thursday issues:

1. Leasing.  I will vote to keep this out of 1.0.  For me this is a potentially
nice feature but isn't necessary to build a complete, performant protocol for
writing portlet to work with our portal.  Put another way, I would expect at
most a small percentage of producers to utilize this.  My philosophy at the
moment is to strip the protocol down to satisfy the 80-90% case cleanly and in
a way that will allow highly efficient implementations.  As we are still
struggling to define the later we shouldn't be spending energy adding/defining
the former.

2. Renaming to refHandleExpires.  I propose we add a second alternative to be
voted on.  This alternative defines a structure RefHandleContext with two
fields: handle and expires.  The argument for this proposal [defining an
explicit Context]  is its consistent with how we have handled other situations
where there is other information to be returned related to a particular
handle.  Once a context is used the confusion on what the expires field
pertains to should be mitigated.  If there is still concern over the names of
these fields, the more complete/descriptive names can also be considered.

3. Should only POEs be published?  Unfortunately, I am still
investigating/learning the details of UDDI usage so I will have to vote to
defer this until I can understand more fully.  I certainly have no objections
to Producer published services particularly as we have defined it for self
discovery.  I am still trying to figure out if POE published via UDDI makes
sense.  A question I have in this regards from the limited investigation I have
done relates to initEnvironment().  If POEs are published to UDDI and not the
producer what is the semantics/requirements to the consumer with respect to
initEnvironment().  As each entity is published as a different business service
how do I know which entities are from the same producer?  Matching tModels and
accessPoints, though maybe a possibility, seems clumsy and could be easily
misused.  I think I would find this a much more serious hole then the entityId
sessionId = refHandle problem we discussed at the F2F.  The second
question/concern I have with POEs is how is producer global meta data handled?
The spec currently works hard at only having POE meta data but is this really
appropriate/realistic?  For example, now that we have initEnvironment() in the
core interface I suspect we will need a requiresInitEnvironment piece of meta
data on the producer so consumers can determine whether its needed/used.
Another example relates to question 4 -- i.e. if we define meta data in the
future that describes (sub)grouping, how can this be conveyed in the POE
exclusive metadata model? Finally, its not so clear that roles should be
defined at the entity level.  Should an administrator have to map roles N times
one per POE she chooses to incorporate into the portal?  I think the JSR offers
a better solution by making this producer/application wide.

4. GroupIds:  For me, groupIds "direct" how shared session are to be grouped.
For v1 the only form of grouping we should define corresponds to the
client/user session in the portal.  I.e. the protocol defines that the only
meaningful interoperable understanding of groupId is that all portlets from a
given producer that a user interacts are grouped using the same ID.  Portlets
designed to be interoperable can only code to this semantic.  I.e. they must
assume that two instances of that same portlet are running in the same
session.  Portal vendors are allowed to provide more fine grained grouping --
i.e. a particular set of portlets on a page within a given user session.  This
can even be done by defining producer extended meta-data.  However, utilizing
groupID in this manner would be considered a vendor specific extension.
Producers would have to code accordingly.  In future versions of the spec we
may define producer meta-data to describe more fine-grained groupings.

5. Should we have an isRefresh?  I think not.  The problem that is trying to be
solved is one that allows a portlet to encode a render URL with both action
parameters and navigational state.  In this manner when the user subsequently
clicks on this link the render is called and is processed as a "non-blocking"
action.  The requirement/problem is to ensure that when a user subsequently
begins interacting with other portlets on the page that the portlet that
handled the non-blocking action can is called in such a way so it merely
renders (and doesn't perform the action).  I don't believe this should be
handled by an isRefresh flag.  Rather I think that portals/consumers should be
required to distinguish between the action parameters and navigational state
parameters in a given render URL. Once we require this, its a simple step to
require the consumer to only retain/encode the navigational state portion of
the render URL.  Hence in the scenario above when the user clicks on the render
link within the portlet it receives both the action and navigational state
parameters.  However, following this if the user interacts within other
portlets, the original portlet merely receives its navigational state.  Having
just briefly glanced at the spec again, I think supporting this may just mean
defining a new token in the producer/consumer write URL case for holding the
action parameters and defining that any parameters passed on a request that
weren't explicitly defined to be part of the navigational state are assumed to
be action parameters.

    -Mike-




Rich Thompson wrote:

> Sorry for the delay in getting this out, just incorporated the comments
> from those who raised the new issues queued for discussion.
>
> Issues scheduled on the 9/19 for a vote on the 26th:
> 1. (#16) Adding "lease" concept for registration
>  - Vote will be on whether to defer consideration of this concept out of
> the v1.0 version.
>
> 2. (#44) Rename "expires" to "sessionExpires" in ResponseContext
>  - Vote will be on whether to rename this field "refHandleExpires". This
> rename would closely alignment this field with the newRefHandle that it
> refers to.
>
> Issues where we will be opening the discussion:
>
> 3. (#58) Should only POEs be published? Only Producer service? Both?
>   - Abstract:
> In the current draft spec we envision that a service description can be
> access via the self-description interface or via a third-party registry,
> e.g. the UDDI registry.
>
> case 1: the self-description interface is used
> 1.1 the consumer locates the address of the service's WSDL file
> 1.1.1 the user enters the address manually
> 1.1.2 the consumer uses a registry to find the WSDL file
> 1.2 the consumer finds the access point from the WSDL and then calls
> getDescription to find out about the service's metadata and contained POEs
>
> consequence: the use of a registry is limited to finding the WSDL of the
> service, information of POEs will not be present in the registry. Search
> mechanisms provided by the registry that are based on category or
> functionality (e.g. tModels) cannot be applied to finding POE, the consumer
> has to invent its own search mechanism for filtering the result of
> getDescription.
>
> case 2: UDDI is used to locate POEs
> 1.1. the consumer uses the registry to search directly for POEs (see 0.5
> spec for details). Calls to getDescription are not required, all metadata
> and interface information has been published to UDDI
>
> consequence: the full search capabilities of the registry can be reused
> disadvantage: conceptually a POE is not a service itself. This might lead
> to confusion
>
> Proposed Solution:
> Cover both cases in the spec
>
> 4. (#6) Metadata needed to support shared Producer session.
>  - If Consumers are to "direct" how shared sessions are to be grouped, then
> significant additional information about what entities share what data will
> be neccessary. Key question: Does the Consumer "direct" how shared sessions
> are grouped or just provide a hint to the Producer? If we choose the
> former, can the issues of fully directing this sharing be deferred beyond
> the scope of v1.0?
>
> 5. (#26) Would an isRefresh flag be valuable for Producers supporting
> servlet/JSP entities?
>    -Abstract:
> It would allow a portlet to differentiate, within the getMarkup call,
> between a request targeted to the portlet and from a request that is a
> refresh (targeted to another portlet).
>
> This flag is particularly useful for portlets that do not use
> performInteraction, it will help the portlet to handle the replay
> problem. Many existing technologies (Servlets, JSPs, CGIs, etc.) have a
> single entry point for their request handling. These technologies can
> not leverage the WSRP two phase request handling. They commonly avoid
> the replay problem by using redirections, but this is not possible from
> within a getMarkup call. The isRefresh flag will help identity a refresh
> request from a real request and handle the replay problem.
>
> One of JSR168 goals is to leverage and enable the use of these
> technologies from portlets. The JSR168 portlet API, as part of the
> PortletRequest interface provides a isRefresh() method. Currently that
> information is not present in the WSRP protocol.
>
> Navigational state can not be used for this purpose because it does not
> change on refresh requests (that is its purpose).
>
> Session state could be use for this but it would be error prone when
> there a client request fails/aborts half way through (i.e:
> performInteraction succeeds and getMarkup does not get called, the next
> getMarkup will find the bit in the session). Also it would require the
> producer to have a session to keep this state.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>