Re: [provision] ask the cloud : why not SPML ?

[Gary Cole <gary.cole@oracle.com>]

On Mar 31, 2011, at 9:43 PM, Tom Zeller wrote:

>> Hi Tom - I think it's a good idea. Especially Google Apps is a good  
>> case for identifying weaknesses in SPML2.
>>
>> Of course, google's provisioning API is a REST interface. But many  
>> of the atomic operations it supports are examples of operations I  
>> think that SPML2 should have better typed support for (e.g. CRUD  
>> operations for groups, org units).
>>
>> Lets put it as a topic for the next call...
>
> Apologies for missing the last call.
>
> Should I add "SPML to the cloud" as a use-case on the wiki ?
>

Do you have enough information to describe the business problem(s) we  
are trying to solve?  Then yes, please do.  I'd really like to know  
what's different about provisioning to the cloud and how we could  
change SPML to better support that.

REST interfaces are the opposite of SPML in one way: they represent  
primarily the objects (as resources) and let the standard HTTP verbs  
do most of the work.  REST interfaces might define a "pseudo-resource"  
to represent any operation that doesn't map easily onto the standard  
HTTP verbs.

SPML is a closer fit to WSDL in its "verb-first" orientation.   
However, the big benefit of WSDL is when you can point your IDE at it  
and auto-generate the stubs.  The real value of that is when the IDE  
can discover for every method every parameter, its type, its  
description and pop that up on the screen.  SPML as a protocol is  
payload-agnostic.  You'd really want to generate the stubs based on  
the schema that the provider exposes.

In a past project for Sun Microsystems, we prototyped a provisioning  
system that automatically supported REST and WSDL and SPML for any  
connected target.  REST and WSDL were relatively easy; generating WSDL  
bindings that were sufficiently specific required code-generation.

Gary