Abstract:
Contexts are propagated between a first and second system. The contexts provide information about the environment within which work in the first and second systems is to be performed. The contexts have a hierarchical structure in which the bottom most context in the hierarchy is identified as a leaf context. A request is received at the first system a request to perform the work. Context information is created in the first system pertaining to the environment within which the work is to be performed. The context information forms a context hierarchy having a root context and one or more descendant contexts. Information is propagated from the first system to the second system enabling re-creation at the second system of context information pertaining to the leaf context only.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates to the distribution of contextual information and more particularly to the distribution of nested contexts. 
       BACKGROUND OF THE INVENTION 
       [0002]    Context information is typically used to encapsulate and describe the state of a particular aspect of a data processing system. For example, a transaction context describes an associated transaction that is currently in existence on the system. Such a transaction may have one or more descendants, in which case nested contexts would be used to describe the hierarchy of transactions. 
         [0003]    The concept of nested contexts and distributing them between systems is not new, for example, an OMG Transaction Service (OTS) specification, currently available from Object Management Group, describes nested transactions and their propagation between processes. In the case of OTS, however, details of the entire hierarchy are propagated between systems. 
         [0004]    The use of context information in transaction processing will be used for explanatory purposes.  FIGS. 1A and 1B  illustrate the prior art process in detail. 
         [0005]    Referring first to  FIG. 1A , an application  30  may initiate a transaction (such as to book a vacation) in a “superior” (or coordinating) environment  10 . The term“environment” should be construed as encompassing both hardware in a data processing or computer system and software that must be installed and executed on that system in order to perform a described transaction. When a transaction is instantiated by process A, context information is created about that transaction. This information typically consists of a transaction identifier (e.g. ABC). Transaction ABC may require interaction with a backend resource such as a database  40 . Again context information is created indicating that this is the case. Furthermore, the transaction ABC may need to instantiate work on another distributed system. If this is the case, then the context information needs to be propagated to the secondary or subordinate environment  20 . 
         [0006]    Propagation of the context information is achieved via a Context Propagation Message (CPM)  1001  shown in  FIG. 1B . A context propagation message includes details of the transaction(s) owned by superior environment  10 . Thus the CPM message  1001  includes the transaction identifier ABC, details of its parent (NULL in this case) and details of its ancestors or children (again NULL). 
         [0007]    Upon receiving CPM  100  in subordinate environment  20 , process B extracts information from the message to recreate the context hierarchy present in superior environment  10 . Again, subordinate transaction ABC may require interaction with backend systems such as databases  50 ,  60 . 
         [0008]    Superior transaction ABC has overall control. When application  30  indicates that the transaction is to complete, superior transaction ABC commits (completes) its changes to backend database  40  and also instructs subordinate transaction ABC to complete its part of the work. Responsive to an instruction to complete successfully (henceforth known as a complete instruction) from superior ABC, subordinate transaction ABC commits its changes to databases  50 ,  60 . 
         [0009]    It can be seen that the processing involved when there is a parent transaction only (no children) is relatively simple. 
         [0010]    The situation becomes far more complex, with nested transactions and therefore nested context information.  FIGS. 2A and 2B  illustrate this. 
         [0011]    Referring first to  FIG. 2A , a transaction and associated sub-transactions are initiated by an application (not shown). As before, transaction initiation causes the creation of associated context information by process A. Thus process A creates contexts C 1 , C 2  and C 3 . Once again, it is necessary for some of the work to be done in a secondary or subordinate environment  20 . Consequently a CPM  1002  (as shown in  FIG. 2B ) is sent to environment  20 . 
         [0012]    CPM  1002  includes the details of the context information being propagated. This comprises an identifier for each transaction (C 1 , C 2 , C 3 ) and whether that transaction has a parent and/or any children. The CPM  1002  is used by process B to replicate the hierarchical information as part of process B. 
         [0013]    Again, the superior transaction has overall control (C 1 ). A superior transaction is responsible for determining when an instruction to complete can successfully be invoked on a particular sub-transaction (subordinate transaction). Thus C 2  has responsibility for C 3  and C 1  has responsibility for C 2 . Chains of responsibility are propagated up the hierarchy both in and across superior and subordinate environments. For example, responsibility for subordinate transaction C 1  in environment  20  is owned by superior transaction C 1  in environment  10 . Consequently superior C 1  has overall control of both superior and subordinate environments. Propagation of such responsibility to a context&#39;s parent happens each time a “complete” instruction is received at that context. 
         [0014]      FIGS. 2A and 2B  depict a fully workable and known solution. However performance testing in multi-CPU machines has revealed that, even with gigabit Ethernet connections between systems, it is possible for network bandwidth to become a performance bottleneck when propagating contexts across a network. Therefore it is desirable for such contexts to be as concise as possible to minimize the likelihood of such a bottleneck occurring. 
         [0015]    One way in which the amount of data used to propagate the contexts between systems can be reduced is to compress the data at the sending side and decompress it at the receiving side. While this reduces the burden on network bandwidth, it increases the burden on the system processors during the compression and decompression of the data. A secondary concern is that the two parties involved in the data transmission must agree on the compression/decompression algorithm to be used, adding to the complexity of the data transfer. 
       SUMMARY OF THE INVENTION 
       [0016]    The invention relates to propagating contexts between a first and second system, the contexts providing information about the environments within which work in the first and second systems is to be performed. The contexts have a hierarchical structure with the lowest level context in the hierarchy being identified as a leaf context. When the first system receives a request to perform work context information is created in the first system pertaining to the environment within which the work is to be performed. The created context information forms a context hierarchy having a root context and one or more descendant contexts. The context information is propagated from the first system to the second system enabling re-creation at the second system of context information pertaining to the leaf context only. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]    Preferred embodiments of the present invention will now be described, by way of example only, and with reference to the following drawings: 
           [0018]      FIGS. 1A ,  1 B,  2 A and  2 B disclose prior art techniques for the use of context information; 
           [0019]      FIGS. 3A-3C  illustrate problems associated with propagating only the bottom (leaf) context information in a context hierarchy; 
           [0020]      FIGS. 4A-4C  disclose the operation of the present invention in accordance with a preferred embodiment; 
           [0021]      FIG. 5  illustrates the components of a system implementing a preferred embodiment of the present invention; 
           [0022]      FIG. 6  is a flow chart of processing steps by the system shown in  FIG. 5 ; 
           [0023]      FIGS. 7A-7C  illustrate a loopback problem; 
           [0024]      FIG. 8  illustrates the operation of a solution to the loopback problem, in accordance with a preferred embodiment of the present invention; 
           [0025]      FIG. 9  illustrate components that address the loopback problem, in accordance with a preferred embodiment of the present invention; and 
           [0026]      FIG. 10  is a flow chart of processing steps performed by the components shown in  FIG. 9 . 
       
    
    
     DETAILED DESCRIPTION 
       [0027]    As mentioned above, the propagation of context information can impact system performance. One way in which such contexts can be made less verbose is to propagate only the bottom (leaf) context rather than the entire hierarchy providing at least a 50% reduction in the amount of data taken up by the contexts. 
         [0028]      FIGS. 3A-3C  illustrate the problem that occurs when a simplistic approach to propagation of the bottom context is adopted. 
         [0029]    As shown in  FIG. 3A , a context hierarchy (C 1 , C 2 , C 3 ) exists in process A. Only the bottom context C 3  is propagated to subordinate environment  20  using a context propagation message  1003  shown in  FIG. 3B . Process B uses the context propagation message to instantiate C 3  and a link is established between superior and subordinate C 3  context information. Subordinate C 3  is then registered with superior C 3  (context information  25 ). 
         [0030]      FIG. 3C  indicates that a complete instruction is received at superior C 3  from an application (not shown). When C 3  in process A completes, it directs C 3  in process B to complete. C 3  in process B has no knowledge of its parent (since such information was not transmitted in CPM  1003 ) and therefore immediately directs its resource to complete. In fact, C 3  should not complete until root context (superior C 1 ) completes. 
         [0031]    The present invention enables the transmittal of only the bottom or leaf context in a hierarchy, while overcoming the problem described above. 
         [0032]    The solution will be discussed with reference to  FIGS. 4A-4C , along with  FIGS. 5 and 6 , all of which should be considered in conjunction with one another.  FIG. 5  illustrates the components used to achieve the preferred embodiment, while  FIG. 6  shows the processing steps performed by the components. 
         [0033]    Process A instantiates a new transaction (including several sub-transactions) for performing work (step  300  in  FIG. 6 ) using transaction instantiator  200  shown in  FIG. 5 . At the same time, context information for the transaction is created using context creator  210  (step  310  in  FIG. 6 ). Such context information C 1 , C 2 , C 3  (superior environment or system  10 ) is shown in  FIG. 4A . 
         [0034]    When it is determined that some of the work for the transaction needs to be performed by subordinate environment  20 , CPM Propagator  220  (shown in  FIG. 5 ) propagates the bottom context information to environment  20  (step  320  in  FIG. 6 ). 
         [0035]    Receipt of CPM by process B in subordinate environment  20  results in a context creator component (equivalent to that shown for process A) creating context information for C 3 . Again this can be seen from  FIG. 4A . 
         [0036]    Note each context hierarchy is associated with a thread running within the relevant process. 
         [0037]    Process B requests that subordinate C 3  context information be registered with the superior C 3  context information (step  340  in  FIG. 6 ). Registration component  260  (in superior environment  10  shown in  FIG. 5 ) performs the actual registration and registers the information necessary to communicate with subordinate C 3 . 
         [0038]    Once subordinate C 3  is registered with superior C 3 , it is determined by parent identifier component  240  shown in  FIG. 5  that superior C 3  has a parent (C 2 ). Consequently context promoter component  250  promotes the subordinate C 3  registration up the hierarchy to C 2  when a complete instruction is received at superior C 3  (step  350  in  FIG. 6 ). Here it can be seen that context information for subordinate C 3  (C 3 (s))  25  has been promoted from superior C 3  to superior C 2 . Thus, when a complete instruction is received at superior C 3 , it does not cause superior C 3  to instruct subordinate C 3  to complete. Control now rests with superior C 2  as indicated by the dotted arrow between superior C 2  and subordinate C 3 . 
         [0039]    When control is redirected to superior C 2 , parent identifier component  240  identifies that superior C 2  also has a parent (C 1 ). As shown in  FIG. 4B , this causes CPM Propagator  220  to promote the context information for subordinate C 3  to superior C 2 &#39;s parent C 1  when a complete instruction is received at superior C 2  (step  360 . In  FIG. 4B , superior context C 3  is no longer shown (the associated sub-transaction has now completed). When superior C 2  completes, the context information for that sub-transaction is removed and only context information for superior C 1  remains in process A. The final stage is illustrated in  FIG. 4C , which can finally instruct subordinate to complete. Completion is in all cases performed by completer component  230  shown in  FIG. 5 . 
         [0040]    Thus a workable solution has been disclosed which enables only the propagation of the bottom or leaf context in a context hierarchy to be propagated. 
         [0041]    The second problem addressed herein involves loopbacks where the request flow is such that a call is made back into a process in which the hierarchy has already been seen. This will be discussed with reference to  FIGS. 7A-7D . 
         [0042]    Consider process A with a hierarchy of three contexts. As before only the bottom context C 3  is propagated to subordinate environment  20  and a link is established between process A and process B by which subordinate C 3  is associated with superior C 3 . The “loopback” problem occurs when, for example, subordinate transaction C 3  wants to initiate a call back to the superior environment. This is achieved by propagation of a CPM from process B to process A. The CPM includes details of only the bottom context, superior C 3 . Thus, as far as superior C 3  is concerned, the context hierarchy in which it previously resided, no longer exists. It is only aware of itself. This is shown by greyed representations of C 1  and C 2  in  FIG. 7B . As illustrated in  FIG. 7C , this causes problems when superior C 3  receives a complete instruction. Superior C 3  believes that it has control and thus, when it is ready, instructs subordinate C 3  to also complete. This is incorrect, since both superior C 3  and subordinate C 3  should actually wait until superior C 1  (which does still exist), completes. 
         [0043]    This problem is rectified, as shown in  FIG. 8 , by modifying process A to assume that, upon receipt of any context in the hierarchy all contexts in the hierarchy about which it has knowledge (from a previous occasion) should be resumed. Thus, in this example, the superior environment is to run under the environment described by C 3  and its ancestors (predecessors) about which the superior environment already has knowledge. 
         [0044]    When the CPM is received from process B, process A determines that it already has knowledge of C 3 . C 3  is not however associated with a processing thread (it is in suspended mode). Thus C 3  needs to be associated with a thread. Superior C 3  will be aware of its parent and consequently C 3 &#39;s parent also needs to be associated with the same thread. C 3  (upon receipt of a complete instruction) will correctly promote the reference to subordinate context C 3  in process B to superior parent context C 2 . Similarly superior C 2  will be aware of its parent C 1  and will have to associate C 1  with the same thread. Upon receipt of a complete instruction at C 2 , C 2  will again promote the reference. This leaves C 1  with overall control over subordinate C 3 . The context hierarchy in process A is therefore reinstated and promotion of subordinate C 3  occurs on each receipt of a complete instruction at the superior context currently referencing the subordinate C 3 . 
         [0045]    The components and processing that enable this is discussed with reference to  FIGS. 9 and 10 . 
         [0046]    At step  400 , bottom context information (e.g. C 3 ) is received by process A via CPM receiver  205 . Because this is a loop back, information about C 3  and its predecessors already exists. Thus the contexts for C 3 &#39;s hierarchy do not need to be created. Instead such hierarchy information for the context C 3  is retrieved (via Context Retriever  240 ) using context information  245  (step  410 ). Once such information has been retrieved, the retrieved contexts need to be associated with a thread (via Context Associator  210 ). Having restored (reinstated) C 3 &#39;s context hierarchy, it is now possible for superior C 1  to have overall (and direct) control of subordinate context C 3 . There is already a coordination link between subordinate leaf context C 3  and superior leaf context C 3 . Upon receipt of a complete instruction at the current superior context, the subordinate context information (providing the information necessary to communicate with the subordinate leaf context) is promoted to the superior&#39;s parent context (step  430 ). This continues (step  440 ) until the root or parent context has overall and direct control of subordinate C 3 . Thus a loopback event now works properly. 
         [0047]    It should be appreciated that a loopback from subordinate C 3  to the first system should occur while superior C 3  is still active (i.e. has not completed). Thus when C 3  is reinstated as a result of a loopback request, the information necessary to contact subordinate C 3  (i.e. that provided via the registration link made between subordinate C 3  and superior C 3  at step  340 )) is still available for use during the loopback. 
         [0048]    Further, when context information is propagated between a first and a second system, such context information is propagated along with a request from an application (not shown) at the first system which is controlling the work being done. The context information is associated with a thread running within process A. When an outbound request is sent to the second system, the context information in the first system is placed into “suspended” mode—i.e. is disassociated from the thread. When a reply to the application&#39;s request is received, or when a request loops back to the first system, the context information under which work is being performed or under which the loopback request is to be performed has to be reinstated and associated with a thread for performing the relevant work. 
         [0049]    It should be appreciated that the invention is not limited to transactional context information only. Rather it is applicable to all systems between which coordinated contexts are propagated. For example, context information pertaining to compensation many be propagated between first and second systems. Such context information would contain details necessary to compensate work done in the event of a failure occurring. 
         [0050]    Note, in the preferred embodiment, subordinate context information does not get propagated to a superior parent context if a rollback (undo) is received at the current superior context. The current superior context has the power to instruct the subordinate context at this point. 
         [0051]    In the preferred embodiment, the superior context hierarchy has overall and direct control over the subordinate leaf context. However even in the situation where the superior context hierarchy does not have such overall and direct control, the solution still works where the superior leaf context receives a rollback (undo) request. The superior leaf context has the authority in such a situation to instruct the subordinate leaf context to rollback. The same is also true if and when control for subordinate C 3  rests with superior C 2 . If a rollback is received at superior C 2 , superior C 2  has the authority to instruct the subordinate leaf context to rollback. 
         [0052]    Finally, the application mentions that complete instructions are received at contexts. This is for ease of explanation, strictly speaking a complete instruction is actually received by the relevant system and is processed by the entity that the context represents. 
         [0053]    While preferred embodiments of the invention have been described, the scope of the invention is not to be limited to the described embodiments. The scope of the invention is defined by the following claims and includes all variations and modifications of the invention that may occur to those skilled in the art.