OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp][markup] First conference call (Summary)

I'll chime in in support of Greg here.

Sasha makes a valid observation regarding the potential difficulty in
getting today's web app developers to adopt a new paradigm to create WSRP
portlets, and migrage existing web apps to portlets.  However, I think this
may be mitigated to the extent that JSR 168 and WSRP (not to mention WSIA,
which could be seen as addressing the more generic web application case)
mature in a synchronized fashion, and ultimately comprise well-coordinated
layers in a new stack which addresses the full spectrum of web app
development, implemented on top of SOAP and HTTP/WAP/Other wire protocols.  

I see risk in the failure of these multiple efforts to achieve the necessary
synergy, thereby sending a confused message.  In this event, we certainly
could expect resistance and slow adoption.


-----Original Message-----
From: PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com]
Sent: Wednesday, April 24, 2002 2:05 PM
To: 'Sasha Aickin'; PAVLIK,GREGORY (HP-NewJersey,ex2); Thomas Schaeck
Cc: Eilon Reshef; Takao Mohri; WSRP Mailing List (E-mail)
Subject: RE: [wsrp][markup] First conference call (Summary)

Sorry, I meant to say that the portlet container would be doing what the
servlet container now does, ensuring that the user is shielded from managing
sessions for portlets.

I agree with you in that I think it's clear that both WSRP and WSIA are
working toward a new paradigm for web applications. The degree to which
these specifications will succeed is going to be predicated on developer's
willingness to rethink how they build web apps, which is a substantial goal.


-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Wednesday, April 24, 2002 4:49 PM
To: PAVLIK,GREGORY (HP-NewJersey,ex2); Thomas Schaeck
Cc: Eilon Reshef; Takao Mohri; WSRP Mailing List (E-mail)
Subject: RE: [wsrp][markup] First conference call (Summary)


I totally agree with you in your first paragraph here.  Folks earlier on
this thread were suggesting that implementing a web service portlet
using standard web app tools would not be hard, and I was trying to
point out that it would be quite hard to leverage web app features like
caching and session management without a lot of work.  I think you hit
the nail on the head when you say that "it's not clear how a SOAP
message should be reconstituted in a normal and repeatable way into
something that the servlets treat as an HTTP request without a
standardized definition".  Thanks for being clearer and much more
concise than I was.

If this hypothesis is true, and portlet development will not work like
web app development, then I think we need to be honest about the fact
that we are discarding a lot of developer knowledge, training, and
experience by using a SOAP based approach.  We are also creating a large
barrier to entry for the large existing codebase of web apps out there.
I don't mean to imply that we would be able to create a spec that will
support all existing web apps if we use HTTP/HTML, but the smaller the
barrier, the better.

To answer your question, Plumtree's current architecture does use
HTTP/HTML, and we do use standard proxy caches in between the portal and
portlet.  Since we didn't define a new caching scheme, portlet
developers can use standard HTTP caching directives in JSP, ASP, and
Perl, and they have a good strong specification (RFC 2616) as to what
effect those caching directives will have.

I understand your point about action handling, although I would argue
again that this is discarding the standard notions that developers have
about (X)HTML links.  Also, I feel like relative links might be a little
tricky, but I haven't honestly thought that completely through.

As for your point about session management, I'm not quite sure I
understand the sentence "Session could be
eliminated as a problem in Java if the portlet container is in fact a
container rather than a web application."  Can you expand on this point?


-----Original Message-----
From: PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com]
Sent: Wednesday, April 24, 2002 4:49 AM
To: Sasha Aickin; Thomas Schaeck
Cc: Eilon Reshef; PAVLIK,GREGORY (HP-NewJersey,ex2); Takao Mohri; WSRP
Mailing List (E-mail)
Subject: RE: [wsrp][markup] First conference call (Summary)

It's not necessarily an easy problem to call from SOAP to servlets. Axis
do what Thomas states, but that's no guarantee that it's a ubiquitous
capability of all SOAP servers. In addition, even if we assume the SOAP
request is sent over HTTP and the server gives the programmer access to
RequestDispatcher, it's not clear how a SOAP message should be
in a normal and repeatable way into something that the servlets treat as
HTTP request without a standardized definition, certainly not without
jeopardizing both server-side implementation portability and alot of
repetitive coding.

This kind of implementation can be done, but it's not a good mechanism
implementing portlets. To make it simple and transparent, there really
to be a portlet container unless portlets are just web applications as
seems to be suggesting.

Sasha, what you are describing is essentially the way Plumtree's portal
architecture is built? Do people use, for example, HTTP proxy caching
between portlets and portals routinely? I don't really see a problem if
portal framework has different or new cache management rules for WSRP as
this is an implementation detail of the framework.

With respect to action handling, this should be the responsibility of a
portlet container, which in Java is already being defined. Again, I
see a huge problem: hand the action URL from the SOAP handler to the
container and return the result. It's only becomes a problem if you take
position that WSRP servlets should be implemented as regular web apps
on servlets.

I agree that session is a problem, since we want it to be replicated or
fault tolerant in the same way we expect servlet sessions to be (though
persistent state strikes me as being no different). Session could be
eliminated as a problem in Java if the portlet container is in fact a
container rather than a web application.


-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Tuesday, April 23, 2002 11:36 PM
To: Thomas Schaeck
Cc: Eilon Reshef; PAVLIK,GREGORY (HP-NewJersey,ex2); Takao Mohri; WSRP
Mailing List (E-mail)
Subject: RE: [wsrp][markup] First conference call (Summary)


I realize that it is possible to implement WSRP services on Java
application servers in the way that you suggest, but it seems to me that
a lot of web application programming paradigms will be so different in
that scenario that developers will not be able to leverage their web app
development experience, tools, and knowledge.

One example is state and session management.  Currently, servlets depend
on the app server's native session support, which is usually implemented
with cookies (or URL rewriting).  Several people on our TC have
suggested using a token in the WSRP API as a way to manage states and
sessions instead of cookies.  When we use the paradigm you suggest (SOAP
code dispatching out to a servlet), which notion of state/session
management would we expose to the servlet?  If we use the app server's
native cookie-based session management, then the servlet needs to have
knowledge about how to extract the WSRP state/session token.  If,
instead, we expose the WSRP session management to the servlet, then we
will have changed the semantics of the way the servlet works, and
someone may have to write a whole new session mechanism which uses WSRP
tokens as their key.

Caching is another thing that we are in danger of rewriting.  Standard
HTTP/HTML web apps have fairly well developed ideas of how caching
should be done, and those mechanisms have proved remarkably successful
in scaling up the web.  However, HTTP caching is not generally used in
SOAP calls for many reasons, chief among them being that it is not clear
when two SOAP requests correspond to the same call into a Web Service
(whereas HTTP can specify this with the Vary header).  This suggests to
me that either WSRP will not support HTTP-type caching capabilities (the
kind of features exposed by the Expires, Last-Mod, Etag, and Vary
headers) and will therefore be less feature rich, or we will spend quite
a while spec'ing out caching rules in our protocol.  If we do spec out
caching rules in our protocol, we would then need to build
infrastructure so that web apps written in servlets could easily exploit
those caching mechanisms.  We would also have to implement caches that
understood our new type of SOAP based cache rules (and potentially even
try to convince proxy server makers to do the same).  This is a
tremendous amount of work to just get to the level of functionality we
already have with HTTP/HTML web apps.

Action handling is yet another problem that we are looking to rewrite.
With an HTTP/HTML web app, user actions are generally handled by links
and forms.  However, since a web service will generally always be at the
same URL, links in the markup will need to be transformed according to
some scheme to become arguments to the web service.  I could see your
SOAP to servlet scheme taking in an URL argument to the web service and
dispatching to a servlet which corresponds to the URL, but this would be
both cumbersome to implement and difficult to make work with relative
URLs.  We are looking at adding several levels of transformation and
indirection to standard HTML/HTTP links, and I don't see that action
handling in web services gains any interesting functionality above and
beyond links in HTML/HTTP.

