In the previous post I introduced three web service protocols that ILM uses. In this post we will explore the first protocol, WS-Transfer.
WS-Transfer is a stateless protocol designed to create, read, update, and delete object instances. We use the protocol for its intended purpose. As a stateless protocol, there are no transactions with WS-Transfer, and each operation is atomic. The spec says that the server is free to modify data in-between requests and that the client may not assume data is consistent between operations. In ILM “2” these race conditions sometimes occur when action workflows modify data or the ILM Synchronization Engine flows in data. As a caller, you must be cognizant of these race conditions when communicating with the ILM Service.
The four operations in WS-Transfer are Create, Get, Put, and Delete. The WS-Transfer protocol proscribes that the create operation exists on the ResourceFactory endpoint. All other operations are on the Resrouce endpoint. In ILM “2” RC, the default endpoint for ResourceFactory is http://localhost:526/ResourceManagementService/ResourceFactory. The default endpoint for Resource is http://localhost:526/ResourceManagementService/Resource. Please note that all of the following requests are gated by authentication and authorization workflows to protect an enterprise’s data. Let’s describe the operations in detail.
The create operation requests the ILM Service to create a new object instance based on initial data provided in the request. The initial data is an XML representation of an ILM object instance. The ILM Service returns a create response with information on how to then retrieve the created object using the WS-Transfer Get operation.
The get operation requests the ILM Service to return an XML representation of a single ILM object instance. The client specifies the particular instance using the ObjectId in the request header. The XML representation is returned in the get response.
The put operation requests the ILM Service to replace the given attributes of a single ILM object instance. The client specifies the particular instance using the ObjectId in the request header. The ILM Service either returns an empty response or a fault with information why the request could not be processed.
The delete operation requests the ILM Service to remove a single ILM object instance. The client specifies the particular instance using the ObjectId in the request header. The ILM Service either returns an empty response or a fault with information why the request could not be processed.
WS-Transfer usage in ILM “2”
The most common use of WS-Transfer protocol in ILM “2” is to interact with specific objects. For instance, to add a member to a group, a client would invoke the put operation to add a new member to the multi-valued attribute ExplicitMember on a Group object. To create a new user for provisioning, a client would invoke the create operation and specify initial data.
Please recall that ILM uses both XML representations of object instances and ILM’s extension to WS-Transfer to represent partial attributes of object instances. We will discuss the extension in a later post (Topic 7). By default all WS-Transfer operations will use the “naked” XML representations of object instances. These representations are straight-forward and easy to understand when inspecting. A client must specify explicitly that it wishes to use the extensions.
In our next post we will discuss ILM’s use of WS-Enumeration.