Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Optimised OMG Activity Service implementation - avoid unnecessary creation of ActivityCoordinators

IP.com Disclosure Number: IPCOM000014295D
Original Publication Date: 2001-Jun-16
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 51K

Publishing Venue

IBM

Abstract

Optimised OMG Activity Service implementation avoid unnecessary creation of ActivityCoordinators Disclosed is a mechanism for optimizing the performance of distributed CORBA Activitiy service contexts by avoiding the unecessary creation of ActivityCoordinator objects in a distributed environment. The OMG Activity service is a CORBA Object Service described in the OMG document "Additional Structuring Mechanisms for the OTS" (orbos/2000-06-19). It provides a generalized framework for the support of more complex transactional semantics than the simple ACID properties of the Object Transaction Service (OTS). The purpose of the Activity service is to provide support for composing applications that require non-prescriptive, extended transaction behaviour. Long-running applications, for example, can be structured as many independent, short-duration units of activity to form a "logical" long-running transaction. Such structuring allows an activity to acquire and use resources for only the required duration of this long-running transactional application. The Activity service defined in the OMG document describes a service context that enables different vendor implementations to interoperate. In particular, an ActivityContext structure is specified that defines the wire format of an Activity. This structure may contain an ActivityCoordinator reference and it may contain implementation_specific_data in the form of a CORBA::Any. When an Activity service context is imported into a server, the Activity service must examine the service context and import the context into the server. If the context was initiated from a client that is, an execution environment that does not contain a factory for an ActivityCoordinator the context may contain a null ActivityCoordinator reference as part of a deferred-begin context. In such a case, the server creates the ActivityCoordinator and returns its reference in the service context associated with the reply to the client. However, the OMG specification for the Activity service allows for the possibility that an Activity context may represent objects that have no requirement for coordination, in which case the received ActivityCoordinator reference is also null. For example, an Activity context may consist only of PropertyGroup context and may not have any Actions or SignalSets registered. In this case the OMG specification allows for the context to be imported onto the server only for the duration of the request, creating no ActivityCoordinator object and leaving no objects behind on the server when the request completes. The OMG specification suggests that an importing server determine whether a ActivityCoordinator is required or not by locating the PropertyGroupManager of each PropertyGroupIdentity and querying its cacheable attribute; if none of the PropertyGroups are cacheable then the importing Activity service is at liberty to avoid the creation of an ActivityCoordinator.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

  Optimised OMG Activity Service implementation - avoid unnecessary creation of ActivityCoordinators

Disclosed is a mechanism for optimizing the performance of distributed CORBA Activitiy service contexts by avoiding the unecessary creation of ActivityCoordinator objects in a distributed environment.

    The OMG Activity service is a CORBA Object Service described in the OMG document "Additional Structuring Mechanisms for the OTS" (orbos/2000-06-19). It provides a generalized framework for the support of more complex transactional semantics than the simple ACID properties of the Object Transaction Service (OTS). The purpose of the Activity service is to provide support for composing applications that require non-prescriptive, extended transaction behaviour. Long-running applications, for example, can be structured as many independent, short-duration units of activity to form a "logical" long-running transaction. Such structuring allows an activity to acquire and use resources for only the required duration of this long-running transactional application.

    The Activity service defined in the OMG document describes a service context that enables different vendor implementations to interoperate. In particular, an ActivityContext structure is specified that defines the wire format of an Activity. This structure may contain an ActivityCoordinator reference and it may contain implementation_specific_data in the form of a CORBA::Any. When an Activity service context is imported into a server, the Activity service must examine the service context and import the context into the server. If the context was initiated from a client - that is, an execution environment that does not contain a factory for an ActivityCoordinator - the context may contain a null ActivityCoordinator reference as part of a deferred-begin context. In such a case, the server creates the ActivityCoordinator and returns its reference in the service context associated with the reply to the client. However, the OMG specification for the Activity service allows for the possibility that an Activity context may represent objects that have no req...