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

[Carsten Leue <CLEUE@de.ibm.com>]

Mike -

if I understood your proposal correctly you agree in princple with the
concept of having metadata that is telling the consumer how to group
entities but propose a different way to do it. The basic simplification
seems to be that the producer is enumerates all of its groups (i.e.
applications), so the groupID (--> environmentID) would be much more
limited in range than as if it was a GUID.
What is not clear to me is how a producer could safely tell how many
applications it hosts. This number may change when new applications are
deleted or added. Whouln't it be much simpler to have a globally unique
identifer as the groupID without exposing mutable producer internals?

Best regards
Carsten Leue

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



                                                                           
             Michael Freedman                                              
             <Michael.Freedman                                             
             @oracle.com>                                               To 
                                       wsrp-wsia@lists.oasis-open.org      
             10/19/2002 08:11                                           cc 
             PM                                                            
                                                                   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>