[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] Reuse in SPML
Jeff,
You'll have to forgive me if I'm a little less familiar with the specific
responsibilites of each of the entities as defined in the PSTC use cases,
but I'm not sure that the PSP needs to understand the schema just as I
would not expect a DSMLv2 server to understand that an attribute named
ntAccountUser is used by an NT target as a user name. I may be
misinterpreting your question or the division of labour as defined by the
PSTC, but I view the target schema as the definition of a contract with the
target, and the PSP merely as the delivery vehicle to the RA.
Filtered searches are unquestionably difficult. There are two significant
entities in my outline: the subscription and the target. I'm imagining
that querying each of these would correspond to PSTC use cases 14, 16 and
18. Since there will undoubtedly be substantially more subscriptions than
targets, I was considering the availability of something like a
getAvailableTargets() method either on the PSP service or some kind of
target registry interface, that would simply return all available targets
either in an array or some sort of iterator. For subscriptions the problem
is more difficult but in practise would probably be limited to the
subscriptions for a particular entity, such as a user for example. This
could be done through a method or methods targeted at specific use cases
like use case 18 which could be satisfied by a getSubscriptionsForObject()
method that again would return an array or iterator. Since this is an
external interface, actually service is a better word, the limited use
cases specified by the PSTC seem reasonable to me and in general don't seem
to necessarily require a full-blown search language.
Your suggestions reflect the difficulty in coming up with a compromise
position between these two approaches. Without going into some detail on
what the resulting schema would look like, I'm not quite sure how well your
modified schema definition would meet my needs. I would cetainly agree
with the removal of some of the dependencies on DSML such as the
DsmlMessage that we talked about before. If my interpretation of the
intent of the use cases is correct then perhaps the DSML filter mechanism
might not be required. If that's true, and I have a feeling that you'll
disagree heartily with that suggestion, then at that point you would need
to define some mechanisms to satisfy the specific query use cases and
you're looking increasingly like the approach I am advocating.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 02/28/2003 04:55 |
| | AM |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Gearard Woods/Irvine/IBM@IBMUS |
| cc: provision@lists.oasis-open.org |
| Subject: RE: [provision] Reuse in SPML |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Gerry,
In your example, how does the PSP understand what is meant by the
meta-data defined in NT_40_Jerusalem? How does it know what the username
element means? Obvious for simple cases a mapping could be defined, but
since you propose that this be open ended, how would the semantics
represented by the schema be understood? How would filtered searches be
supported?
Let me suggest a compromise solution. What if we did the following?
1) We could remove the dependency to the DSML schema by replicating the
parts of it we use (attributes, modifications, and filters).
2) Currently attributes are name/multi-valued pairs. We could extend
them so that the value elements where not limited to simple values, but
could be optionally sub-elements.
3) We could then modify the meta-data mechanism (schema schema) to use
XSD to define the syntax of attributes that are not simple values.
4) We would then have to figure out how to make a search filter that
could handle the attributes that are not simple values.
If we made these changes, would that make the specification acceptable
to you? Are there any changes, other than starting from scratch that
would?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Friday, February 28, 2003 12:37 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML
Jeff,
That's what I used to form my little example in a previous e-mail:
...
<AttributeDefinition xmlns="urn:oasis:names:tc:SPML:1:0:schema"
name="accountStatus" multivalued="false" type="xsd:string"/>
...
I think this conforms to your schema and of course the type is
equivalent
to the LDAP notion of syntax, my apologies. I apologize too for
overlooking the SchemaRequest and SchemaResponse classes hidden down
there
at the end of the "schema" document, I was expecting to see something
like
that in the "core" document.
As I'm sure you know, the separation of schema from the messaging
interface
is common when working with WSDL. Type definitions are often imported
into
the messaging definition using WSDL's import mechanism, for all but the
simplest types. So I'm not saying that I want to define the schema in
the
WSDL at all. To get a more concrete feel for the approach that I would
like to have seen in SPML, let me sketch a fictitious provisioning
schema
and WSDL based on the ideas that the PSTC has outlined in the Use Cases.
Imagine that a PSO or PSO-ID, is represented by an artifact that I'll
call
a subscription:
...
<element name="ProvisioningServiceSubscription">
<complexType name="ProvisioningServiceSubscriptionType">
<sequence>
<element name="identifier"
ref="tns:ProvisioningIdentifier" minOccurs="1" maxOccurs="1"/>
<element name="target"
ref="tns:ProvisioningTarget"
maxOccurs="1"/>
<element name="state"
type="tns:ProvisioningSubscriptionState" maxOccurs="1"/>
<element name="lifecycle"
type="tns:ProvisioningSubscriptionLifecycle" maxOccurs="unbounded"/>
<element name="children"
ref="tns:ProvisioningServiceSubscription" maxOccurs="unbounded"/>
<any namespace="##other"
id="subscriptionParameters" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
...
The subscription has an identifier, the PSO-ID in PSTC terms, a target
which defines the resource or PST, an enumerated state, a lifecycle
specifier that determines the allowed periods of activity for the
subscription, children which form a Composite structure, and then any
additional data required for this specific subscription. This, and its
associated definitions reside in a file located at "
http://provisioning.is.us/spml.xsd"; for want of a better name. The
(abbreviated) WSDL file, call it psp.wsdl, would then define my
interface
using these types:
<?xml version="1.0" encoding="utf-8"?>
<definitions ...
xmlns:spml="urn:oasis:names:tc:SPML:0.1:provisioning:spml">
...
<import namespace="urn:oasis:names:tc:SPML:0.1:spml" location="
http://provisioning.is.us/spml.xsd"/>
...
<message name="createSubscriptionRequest">
<part name="subscription"
element="spml:ProvisioningServiceSubscription"/>
</message>
<message name="createSubscriptionResponse">
<part name="requestId" type="xsd:string"/>
<part name="status" element="spml:ProvisioningServiceStatus"/>
<part name="subscription"
element="spml:ProvisioningServiceSubscription"/>
</message>
...
<portType name="ProvisioningServicePoint">
<operation name="createSubscription">
<input message="tns:createSubscriptionRequest"/>
<output message="tns:createSubscriptionResponse"/>
</operation>
...
</portType>
...
And so on. This is the kind of thing I'm talking about when I refer to
a
provisioning-centric approach. Of course this is only part of the
problem
and there is still the thorny issue of target schema. Fotr that it
might
be possible to define the ProvisioningTarget and its schema as something
like:
...
<complexType name="ProvisioningTargetSchema">
<sequence>
<any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="ProvisioningTarget">
<complexType name="ProvisioningTargetType">
<sequence>
<element name="identifier"
type="tns:ProvisioningIdentifier" minOccurs="1" maxOccurs="1"/>
<element name="schema"
type="tns:ProvisioningTargetSchema" minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
</element>
...
Allowing the schema to contain pretty much anything. Of course, in most
cases we would use XML-Schema because that what our tools understand.
So
an instance might look roughly like:
...
<ProvisioningTarget
xmlns="urn:oasis:names:tc:SPML:0.1:provisioning:spml"
... >
<identifier name="NT_40_Jerusalem"/>
<schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="username" type="xsd:string"/>
...
</xsd:sequence>
</xsd:complexType>
</schema>
</ProvisioningTarget>
...
Obviously this is just a sketch but it serves to illustrate where my
thinking is. This kind of approach allows any kind of complex type
that
XML-Schema can express to be accommodated.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 02/27/2003 07:40 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: <provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Reuse in SPML
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
The current SPML Schema approach does support defining attribute syntax.
In
the draft_pstc_schema_schema_03.xsd the element for the
AttributeDefinition
is defined as:
<xsd:complexType name="AttributeDefinition">
<xsd:sequence>
<xsd:element name="properties" type="Properties" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="name" type="dsml:AttributeDescriptionValue"
use="required"/>
<xsd:attribute name="description" type="xsd:string" use="optional"/>
<xsd:attribute name="multivalued" type="xsd:boolean" use="optional"
default="false"/>
<xsd:attribute name="type" type="xsd:string" use="optional"
default="xsd:string"/>
</xsd:complexType>
Where the attribute named type represents the syntax. The normative
values
for this is the xsd strings representing attributes types (sxd:string,
xsd:boolean, etc).
We did discuss ways of making the AttributeDefinition element more
expressive, but no one has put forth any proposals on how to do it. If
this
was more expressive, perhaps even using more of the xml schema
capabilities, would that make the proposed spec more acceptable to you?
As far as finding the schema, there is no root DSE required. The
starting
point would be the web service URL itself. If the url is known (which
obviously it has to be), then all the schemas for an SPML service would
be
returned in response to a SchemaRequest message. If a specific schema is
needed it can be retrieved by specifying the schema identifier. We are
not
following the LDAP V3 approach of returning schema in response to a
search.
You mentions other specification that work as you propose. Which ones
are
they? I think if I could see some concrete examples I would understand
your
concerns better. The SPML SOAP/HTTP Binding will consist of a
combination
of an WSDL description and an XML Schema defintion, with associated
normative specifications. The solution you are proposing would be the
same,
but it seems that you want to define the provisioning meta-data totally
in
the WSDL for a specific provisioning service type, rather than in a
protocol specific meta-data mechanism as we have done in SPML. I would
be
interested in seeing some examples of that approach, as I am not aware
of
any.
Jeff B.
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thu 2/27/2003 3:04 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML
Jeff,
It sounds to me like you didn't read my response thoroughly
and are
assuming that I haven't read the SPML schema documents.
Let
me rephrase my
objection. Even if there is an agreed upon standard schema
as
there is for
LDAP, you are still constrained by the expressive
limitations
of the schema
language. This is as true for SPML schema as it is for
LDAP.
My example,
you didn't seem to notice, was stated in SPML schema, not
LDAP schema - I
know the difference even though it is slight. Since we're
on
the subject,
SPML even loses some of the expressiveness of LDAP schema
in
that there
seems to be no way to specify syntax or matching rules.
Not
that I'm in
love with those concepts because, again, they are defined
in
documents that
must be ferreted out (or known about beforehand) rather
than
being
available for immediate interpretation by tools.
As far as a root DSE and controls go, I would argue that if
there is no way
for a tool to determine any metadata about an element of
the
protocol then
it doesn't belong there. I would ask the same question
about
determining
the schema for an entity in the absence of a root DSE or
the
requirement
for a subschemasubentry attribute. Does SPML mandate the
use
of
subschemasubentry or is SPML schema simply declarative and
how
you go about
getting it outside the scope of the spec?
As I'm sure you know, we also make extensive use of
directory
based
protocols for provisioning and I don't see the need to
restate
that or
OpenNetwork's commitment to DSMLv2. What would be more
interesting to me
would be for you to assure me that you have never run into
any
limitations
in your use of DSML or LDAP: No XML documents as attribute
values; No
Java serialized objects as attribute values because you
were
just stuck and
there was no other way.
You seem to be completely missing my point about WSDL. and
I
can certainly
be more specific, but I also like the direction some other
specifications
have gone with their definition of the basic message schema
in
XML-Schema
and then a separate binding into WSDL. That's exactly what
I
would like to
see. Those specifications have targeted their messages to
the
domain and
publish the interface using WSDL. To state that you are
following that lead
is to ignore the fact that you are repackaging a directory
protocol which,
to repeat myself again, is the brunt of my objection.
Obviously SPML must go beyond a lot of the existing simple
services out
there because it must allow the definition of schema. This
is
another
conerstone of my argument and you cannot dismiss it by
claiming that
someone could define a class with a particular attribute
with
a particular
syntax if they want a suspendable account or some other
feature. Sorry but
that doesn't jive with your arguments about semantics and
it
doesn't
satisfy my need for a provisioning centric API with en
expressive schema
language.
The questions I'm asking will be asked by others when you
unveil this
proposal to the world at large. To be honest, the
dismissive
"don't worry
about it, it will easily work" platitude is OK for me but
doesn't win
support when real problems have to be confronted and
solved.
As I have
said before, we should be on the same side.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 02/27/2003 11:15 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: provision@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [provision] Reuse in SPML
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I apologize for not being clear on this, but root DSEs are
not
part of
SPML. Although the control element is allowed as past of
the
DSMLMessage
definition, this is outside of the scope of SPML. If that
bothers you we
could easily remove the reuse of the DSMLMessage type.
Would
you like me
to propose that at the next meeting? It would have no
impact
on the spec
to do that. Also, we do not use LDAP Schema in SPML. There
is
an SPML
Schema mechanism.
I'm sorry, but I still don't see the value in throwing away
what we have
so far to start from scratch along a path that may never
yield
any
useful results. I would still rather go with something I
know
will work.
Could you do provisioning with just DSML v2? Absolutely,
and
OpenNetwork
Technologies will continue to support that in addition to
SPML. In fact
my original "SPML based on DSML v2" proposal was much
closer
to DSML v2
than SPML is today. As committee we added the additional
functionality
to support areas that DSML v2 was deemed insufficient.
The SPML effort is not intended to be limited to SOAP/HTTP.
That is one
of two supported bindings (the other being the File
Binding)
in the 1.0
spec. There will probably be other bindings defined post
1.0.
If we
build the spec around WSDL, then we are limited to the
SOAP/HTTP
binding. I don't find that acceptable.
If you believe that WSDL/XML Schema is the right solution,
go
ahead and
use it. The PS TC has published a XML Schema for SPML and
will
likely
publish a WSDL definition as part of the SOAP/HTTP Binding.
Note that the approach we are taking for SPML of defining
the
protocol
in the document body schema (with supporting normative
restrictions)
rather than as WSDL/XML Schema is the same approach being
taken by DSML,
SAML, XKMS, OMI, UDDI, etc. Are there any standards bodies
taking the
approach of defining the protocol in terms of WSDL/XML
Schema
only? It
is an interesting idea, but it seems risky to me at this
stage.
The intention is that WS-Security be used with the SPML
SOAP/HTTP
Binding. That is why we explicitly avoided dealing with
authentication
issues in that binding. There will be recommendations
around
WS-Security
in the SOAP/HTTP Bindings document.
The SPML Batch Request is not intended to imply
transactions,
although
an implementer could certainly make them transactional.
Instead it is
intended to support the asynchronous request/response
model,
something
that DSML v2 lacked.
Now for the suspend/restore example. The PSTC (or someone
else) could
define a standard schema that defines an object class for
accounts that
can be suspended. For this example, call it
suspendableAccount. This
class would define an accountStatus attribute. Any PST that
supports
suspendable accounts would add this object class and a
parent
class of
the PSTs object class.
The PSP, when trying to suspend an account would look to
see
of the
account type had suspendableAccount as a parent class. If
it
did, it
would use the accountStatus attribute.
This is just speculation, so don't get hung up on the
details.
I'm not
sure how this problem will actually be solved, but it is
easily
solvable.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, February 27, 2003 12:30 PM
To: Jeff Bohren
Cc: Conrad Agramont; provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML
Jeff,
You'll have to tell me how LDAP schema conveys the concept
of
suspending
an
account using a specific value of an arbitrary attribute
like
accountStatus. Let me try. An LDAP (SPML) schema for
accountStatus
might
look roughly like:
...
<AttributeDefinition
xmlns="urn:oasis:names:tc:SPML:1:0:schema"
name="accountStatus" multivalued="false"
type="xsd:string"/>
...
OK, so I can look at at this document and see that there is
a
single-valued
attribute called accountStatus that is a string. Yesterday
we
were
talking
about semantic predictability, this tells me nothing about
semantics and
just a little about syntax. I wouldn't call that
successful.
Compare
instead what some kind of service level API definition
might
look like,
were we instead to use XML-shema:
...
<xsd:attribute name="accountStatus" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="supend"/>
<xsd:enumeration value="restore"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
...
Now I'm not suggesting that this is a real part of some
API,
it's just
an
example - I could just as easily have concocted a WSDL API
that included
a
suspend method. My point is that already, to a human
reader,
this
conveys
some meaning. The semantics of this attribute leap out of
the
page. In
addition I have tools that can generate classes from this,
in
many
langauges, that I can use directly and that now model the
domain. You
can
throw examples like SNMP around until we're all blue in the
face, and
counter examples like CIM but you know as well as I do that
the success
or
failure of a given specification relies heavily on
adoption,
momemtum
and,
dare I say, fashion as much as anything else. I'm not
saying
that's
what
happened in the cases you mention but if you really want
some
examples
why
not look at WSDL? Is Microsoft barking up the wrong tree
with
.Net I
wonder? IBM's emphasis on Web Services must be
misdirected.
What about
the explosive growth of Portal servers? What about the body
of
work that
is
growing up around these standards such as WS-Security,
WSTransactions?
The
list goes on. It's my belief that the SPML can ride this
wave
and be
counted or look backwards to SNMP and LDAP, use the limited
schema
facilities they have to offer, and be regarded as difficult
and
outdated.
Why should I have to use different tools and switch
cognitive
gears when
I'm faced with dealing with SPML when I'm merrily
integrating
disparate
systems that rely on WSDL/XML-Schema?
You keep referring to the simple, proven model that works
and
yet there
are
so many things, other than schema, carried over from
LDAP/DSML
into the
current proposal that are not simple nor have they proven
to
be useful
to
provisioning. You never answered my question about server
requirements
for
a root DSE. How will I discover what controls are
supported
by a PSP?
Why
should I have to? Even if I do, what does a control mean?
How do I get
even a syntactic description of one, read an RFC? The
semantic
behaviour
of
batch requests in SPML differs from DSMLv2 as far as I can
tell because
you
are implying transactional semantics in a batch request
which,
correct
me
if I'm worng, is not part of DSMLv2.
If acceptance is what you are after then a specification
that
fills the
vacuum for a provisioning API is what we should be aiming
for.
If SPML
differs only slightly from DSMLv2, and raises more
questions
about
inappropriate directory type behaviour and limited schema,
why
should I
adopt it in favour of DSMLv2?
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 02/27/2003 05:13 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: Conrad Agramont
<conrada@microsoft.com>,
provision@lists.oasis-open.org
|
| Subject: RE: [provision] Reuse in SPML
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
There is a very easy way to convey the meaning of concepts
like
accountStatus. It can be done through the use of standard
schemas.
Although LDAP has successfully used that concept, the best
example I
have for that is SNMP. SNMP has a simple protocol that
defines
operations and data types. True interoperability is not
achieved in SNMP
via the protocol but through the use of standard schemas
that
define
what the semantics of protocol for specific services.
This approach has led SNMP to achieve the highest level of
adoption and
interoperability of any management protocol while it's more
fully
feature competitors such as CMIP are dead.
By counter example, the WEBM/CIM specification from the
DMTF
does model
real world objects. Although there are a lot of things I
like
about
WEBM, and it has been implemented by MS and a few others,
it
has not
achieved widespread industry adoption. And I don't expect
it
to do so
anytime soon. WEBM is everything you describe, but no one
wants to
implement it.
I would rather stick with a simple proven model that we
know
can work
rather than try to invent a new concept that may never be
accepted. Sure
there are limitations, but by using proven model we know
what
those
limitations are and can plan accordingly. If we start from
scratch, we
most likely won't know what the limitations are until it is
too late.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, February 27, 2003 2:35 AM
To: Jeff Bohren
Cc: Conrad Agramont; provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML
Jeff,
I know you've worked hard on this spec and I'm sorry to
drop
in at the
last
minute only to be criticial. After all, the window for
submissions came
and went and there was a resounding silence from our
corner.
In the end
though, competitive pressures aside, I think we're all on
the
same side.
We all want something that will work, as you point out, and
beyond that
for
my part, I want something that fits in with the tools and
technologies
that
I anticipate I will be using over the next few years. I
would
prefer
that
it be as elegant as is possible in a design by committee
scenario, as
clean
and simple as possible so that it can be understood and
implemented, and
appropriate to the domain as a service interface should be.
There are many people on the committee I'm sure who have
direct
practical
experience with directory based protocols in provisioning.
My
experience
with them in a provisioning context is what leads me to
conclude that
it's
more by chance and, as Conrad said, for lack of something
better that we
use them at all. Of course they work. We're engineers, we
make things
work even if it takes pieces of string and double sided
tape
but that's
not
the point. The point is that we have the opportunity, the
tools, the
technology and the market interest to make something
better.
Directories
like X.500 were created way back in the big iron days to
solve
a
specific
problem. The fact is that it wasn't a provisioning
problem,
it was a
directory problem. Provisioning is becoming a term that
people
recognize
more and more as something that is distinct, and something
that has
growing
importance. Building a management or provisioning
interface
into
software
is a pivotal part of the product's ability to integrate
into
your
enterprise and thereby part of its appeal and value. Of
course XML is
seen
as the answer to all integration problems but we can be
more
specific:
WSDL and XML-Schema are here to stay because there is huge
momentum
behind
them in the form of your second point, industry acceptance,
which
translates into toolkits, and a growing set of
interoperable
and
comlementary specifications that everyone can take
advantage
of to make
their job easier and their systems more robust.
I like your semantic predictability argument despite its
cognitive
dissonance. All joking aside, you seem to be assuming that
it's not
possible to create an interface that exhibits an equal
measure
of
predictability on an equally predictable model. In fact, I
would argue
that a more predictable model and interface could be
created
when the
the
entities involved reflect real world objects rather than a
set
of
attributes and values, and operations that reflect
provisioning
operations
rather than add, delete, modify. Take a specific problem
common in
provisioning systems: suspending an account. I know some
provisioning
systems that use an attribute modification (say, the
setting
of an
attribute to some value, e.g. accountStatus = "1") to
effect
this
operation. In the world of LDAP and LDAP schema, there is
no
way to
communicate this semantic meaning and the current SPML will
continue
that
tradition. Where is predictability when I buy multiple
products with
reams
of documentation and have to wade through it all to
discover
how to
suspend
an account? You can see where I'm going. Comprehensive
schema,
self-describing systems, and APIs that make sense to humans
are all the
rage for good reason and I think you've hit the nail on the
head - it's
semantic predictability.
I'm not suggesting that SPML be a rehash of WSDL or consist
exclusively
of
extended operations, that wouldn't do either. But there is
a
definite
need
that we're all feeling for a usable provisioning API that
will
fit
snugly
with the Web Services we're using and creating and is all
about
provisioning. The question that we're being asked as
practitioners in
the
field is what should that look like? X.500 wouldn't be my
answer.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 02/26/2003 07:08 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Conrad Agramont
<conrada@microsoft.com>,
Gearard
Woods/Irvine/IBM@IBMUS
|
| cc: provision@lists.oasis-open.org
|
| Subject: RE: [provision] Reuse in SPML
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
I personally feel that everyones views should be considered
regardless
of
how much time they have spent working on the TC, so long as
they are
serious contributions. If there are a number of people that
feel that we
have accomplished so far is not the right solution, we
should
take the
time
to work this out. Even though I have put a lot of work into
this, I
don't
want to put forth a specification that only gets adopted by
two or three
companies. Of course the price for this is to miss the
oportunity for a
Burton Catalyst Interop event.
Darran, should we add time to Monday's agenda to talk about
Gerry and
Conrads concerns?
Having said that, let me outline my reasons that I think we
do
have the
right solution. It may not be the best solution, but I
doubt
we as a
committee would ever find the best solution anyway.
Committees
never
find
the best solution for anything. Anyway, here is my case for
our current
approach:
Practicality - I know from personal experience that the
DSML/LDAP model
works for provisioning. It is as simple as that. It works.
We
can invent
lots alternative solutions, but if we built a spec around
one
of them,
how
confident would we be that after the spec is ratified, it
would work in
practice? We currently have a model that has been
demostrated
to work in
practice, not just in theory.
Industry Acceptance - forget about DSML for the moment. The
concept of
representing accounts as name/value pairs is widely
accepted
among the
types of resource that need to be provisioned. JNDI has
achieved
widespread
usage, and not just for LDAP. LDAP is being adopted at an
astonishing
rate.
MS seems to be slowly moving all of it's major server
identity
stores to
AD
(at least as an option). Most commercial IT systems now
support LDAP as
an
option. Most of the commercial provisioning systems are
either
LDAP
enabled, support LDAP in some fashion, leverage
meta-directories, or
have a
virtual directory front end. DSML itself is starting to
gain
traction,
with
a JNDI SP available from Sun, a DSML gateway for AD from
MS, a
DSML
gateway
for eDirectory from Novell, announced DSML support in MMS
3.0,
and of
course the DSML based provisioning web service from
OpenNetwork
Technologies. And then there are the other XML provisioning
specifications
that are LDAP related, such as the Access360 DAML spec and
the
Novell
DirXML spec.
Theoretical Advantages - one way to look at provisioning is
as
a
federated
namespace problem. A typical provisioning system maintains
an
internal
model of the provisioning namespace and synchronizes that
namespace with
the external systems. The LDAP model does have inherent
limitations, but
those limitations are also it's strength. Because there are
limits to
how
the namespace can be represented and what operations are
available,
there
is semantic predictability of the operations. When a PSP
makes
an add,
modify, or delete request to a PST, there is predictability
as
to how
that
PST will behave. The PSP should be able to make reasonble
assumptions
about the post-operation state of the PST namespace without
having to do
a
reconciliation. This is why I have tried to downplay the
extended
requests.
By thier very nature the do not have sementic
predictability.
You could
create a provisioning system that could use any PST web
service that had
a
WSDL definition, but such flexibility would make
interoperability very
difficult. Likewise doing everything through extended
requests
will have
the same result.
Mature Proven Track Record - SPML is derived from DSML v2,
which is
derived
from DSML v1, which is derived fro LDAP, which is a
derived
from X.500.
X.500 and LDAP both have a long successful track record.
Simply put,
they
work. They work well.
Finally, I would like to pose the question: What do we gain
by
not using
the DSML/LDAP model?
Jeff Bohren
-----Original Message-----
From: Conrad Agramont [mailto:conrada@microsoft.com]
Sent: Wed 2/26/2003 6:02 PM
To: Gearard Woods; Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML
I have also been very absent from much of
these
conversations
and much
of it has to do with the discussion in this
thread.
I don't think that the requirement of matching
the model to
DSML closely
for mindshare reasons is justified for what
needs
to be
done.
As I've
stated before in previous meeting, we should
be
focused on
providing a
model that fits the need directly and not
derail
the
innovation by
trying to align too closely another standard
that
is not
offering a
great deal of leverage.
I also understand that this type of
functionality
is
working
within
OpenNetwork's product today, but does this
mean
that it's
the
right
model that the entire industry should be
moving
towards?
OpenNetwork's
decision to leverage DSML could be contributed
to
the lack
of
an SPML
model being readily available. So by
providing
an SPML
model
that looks
like DSML might be great for OpenNetwork or
anyone else
that
has done
the same, but for the future of SPML is this
the
right way
to
go?
Now this may be a bit late in the game, but I
agree with
Gearard that we
should really put a little bit more time to
decide if this
is
the model
that we want presented to the industry as our
recommendation
for a
provisioning schema.
Thanks,
Conrad Agramont
Program Manager
Microsoft Corporation
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Monday, February 24, 2003 10:46 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Thanks for the reply Jeff and of course I
agree
with you,
directories
are
well understood and there are plenty of
examples
of
provisioning systems
that take advantage of directory-centric
protocols such as
DSML (and
DAML
for that matter). I don't want to turn this
into
a big
debate
when you
guys are so close to finalising something but
as
a
potential
user/implementor of SPML, I want to put in my
two
cents in
an
attempt to
make sure that we don't end up suffering from
the
shortcomings
of
directory-centric protocols that we, and you,
have
tolerated
for so
long.
As I said, I can understand the argument for
filters, and
DsmlMessages
are
minimal (an argument against coupling I
thought,
and what
about those
controls?). What pains me more is the schema
limitations
of
LDAP,
particularly when you want to talk about more
complex
entities
than
attributes and values. I know that the
committee
understands
these
limitations of directories - the enhanced
schema
for
extended
operations
reflects that. In my mind though, the ability
to
specify
operations is
only one side of the coin (and I would argue
that
there are
more
tool-friendly ways of doing it), complex types
is
the
other.
You'll have to forgive me but I don't buy the
midshare
argument for
anyone
but the most high level marketing types.
There
are plenty
of
examples,
and
for this you need look no farther than the
wealth
of Java
APIs, where
developers are more than happy to adopt
unfamiliar concepts
when the
ideas
match the problem, or at least model it
adequately. And I
don't have to
point out to this group that the world is
tooling
up
rapidly
for WSDL
and
XML-Schema based Web Services. Portal servers
that
understand
WSDL as
their essential lingua franca are being
adopted
like hot
cakes
and those
just require an appropriate API, not a
familiar
one. I'm
not
being a
complete nay-sayer here, I think that it could
be
easy to
transition to
this kind of approach if there is a will and
we
bear it in
mind before
we
commit anything to stone.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 02/24/2003 06:32 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To:
provision@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [provision] Reuse in
SPML
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
From the OpenNetwork Technology perspective,
the
DSML
approach
is
working
quite nicely. We already have a provisioning
web
service
(PST)
based on
DSML (
http://www.opennetwork.com/solutions/standards/dotnetconnected/).
It
will be a natural progression to extend this
to
support
SPML
as well.
Although DSMLMessage is extended, it is really
not core to
the
SPML
concepts and could easily be replaced. What is
leveraged in
SPML is:
Search Filters
Attributes
Modifications
That may not seem like a lot, but the cost is
very low, so
why
not? We
coudl very easily replicate the parts of DSML
we
are using
and
no depend
on
it any more, but I don't see any tangible
benefit
in doing
so.
Of course the real benefit is not is saving a
few
element
definitions,
but
in the mind share that is gained by explaining
Provisioning
in
terms of
a
model than many already understand. The
concept
of
representing
provisioned
using LDAP like constructs seems to be a good
fit
for most
provisioning
systems.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Mon 2/24/2003 5:29 PM
To:
provision@lists.oasis-open.org
Cc:
Subject: [provision] Reuse in
SPML
I've been absent from the
discussion
for a
while
so I
apologise if this is
an old chestnut but following on
the
heels of
Matthias'
question about
batch operations in SPML, I'd
like
to ask the
committee if
the
advantages
of maintaining the dependency on
DSML are
really
working
out?
I can
certainly understand the argument
for the use
of
the DSML
Filter, athough
that could be adressed if
necessary,
but I'm
more
curious
about the use of
DsmlMessages. As everyone knows,
DsmlMessages
really
encapsulate a set of
controls and an optional request
ID.
This is
such a
trivial
class and all
of the SPML messages are derived
from it so it
seems to me
that SPML is
building in a dependency for very
little gain
in
this case.
This also
raises the issue of discovery of
supported
controls, as
with
LDAP/DSML. In
LDAP of course, the specification
calls for
the
server to
provide a root
DSE where vendors generally
publish
the set of
supported
controls and
extensions. I notice that the
SPML
schema
includes the
ability to define
extended operations but I don't
see
a place
for
controls.
I've been trying to catch up on
the
minutes of
the meetings
that I've
missed but I don't see any
discussion so far
of
the use of
yet
another
schema language. Propagating an
LDAP style
schema language
when the
specification is written in a
more
expressive
language,
XML-Schema, seems a
little anachronistic to me. I'm
sure there is
a
reason,
and
I'm sure there
was discussion on the subject,
but
it appears
on
the
surface
that a lot of
time could be saved by re-using
XML-Schema
rather
that
re-defining another
schema langauge in XML-Schema.
This
leads to
my
final
question on
appropriate re-use and that is
the
definition
of
extended
operations in a
world where considerable effort
and
tool
support
has been
put
into the
WSDL. For that matter, it seems
likely to me
that the SPML
might be
frequently used within an WSDL
context. In
that
case, the
batch request
and response mechanisms adopted
from
DSML
don't
seem very
useful and
extended operations would more
naturally be
defined using
WSDL's
capabilities.
Again, apologies if I'm covering
old
ground,
Gerry
----------------------------------------------------------------
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>
----------------------------------------------------------------
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