My basic point is that, by using SOAP (and decoupling markup from HTTP),
we are losing many solutions to common problems that are standard in the
HTTP/HTML application world, and I am not clear that we are gaining that
much in terms of functionality.  By porting concepts like session
management, caching, and action handling to web services, we will need
to build and test new development tools, provide documentation for
development best practices, and train developers in our new solutions to
these problems.  This seems to me like a major problem for our spec, and
one which will potentially be a large barrier to entry for developers.

What do people think about this?


-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Saturday, April 13, 2002 12:53 PM
To: Sasha Aickin
Cc: Eilon Reshef; PAVLIK,GREGORY (HP-NewJersey,ex2); Takao Mohri; WSRP
Mailing List (E-mail)
Subject: RE: [wsrp][markup] First conference call (Summary)

Just as a comment - it will be quite easy to implement WSRP services as
servlets running on a normal application server, all one has to do is to
call from the SOAP code (e.g. SOAP4J or AXIS) into the servlet container
using the request dispatcher that can be obtained within a provider for
SOAP code. Similar things are probably possible on .NET. So when
from scratch, developing WSRP services will be about as simple or hard
developing web apps.

But of course it is true that existing web apps need to be changed to
as WSRP services...

Best regards,


Sasha Aickin <AlexanderA@plumtree.com> on 04/12/2002 05:48:27 AM

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

To:    Eilon Reshef <eilon.reshef@webcollage.com>, "PAVLIK,GREGORY
       (HP-NewJersey,ex2)" <gregory_pavlik@hp.com>, Thomas
       Schaeck/Germany/IBM@IBMDE, Takao Mohri
cc:    "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org>
Subject:    RE: [wsrp][markup] First conference call (Summary)


While  this is true (and I'm generally a big fan of integrating with
existing systems),  supporting HTML doesn't seem like the big barrier to
supporting JSP and Perl  scripts.  The big problem with that, it seems,
that we've committed  ourselves to the SOAP web services world. 
a web app to be a  web service is decidely non-trivial; you can lose out
a lot of things that  J2EE server and IIS give you for free (session
management being a huge one), and  fitting in with the web service
programming paradigms is very different than  writing a web app page.

As a sidenote, I  have to admit that sometimes I get frustrated that we
trying to solve a lot  of problems that have already been solved with
standard web app development  tools.  Session management,
privacy, efficient caching, and  other issues are all fairly well
understood using the basic HTML/HTTP solution,  and I feel like we're
rewriting a lot of that.  Not only is it a lot of  work, it will be hard
for us to document and for developers to learn.  Does  anyone else
sometimes feel this way, or am I the only one?

That  all being said, I think that we have to support HTML if only for
huge amount  of developer knowledge of HTML (vs. XHTML).

-----Original Message-----
From: Eilon Reshef  [mailto:eilon.reshef@webcollage.com]
Sent: Wednesday, April 10, 2002  8:58 AM
To: 'PAVLIK,GREGORY (HP-NewJersey,ex2)'; 'Thomas Schaeck';  'Takao
Cc: 'WSRP Mailing List (E-mail)'
Subject:  RE: [wsrp][markup] First conference call (Summary)

I do believe we have to offer a migration path for  people that have or
even prefer plain old HTML - expecting everybody to go  back to their
scripts and JSP templates and rework them might provide a  barrier to
that we can avoid by simply supporting  HTML.
-----Original Message-----
From: PAVLIK,GREGORY  (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com]
Sent:  Wednesday, April 10, 2002 11:48 AM
To: 'Thomas Schaeck'; Takao  Mohri
Cc: PAVLIK,GREGORY (HP-NewJersey,ex2); WSRP Mailing List  (E-mail)
Subject: RE: [wsrp][markup] First conference call  (Summary)

