[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