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:
> > 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:
>
> 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:]
> Sent: 26 November 2002 12:52
> To: Martin Bryan
> Cc:
> 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"
>
> <[email protected] 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:
>
> 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>
