MHonArc v2.5.2 -->
wsia message
[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
I think there has been enough use cases on the email lists & conference
calls for both options 2 & 4 that I would propose we work on how the
underlying semantics of having both options works. My current thoughts:
- Well defined property names for the templates of option #4
- Decide whether the prefix of option #2 is static to the spec or dynamic
via a property (this choice essentially includes whether or not there is a
recommended a parse algorithm)
- Producer property set includes predefined names if it is willing to use
option #4.
- Consumer metadata indicates whether it is prepared to do URL rewriting
(option #2)
- Compliant Consumers MUST either set template properties OR indicate a
willingness to rewrite URLs.
- Producer options when defining the template properties then become:
- If Consumer set template properties AND indicated it is willing to
rewrite URLS, Producer may choose either option.
- If Consumer set template properties AND indicated it will not
rewrite URLs, Producer must use option #4
- If Consumer did not set template properties AND indicated it is
will to rewrite URLs, Producer must use option #2
- If Consumer did not set template properties AND indicated it wil
not rewrite URLs => non-compliant Consumer.
- Producers not defining the template properties require that their
Consumers support URL rewriting & use option #2
Net effect:
- Producers are not required to support option #4, but those desiring
broadest use by Consumers will.
- Consumers are not required to support option #2, but those desiring to
use the broadest set of Producers will.
- If both options are available, the Producer gets to choose which to use.
I see the email servers messed up the original table ... I have appended a
Word version of it to this email.
(See attached file: WSIA-WSRP URL rewriting.doc)
Gil Tayar
<Gil.Tayar@webcol To: Carsten Leue/Germany/IBM@IBMDE
lage.com> cc: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
Subject: RE: [wsia] [wsrp][markup] URL rewriting for proposals 2 &
06/18/2002 12:07 4
AM
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.
|
|----------------------+----------------------------------------------------
-----------------|
Attachment:
=?iso-8859-1?Q?WSIA-WSRP_URL_rewriting.doc?=
Description: MS-Word document
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC