[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-wsia] Minutes for 06 March 2003 Meeting
Thanks Andre for putting together this proposal on how an operation could be defined to deal with this request for passing data to resources. It helped to crystalize why I have been feeling uneasy with this discussion. When we first began discussing resources (I think that was April-May 2002), we quickly separated them into two camps: 1. Simple resources (e.g. a gif). A portlet's markup is likely to want to reference such items as they often can not be incorporated inline. We decided to encourage these to be absolute URLs, but also added the proxying of resources to v1 in order to handle the case where the user agent is unable to access the resource directly. 2. Complex resources (eg. a jsp page). Inclusion of these types of resources is paramount to dynamically constructing the page layout under the portlet's control (i.e. the portlet is saying how to directly aggregate subcomponents into its portion of the page). While we did not want to rule out doing such aggregation, it was deferred out of v1 with the view that the portlet could always directly aggregate such resources itself before streaming the aggregated markup tothe Consumer. I think the discussion of how to pass various pieces of data to a resource definitely falls into #2. I understand the very fuzzy line between these two as the Portlet can always pass data to more complex resources via the URL (or possibly cookies), but am concerned that we can not reasonable work through the issues and architect this whole area without delaying v1. I think our earlier decision was right and therefore would prefer the entire discussion move into a 1.1 timeframe. Rich Thompson Andre Kramer <andre.kramer@eu.citrix.com> 03/07/2003 10:03 AM To: WSRP <wsrp-wsia@lists.oasis-open.org> cc: Subject: RE: [wsrp-wsia] Minutes for 06 March 2003 Meeting On yesterdays call I took the action to draft a strawman proposal for how resources can be accessed within a producer / consumer context without re-inventing a HTTP encoding of our protocol. As Eilon previously suggested with much foresight, this introduces a new candidate operation in our markup interface and suggests a new url type. I wanted to get a strawman out before the weekend, so that people can reflect on such an approach. Basically, the resource becomes "owned" by a (producer offered) portlet who supplies it's portlet description, so that most of our protocol machinery can be re-used. But firstly, the current resource URL type should not go away or change. It is very useful for light-weight static state-less REST (http://www.w3.org/TR/webarch/) resources that can be readily cached at the http level. We may even like to let resource http requests have cookies (though personally I think this is not required, if we accept this strawman and as the Web does not mandate cookies) or forward POSTs (again a consumer may want to not support this: I, as a consumer, don't want a producer to say POST some form from a script to "transfer money from my account" to some URL (the bank's and include my banking cookies). I know consumers will do access control (I hope :-) on resource URLs, but it still seems a dangerous feature. And what about honouring re-directs - that could keep a server busy?) Especially, I do not think we should make sure our session cookie is valid (initCookie and InvalidCookie fault requirements) for HTTP resource requests, or try to add our data (UserProfile etc) to Web requests, or even make sure this data can be referenced from HTTP requests. But I agree we do need to support this functionality, as a consumer (not the Web user agent client) should be able to interact with a resource that is a part of a larger producer side "Web Application". Functionality included here is structured form data (via attachments in future), established security context etc. This does not imply that the access need be direct to the (Web) resource, rather it should go via the same application access control and share its context with portlet requests, i.e. our SOAP super-layer. This may then forward the request to a J2EE Servlet, a ASP.NET Web Form, or even serve up the resource directly from the producer side Portlet/Web application/server context. One could argue that a Portlet (in getMarkup and perform(Non-Blocking)Interaction for POSTs) can already do this. The new operation simply allows the Producer container (apologies to those who have no such thing;- a library not a container is implied) to do it more automatically. I am going to propose to name the operation "getPortletResource" and the url type "portletResouce" (keeping "resource" urls as is and to help flag that this operation is in the portlet application scope. We can argue we have no such thing as application scope; I just mean groupID and other metadata), but strictly the new operation is derived from perform(NonBlocking)Interaction, so really should be called some thing like "performPortletResourceInteraction". The new url type (wsrp-urlType=portletResource) MUST carry the wsrp-url parameter (more a uri than a url here) and MAY include a wsrp-secureURL boolean (default is false). wsrp-fragmentID can be easily encoded on the wsrp-url and I would like to make resource re-writing dynamic, so no wsrp-rewriteResource for this url type. portletResource MUST also specify a wsrp-owningPortlet parameter (containing a portlet handle which should really be for a producer offered portlet) IF the call is to be in a http session or if a user context (profile data) is to be communicated. We may also like to add a wsrp-supplyUserContext boolean parameter (usual use case is true). For a portletResource url in a Portlet's markup we can let the current/"this" portlet be the wsrp-owningPortlet. We may even make this implicit. I think it's nicer to make it an explicit parameter for portletResource urls. Note, this does not change what follows the next paragraph. Also note that, for re-writing, the markup returned should not really contain any of the following wsrp-urlTypes: action, blockingAction and render. For complete re-writing of http resources the consumer must currently encode the portlet instance into the url returned to the client. That could be the wsrp-owningPortlet but, for now, we should encourage use of render urls in favour of portletResource urls, if the generated markup is portlet specific. For 2.0 & Events, we may want to allow arbitrary portles to be url targets in any markup. Finally (thanks for your patience with the above), we come to the operation description itself. The (possibly implicit) wsp-owningPortlet url parameter is used to make sure a http session is in place, by directing the consumer to look at the owningPortlet's portletDescription's groupID (if serviceDescription.requiresInitCookie is "perGroup"). This should not require a call to getPortletDescription if the owningPortlet is a producer offered portlet and the producer service description is cached. The consumer will want to also look at the portletDescription's markupTypes[], userCategories, userProfileItems, usesMethodGet meta data (no other fields are relevant here). [Having to ignore the MarkupType's windowStates and modes is a bit ugly.] The new section 6 markup operation: ResourceContext = getPortletResource(RegistrationContext, UserContext, ResourceParams, url); faults: Security.AccessDenied, Security.InvalidRegistration, Interface.MissingParameters, Interface.OperationFailed, Interface.InvalidUserCategory, Interface.InvalidCookie, Interface.UnsupportedLocale, Interface.UnsupportedMarkupType IN arguments for getPortletResource: RegistrationContext registrationContext: optional registration context. It is up to the consumer to guess the registration requirements and track any resulting scope. UserContext userContext: The consumer can not assume this is stored in a session and MUST supply a userContext if the url carried a (possibly implicit) wsrp-supplyUserContext==true parameter. [Only the userContextKey is actually Required.] The user profile is to be constructed using the normal portletDescription.userProfileItems rules. ResourceParams resourceParams (restiction of MarkupParams and RuntimeContext ) { [R] boolean secureClientCommunication; [R] ClientData clientData; [R] string userAuthentication; [O] NamedString formParameters[]; [O] UploadContext uploadContexts[]; [R] string locale[]; [R] string markupType[]; [O] string markupCharacterSet[]; [O] string namespacePrefix; // may not be used if return requiresUrlRewriting==true [O] string validateTag; [O] Extension extensions[]; } String url/uri: the wsrp-url parameter value. [could be in ResourceParameters but I wanted to call it out. Encodes interactionState]. RETURN(OUT) parameter: may be null (if ResourceParams.formParameters != null or uploadContexts != null) ResourceContext resourceContext (restriction of MarkupContext) { [O] boolean useCachedMarkup; // sort of an [R] as it has a default "false" [O] string markupType; // future: attachments could return multiple results [O] string markupString; [O] base64binary markupBinary; [O] string locale; [O] boolean requiresUrlRewriting; [O] CacheControl cacheControl; // here our defined caching semantics may even be useful! [O] Extension extensions[]; } [only blocking portlet interactions can do redirects & change nav state. Could be MarkupContext is we ignore the optional preferredTitle and don't add anything else.] Finally, note that this operation would be optional for producers as only they write portletResource URLs. regards, Andre ---------------------------------------------------------------- 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] | [List Home]