[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM
Darran, I am interested in seeing Jeff's proposal because I'm a big advocate of having a "straw man" to act as a focal point for discussion. At the risk of testing your patience by repeating myself one too many times, I'd like to reiterate that there are actually three areas of the spec that I think warrant further work for 2.0: the schema, data model and operational model. In an earlier message, Jeff raised the point that we have not really settled on a set of requirements for 2.0. Regrettably I couldn't make the last call so this might have been discussed then, but perhaps in parallel with Jeff's proposal we can put aside some time on the next call to review the requirements with a view to firming them up as soon as possible. Although I'm not sure how we would structure the topic, it might also be useful to talk some more about Web Services and their relationship to the SPML. I might need to first clarify what I mean when I use the terms Web Services based/compatible/friendly/practices. This comes down to a few main aspects in my view. The first is that the spec use Web Services standards in its definition. Specifically, this means to me that the spec use WSDL as the primary mechanism to describe the operational interface, and XML Schema to describe the interface object model. Conformance with the spec would mean that implementors support an identified WSDL interface. This might also extend to the incorporation of, or at least a statment of position on, the spec's relationship to other WS standards such as WS-Security for example. The second is that the interface be compatible with Web Services tools. Obviously this is dependant on the first point since the bulk of Web Services tools seem to have settled on WSDL and XML Schema. In practice, it should be possible to take the WSDL and schemas defined by the PSTC and run them through off-the-shelf tools, such as those provided by WebSphere and .NET, without any difficulty. Finally, the specification should not offer any impediment to interoperating with, or provisioning to, Web Services. I imagine the SPML interface finding a lot of use as a generic way to provision other Web Services. If this view is proven correct, then the SPML will need to transport the schema and any XML data required by the target Web Services. This last point has been one of the issues in the recent exchanges between Jeff and myself. Although Jeff's proposal doesn't require this, transformations of the schema or data in this scenario would generally be unacceptable, particularly where schema constraints are lost or there is a requirement that state be maintained to manage the communication between the SPML client and the target WS. As part of this I've also been advocating the use of XML Schema as the target schema language to facilitate its use with available WS tools. The issue of practices is a little more hazy but in general I think it encompasses the points I've just outlined and the notion that we should not reinvent the wheel when there are other standards that adequately provide the functionality we need. Jeff and myself have discussed identifiers a little already. Another useful practice would be to follow interoperability guidlelines such as those published by the WS-I organization. The advantages of this emphasis are obvious: better interoperability, ease of development, ease of use, reduced learning curve, more seamless compatibility with runtime systems such as management systems, intermediary systems, UDDI repositories and so on. In addition we get to build on, or allow users to take advantage of, other WS standards to build a complete solution. Gerry |---------+----------------------------> | | "Darran Rolls" | | | <Darran.Rolls@wav| | | eset.com> | | | | | | 12/04/2003 06:31 | | | AM | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >------------------------------------------------------------------------------------------------------------------------------| Jeff/Gerry It sounds like we have a good waypoint here. If we can converge our efforts around a set of changes that retain the current SPML request/response model, but extends current verbs to support the WS-Provisioning data model, would you both agree that we have something that warrants close inspection? Jeff, if you are taking the lead on such a proposal, I'd like to propose we set an agenda item this Monday to discuss with Gerry and the rest of the team what this might look like? -darran From: Jeff Bohren [mailto:jbohren@opennetwork.com] Sent: Wed 12/3/2003 9:35 AM To: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM Gerry, I am sorry that you feel that SPML 1.0 spec was railroaded through. The SPML 1.0 effort took almost 2 years to reach an approved specification. The effort include individuals from previous standardization efforts, XRPM, ADPr, and ITML. The direction for the current spec was developed with the participation and approval of IBM (although via a different individual representative). When IBM changed direction and decided that the effort needed to start over, the effort was delayed by several months while the issue was discussed. IBM was given ample time to present it's case. A committee vote was ultimately taken and the IBM proposal to start over was rejected. The spec then went through the proper OASIS review cycles and was approved first by the TC and then by the required 15% of OASIS member organizations. To say that this was "railroaded" is an unfair characterization. You keep making the straw man argument that we "decided against a web services approach". You apparently make this case based on the fact that the provisioning meta-data is represented in a form other than XSD. Are you claiming that any protocol that does not XSD to represent meta-data is not taking a "web services approach"? If you want to argue that the current approach is not appropriate for the provisioning domain, that is legitimate debate. To argue that it is not "web service based" is not. The current SPML data model seems to be the biggest point of contention. It seems that the other issues are more tractable. If could put together a compromise proposal where the current SPML spec was expanded to support both the current data model and a data model similar to what is proposed in WS-Provisioning, would that be acceptable? This would still use the current SPML request/response model, but each of the verbs (add, mod, del, get schema) would be expanded to support both the current model and the model proposed in WS-Provisioning. This would support the open ended data model that you want as well as the backwards compatibility that I want. Would IBM be willing, in theory at least, to support that as a compromise solution? Jeff Bohren Product Architect OpenNetwork Technologies, Inc Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval. -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wednesday, December 03, 2003 2:18 AM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM Jeff, We've had all these arguments before and we could go back and forth for days on this. The bottom line is that I feel the SPML 1.0 was railroaded through for marketing purposes to make Catalyst. The official argument at the time against a Web Services approach was that the committee would lose both credibility and an investment in work already done. You argued vigorously, almost violently, against what we were trying to propose because, you said, directories are proven and our approach wasn't. Now here we are again, there is too much investment in the current path and directories are proven. I'll re-iterate my previous high-level arguments for the record: - The SPML should interoperate seamlessly with Web Services - The SPML should itself take advantage of, and be implemented using, accepted Web Services standards - The SPML should offer a Provisioniong model, not a directory model. This point is very relevant at this juncture because had the SPML 1.0 offered a provisioning foundation we would now be discussing what a richer provisioning model would look like rather than how we might cram XML Schema and XML data into a directory protocol. These things seem self-evident, just as the creation and refinement of another directory protocol seems redundant. Your roundup of attribute/value protocols and products makes it clear that there are plenty already but fails to mention that SPML is, in fact, crippled as compared to the directory protocol is is based on, DSMLv2. Your recent e-mail on the search limitations indicate that you fully understand this. The roundup also fails to acknowledge that directory vendors are putting a lot of thought into how to get around the very problems we are discussing, initiatives such as XED illustrate this. But here is a protocol hot off the press that has all of the traditional directory limitations and more built right in from the start. You'll forgive me if I don't consider the SPML1.0 to be an appropriate foundation for the future of provisioning interfaces. It's a good reflection of the past though, I'll give you that. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 12/02/2003 05:53 | | | PM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, I agree that we should be willing to consider all options for SPML 2.0. I would be willing to consider just about anything including a total rewrite if that is what is required to meet the requirements for 2.0. But I am not going to support a total rewrite if the requirements can be met with an approach that is backwards comatible with the current spec. Of course we have not finalized the requirements so that decision can not be made yet. At highest level the SPML 1.0 spec is based around the concept that the provisioning data is represented as a collection of attribute/values rather than arbitrary XML. This is the approach taken by SAML as well as SPML. It is also the approach taken by many of the currently provisioning products in the market place. Many workflow, EAI, and BPA products use this approach as well. And of course it is also how all directory, meta-directory, and virtual-directory products work. Given that, I don't think it is reasonable to characterize that approach as "crippled" or "worthless". My suggested compromise for SPML 2.0 is that the provisioning data be represented as a collection of attribute/values plus arbitrary XML where appropriate. Under this approach provisioning target developers are free to use as much as needed from either model. People who already have provisioning targets (as we do) don't have to be impacted. This approach is not perfect, as compromises seldom are. I have a hard time believing that not being able to represent provision schema solely through XSD means that the spec has to be rewritten. It seems that there should be a compromise somewhere in between. If not the one I am suggesting, then perhaps another one. Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Tue 12/2/2003 6:21 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM Jeff, You know the history of this debate as well as I do, including the rush to demo at Catalyst in the face of the strenuous objections of both ourselves and Microsoft. Now you are using exactly the same arguments as you used then. We have committed to try to work with the committee as part of the SPML 2.0 effort but if we are not to debate the merits of different approaches now then there is no debate. I'd like to point out too that a radical departure from an earlier approach is not unprecedented - an example close to your heart would be the fact that DSMLv2 is obviously a far cry from DSMLv1. I'm not saying that WS-Provisioning does not require that a client retrieve the schema. What I'm saying is that it doesn't get in the way by imposing a proprietary schema language. If you are using XML Schema then you get XML Schema, not XML Schema shoehorned into another schema language. In terms of the respect that SPML 1.0 deserves, in my book that's something that results from being tested and implemented and found to be thorough, robust and appropriate. As you know we will not be implementing it. In terms of the utility that it represents, in any large scale application, which the interop demo was not, the limitations of the spec are crippling. It's encouraging to see that you recognize that there is merely "some" level of interoparability because to claim interoperability for a demo in a highly controlled environment with 10 simple attributes would be overstating the case. If the committee is to try to build a provisioning standard rather than another directory protocol, then it should not be built on the SPML 1.0 schema language, simple as that. If you are prepared to commit wholeheartedly to the use of XML Schema then let's dispense with the SPML schema language altogether. Sure, make it backward compatible but with SPML 2.0 as a superset, not as a dependant specification. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 12/02/2003 12:30 | | | PM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, I will try to flesh out the examples more in the next iteration of the OpenNetwork proposal. I should hopefully have that done soon. I agree with you about the SPML Identifier. In retrospect a pure urn based approach would have served better. I would like to make that change in SPML 2.0 so as to allow for either the current identifier approach or a URN approach. You seem to be implying that in WS-Provisioning an XSD based tool could somehow use the provisioning target schema definition to do something useful. The WS-Provisioning approach requires that the client queries the service to get the provisioning schema, and parses the result. For instance if you wanted to automatically generate client code then you would have to create a WS-Provisioning specific tool to do it. This is true with both proposals. Now whether SPML 1.0 had compelling features that make it worth being backwards compatible with is certainly a matter of opinion.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]