22.16.2 MessageRouting Module

   The following module has been added for the CORBA Messaging Interoperable Routing Protocol. These definitions are only required for interoperable support of Time-Independent Invocations:

   // IDL// File: MessageRouting.idl#ifndef _MESSAGE_ROUTING_IDL_#define _MESSAGE_ROUTING_IDL_

   import ::CORBA;import::Dynamic;import ::GIOP;import ::IOP;import ::Messaging;module MessageRouting {

   typeprefix MessageRouting “omg.org?;

   //// Basic Routing Interoperability//

   interface Router;interface RouterAdmin;typedef sequence<Router> RouterList;

   struct MessageBody { sequence<octet> body; boolean byte_order;

   };

   struct RequestMessage { GIOP::Version giop_version; IOP::ServiceContextList service_contexts; octet response_flags; octet reserved[3]; sequence<octet> object_key; string operation; MessageBody body;

   };

   enum ReplyDisposition { TYPED, UNTYPED };

   typedef sequence<RequestInfo> RequestInfoSeq;

   interface Router {

   void send_request(in RequestInfo req);

   void send_multiple_requests(in RequestInfoSeq reqSeq);

   readonly attribute RouterAdmin admin; };

   //// Polling-related interfaces//

   interface UntypedReplyHandler : Messaging::ReplyHandler {

   void reply( in string operation_name, in GIOP::ReplyStatusType reply_type, in MessageBody reply_body);

   };

   exception ReplyNotAvailable { };

   interface PersistentRequest { readonly attribute boolean reply_available;

   GIOP::ReplyStatusType get_reply( in boolean blocking, in unsigned long timeout, out MessageBody reply_body)

   raises (ReplyNotAvailable);

   attribute Messaging::ReplyHandler associated_handler; };

   interface PersistentRequestRouter {

   PersistentRequest create_persistent_request( in unsigned short profile_index, in RouterList to_visit, in Object target, in CORBA::PolicyList current_qos,

   valuetype RetryPolicy supports CORBA::Policy { };

   const CORBA::PolicyType IMMEDIATE_SUSPEND_POLICY_TYPE = 50; valuetype ImmediateSuspend : RetryPolicy { };

   const CORBA::PolicyType UNLIMITED_PING_POLICY_TYPE = 51; valuetype UnlimitedPing : RetryPolicy {

   public short max_backoffs;

   public float backoff_factor;public unsigned long base_interval_seconds;};

   const CORBA::PolicyType LIMITED_PING_POLICY_TYPE = 52; valuetype LimitedPing : UnlimitedPing { public unsigned long interval_limit; };

   const CORBA::PolicyType DECAY_POLICY_TYPE = 53; valuetype DecayPolicy supports CORBA::Policy { public unsigned long decay_seconds; };

   const CORBA::PolicyType RESUME_POLICY_TYPE = 54; valuetype ResumePolicy supports CORBA::Policy { public unsigned long resume_seconds; };

   interface RouterAdmin {

   void register_destination(in Object dest,in boolean is_router,in RetryPolicy retry,in DecayPolicy decay);

   void suspend_destination(in Object dest,in ResumePolicy resumption)

   raises (InvalidState);

   void resume_destination(in Object dest)raises (InvalidState);

   void unregister_destination(in Object dest)raises (InvalidState);

   }; }; #endif

   Appendix A Overall Design Rationale

   A.1 QoS Abstract Model Design

   This Appendix describes each of the components in the Quality of Service (QoS) abstract model and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA. The Messaging-specific QoS are defined in terms of this framework.

   Note – The QoS definitions specified in this specification are applied to both synchronous as well as asynchronous invocations.

   A.2 Model Components

   The QoS framework abstract model consists of the following components:

• Policy - The base interface from which all QoS objects derive.

• PolicyList - A sequence of Policy objects.

• PolicyManager - An interface with operations for querying and overriding QoS Policy settings.

• Mechanisms for obtaining Policy override management operations at each relevant application scope: • The ORB’s PolicyManager is obtained through invoking ORB::resolve_initial_references with the ObjectId “ORBPolicyManager?. • A CORBA::PolicyCurrent derived from CORBA::Current is used for managing the thread’s QoS Policies. A reference to this interface is obtained through an invocation of ORB::resolve_initial_references with the ObjectId “PolicyCurrent?. • Accessor operations on CORBA::Object allow querying and overriding of QoS at the object reference scope. • The application of QoS on a Portable Object Adapter is done through the currently existing mechanism of passing a PolicyList to the POA::create_POA operation.

• Mechanisms for transporting Policy values as part of interoperable object references and within requests:

• TAG_POLICIES -A Profile Component containing the sequence of QoS policies exported with the object reference by an object adapter. • INVOCATION_POLICIES - A Service Context containing a sequence of QoS policies in effect for the invocation.

   The Messaging QoS abstract model consists of a number of CORBA::Policy-derived interfaces:

• Client-side Policies are applied to control the behavior of requests and replies. These include Priority, RequestEndTime, and Queueing QoS.

• Server-side Policies are applied to control the default behavior of invocations on a target. These include QueueOrder and Transactionality QoS.

   A.2.1 Component Relationships

   Programmers set QoS at various levels of scope by creating a Policy-derived Messaging QoS Policy and selecting the interface for the particular scope. It is anticipated that the following is the standard use-case scenario:

• A POA is created with a certain set of QoS. When object references are created by that POA, the required and supported QoS are encoded in that object reference. Such an object reference is then exported for use by a client.

• Within a client, the ORB’s PolicyManager interface is obtained to set QoS for the entire ORB (for the entire process when only one ORB is present) either programmatically, or administratively. The Policies set here are valid for all invocations in the process. A programmer-constructed PolicyList is used with this interface to actually set the QoS.

• Within that same client, the CORBA::PolicyCurrent is obtained to set QoS for all invocations in the current thread. This interface is derived from the PolicyManager interface, which can be used to change the QoS for each invocation. A programmer-constructed PolicyList is used with this interface to actually set the QoS.

• Within that same client, the object reference is obtained and an invocation of its get_client_policy operation queries the most specific QoS overrides. A programmer-constructed PolicyList may be passed to the Object’s set_policy_overrides operation to obtain a new Object reference with revised QoS. Setting the QoS here applies to all invocations using the new Object reference and supersedes (if possible) those set at the ORB and thread (Current) scopes. The current set of overrides can be validated by calling the Object’s pseudo-operation validate_connection, which will attempt to locate a target for the object reference if no target has yet been located. At this time, any Policy overrides placed at the Object, Thread or ORB scope will be reconciled with the QoS Policies established for that object reference when it was created by the POA. The current effective Policy can then be queried by invoking get_policy, which returns the Policy value that is in effect.

• Unseen by the application, the ORB (including the protocol engine) modifies its internal behavior in order to realize the quality of service indicated by the client through the first three steps. See the description of the protocol abstract design in Section A.4, “Message Routing Abstract Model Design,? on page 22-80.

   A.2.2 Component Design

   Design decisions were made with respect to the following components of the QoS framework:

• A generic factory for creating QoS Policies. In the POA specification within CORBA, each POA Policy is created through an operation on the POA itself. Although this presents a convenient typed interface for the creation of Policy objects, it causes serious problems when new POA Policies are introduced. To fit with the current model, operations would have to be added to the POA interface for every new type of POA Policy. To address this potential administrative nightmare, this specification introduces a new ORB operation create_policy. Rather than introducing typed operations for creating all of the Messaging QoS Policies discussed in this specification, the generic factory operation is used.

• A RebindPolicy client-side QoS Policy to ensure deterministic effective QoS. In CORBA, transparent rebinding of an object reference may take place during any invocation. Rebinding is defined here to mean changing the client-visible QoS as a result of replacing the IOR Profile used by a client’s object reference with a new IOR Profile. Transparent rebinding is defined as when this happens without notice to the client application. Typically, this happens within GIOP through the use of location forwarding. The default RebindPolicy (and the only CORBA behavior) supports this transparent rebind. For an application with rigorous quality of service requirements, such transparent rebinding can cause problems. For instance, unexpected errors may occur if the application sets its QoS Policies appropriately for an object reference, and then the ORB transparently changes the application’s assumptions about that reference by obtaining a new IOR. The RebindPolicy has

• Each QoS is an interface derived from CORBA::Policy. The design trade-offs focused on ease of application interface for setting specific QoS values, extensibility for new QoS types and values, and compactness so the QoS values can be represented efficiently in Service Contexts and IOR Profile Components. Several alternatives were considered as the basic type for each QoS entity before the decision was made to use the Policy interface:

• CORBA::NamedValue - A pair of string and any were considered mainly due to the flexibility afforded by using an any to represent QoS values. This design was discounted due to the untyped nature of the any and the application development and execution costs of inserting typed data into and extracting typed data from values of type any. Furthermore, the presence of a full typecode within an any makes the size of such pairs too large for inclusion in compact Service Contexts and Profile Components. • Stateful CORBA valuetype - Although the valuetype does present a typed interface to the application program, including valuetypes in Service Contexts and IOR Profile Components is too expensive due to the presence of full repository identifier information when the valuetype is marshaled. Furthermore, there are issues associated with potential truncation of such QoS valuetypes when passed as formal arguments of their base type. • Interfaces derived from CORBA::Policy and compact representation. In the model chosen by this specification, the QoS values are accessible through locality-constrained interfaces. Derivation from CORBA::Policy allows reuse of existing interfaces and operations for policy management. When certain QoS values must be marshaled in a Service Context or an IOR Profile Component, the most compact format was chosen. The type of QoS Policy represented is indicated by a structure containing the integral PolicyType and a sequence of octet holding the values for that policy.

   been added so that applications can prevent the ORB from silently changing the IOR Profile (and therefore the server-side QoS) that have been assumed. A more rigorous value of this Policy even precludes the ORB from silently closing and opening connections (when IIOP is being used, for example). The specific requirements demanded by an application dictate which level of RebindPolicy is necessary.

   A.3 AMI/TII Abstract Model Design

   This section describes each of the components in the Asynchronous Method Invocation /Time-Independent Invocation (AMI/TII) abstract model and the relationships between them.

   The model supported by Messaging is a specialization of the general object model described in the OMA guide. All of the elements of the CORBA object model are present in the model described here. Some of the names of existing components are defined more precisely than they are in the CORBA object model. In addition, this specification adds some new components to support Messaging.

   Some of the components described here have been borrowed from other specifications, which in some cases have yet to be ratified. Where this occurs, it is clearly noted.

   A.3.1 Asynchronous Method Invocation Components

   The abstract model for AMI/TII supported by Messaging adds the following client-side components:

• ReplyHandler - A ReplyHandler is an Object that encapsulates the functionality for handling an asynchronous reply. It is used for callback model reply handling.

• Poller - A Poller is a valuetype used by clients to obtain replies to asynchronous invocations. The Poller provides a type-specific wrapping through which a Reply is obtained.

• Asynchronous Method Invocation (AMI) - A remote method invocation that returns immediately and whose reply is handled by a ReplyHandler-derived class implemented by the programmer, or whose reply is obtained through a Poller valuetype.

   A.3.2 Time-Independent Invocation Components

   The abstract model for AMI/TII supported by Messaging adds the following components to support interoperability of Time-Independent Invocations:

• PersistentRequest - A PersistentRequest is an Object that encapsulates an outstanding request. It supports operations for asynchronous operations (including polling or blocking until the reply comes). The PersistentRequest is not a locality constrained object (as opposed to the CORBA::Request).

• Persistent ReplyHandler - A ReplyHandler whose Object reference is created by a POA with a PERSISTENT LifeSpan Policy. The Persistent ReplyHandler may be implemented by a process other than the one that issued the request.

• PersistentPoller - A Poller with state including a PersistentRequest reference. The PersistentPoller may be used by a process other than the one that issued the request.

• Time-Independent Invocation (TII) - A time-independent invocation is an AMI request whose reply may outlive the client process. This is addressed via the persistent ReplyHandler and Poller mechanisms.

• Router - A software routing agent that is used when the target objects (either the target of the request or the target of the reply) are not available.

• Interoperable Routing Protocol -- An interoperable routing protocol built in terms of GIOP that provides a higher level of Quality of Service with respect to message routing and delivery than is currently supported by IIOP. These extensions allow out-of-the-box interoperability and define interfaces for MOM product plug-ins to support CORBA Messaging with value-added QoS services that the particular MOM vendor brings to the market.

   A.3.3 Component Relationships

    Figure 22-2 denotes an abstract view of the general Messaging architecture and is not meant to imply any particular implementation.

   Figure 22-2 TII: No direct connection possible

    Figure 22-2 depicts the most general scenario in which a client application residing on a laptop wishes to make an asynchronous method invocation on an object in a server residing on another laptop. Each laptop typically connects to its own corporate or ISP network. Each of these networks has some set of Request/Reply Routers installed that are meant to be highly available and reliable. These Routers provide store-and-forward capabilities.

    In Figure 22-2 neither client nor server laptops are currently connected to their respective networks. In this scenario, the client application makes its requests using the Time-Independent Invocation model. The dashed arrows indicate that the client always tries to make the invocation on the target object or the Request/Reply Router closest to the target. Since the client is not connected, it makes the invocation on the local router (indicated by the solid arrow).

    Figure 22-3 depicts an asynchronous invocation in that the replies to the client invoke an operation on a callback object called a ReplyHandler. In general, the client may passivate himself, or may die while the request is outstanding. If a persistent delivery quality of service had been specified (with a long enough time-out period) the reply may be delivered when the ReplyHandler instance becomes available again. All object adapter features including process activation, Adapter activation and servant activation can be used in ensuring delivery of the reply to a persistent ReplyHandler.

    Again, Figure 22-3 is meant to depict the most general case.

   Corporate Corporate

   Client Laptop Network Network Server Laptop

Corporate Routers Request Tried Request/Reply Made Figure 22-3	Corporate
Routers
	Internet Connection
TII:	Target not available synchronously

    Figure 22-4 illustrates the case where the client laptop gains an Internet connection to its corporate network. In this scenario, the Routers that are accessible exchange requests and replies always first trying to contact the target and then sending to the accessible Router closest to the target. In Figure 22-3, the server laptop is not accessible so the routers exchange information. Notice that Corporate Routers may have replies to invoke on the client’s set of ReplyHandlers now that the client is reachable. Also, recognize that since the client laptop is now connected, there may be requests and replies for other targets, which are not currently running on the Client Laptop and so are cached in the Client Laptop’s Local Router.

   Corporate Corporate

   Client Laptop Network Network Server Laptop

Corporate Routers Request Tried Request/Reply Made Figure 22-4	Corporate
Routers
	Internet Connection
Full connectivity available

   Finally, Figure 22-4 represents full connectivity. Notice that all of the Request/Reply Routers exchange information to get previously-queued requests/replies closer to their target objects. Since there is full connectivity between the two applications, the client’s async invocations can be made on the target object directly and the replies can be sent directly back to make the appropriate invocation on the ReplyHandler object.

   If the client application has requested queued delivery, a Router is used even in the case depicted in Figure 22-4. Despite the availability of the target, the client ORB sends the request to a Router, which can queue the request prior to attempting the synchronous invocation on the target. As an optimization that limits the request to needing only a single network hop, this Router may be local to the target, but it is still a Router with all the usual responsibilities.

   Notice also that since the Server Laptop is connected its Request/Reply Router exchanges information for applications that may or may not be running.

   A.3.4 Callback Model Detailed Design

   Several characteristics of the Callback programming model are worth extra attention:

• Exception replies require special handling in the Callback model. Since the ReplyHandler implements an IDL interface, all arguments passed to its operations must be defined in IDL as well. However, exceptions cannot be passed as arguments to operations; exceptions can only be raised as part of a reply. To solve this problem, an ExceptionHolder valuetype is created to encapsulate the identity and contents of the exception that was raised. An instance of this ExceptionHolder is passed as the argument to the ReplyHandler operation that indicates an exception was raised by the target. In addition to its exception state, the ExceptionHolder also has operations that raise the returned exception, so the ReplyHandler implementation can have the returned exception re-raised within its own context.

• The ReplyHandler is a CORBA object that receives the reply to an AMI. The programmer writes the implementation for a type-specific ReplyHandler. A client obtains an object reference for this ReplyHandler and passes it as part of the

asynchronous method invocation. When the server completes the request, its reply is delivered as an invocation on the ReplyHandler object. This invocation is made on the ReplyHandler using the normal POA techniques of servant and object activation. As a result, the callback operation may be handled in a different programming context than that in which the original request was made.

   A.3.5 Poller/PersistentRequest Detailed Design

   In the Polling model, the routing relationships are a superset of those seen in the Callback model. The differences in this model appear at both the beginning and end of the request/reply cycle. For Polling, the client application does not establish a Callback ReplyHandler . The events that occur when Polling are pictured in Figure 22-5 on page 22-79. The steps are as follows:

1. The client invokes the “sendp? variation of the target object’s operation.

2. The ORB creates a PersistentRequest object and associates a reference to it with an invisible ReplyHandler that is wrapped in a type-specific Poller value.

3. The ORB returns this Poller to the client.

4. The ORB then proceeds as if the invocation were done with the invisible ReplyHandler and sends its request into the network.

5. At the very end, the invisible ReplyHandler receives the response and waits for a poll.

6. When the computing context holding the type-specific Poller asks for a response, the Poller obtains the response from the invisible ReplyHandler and delivers that response to the caller.

   Figure 22-5 Sequence of Steps in Polling

   A client uses the Poller in a similar fashion as in the DII deferred synchronous model. The programmer can at any time choose to check whether or not the reply has arrived and deal with it in the current programming context. The user may also ask a Poller to block until the reply has arrived. The PersistentRequest reference is not visible to the client application, but is specified to enable interoperability between Messaging products.

   When a Time-Independent Invocation has been made, it is possible to poll for the reply in a client different from the one that made the initial request. An application takes advantage of this by passing the Poller from the client that made the request to the client that intends to poll for the reply (presumably by way of an Object instance that is collocated with the latter client). Since this Poller is implemented through the use of a PersistentRequest object implemented by the Messaging layer, that PersistentRequest must be accessible to whichever client uses that Poller. When the TII is used, it is possible for the polling client to obtain the reply after the original invoking client no longer exists. Since the PersistentRequest must be implemented in a server that is accessible to the Polling client, that PersistentRequest must be external to the original invoking client. A common design might be to have the PersistentRequest in this case be implemented by a corporate Router accessible to the invoking client as well as to the client that intends to poll for the response. The creation of PersistentRequest objects is discussed in detail in the Section 22.12, “Section III - Introduction,? on page 22-44.

   In addition to being able to query the status of an individual Poller, the client can use the PollableSet interface to ask about the status of several pollers, as well as the status of any deferred synchronous requests. The client can query to find out if any of a particular set has completed or it can block until one of the set completes.

   Note on CORBA AMI Support

   Asynchrony is addressed in several places in CORBA. These items are taken into consideration by this specification and are modified in the following ways:

   • oneway operations - Operations can be defined in IDL to be oneway. Such operations are by their very nature asynchronous, in that no reply is ever received from a oneway operation and no synchrony can be assumed between the client and the target. However, the definition of oneway in the CORBA specification does not guarantee a deterministic, portable behavior between compliant ORB products. To address this issue, the CORBA Messaging specification introduces a QoS Policy that makes the behavior of oneway operations deterministic. Note that this new Policy addresses the behavior of oneway operations regardless of the use of the new Polling and Callback stubs introduced by this specification.

   • DII Deferred Synchronous - Deferred synchronous invocations are supported in CORBA only when the DII is used. The CORBA::Request pseudo-interface is enhanced by this specification with the additions of TII and the Callback model.

   Note on Asynchrony and Narrowing of Object References

   Many programming languages map IDL interfaces to programming constructs that support inheritance. In those language mappings (such as C++ and Java) that provide a mechanism for narrowing an Object reference of a base interface to a more derived interface, the act of narrowing may require the full type hierarchy of the target. In this case, the implementation of narrow must either contact an interface repository or the target itself to determine whether or not it is safe to narrow the client’s object reference. This requirement is not acceptable when a client is expecting only asynchronous communication with the target. Therefore, for the appropriate languages this specification adds an unchecked narrow operation to the IDL mappings for interface. This unchecked narrow always returns a stub of the requested type without checking that the target really implements that interface. If a client narrows the target to an unsupported interface type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION with standard minor code 2.

   A.4 Message Routing Abstract Model Design

   This section describes each of the components of the Message Routing abstract model and their relationships.

   A.4.1 Model Components

   By and large the components of the message routing protocol are the same as those of GIOP. The differences come with respect to two issues:

• TII is essentially a store-and-forwarding mechanism. This implies the use of Request routing agents. The protocol followed by these Routers is defined in Section 22.14, “Message Routing,? on page 22-45, and is intended for insertion into Common Object Request Broker: Architecture and Specification as a chapter on Messaging Interoperability.

• Dynamic Protocol Selection based on QoS is reconciled locally via information in the IOR and the local ORB. This implies several newly defined items at the protocol level:

• Newly defined IOP::ServiceContext that contains QoS parameters. • Newly defined IOP::ComponentId tag for Messaging and a Component consisting of a representation of default QoS parameters. • Newly defined IOP::ComponentId tag and Component representing the transaction policy. • A newly defined IOP::ComponentId tag and Component containing a sequence of Request Routers. This sequence of Routers represents the preferred addressing strategy when TIIs are made on an Object.

   A.4.2 Component Relationships

   The relationship between the above described components is based on the following:

• QoS resolution should be performed by the client ORB if possible. Routers and/or Messaging-aware Adapters must ensure that only valid QoS have been selected.

• For efficient use of the Request/Reply Routers, their addressing information needs to be in the IOR.

• Request/Reply Routers re-route request and reply messages by explicitly sending messages between them, and then generating a regular GIOP request (and receiving a regular GIOP reply) when interfacing with the real target. To allow this routing to occur, the Router interface requires an encapsulation of a GIOP request in terms of:

• Routing information including the message header and pertinent QoS information. • Message payload (the marshaled arguments and service contexts from the client).

   The routers use the encapsulated QoS & re-routing information to re-route requests and replies and to decide whether to store request/reply information for a specified lifetime. The GIOP must be flexible enough to allow the Router closest to the request’s destination to generate a request that looks like it was marshalled at the original client. This closest Router must be able to handle the full GIOP including the processing of a LOCATION_FORWARD reply without necessitating a return to the original client.

   A.4.3 Router Administration Design

   Several features of the Router administration design are worth note. These fall into two main areas:

• Static vs. Dynamic Routing - Routing information for an Object is available to the client ORB through a Profile Component in the object’s IOR. This Component contains a sequence of Router references through which Time-Independent requests may pass on the way to the target. Therefore, portably exporting a target’s preferred Routers must be done statically, at the time when the target’s reference is created. This specification introduces no interfaces that support dynamic routing. It is expected that future work in CORBA Messaging will introduce portable administrative interfaces through which domains of Routers may be connected. Note that since the Router is an Object, the usual CORBA mechanisms for dynamic server relocation can certainly be used to allow migration of Routers and other such dynamic Routing activities.

• Minimize administrative traffic - Administrative interfaces are introduced that will allow a minimal amount of network bandwidth to be consumed when network disconnections occur. Furthermore, these administrative interfaces have been designed so that additional overhead is not consumed when Routers would normally be in an idle state. Administrative communication is only necessary when messages would otherwise have to be sent between Routers.

   Appendix B Conformance and Compatibility Issues

   This Appendix specifies the points that must be met for a compliant implementation of CORBA Messaging and compatibility issues associated with this specification.

   B.1 Conformance Issues

   This specification can be separated into several logical components.

   In order to be conformant with this specification, the following mappings and features must be supported and implemented using the specified semantics:

• Changes to CORBA and Services. These changes include the modifications to GIOP, OTS, and the SyncScopePolicy refinements to oneway operations. This component includes the Policy management framework for Quality of Service as described in Section 22.1, “Section I - Introduction,? on page 22-2.

• Asynchronous Method Invocation (AMI) interfaces. This component includes the generation of asynchronous stubs (sendc/sendp operations) along with all interfaces and values upon which these stubs rely. All modifications to the DII are also included in this component.

• Time-Independent Invocations (TII). This component includes the QoS Policy that supports TII (RoutingTypePolicy), the typed PersistentPollers described in Section 22.10.2, “Persistent Type-Specific Poller,? on page 22-28, and all interoperable Routing interfaces described in Section 22.12, “Section III Introduction,? on page 22-44.

• Quality of Service Policies for Messaging. These new Policies and their possible values are described in Section 22.2, “Messaging Quality of Service,? on page 22-2.

Implementation of the following component is not required to be conformant with this specification:

   B.2 Compatibility Issues

   B.2.1 Transaction Service

   Transaction service compatibility is affected by two factors:

• Changes to existing transaction service behavior introduced as part of this specification.

• New transaction service functions introduced by this specification and the affect on existing implementations.

   These are considered separately in each of the following sections.

   B.2.2 Changes to Current OTS Behavior

   This specification deprecates the TransactionalObject interface defined in the Transaction Service specification located in the CORBAServices specification. The TransactionalObject interface was defined to control propagation of the transaction context between the client and the server. An interface that inherits from TransactionalObject will automatically have the client’s transaction context established by the server ORB before any operations on that interface are invoked.

   A new mechanism for transaction propagation is independent of the use of inheritance from TransactionalObject. This mechanism has been defined so that existing applications will continue to operate correctly without change so they do not have to remove TransactionalObject inheritance from their existing IDL. At most, they will need to ensure that a definition of CosTransactions::TransactionalObject continues to be available to the IDL compiler.

   The use of TransactionalObject inheritance had two other side effects in the Transaction Service specification.

• It affected the CORBA type of the interface being defined and thus the RepositoryID in the Interface Repository. This means that once interface inheritance is actually removed, transactional and non-transactional implementations of the same interface will have the same CORBA type.

• It provided for documentation within IDL of interfaces whose implementation was intended to be transactional. This enabled application developers to easily track their use of transactions.

   Once TransactionalObject is actually removed, these side effects will no longer be present.

   Effects of New OTS Functions on Existing OTS Implementations

   This specification introduces new functions and behaviors to the Transaction Service to support the global transaction model used by messaging and to encode the transaction model in the object reference using a newly defined TransactionPolicy. The default for this new policy has been chosen to be compatible with existing CORBA behavior (i.e., a global transaction is associated with the target object if present) otherwise it is not. Existing applications, which will not create TransactionPolicy objects, will get the existing CORBA behavior.

   Existing Clients with New Servers

   New server applications can create object references with new TransactionPolicy selections that can be exported to existing clients. Depending on the TransactionPolicy selected, invoking methods on these objects may succeed transparently to the client or produce failures (in the form of system exceptions) existing clients will not have previously seen.

   New AMI Clients with Existing Servers

   Existing servers may require analysis of their existing semantics to determine the extent to which they may be able to operate with new clients, especially clients that use the new AMI request invocation model. In general the following are true and existing objects may as a result be usable without change by AMI clients:

• If transactions are not used, existing server objects will interoperate with new AMI clients.

• If transactions are used, AMI invocations will use the new queued transaction model causing invocations on the target object to be rejected with a new system exception.

• Depending on application design, it is possible that some (but not all) of these existing applications can operate successfully with AMI clients. This will require that these server objects be changed to produce new compatible object references.

   It is normally true that a server application design, which depends on updating recoverable resources managed by objects at multiple sites cannot support an AMI invocation without producing different behavior. For the cases where this is not a problem the application can take advantage of new AMI clients by changing the object reference at creation time.

   B.2.3 Security Service

   The issues surrounding Security and Time-Independent Invocations must be addressed in a subsequent RFP. Current CORBA Security does fully support all other aspects of this specification, including typed deferred synchronous invocations.