[wsrp-wsia] Agenda for WSRP TC Call 9/26 8AM PST / 11 am EST / 5 pm CET

[Thomas Schaeck <SCHAECK@de.ibm.com>]

Dear WSRP and WSIA TC Members,

here is the Agenda for the next call, Thursday 26th, 8 AM PST / 11 AM EST /
5 PM CET:


Election of new Secretary
-------------------------

We need a new secretary starting in next week's WSRP TC call.


Resolve these Issues
---------------------

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.


Callin info:
 TIME:         08:00 AM PACIFIC TIME (11:00 Eastern)
 DURATION:     2 hours
 USA Toll Free Number: 877-302-8255
 USA Toll Number: +1 303-928-2609
 PASSCODE: 8814427

Best regards,

Thomas

Thomas Schaeck
Chairman OASIS WSRP TC