MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]createEntity/createTemplate/createPortlet
Eilon -
1. A syntax like http://foo.com/wsrp?s=weather would at least be more
promising like the former approach. However this relies on the ability to
access request parameters from within a SOAP handler. Unless you override
the SOAP handler this will not be possible as normally your SOAP
environment directly maps the incoming request to a method call in your
prefered programming language. For the method, the calling context is
totally transparent. In SOAP4J and AXIS you could write yourself a hack for
this problem, but in my opinion we should not build our interface and
protocol specification on such assumptions. Furthermore I don't know an
easy way in .NET to do the same thing.
2. We should try to design our data structures, method signatures and WSDL
files such that today's standard tools are able to generate automatic
proxies and stubs (e.g. WSAD and Visual Studio .NET). This will not be easy
and maybe in the end there will be the need of some custom mappings. But I
think that we should not enforce users to hack themselves into their
product's SOAP stack to implement WSRP services. If a portal vendor does
this for efficiency reasons, that's ok, but it should not be required.
3. The approach to put some parameters together in one data entity sounds
good. I would even go a step further and try to make as much information
implicit as possible:
- e.g. the portlet instance implies the portal ID because it has already
been created in a registration context
- the same is true for instance and type
There is another reason why explicitly addessing portlets in the portal
service might be preferable to using the URL to address them and that is
batch processing. For tasks like staging or deserialization of portals you
can assume that a large number of remote portlet thingies might need to be
generated "simulaneously" from the same consumer on the same producer.
Instead of requiring N request for this we could allow vectors of
information to be passed to the different WSRP methods and such
significantly reduce roundtrips. We should at least do this for the
deletion of handles but why not for their creation as well.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | "Eilon Reshef" |
| | <eilon.reshef@webc|
| | ollage.com> |
| | |
| | 05/28/2002 06:04 |
| | AM |
| | Please respond to |
| | "Eilon Reshef" |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Carsten Leue/Germany/IBM@IBMDE |
| cc: "'Alan Kropp'" <akropp@epicentric.com>, "'Gil Tayar'" <Gil.Tayar@webcollage.com>, "'Michael Freedman'" |
| <Michael.Freedman@oracle.com>, <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org> |
| Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
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:cleue@de.ibm.com]
Sent: Monday, May 27, 2002 6:36 AM
To: Eilon Reshef
Cc: 'Alan Kropp'; 'Gil Tayar'; 'Michael Freedman';
wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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�blingen , 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'"
<akropp@epicentric.com>
|
| cc: "'Gil Tayar'" <Gil.Tayar@webcollage.com>,
"'Michael Freedman'" <Michael.Freedman@oracle.com>,
<wsia@lists.oasis-open.org>, |
| <wsrp@lists.oasis-open.org>
|
| 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:cleue@de.ibm.com]
Sent: Friday, May 24, 2002 10:48 AM
To: Alan Kropp
Cc: 'Eilon Reshef'; 'Gil Tayar'; 'Michael Freedman';
wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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�blingen , 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'"
<eilon.reshef@webcollage.com>,
"'Michael Freedman'" <Michael.Freedman@oracle.com>, "'Gil
Tayar'"
|
| <Gil.Tayar@webcollage.com>
|
| cc: wsia@lists.oasis-open.org,
wsrp@lists.oasis-open.org
|
| 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:eilon.reshef@webcollage.com]
Sent: Thursday, May 23, 2002 3:36 PM
To: 'Michael Freedman'; 'Gil Tayar'
Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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:Michael.Freedman@oracle.com]
Sent: Thursday, May 23, 2002 5:51 PM
To: Gil Tayar
Cc: wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
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>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC