Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

Framework and Objects

APRIL 1999

Framework and Object Descriptions

Introduction

The InfraSet Framework supplies business object services to non-visual business-process components - the business classes of middle-tier components. The Framework supplies a line of business (LOB) class with the fundamental attributes and behaviors of a business object that persists within a relational database and is available to clients through ActiveX/COM/DCOM. It also supplies important services and features to all types of client programs and visual components of a business system.

The Framework supplies the following business object services that are essential to multi-tiered component architectures:

· Line of Business (LOB) object brokering services
· Instantiation control services
· LOB object configuration and assembly services
· Database connection management
· Object-to-relational mapping services
· Database access services
· Business object persistence services
· Business object collection and property management services
· Business class association (related-object) services
· A universal business meta-object or base-class that adapts InfraSet services for any LOB class
· Well-defined business object interfaces for use with any LOB object or collection-object

The Framework's BusinessContext object is a general-purpose business object request mechanism, a LOB broker-object. Its methods are used by clients to obtain named-collections of LOB objects and/or sets of persistent properties. Business class programs as well as presentation-tier programs obtain named-collections of LOB objects through BusinessContext methods. Named-collections function as named-object queries.

The BusinessContext utilizes nearly all of InfraSet's other services and features in brokering requests for named-collections of LOB objects. The definition of a named-collection includes the specifications for the underlying database connection and access procedures, and LOB object configuration and assembly instructions. Various Framework objects perform the underlying services related to database connection and access management, LOB instantiation and persistence, business-class associations, and the management of LOB objects and collection-objects for client programs.

The properties and methods of all Framework service objects as well the developer's LOB design objects are available for direct use and manipulation by client programs. The BusinessContext object and other primary service and support objects of the Framework are described within this document.

General InfraSet Concepts

The InfraSet run-time component instantiates the Framework with the Repository-based design objects of a business system. This configures InfraSet's BusinessContext object-broker and other Framework objects at run-time rather than compile-time, according to the design requirements of the line of business system.

InfraSet's general-purpose business object model, InfraSet.Model, encapsulates a set of common business object services related to persist property managment and it acts as a base-class or model-object for use within any line of business class. This meta-object models the property collections and object relationships for any line of business object and it encapsulates the Framework services for use by the line of business system. It supplies methods to LOB objects which reflect InfraSet object request and persistence services, and it supplies a general object model for LOB properties.

The Framework's object model functions as an extension of the line of business (LOB) object model. It extends the LOB object's unique business-process methods and properties with the Framework's reusable methods and properties. InfraSet's features abstract database access and persistence operations and provide underlying COM object instantiation services.

The business application's use of Framework services removes these complexities from the scope of LOB development. They enable the focus of line of business software development to be almost exclusively upon business-process rules and presentation issues, rather than the development of complex instantiation control and object-to-relational persistence service models.

With InfraSet, the line of business developer retains control over instantiation, persistence, and related-object services but does not have to build the programs that deal with object-to-relational mapping and translations, database access services, object relationship management, or business object request and interoperability models.

The Framework is utilized throughout the development life-cycle and the operational deployment of line of business component systems. Line of business classes implement Framework interface classes, and use the InfraSet.Model to obtain persistent properties.

The Framework supplies integrated business object features and services to LOB developers through ActiveX /COM/DCOM. The Framework contains member objects that are responsible for assembling line of business object collections. It automatically performs the underlying processes of database access for the LOB object, instantiating LOB objects and populating them with persistent properties, managing LOB object persistence and relationships between different LOB objects.

Framework methods supply a general-purpose object request mechanism that may be used by both business classes as well as UI programs. UI programs may request LOB objects directly through InfraSet methods or indirectly through business class methods that may wrap InfraSet's general object request services with specialized LOB request mechanisms.

In addition to object request methods, the business class generally utilizes many additional Framework services and member objects.

The Framework's object model includes two general classifications of member objects; Design Objects and Service Objects.

Repository-based Design Objects
Design objects supply specifications that control how Framework service members will actually perform the assembly and construction of LOB objects. Repository information for the line of business system is instantiated as Design objects within the Framework. Design objects control how InfraSet's run-time services are performed with different database engines and server/business-class configurations.

The developer using the InfraSet Repository Engineer program typically creates Repository-based Design objects. However, they may also be created by the business program at run-time and then used to control services. Design objects may also be created and stored within the Repository through developer-written programs.

Repository-based design information provides for the identification of named-collections of LOB objects and the underlying specifications necessary to their assembly. Named-collections are identified through Action objects. They are effectively the recipes necessary to define which objects and what parts of an object are to be produced. They tell the Framework Service members how to use database procedures and assemble the LOB collection from database information and business class programs.

Named-collections represent specific instances of business objects with various configurations of property collections. Their underlying specifications describe the business component servers, business classes, database engines, and physical databases that are involved in constructing and assembling the specific collection. Additional details identify related business objects, describe object-to-relational mapping information, identify underlying database procedures or commands, and describe the persistence methods that are appropriate to each LOB collection.

InfraSet Design objects are stored within the Repository. They have methods that control their creation as well as their persistence within Repositories (Setup, Update, Delete, etc.). Design objects can be created at run-time and stored in a Repository under program control - without use of the Engineer interface program.

Design Objects are purple in color within the attached object diagram.

Framework Service Objects
Service Objects utilize design object specifications and perform the actual process of assembling line of business objects in response to client requests. They perform the underlying database access, instantiate the business class and populate it with persistent properties.

In addition to instantiation control, Service objects also supply common business object attributes and methods that are implemented by business class programs. These methods supply any line of business object with persistence services, business object relationship management, state management, database transaction management and transaction context control.

Service objects are blue in color within the attached object diagram.

The Framework Object and its Members
The Framework object represents the instances of the InfraSet run-time engine. All InfraSet services are provided through the Framework and its members. It provides access to the repository-based Design-object properties and methods for the business system as well as InfraSet's run-time Service-object properties and methods.

The Framework supplies globally declared methods that utilize the properties and methods of its various member objects.

The Framework directly manages the following types of collection objects; Databases, ConnectionContext, Servers, BusinessContext, Messages, and Profile collections.

Database Object
A Databases object manages a collection of Database objects. Each Database object manages a connection to a specific database engine that's being used as a data store. When a Database object is defined in the InfraSet Engineer program, it is given database connection and user identification properties for each database engine to be supported. An attribute that's set in the Repository tells the Database object which database engine to access.

The Database object has begin transaction, commit transaction, and rollback methods that are operative across multiple databases. All Action objects reference a Database object.

ConnectionContext Object
The ConnectionContext object is a container for Database objects. It is used to control database update "transactions". When a transaction is invoked on a ConnectionContext all of the context's related Database objects will be involved in the transaction. The ConnectionContext of a Database object is named at the time the Database object is instantiated. Each database engine has a default transaction set that is used if a ConnectionContext is not named.

Servers Collection Object
A Servers object manages a collection of Server objects. It contains a collection of Server design objects and their members that are registered for use with InfraSet per the Windows system registry.

Server Object
A Servers object manages a collection of Server objects. A Server object identifies a line of business component, an ActiveX DLL that contains LOB classes. It contains basic identification information necessary for InfraSet to use COM/DCOM to create empty instances the LOB class. A Server design object has associated Class and Action objects that provide InfraSet with the additional information necessary to populate the instances of the business class with persistent properties. The Server object contains a collection of Class objects. Each Class object represents a different business class that's defined within the ActiveX business component.

Class Object
Class objects represent a specific business class that receives InfraSet's services in the production of its business objects. The Class object controls the creation of business objects from ActiveX components. The Class object contains object-to-relational mapping information necessary to perform object requests and manage persistent properties. It also contains class association information that enables a business object to be aware of its related business objects and to request and manipulate its related business objects.

A Class object manages a collection of Action objects and a collection of Relationship objects.