Is there a general statement on whether the markup  subcommittee intends
treat HTML and XHTML  interchangeably? My initial thought was that WSRP
do better to standardize on XHTML, which would have a number of
including the ability of the consumer to  treat the fragment as an XML
fragment. It's not  terribly difficult to tidy up a piece of HTML and
repurpose it as well-formed/valid XHTML when dealing with legacy
early focus on XHTML might position us  better for dealing with devices
the long run, as  it appears that WML and cHTML are going to be
targets for the TC.


-----Original Message-----
From:  Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Tuesday, April 09, 2002 5:43 PM
To: Takao Mohri
Cc: PAVLIK,GREGORY  (HP-NewJersey,ex2); WSRP Mailing List (E-mail)
Subject: Re: [wsrp][markup] First conference call (Summary)

There is not something like "the markup language of WSRP",  the WSRP
protocol needs not to be tied to any  particular markup language, the
protocol and the  markup exchanged can be viewed as orthogonal.

However, WSRP will need to define rules for valid markup  fragments and
common styles with the  priorities
1. (X)HTML
2.  WML, cHTML, VoiceXML...

It would be interesting to see the rules that would define  valid XHTML
Basic fragments.

Takao, could you post an XHTML Basic example document to the  mailing
and an outline of fragment rules for  XHTML Basic ? Which tags would be
allowed in  aggregatable XHTML Basic fragments and which tags would not
allowed to use in fragments ?

Best regards,


Takao Mohri <mohri.takao@jp.fujitsu.com> on 04/09/2002  01:26:58 PM

Please respond to Takao Mohri  <mohri.takao@jp.fujitsu.com>

To:    "PAVLIK,GREGORY (HP-NewJersey,ex2)"  <gregory_pavlik@hp.com>
cc:     "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org>
Subject:    Re: [wsrp][markup] First  conference call (Summary)


Yes, as you mentioned, XHTML Basic is becoming a standard  for cellular
In WAP  2.0, XHTML Mobile Profile (an extention of XHTML Basic) is a
standard markup language. In Japan, cellular phones that  support WAP
are already on sale by KDDI. NTT  Docomo also has announced support of
In the near future, WAP 2.0, i.e, XTHML Basic will be used  by many

If the markup language of WSRP is based on XHTML  Basic,
it makes support of mobile devices much  easier.


"PAVLIK,GREGORY (HP-NewJersey,ex2)" wrote:
> Gino,
> Could you clarify if your intent is  to consider XHMTL/XHTML Basic as
> of the HTML focus? This wasn't clear from the notes.  There appears to
>  broad convergence in the mobile space, both with respect to WML and
> Docomo, to standardizing on XHTML Basic +  CSS. XHTML is going to be
> the device very soon, perhaps quicker than on the desktop,  making
this a
> relatively high priority item.  Fujitsu may have some comments on this
>  well.
> Greg
> -----Original  Message-----
> From: Gino Filicetti [mailto:gfilicetti@bowstreet.com]
> Sent: Friday, April 05, 2002 3:22 PM
> To: WSRP Mailing List (E-mail)
>  Subject: [wsrp][markup] First conference call (Summary)
> Team,
> Attached are the meeting notes from  today's Markup Subcommittee
> Comments  and suggestions are welcome.
> One thing I did notice was that there were quite a few  participants
> that aren't on the actual  list of official members for this team.
> team is quite small, I think it'd  be great if we could get some of
>  officially join and help out with the effort. Unfortunately, I wasn't
> to capture the names of  ALL the attendees this time around (I'll be
> record the con-call next time), but  please send me an email so we can
> your name  to official list and flesh out the team a little more.
> Currently, the official list  is:
> Gino  Filicetti
> David Taieb
> Khurram Mahmood
> Susan Levine
> Michael Hillerman
> Thanks,
> . . . . . . . . . . . . . . . . . . . . . . . .
> Gino Filicetti | Software Engineer
>  One Harbour Place, Portsmouth, NH 03801
> T  603.559.1692 | gfilicetti@bowstreet.com
> w w w .  b o w s t r e e t . c o m
>  ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the  subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

// Takao MOHRI (mohri.takao@jp.fujitsu.com)

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