March 1998 1

Object-Oriented Frameworks

Wei-tek Tsai

Department of Computer Science and Engineering

University of Minnesota

Minneapolis MN,55455

tsai@cs.umn.edu

March 1998 2

What will be covered

• Issues in component based software development• Concepts of the framework

– What is object-oriented framework– What have been provided by the framework

• Framework Introduction– IBM San Francisco Framework

• Using the IBM SF framework• IBM SF techniques

– Enterprise Java Beans Specification– Microsoft COM+ Idea

• Framework based software engineering

March 1998 3

Issues in the Object-Oriented Software Development

• Software reuse– Software reuse is difficult, especially

• in large scale (enterprise level)

• cross business domain

• cross software platform

• cross hardware platform

– Most people reuse their own code, rely on themselves

March 1998 4

Component based software development

• Several Component model have been proposed to address software reuse and distributed objects management issues. Which helps to achieve the cross hardware and cross software platform software reuse.

• Component model is essentially based on the common interfaces defined at the class/method level.– Java Bean

– CORBA

– COM/DCOM ActiveX

• The “languages” for the object world.

March 1998 5

Issues in Component based software development

• Can component model solve the software reuse issues?– Currently off the shelf component reuse is almost

impossible• you just can not find the component you want.• you just can not find a proper shelf to put your

component on it.– Where to put/find?– How to put/find?– Which one to choose?– Why choose

– Although component has the facilities to talk to each other, they talk on different topics in different way.

March 1998 6

• To make components cooperate with other components(reusable), there are two approaches– Make them smart enough, so that they can understand

everything. Agent/Real Person?– To construct them into standard shape, so that they

understand something.• when different components talking on the same topic, they should talk in

the same way.

• build a standard host of components = define the shapes of the components = build the shelf for components

• different vendors’ components on the same position of the shelf can be reused by anybody who need the component on that position

Issues in Component based software development (cont.)

March 1998 7

Which approach is practical?

• To construct component into standard shape, so that they understand something.– Build the Shelf for the component, so that

• you know where should put the your component

• I know where I can find the component I want

– Limitations for this approach• To make your component can be reused by other people, you

can not design your component freely. Commit to certain shape is essential.

• To share components belong to different shelves is difficult

March 1998 8

What is a good shelf for components?

• Criteria for a good shelf– Based on the standard component model

– Support different hardware/software platforms

– Clear decomposition of the application domain

– Component should be reusable

– Component should be extensible

– Open standard

– ...

March 1998 9

What is object-oriented framework?

• OO framework is a set of cooperating classes that make up a reusable design for a specific class of software.

• OO framework is partially finished OO application. Application developers can extend framework to modify/add/remove existing functions provided by the framework.

• OO framework is the shelf for software components.

March 1998 10

What should be provided by a framework

• As a partially finished application, the following points are essential which should be provided by any framework– Architecture

• Layered architecture / Multi-tier architecture

– Object-bus• CORBA/COM/Java Bean/Others..

– Functionality• Based on Common requirement / Business requirement

– Extension rules• How to extend the framework

• It may also provide the following – Developing tools/Programming guide/Testing support …

March 1998 11

Framework Categories (Decomposed by functionality)

• Horizontal Framework– Provides common services for multiple application domains.

(distributed object management, transaction service and persistent service etc.)

– Example: • The base layer of the IBM SF framework

• WebObjects

• CORBA, ActiveX/COM/DCOM (Distributed object management)

• Vertical Framework– Provided for a specific application domain, contain more domain

knowledge. (banking, insurance and manufacturing etc.)

– Example:• The General Ledger provided by the IBM SF framework

March 1998 12

Framework vs. Class Library

• Class Library– static, use only

– Include • Design

• Code

– No application flow

– Can not be treat as an application

• Framework– dynamic, can be extended

– Include• architecture

• process

• design/code

– Application flow

– A mini application

March 1998 13

How to use the framework

• Use the services provided by the framework• Extend the functions provided by the framework• Application developers should expect change in

all the stages in the software development process (requirement, design, implementation, testing and maintain).

March 1998 14

What is the IBM San Francisco Framework

• IBM SF Framework is a sharable framework.– Defines a common architecture for applications in

different domains.– It allows different vendors to build their own component

for the framework.– Component developed by different vendors can be reused

by other people using the IBM SF framework

• A combination of horizontal and vertical frameworks.

March 1998 15

Goals of the IBM SF Framework (I)

