[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Roles
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC