OMG Business Object Domain Task Force White Paper Business Object Concepts This document captures a number of terms and definitions which embody many concepts that were developed during efforts to define a business objects facility. While that effort did not reach fruition in the adoption of an OMG specification, it did result in a better understanding of the problem domain. This white paper provides a vehicle for discussion and adoption of concepts, terms and definitions which will be useful in conducting meaningful discussions and in the formulation of consistent RFP’s and specifications in business domains. Draft prepared by Fred Cummins Electronic Data Systems January 11, 1999 OMG Document Number: bom/99-01-01 Table of Contents TABLE OF CONTENTS 2 INTRODUCTION 4 1. WHAT IS A BUSINESS OBJECT? 5 1.1 IDENTIFIABLE 5 1.2 TRANSACTIONAL 5 1.3 PERSISTENT 6 1.4 ATTRIBUTES 6 1.5 STATES 6 1.6 RELATIONSHIPS 6 1.7 OPERATIONS 7 1.8 AD HOC NOTIFICATION 7 1.9 EVENTS 7 2. DEPENDENT TYPES 8 2.1 PRIMITIVES 8 2.2 DEPENDENT OBJECTS 8 2.2.1 Elementary objects 8 2.2.2 Composite objects 8 2.2.3 Immutable objects 8 2.3 ARRAY OR SEQUENCE 9 3. BUSINESS OBJECTS CONTEXT 10 3.1 TYPE MANAGERS 11 3.1 Life cycle 11 3.2 Queries 11 3.3 Introspection 11 3.4 Type-based dependencies 11 3.5 Relationship-based dependencies 11 3.2 SHARED SERVICES 12 3.2.1 Transaction Service 12 3.2.2 Current Session 12 3.2.3 Name Service 12 3.2.4 Security Service 12 3.2.5 Notification Service 13 3.3 BUSINESS SYSTEM DOMAINS 13 3.3.1 Modeling 13 3.3.2 Recoverability 14 3.3.3 Inter-domain sharing 14 3.3.4 Name Scope 14 3.3.5 Relationships 14 3.3.6 Roles 15 3.3.7 Extents 15 3.3.8 Security 15 3.3.9 Domain manager object 16 4. BUSINESS OBJECT SEMANTICS 17 4.1 PRE/POST CONDITIONS 17 4.2 INVARIANTS 17 4.3 PROCESSES OBJECTS 17 4.4 STATE TRANSITIONS 17 4.6 RELATIONSHIP TYPES 18 5. ADAPTABILITY MECHANISMS 18 5.1 SPECIALIZATION 19 5.2 ROLES 19 5.3 ADAPTORS 20 5.4 LEGACY INTEGRATION 21 GLOSSARY 23 Introduction This document captures a number of concepts and associated terms and definitions related to business objects in a CORBA distributed computing environment. The purpose is to provide a consistent basis for discussion, development of requests for proposals and adoption of specifications within those Domain Task Forces for which business objects are element of the solution to business problems. These concepts, terms and definitions are based on the extended discussions and development of proposals in response to the OMG request for proposals for a business objects facility. While these efforts did not come to fruition with the adoption of specifications, many problems were identified and solved to the satisfaction of a large number of OMG members. Many of these concepts are being incorporated in comercial products. This document is intended to capture the useful results so that there is a common point of reference and formal agreement on those concepts, terms and definitions which continue to be of value. As a white paper, this document does not constitute a formal OMG specification. As specifications are developed, they may refine or redefine the concepts discussed here. However, until that time, this white paper can provide a useful basis for meaningful discourse. The following section defines the concept of a business object and a number of characteristics associated with a business object. Section 2 defines dependent types which exist as elements of business objects. Section 3 describes the context in which business objects operate and the associated services which they are expected to utilize. Section 4 discusses associated business object semantics which are needed to define the behavior of objects. Section 5 discusses adaptability mechanisms. 1. What is a Business Object? A business object is a computing abstraction that represents an entity in the real world. As such, a particular business object may conceptually exist independent of the CORBA environment, as where business objects (i.e., their persistent state) may exist initially in a legacy system database and be activated in a CORBA environment. Consequently, a particular business object may be considered to exist even if it has never been instantiated as a CORBA object. Here we are concerned with business objects, the computing abstraction, which can be instantiated in a CORBA distributed computing environment. These business objects are accessed as specialized CORBA objects—they are network accessible through an object request broker. A CORBA “object reference” uniquely identifies an active business object within the distributed objects environment for purposes of communication of requests through an object request broker. The paragraphs that follow describe particular characteristics of a business object in a CORBA distributed computing environment. 1.1 Identifiable A business object has a unique identity which associates it with the entity it represents in the business domain. This identity, or key, uniquely identifies a business object within its type and its business system domain (see Section 3.3), and generally speaking, it identifies the corresponding entity in the real world. For example, business objects can represent orders, customers, departments, products, factories, procedures, and projects. A business object, and the entity it represents, have unique existence and identity. Consequently, business objects are never passed by value. Business objects may be moved and the move operation will relocate the unique identity. Business objects can also be copied, but the copy must have a new unique identity. Specific implementations might support replication of business objects (i.e., two or more CORBA objects for one business object) for improved performance, but the implementation would be expected to make the replicas transparent to the developer and other business objects, assuring that there is only one defined, recoverable state. 1.2 Transactional In general, business objects are accessed in a transactional context. Because business objects are sharable in a distributed, multi-user environment, there must be concurrency control and transaction serialization to maintain the integrity of the model they represent. These capabilities are expected to be built into business objects so that a business developer need only define the beginning and end of transactions. The transactional context is expected to be passed implicitly. This means that it does not appear in the argument lists of messages, but is passed automatically by the environment. This allows business objects frameworks to hide the details of transactional mechanisms from the business developer in order to provide a simplified abstraction. 1.3 Persistent Most business objects will be persistent. Persistence is necessary to maintain the state of objects (i.e., the data) when the system is shut down or fails. Persistence is not required of all business objects, but, generally speaking, if they have state and represent current information about the business, they will be persistent. Persistence, along with transaction-based updates provide system recoverability. It is generally expected that tools and components will make business object persistence transparent to business developers. Consequently, operations related to persistence may not be visible in the business object interfaces. It is generally assumed that a framework will automatically activate (bring into main memory), update the persistent state and deactivate (remove from main memory) the business objects as required by performance considerations and the operations being performed. 1.4 Attributes Business objects can have attributes. Attributes are associated data elements or objects which provide information about the business object. Attribute values do not have unique identity from a business perspective. These elements without unique identity are called “dependent types” because their meaning and persistence depend on the business objects in which they are attribute values. Dependent types are discussed further in Section 2, below. Attribute values are accessed through accesser methods which will have defined forms. These methods are expected to incorporate related business object functionality. Changes to attribute values can only be made through the use of these accesser methods. Most attributes will contain a single value that is passed by value when requested or set. This includes attributes that contain sequences or arrays of values. Occasionally, an attribute will contain a large number of values which would be inefficient to pass as a very large sequence or array. These may be implemented as multi-valued attributes where members can be retrieved individually or in limited-size sequences through an iterator. Note that business object attributes are not necessarily “IDL” attributes since IDL attributes do not return exceptions and do not provide methods for access to multiple valued attributes. 1.5 States A business object can have defined states . While states and state transitions may be part of the business object specification, the interfaces of state attributes are no different from other attributes except that they are required to have enumerated values. 1.6 Relationships Generally, a business object will have relationships with other business objects which represent associations between their business-world counterparts. Relationships may be one-to-one or one- to-many, and they may be bi-directional or one-way. Relationships between business objects are encapsulated and most are managed so that their integrity is assured. If two business objects are in a managed, bi-directional relationship, when one object removes the relationship, the other object is updated accordingly. Relationships only occur between business objects within a business system domain, discussed below. In some implementations, particularly those which encapsulate legacy systems, relationships may be “derived” rather than “managed.” This means that the affected business objects may not control or be aware of changes to their relationships so that certain facilities based on management of relationships may not be supported. Like attributes, relationships are accessed through accesser methods which will have defined forms. These methods are expected to incorporate related business object functionality. Changes to relationship membership can only be made through the use of these business object accesser methods. Business object attributes are not COS Relationships since COS relationships are not encapsulated and may relate unaware objects. 1.7 Operations Like other CORBA objects, business objects perform operations, i.e., they have methods for which the business object interface defines signatures. Operations are expected to be performed in a transactional context. 1.8 Ad hoc notification Most business objects also support ad hoc event notification. A message can be sent to a business object requesting notification of certain events be sent to a designated consumer. Notices will be sent whenever any specified event occurs until the request is terminated. The need for specific event notices cannot be anticipated in the design of every business object, nor should the computations be performed when there is no interest. Consequently, through a standard protocol, each business object can provide notification of selected events on request. Similarly, events may be requested from all instances of a type and its sub-types by requesting notification from the type manager. Standard levels of service and request options are defined. Selected events may also be directed to an event service to make them more widely accessible and minimize overhead. This notification mechanism is essential for composing systems from independently developed business objects. It allows a dependency specified for one object to be attached to another independently developed object without any special programming. 1.9 Events Business objects have three types of events: (1) intrinsic events exist for every business object and relate to computational state changes, (2) implicit events occur when attributes or relationships are changed or when operations are invoked, completed or result in failure, and (3) programmed events are those which are declared in the interface specifications and generated by business logic. Any of these events may be the basis for ad hoc notification. 2. Dependent Types The values assigned to business object attributes are more primitive than business objects. They do not have unique identity, and they are only persistent and transactional if they are contained in a business object that is persistent and transactional. Because their persistence depends on being contained in a business object, they will be called “dependent types.” Most attribute values are passed by value. This encapsulates attribute values because they can only be changed by assigning a new value through the attribute accesser method. The attribute value structure or object cannot be modified directly, only copies can be accessed directly. Some attribute values may be passed by reference. These are expected to be immutable objects so that the value cannot be changed without using the containing attribute accesser method. Assignment of an immutable object to an attribute will cause the assigned object to be copied. There are six categories of dependent types described below. 2.1 Primitives A primitive value is a native data element such as an integer, string or floating point number. These must be established IDL data types. 2.2 Dependent objects Most attribute values are expected to be objects. These objects will not have unique identity and, as such, can be copied or passed by value. Several specializations of particular interest are discussed below. 2.2.1 Elementary objects Elementary objects are programmatic objects which contain a single instance variable. Elementary objects represent such things as dates, measures (inches, grams) and descriptive characteristics (color, texture). They are also used for business object key values. Methods on these objects provide functions associated with the particular type of characteristic (e.g., unit conversions and key validation). 2.2.2 Composite objects Composite objects are programmatic objects that have multiple instance variables containing primitive values, elementary objects, foreign object identifier objects or other composite objects. An address consisting of street number and name, city, state and zip code could be implemented as a composite object. 2.2.3 Immutable objects Immutable objects are elementary or composite objects that are passed by reference, but cannot be modified using the CORBA interface for that object reference. Immutable objects are used where an attribute value requires substantial storage space and, for efficiency, it is undesirable to pass it by value. When an immutable object is assigned to an attribute, its value will be copied so that a new, immutable object is contained in the associated business object and will be made persistent as part of that business object. If it is desirable to be able to assign such an object by reference (i.e., to avoid a copy) then it should be implemented as a separate business object and managed through a relationship. By prohibiting changes to an immutable object through the CORBA interface, the integrity of the containing attribute is ensured, and business constraints and notification requests will be honored. Typical immutable objects might be bit maps or video clips. 2.3 Array or sequence An attribute may contain a CORBA array or sequence. Arrays may contain primitive values or elementary objects. Sequences may contain primitive values, elementary objects or composite objects. The value assigned to or retrieved from such an attribute is a copy of the array or sequence and its elements. Note that this is not the same as a multi-valued attribute which requires its members to be accessed through an iterator. 3. Business Objects Context Figure 3.1 illustrates the context in which business objects operate. The diagram depicts two different business object types which could be implemented in different languages, executed on different platforms and made persistent in different databases. Business objects must interact with each other and participate in certain functionality provided by their respective type managers. The business objects and type managers support a number of interfaces and protocols by which they interoperate with other business objects and type managers. These interfaces and protocols are identified in the middle of the diagram. At the same time, there are some shared services that are shared by business objects within a business system domain. These services must be used in consistent ways to support execution in a distributed computing environment. Figure 3.1, Business Object Context This model depicts a particular approach to implementing systems in a distributed objects environment. This model is targeted at systems typically described as commercial information systems. The scope of application is very large, but it is not expected to include all distributed objects systems. For example, the model may not apply to engineering design or real time systems. This section examines various aspects of this model is some detail It begins with a discussion of type managers, describes the use of shared services, and describes the implications of the business system domain.. 3.1 Type Managers A type manager is an object that represents all instances of a type and its sub-types. One type manager object will exist in a business system domain (see Section 3.3) for each “managed” business object type. The type manager provides the interface for such facilities as querying all instances of a type (the extent), creation of an instance of a type and notification based on type. The following paragraphs describe the primary type manager capabilities. 3.1 Life cycle Interfaces for life cycle operations—create, delete, copy and move—of business objects must be consistent and accessible for different business object implementations. In addition, it is expected that business objects may only be instantiated in memory (activated) when they are in use or to minimize the frequency of database accesses. The activation and deactivation of objects is expected to be managed transparently. The focal point for instantiation of objects (i.e, for create, copy and move operations) is the type manager where the type manager implementation is expected to determine the appropriate location of the instance (i.e., selection of a factory) based on resource and performance considerations. 3.2 Queries Queries are a mechanism for gaining access to a set of business objects that meet certain selection criteria. Each type manager should provide the mechanism for application of queries against all instances of its type and sub-types. Such queries may traverse multiple databases and involve instances that are active in different address spaces. A query result is an iterator for access to the instances that meet the query criteria along with selected attributes. An iterator, may also be queried to further refine the selected set. The scope of a query will always be within a business object type. This abstraction enables frameworks to use various mechanisms to implement the query and manage activation of the relevant objects. 3.3 Introspection Introspection is a capability to access information about objects of a type. This is of particular interest for general-purpose tools for testing and debugging. The type manager for each type should provide access to the available meta data for that type. 3.4 Type-based dependencies A type-based dependency is a mechanism to obtain notices of specified events from all members of a defined extent, i.e., all instances of a type and its sub-types. The events can be communicated to an event service and consumers of the events can then register with the event service to receive notice of the events. Alternatively, each notice can be directed to a specific consumer. 3.5 Relationship-based dependencies A relationship-based dependency is a mechanism to invoke an action on an object whenever a specified change occurs in a related object. For example, the total price on an order should be re- computed if the price of any of its order items changes. By establishing a relationship-based dependency on items, when an item changes, its associated order will be notified and the total price will be updated. A relationship-based dependency is registered with the type manager of objects of interest, and when one of these objects changes, the notice is directed to objects related to it through a specified relationship. Relationship-based dependencies are defined for all members of a defined extent, i.e., all instances of a type and its sub-types. When an object is added to the relevant relationship, a dependency is implicitly established. A dependency may be registered on any object without prior programming. The dependent object must implement appropriate logic to perform the dependent operations when notified of a change. In this way, new objects can be introduced into an environment and establish dependencies on independently developed objects that were not pre-programmed for the dependency. 3.2 Shared services There are a number of supporting services that must be shared for business objects to interoperate. The following paragraphs describe these services. 3.2.1 Transaction Service The transaction service is fundamental. It provides the basis for concurrency control and recoverability of persistent objects. Within the context of a transaction, a message may go from one business object to another, and a subsequent message, within that context, may be sent back to the first business object. When actions pass through different implementations, the transaction context must be maintained. Actions on a business object within the context of a single transaction, must be recognized as being in the same transaction so they are not blocked. Commit and rollback operations must be communicated to all objects affected by a transaction, regardless of the language, platform or software product in which they are implemented. It is possible to initiate a sub-transaction, but the sub-transaction must still carry appropriate information about the containing transaction(s). 3.2.2 Current Session A CurrentSession object is associated with each transaction and provides information about the overall activity occurring within the context of the transaction. The information provided by the CurrentSession may, for example, include attributes that affect locking modes and selection of servers or devices based on the location of the originator. 3.2.3 Name Service Certain objects, such as type managers, must be accessible by name, independent of their implementation. In addition, business solutions may require the association of user-defined names with particular business objects. The binding of names to objects must be through a shared name service context so that the bindings can be accessed from any implementation. A single root name service context should comprehend the scope of the Business System Domain (BSD) discussed below. 3.2.4 Security Service In a shared objects business system, an integrated security system is essential. Users must have a single sign-on to access information from business objects within different implementations. Credentials must follow the actions as an operation extends to different business objects. 3.2.5 Notification Service While business objects are capable of emitting events on request, it will be appropriate to make some events generally available through an event channel of an event service. 3.3 Business System Domains A business system domain (BSD) is a distributed objects system that applies to a particular business domain, executes under the control of the associated business entity or organization, and maintains a consistent, recoverable representation of that business domain. The BSD may be as small as a solution to a particular problem, or as large as the information for an entire enterprise. The size of a BSD will be a function of a number of technical and administrative factors relating to reliability, manageability and flexibility of systems. The same system implementation executed by a different organization will be a different business system domain, e.g., the same system executed under independent management in different field offices. Figure 3.2 illustrates the federation of several BSD’s. This federation is accomplished through the use of adaptors, discussed later. Each BSD contains a complete representation of the domain of interest. An adaptor allows a business entity to be represented in one domain and linked to its primary representation in another domain where its shared state and behavior are implemented. Several domains may represent the same business entity from different perspectives. This allows domain models to be developed relatively independently and later federated. Figure 3.2 Business System Domains The scope of a business system domain is important because it defines the scope of concern for a number of issues. Those issues are discussed in the paragraphs that follow. 3.3.1 Modeling Since a BSD is a single, consistent representation, it is an implementation of an integrated model. Within this domain, there will be a one-to-one correspondence between an identifiable business entity in the real world and a business object that represents it. Roles and associations of these entities will also represented consistently by additional business objects within the domain (see roles, below). The same entities may also be represented in other BSD’s by objects having different interfaces as well as different roles and associations. A BSD may implement a composite of integrated models, and different BSD’s may implement the same model (e.g., multiple divisions in an enterprise). The BSD may incorporate a number of component business models, some of which may be incorporated in other BSD’s. A BSD is a run-time instantiation of these models used to support a particular business entity. 3.3.2 Recoverability The objects within a BSD are maintained and recoverable to a consistent state. Thus if some of the objects in a BSD must be recovered to an earlier state, then they all must be recovered to the earlier consistent state. If a transaction is rolled back, then it must be rolled back for all affected objects in the BSD. The relationship of objects within the domain to objects representing the same entities in other BSD’s is less controlled and may require synchronization if consistency between the domains is important (see below and the discussion of adaptors, Section 5.3). 3.3.3 Inter-domain sharing Different BSD’s may incorporate representations of the same entities. These domains may share some of the state and behaviors for these entities through the use of adaptors. The domain containing the adaptor is dependent upon the referenced domain which contains the primary representation of the shared entity. The object in the primary domain should function independent of the adaptor in the dependent domain. If the adaptor contains none of its own state (no additional attributes or relationships) then it may be a transient business object. It is possible for BSD’s to be peers so that for some objects, one domain is dependent and for other objects the other domain is dependent. In such cases, the logic related to the adaptors in each domain must recognize that the state incorporated into the adaptor may change independent of the control of its domain. 3.3.4 Name Scope A business domain defines the scope of names in an associated name service context. Names can be bound to objects within the business domain using a name service. The names in the associated name service context will include only those entities known to and represented in the business system domain. In a BSD, some business entities may be represented by adaptors. Since an adaptor represents an entity with a primary implementation in another domain, a persistent adaptor may have an external name bound in its local domain name service, and it may have a type manager for adaptors of its type. In this way, the name space of the dependent domain may be extended when new entities are added by reference to the remote domain. This is particularly appropriate when the adaptor contains local state that is persistent. 3.3.5 Relationships Managed relationships between business objects should not cross BSD boundaries. Cross-domain relationships would imply that the two domains comprise a single, consistent model, and these relationships would also require that the two domains be recoverable to the same consistent state. Adaptors will necessarily have a reference to the corresponding entity in the remote domain. Ad hoc notification on the primary object may be used by the adaptor to track changes in state of the primary object or the invocation of selected operations. In this way the dependent domain may exist in a less secure environment and not jeopardize the integrity of the primary domain. It is expected that the primary domain may be the source of information on the entity of interest for multiple, dependent domains, and is either designated the master for purposes of synchronization, or is the domain most reliably updated to reflect changes occurring in the real world. The adaptor reference to a foreign object is not considered a relationship. Adaptors should incorporate logic to manage these references and resolve inconsistencies that may develop between the two domains. Adaptors can participate in relationships within their local BSD. This provides appropriate representation of relationships without the relationships crossing BSD boundaries and jeopardizing the integrity of the BSD. 3.3.6 Roles In some cases, an entity participates in different business processes for different purposes or under different circumstances. When this occurs within a BSD, the different purposes or circumstances may be represented by roles. For example, a person may participate in activities in the same domain in the roles of manager, team member, committee chair and matrixed product manager. Each of these roles is represented by different business objects, but they all refer, directly or indirectly, to the person object as the primary representation. Each role provides the interface(s) appropriate for the activities in which it participates. A role, therefore, represents the principal entity in a particular context; the context may be explicit, through a relationship, or it may be implicit by virtue of the scope of the business system domain (e.g., an employee within a company). A role will use delegation to incorporate appropriate state and behavior from its parent object. See also the discussion in Section 5.2. 3.3.7 Extents An “extent” is the set of all objects of a particular type within a BSD. An extent defines the scope of a query on the type. Thus the BSD determines the scope of all queries. The type manager provides the abstraction for access to instances of a type active in different address spaces and stored in different databases within the BSD. The result of a query can only return objects that are known to the BSD. 3.3.8 Security Since the objects within a BSD are interrelated and represent a consistent state of the business, the general level of security of the system should be consistent for all objects in the domain. For example, under most circumstances, it would be inappropriate for objects that are the basis for running an enterprise to be distributed across both shared servers and desktop computers since desktop computers are unlikely to provide an adequate level of security. The integrity of the domain is no more secure than the least secure server. Business objects requiring different levels of physical security and with independent security administration should be implemented within different BSD’s. Consequently, a BSD should be aligned with a security policy domain. On this basis, the primary level of security will be enforced at the BSD boundary. The security service will provide restrictions on the object types and methods which may be accessed from outside the domain, and may be used to control messages from within the domain to objects outside the domain. For some domains, messages between objects within the domain may not require security constraints. 3.3.9 Domain manager object A business system domain should be identified by a unique CORBA policy domain manager object. As defined by the CORBA specifications, a policy domain object may manage policies relevant to the objects within the domain. The BSD domain manager is expected to be distinct from its security policy domain manager although, in most cases it is expected that the domains will contain the same set of objects, i.e., they will define coincident domains. 4. Business Object Semantics Business objects will implement some modeling semantics that are not evident in their IDL interface specifications. This sub-section provides a discussion of a number of these semantics which should be specified to provide sufficient information for defining the expected behavior of an object. 4.1 Pre/Post Conditions Pre and post conditions generally apply to operations on business objects. The pre-condition defines the circumstances under which invocation of an operation is valid. The post-condition defines the condition that must exist when the operation is completed for the state of the object to be valid. 4.2 Invariants Invariants generally apply to conditions that must exist between business object attributes and related business objects. An invariant condition applies when a transaction that affects relevant attributes and relationships is committed. Evaluation of the invariant should be posted for execution when the current business transaction requests a commit. If the invariant fails, the transaction should be rolled-back. 4.3 Processes objects Processes may be represented with business objects the same as any other entity that occurs in the business domain. Consequently, a workflow management facility may be implemented with the process and activity objects implemented as specialized business objects. Some processes may be programmable at run time so that new processes can be programmed interactively and existing processes can be changed dynamically. 4.4 State Transitions Business objects may have formally defined states and state transitions. The formal state of a business object should be expressed as a current value of one or more state variables. A formal state variable is implemented as an attribute with enumerated values. Logic within the object will determine valid state transitions and the relationship between multiple state variables, e.g., one state variable may represent sub-states of another state variable. Typically, state transitions will be performed by logic internal to a business object, and the state variables will be declared as read-only. The business object logic is responsible for making available an appropriate events when state transitions of interest occur. Consequently, notification of state transitions may be obtained by monitoring either the state variable(s) or the transition events, assuming that the events of interest are defined for the type. 4.6 Relationship Types From a modeling perspective, there are a number of different types of relationship. The implementation of different types of relationships are implemented by the traversal of relationships during certain recursive operations. For example, if an object receives a delete_object message, the delete should traverse any “contains” relationships, and should remove itself from all other relationships. These operations are all within the implementation of the business object and should not affect the relationship interfaces. 5. Adaptability Mechanisms In the real world, systems cannot be conceived and developed to comply with a single, universal model, but must be adapted and integrated as composites. Independent models represent different perspectives on the business, or simply independently developed solutions. The following mechanisms are envisioned as ways models representing different perspectives or related business system domains may be integrated in a distributed objects environment. 5.1 Specialization Once consistent mechanisms are available and used to implement common business objects, it will be necessary to specialize the common business objects to meet the specific needs of users of those objects. This specialization may be accomplished through build-time inheritance, but it will be desirable that specialization be supported without access to common business object source code. In addition, it may be desirable to provide local specializations within the context of a large corporate environment. Run time specialization can be implemented through delegation. In delegation, a specialized object delegates much of its functionality to a “parent” object, but may override the parent functionality with its own methods where required. The parent may be an abstract type that is parent to many specialized instances and may provide default instance variable values as well as methods. 5.2 Roles Roles represent the participation of a business entity in a particular context. For example, an employee is a role of a person in the context of the employer. Roles use delegation to incorporate the data and functionality of the parent business object, but unlike simple delegation, above, the role extends the state and functionality of the parent object for its participation in a particular context. A role will have a relationship with the parent entity and may have a relationship with an object representing the context. In relational modeling terms, a role is an associative entity defining the association of a parent entity with a context entity. In some cases it is not necessary to have an explicit relationship to the context if the context is implicit in the model. For example, employee and customer may be implemented as roles of a legal entity (e.g., a person or corporation). The context of these roles is the business enterprise for which the BSD exists. Consequently, it is not necessary to have a relationship to the enterprise object. Figure 5.1, Roles with Roles Roles are generally used within a model to represent participation in different activities or business functions. For example, from time to time an employee may be a manager or a project resource, as depicted in Figure 5.1. Note that roles may have roles and an entity may have multiple roles of the same type at the same time. The employee is a role of person and the manager is a role of employee. Employee has two roles: manager and resource, and could have more. An employee could be a resource for several projects, each represented as another resource role. Each of the roles has a context—the enterprise context of employee may be implicit. The addition or removal of roles does not change the underlying entity, but the role provides ad hoc extension of the entity for particular purposes. A role will not, as a rule, be interchangeable with its primary entity object since it exists to represent the primary object in a context not supported by the primary object. For example, a project resource may be a person or a machine. The resource role object cannot be substituted for a person (at least for most processes) and a person object cannot be substituted for a resource in a project planning process. Generally, a role object will not be a member of the same extent as its primary object. On the other hand, there may be some interfaces inherited by both the role and its primary object that allow them to participate in the same processes. A role object will often be implemented with different tools, components, language and platform from its parent object. It may be part of an extension to an existing model to support added business functionality. 5.3 Adaptors Adaptors perform a function similar to roles, except that they relate the representation of an entity in one business system domain (discussed in Section 3.3) to the same entity in another business system domain. Generally, the adaptor is a “surrogate” in one model for a primary or master representation in another model. An adaptor can transform method signatures to provide an interface which is semantically consistent with the model in which it exists. It is loosely coupled to the primary object so that it can be added on an ad hoc basis and the integrity of the primary object does not depend on the adaptor. 5.4 Legacy integration A legacy system represents a category of implementation of an independent model that is not designed for interoperability. There are two fundamental approaches to integration: 1. Functional integration. The functional capabilities of the legacy system are integrated by invoking them through message calls. It is expected that this will be implemented with one or more adaptors which will translate message sends in the distributed objects environment into appropriate function calls in the legacy system environment. 2. Database sharing. The distributed objects system may share the legacy database and use it as the persistent storage for business objects. In this case, the database provides concurrency control between the two systems. In general, because the state and logic of the legacy system may be outside the control of the business object implementation, objects that interface to legacy systems may only implement a limited level of compliance with full business object implementations. Glossary Adaptor. A specialized business object that adapts the representation of another business object in a different business system domain (BSD). For example, where a resource adaptor in an project management application represents an employee object that is shared in the enterprise domain. An adaptor delegates message processing to the implementation of methods on the primary business object. It may translate the method signatures from the form received to a form acceptable to the primary object in order to translate the semantics of different domains, or to adapt an independently developed application. An adaptor may also have local methods and instance variables which extend its capabilities beyond that of the primary object to meet local requirements. Ad hoc notification. A mechanism by which any business object can be asked to provide notices of events, such as changes in one or more of its attributes and relationships. A request specifies where the notices are to be directed. The business object has no prior specific programming to provide the requested notices. Ad hoc notification may be used to keep displays up to date and to initiate processes on other business objects. Business system domain (BSD). A run-time, distributed system that implements a consistent business model, is managed by a single business entity, is maintained consistent with revisions and is recoverable to a consistent state. Different business system domains may interoperate, but must be loosely coupled through adaptors to achieve compatibility and maintain integrity within each BSD. Related BSD’s may operate on different schedules and will have independent administrative controls. Business object. An object which represents a corresponding entity in the real world of the business. A business object has identity that corresponds to the identity of the real-world entity. Business objects are (usually) persistent and recoverable. Operations on business objects are in a transactional context that assures concurrency control and supports commit and roll-back operations. Composite object. An object which “contains” other objects in order to provide a composite representation of a concept. Commit. The action of finalizing and making persistent the results of a process—the action taken to finalize a transaction. It is also the name of the second phase of a two-phase commit where the first phase is “prepare.” The two phase commit is used to coordinate the completion of actions of multiple, distributed persistent resources (e.g., databases). It is essential that either all resources commit or none commit to assure the integrity of the system. CurrentSession. An object containing information that is implicitly passed along with a transaction to provide information about the current transaction. It will contain information related to the source and nature of the transaction being performed which may be used to assign objects to particular servers, select locking modes, or observe user preferences. Delegation. A mode of operation whereby an object delegates operations to another object to be performed. Essentially the delegating object incorporates some or all of the behaviors and state of the object to which it delegates (the parent). Dependent object. An object which derives persistence and relevance from the object which contains it. Objects assigned to business object attributes are dependent objects. They have no unique identity and are typically passed by value rather than by reference. Event. The occurrence of a named circumstance. Events are (1) intrinsic: circumstances that occur to all business objects, (2) implicit: changes of state in attributes or relationships, or the invocation, completion or failure of an operation, and (3) programmed: circumstances or state transitions that are identified in the business logic of an object. Event Service. The event service provides a shared mechanism for distribution of events to interested consumers. An event service will typically provide an event channel for particular types of event. Suppliers of the event will direct events to the channel. The channel will then direct the events to consumers that have previously requested notification. Extent. The logical set of all members of a type and its sub-types within a business system domain. The extent of a type defines the scope of queries on the type—it is “all known instances” of the type. External identifier. Any code or string of characters provided by the user or an external source that can be used to identify an object. The context of the external identifier is required to determine its meaning and its association to a particular object, as where a room number only has meaning within the context of a particular building. The Name Service may bind the same object to many external identifiers if this is useful to the user and the application. Immutable object. An attribute is allowed to return an object by reference if the object is immutable. This means that the interface accessible through the reference does not provide any methods which can change the state of the object. The creation and modification of the object then remains under the control of the object which provided the reference. This provides control over the integrity of the parent object and allows it to support notification of changes. If a new object is assigned to the attribute, it is copied and becomes a dependent of the object containing the attribute for purposes of concurrency control and persistence. Introspection. The ability of an object to provide information about itself. A fundamental level of introspection is the ability for an object to identify its attributes and relationships. Such information can be very useful for the implementation of generalized tools. Invariant. A condition which defines the legal state of object attribute(s) and relationship(s). Typically, an invariant will be evaluated after a number of operations have been applied to change the state of the system, when the new state of the objects is intended to be valid and consistent. Iterator. An object which retrieves successive members or groups of members from a collection. An iterator may operate on a real or virtual collection, as where the members being returned are not determined until they are requested. Iterators are used to access the collections implicit in one- to-many relationships, to provide query results and for other situations where access is provided to a controlled and/or shared collection. Legacy system. A legacy system is typically a system implemented in another technology which is either being replaced or “wrapped” to take on the character of the target technology. In general terms it is a system that does not comply with current architectural specifications for the computing environment or is in some way incompatible with systems currently under development. The primary concern with legacy systems is integration and/or migration. Integration involves efforts to build an transparent interface for cooperation. Migration involves replacing components of the legacy system until it is no longer needed. Life cycle. A set of operations on objects related to their creation and destruction: create, destroy, copy and move. For business objects, this is extended to include activate, retrieval from persistent storage, and passivate, removal from main storage. Location. A specification of a network node. The Location object contains a URL for a host computer which may be used for management of workload distribution to optimize performance. Name Service. The Name Service associates (binds) names, usually identifiers that are meaningful to humans, to object references which are the identifiers used to send messages to objects. It is expected that there is one name service within a business system domain. Object key. One or more concatenated attribute values, separated by tildes (~). This key uniquely identifies a business object within a business system domain and within its type extent. Object reference. The value passed by object request brokers for reference to an object. The object reference identifies the address space and the object within the address space. Pass-by-value. A mode in which arguments or return values for messages are copied into the receiving address space rather than being identified by an object reference as a remote object. Business objects are not passed by value since they have unique identity and should not be casually replicated. Dependent objects (except for immutable objects) are passed by value. Passing by value reduces network activity for interactions with these objects. Persistent. Objects are persistent if their state information is preserved when the computer is turned off. Typically this means that their state is stored in a database. Business objects and their associated dependent objects are expected to be persistent. Post-condition. A conditional expression which defines the valid state of an object after a specified method has executed. Pre-condition. A conditional expression which defines the required state of an object before a specified method can be validly executed (i.e., for the associated message to be acceptable). Prepare. The name of the first phase of a two-phase commit where the second phase is “commit.” The two phase commit is used to coordinate the completion of actions of multiple, distributed persistent resources (e.g., databases). It is essential that either all resources commit or none commit to assure the integrity of the system. Query. A process by which information meeting certain criteria is selected from an extent or the result of another query. A query returns an iterator, which provides access to the resulting set of selected members, which may be real or virtual. The iterator will return individual or groups of members from the set on request. The iterator is also a query evaluator and can be asked to select members from its set and provide another result iterator. Relationship. A reference of a business object to one or more other business objects. A one-way relationship is allowed to reference one business object. Relationships are binary as opposed to n- ary, meaning that there are two types of objects with two different roles in any relationship. N-ary relationships can always be implemented as multiple binary relationships and the implementations are much simpler and easier to understand. The cardinality of bi-directional relationships may be one-to-one or one-to-many, but not many-to-many. Many-to-many relationships can always be represented as two one-to-many relationships, and, in most cases, there will be a need at some time for the added associative entity. Relationships may also be bi-directional, meaning that if A has a relationship with B, then B has a relationship with A. Relationship-based dependency. A requirement for notification based on a relationship. A relationship-based dependency is requested from a type manager to apply to all instances of the type. Objects that are members of a specified relationship are dependents of the object containing that relationship. When a relevant event occurs, the object will notify all members of its relationship of the occurrence. Role. A business object which has a special relationship with a “parent” object. The role object delegates requests to its parent in order to incorporate some or all of the parent object’s state and behavior. A role relationship exists between the parent and its roles. State. The data of an object. Alternatively, the value(s) of some or all of the data of an object which determine a condition of interest. A state may be named, and the states of an object may be enumerated. A state may have nested states, or alternative conditions that may exist when the primary state is true. State transition. The occurrence of a change in the state of an object. More specifically, the change from one named state to another. Certain events may be associated with a transition from one state to another. State variable. An attribute value may designate the current state of an object so that the enumerated values of the attribute define alternative, mutually exclusive states of the object. Synchronize. An optional third phase in the transaction commit process which occurs immediately before the prepare phase. Transaction serialization. The process by which the execution of multiple, competing transactions is coordinated such that the resultant impact on the system is the same as if the transactions were executed in sequence, one after another. This assures that each transaction takes the system from one consistent state to another without interference from another transaction, and it assures that a system is recoverable to a consistent state which represents the completion of all committed transactions and the back-out of all un-committed transactions. Transaction Service. A CORBA service which accepts a begin message to establish a transaction context, provides for tracking resources affected within the transaction context, and accepts a rollback or commit message to terminate the transaction. Rollback and commit messages are implemented by either causing affected resources to roll back changes or causing them to commit changes, usually by updates to persistent storage. The transaction context is also used by affected resources to control concurrent accesses by different transactions. Type-based dependency. A dependency, i.e., a requirement for event notices, that is specified for a type and affects all instances of the type within a business system domain. All occurrences of the specified event(s) will be directed to the specified consumer object, which may be an event channel (of an event service) or another business object. Type manager. A type manager represents all business objects of a type within a business system domain. The type manager object is transactional and persistent, like business objects, and can have attributes, relationships and operations that apply to all members of the type. The type manager supports queries against all members of the type and its sub-types (the type extent), and it manages, directly or indirectly, the creation, activation and deactivation of members of the type. Type variable. A type variable is a stored attribute or relationship on a type manager which applies to all instances of the type and its sub-types. For example, on a Order type manager, the next order number might be held in a type variable. Business Object Concepts—White Paper 24 3 Business Object Concepts—White Paper 1 What is a Business Object? What is a Business Object 1 Dependent Types 1 3 Business Object Context Business Object Context 3 4 Business Object Semantics Adaptability Mechanisms 5 5 Adaptability Mechanisms Adaptability Mechanisms 5 Glossary Glossary