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