1. Ownership Management
1. Introduction

This chapter introduces the RTIambassador service and FederateAmbassador callback methods that support ownership management. Chapter 7, Declaration Management, presented declaration management methods supporting publication and subscription of objects and interactions. Chapter 8, Object Management, explored methods for registering and updating object instances.

The RTI allows federates to share the responsibility for updating and deleting object instances with a few restrictions. It is possible for an object instance to be wholly owned by a single federate. In such cases, the owning federate has responsibility for updating all attributes associated with the object and for deleting the object instance. It is possible for two or more federates to share update responsibility for a single object instance. When update responsibility for an object is shared, each of the participating federates has responsibility for a mutually exclusive set of object attributes. Only one federate can have update responsibility for an individual attribute of an individual object at any given time. Also, only one federate has the privilege to delete an object instance at any given time.

1. Push v. Pull

The ownership management methods provide a facility for exchanging attribute ownership among federates in a federation execution using a "push" and/or a "pull" model. A federate can try to give away responsibility for one or more attributes of an object instance – or push ownership. Alternatively a federate can try to acquire responsibility for one or more attributes of an object instance – or pull ownership. The push model cannot thrust ownership onto an unwitting federate. Similarly, the pull model cannot usurp ownership.

2. Privilege to Delete

The special attribute "PrivilegeToDelete" exists in all object instances (by default). The federate that "owns" this attribute for an object instance has the right to delete the object. Federates can exchange the privilege to delete attribute as they would any other attribute.

2. Ownership Pull

In Chapter 7, Declaration Management, Figure 7-2 introduced four object classes in a small hierarchy – including the object class Y with attributes {a, b, c, d, e, f, g, h, ~}. The privilege to delete attribute is shown graphically with a tilde. As mentioned above, multiple federates may share update responsibility for a given object instance. In Figure 9-1, Federate #1 declares that it can publish attributes {b, e, f, g, h, ~}. Federate #4 declares that it can publish attributes {a, c, d, ~}. Each federate implicitly publishes the privilege to delete attribute.



Figure 9-1. Shared Update Responsibility.

In this particular example, there's no contention for attribute ownership since the two federates are interested in mutually exclusive attributes. However, only one federate can create a particular object instance. If Federate #1 creates an instance of Y named "Y_alpha," then it will "own" Y_alpha{b, e, f, g, h, ~} since it has published those attributes for object class Y. The attributes Y_alpha{a, c, d} are initially unowned.

If Federate #4 has subscribed to object class Y, it will discover Y_alpha as soon as it is registered by Federate #1. Federate #4 can attempt to acquire ownership (i.e., update responsibility) of any Y attributes for Y_alpha. Figures 9-2 and 9-3 provide interaction diagrams that illustrate the pull ownership model for orphaned and obtrusive "pulls" respectively.



Figure 9-2. Ownership Pull Interaction Diagram – Orphaned Attribute



Figure 9-3. Ownership Pull Interaction Diagram - Intrusive

1. Attribute Ownership Acquisition

The RTIambassador method attributeOwnershipAcquisition() attempts to secure ownership of an attribute whether or not it is currently owned by another federate. As an alternative, the method attributeOwnershipAcquisitionIfAvailable() attempts to secure attributes that are not owned by another federate. A call to attributeOwnershipAcquisition() ultimately results in one or more requestAttributeOwnershipRelease() callback invocations if the requested attributes are owned by other federates. When attributeOwnershipAcquisitionIfAvailable() is called, any attributes that are already owned are reported via the attributeOwnershipUnavailable() callback. In order to request ownership of attributes for a particular object instance, the requesting federate must construct an attribute handle set. The procedure is outlined in Chapter 7, Declaration Management.

2. Attribute Ownership Release

As discussed in the previous paragraph, a call to attributeOwnershipAcquisition() will produce a requestAttributeOwnershipRelease() callback invocation on any federate that holds a requested attribute. A federate fielding this callback responds with the RTIambassador method attributeOwnershipReleaseReponse(). At a minimum, the federate should respond with a null attribute handle set – indicating that the attributes cannot or will not be released. The federate is free to give up none, some, or all of the requested attributes. The federate is released from update and/or delete responsibility once it has called attributeOwnershipReleaseReponse().

3. Ownership Push

Ownership push suggests that a federate owns update responsibility and/or the privilege to delete for an object instance and wishes to transfer ownership to another federate. The ownership may be surrendered "unconditionally" or "negotiated." Unconditional push releases a federate from attribute update and/or deletion responsibility without any commitment from other federates to assume these responsibilities. Negotiated push is a formal exchange where a federate retains responsibility until a new owner is identified and a formal exchange process is completed. Typical ownership push interactions are presented in Figure 9-4.



Figure 9-4. Ownership Push Interaction Diagram

 

1. Unconditional Push

A federate wishing to relieve itself immediately from attribute update responsibility for an object instance and/or the responsibility of deleting the object instance, can call the RTIambassador method unconditionalAttributeOwnershipDivestiture(). The federate is immediately free from the attribute responsibilities (including privilegeToDelete if listed) for the specified object instance.

2. Negotiated Push

A negotiated push is more involved than an unconditional push and is designed to ensure that attribute update and object deletion responsibilities are not dropped. The federate wishing to let go responsibilities calls the RTIambassador method negotiatedAttributeOwnershipDivestiture(). Federates that are capable of publishing any or all of the attributes being given away are notified via the FederateAmbassador callback method requestAttributeOwnershipAssumption(). A federate wishing to acquire one or more of the offered attributes makes use of one of the pull methods – attributeOwnershipAcquisition() or attributeOwnershipAcquisitionIfAvailable().

As federates are found to assume the responsibilities being given away, the federate that initiated the push receives the callback attributeOwnershipDivestitureNotification() – which informs the federate that it is no longer responsible for the listed attributes. The federate(s) gaining responsibility for the attributes is informed of its new responsibility with the callback method attributeOwnershipAcquisitionNotification().

3. Complex Exchanges

Ownership exchange can be quite complex. In the push model, several federates may vie for ownership of offered attributes. The pushing federate may not succeed in giving all the requested attributes away. The contending federates may not get everything they ask for. A federate that doesn't get everything it wants may try to surrender the attributes it did receive. A federate that fails to get rid of everything it requested can let a negotiated divestiture stand or issue an unconditional divestiture. Divestiture calls for a specific object instance replace any previous calls for that instance.

4. Supporting Functions
1. Cancellation

Sometimes a federate has a change of heart during an ownership transfer. A federate attempting to push ownership may decide that there aren't any takers or otherwise decides to retract the push offer. The RTIambassador method cancelNegotiatedAttributeOwnershipDivestiture() invokes push cancellation.

Similarly, a federate attempting to pull ownership of one or more attributes may wish to cancel the exchange. The method cancelAttributeOwnershipAcquisition() cancels a pull. It is acknowledged by the confirmAttributeOwnershipAcquisitionCancellation() callback method. The cancellation methods in Figure 9-4 are available to bail out of an in-progress exchange.

2. Queries

Two mechanisms exist for determining attribute ownership. The queryAttributeOwnership() method seeks the federate currently responsible for a particular attribute of a particular object instance. It solicits the informAttributeOwnership() callback on the FederateAmbassador that delivers the handle of the owning federate.