Title: Message
We are on the same page with the approach.
Three questions I might have:
1. Would URL parameters (e.g., http://foo.com/wsrp?s=weather) be more
natural to those environments? (Still no need for an explicit
parameter)
2. The problem we are trying to solve is a single service serving
multiple portlet types (otherwise, there's no issue with either approach). Do we
expect such services to use .NET out of the box or would it be reasonable to
expect such service to implement custom SOAP-to-object
mapping?
3. Would it make sense to assume that the function
createTransientThingy (...)
accepts a persistentThingyID as an argument, i.e.,
createTransientThingy (persistentThingyID)
and that persistentThingyID can be assumed to include <portlet type,
portlet instance, [portal id]>
and leave the question whether we want to separate those components into
explicit variables to a WSRP-specific discussion?
Eilon
-----Original Message-----
From: Carsten Leue
[mailto:]
Sent: Monday, May 27, 2002 6:36
AM
To: Eilon Reshef
Cc: 'Alan Kropp'; 'Gil Tayar';
'Michael Freedman'; ;
Subject: RE: [wsrp][wsia][wsrp-wsia joint
interfaces][Draft Spec 0.43]crea
teEntity/createTemplate/createPortlet
Eilon - I would discourage the URL path approach because it
seems as if
this worked only in a servlet world. The
SOAP servlet intercepts the
request, interprets the
remaining portion of the URL and addresses the
internal service according to this URL. E.g. a request to
http://foo.com/wsrp/weather would be
intercepted by the
"htttp://foo.com/wsrp" servlet with
the service identifier "weather". Do I
understand this
approach correctly?
The problem is that this won't
work in AXIS or in .NET. That's why I would
prefer to
have a single service and do the dispatching using a class
identifier that is passed as an explicit parameter.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
|
| "Eilon
Reshef" |
|
|
<eilon.reshef@webc|
|
|
ollage.com> |
|
|
|
|
| 05/24/2002
07:33 |
|
|
PM
|
|
| Please respond
to |
|
| "Eilon
Reshef" |
|
|
|
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
|
To: Carsten Leue/Germany/IBM@IBMDE, "'Alan
Kropp'"
<>
|
|
cc: "'Gil Tayar'"
<>, "'Michael Freedman'"
<>, <>,
|
|
<>
|
| Subject:
RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea
teEntity/createTemplate/createPortlet
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Carsten,
Clearly there's a need for a single servlet to handle multiple
portlet
types. Why do you feel there's a need for a
single service (in the WSDL
sense) to handle multiple
portlet types? Why not map multiple services,
each
representing a different portlet type, into a single servlet using
WSDL techniques, such as URL paths, etc.?
Eilon
-----Original Message-----
From: Carsten Leue [mailto:]
Sent: Friday, May 24, 2002 10:48
AM
To: Alan
Kropp
Cc: 'Eilon
Reshef'; 'Gil Tayar'; 'Michael Freedman';
;
Subject: RE: [wsrp][wsia][wsrp-wsia
joint interfaces][Draft Spec
0.43]crea
teEntity/createTemplate/createPortlet
Alan -
from my point of view there are
a couple of advantages introducing
the
concept of a service container (at least
for WSRP):
- for WSRP all services are of
the same type, so handling them (life
cycle,
invokation framework on the server,
addressing) will be the same. In
that
case it is much easier to handle the
request centrally at one single
access
point.
- a portal might expose a large number
of portlets. If there was no
container the service would need an
entry point (e.g. soap servlet)
for
each of the portlets. This is not only
difficult to setup but may
also
consume a lot of resources (depending on
your app server)
-
conceptually a portlet is something that runs inside a portlet
(that
manages access, lifetime etc) . So it
makes sense to adpot this model
to
the remote case by introducing a service
container.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen ,
Germany
Tel.:
+49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
|
| Alan
Kropp |
|
|
<akropp@epicentri|
|
|
c.com> |
|
|
|
|
| 05/24/2002 01:32
|
|
|
AM
|
|
| Please respond
to|
|
| Alan
Kropp |
|
|
|
|---------+---------------------------->
>
---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To:
"'Eilon Reshef'" <>,
"'Michael Freedman'"
<>, "'Gil Tayar'"
|
|
<>
|
| cc:
,
|
| Subject: RE:
[wsrp][wsia][wsrp-wsia joint
interfaces][Draft Spec 0.43]crea
teEntity/createTemplate/createPortlet
|
|
|
|
|
>
---------------------------------------------------------------------------------------------------------------------------------------------|
Mike,
Along the lines of Eilon's
question, I'd like to have a better
understanding as to what the WSRP
Producer Container is for. I
confess to
not being well-informed on the
motivation for introducing this
concept in
the early interfaces/protocols
discussions. My hope has been that it
is
entirely a WSRP-specific construct, and
therefore not something that
needs
to be accounted for in the joint
interface. But I'm not convinced
one way
or the other, yet.
In the interests of furthering
this discussion, if you could run down
the
main points behind the container, for
both groups, I think it would
be
beneficial.
I think Mike's outline of the
lifecycle interfaces from a "pure" WSRP
perspective, in relation to
Gil's and Rich's latest rev of the joint
interface specification, represents the
clearest illustration yet of
the
"gap" we need to close. This is
good progress.
Alan
-----Original Message-----
From: Eilon Reshef [mailto:]
Sent: Thursday, May 23, 2002 3:36 PM
To:
'Michael Freedman'; 'Gil Tayar'
Cc:
;
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft
Spec
0.43]createEntity/createTemplate/createPortlet
Mike,
Per
the tension you mentioned, and your previous e-mail with
the
"Container" interfaces (C1-C4).
This
is a question that Rich referred to as "Heterogeneous
versus
Homogeneous" services. The question is whether the "container"
behavior should be an explicit part of the interface (as you
suggested in C1-C4 = "heterogeneous") or can be implicit in the
interface by providing different "services" (in the WSDL
sense), each
representing a separate portlet type (= "homogeneous").
Why
do you feel that WSRP needs the heterogeneous service?
Couldn't a
single container/server provide different services for
different
portlet types, and use WSDL techniques (mainly, URL paths) to
differentiate between the different portlets?
Eilon
-----Original Message-----
From: Michael Freedman [
mailto:]
Sent: Thursday, May 23, 2002 5:51 PM
To: Gil Tayar
Cc: ;
Subject: Re: [wsrp][wsia][wsrp-wsia joint
interfaces][Draft
Spec 0.43]createEntity/createTemplate/createPortlet
I don't think we want to give up so quickly on this. As
I
think all calls (after createEntity) need to be passed
the
entity handle -- and would find each to be unnatural if
we
defined they took an optional "bind" key. Also, I don't
think
entities are WSRP exclusive things. Rather I think the
tension
is WSRP needs (generic) container model while many
components
will be happy running as standalone services.
Personally, I
wonder if we will end up with two APIs -- one for service
simple and one for service container -- much like I
depict in
the e-mail sent earlier describing different component
types
needing to be modeled. Though containing by and large
the same
API the difference is the need for createEntity and
passing the
return handle in all subsequent operations -- i.e.
getFragment,
etc.
-Mike-
Gil Tayar wrote:
In the interest of sanity and progress, I have
broken up
Rich's, Michael's, Monica's and Eilon's emails into
four
subjects - "Shared Transient Information",
"Persistent
Information Scope",
"createEntity/createTemplate/createPortlet",
"session and
entity handles", and "Property lists". This email
will
deal with
createEntity/createTemplate/createPortlet, and
the relevant quotes from the emails and my reply to
them:
Rich wrote:> Presuming the 2nd case to get dropped
relative to the previous set of
> emails, I would propose this section call out how
we
will refer to these
> things throughout the remainder of the
document/API. In
particular, I would
> suggest:
> Session Information - This is
carried
opaquely
in
the interface as a
> "sessionID".
> => goes away
> Persistent Information - This is
carried
opaquely
in the interface as
> a "handle".> > Rather than
"Manifestation",
I
would propose using "Entity" to describe the
> thing from which markup may be requested. I think
it
has the right level of
> opacity (Consumer has no idea what kind of entity
it
is) while carrying
> appropriate semantics (a thing that may be
interacted
with). Using these
> terms, there was also an open question at the end
of
our last call related
> to whether there were both persistent and
transient
entities ... > > If we are going to support
explicit
lifecycle for both of these, I would
> propose:
> handle createEntity(handle,
propertyValues)
> sessionID createSession(handle,
propertyValues)
Michael wrote:> 1) createEntity (aka
createTemplate). In
WSRP we have discussed requiring
> consumers register with a producer to "activate"
it.
Registration returns an
> 'activation' handle used in subsequent calls to
identify the consumer. How can
> we account for this with the createEntity (and
other)
APIs? I really, really,
> really, don't want this to be an property value.
Also
what is the actual
> intent of these property lists? Gil implies they
are
persistence presets. If
> so should we have a separate list parameter that
allow
the consumer to further
> qualify the Entity being created? I.e. in WSRP
portlets aren't the direct
> producer -- they are managed/contained by the
producer.
We will want to use
> the createEntity call to create/be tied to these
subtypes -- hence need someway
> to qualify it in the call. Finally, are we
assuming
the service never wants to
> programmatically authorize this operation? If
not,
don't we need to pass User
> identity and roles as well?> > 2) destroyEntity
(aka
destroyTemplate). Since we seem to want to support
> creating new entities from existing one's do we
want to
support cascading
> delete? If not we likely should support bulk
deletes.
[Note: should we
> consider bulk create as well for
import/export/publish
purposes?] As with
> create entity the consumer ID should be
passed.Eilon
wrote (and I condense...):[...]> Would you find the
following, radically simplified, suggestion for an
operation> name intrusive:> createPortlet> Along
those
lines, a portal would call the operation
createPortlet,
would get back a > (persistent) portletID and then
(optionally) call createSession with the portletID.
[...]>
2. The ability to create a persistent key seems to
be
only under the scope of > WSRP and not under WSIA.
WSIA
supports a persistent key to create sessions and >
to
subsequent operations, but wouldn't probably deal
with
how they are created> and management (with all the
associated issues that are well described in
Mike's>
latest summary). Hence, the motivation to use a
portal-specific name.So now Gil writes:It seems
that
Michael, Eilon, and myself believe that the
createEntity/Template/Portlet operation is
particular to
WSRP (Rich, I even remember adding the
"templateKey"
thingie as a shot in the dark to where WSRP is
going - it
seems the shot missed!).I suggest then, dropping
this
from the joint interface subcommitee, and leaving
it in
the hands of the WSRP. Having said that, we must be
able
to support some type of connection between the
template/entity/portlet and the "session handle",
so what
I propose is that the createSession/Instance
operation
(outlined above) will accept an unspecified
"bindingKey",
i.e.:sessionHandle/ID =
createSession/Instance(bindingKey).The "bindingKey"
will
be an opaque string to be defined either by the
WSIA
service, or defined by specs above WSIA (i.e.
WSRP). One
can argue that this is similar to JDBC's
"connection URL"
(in getConnection) which is an opaque string
specified
when "connecting". WSRP could also use it to
specify the
"sub-service/portlet" of the container, if WSRP
decides
to go the heterogenous.My suggestion is to drop the
createEntity/Template/Portlet, and
leave:sessionHandle =
createSession(bindingKey) [bindingKey is an
opaqueString,
which will be used in the future by WSRP binding
specifications]getMarkup/performAction....(sessionHandle,
...) [i.e. all operations within the session will
receive
the sessionHandle]destroySession(sessionHandle)And,
as
Michael suggested, resolve timeout and implict
session
creation and deletion issues ASAP.(I specifically
dropped
the "propertyList" arguments as they are not the
issue
here, but that doesn't mean that I don't support
them).
Gil TayarWebCollage
----------------------------------------------------------------
To subscribe or unsubscribe
from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
