[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC