4.1 Overview of Growing Objects and How They Work

Topic Version1Published10/16/2017
For StandardETPW20 v1

Growing objects in WITSML v2.0 consist of a constant part—similar to a header—and a growing part (or a master/detail, if that pattern is more familiar). In WITSML v1411, each growing part is typically not addressable on its own; it exists only in an array of its parent. For example, in the v1411 XML schema, a Trajectory has an unbounded array called TrajectoryStation, whose type is also called TrajectoryStation. There is no way in XML to address a single TrajectoryStation because there is no global element for it.

To overcome this historical limitation of WITSML, in v2.0 the growing parts have their own global elements. These are streamed in real time on a channel as they are produced, eliminating the need for a consumer application to poll a producer application repeatedly to see if any new data is available. Streaming the growing portion is done by subscribing to the main object using Protocol 1 (P1). The growing part objects are transferred as channel data.

NOTE: Any object that is “channel subscribable” (that is, its Resource record has a channelSubcribable flag set to “true” as described in Section 3.3.17.3 in the ETP Specification) can be described in Protocol 1.

The header (or master) portion of the growing object MUST be sent as part of the channel metadata, because it applies to the entire set of data, not just a portion. This WITSML XML document is attached as a domainObject to the ChannelMetadata message.

It is not necessary to send a new ChannelMetadata record each time any attribute of the header domain data object is changed in the store. Even though a ChannelDescribe is a subscription to changes, the only changes that should cause the sending of a new ChannelMetadata record is the addition or deletion of a Channel. If the consumer wants an update to the metadata, then the consumer must issue a new ChannelDescribe message.