[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] Issues agenda for 9/26
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.
Powered by eList eXpress LLC