[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] Reuse in SPML
The main idea behind using DSML , SAML and SOAP in SPML was to reuse as many
existing protocol whenever possible.
This was both technical and political decision. I believe that our protocol
will gain more support in the industry if we will use existing protocol and
work.
I believe that our purpose is to create a widely used protocol. I think that
using DSML will help SPML to be more popular protocol. I think that we
should pay the toll of less elegant protocol and some what more complex
schema to achieve this goal
Yoav Kirsch
Director, Applications Development
Business Layers
-----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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC