IBM SanFrancisco Project

IBM SanFrancisco
H. C. Rikki Chang
Tang-Jung Huang
November 20, 2000
Introduction of SanFrancisco
 A Java-based collection of components that allows
developers to assemble server-side business applications
from existing parts.
Enable developers to build and modify business
applications quickly.
Provides the capability to make new Java components that
can be reused.
Enables software development to keep pace with the
changing needs of business. It helps companies bridge to
new applications and new markets.
Applications can be written once and run on a wide range
of servers.
Advantages of SanFrancisco
 Business Value
 Time to Market
 Competitive Position
 E-Business
 Market Opportunity
SanFrancisco Architecture
SanFrancisco is building three layers of reusable code for
use by application developers.
 The lowest layer, Foundation, provides the infrastructure
and services that are required to build industrial-strength
applications in a distributed, managed-object, multiplatform applications.
 The second layer, Common Business Objects, provides
definitions of commonly used business objects that can be
used as the foundation for interoperability between
 The highest layer, Core Business Processes, provides
business objects and default business logic for selected
vertical domains.
Foundation Layer
 It is the distributed computing infrastructure.
 Providing common cross-platform, cross-application
functions for application development and deployment.
 Includes Application Programming Interfaces (APIs) for
distributed computing services.
 Provides consistent behavior and common methods for
administration of applications.
 The basis for managing distributable objects in
Foundation Layer (Cont.)
 Promotes an architecture where a distinct object’s role
exists in the client/server paradigm:
1. Separation of user-interface from business logic.
2. Isolation from the underlying mechanisms for
3. Separation of command and selection logic from
business data and user interface.
4. Distribution of business processing to allow for optimum
Common Business Objects
(CBOs) Layer
 Contains behavior and business objects
commonly needed across business domains.
 Contains interfaces to the financial Core
Business Processes.
 Contains generalized mechanisms.
Core Business Processes Layer
 Contains behavior and business objects that
are particular to a business domain.
 Currently available:
1. General Ledger
2. Warehouse Management
3. Order Management
4. Accounts Receivable/ Accounts Payable
SanFrancisco Patterns
 The objective of SanFrancisco Business
Process Components is to enable solution
providers to produce customized multiplatform business applications.
 To achieve this objective, SanFrancisco
makes extensive use of design patterns.
What is a Pattern?
A general definition of patterns:
“Each pattern describes a problem which occurs over
and over again in our environment, and then
describes the core of the solution to that problem,
in such a way that you can use this solution a
million times over, without ever doing it the same
way twice.”
Source: Christopher Alexander, et al; A Pattern Language:
Towns, Buildings, Construction; Oxford University Press,
What is a Pattern? (Cont.)
A definition of patterns in object-oriented design:
“A design pattern names, abstracts, and identifies the
key aspects of a common design structure that
make it useful for creating a reusable objectoriented design.”
Source: Erich Gamma, et al; Design Patterns, Elements of
Reusable Object-Oriented Software; Addison-Wesley
Publishing Company, 1994.
Why use Patterns?
 The SanFrancisco patterns guarantee consistency
throughout the framework.
 Patterns systematically name, motivate, and explain a
general solution that addresses a recurring problem.
 Once you understand how the problem was solved using a
particular pattern, the next time you encounter the problem
or pattern, you will understand the solution.
 Sometimes the solution is customized to fit the special
conditions of a particular need.
About the SanFrancisco Patterns
Each of the patterns described are structured as
States the intent of the pattern or the problem it is intended to solve.
Gives a high-level description of how the pattern fulfills the intent.
Explains how the pattern serves the goals of extensibility and reuse.
SanFrancisco Patterns
 Factory class replacement
 Cached balances
 Commands
 Keyed attribute retrieval
 Property container
 Extensible item
 Policy
 Life cycle
 Chain of responsibility
 Hierarchy level
driven policy
 Token driven policy
 Controller
 Keys and keyables
 “Ables”/”Ings”
 Generic interface
 List generation
Factory class replacement
 Intent
Situations occur where a class needs to be
modified to support a particular business need.
Client programs which create, access, or maintain
instances of this class must be allowed to remain
ignorant of the modifications to the said class
unless they wish to use the new information.
Factory class replacement
 Concept
Factory class replacement allows for specifying a
substitute class that is created instead of the one
requested. When a client requests the creation of a
new object, it issues a request to the desired class
factory. The class factory requests the
BaseFactory(a SanFrancisco Foundation base
class) to create a new object. The BaseFactory
determines the actual class instance to be created,
which is returned to the client.
Factory class replacement
 Benefits
The obvious advantage of using this pattern is the
ability to replace a class without affecting any
users of that class. This relieves client programs
from the burden of needing to know about
unrelated changes to the classes it uses.
Developing applications on Top
of SanFrancisco
SanFrancisco allows you distribute your
business application and its contained
business objects across servers and clients.
This can be accomplished within a two-tier
or a three-tier architecture.
The two-tier architecture
 The two tiers are typically represented by a server
process and a client process.
 The client process provides the user interface,
most likely in form of a graphical user interface.
 This GUI may be developed using the
SanFrancisco GUI beans, or using the Swing class
 This has been referred to as a thick client model.
The two-tier architecture
The three-tier architecture
 This is called the thin client model.
 The third tier remains the same from the two-tier
architecture. It is where the server side business object
 The former client tier is split up into two pieces:
1. The first tier is responsible only for the actual user
interface, most likely in the form of a web browser.
2. The second tier handles user requests and delegates them
to the backend. This is usually implemented through the
use of servlets and/or Java Server Pages (JSP).
The three-tier architecture
 Many of the applications are developed following the
Model-View-Controller(MVC) design pattern.
 This pattern defines three different roles in an application:
1. Model represents the data that an application deals with.
2. View displays this data to a user, without knowing what
this data is all about.
3. Controller handles events triggered by the end user and
steers the flow of the application.
 SanFrancisco was started when several software
developers asked IBM for help in modernizing their
application products.
 These partners realized that their current applications
needed to be updated if they were to continue to be viable
products in the emerging object-oriented, network-based
 However, several barriers prevented them from being able
to update their applications.
 Barriers:
1. One barrier was the problem of how to retrain
their development staffs to be able to effectively
use object-oriented technology.
2. A second barrier was the risk involved in
moving to a new technology.
3. A third barrier associated with moving to
object-oriented technology was the cost of making
the change.
 SanFrancisco helps solve these problems by offering solution
developers business process components, that provide an objectoriented infrastructure, a consistent application programming model,
and some default business logic which can be used to start building
 These components make it easier to move to object-oriented
technology by providing a well-tested function and services.
Developers can design their solutions using a proven programming
model instead of developing a unique approach.
 Finally, the use of a shared architecture will make it easier to integrate
solutions from different software vendors.
 IBM-
 IBM SanFrancisco -
 IBM SanFrancisco - http://www
IBM SanFrancisco -
IBM SanFrancisco -
IBM SanFrancisco -
IBM SanFrancisco -
EarthWeb -|repository||certification|content|certification|1998|01|01|GC_325
IBM SanFrancisco
Thank you

similar documents