OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


For case (3), I was thinking about decomposing WSRP services so that they could be refactored.  As an example, imagine an e-mail inbox portlet and a contacts portlet.  The e-mail portlet has a "new" link to compose a new mail, and the contacts link has a "compose e-mail for this person" link next to each contact's info.  I think it would be cool if the new mail component could be factored out into a different WSRP service, and each portlet could link to it.

As for your last question, yes, that is essentially what I meant.  Actually, I mistyped when I wrote the original and I meant that the producer would give back something more like "<a href="wsrp://server/blah">" instead of "<a href="wsrp:blah">", but that's a small issue.  (I recognize, by the way, that there are some tremendous problems with defining a new URI scheme for WSRP, and based on the small amount of thinking I've done I think it is probably a bad idea.  One problem, for example, is that it is difficult to specify that a wsrp service could be used over multiple transits -- would you say "wsrp://http://server/portlet"; and "wsrp://smtp:portlet@server"?)

As for the rest of the cases, I understand that they all CAN be done (and I think your mail has good outlines for how to do them), but I'm concerned about whether they SHOULD be done with traditional linking mechanisms.  I'm especially concerned about the notion that, as Jeff points out, we will be mucking around with the well known semantics of links.  It seems to me confusing for developers and dangerous for compatibility, and I would kind of hope that the mechanics of how to link to SOAP services would be handled by a group with broader reach than us.  Does anyone know of a group that is working on standardizing URIs for SOAP services?

One thing I wasn't clear about in your mail: you seem to make a distinction in #4 between links and "actions" encoded in the markup.  I had always assumed these were synonymous; can you describe your vision of what the difference is (other than the fact that actions become arguments to the web service)?


-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Friday, May 31, 2002 5:08 AM
To: Sasha Aickin
Cc: WSRP (E-mail)
Subject: Re: [wsrp] Links in a WSRP service: what do they mean?

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 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>
Subject:    [wsrp] Links in a WSRP service: what do they mean?


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
 This is useful if you want to delegate part of a WSRP service to another

(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?


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC