[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [provision] RE: SPML should be Schema+WSDL
Sorry, but I really feel this discussion should be on the list for anyone seeking clarification of the debate so I'm copying it there. Jeff is correct in that with my proposed approach, there would be a well-defined service interface that would be the SPML protocol, not simply the suggestion that SMPL is WSDL. The protocol would comprise a set of schema documents (XML-Schema) representing the object model of the SPML, and a set of WSDL files describing the service level interface to (roughly) the actors or participants identified in the PSTC Use Cases. Where I would disagree with Jeff is on the tool support for this approach. Obviously, there are tools that would be able to interpret the WSDL and XML-Schema definitions for the raw remote procedure call aspects of this type of solution. I think Jeff feels that the schema that is in turn published by targets would not benefit from those same tools but I'm not sure about that. My perpective is that if you have to have XML-Schema knowledge in any case, the same facilities can be used to interpret the target schema. The question of interoperability is important and here my argument would be that interoperability at the protocol level is possible because of the well-defined SPML API and object model. The target object model (i.e. the schema for a specific target, say Exchange) is a different matter because that pertains to entities that are outside the scope of the specification and that is true if you are using a directory view of the world or this kind of scheme. If a target elects to use a schema language that, for example, an RA does not understand then there is an incompatibility and the RA either gets smarter about the particular schema language or the target publishes its schema in a different language. In fact, in my little example there is nothing to stop a target publishing its schema in multiple schema languages to accomodate different kinds of clients. The level of difficulty is really hard to guage for each approach. On the one hand, Jeff's proposal might be able to leverage exisiting DSML/directory knowledge but will, I submit, place more of a burden on the client. The kind of approach that I'm suggesting would benefit from the ease with which an interface can be generated from a Session EJB, for example, and the wealth of tools that clients can use to talk to a WSDL-defined service. I'm tempted to say that this is a wash but we would have to undertake a prototype implementation in each, if only on paper, to get a more profound understanding of the difficulties. As far as the practical issues go, I can certainly understand the reluctance to change approaches at this stage but does anyone have a good handle on exactly how close the committee members are to a reference implementation? With all due respect, if Yoav's recent XML examples are a reflection of the state of play then there is ample opportunity to indulge in at least a paper exercise to compare the two approaches. An experiment like that would show up any real flaws in both and would, I think, give the committee even more credibility. At the very least it would drive the creation of some useful examples for the documentation. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 02/28/2003 10:50 | | | AM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: "DeSouza, Edwin" <email@example.com>, <Darran.Rolls@waveset.com>, <Gavenraj.Sodhi@businesslayers.com> | | cc: Gearard Woods/Irvine/IBM@IBMUS, <firstname.lastname@example.org>, <email@example.com>, | | <firstname.lastname@example.org>, <Doron_Cohen@bmc.com>, "Steve Anderson" <email@example.com>, | | <Yoav.Kirsch@businesslayers.com>, <firstname.lastname@example.org> | | Subject: RE: SPML should be Schema+WSDL | | | >------------------------------------------------------------------------------------------------------------------------------| Edwin, First of all, a general purpose solution where the PST vendors just write any generic WSDL and XML Schema is not practical. That is not what Gerry is proposing, if I understand him correctly (Gerry, please correct me if I misrepresent this). Even with Gerry's proposal, the PST vendors would still need to know the specific SPML protocol and its semantics. The meta-data would still need to be defined and transmitted in an SPML specific fashion. The fact that you would use XSD to define the meta-data does not alleviate that. All the available tools out there will not directly support this. While Gerry's proposal is interesting and more flexible, it appears be more difficult for both the PST and PSP vendors to implement. There are several issues that will make that so: - How do we support using an open-ended meta-data mechanism such as XML Schema, but restrict it in a way that supports some level of interoperability? - How do we support filtered searching when the meta-data is so flexible? So far, I interpret Gerry's proposal to be in a nutshell (Gerry, again, please correct me if I misrepresent this): - make the protocol in terms of high-level provisioning operations rather than federated naming operations - define the provisioning meta-data in XML Schema rather than a protocol specific mechanism I don't believe that these approaches are going to solve the problem you are referring to. Let's leave theory aside for the moment and talk about practical issues. Netigrity and Business Layers have announced a demo of the current SPML spec at the next RSA conference. I also know of several other companies that are currently working on implementations, but have not announced them yet. Darran is working on setting up a Burton interop event in July similar to the one on SAML last year. There are draft specs on the web site. The analysts are starting to write about SPML and include it in their presentations. Other standards bodies are looking at what we have. Darran has indicated the Waveset would open source an SPML web service client in Java. OpenNetwork Technologies is looking at open sourcing a .NET SPML web service. All this things enhance adoption. If we start over, all that goes away and we will be 6-12 months away from where we are now. That will only hinder PST support, not help it. Even Gerry concedes that the current approach will work, but he believes his approach is superior. Even if you assume that, is that worth flushing a year worth of progress? Is it worth delaying the spec another 6-12 months. Is it worth destroying the credibility that the PS TC has with Burton and the other analysts? Is it worth tanking the work companies have already done to support it in their products. It would be one thing if the current spec was not feasible. Everyone agrees that it is. It also seems to be garnering support in the industry and I see no reason why it would not be adopted, which is ultimately the most important factor. BTW, why are we discussing this off the SPML mail list? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: DeSouza, Edwin [mailto:email@example.com] Sent: Friday, February 28, 2003 12:17 PM To: Jeff Bohren; Darran.Rolls@waveset.com; Gavenraj.Sodhi@businesslayers.com Cc: firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; Doron_Cohen@bmc.com Subject: RE: SPML should be Schema+WSDL Jeff, I don't have a problem with the UseCases that SPML addresses -- my issue is the skills/tools required to be successful with SPML. We should assume engineers+Tools will know XML Schema and WSDL. That's all. Why make them and their tools also deal with yet another thing. Example1: Assume companies like the idea of centralized Provisioning to all their internal applications. Lets say they buy a commercial Provisiong product to do the centralized part. Now they need to go and add Provisioning APIs to all their existing applications. Same applies to all their New applications. MUCH easier sell if "your engineers who do normal XML Schema and WSDL and their favorite tools" is all you need to get these applications to be SPML enabled. Example2: Same applies to all the MSPs/ASPs. They don't want their engineers to go learn something sooo specialized. Provisioning Vendors: If 1+2 is easy, then the need for centralized Provisioning products will be much bigger. At Jamcracker, we continuously face 1+2, and it is hard enough to convince folks to add Provisioning APIs. Why add an extra hurdle. Regards, Edwin. (Background: In a previous life was the founding Product Manager of Borland JBuilder ver 1,2,3,4 and Delphi before then. So, I know a little bit about Tools/IDEs). -----Original Message----- From: Jeff Bohren [mailto:firstname.lastname@example.org] Sent: Thursday, February 27, 2003 7:52 PM To: DeSouza, Edwin; Darran.Rolls@waveset.com; Gavenraj.Sodhi@businesslayers.com Cc: email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; Doron_Cohen@bmc.com Subject: RE: SPML should be Schema+WSDL Not to be picky, but OASIS is not just limited to web services and neither is the PS TC. The committee has already agreed to a SOAP/HTTP (i.e. web service) binding and a file binding. There will likely be more bindings to follow after the 1.0 specification. The intention has allways been to produce and XML Schema that is used for both the SOAP/HTTP and the file bindings, and a WSDL definition for the SOAP/HTTP Binding. Is there anything in the JamCracker business model that can not be supported using the current SPML draft spec? Jeff B. -----Original Message----- From: DeSouza, Edwin [mailto:email@example.com] Sent: Thu 2/27/2003 7:57 PM To: Darran.Rolls@waveset.com; Gavenraj.Sodhi@businesslayers.com Cc: firstname.lastname@example.org; Jeff Bohren; email@example.com; firstname.lastname@example.org; email@example.com; Doron_Cohen@bmc.com Subject: SPML should be Schema+WSDL Darran, Gavenraj, We had a lot of discussion about this early on. I even suggested basing SPML on SAML (rther than DSML) But, that was still a bad solution. Now, I saw this post from Gearard Woods and I cannot be more emphatic in agreeing with his idea for SPML below. Absolutely right on!!! My 3 years experience (as an ASP Aggregator) selling/provisioning 30+ MSP/ASP Web-based applications and WebServcies: -- Gearard is describing the right Provisioning solution -- An XML Schema with WSDL. SPML is early enough for you to make this change. And, at OASIS, standards are for WebServices first. regards, Edwin DeSouza, Director, Product Management, Jamcracker, Inc. http://lists.oasis-open.org/archives/provision/200302/msg00078.html "....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."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC