Dynamic binding

In object oriented programming, dynamic binding refers to determining the exact implementation of a request based on both the request (operation) name and the receiving object at the run-time. It often happens when invoking a derived class's member function using a pointer to its super class. The implementation of the derived class will be invoked instead of that of the super class. It allows substituting a particular implementation using the same interface and enables polymorphism.

Definition of: dynamic binding

Also called "late binding," it is the linking of a routine or object at runtime based on the conditions at that moment. Contrast with early binding. See binding time and polymorphism.

Example

Suppose all life-forms are mortal. In object oriented programming, we can say that the Person class must implement the Mortal interface, which contains the method die().

Persons and Plants die in different ways, for example Plants do not have hearts that stop. Dynamic binding is the practice of figuring out which method to invoke at runtime. For example, if we write

void kill(Mortal m) {

  m.die();

}

it's not clear whether m is a Person or a Plant, and thus whether Plant.die() or Person.die() should be invoked on the object. With dynamic binding, the m object is examined at runtime, and the method corresponding to its actual class is invoked.

What Is Dynamic Binding? (Typing - Object-Oriented Technology)

Dynamic binding has two forms, static and dynamic. Statically-typed dynamic binding is found in languages such as C++ (virtual functions) and Eiffel (redefinition). It is not known which function will be called for a virtual function at run-time because a derived class may override the function, in which case the overriding function must be called. Statically determining all possibilities of usage is undecidable. When the complete program is compiled, all such functions are resolved (statically) for actual objects. Formal object usage must have a consistent way of accessing these functions, as achieved thru vtables of function pointers in the actual objects (C++) or equivalent, providing statically-typed dynamic binding (this is really just defining simple function pointers with static typechecking in the base class, and filling them in in the derived class, along with offsets to reset the receiver).

The run-time selection of methods is another case of dynamic binding, meaning lookup is performed (bound) at run-time (dynamically). This is often desired and even required in many applications including databases, distributed programming and user interaction (e.g. GUIs). Examples can be found in [Garfinkel 93, p80] and [Cox 91, pp 64-67]. To extend Garfinkels example with multiple-polymorphism, a cut operation in an Edit submenu may pass the cut operation (along with parameters) to any object on the desktop, each of which handles the message in its own way (OO). If an (application) object can cut many kinds of objects such as text and graphical objects, multiple-polymorphism comes into play, as many overloaded cut methods, one per type of object to be cut, are available in the receiving object, the particular method being selected based on the actual type of object being cut (which in the GUI case is not available until run-time).

Again, various optimizations exist for dynamic lookup to increase efficiency (such as found in [Agrawal 91] and [Chambers 92]).

Dynamic binding allows new objects and code to be interfaced with or added to a system without affecting existing code and eliminates switch statements. This removes the spread of knowledge of specific classes throughout a system, as each object knows what operation to support. It also allows a reduction in program complexity by replacing a nested construct (switch statement) with a simple call. It also allows small packages of behavior, improving coherence and loose coupling. Another benefit is that code complexity increases not linearly but exponentially with lines of code, so that packaging code into methods reduces program complexity considerably, even further that removing the nested switch statement! [Martin 92] covers some of these issues.

Using Dynamic Binding

In many cases, control attributes are statically defined using annotations. Some controls provide a Java API to dynamically change certain attributes. Dynamic controls, including the Service Broker and Process controls, provide the means to dynamically set control attributes. Attributes are determined at runtime using a combination of lookup rules and lookup values, a process called dynamic binding. Controls that support dynamic binding are called dynamic controls. The business process developer specifies lookup rules using WebLogic Workshop while the administrator specifies look-up values using the WebLogic Integration Administration Console. This powerful feature means that control attributes can be completely decoupled from the application and can be reconfigured for a running application, without redeployment. How the Service Broker Control Uses Dynamic Binding

The following scenario shows how the Service Broker control uses dynamic binding. POService.jpd needs to call an external service to obtain a quote on a specific item. Several vendors offer this service. The administrator needs to be able to access multiple implementations of the outside service without changing or redeploying POService.jpd. Components Used in Dynamic Binding

This topic describes the capabilities that provide dynamic binding to the quote service using the Service Broker control. @jc:selector Tag

The method-level annotation, @jc:selector, allows dynamic definition of certain properties of the control. The selector has an attribute, xquery, which is an XQuery expression, as shown in the following example:

   /**

    * @jc:conversation phase="start"

    * @jc:selector xquery ::

    *     lookupControlProperties($request/vendorID) ::

    */

   public void requestQuote(PurchaseRequest request);

The value of the selector's XQuery expression is an XML document with a schema that contains control property values. If you are accessing a TPM repository, the XQuery expression appears as follows:

   /**

    * @jc:conversation phase="start"

    * @jc:selector xquery ::

    *     lookupTPMProperties($request/vendorID, $request/vendorID2) ::

    */

   public void requestQuote(PurchaseRequest request);

When invoking a method on the control, the system looks for a selector annotation. If one is present, the XQuery expression is evaluated, possibly binding arguments of the Java call to arguments of the XQuery expression. The result of the XQuery expression is a String value that defines dynamic properties for the control. Built-In XQuery Functions

Two types of XQuery functions are supplied to help you write selector expressions: lookupControlProperties and lookupTPMProperties. The lookupControlProperties function looks up values for dynamic properties specified in a domain-wide DynamicProperties.xml file. The lookupTPMProperties function looks up values from properties in the TPM (Trading Partner Management) repository.

To learn about the TPM repository, see Introducing Trading Partner Integration at http://edocs.bea.com/wli/docs81/tpintro/index.html. To learn about adding or updating information in the TPM repository, see Trading Partner Management in Managing WebLogic Integration Solutions at http://edocs.bea.com/wli/docs81/manage/tpm.html. The TPM control provides WebLogic Workshop business processes and Web services with query (read-only) access to trading partner and service information stored in the TPM repository. To learn about the TPM control, see TPM Control.

If the selector expression uses the lookupControlProperties function, the fully-qualified class name of the JCX together with the result of evaluating the selector are used as a lookup key into the DynamicProperties.xml file. If a match is found, the dynamic properties are applied before making the call to the target service. DynamicProperties.xml File

DynamicProperties.xml is an XML file managed through the WebLogic Integration Administration Console. It contains mappings between values from the message payload (the lookup key) and corresponding control properties. It is a domain-wide file shared by all WebLogic Integration applications in the domain. This file allows you to administer dynamic properties without redeploying the application. The file is located in a subdirectory of the domain root named wliconfig. To learn about managing dynamic selectors, see Processes Configuration in Managing WebLogic Integration Solutions at http://edocs.bea.com/wli/docs81/manage/processconfig.html.

See also

• Name binding
• Method overriding (programming)