View
214
Download
0
Category
Tags:
Preview:
Citation preview
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 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
Recommended