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

[Rich Thompson <richt2@us.ibm.com>]

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>