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

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

Hi Sasha,

regarding the difference between actions and links I'd say that a link
references a resource while an action triggers a state change in a WSRP
service. In the final markup sent to a browser after URL-rewriting, of
course actions have to be rewritten into normal links that encode the
action so that the portal can reconstruct the action from the link.

I am not sure where we would have a problem with linking mechansism ... the
WSRP markup sent from the producer to the consumer would always be
rewritten by the consumer so that the resulting final markup sent to the
browser just consists of "http://...."; - which is something all browsers
can handle.

What do you mean by URIs for SOAP services ?

On the portal side, the URLs for the SOAP operations are an implementation
detail of the SOAP proxy to be used to connect to WSRP services. I think it
would in most implementations just get the URLs from the bindings that a
service advertises for the different operations defined in the WSRP
interface definition.

This is an example of such a binding definition (maybe not conforming to
the newest WSDL version, but it illustrates the binding concept nicely) -
the soapAction attribute defines the URL - just http://... in this example,
but other services might have other bindings using other base protocols for
transport.


<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

         <soap:binding style="document"/>

         <operation name="GetLastTradePrice">

            <soap:operation soapAction="http://my.org/GetLastTradePrice"/>

         </operation>>

    </binding>

I think a key thing to observe is that the portal communicates with the
WSRP service using SOAP and WSRP markup, but *must* communicate with
browsers using HTTP and final markup with rewritten links according to the
portal's URL schema.

Between the portal and browsers, we need business as usual - with normal
links according to the particular portals' schemes for addressing resources
like page groups, pages, portlets etc. One special case of these portal
links are links that come from special portlets that are actually
implemented as WSRP services, but the prefixes of these links also need to
exactly match the URL scheme used in the consuming portal like those for
any local, non-WSRP portlets.

The portal is responsible to rewrite any links and actions in WSRP markup
obtained from a WSRP service to that the browser accessing the portal can
consume it and so that any request resulting from a rewritten URL in that
final markup displayed in the browser can be intercepted by the portal.

Best regards,

Thomas



"Sasha Aickin" <AlexanderA@plumtree.com> on 05/31/2002 11:56:03 PM

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

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



Thomas,

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

Cheers,
Sasha.


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

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>