Browse Prior Art Database

Framework for managing a family of cloned objects

IP.com Disclosure Number: IPCOM000031020D
Original Publication Date: 2004-Sep-07
Included in the Prior Art Database: 2004-Sep-07
Document File: 4 page(s) / 85K

Publishing Venue

IBM

Abstract

A mechanism for managing a group of clones when changes to one of the clones need to be copied back to the original object from which the clones were created.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

Framework for managing a family of cloned objects

Disclosed is an invention that manages a collection of clones in such a way that changes to one of the clones can be copied back to the original object from which the clones were created. This is useful in programming models (such as Java* API for XML-Based RPC (JAX-RPC) handlers) in which the interface treats a parameter as an 'In-Out' parameter, i.e. the operation of the function modifies the input parameter in a way that is expected to be used in later calls. This is particularly important where the interface to be used cannot be refactored (for example where it is dictated by a standard or other supplied interface).

    This allows for a more flexible programming model, which is more suitable for decomposition into subcomponents. Each subcomponent can work on a clone (to ensure isolation). At some stage a decision can be taken amongst the clones about which one should be returned used as 'return' value of the 'In-Out' parameter. Example

    Examples in this disclosure are concerned with the JAX-RPC handler interfaces. JAX-RPC handlers have methods such as boolean handleRequest(MessageContext mc)
in which the properties of mc are changed by the handleRequest() method, and subsequent calls can make use of this modified object.

    This invention allows multiple clones of (e.g.) mc to be created inside the implementation of (in this case) handleRequest, different computation being done on each, with a decision about which of the clones will be used to modify the properties of mc made at any time.

    The invention introduces an efficient mechanism to allow the properties of any clone to be used to override the properties of the 'master' instance. The external mechanism used is to call a 'copyToMaster()' method on any clone.

In summary, the 'Master Copy' is in fact a proxy to a 'real implementation object'; calling the 'copyToMaster()' on any clone causes the 'Master' proxy to change its delegation to that instance.

Page 2 of 4

<<interface>>

ManagedClone

+ copyToOriginal() + clone()

<<interface>>

BusinessInterface

<<interface>>

ManagedCloneableBusinessInterface

ManagedCloneableBusinessInterfaceProxy

<<synchronized>> + delegateTo(d : ManagedCloneableBusinessInterface)


0..1

0..1

+delegateTo

   BusinessInterfaceImpl + getOriginator() + setOriginator()

1

1

1

1..*

1..*

1+originator

<<interface>>

ManagedCloneableBusinessInterfaceFactory

+ newInstance()

    The 'design pattern' for this invention is shown in the diagram above, using a Unified Modelling Language class diagram.

The pattern consists of a number of elements;

The ManagedClone interface; this holds the two methods used by clients of this model to manage the family of clones.

Some 'BusinessInterface'; this is in fact any interface, and defines the business methods of the family of clones These two interfaces must be implemented both by the ManagedCloneable??Proxy and the ??Impl classes (In the example shown, there is ManagedCloneableBusinessInterfacePr...