[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" <edesouza@jamcracker.com>, <Darran.Rolls@waveset.com>, <Gavenraj.Sodhi@businesslayers.com> |
| cc: Gearard Woods/Irvine/IBM@IBMUS, <conrada@microsoft.com>, <mattleib@microsoft.com>, |
| <adrian.viego@businesslayers.com>, <Doron_Cohen@bmc.com>, "Steve Anderson" <sanderson@opennetwork.com>, |
| <Yoav.Kirsch@businesslayers.com>, <rami_elron@bmc.com> |
| 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:edesouza@jamcracker.com]
Sent: Friday, February 28, 2003 12:17 PM
To: Jeff Bohren; Darran.Rolls@waveset.com;
Gavenraj.Sodhi@businesslayers.com
Cc: gewoods@us.ibm.com; conrada@microsoft.com; mattleib@microsoft.com;
adrian.viego@businesslayers.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:jbohren@opennetwork.com]
Sent: Thursday, February 27, 2003 7:52 PM
To: DeSouza, Edwin; Darran.Rolls@waveset.com;
Gavenraj.Sodhi@businesslayers.com
Cc: gewoods@us.ibm.com; conrada@microsoft.com; mattleib@microsoft.com;
adrian.viego@businesslayers.com; 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:edesouza@jamcracker.com]
Sent: Thu 2/27/2003 7:57 PM
To: Darran.Rolls@waveset.com;
Gavenraj.Sodhi@businesslayers.com
Cc: gewoods@us.ibm.com; Jeff Bohren; conrada@microsoft.com;
mattleib@microsoft.com; adrian.viego@businesslayers.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