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] agenda for Tuesday 11June
Eilon -
I don't think its really counter-intuitive to have the porlet published its
conversation partners (portlets it wants to share a session with). An
approach could be to define categories. A portlet that belongs to a certain
category can the communicate with other portlets in this category. For
example if we define a very generic "SHOP" category a portlet can expect
that one of the other portlets in its session is the ShoppingCart portlet
and then use ShoppingCart specific parameters in the session.
Direct answers to your issues:
(a) not having shared sessions would in fact be the perfect approach. But
in this case we would have to define an event mechanism to allow portlets
to communicate. We decided to defer this. So the only way that portlets can
communicate is via the shared session.
(b) if there was only one session per service (not per remote portlet) then
the whole burden of shielding the portlets from each other lies on the side
of the producer. This is clearly not preferable as the consumer could
provide the appropriate logic and reduce the implementation effort on the
producer. I think that in WSRP we can assume that the consumer (normally a
portal) can be much more complex than a producer.
(c) if I understand this point correctly then the producer would have to
implicity return session IDs for the individual remote portlets. There
would be no createSession on the consumer. The producer would have to make
sure to return the same sessionID for all portlets that should share a
session. Right?
The problem here is in the following case: assume a portlet A that contains
a list of links and B that displays a link's content. If a user clicks on
A, B should display the content. This could be implemented such that A puts
the current link into the session and B simply uses this information to
display its content. So far so good. But what happens if two copies of A
and B appear on a page? How could the producer know which two should share
the session. Of course A1 should only influence B1, not B2 and vice versa.
The answer is that producer cannot known. The consumer must specify which
two portlets belong together, so the consumer must be able to create a
session.
(d) This would be indeed a valid option vs defining the interoparability in
the metadata. Do you have any detailed ideas?
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> |
| | |
| | 06/11/2002 07:27 |
| | PM |
| | Please respond to |
| | "Eilon Reshef" |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Carsten Leue/Germany/IBM@IBMDE, "Gil Tayar" <Gil.Tayar@elseweb.com> |
| cc: <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org> |
| Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for Tuesday 11 June |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Carsten,
A small concern I have regarding your point below.
Meta-data that defined inter-relationships between portlets doesn't seem
simple, nor does it seem intuitive to me that the fundamental way in which
a portal interacts with a set of portals depends on meta-data (and I'm
talking about a sequence of invocations, not about the type of information
passed, which is what meta-data is good for).
I would much rather have the notion of session sharing either (a) disappear
(b) be in a one-to-one relation with a service (c) be one-to-one with a
session, but managed by the portlet group (who don't need to publish this
information) (d) be explicit in the protocol in some other unidentified
way.
Eilon
[CL]
The idea was that the producer indicates session sharing capabilities
through its metadata (e.g. by defining categories, etc). However this
has
not been detailed yet.
The producer itself is a container of services.
[CL]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC