[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 Subbu for a detailed response. My response as KM--> below.
Khurram Mahmood
Product Manager - Portal Solutions
Off: (925) 694-9566
Cell: (408) 230-6784
"Subbu
Allamaraju" To: wsrp@lists.oasis-open.org
<subbu@bea.com> cc: (bcc: Khurram Mahmood/PeopleSoft)
Subject: Re: [wsrp] Re: Q about resource usage with http post
11/07/2004 08:49
AM
Khurram_Mahmood@peoplesoft.com wrote:
>
> 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.
I don't see the advantage of such a mixed mode as being the norm and not
an exception. I agree that WSRP does not solve this kind of mixed mode,
but that is because that was never the goal. Moreover, mixed has several
problems with state, sessions, security etc. Why not create a direct
link (not rewritten) to your producer-hosted app avoid the consumer. But
then, why need a portal/consumer at all?
KM--> My argument is that this kind of interaction needs to be natively
supported in the spec as most non-trivial applications will encounter this.
I can speak for many enterprise software vendors. As I wrote, this is
especially true for the highly interactive applications like CRM. We are
seeing a surge in the demand for high interactivity in all applications,
not just CRM. Traditional transaction-oriented systems are on their way
out.
Why need consumer/producer--> You need a producer/consumer model because
applications are not silod anymore - they themselves are composed of
portlets. They are increasingly composed of multiple different pieces from
different disparate apps. Visual integration presents a very quick and
easy integration scenario and we see that being a competetive advantage for
WSRP over other Webservice standards for a significant set of use cases. I
am not suggesting that other standards are not valid, of course not. I am
just saying that visual integration facilitated by WSRP is a very valid
scenario that will be increasingly used for quick, loosely coupled
integrations. For many use cases, you don't need much more than that
anyway. I also see WSRP being used outside of what we call portals today.
I see it being used as a standard presentation integration technology
within applications too (this raises a very interesting issue of consumer
chaining -- we'll discuss that later). My point is that such mixed modes
are not boundary cases, unless we resolve these in the spec, we will see
each vendor coming up with its own clugy workaround and thereby making it
less than optimal and even incompatible for other consumers.
Why not create a direct link....--> it is easier said than done. There are
producer session and state management and signon issues. Since the
producer session is being maintained by the consumer and is not necessarily
at the browser in a cookie, a direct link will result in an error and not a
smooth transition. There are really clugy workaround like setting cookies
in javascript but they suffer from numerous issues like the cookie domain
problems etc. If there was a way for a consumer to 'delegate control' of
an area to the producer in a well-defined manner and then for the producer
to relinquish control back to the consumer when it is done.... That's what
I am looking for. I do realize that it is a tall ask.
> 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
Consumer need not rewrite markup if the producer is capable of creating
correct links using templates. In fact, if and when adopt MIME
attachments at the transport, consumer can simply stream the markup.
> 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
In our testing, performBlickingInteraction becomes an overhead only with
large forms (tens of fields) and with file uploads. For these cases,
MIME attachments would be a better solution since the Consumer can
simply stream the incoming POST body to the Producer. But WSRP does not
support this yet.
KM--> I disagree. We have extreme performance requirements for our apps,
having a multi-phase, serialized retrieval is unacceptable in most cases.
I think one of the fundamental difference is our perspectives is that I am
looking at WSRP as 'the' standard for integrating all visual web services.
This goes way beyond what we traditionally call portlets. Essentially, all
application pages (PeopleSoft apps typically have dozens of thousands)
becomes portlets where each portlet itself is composed of many others.
Almost all of our component pages have many fields and thus large forms.
The real meat in wsrp, it's real value, it's calling in life is to be the
standard that guides all visual integration and seamlessly ties to the
other integration standards. Portals alone are not very interesting, they
are being commoditized anyway.
> 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'm not sure why the serial nature of pbia is a problem. Can you elaborate?
KM--> performance, performance, performance.....
> -----------------------------
> 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
>
> .
>
>
>
>
>
>
> 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]