Relationship Object
Relationship objects define how business classes are related to other business classes - how business objects are related. A Relationship object defines a relationship between two business classes. Related Business classes can be contained within the same Server or different servers (ActiveX business components).

A Relationship contains references to the mapping information necessary to fulfill the relationship for both business objects. This includes references to the Servers and Classes of each, as well as the Action used to retrieve the related business objects.

Action Object
Action objects are key arguments for InfraSet's business object request methods. Internally, an Action defines how a specific collection of line of business (LOB) objects is to be assembled for the client by InfraSet.

An Action is used by a client as a logical named-collection of business objects. It is referenced when InfraSet Framework methods, such as GetBusinessObjects, are used to obtain LOB collections within client programs.

At run-time an Action name is simply supplied by a client to identify a named-collection of LOB objects. It contains specifications that enable InfraSet to interact with a database, instantiate a business class and assemble LOB objects with persistent properties. The results of the business class operations are supplied to the client.

Clients supply Action names as arguments to Framework methods in order to request individual objects, object-collections, or incremental collections of persistent properties for already instantiated objects. They may be used with all of the InfraSet methods that create, retrieve, update and delete LOB objects (CRUD operations).

Action objects and their related specifications are typically stored within the InfraSet Repository. Actions contain references to other Repository design objects (Class, Server and Database) as well as the specific database procedures used to control database access and instantiation. Actions may also be programmatically created.

An Action identifies a set of one or more business objects that meet specific criteria. It defines the persistent properties that will be instantiated and it controls which InfraSet methods will be available to the collection. Actions are the recipes for assembling collections of line of business objects. And, they contain the data access information necessary to produce a database resultset which is then used by InfraSet assemble collections of business objects with persistent properties.

Action objects support the inclusion of run-time criteria and parameters. This allows the client to control which instances of a LOB are created at run-time.

Actions supply a business class with an InfraSet.Model object, a meta-object that contains the requested persistent properties and a set of Model methods that can be used by the business class for managing properties, performing persistence methods, and performing related-object methods.

Actions can also be used to produce strictly Model-based business objects without requiring a corresponding business class ActiveX DLL component - since InfraSet supplies general businss object services, a line of business class is not absolutely necessary if the class does not have unique business rules.

Action properties determine which persistence methods are available to the business class for use with the requested named-collection. Collections can be defined so that they are able to update themselves in a database or they can be defined as "read-only".

The database access specifications of an Action can support any type of select statement or other database operation that can perform database access, update or execute operations. This can include stored procedures, simple table references, or other database instructions such as a Microsoft Access QueryDef. An Action object references the specific database instructions executed by the database engine to produce a resultset. The resultset is used by InfraSet to populate the Model object of the LOB class.

An Action can contain a collection of database source statements and procedures for use with different database engines. This enables the use of alternate engines and data-stores for persistent properties. Support multiple database engines allows for database portability without impact upon client programs. An Action may contain references to different database procedures for different database engines, each of which produces equivalent results from their respective engine. For example, both a Microsoft Access QueryDef and a corresponding SQL Server Stored Procedure can be associated with a single Action. InfraSet manages database connections and enables an Action to produce the same logical collection of business objects from different relational database engines.

Action names are supplied as arguments when using Framework methods. They may also be referenced through default Actions that are assigned to the Class object. Under program control the parameters to an Action are often manipulated. However, a program typically does not need to directly manipulate a Framework Action object - change its properties or invoke methods of an Action object. However, under program control any Action may be examined and new Actions may be created, used and stored within the Repository.

BusinessContext Object
The BusinessContext performs the processes necessary to fulfill all types of LOB object requests and methods. It manages a collection of services used to instantiate business classes, assemble Model objects, and support their related methods (persistence, property, and related-object management).

All of the global Framework methods used to create, retrieve, update, and delete LOB objects implement the BusinessContext. Therefore, it plays a central, but typically behind-the-scenes role. Its role is more visible when the BusinessContext is used to retrieve the objects related to a LOB object. A BusinessContext is instantiated automatically whenever a LOB object references its related-objects.

Internally, a BusinessContext manages or utilizes the following Framework classes:
· A collection of BusinessObjects collections.
· A Server object.
· A Class object.
· An Action object.
· A Relationship object for access to related-objects
· A Properties collection-object for managing the parameters of an Action.
· An Identifier object.

A developer may directly control the instances of a BusinessContext to develop specialized object brokering routines and contexts for the LOB application. The LoadBusinessObjects method adds a BusinessObjects collection the BusinessContext.

BusinessObjects Collection
The BusinessObjects collection-object manages one or more individual business objects. The members of the collection can be all of the same business object, or it can be a hetrogenous collection of different types of business objects.

The methods of the BusinessObjects collection include full create, retrieve, update and delete (CRUD) for all of the members of the collection. For example, Update will invoke an Update method on all objects in the collection. The general behavior of a BusinessObjects collection is similar to that of a standard Visual Basic collection class. You can add objects to the collection using the Add method, you can remove objects from the collection using the Remove method.

Model Object
The InfraSet.Model is the vehicle through which InfraSet delivers of persistent properties and methods to the business class as well as the focus for the LOB object's use of related InfraSet services. The Model is an inner-object of an InfraSet-enabled line of business (LOB) object.

The Model is a meta-object with properties and attributes that are able to model the properties of any LOB object. The Model also has a set of methods that are supplied by InfraSet for manipulating persistent properties. The Model's methods perform persistence functions, relationship management, and property management services for LOB objects.

The Model is effectively a business object without business logic; a business object made up solely of persistent properties and related methods. Business-rule logic is supplied by the developer within a LOB class that utilizes the Model and InfraSet services. If a type of business object is without unique business logic, then the Model can be directly used as that object - without a business class.

Each business class receives an InfraSet.Model by implementing the InfraSet business object interface class, IBusinesObject. This enables InfraSet's run-time component to instantiate the business class and to populate the Model of the business class with persistent properties. Implementation of the IBusinessObject interface enables InfraSet to use the InfraSet.Model within the LOB as a vehicle for delivering persistent properties and related methods to the business class. Which properties are defined by a Repository Action - a named collection of business objects that is declared by client programs at the time of a business object request.

Independent of business class use of the InfraSet.Model, it can also play a useful role within presentation-tier UI programs. Because the Model is a meta-object representation it extends significant flexibility when used within any program. The business class developer may elect to expose LOB objects to clients through Model objects rather than through hard-coded business-class property declarations. And programs that may not directly utilize any InfraSet services may also be programmed to use the Model's meta-representation of the properties and attributes for a LOB object.

The InfraSet Model supplies the reusable generic methods and properties of InfraSet's base-class business object. It provides methods to read and write persistent properties within the database and to retrieve related business objects. It contains a collection of properties that are the persistent properties of any business object.

Upon client business object requests, InfraSet invokes database actions to retrieve persistent database information for the business class and packages it up into a Model. InfraSet uses the ActiveX Business Component defined by the Server object to create an instance of the business object. After a business object is created it is initialized with a Model that contains the persistent properties of the business class.

When the line of business object is instantiated the InfraSet.Model contains the following:

A collection of persistent properties based on the Action used to initialize the line of business object stored in the PropertyContext and accessible through the GetProperty and PropertyContext method. Services used to manage the persistent properties.

A reference to a BusinessContext, which can be used as an object broker for retrieving objects, related to the instantiated line of business object.

A BusinessObject's data mapping information such as, server, class, etc., is contained in its Identifier object and accessible through the Identifier property.

A InfraSet.Model object is created whenever an InfraSet enabled line of business object is instantiated. A InfraSet.Model is automatically passed into a line of business object via its Setup method during the business object's instantiation.

Additional Properties objects can be loaded into the InfraSet.Model with the LoadProperties method. The GetProperty method returns a Property object from the InfraSet.Model. The BusinessObjectContext.BusinessObjects method returns a BusinessObjects containing a set of related business objects.

The Update method commits changes to the object's persistent Property objects.

