[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC