[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-markup] RE: [wsia] [wsrp][markup] URL rewriting for proposals 2& 4
Carsten,
In
essence, this means that the developers of the service would have to, in
development, search _all_ URL-s in their application, and write them using
a RewriteUrl(...). In this case, why not spare the Consumer the task of doing
this in runtime? Just send the RewriteUrl(...) the ConsumerUrl and
let the Producer rewrite it using this ConsumerUrl.
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tue, June 18,
2002 21:32
To: Gil Tayar
Cc: 'Peter Fischer3';
wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
Subject: RE: [wsia]
[wsrp][markup] URL rewriting for proposals 2 & 4
Gil
-
1. the porlet code would not change in the two scenarios, just the
URL
rewriter would be modified (part of the container)
2. unfortunately
there will be no way around converting static HTML pages.
It should be not
that difficult.
Best regards
Carsten Leue
-------
Dr.
Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.:
+49-7031-16-4603, Fax:
+49-7031-16-4401
|---------+---------------------------->
|
| Gil
Tayar
|
|
|
<Gil.Tayar@webcol|
|
|
lage.com>
|
|
|
|
|
| 06/18/2002 11:58
|
|
|
AM
|
|
| Please respond
to|
|
| Gil
Tayar
|
|
|
|
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
|
To: Peter
Fischer3/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
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
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>
----------------------------------------------------------------
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