[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?
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)" <email@example.com> 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: firstname.lastname@example.org 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)" <email@example.com> 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC