RE: [wsrp-wsia] Minutes for 06 March 2003 Meeting

[Andre Kramer <andre.kramer@eu.citrix.com>]

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>