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