[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] [wsrp][markup] URL rewriting for proposals 2 & 4
1. Definitely, but as a developer I would like as little change as possible to occur when debugging the application as standalone, and when debugging it as a WSIA/WSRP service. 2. There is also the small case of static HTML. Although this is minor, _sometimes_ an application contains one or two static HTML pages. To convert them to JSP/ASP/... is a _small_ pain. Gil -----Original Message----- From: Peter Fischer3 [mailto:peter.fischer3@de.ibm.com] Sent: Tue, June 18, 2002 10:21 To: Gil Tayar Cc: 'Carsten Leue'; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: RE: [wsia] [wsrp][markup] URL rewriting for proposals 2 & 4 Gil, option #2 can be easily debugged if the producer (e.g. a portlet) uses a well defined API to create its links. So the producer always calls something like: someClass.createURI(); This creates a prefixed URI according to option #2 in the production environment and a 'working' link in the develpment environment.... Mit freundlichen Grüßen / Best Regards Peter ___________________________________________________________________ IBM WebSphere Portal Development Boeblingen, Germany Phone: ++49-7031-16-4497 eMail: peter.fischer@de.ibm.com |---------+----------------------------> | | Gil Tayar | | | <Gil.Tayar@webcol| | | lage.com> | | | | | | 06/18/2002 06:07 | | | AM | | | Please respond to| | | Gil Tayar | | | | |---------+----------------------------> >--------------------------------------------------------------------------- ---------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE | | cc: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org | | Subject: RE: [wsia] [wsrp][markup] URL rewriting for proposals 2 & 4 | | | | | >--------------------------------------------------------------------------- ---------------------------------------------------------| Carsten, I understand why option #2 may put less burden on the producer, but in contrast it may make it more difficult to _debug_ the producer. Option #2 means that the markup produced by the producer is not "valid", e.g. the links cannot be "followed" by a browser. This means that if behind the producer is a real HTTP application, it cannot be debugged "offline", or even checked with HTML validators that check links. Option #4, on the other hand, always creates valid HTML and links, which means that the "underlying application" can be tested by sending a "dummy" Proxy URL. In any case, the difference in the difficulty for the producer between #2 and #4 are minor. In both cases, URL-s in the underlying applications will need to be changed by the producer - it's just a question of the change algorithm (although in the case of "static" HTML pages I do agree that option #2 is easier). What I would propose is to enable both. Option #4 is enabled by one simple argument in the getFragments/performAction - the "Proxy URL" below (which in the original draft was named "controllerUrl" and which Thomas and Rich omitted when moving from the original draft specification to the new draft specification). The producer metadata (or return value from those operations) will specify whether URL rewriting was done or not. Gil -----Original Message----- From: Carsten Leue [mailto:CLEUE@de.ibm.com] Sent: Mon, June 17, 2002 18:45 To: Rich Thompson Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: Re: [wsia] [wsrp][markup] URL rewriting for proposals 2 & 4 Rich - very good proposal. As already indicated in the discussions I would certainly vote for options #2. They put less burden on the producer, allow for static producer content and still allow for efficient processing on the consumer side (by applying fast string matching algorithms like the BM alg. and selecting the StartToken carefully). Let's keep in mind that we envision a world in which it is easy to write and producer and we (the portal vendors) write the consumers. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Rich | | | Thompson/Watson/I| | | BM@IBMUS | | | | | | 06/11/2002 11:13 | | | PM | | | Please respond to| | | Rich Thompson | | | | |---------+----------------------------> > --------------------------------------------------------------------------- ------------------------------------------------------------------| | | | To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org | | cc: | | Subject: [wsia] [wsrp][markup] URL rewriting for proposals 2 & 4 | | | | | > --------------------------------------------------------------------------- ------------------------------------------------------------------| I had been asked to sketch a possible way proposals 2 & 4 could flow through the chain Producer -> Consumer -> End-User -> Consumer -> Producer to help people see the proposals more concretely. None of the choices for how things are represented here are meant to reflect a choice the subcommittee has made, just a possible means by which things could work. Sorry for the delay in getting this out .... I had been consumed by the merged interfaces work. ------------------------------- Possible impacts of the 2 proposals for Action type URLs ----------------------------------- Proposal #2: All portlets use a predefined prefix, which is part of the specification, to do the URL boundary demarcation. The aggregator then parses the markup looking for the well known prefix. |---------------------+-------------------------------------------| |Entity's URL |{StartToken}{urlType = | | |action}{actionName}{EndToken} | |---------------------+-------------------------------------------| |Consumer rewrites URL|Stores Entity's URL & generates url to | | |reference the action | |---------------------+-------------------------------------------| |End-User browser sees|http://Consumer.com?WSIA_urlref=5 | |---------------------+-------------------------------------------| |Post to Consumer |Consumer does a lookup and calls Producer | |---------------------+-------------------------------------------| |Soap invocation to |Producer.performAction(entityHandle, ..., | |Producer |actionName, ...) | |---------------------+-------------------------------------------| Proposal #4: The Consumer sends URL info to use to the remote portlet, allowing it to do correct URL writing itself. The markup sent back to the Consumer is then ready for immediate inclusion in the page, with no parsing necessary. Using Eilon's templating suggestion: |----------------------+---------------------------------------------------- ---------------------| |Consumer sets Entity |ActionURL = http://Consumer.com?WSIA_entity=7,WSIA_actionName | |property |={actionName}{params} | |----------------------+---------------------------------------------------- ---------------------| |Entity's URL |http://Consumer.com?WSIA_entity=7,WSIA_actionName=DoTransaction,parm1=foo| |----------------------+---------------------------------------------------- ---------------------| |Consumer passes URL | | |asis | | |----------------------+---------------------------------------------------- ---------------------| |End-User browser sees |http://Consumer.com?WSIA_entity=7,WSIA_actionName=DoTransaction,parm1=foo| |----------------------+---------------------------------------------------- ---------------------| |Post to Consumer |Consumer does a lookup of the entity and calls Producer | |----------------------+---------------------------------------------------- ---------------------| |Soap invocation to |Producer.performAction(entityHandle, ..., DoTransaction, ...) | |Producer | | |----------------------+---------------------------------------------------- ---------------------| ------------------------------- Possible impacts of the 2 proposals for Proxy type URLs ----------------------------------- Proposal #2: All portlets use a predefined prefix, which is part of the specification, to do the URL boundary demarcation. The aggregator then parses the markup looking for the well known prefix. |---------------------+----------------------------------------------------- -------| |Entity's URL |{StartToken}{urlType = proxy}{images/ok.gif}{EndToken} | |---------------------+----------------------------------------------------- -------| |Consumer rewrites |The Consumer acts as a proxy. | |URL: |Stores Entity's URL & generates url to reference the | | Case #1 |resource. The base URL for the resource has been discovered | | |from metadata or the self description. | |---------------------+----------------------------------------------------- -------| |End-User browser sees|http://ConsumerProxyServer.com?WSIA_resourceref=12 | |---------------------+----------------------------------------------------- -------| |Request from Client |Consumer does a lookup and serves the resource. | |---------------------+----------------------------------------------------- -------| | | | |---------------------+----------------------------------------------------- -------| |Consumer rewrites |The Consumer does not act as a proxy. | |URL: |Prefixes the URL with the service's base URL (see above). | | Case #2 | | |---------------------+----------------------------------------------------- -------| |End-User browser sees|http://Producer.com/images/ok.gif | |---------------------+----------------------------------------------------- -------| |Request from Client |The client directly accesses the resource | |---------------------+----------------------------------------------------- -------| Proposal #4: The Consumer sends URL info to use to the remote portlet, allowing it to do correct URL writing itself. The markup sent back to the Consumer is then ready for immediate inclusion in the page, with no parsing necessary. |----------------------+---------------------------------------------------- -----------------| |Consumer sets Entity |ProxyURL = http://Consumer.com?WSIA_entity=7,WSIA_proxy={resource} | |property | | |----------------------+---------------------------------------------------- -----------------| |Entity's URL |http://Consumer.com?WSIA_entity=7,WSIA_proxy=images/ok.gif | |----------------------+---------------------------------------------------- -----------------| |Consumer passes URL |The base URL for the resource has been discovered from metadata or | |asis |the self description and is stored by the Consumer. | |----------------------+---------------------------------------------------- -----------------| |End-User browser sees |http://Consumer.com?WSIA_entity=7,WSIA_proxy=images/ok.gif | |----------------------+---------------------------------------------------- -----------------| |Post to Consumer |Consumer uses the entity reference to lookup Producer, builds the | | |correct URL & serves the resource. | |----------------------+---------------------------------------------------- -----------------| ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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