SPML understood as Service Provider Markup Language is a Standard. It allows service requestors and service providers offering mainly ICT features to exchange provisiong request relevant information within a given framework.
If you’re not familar with the standard yet, just google for it and you will find information on the OASIS side including a well defined specifiction. This allows to implement a service provider or service requestor as it describes the request ans the response for defined capabilities and operations of both sides. Hence, you know what to send and how to react on request.
SPML does not define the services itself, but provides the carrier to transport the data for CRUD operations with.
This really make sense as this on the one hand side provides the frame, but also allows to flexible define the data structures fitting to the actual service requirements / offerings and the technological constraints.
One of the most important advantages of implementing SPML for cloud service provisioning is, that as a service provider you do not have to care who actually is requesting something from the cloud. The contract or as it is called Profile needs to be aligned once at the beginning. From that moment on the requestor can use one or many systems to send requests to the service provider.
The rest comes with the operation listsTargets, which provides in WSDL/XSD language all the capabilities and operartions offered by the service provider.
One of the rather pain points is, that a requestor won’t get notified on provisioned requests when the execution mode is asynchronous instead of synchronous.
The SPML Standard offers a statusRequest operation, which allows the requestor to get information on whether the request’s execution is still pending, successfully provisioned or aborted due to failure. The requestor needs to pull the information until the request has been provisioned successfully or has been aborted with failure.
This brings some senseless load on the provider’s system. It is recommended to spend a notification, i.e. The provider informs the requestor that the request has been executed.
There is more good things coming with SPML and implemented properly it can make service provider and service requestor lifes easier in the long run as reusability and standardization are not too far away from it.
Design work is required on targets, PsoID, PSOs and their attributes and the customer specifics, e.g. Two different passwords for one PSO intead of one which might lead to enhancements of the setPassword operation.
The last note on SPML for today – spend some more time on designing the inner stuff properly. Although it is a Standard some things need to be done and they need some time to be thought through end to end.