Title: Message
I think it would behoove
everyone to think about what business models will actually make it profitable
for ISVs and independent developers to adopt WSRP/WSIA (other than portal
vendors, who gain obvious value).
Standards, whether open or de facto, typically succeed because there is a
business reason for them to succeed, not because they have the best technical
approach. In context of the portal market there indeed is an incentive to
developers who want to plug their apps into customers' portals to use
WSIA/WSRP/JSR168 and avoid having to write to several proprietary portlet APIs.
However the cost of writing to WSRP etc. needs to be less than that of just plugging into
different portlet APIs when customers demand they do so, or ISVs probably won't
adopt it. When possible it seems WSRP should try to avoid breaking
existing practices and skillsets, perhaps by abstracting whatever
functionality is re-invented and providing familiar interfaces to write
to.
Chad
-----Original Message-----
From: Eilon Reshef
[mailto:]
Sent: Thursday, April 25, 2002
8:41 AM
To: 'Sasha Aickin'; 'PAVLIK,GREGORY (HP-NewJersey,ex2)';
'Thomas Schaeck'
Cc: 'Takao Mohri'; 'WSRP Mailing List
(E-mail)'
Subject: RE: [wsrp][markup] First conference call
(Summary)
Sasha,
The question you raised is a somewhat major one.
SOAP is an application-level protocol that attempts to provide
transport-independent (and hence HTTP-dependent) functionality. Thus, notions
of caching, state, security, routing, and others would eventually
have to be replicated as part of the protocol stack, as part of the vendors'
offerings, and as part of the users' knowledge and
training.
With different pros and cons, it seems that the $$$ that vendors put
into so-called "education" around SOAP (and specifically, our friends in
Redmond and our colleagues in IBM) paves the way for end users to accept the
fact that SOAP is the de-facto server-to-server communication protocol, and
implicitly accept the fact that this may require new "stuff" (whether new
server constructs such as a "portlet container" Greg suggested or Web
Application->WSRP adaptors or other tools).
Naturally, this direction is somewhat more questionable in portlets and
interactive applications, where there's hardly a chance that someone will
route the message through an MQ/Series, and HTTP does provide considerable
"must have" functionality (which may not be required in other cases). Yet, I
don't think there's a way the industry would accept today any standard that's
not SOAP based. The bad part is that this will require a steeper learning
curve, with the obvious associated risk. The good part is that this provides
vendors with the opportunity to introduce new tools and solutions around the
new standards, which, life as it is, is one of the main reasons the new Web
Services stack was introduced.
Having said all this, WSDL does support plain HTTP binding, and we
might want to consider this as well. It will not solve all the complexities
you mentioned (e.g., there is still a single "Web Service" URL), but may offer
a way to alleviate some.
Regards,
Eilon
-----Original Message-----
From: Sasha Aickin
[mailto:]
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)
Greg,
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?
Thanks,
Sasha.
-----Original Message-----
From:
PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:]
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
may
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
the
RequestDispatcher, 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, 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
for
implementing
portlets. To make it simple and transparent, there really
needs
to be a portlet container unless
portlets are just web applications as
Sasha
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
agents
between portlets and portals routinely? I don't really see
a problem if
the
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
don't
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
the
position that WSRP servlets should be implemented as
regular web apps
based
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.
Greg
-----Original Message-----
From:
Sasha Aickin [mailto:]
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)
Thomas,
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?
Cheers,
Sasha.
-----Original Message-----
From:
Thomas Schaeck [mailto:]
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
the
SOAP code. Similar
things are probably possible on .NET. So when
starting
from scratch, developing WSRP
services will be about as simple or hard
as
developing web apps.
But of course it is true that existing web apps need to be
changed to
run
as WSRP
services...
Best regards,
Thomas
Sasha Aickin <> on 04/12/2002
05:48:27 AM
Please respond to Sasha Aickin
<>
To: Eilon Reshef
<>, "PAVLIK,GREGORY
(HP-NewJersey,ex2)"
<>, Thomas
Schaeck/Germany/IBM@IBMDE, Takao
Mohri
<>
cc: "WSRP Mailing List (E-mail)"
<>
Subject: RE: [wsrp][markup] First conference call
(Summary)
Eilon,
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,
is
that we've
committed ourselves to the SOAP web services world.
Rewriting
a web app to be
a web service is decidely non-trivial; you can lose out
on
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
are
trying to solve a lot of problems that have already been solved
with
standard web app development tools.
Session management,
authentication,
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
the
huge
amount of developer knowledge of HTML (vs. XHTML).
Cheers,
Sasha.
-----Original Message-----
From: Eilon
Reshef [mailto:]
Sent: Wednesday, April 10, 2002 8:58 AM
To: 'PAVLIK,GREGORY (HP-NewJersey,ex2)'; 'Thomas
Schaeck'; 'Takao
Mohri'
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
Perl
scripts and JSP templates and rework
them might provide a barrier to
entry
that we can avoid by simply supporting HTML.
-----Original Message-----
From:
PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:]
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
to
treat HTML and XHTML interchangeably? My initial thought was
that WSRP
would
do better to
standardize on XHTML, which would have a number of
advantages
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
content.
An
early focus on XHTML might position
us better for dealing with devices
in
the long run, as it appears that WML and cHTML are
going to be
secondary
targets for the TC.
Greg
-----Original Message-----
From: Thomas Schaeck [mailto:]
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
list
and
an outline of fragment rules for XHTML Basic ? Which tags would
be
allowed in aggregatable XHTML Basic
fragments and which tags would not
be
allowed to use in fragments ?
Best regards,
Thomas
Takao Mohri <> on
04/09/2002 01:26:58 PM
Please respond to Takao Mohri
<>
To: "PAVLIK,GREGORY
(HP-NewJersey,ex2)" <>
cc: "WSRP Mailing List (E-mail)"
<>
Subject: Re: [wsrp][markup] First conference
call (Summary)
Greg,
Yes, as you mentioned, XHTML Basic is becoming a
standard for cellular
phones.
In WAP 2.0, XHTML Mobile Profile (an extention of XHTML Basic)
is a
standard markup language. In Japan, cellular
phones that support WAP
2.0
are already on sale by KDDI. NTT Docomo also has announced
support of
WAP
2.0.
In the near future, WAP 2.0, i.e, XTHML Basic will be
used by many
mobile
devices.
If the markup language of WSRP is based on XHTML
Basic,
it makes support of mobile devices much
easier.
Regards,
Takao
"PAVLIK,GREGORY (HP-NewJersey,ex2)" wrote:
>
> Gino,
>
> Could you clarify if your intent
is to consider XHMTL/XHTML Basic as
a
part
> of the HTML focus? This
wasn't clear from the notes. There appears to
be
a
> broad
convergence in the mobile space, both with respect to WML and
NTT
> Docomo, to standardizing
on XHTML Basic + CSS. XHTML is going to be
here
on
> the
device very soon, perhaps quicker than on the desktop, making
this a
> relatively high
priority item. Fujitsu may have some comments on this
as
> well.
>
> Greg
>
> -----Original
Message-----
> From: Gino Filicetti [mailto:]
> 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
meeting.
> Comments and suggestions
are welcome.
>
> One
thing I did notice was that there were quite a few participants
today
> that aren't on the
actual list of official members for this team.
Since
this
> team
is quite small, I think it'd be great if we could get some of
you
to
> officially join and help out with the effort.
Unfortunately, I wasn't
able
> to capture the names of ALL the attendees this time around
(I'll be
sure
to
> record the con-call next time), but please send
me an email so we can
add
> 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 |
> 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 ()
// FUJITSU LABORATORIES LTD.
----------------------------------------------------------------
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>
