[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Re: Q about resource usage with http post
Thanks Rich.
1. I will need to look at Andre's feature proposal to be able to
understand your comment.
2. The issue really is that for highly interactive applications, we need
someway for the consumer to act as a proxy but then somehow pass the
producer the control if needed as such. Consider the following business
scenario as an example.
a. A call center agent, let's call him Rich, logins to a CRM Customer
Support Portal. The portal displays the user a page with the following 4
portlets (a hypothetical example)
i. My Last 10 Open Cases
ii. Open Cases from Platinum Customers
iii. Escalations (if any)
iv. Calendar
The consuming portal essentially contacted the content provider CRM
system(s) through WSRP and assembled the information by doing a getMarkup
Operation on all of the portlets.
b. Rich drills down on one of the cases from the list of 10 open cases.
He does this by clicking on the link. The consuming portal acts as a proxy
and calls performBlockingInteraction. The portlet in question maximizes
its view and we see a page with the case detail for the case in question.
c. Now Rich decides to update the case:
(i) he updates the status --> an event fires that takes a server trip
through the consumer.
(ii) he updates the resolution --> another event fires.... another
server trip through the consumer.
(iii) he adds a few people to the notification list --> for each one
of them, an event fires that looks up the individual and updates the list.
All trip proxied through the portal.
(iv) clicks on the notification button to notify the interested
parties --> another event again through the consumer
Note that i through iv are all performBlockingInteractions that if
done according to the spec would result in the whole page being
re-retrieved and re-assembled.
Note that all a, b and c above need state information and thus by your
definition have to be proxied.
Consumer acts as a mandatory proxy for every request in the above use case.
As a result, we see significant and in some cases prohibitively significant
performance degradations. This is further aggravated if the consumer is
striclty following the spec and actually re-retrieving (getMarkup) and
re-assembling all the other portlets on the page. In my personal tests
using just http gets and posts with a portal as the proxy (i.e. even
without the overhead of SOAP over HTTP or the blockingInteraction calls), I
have seen the degradation to be around 70-90% for the complete business
scenario like the one outlined above. This was when all the portlets other
than the one being interacted with were cached on the portal server. If
you don't take caching into account as it is but optional, this figure
would shoot up even more.
How can I go to my CRM team and try to sell them WSRP. CRM products
compete very aggressively on how much time it takes for an agent to
open/close a case or change its status etc.. You can add more CPUs, more
memory but its those extra hops due to consumer proxy that you have to jump
over the network that kill performance. Not to mention the serial nature
of performBlockingInteraction call.
-----------------------------
I see this alongwith registry federation, federated identity mangement and
authorization as the three major issues that we must resolve either as part
of this specor other ones to make plug n' play reality. At PeopleSoft, we
have been tacking these issues eversince we pioneered into the pure HTML
era. We have a few ideas on how to resolve this.
All of us in the WSRP committee need to make these issues our top
priorities. I see this as being much more important than the less-core and
more value-add features like interportlet communication. (On a lighter
note) To start with, we have to stop taking the ubiquitous but entirely
useless "Stock Portlet" as a use case. It is by far the most unrealistic
and yet most frequently cited portlet by most portals that I come across.
Other culprits are the weather portlet, Calendar, e-mail, clock and
ofcourse the Dilbert portlet :-) Let's start analysing how WSRP can work
within the context of critical business applications.
Thanks,
Khurram Mahmood
Product Manager - Portal Solutions
"Rich Thompson"
<richt2@us.ibm.co To: wsrp@lists.oasis-open.org
m> cc: (bcc: Khurram Mahmood/PeopleSoft)
Subject: Re: [wsrp] Re: Q about resource usage with http post
09/27/2004 07:03
AM
Thanks, this helped a lot ... my suggestions:
1. Resources are the matching concept as they are items directly requested
by the browser for insertion into the overall page. Andre, I think this use
case should be added to the related feature proposal you own and a number
of requirements extracted from it.
2. The spec should clearly do a better job at calling out when a resource
should be directly requested rather than Consumer-proxied. Times when a
proxied request are needed include when the network configuration precludes
direct access and times when the resource request needs stateful
information that is likely to only be known by the Consumer. The generation
of markup fragments for placement on the page certainly falls into the
later case.
3. Resource requests need to be able to carry state information and
request-specific information. The get/post issues need clarification and
the semantics around any getPortletResource operation need to take these
needs into account.
Rich
Khurram_Mahmood@peoplesoft
.com
To
09/24/2004 01:49 PM lars_hofhansl@peoplesoft.com
cc
Rich Thompson/Watson/IBM@IBMUS,
wsrp@lists.oasis-open.org
Subject
Re: [wsrp] Re: Q about resource usage
with http post
I would like to emphasize the problem that Lars has described in detail
below.
In transaction-oriented highly interactive systems, such background
interaction where only optimized pieces of the page are being refreshed
instead of the whole page is increasingly becoming the rule instead of an
exception. One may argue that the combination of HTTP+HTML was not
designed to support such interaction but that's a moot point as we have to
live within these limitation until rich clients bring back a smarter
version of client-server.
In the past few months, I have had discussions with quite a few content
providers around the technical aspects of WSRP. More than a few have
described it as a standard that is not fully baked out or is out of touch
with reality. If you probe a little further one of the complaints that
surfaces almost immediately has to do with the technical limitations that
WSRP puts on highly frequent user interaction. Complaints ranging from
mandating the consumer as the ubiquitous proxy essentially slowing down
every single request to the implicit assumption that refreshing the whole
page with every request would be acceptable to users in the real world.
For example, in this case we will have to be forced to use the resource
template and go directly to the content server whenever partial page
refresh is involved. We don't want to do that and it is not an optimal
design but the limitations of the spec will force us in this direction.
Otherwise we don't support WSRP at all but that will not provide value to
our customers and also significantly weaken the standard.
It's time that the 2.0 version and subsequent specs focuss on the
interactive systems and take requirements from them. We should try to
accomodate those requirements in 2.0 and subsequent specs even if it means
breaking the theoretically pleasing aspects of the spec. The bottom line
is that the spec is useless until and unless content providers support it.
We already have all the leading portal vendors supporting WSRP consumption
but little non-trivial activity on production. What will make this
standard viable and popular is the rapid increase in the number of content
providers supporting it for production. Issues like the one that Lars has
stated in his mail below present a significant road-block for achieving
that vision.
PeopleSoft is a leading provider of highly interactive enterprise
applications. We will continue to work with the WSRP committee to make it
into a more feasible standard for us and for other content providers who
are facing problems that are similar to us. In my opinion, to enable wide
adoption of this spec among producers, we will need a shift in the way we
approach it -- a shift away from a portal vendor perspective to a
interactive content provider's perspective. Without such a shift, we
might end up with thousands of earnest consumers with nothing to consume.
Thanks,
Khurram
lars_hofhansl@peo
plesoft.com To: richt2@us.ibm.com
cc:
wsrp@lists.oasis-open.org, (bcc: Khurram Mahmood/PeopleSoft)
09/24/2004 10:03 Subject: Re: [wsrp] Re: Q
about resource usage with http post
AM
We have potentially a lot of information to send; more than the maximum
size of a URL (which is also browser dependent). We could chunk the
information, send multiple GET requests and re-assemble the fragments on
the server, but I'd rather perform a simple POST.
There are also security issues. POSTed information is automatically secure
when using SSL, for GET encoded data we'd have to do our own encryption
(for example if access logging is enabled on the server where the resource
is served from).
-- Lars
"Rich Thompson"
<richt2@us.ibm.co To:
wsrp@lists.oasis-open.org
m> cc: (bcc: Lars
Hofhansl/PeopleSoft)
Subject: Re: [wsrp] Re: Q
about resource usage with http post
09/23/2004 12:20
PM
As I read your first paragraph, I also went to using the concept of
resources as the right way to accomplish what you need (i.e. the updated
fragment is a resource from the Consumer's point of view). Is there a
particular reason the information you want to transfer has to be via http
post rather than get? This sounds a lot like some of the things I did in a
previous research project, but we used http get for all the transfers.
Rich
lars_hofhansl@peoplesoft.com
09/23/2004 02:35 PM To
wsrp@lists.oasis-open.org
cc
Subject
[wsrp] Re: Q about resource usage
with http post
In our case we are implementing a mechanims for "selective page refresh"
using DHTML. I.e. we have to completely bypass the Portlet Interaction
model. There seems to be no specific provision for this in the WSRP Spec
(V1). For example performBlockingAction() either has to return the complete
markup or it has to be followed by getMarkup(), we can't just return some
change information and partially update a portlet. (I realize that when
multiple portlets are displayed by a Consumer and one of the portlets needs
to be re-rendered that the Consumer may re-render all portlet, which breaks
our selective refresh paradigm for that case.)
For these reasons we're trying to POST to resourceURL in order to handle
our data exchange, then update the representation using DHTML based on the
exchanged information without triggering any (Consumer visible) refreshes
in the Consumer.
Now, the V1 WSRP spec in 10.2.1.1.3.1 says that the cosumer is "encouraged
to use the same communication style (e.g. HTTP Get or POST)" that was used
by the user-agent. That does not seem to mandate that behavior and thus we
cannot assume that all Consumers will indeed behave that way.
Thanks.
-- Lars
Rich Thompson wrote:
I don't know of cases where people have used http post in this manner, but
the spec anticipates that such cases may exist and allows the markup to
specify use of post with the requirement that the Consumer then also use
post when passing the request on to the resource url. This keeps the
Consumer truly acting as a proxy for these resources.
Rich
ricky_frost@peoplesoft.com
09/21/2004 05:36 PM To
wsrp@lists.oasis-open.org
cc
Subject
[wsrp] Q about resource usage
with http post
Is HTTP post supported for resource operations according to the spec? My
reading of it points to an ambiguous statement to that effect on pg 62,
section 10.2.1.1.3.1
Thanks
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]