Also, if we want to support multiple occurrences of collaborating
portlets on the same page (e.g., A1-B1 and A2-B2), then a groupID is
required to differentiate between the two.
To relate this to Yossi's point, this groupID could still be stored
persistently at the Producer (as part of the Entity's persistent
information) and not explicitly communicated. I think the tradeoff here
is simplicity versus flexibility for the Consumer and the Producer.
--Eilon
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Monday, September 30, 2002 11:56 AM
To: Tamari, Yossi
Cc: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
Yossi -
my point is that it might be very restictive to put all portlets from
one producer (per user) into one single initEnvironment context.
Especially if the result of such a call is the establishment of a HTTP
connection that will be reused for all other invokations of getMakup.
This will tie the connection (in most app servers) to one single cluster
node. This is necessary for the case that the portlets are in the same
application. But if they are in two distinct applications in principle
the requests to these two groups could be served by two cluster nodes.
If we limit ourselves to having one environment per producer we don't
allow for this option. Does that make sense? In many cases there will be
applications that only consist of one single portlet. We would not have
load balancing capabilities (per
user) if the user puts several portlets on his pages without a groupID.
I think that the information what portlets should be grouped together
(in JSR 168 terms they form an application) should be part of the
metadata in getDescription. The actual value of the groupID could be
arbitrarily chosen by the consumer as long as initEnvironment has been
called with this ID.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | "Tamari, Yossi" |
| | <yossi.tamari@sap|
| | .com> |
| | |
| | 09/30/2002 05:25 |
| | PM |
|---------+---------------------------->
>-----------------------------------------------------------------------
--------------------------------------------------------|
|
|
| To: Carsten Leue/Germany/IBM@IBMDE
|
| cc: wsrp-wsia@lists.oasis-open.org
|
| Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
|
|
|
|
|
>-----------------------------------------------------------------------
--------------------------------------------------------|
I am still not seeing your point. The producer, in our case a JSR 168
container, knows for each portlet in which application it resides,
right? so once again we have a situation when the consumer must know
which portlets are in the same group, and pass that information to the
producer which ALREADY KNOWS this. So either the producer receives
redundant information, or worse, it receives conflicting information. I
do agree that "it is a bad design". Even if we wanted to have the
groupId explicit in the protocol, it should have been returned from
initEnvironment rather than passed to it, since, at least for JSR168,
the producer application structure forces the grouping of the portlets.
If we put sessionId in the spec, I just don't think it is acceptable to
then say: "The value of this is determined by the consumer but MUST be
345" or something like this, which is where this is going...
Yossi.
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Monday, September 30, 2002 6:11 PM
To: Tamari, Yossi
Cc: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
Yossi - I think the statement should be "I disagree with Mike" and "it
is a bad design".
1. From my understanding the JSR168 issue is the following:
- JSR 168 defines an application scope (per user session), i.e. that all
portlets within an application within a user session need to be able to
share data
- portlets that are in two different applications cannot share data (no
global producer scope)
If this is correct then the JSR168 restriction to WSRP would mean that
the groupID must correspond to the application ID of portlets in the
producer and not to the producer ID. The producer can expose multiple
applications as WSRP services. If we used the groupID on a per producer
basis ignoring the application scope of JSR then the producer would have
to do addinional namespacing to isolate the applications.
2. I agree with Andre's comment that initInvironment is bad design. It
relies on a side effect (namely the fact that by this call a HTTP
session is established and the transport level cookie is used as a
hidden environment identifier). If some of us really need this
initEnvironment call then it must take the groupID as a parameter (the
groupID is then the explicit environment identifier).
Summary: I do not see a valid reason to get rid of the groupID.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | "Tamari, Yossi" |
| | <yossi.tamari@sap|
| | .com> |
| | |
| | 09/30/2002 04:27 |
| | PM |
|---------+---------------------------->
>
------------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: wsrp-wsia@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
|
|
|
|
|
>
------------------------------------------------------------------------
-------------------------------------------------------|
I am having trouble following the discussion thread here. Mike claims
that (at least for 1.0) the groupId must always be semantically
identical to the producer ID. Since a producer knows what is the
producer it is running in (I know this sentence does not make a lot of
sense, but that is exactly my problem here), there is no need to pass
the groupId. So it seems to me you can make one of two statements: "I
disagree with Mike" or "groupId is redundant". We are not depending on
any transport layer element here, which is one of the reasons I don't
understand Andre's comment.
Yossi.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Monday, September 30, 2002 5:15 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
I agree for the most part, but if the purpose is grouping, then why
wouldn't the ID be groupID and the operation be initGroup()?
I do not like the idea of piggybacking this on the first operation
within the group ... how is the Consumer to tell which transport level
items (cookies for http) are related to initializing the group and which
are related to interacting with the entity?
Andre Kramer
<andre.kramer@eu. To:
"'wsrp-wsia@lists.oasis-open.org'"
citrix.com> <wsrp-wsia@lists.oasis-open.org>
cc:
09/30/2002 09:17 Subject: RE: [wsrp-wsia]
[I#6]Update: Is groupId required?
AM
Introducing an implicit transport level token that is not reflected in
our application protocol (SOAP- headers or interface WSDL) seems bad on
design principles alone, to me, as producers are not always going to be
one (http or other transport) hop away from producers. Therefore the
pattern should
be:
initEnvironment(environmentID) - if environment needs to be explicitly
established
operation(environmentID) - if operation is in the context of the named
environment then the context should be explicit.
I don't mind limiting the use cases for initEnvironment (as long as it
remains optional) but I do wonder why we are both trying to simply the
semantics and adding an extra costly network round trip to the end user
interaction (maybe initEnviornment and its result should carry a
timestamp so that user dead time can be easily measured as well as a
context/environment/grouping identifier? ;-)
How about instead limiting a new connection to only one outstanding
getMarkup or performInteraction at first use so that a context can be
established both at the transport and wsrp level? This avoids the extra
initEnvironment round trip but I would still vote for some form of
context/environment/group identifier to make explict the shared context.
regards,
Andre
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: 26 September 2002 18:40
To: 'Tamari, Yossi'
Cc: 'wsrp-wsia@lists.oasis-open.org'
Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
Yup. Sorry. I'll update the list (remove the "we are
postponing..."
part). Note however that a "tentative proposal" email was also
sent.
-----Original Message-----
From: Tamari, Yossi [mailto:yossi.tamari@sap.com]
Sent: Thu, September 26, 2002 20:32
To: 'Gil Tayar'
Subject: RE: [wsrp-wsia] [I#6]Update: Is groupId required?
Hi Gil,
I think you got a little confused. Regarding this we said we
will vote next week to remove groupId from the spec.
It was regarding the isRefresh that we said we will defer
until
after the JSR meeting.
Yossi.
-----Original Message-----
From: Gil Tayar [mailto:Gil.Tayar@webcollage.com]
Sent: Thursday, September 26, 2002 8:29 PM
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] [I#6]Update: Is groupId required?
Owner: Michael Freedman
Title: Is groupId required?
Description:
Since we now have initEnvironment, which is the
solution
for shared sessions, do we now need groupId, which was
also defined as a mechanism for group sessions.
We are postponing this until we hear some more
information from the JSR-168 liason people.
----------------------------------------------------------------
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>
----------------------------------------------------------------
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>