• Flexible application business frameworks that reduce the complexity, expense, and time-to-market for software vendors to build customized multi-platform systems.

• Using San Francisco, software vendors can produce robust solutions built on top of high-level reusable business frameworks that are internet-enabled, scaleable and multi-platform client/server.

March 1998 16

Goals of the IBM SF framework(II)

To help application developers by:• Offering a common foundation for developing business

applications.

• Achieve large scale, cross platform, cross domain software reuse

• Providing a cost-effective way to add the capabilities that customers demand

• Allowing them to focus development resources to make their products unique

March 1998 17

A close look at the IBM SF framework (I)

• Architecture - Layered Architecture– Three major layers.

• Foundation Layer (Base Layer)

• Common Business Objects

• Common Business Processes

• Object Bus - Private bus– Has its own object bus implementation

– Not followed the common object bus standard, but similar to CORBA.

March 1998 18

• Functionality– Base Layer is a horizontal framework which provides the

common services for different application domains.• Naming Service• Distributed Object Management Service• Persistent Service• Transaction Service

– Common Business Processes layer provides domain specific functionality. Contains business requirement for banking domain.

• General Legal

A close look at the IBM SF framework (II)

March 1998 19

A close look at the IBM SF Framework (III)

• Extension Rules– Design patterns are widely adopted to help application

developers to use and extend the framework.

– Extension points are clearly specified through out the entire framework for application developers to extend the framework.

March 1998 20

A close look at the IBM SF framework (IV)

• Defines its own programming modals/rules based the Java language– For example:

• Class name with “impl” means the class represents a distributed object

• Dependent subclass’s name begin with a “D”, such as Dtime.

• Provides code generator for application developers

March 1998 21

Architecture of the IBM SF Framework

March 1998 22

The Base Layer (Fundamental Layer)

• The lowest level of the framework• It provides

– Foundation Object Model Classes• Entity/ Dependant / Command ...

– Kernel Services• Distributed Object Management

• Naming Service

• Transaction Service

• Persistent Service

– Utilities

March 1998 23

Foundation Object Model

• Class Hierarchy of several major classes of the Base Layer

• All these are interfaces defined in the Base Layer

Object

Base

BusinessObject

Dependant

Command

BaseFactory

Entity

DynamicEntity

March 1998 24

Entity Object• The independent, sharable, objects that are used in the

operation of the business.

• Often associated with data, it is the core to an application or framework

• Persistent Objects, associated with an underlying persistent storage mechanism.

• Example of Entity Object– Person, Account, Order

• Example of Non-Entity Object– String

– PrintMg (an object provides printing service)

March 1998 25

Entity Class Hierarchy

EntityImpl

Base BaseImpldestroy() equals(Object) externalizeToStream() initialize() internalizeFromStream() isIdentical() toString()

uninitialize()

Entity

isDirty()getHandle()notifyObserver()update()

Implements

extends

extends

March 1998 26

Dependant Object

• A dependant object is a lightweight business objects that encapsulate a small amount of data, usually it is not required to be saved in persistent storage

• If the dependant object is contained in an Entity, the dependent object will be saved in the persistent storage

• Transient Dependent objects can stand alone

• Example of Dependent– DTime

– Command

March 1998 27

Command Object

• A specialized type of Dependent object.

• Commands represent business tasks, calculations, and other actions that control or modify Entities.

• Support logging , redo and undo.

• Commands can be used to perform their task atomically or as part of a larger transaction.

• Commands can be created to execute their task in a remote server process or locally.

• Commands are often transient but may be persistent if contained in an Entity.

March 1998 28

Kernel ServicesDistributed Object Management (I)

• Provide platform independent distributed object management services, similar to OMG CORBA architecture

• Clients Function support:• Create instances of distributed objects

• Refer to an existing persistent object

• Create new objects

• Invoke methods on distributed objects

• Transparency

• Exchange complex parameters

March 1998 29

Kernel Services Distributed Object Management (II)• Naming Services

– Objects can be uniquely identified in the network

– Provide installation utility, similar to the registration process in the CORBA architecture

• Locking and commitment control– Part of the locking mechanisms of CORBA are supported (only

optimistic locking)

• Java Remote Method Invocation(RMI) is the major communication infrastructure used in IBM SF framework

March 1998 30

Kernel ServicesTransaction Services

• Most business objects in the San Francisco frameworks represent shared, persistent data and operations

• Entities can only been accessed as a part of a transaction

• The scope of a transaction is defined by using the following commands:– begin : Identify the beginning of a transaction

– commit : Identify the successful completion of a transaction

– rollback : Identify the unsuccessful completion of a transaction

– rollbackOnly : Notify that the current transaction can not be commit.

– getTransactionStatus: return the current status of the transaction

March 1998 31

Kernel ServicesPersistent Services

• Standard interface defined in the object Base– internalizeFromStream(BaseStream)

– externalizeToStream(BaseStream)

• Application developers should implement these in their own Entity to save/retrieve data to/from persistent storage

• From the application developer’s point of view, there is no difference whether the data is saved in a database of file system.

• Using configuration tools to configure the object container, either using odbc(save in database) or posix(save in files).

March 1998 32

BaseFactory Interface

• BaseFactory is the central interface to application developer of all the kernal services provided by the base layer

• Manages creating, deleting, and accessing all business objects in a distributed environment.

• Manages transactions, distribution connections, persistence, and security checks as objects are accessed.

March 1998 33

Base Factory Class Diagram

BaseFactory

EntityManagement

getEntity()deleteEntity()createEntity()dropAccess()syncEntity()

TransactionManagement

begin()commit()getTransactionStatus()rollback()rollbackOnly()

DependantManagement

copyDependant()createDependant()deleteDependant()

CommandManagement

executeCommand()redoExecuteCommand()undoExecuteCommand()

Other interface..

March 1998 34

Common Business Objects

• The middle layer of the IBM SF framework

• Object uses the services provided by the Base Layer.

• Most of the Common Business Objects are a concrete Entity, Dependant or Command.

• Common Business Object are general objects which can be reused in different business domains

• Examples of CBO:– Address– Company– BusinessPartner– CheckingAccount

March 1998 35

Common Business Processes

• The top layer of the IBM SF Framework

• Contains business requirement

• Build on top of the Common Business Objects layer, provides application flow and behaviors.

• A vertical framework with extension points, can be extended to build similar applications

• Represents the highest level of software reuse

• Examples of CBP:– The General Legal provided by the IBM SF framework

March 1998 36

IBM SF Framework (Background Information)

• 1.0 Beta Released August 15th, 1997• Java 270KLOC, C++ 15KLOC

• 3000 Downloads

• A complex object-oriented application, contains over thousand of classes.

• 1.2 will be available in March 1998 at Java One.– 3 times faster than the current version

March 1998 37

Building the IBM SF Framework(Background Information)

• Around 150 people involved in developing the IBM SF framework

• Skills used to build the IBM SF Framework– 40% Domain experts (based in European)

– 40% OO programmers

– 10% Application developers (above CBO)

– 10% Highly skilled OO designers/architectures

March 1998 38

Using the IBM SF Framework

• Use the framework at the Base Layer as a horizontal framework– Use general services

• Use the framework at the CBO layer– Use generic business objects

• Use the framework as the specialized Business Process– Application structure and behaviors of a special business process

– Use the vertical part

• Tradeoff between reusability and generality– The more reusable, the more general

March 1998 39

How to Use the Services provided by the IBM SF Framework

• Understand the IBM SF architecture

• Know the what services have been provided by the IBM SF Framework

• Understand how the services are provided to the applications using the framework

• Example:– How the Common Business Objects use the services provide by

the base layer.

March 1998 40

Layer Interactions Between the CBO and the Base Layer(I)

• Common Business Object are constructed based on the base layer– CBO can be shared by different applications since they are

constructed based on the same layer.

• The base layer provides its service to the upper layer in the following ways:– Conceptual interface (Foundation Objection model)

• Application developer should inherit from the conceptual interface in order to get the services provided by the base layer

– Direct method invocation• Similar to the class library

March 1998 41

Layer Interactions Between the CBO and the Base Layer(II)

Persistent ManagementDistributed Services(Naming Services, Remote Method Invocation,)

Entity Dependent Command

DomainApplication

Domainapplication

Common object1 object2 Object 3

Transaction ServiceSecurity services

March 1998 42

Using the Persistent Service (I)

• When you should consider to create a persistent object– The object can be shared by multiple users simultaneously at the

run time

– The object should be saved while the application is not running

(At the creation time, the object is associated with a form of permanent storage such as file system or data base.)

• Persistent objects– Account

– User

• Not persistent objects– PrintMg (an object provides printing service)

March 1998 43

Using the Persistent Service (II)

• How persistent service is provided in the IBM SF framework– Entity is an interface defined by IBM SF framework to provide

persistent service

– Object should inherit from the Entity/EntiryImpl to get the persistent services(Stored in the persistent storage).

