Re: [wsrp] Links in a WSRP service: what do they mean?

[Thomas Schaeck <SCHAECK@de.ibm.com>]

Hi Sasha,

very good point, I think this is something that needs to be covered in some
detail in the spec.

Some thoughts ...

(1) can be done if the producer does not mark the URI for URL rewriting by
the portal - in this case the link would go into the makup displayed in the
browser and therefore the browser just follows the link.

Protocols involved:

Client <--- HTTP --->  Consumer <--- SOAP ---> Producer (Markup with links
to resources)
Client <------------  HTTP ------------------> Producer (Resources -
Images, Sounds, Video, ...)

I.e. the normal markup is retrieved inline in the WSRP over SOAP
communication, the big resources are accessed directly via HTTP. This is
just like if you have an application server running servlets for generating
a dynamic web site and an HTTP server that serves up images, animations,
sounds and short videos.

(2) can be done if the producer marks a resource URI for URL
rewriting/proxying by the portal so that at the portal, the portal base URL
is put in front of the URI of the actual resource. When the browser follows
the link to get a resource, it sends a request to the portal proxy
mechanism, that in turn sends an HTTP request to get the resource and
retuens it to the client.

Client <--- HTTP --->  Consumer <--- SOAP ---> Producer (Markup with links
to resources)
Client <--- HTTP --->  Consumer <--- HTTP ---> Producer (Resources -
Images, Sounds, Video, ...)

(3) I am not sure how exactly that scenario would work - can you elaborate
?

(4) This is what the action mechanism with URL rewriting is intended for: A
producer may embedd action references into the markup it generates - the
consumer identifies them based on some mark and replaces them with links
prefixes with the portal base URL in the final markup that goes to the
browser. If the user clicks on such a link, the browser sends a request to
the portal / consumer, the portal maps it to the right action and makes a
performAction call to the service.

Client <--- HTTP --->  Consumer <--- SOAP ---> Producer (Markup with
embedded actions)
Client <--- HTTP --->  Consumer <--- SOAP ---> Producer (Action)

(1) and (4) were demonstrated in the little demo we showed at the first
face to face (the service for viewing documents used actions as well as
links to dynamically generated images, the setup was so that the browser
could access the images via HTTP directly)

I assume you mean

<a href="wsrp:blah"></a>

would be in the markup sent from the producer to the consumer (in this
example portalxyz.com) and then replaced by the consumer by something like

<a href="http://www.portalxyz.com/..../(wsrp:blah)"></a>

in the merkup that actually is sent to the browser, right ?

Best regards,

Thomas

Thomas Schaeck
Architect, WebSphere Portal Server
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479   Mobile: +49-(0)171-6928407   e-mail:
schaeck@de.ibm.com   Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany


Sasha Aickin <AlexanderA@plumtree.com> on 05/30/2002 11:02:26 PM

Please respond to Sasha Aickin <AlexanderA@plumtree.com>

To:    "WSRP (E-mail)" <wsrp@lists.oasis-open.org>
cc:
Subject:    [wsrp] Links in a WSRP service: what do they mean?



Folks,

I brought up a question yesterday in the markup subgroup call that I would
like to address to the whole group.  Basically, I think we need to have a
clear idea what it means to have a link in a markup fragment returned by a
WSRP service.

Let's say we have some WSRP service A which returns an (X)HTML markup
fragment that contains the text "<a href
='http://someserver/resource.htm'>link</a>".  What should clicking this
link do?  I see four possibilities:

(1)  link a user to http://someserver/resource.htm over straight,
 traditional HTTP without any proxying by the portal.
 This seems like a good idea if the linked resource is a large static file
 like an image.

(2)  link a user to http://someserver/resource.htm over straight,
 traditional HTTP with proxying by the portal.
 In this scenario, the portal would proxy the request to the resource, but
 it would not create a SOAP request.  This would be a good idea for large
 static files like images in situations where network connectivity does not
 allow the end user and the portlet server to talk directly.

(3)  link to WSRP service B at the URI http://someserver/resource.htm using
 SOAP
 This is useful if you want to delegate part of a WSRP service to another
 "sub-service".

(4)  link to the same WSRP service A at the same URI using SOAP but pass in
 an argument of the form "linkClicked=http://someserver/resource.htm";
 This is useful if you want to stay in the same service and mimic URI links
 at the same time.

I think there are use cases for all four of these possibilities, and I
think that they all make some sense.  However, I think that 3 & 4 are
definitely not what links are supposed to be used for in (X)HTML, WML, &
VXML, and I'm troubled by the idea that we might rewrite the semantics of
markup tags with well established meanings.  I would propose that we define
different linking mechanisms for cases (3) & (4) above through a different
markup tag (e.g. <wsrplink>), through a new URI scheme (e.g. <a href
="wsrp:blah"></a>), or through some other means.

Part of the problem here is that different resources returned by a single
WSRP service (e.g. a portlet page, a detail view, a help page, an image)
don't have actual different URIs, and so it is difficult to refer to them
in hyperlinks in a way that is consistent with prior standards.  I think
this is a major problem with the SOAP architecture we've chosen, and we
should think about what workarounds there are to solve it.  Any ideas?

Cheers,
Sasha.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>