WITSML and the Web

WITSML and Concurrency

Using SOAP as the packaging for WITSML messages adds nothing and gives up a lot, compared to using HTTP/REST. A customer integration revealed a concrete issue.

Our client wants to collaborate with a partner on the rig. Our client maintains well, wellbore, and log objects in Wellstorm. The partner would monitor the log data, do some analysis, and then modify a custom element in the wellbore object -- call it "targetHookLoad". Our client, or drill floor personell, would react to that changed number.

In that particular case, no problem. The partner calls WITSML UpdateInStore on an element that our client never modifies.

This is a cool idea: using WITSML objects as a medium of communication. But consider what happens in a more general case.

Say more than one partner on the rig needs to modify the shared element.

Company A's analysis indicates they need to increase the target hook load by 10%. Company A calls GetFromStore to obtain the current value, adds 10% to it, then calls UpdateInStore to change the value.

Company B, meanwhile, in its own analysis, computes another target value. Between the time Company A reads the value and the time they update it, Company B modifies it. But Company A's update is now based on out of date data.

In practice we'll have workarounds. Aware that the WITSML API has no provision for locking objects or concurrency management, we'll contrive new custom data elements for each service company's exclusive modification. Not a big deal by itself.

But compare this omission to a well designed application protocol like HTTP. Note the words "application protocol": HTTP is a protocol you can use to design a distributed application. The designers addressed dozens of issues in distributed application design, based on hard experience as the web emerged in the 1990s. Among the issues they addressed is concurrency management.

In HTTP applications use ETag, Last-Modified, If-Unmodified-Since, and If-None-Match headers to ensure they never modify changed data. For example, when a client retrieves a resource, it checks the Last-Modifed date/time header. When updating the resources using PUT, the client puts that date in the If-Unmodified-Since header; the server will not update the resource if it has changed since that time.

It's not that WITSML couldn't address each issue in distributed application design. WITSML committee could add new concurrency management parameters to calls. But that would be reinventing the application protocol. There's already a great application protocol out there we can leverage: HTTP.

posted by hughw @ 4:40 AM