The Delete method deletes persistent Property objects from the database.

The Undo method cancels changes made to Property objects.

IBusinessObject Interface Class
The InfraSet Business Object interface class, IBusinessObject, is implemented all line of business classes in order to receive InfraSet services; instantiation, persistence, property management and related-objects. It enables InfraSet to deliver the line of business object's persistent properties and the related InfraSet services to the LOB through the InfraSet.Model object.

The IBusinessObject (IBO) interface may optionally be used by the business class as its interface for exposing business object methods and properties to LOB client programs. There are distinct software development and maintenance benefits of representing business objects to LOB clients via the IBO - it is a well-defined and comprehensive business object interface that also employs a flexible metamodel. It leverages a high-degree of interoperability between business class programs and client programs as well as significant benefits when used with ActiveX UI controls. However, using the IBO as a client-side technique is optional and a LOB class may expose its objects through any combination of the IBusinessObject class and the LOB's class interface. InfraSet's underlying services are available for reuse using either interface technique.

A line of business class implements the IBusinessObject (IBO) interface. The IBO has a Model Set property through which InfraSet "delivers" the Model to LOB objects. This enables InfraSet to perform instantiation services for the class and populate its objects with persistent properties through the LOB's reference to the InfraSet.Model object. And, since it delivers the InfraSet.Model, InfraSet delivers the Model's methods and properties to the LOB class for reuse.

IBusinessObject supplies a standard reusable interface and the InfraSet.Model supplies the LOB with properties and methods that that are common to all business objects. The Model supports property management, related-objects, and persistence features. These properties and methods are used by clients/consumers of business objects to perform CRUD operations and to access related business objects.

The LOB class may expose its business objects through the IBusinessObject (IBO) interface as well as through its own private LOB object interface. The IBO is a well-defined interface that addresses common needs and it provides for a high level of code reuse and interoperability between business class programs and client programs as well as significant benefits when used with ActiveX UI controls.

PropertyContext Object
A PropertyContext manages a collection of Properties collections for a business object. Seperate Properties collections can be retrieved as needed/requested and managed as a collective unit through the PropertiesContext. For example, the Update method of the PropertyContext uses the Update method of each Properties collection within the context.

Properites Collection Object
The Properties object manages a collection of Property objects. It represents a row of data from a database whose fields are the persistent properties of a business object.

The persistent properties of a business object that are retrieved from a database are packaged into a Properties collection. The initial object request (GetBusinessObject) produces a Properties collection. Any subsequent properties requests (LoadProperties) produces additional Properties collections for the same busienss object. The update method of the Properties class commits to the database any changes or updates to Property objects within a Properties collection. A programmer can also use a Properties object as a container for non-persistent properties.

Property Object
Each Property object represents a single business object property. The Model of a business object is made up of Property objects.

Each Property object contains data and meta-data. It contains the value of the property as well as other properties that describe the information. InfraSet will utilize meta-information to validate the correctness of changes to a business object property.

A Property object can be used by a business class to store non-persistent, derived business object properties. Property objects are also used to contain the values that are used as parameters to Actions and database select statements.

Attribute Object
Attribute objects contain additional information that describes a Property. Attributes include the meta-data supplied by the database engine. Attribute objects are instantiated when Property objects are instantiated. Standard attributes are used by InfraSet to validate changes to Properties.

A programmer can create custom Attribute objects that can be used within developer-written routines.

Identifier Object
An Identifier object contains the values that uniquely identify a LOB object. It contains information necessary to map a business object to its persistent data in a database. An Identifer can be used as a parameter for the GetBusinessObject method of both the Framework and the BusinessContext object.

A programmer may use an Identifier object when it is appropriate to manage identifiers separately from the other properties of a LOB object.

Message Object
A Message object contains a text message that is used to pass information from one object to another object.

Methods Bay, Inc. mailbox@methodsbay.com

phone: 530-673-6161 fax: 530-673-1945

Copyright © 1998 by Methods Bay, Inc. All rights reserved.
Trademarks ® and Acknowledgements