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

[Eilon Reshef <eilon.reshef@webcollage.com>]

Mike,

Your point #3 (POEs and UDDI) relates to the decoupling idea that's
inherent in the Web services stack, that is: the behavior of an
application that uses remote Web services only depends on the set of
functions enabled by the Web service, but is independent of the access
method: location, protocol, etc. That is, in an ideal world, a service
can move location, etc., while the only thing the service user needs to
do is to reload the WSDL (or whatever).

The more semantics we put in a global producer, the more we deviate from
this model. Put differently, if a business entity publishes two services
(a weather service and a stock service, to use very
business-value-oriented examples), their behavior should be unchanged
based on their deployment environment (e.g., one machine, two machines,
one URL, two URLs). This means that if POEs that belong to the same
Producer behave radically different than two POEs that belong to two
Producers, then if a POE is moved from one cluster to another cluster
(for deployment reasons), users of the service (that is: portals that
use the POEs) may break due to incorrect assumptions about the
relationship. This is somewhat troubling.

One may address global services such as initEnvironment in multiple
different ways, e.g., an attribute of each POE that specifies the id (or
the URL) of the "Producer". If two POEs share the same URL (which can be
completely meaningless), then they fall into the same "bucket". Etc.

My point is at a conceptual level: one of the reasons why WSRP is needed
is to support a distributed environment (which inherently has more
challenges than a local environment). Such an environment inherently
evolves. The more assumptions we make about centralization of the
environment (e.g., multiple POEs are inherently part of a global scope),
the more we run into deployment issues that relate either to inability
to distribute services or to fragility due to changes in a deployment
environment.

Cheers,
Eilon

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com] 
Sent: Tuesday, September 24, 2002 9:55 PM
Cc: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Issues agenda for 9/26


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>


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