[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