RE: [wsrp-wsia] Issues #6 - Is groupID required?

["Tamari, Yossi" <yossi.tamari@sap.com>]

Hi Andre,

 

Regarding inter-entity communication post 1.0, one possibility is some sort of pub/sub mechanism, operated by the consumer. This means one portlet can publish/subscribe to multiple events, so it actually needs more then a group ID, but it does not necessarily belong to any one group.

 

    Yossi.

-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Monday, October 21, 2002 12:41 PM
To: 'Michael Freedman'; wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?

As producers evolve they are likely to publish or remove applications (large producers may publish hundreds) and move entities between apps etc, so the ints are unlikely to remain small and consecutive, so I don't think this simplifies anything much [But I see the problem of efficiently look-up application names;- I was using groupID for that.]

 

 

I understand Carston's proposal is to tighten up the grouping semantics (allowing JSR 168 application producer grouping only) and to then drop the per - operation runtime groupID. Fine, but:

 

- we don't express our transport relationship in our protocol.

- initEnvironment() still seems a kludge (especially if required to be per-user).

- I can not imagine any inter-entity communication scheme that does not require some sort of groupID (please enlighten me for > 1.0).

- JSR168 is proposing a WindowID to associate entities (multiple times) with a Portal page (in my view that was covered by a sub-part of groupID).

- we can't extend our protocol to allow for simple counsumer sub-grouping in producer offered application scopes (except by mandating groupID).

  We could have had simple consumer sub-divisions of the producer application grouping scope (e.g. for multiple user pages or panes) by:

        - producer grouping  meta-data etc as Carston describes.

        - consumers optionally appending a local id to the producer meta data applications names (see producer-app-uri#consumer-id below).

        - consumers being (optionally) allowed to call initEnvironment more than once per application name (as long as appended local id (incl. null) is different).

        - consumers passing the extended application name (e.g. extended with a Panel or Window ID) in getMarkup/performInteraction (and initEnvironment if intEnvironment is required by the producer and as needed by the consumer sub-scope).

I fear consumers will discover such sub-scoping of application names works in practice for simple HTTP session based producer implementations and come to rely on it (even though it may be forbidden by our spec but expressed (only by transport level cookies) in the protocol).

 

 

Without a runtime groupID, I would encode grouping information in refHandels and therefore request that the issue of size of refHandel be tipped more in favour of large refHandels (or split into refHandle/refHandleState as Gil suggested as a possibility).

 

I would also like producer grouping names to remain unique (actual URIs, which may be more than Carston suggested). Then it is easy to qualify them with consumer page layout information (uri#id - using URI fragment identifiers).

 

regards,

Andre

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: 19 October 2002 19:11
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?

Carsten,
    This looks good, but I think we can [and should] make it a little simpler.  Basically, as groupID is no longer carried over the wire we need not concern ourselves with arbitrary group names.  I suggest we do the following:
    1) We change the doInitEnvironment field in ServiceDescription to something like numInitEnvironments. numInitEnvironment would be an int.  A value of 0 would mean initEnvironment should not be called.  A number > 0 indicates how many initEnvironments the producer requires.
    2) We change the groupID field in EntityDescription to something like environmentID. environmentID would be an int.  Its value would be between 1 and numInitEnvironment inclusive.  If numInitEnvironment is 0 or 1 the environmentID field is ignored by the consumer.  [When numInitEnvironment is 0 this field can be ignored because there are no environments. When  numInitEnvironment is 1 this field can be ignored because all entities are in the 1 enviornment.] If > 1, environmentID indicates the environmental context that should be used when interacting with this entity.  Values outside the range [or missing] signify invalid entity descriptions.  Consumers must not activate/use such entities.

This simplification makes consumer management/lookup simpler and more efficient and seemingly loses nothing on the producer side.
     -Mike-

Carsten Leue wrote:

Hi all.

As discussed on Thurday's call here is a writeup of the proposal we
discussed.

procedure:
1. the producer tells via metadata what entities belong to an application.
The producer assigns an ID (or name) for each such group. This name should
ideally be globally unique.
2. the consumer MUST respect the metadata grouping information. It MUST
call initEnvironment for each user session prior to making a call to any
entity that belongs to a group.
3. it would not be required to transfer the grouping-metadata at all across
the wire, so we could remove groupID (see the disadvantages section)
4. the consumer must respect cookies and headers in the HTTP case

advantages:
- no explicit groupID mechanism that pollutes the protocol
- compliance with JSR168

disadvantes:
- we lose our per-instance grouping concept
- functionality depends on metadata-awareness

comments:
to 1: in the JSR168 case the producer will choose the application ID as the
groupID
to 2: calling initEnvironment on a per-group basis provides a simple (yet
protocol dependent) mechanism for the producer to support multiple JSR 168
applications. As each application requires an HTTP session and the JSR168
producer respects (1), the call to initEnvironment establishes such an HTTP
session. Together with (4), ensuring that the session will be kept, the
producer can reuse this session between the consumer and the producer
directly as the HTTP session required by the JSR. No re-implementation of
session management on the producer would be required.
to 3: after the session has been established the groupID does not to travel
over the wire as the HTTP together with the entityHandle implies the
appropriate grouping on the producer. This implies that the consumer side
grouping equals exactly the producer side grouping. (1),(2) and (4) ensure
that.

Comments?

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>