Bidirectional propagation

 

Example: Bidirectional propagation of work area context

Whether context changes propagate back to a calling application from a remote application depends on the configuration of the work area partition. If a user creates a bidirectional partition, changes made by a remote application propagate back to the calling application. In other words, changes made to the work area context by a downstream process propagate back up stream. Figure 1 illustrates distribution of work area context on a remote call when the partition containing the given work area is configured for bidirectional propagation of its work area context. For this illustration, the client and server must have created a partition with the same name. Figure 1. Figure 1

As Figure 1 shows, when the client makes a remote call to the server, the server receives the context set by the client process. The server then can make changes to this context or add to it. In this illustration, the server overwrites the value at key1, removes the property at key2, and adds two new properties at key5 and key6. When the server application returns to the client, the work area context is propagated back to the client and demarshalled. The current work area is then updated with the new context.

Note, that if the partition is not configured as bidirectional, and the server tries to change or remove context in work area, "Work Area 1", it will receive a com.ibm.websphere.workarea.NotOriginator exception since the client was the originator of the work area. The server can retrieve the context in "Work Area 1". This is the main distinction between bidirectional propagation of context and non-bidirectional propagation.

 

Bidirectional propagation of nested work area context

If a remote application needs to add context to a work area that is only used by itself or any other remote objects, the remote application should begin another work area. By beginning a new work area, the new context added is scoped to that application and does not flow back to the calling application. The major benefit of nesting work areas is that nesting work areas allows an application to scope work area context to a given application. Taking the above illustration one step further, if the server has begun a work area before overwriting the value at key1, removing the property at key2, or adding new properties at key5 and key6; those changes would not have propagated back to the client. This is shown in Figure 2. We can also see from this figure that the client does not receive the context from the nested work area started by the server. Figure 2. Figure 2


 

See Also


Work area partition service
Nested work areas

 

Related Tasks


Configuring work area partitions on the server

 

See Also


The Work area partition manager interface