OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsrp-wsia] Roles



I agree with Mike.

Yet another option would be:

   d) Consumer arbitrary mapping: The consumer would associate many 
producer roles to a single consumer role. For example, the consumer 
would map both producer.seller and producer.buyer to consumer.user. All 
users with consumer.user role would have the producer.seller and 
producer.buyer roles.

Alejandro

Michael Freedman wrote:
> Rich can you explain why you reach your conclusion that this smells like an extension?  It
> doesn't to me.  Though I agree there will be problematic mappings, the mechanism we have
> defined is useful [when it can be used] and properly needs to be standardized for these
> situations.  By leaning towards making this an extension you seem to imply that the
> consumer and producer will have to come together to make this work anyway which is exactly
> our expectation for all extensions.  I see a different outcome.  To me, administrators of
> consumers get a choice when presented with foreign roles that no existing consumer role
> maps directly to -- the administrator may create new roles in the consumer [if possible] to
> match the producers requirements or the administrator may choose to abort the registration
> and not interact with the producer.  I.e. for your example I see one of 3 outcomes:
>      a) The existing roles map:  I.e. it might be that this consumer only wants to interact
> with the buying function and is happy to map all its users to the producers "Buyers" role.
>      b) Create new roles:  I.e. when no good mapping exists the consumer [if capable] can
> create new roles corresponding to the producer functional roles.  In this case the consumer
> creates a new "Buyers" and "Sellers" role.
>      c) Drop the producer:  If no good mapping exists to necessary function and new
> consumer roles aren't added then the administrator makes a decision to not use the
> producer.
> 
> Since in both case (a) and (b) above the consumer uses the producer and supports role
> mapping it must pass the role information in its requests.  Wouldn't we want this
> standardized so the producer receives/interacts with roles in a standard way?
>     -Mike-
> 
> Rich Thompson wrote:
> 
> 
>>What was missing from the email you responded to was the original issue
>>comments ... copied here for reference. Please explain how the
>>administrator maps roles in this case:
>>
>>In pulling this together I have worked through clarifying a number of areas
>>people questioned, including sections 8.3 & 8.4 discussing interoperability
>>of roles. It currently discusses how Producers and Consumers making
>>different choices about supporting this option. The one area this has left
>>me with big concerns is when both choose to support roles. I don't see any
>>clearly definable semantics whereby Consumer maps its roles to the Producer
>>published roles. To keep it simple, I would like to consider the scenario
>>where:
>>   The Consumer only supports the spec defined roles of Administrator, User
>>   and Guest
>>   The Producer declares the roles Admin, Buyer and Seller
>>
>>A reasonable administrator at the Consumer will probably map the
>>Administrator role to the Producer's Admin role, but clearly the
>>granularity of the Producer's roles does not match the granularity of the
>>Consumer's roles. There is no reasonable mapping available to be made.
>>Reflecting on this further, the whole schema of role mapping only really
>>works when there is a huge overlap in the roles supported at the Producer
>>and the Consumer. To me this is more and more smelling like something that
>>belongs as an extension rather than an inherent part of the spec.
>>
>>
>>                      Alejandro
>>                      Abdelnur                 To:
>>                      <alejandro.abdeln        cc:       wsrp-wsia@lists.oasis-open.org
>>                      ur@sun.com>              Subject:  Re: [wsrp-wsia] Roles
>>
>>                      11/26/2002 03:46
>>                      PM
>>
>>
>>
>>How roles are mapped is clear (an admin does the mapping), what is not
>>clear is the idea of automatic mapping (without admin intervention).
>>IMO, not having a solution for this automatic mapping is not an argument
>>for dropping all concept of roles from the spec.
>>
>>Alejandro
>>
>>Rich Thompson wrote:
>>
>>>
>>>
>>>
>>>What I am saying is that we either need to clearly define the semantics
>>>(including how roles can be mapped when there is no match in the
>>>granularity of role definitions) or drop all concept of roles from the
>>>spec. Note that the later case does not eliminate using roles when both
>>>sides agree on how to do this (e.g. JSR109), but rather leaves this area
>>
>>to
>>
>>>other specifications the end-points also choose to support.
>>>
>>>
>>>
>>>
>>
>>>                      Alejandro
>>
>>>                      Abdelnur                 To:
>>
>>>                      <alejandro.abdeln        cc:
>>
>>wsrp-wsia@lists.oasis-open.org
>>
>>>                      ur@sun.com>              Subject:  Re: [wsrp-wsia]
>>
>>Roles
>>
>>>                      11/26/2002 12:54
>>
>>>                      PM
>>
>>>
>>>
>>>Rich,
>>>
>>>Are you suggesting to drop the predefined roles from the spec?
>>>
>>>Alejandro
>>>
>>>Rich Thompson wrote:
>>>
>>>
>>>
>>>
>>>      This mapping works reasonably in a J2EE environment because the
>>>      granularity
>>>      of role definitions doesn't vary too dramatically. As a web service
>>>      spec,
>>>      WSRP had better worry about cross platform issues as well. As soon
>>
>>as
>>
>>>      one
>>>      moves out of the J2EE world, the chances that the granularity of
>>
>>role
>>
>>>      definitions is close drops precipitously.
>>>
>>>      Rex suggested the role fields could just be optional ... they are,
>>>      but what
>>>      this means for a Consumer that doesn't use roles and wants to use
>>
>>the
>>
>>>      maximum number of Producers is pretending they support the spec
>>>      defined
>>>      roles (e.g. mapping whatever internal access control mechanisms are
>>>      in use
>>>      to the spec defined roles) and trying to map these onto the
>>
>>Producer
>>
>>>      published roles. I assert this will fail miserably more than it
>>
>>will
>>
>>>      succeed.
>>>
>>>
>>>
>>>
>>>                            Andre Kramer
>>>
>>>                            <andre.kramer@eu.        To:
>>>      wsrp-wsia@lists.oasis-open.org
>>>                            citrix.com>              cc:
>>>
>>>                                                     Subject:  RE:
>>>      [wsrp-wsia] Roles
>>>                            11/26/2002 08:48
>>>
>>>                            AM
>>>
>>>
>>>
>>>
>>>
>>>
>>>      J2EE also has the concept of role mapping in that a developer can
>>>      write her
>>>      application in terms of her usual set of roles. The deployer of the
>>>      application can then map those roles, at deployment time, using a
>>>      relatively
>>>      simple XML role reference description mechanism. I view wsrp
>>
>>consumer
>>
>>>      roles
>>>      as the analogue of the J2EE developer's role set, the consumer
>>
>>Portal
>>
>>>      admin
>>>      as the analogue of the application deployer (at service
>>
>>registration
>>
>>>      time),
>>>      and the role names on the wire as the J2EE container roles. So, we
>>>      potentially have two similar mappings of roles: consumer to
>>
>>producer
>>
>>>      and
>>>      JSR
>>>      168 Portlet to J2EE Container? Each requiring human intervention.
>>>
>>>      regards,
>>>      Andre
>>>
>>>      -----Original Message-----
>>>      From: Rich Thompson [mailto:richt2@us.ibm.com]
>>>      Sent: 26 November 2002 12:52
>>>      To: Martin Bryan
>>>      Cc: wsrp-wsia@lists.oasis-open.org
>>>      Subject: Re: [wsrp-wsia] Roles
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      I have had the uneasy feeling about roles for a while, but
>>
>>rewriting
>>
>>>      those
>>>      sections finally caused me to focus on it enough to see the
>>
>>detailed
>>
>>>      reasons why (you site some good examples). At this point I think it
>>>      is only
>>>      useful to that set of Consumer-Producer pairs that have a
>>
>>coordinated
>>
>>>      set
>>>      of roles and since we won't be able to define tight semantics it
>>>      doesn't
>>>      belong in the spec.
>>>
>>>      On the address side, the variations in address are a big issue and
>>>      WSRP is
>>>      not the right place to tackle it. We took guidance from the P3P
>>
>>data
>>
>>>      model
>>>      in this area though we did need to provide some structure for their
>>>      unstructured portions. I was hoping much of the variability could
>>
>>go
>>
>>>      into
>>>      the field named street as this is an array of strings. In addition,
>>>      each of
>>>      the structures is individually extensible with the expectation that
>>>      some of
>>>      those extensions will come back for consideration as base level
>>>      fields in
>>>      v2. If there are other sources that would give a more
>>>      internationalized
>>>      view of this area, we certainly would appreciate a pointer ....
>>>
>>>
>>>
>>>
>>>
>>>                            "Martin Bryan"
>>>
>>>                            <mtbryan@sgml.u-n        To:       Rich
>>>      Thompson/Watson/IBM@IBMUS
>>>                            et.com>                  cc:
>>>
>>>                                                     Subject:  Re:
>>>      [wsrp][wsia]
>>>      Draft spec v0.85
>>>                            11/25/2002 11:35
>>>
>>>                            AM
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      Rich
>>>
>>>
>>>            Reflecting on this further, the whole schema of role mapping
>>>            only really
>>>            works when there is a huge overlap in the roles supported at
>>>            the Producer
>>>            and the Consumer. To me this is more and more smelling like
>>>            something
>>>
>>>      that
>>>
>>>            belongs as an extension rather than an inherent part of the
>>>            spec.
>>>
>>>
>>>      At last you are beginning to see the problem. Now consider what
>>>      happens if
>>>      the Producer is Finnish and the Consumer is Japanese and both use
>>>      their own
>>>      languages to define their services. Now we have a real problem,
>>
>>which
>>
>>>      will
>>>      only be solved if you introduce a multilingual ontology of mapped
>>>      terms
>>>      into
>>>      the equation.
>>>
>>>      The real problem, however, is how to do this dynamically, so that
>>
>>we
>>
>>>      can
>>>      annotate recorded roles with "related names from other sources"
>>
>>(e.g.
>>
>>>      record
>>>      that someone has determined, by some off-line means, that A relates
>>>      to B).
>>>
>>>      Incidentally your address info structure in section 10 has not been
>>>      suitably
>>>      internationalized. You need techniques for defining subsections of
>>>      what you
>>>      call cities (e.g. Kensington, London) and for identifying blocks
>>>      (both at
>>>      street and house level) and subunits of buildings (flats or
>>
>>suites).
>>
>>>      For
>>>      example, I have a friend in Roumania for whose address I need to
>>>      identify
>>>      the flat number, the staircase, the block on the road (unless you
>>>      call
>>>      Block
>>>      26 a name!) and the district of the town in addition to the fields
>>>      you
>>>      allow
>>>      me to define once only if I want to send him something. It looks
>>
>>like
>>
>>>      I'm
>>>      going to have to define more extensions than you do base fields,
>>
>>even
>>
>>>      though
>>>      every different Consume and Producer will have to define his own
>>
>>set
>>
>>>      of
>>>      extensions for most of these :-(
>>>
>>>      Martin Bryan
>>>      The SGML Centre, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
>>>      Phone/Fax: +44 1452 714029  E-mail: mtbryan@sgml.u-net.com
>>>
>>>      For further details about The SGML Centre visit
>>>      http://www.sgml.u-net.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      ----------------------------------------------------------------
>>>      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>
>>
>>----------------------------------------------------------------
>>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>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC