Title: Message
My
comments added to doco as well.
-----Original Message-----
From: Eilon Reshef
[mailto:]
Sent: Wednesday, April 03, 2002
12:12 PM
To: 'Cassidy, Mark'; 'Michael Freedman';
Cc: 'WSRP'
Subject: RE:
[wsrp][pfbm] -- Getting started
I think the main topics are covered. Added
a couple more thoughts and questions.
-----Original Message-----
From: Cassidy, Mark
[mailto:]
Sent: Wednesday, April 03, 2002
12:32 AM
To: 'Michael Freedman'; WSRP;
''
Subject: RE: [wsrp][pfbm] -- Getting
started
I think your approach is fine. Let me throw out a
couple thoughts for
starters:
- From interactions with customers and others involved with
web services
currently, I've found few that really
are pushing on the 'Find' part of
PFBM. Most
folks are dealing with services they explicitly know about.
So
I would propose that WSRP really doesn't need to
invent anything new in the
'Find' arena, unless of
course the requirements we converge on for 'PBM'
have some implications on what can be supported with the current
UDDI
specs(which I'm not a SME on).
- On a similar note, I would argue that 'Publish' is simply
a formal method
of making known Bind/Metadata
information about a WSRP service, and that we
don't
need to invent anything new in this arena either. Another
arguement
deferring much of a focus on publish/find,
at least initially, is that it
seems these could be
affected by what the bind/metadata part ends up looking
like.
So, I'd suggest we focus on bind/metadata for
starters.
Some initial questions(should be answered in order):
a) What actions should a portal application be able to take
based on the
published metadata about a WSRP
service?
Metadata requirements should directly fall
out of this.
b) Which metadata is required?
Which is optional?
c) Will we support an extension
mechanism to allow vendors to include custom
metadata? Example scenario?
As far as work product, it seems that we need to document
requirements and
then a spec for the metadata
schema(perhaps dtd & any companion semantic
information?). Not sure we need to do anything more...
Note: Tim Granshaw sent me a note following the F2F
expressing an interest
in contributing to this
group. We should include Tim in any
correspondance(if we have any outside of the standard wsrp mail
alias).
-----Original Message-----
From:
Michael Freedman [mailto:]
Sent: Tuesday, April 02, 2002 5:41 PM
To: WSRP
Subject: [wsrp][pfbm] -- Getting
started
Note: [PFBM] is short for [Publish, Find, Bind, and
Meta-data]
Folks, in particular Mark Cassidy, Jeff Broberg, Petr
Palas, its time
to get ourselves organized and
going. At the face-to-face we decided
not to
schedule regular conference calls -- but didn't really discuss
how we would begin. Any suggestions? Did you
like the approach I took
with [interfaces and
protocols]? Namely, attempt to categorize the
problem space and pose the questions we need to begin
discussing? If so
would someone like to make a
stab at this to get us started? Other
ideas?
I also am interested in what work product(s) you think we
should
produce. Is our first task (once we
understand what questions we are
answering) to write
a requirements doc? If so do we stop there? Do we
also try and move from requirements to spec?
-Mike-
----------------------------------------------------------------
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>
Title: InterfacesProtocols
Comments by Eilon Reshef in red
Comments by Carsten Leue in blue
Comments by Jeff Broberg in
green.
Discussion Areas
SOAP encoding
How do we return marked up content in a soap response? efficiently?
Should we support an escape hatch so the getContent request can be made via
HTTP post?
Are there any performance numbers we would like the implementation team to
generate for us to better understand how to most efficiently use SOAP?
Make
sure that the SOAP flavour used is compatible to implementations other that
J2EE (e.g. .NET)
The
2001 spec seems to be better for compatability between java & .net
WSIA
I am assuming for the moment that
the areas where WSIA/WSRP overlap will NOT be discussed in this subcommittee --
the pupose of this ietm is to define explicitly what is exlcuded. From my
notes taken at last week's meeting this would seem to be:
activation/deactivation
version
detection/expression
look and feel customization?
WSRP interfaces
Instance lifecycle
create -- What are
the things we want a producer to be able to do when a portlet instance
is created? What information is needed from the consumer to do
this? Who controls/creates the instance handle (portlet id)? Is the handle persistent? Is the handle cloneable?
Can one (server side) handle be used by multiple clients concurrently?
destroy -- What are
the things we want a producer to be able to do when a portlet instance
is deleted? Can a (persistent) handle
expire?
other operations --
Are there other operations we should consider? Do we need to
define a copy method? How about a publish method (when a portal is
being moved from a dev to a stage to a production environment)?
Others?
A
couple of quick thoughts:
- There
seem to be different notions of lifecycle and state: one is design-time (when
setting up new portals or portal pages) and one is run-time (when new users
come to a portal page and create specific instances of porlets). It could be
nice to form a terminology around that (e.g., design-time versus run-time and
portlet template versus portlet instance??) .
- We need to get these terms into the
glossary. Has anyone seen the doc
from the f2f that had the proposed items ??
-
A couple of additional
questions related to the design-time model. What workflow is supported for
creating a portlet template? Does the portal need to be “registered” with the
portlet? Any extensibility around the process for creating and approving
creation of a design-time portlet? (E.g., if the portlet owner needs to know about
it or approve it?) Any design-time information the portlet needs to get? Is the
persistent data always stored at the portlet? Also on the portal?
-
I don’t think we should be
talking about workflow and portlets, in my opinion they are separate, expcept
that we may want to describe the potential ( not mandatory ) interaction that a
portal administrator may have in regards to the discovery of available
portlets, and the inclusion of them into their environment. But how this is done, I believe is
probably where the portal vendors can have their value add.
-
Are we all under the
assumption that the portlet producer will provide an opaque handle to a portlet
template, which can be instantiated in run-time?
Content generation
What information does the producer
need to generate content? How does the producer know what content to
produce? How does the producer return content? How does it indicate
content type and encoding? Should we start with an assumption that most
renderers adhere to the HTTP get/post response model and try and map from that
to SOAP?
Actions
What are actions? How are
they different from events? Why are they needed? Do actions produce
content? Can action handlers cause other actions or events to be
triggered? If so how does a portlet instance discover and identify targets? How
can actions be efficiently implemented? How are
actions encoded in the markup?
I have heard others refer to the notion of an “action”
as an “option”.
Events/messaging
What are events? How are
they different from actions? Why are they needed? Do events produce
content? Can event handlers cause other actions or events to be
triggered? If so how does a portlet instance discover and identify
targets? Are events a general purpose concept that should utilize a
general purpose messaging system or is the messaging system defined and managed
by the consumer/Portal? How can events be efficiently implemented? Do we need events in WSRP or can we live with actions for
the sake of ease-of-use and ease-of-implementation?
I think we need both to truly handle both the
embedded and customized use cases.
Session
Management/Portlet Grouping
What are session for; maintaining
state within a single portlet and/or maintaining between a set of (cooperating)
portlets? If the later, do we need a notion of a Portal application/group/provider
int he API? If we do, what is its role (from an API/abstraction
perspective)? How are sessions established? By the consumer? By the
consumer requesting a session? Or willy-nilly in responses by the producer
(this is the http/servlet model)? Is the
portlet always stateful? (probably not) Who can invalidate a
session? How does each side get notified? How does a consumer react when
told a session has become invalid? How does the portlet/producer? Can user-specific run-time data be persistent as well?
(e.g., a “Remember Me” box in a login page) If so, is this part of this topic
or the lifecycle topic? (Might be a good idea to combine the two under “State
Management”)
How should the portlet react when running in a
cluster, what effect does this have on the session information ?
Request data
What information should the portal
pass to the portlets when requesting markup? Will
all data need to be published with each request or will it be possible to
initialize the service once and send only differential data in the subsequent
calls?
I think that this type of information could
potentially be passed in the first bind operation, and removed from the
subsequent traffic.
Order of method invocation,
client, & server contracts
I don't have any specific questions
to throw out here -- to a certain extent this probably falls out of answering
the questions in the other topic areas. Anyone have any ideas?
URL Rewriting
Does the consumer or a producer do
URL rewriting? (Note: If the producer then URL rewriting is used loosely
here as no rewriting might take place if URLs are written correctly in the
first place) What are the factors we need to consider to make a
decision? Performance? Ease of use? Correctness? Decoupling between producer and consumer? Robustness?
Is there a way to support both styles transparently to the producer? How
do we support hardcoded/(absolute?) URLs? URLs
created dynamically with scripting (i.e., JavaScript)? URLs encapsulated in
some binary content (e.g., links from a Flash file or an applet)? Is there an
explicit/implicit notion of URLs that shouldn’t be rewritten?
I think that we should scope the url rewriting into
the two categories, stream based and property based rewriting.
namespace encoding
How does the portal/portlets
distinguish portlet instance form/request parameters such that each instance
can (safely) locate its parameters in the request? If namespace/prefixing
is used, what is a name composed of? Does the portal expose only a portlet
instance's parameters to the instance or does the instance "see"
other request parameters? If parameters are isolated how is this
implemented? Can the URL rewriting principle be
used to rewrite namespace prefixes? Performance and ease of use need to be
considered. It would be nice if WSRP would allow for services with static
content (so namespace rewriting would be done on the client). Are there any namespace restrictions around content
elements (HTML IDs, JavaScript function names, etc.)? Across different
portlets? Across different instances of the same portlet?
There are probably situations where the parameters
can either be considered private to the originating portlet, or public for
inspection by others.
Remote portlet vs remote
portlet container
Does the API we are designing generally require a producer side runtime
(portlet container) to make it convenient for content developers? If
so, should WSRP define a least one more API, a simple API, that
removes/hides the extra complexity of the full version?
I don’t think we
should go here, once again, the value-add for the portal vendors.