– Factory design pattern is used to create new “Entities”.

March 1998 44

Using the Persistent Service (III)

• The Class Diagram and Methods of the Entity

Entity EntityImpl

• initialize {}• externalizeToStream {}• internalizeFromStream {}• toString {}• ...

• initialize • externalizeToStream• internalizeFromStream• toString• ...

Method Definition Method ImplementationProperty definition

implements

March 1998 45

Using the Persistent Service (IV)

Entity

CheckBook

EntityImpl

implments

extends CheckBookFactory

• createCheckBookCheckBookImpl

extends

implments

March 1998 46

CheckBookName

Address

Balance

CreditLimit

Password

getName/setName

getAddress/setAddress

getBalance/setBalance

getCreditLimit/setCreditLimit

getPassword/setPassword

Using the Persistent Service (V)

CheckBookImpl

CheckBook

EntityImpl

Entity

CheckBookFactory

createCheckBook

Override methods defined in EntityImplexternalizeToStream(), initialize(),internalizeFromStream(), toString.

Method definitions

Property definitionsMethod implementations

March 1998 47

Global.factory().begin(); // transaction begin

checkBookInst = CheckBookFactory.createCheckBook(…);

// BaseFactory.createEntity() is called in this method. The framework

// will create a new instant of the CheckBook entity .

checkBookInst.setBalance(1000.00); // set property

checkBookInst.setName(“Hello”); // set property

..

Global.factory().commit(); //transaction commit

// the externalizeToStream() will be called to output the data to the

// persistent storage.

• Here also the transaction service is used by using direct method call.

Using the Persistent Service (VI)

March 1998 48

What is affected if I use the base services (IBM SF)?

• Object Creating, Deleting, Copying, Accessing, Updating– you never can use new() to create a new instance of class in SF.

– Entity is a persistent object, new entity should be created within a transaction and must be committed to make sure it is save in the persistent store.

• If you don’t use the base services?– You can’t use the entire framework at all.

March 1998 49

Extending the IBM SF Framework(I)

• Extends based on the framework only– Extends the framework at the CBO layer

– Create a new Common Business Object for your own application

• Extends based on the applications using the framework– Change the CBO provided by other applications

– Replace the CBO provided by other applications

March 1998 50

Extending the IBM SF Framework(II)

• Find out the extension points specified by the framework designers– IBM SF framework specified the extension points in the

framework

– Design Patterns are used in the implementation of the extension points

• Follow the extension mechanisms have been provided by the framework– Different extension mechanisms are provided for different kinds of

extensions.

March 1998 51

The mechanisms to extend the IBM SF Framework(I)

• Subclass to add new business object class

• Subclass to replace an existing SF business object class

• Extending SF classes through aggregation

• Extending a framework class through properties

• Adding attributes

• Sharing attributes

• Adding relationships

• Overriding methods

• Overriding method’s preconditions

March 1998 52

Extending the IBM SF framework (II)

• The Design Patterns used in the Extension Points– Policy (similar to strategy)– Controller (similar to proxy and broker )– Key/Keyables (similary to Dictionary)– Extensible Item (dynamic change property)– Factory (Factory Method)

March 1998 53

Using IBM SF framework Requires

• A modified software process – Framework Oriented Analysis, Design, Implementation and Testing

• Understand the entire architecture of the IBM SF framework

• Follow the rules defined by the framework– Class diagram

– Class relationship

– MtSS, MgSS rules of the classes provided by the framework

• Following the programming model of the framework– do not use the new function of the java standard package

– do not use the synchronized method of the java standard package

March 1998 54

What are the issues for using the IBM SF framework?

• Only can be shared within one framework (Reuse is achieved within the framework)

• Unable to access lower level services of the system

• The underlying level provides similar service as CORBA and Java Bean, but the IBM SF framework does not use these industry standard distributed object management techniques, this make it a sort of private framework.

• Long learning curve

• Hard to test in the distributed environment

March 1998 55

Do we really need framework?

• Software reuse is still a difficult task– Reuse cross platform, cross domain, large scale(80%)

• Off the shelf component reuse is still difficult– You just can not find the components you want

– where/how/which/why

• Most people reuse their own code, rely on themselves

March 1998 56

References• IBM San Francisco Framework Document. Ver 1.1 beta.

– Programmer’s Guide

– Extension Guide

– Administrating and Configuring Guide

– Concept and facilities

• WebSite– http://www.ibm.com/java/Sanfrancisco