OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [provision] Reuse in SPML

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.

|         |           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

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

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
             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
             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 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
             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

             Again, apologies if I'm covering old ground,

             To subscribe or unsubscribe from this elist use the
             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