San Francisco Component Framework

Overview

The SanFrancisco Application Business Components product from IBM fills a long-standing need in the business applications development industry. One of the most ambitious projects ever based on object-oriented design patterns and Java technology, SanFrancisco is a set of Frameworks that provide a platform-independent infrastructure and ready-built components for constructing business applications. It enables solution developers to spend less time reinventing functions common to most business applications and more ...
See more details below
Available through our Marketplace sellers.
Other sellers (Other Format)
  • All (8) from $3.32   
  • New (4) from $24.70   
  • Used (4) from $3.32   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$24.70
Seller since 2008

Feedback rating:

(175)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
0201615878 BRAND NEW NEVER USED IN STOCK 125,000+ HAPPY CUSTOMERS SHIP EVERY DAY WITH FREE TRACKING NUMBER

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$59.50
Seller since 2015

Feedback rating:

(357)

Condition: New
Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$70.00
Seller since 2015

Feedback rating:

(229)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$90.05
Seller since 2008

Feedback rating:

(210)

Condition: New

Ships from: Chicago, IL

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Sending request ...

Overview

The SanFrancisco Application Business Components product from IBM fills a long-standing need in the business applications development industry. One of the most ambitious projects ever based on object-oriented design patterns and Java technology, SanFrancisco is a set of Frameworks that provide a platform-independent infrastructure and ready-built components for constructing business applications. It enables solution developers to spend less time reinventing functions common to most business applications and more time customizing applications to better serve their end-customers' specific needs.

Written by key members of the SanFrancisco team at IBM, this authoritative book introduces the SanFrancisco product, describes its major components, and shows how to use it to create business applications. It provides an overview of the SanFrancisco's architecture and comprehensive coverage of its three layers:-The Foundation, Common Business Objects, and Core Business Processes.


Specific topics include:
An Overview of SanFrancisco
Developing an application
The driving principles and architecture
The Foundation
Application server support overview
The application programming model
The Common Business Objects
General Business Objects, such as Business Partner, Credit
Checking, and Currency
Financial Business Objects, including the interface, the general ledger, and Accounts Receivable/Accounts Payable
Generalized Mechanisms, including Cached Balances
The Core Business Processes
General Ledger Core Business Process
Accounts Receivable/Accounts Payable Core Business Process
Warehouse Management Core Business Process
Order Management Core Business Process


The book also presents application examples and case studies, and a step-by-step guide to building client applications, addressing such vital topics as multi-threaded programs and the SanFrancisco JavaBeans tool.
Read More Show Less

Editorial Reviews

Booknews
Written by members of the SanFrancisco Application Business Components team at IBM, the book introduces the SanFrancisco product, describes its major components, and shows how to use it to create business applications. It also provides an overview of SanFrancisco's architecture and its three layers: the foundation, common business objects, and core business processes. Accompanying the book is a copy of the SanFrancisco Release 1 Version 3 Evaluation Edition CD. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201615876
  • Publisher: Addison-Wesley
  • Publication date: 11/16/1999
  • Edition description: BK&CD-ROM
  • Pages: 368
  • Product dimensions: 7.46 (w) x 9.24 (h) x 0.73 (d)

Read an Excerpt

PREFACE:

IBM's SanFrancisco component framework helps software developers--IBM's business partners--to build business applications for their own use or for distribution to their customers. The SanFrancisco component framework is not designed to be used directly for performing business tasks such as keeping track of inventory. Instead, it provides a flexible infrastructure of preprogrammed, tested, and debugged components that solve difficult problems in object-oriented computing and business domains. IBM's business partners then customize the SanFrancisco component framework to create applications that contain business logic and interfaces tailored to their specific needs.

Procedural Versus Object-oriented Techniques

Today's large, heterogeneous systems perform a broad array of tasks including managing inventory levels in warehouses, handling business ledgers, dealing with accounts receivable and accounts payable, and many more. Many of these large systems were built using procedural programming, a technique designed for creating smaller systems with a more limited range of tasks. Many large systems are even built on top of, or as extensions to, smaller systems. In such an environment, systems become unstable and unmanageable. Procedural techniques are no longer efficient or effective when a large, heterogeneous system is produced.

Object-oriented techniques, on the other hand, provide methods of analysis, design, and implementation that fit more closely the heavy demands of complex applications. Furthermore, object-oriented techniques, such as polymorphism, subclassing, and aggregation, help developers adjust to changing requirements by modifying andenhancing a system with minimal disruption to existing applications. Existing applications may not even need to be recompiled to take advantage of new policies and updated capabilities. Finally, object-oriented techniques allow system creators to reap the benefits of reusing designs and implementations produced by others, thus allowing them to focus on extending and customizing a system for their needs. Development is more efficient and effective when it maintains a tight focus on the unique business logic of a particular module rather than trying to focus on the system as a whole. The SanFrancisco component framework helps developers take maximum advantage of object-oriented techniques.

Goals and Objectives of the SanFrancisco Component Framework

Unlike many other projects, the SanFrancisco project has been driven from its inception by the real-world requirements of its users rather than by technology built in a lab. This requirements-driven, top-down model is a familiar one to software developers--it reflects the working environment in which they produce applications for their customers. This approach differs from a typical technology-driven approach, or bottom-up approach, which many development efforts use. This insight is the result of a 1995 meeting in San Francisco between IBM and its business partners. In this meeting, the developers presented a range of difficult problems they faced in their day-to-day tasks of creating applications.

Chief among the requirements was flexibility. To remain competitive, applications had to meet current requirements while at the same time providing the adaptability developers needed to meet future requirements from the customer base.

One result was that SanFrancisco was built with the object-oriented Java programming language. Through its rich array of built-in class libraries, Java provides portability among various hardware platforms as well as robust support for network-based applica-tions. At the same time, its extensibility allows the SanFrancisco component framework to add numerous layers to the Java base. A key enhancement, for example, is SanFrancisco's Foundation layer, which takes care of generic, low-level details so that developers can concentrate on building the parts of an application that meet specific business requirements.

The problems presented by the business partners in 1995 were specific and wide-ranging. The original goals and objectives of the SanFrancisco project included solutions to the following problems:

  • Large parts of applications needed to be rewritten for a variety of reasons, such as solving year 2000 problems, updating networking capabilities of an application, and dealing with the Euro currency.
  • People needed to be retrained or hired to obtain the skills necessary for updating the common portions of application. The combination of a shortage of skilled computer professionals and long training times for creating new skills made the transition to new technologies expensive or even impossible. It was especially difficult to train procedural application developers--who might be using a waterfall development model with an implementation language such as COBOL--to use the object-oriented development and programming environment.
  • Often, existing business systems could not be adapted fast enough to take advantage of the dynamic business environment. Furthermore, because systems were often being adapted to serve purposes for which they were not intended (such as Internet accessibility and processing of additional data), applications became increasingly fragile over time and with each new capability added to the system.
  • Systems had to be deployed on or ported from new platforms--often because of mergers or acquisitions--creating large-scale porting efforts and ensuing problems with maintenance and infrastructure modifications.

It was from this base of customer requirements that the SanFrancisco project was launched. This precedent of top-down, rather than bottom-up, development continues today as hundreds of international business partners provide input into the content and structure of SanFrancisco.

The SanFrancisco Solution

The infrastructure of the SanFrancisco framework (the "plumbing" for object communication and most system services) is the Foundation layer. The Foundation layer, in addition to providing the system services, defines a strict programming model for use throughout the SanFrancisco component framework. On top of this layer is a set of common business classes, patterns, and techniques called the Common Business Objects layer. On top of this framework are sets of interrelated classes, patterns, and techniques, such as general ledgers, warehousing, accounts receivable, and accounts payable, that are tailored to the needs of particular business domains. The expertise to determine the structure and contents of the layers is provided by application developers and domain specialists for the particular framework being built.1

1 SanFrancisco is a single framework that encompasses many frameworks that apply to different business domains. Each of the frameworks encompassed by SanFrancisco is built with the same programming model. Often, the term SanFrancisco application business components is used. It is interchangeable with the SanFrancisco framework, and both are used in this book. Using broad definitions of components and frameworks, the SanFrancisco framework as a whole adheres to both definitions. (Keep in mind that the term components is not synonymous with JavaBeans, even though JavaBeans are components.)

Within each of the business domains for which SanFrancisco provides a framework, analysts locate common processes as well as places where systems may require custom logic. For example, the credit checking policy at a small hardware store may vary substantially from the credit checking policy at an on-line bookseller. The small hardware store may have a credit policy that extends credit to many customers based on good faith rather than on actual credit records, which an on-line bookstore is likely to use. For such cases, SanFrancisco provides default behavior (such as a default credit checking policy) but documents it as a customization point, allowing a system developer to replace it through an extension mechanism. Customization through extension points isolates the custom logic so that the application's logic remains unchanged. SanFrancisco mechanisms automatically take advantage of a replaced policy.

A key benefit of the SanFrancisco component framework is that a development team can take advantage of the framework's wide-ranging potential for reuse of its components. The development cycle does not differ substantially from that of any other object-oriented approach. Analysts, designers, and programmers take additional time to map requirements, patterns, and functions to those provided in SanFrancisco.

Typically, the SanFrancisco component framework fulfills about 40 percent of an application's needs within its supported business domains (such as General Ledger, Warehouse Management, Order Management, and so on), and it may provide significantly more. The amount of reuse depends on how close an application maps to the provided requirements, design patterns, and common business objects (and their implementations). Implementation reuse is valuable in cutting the number of lines of code that developers must write to implement business logic. Analysis and design reuse can go a long way toward reducing the complexity and sheer number of decisions that must be made in building large business systems.

No matter how much reuse occurs, developers benefit from the thousands of hours spent by the SanFrancisco development team working with solution developers to create a robust architecture and design for the SanFrancisco classes. When developers use the framework, they gain--in addition to a design that encourages extension and reuse-- object-oriented design patterns and a robust programming model for consistency and coding guidance.

Reading This Book

This book addresses the SanFrancisco framework using a layered approach that parallels the framework itself. The only exception is the first part of the book, which serves as an introduction to frameworks in general and to the SanFrancisco framework in particular.

As you proceed through the book, the techniques we use to present examples and diagrams vary according to the conceptual level of the material. For example, SanFrancisco's Foundation layer contains the definition of the programming model along with basic functions and utilities. In Part II we present Unified Modeling Language (UML) depictions of many classes and Java code to show how some of the services in the Foundation layer are used. On the other hand, Part IV, The Core Business Processes, has little to do with Java code; instead, it describes particular business domains and explains how the SanFrancisco framework supports them. The samples show how to match an application's business requirements to similar requirements provided by SanFrancisco.

We use the various presentation techniques to reach the target audience of each specific area. After reading about the Foundation layer, a programmer will have an idea of how SanFrancisco is coded and will understand the structure, layout, and techniques used in SanFrancisco's programming model. Because the programming model is used in all layers of the SanFrancisco framework, discussion of how to program while using one of the business domains is not necessary. With respect to business domains, and the SanFrancisco Core Business Processes layer, it is more important to understand the contents of the framework and the approach SanFrancisco uses to support the business domain. As a result, examples are presented in text and non-UML diagrams.

This book provides insight and knowledge about the contents of the SanFrancisco framework as well as how a development shop codes an application that uses it. We delve into various business domains, but first provide a business-oriented background before presenting how the SanFrancisco framework addresses a domain.

The structure of the book is as follows:

  • Part I gives an overview of how the SanFrancisco framework fits with an object-oriented development process and describes the overall architecture of SanFran-cisco. The framework contains several layers. Each layer has a specific purpose and provides capabilities that allow developers to implement business requirements. After reading Part I, you should understand how the SanFrancisco framework fits into the development process. You should also understand the rationale for the layered approach and should be familiar with the contents of the layers. Part I should be read in its entirety by all readers.
  • Part II provides deeper insight into the Foundation layer of SanFrancisco, which contains many of the object-oriented services (such as object persistence, transactions, and distribution). It also establishes the programming model that you use when programming with the SanFrancisco framework. Although many services are provided in this layer, there are no classes that correlate directly to a business application's needs (such as a currency class). On the other hand, there are primitive classes, collections, and helper classes that are used when the business content is built in the upper layers.
  • Part III discusses the Common Business Objects (CBO) layer of SanFrancisco, the first layer to provide requirements-level reuse and implementations of those requirements. This layer provides a set of design patterns and principles that can be reused in their own right within an application. Requirements in this layer address the handling of business partners, currency, Euro transition, and so on. These requirements are implemented using the design patterns and implementation classes defined within this layer, which are built using classes from the Foundation layer.
  • Part IV is a discussion of the Core Business Processes (CBP) layer, where the most reuse for particular business environments can be garnered. Here, the perspective changes from traditional object-oriented development to analysis and design from the perspective of the business processes involved in a particular application. Whereas the earlier parts of the book largely involve reuse of patterns and implementation for developers, this part speaks more to customizations that are particular to a specific business system, explaining how to extend or enhance function within a framework to tailor it for a particular need. The chapters explain business domains using common examples before discussing how SanFrancisco supports the specific business domains.
  • Part V talks about the creation of client applications, returning to programming and client implementation techniques. Whereas most of the book focuses on the framework and class extensions, at some point in development a final, deployable applica-tion must be built. In this part of the book, we discuss many SanFrancisco client development technologies, such as JavaBeans, as well as user interface building techniques.

The topics addressed in this book can be of value to many different people. No matter which of the following categories you fit into, make sure you read Part I. It explains the basis of SanFrancisco.

  • Analysts will get the most from reading Parts III and IV, gaining familiarity with the contents of the Common Business Objects layer and Core Business Processes layerand learning how to exploit these layers for reuse when completing analysis of their own application requirements. An analyst should at least survey Parts I and II to understand the SanFrancisco structure and programming model. Surveying Part V will give analysts an idea of how the developers will complete the application for which the analysts design the business logic.
  • Designers will have much the same task as analysts but should focus more closely on the patterns and implementations discussed in Parts III and IV. Designers should also have some knowledge of the technologies that will be crucial for implementors. As a result, a greater focus on Parts I, II, and III is necessary, and an understanding of Parts IV and V is useful.
  • Implementors should focus on Parts I, II, and V. It is useful for an implementor to have at least a cursory understanding of how analysts and designers come to a particular conclusion, so an understanding of Parts III and IV can be helpful. With SanFran-cisco, software implementors themselves are split into two groups: the framework implementors and the client implementors. Implementors who are putting the designs into use will have much less need for Part V and a heavier reliance on Parts III and IV of this book than those who are actually building clients.

Although we encourage reading the book from cover to cover, we understand that it caters to many different audiences. If your project is committed to using SanFrancisco, it is useful for everyone on the project to have a good understanding of the roles and responsi-bilities of each of the members of the team. At a minimum, the book explains the motiva-tion for the framework and outlines its the benefits. It also looks at the various layers of SanFrancisco and helps you understand each of them in the perspective for which it is most appropriate. Finally, the samples and code will give readers a good starting point for a project involving SanFrancisco.

Where to Find out More about SanFrancisco

On the accompanying CD is the SanFrancisco Evaluation edition. After you install it, you will find a wealth of on-line documentation, including

  • SanFrancisco Programmer's Guide. This reference explains the SanFrancisco programming model in detail. The programming model is introduced in Part IV of the book.
  • SanFrancisco Business Requirements Guides. Complete listings of business requirements and processes that are implemented for the various domains currently addressed by SanFrancisco.
  • JavaDoc. Complete JavaDoc for all publicly accessible classes.
  • On-line documentation. There are thousands of pages of documentation that attempt to fulfill the needs of everyone from a manager to an implementor. In addition to the on-line documentation, the SanFrancisco Web site contains white
  • papers, business case studies, redbook information, and several user's guides for individual business domains. The site is located at ...
Read More Show Less

Table of Contents

(Each chapter concludes with a Summary.)
List of Figures.
Preface.

I. INTRODUCTION.

1. An Overview of SanFrancisco Development.
The Object-oriented Development Process.
Requirements Gathering.
Scenario Creation.
Object-oriented Analysis.
Object-oriented Design.
Code.
Test.
A Framework-Enhanced Development Process.
Requirements Mapping.
Scenario Mapping.
Object-oriented Analysis Mapping.
Object-oriented Design Mapping.
Implementation Mapping.
Documentation.
An Example.

2. Architecture Overview.
SanFrancisco Architectural Vision.
Maximizing Reuse.
Isolation from Underlying Technology.
Focus on the Core.
Integration with Existing Systems.
SanFrancisco Architecture.
The Core Business Processes.
The Common Business Objects.
The Foundation.
Patterns.
Client Programming.

II. THE FOUNDATION.


3. An Introduction to the Foundation.
Foundation Services.
Foundation Object Model.
SanFrancisco Programming Model.
Foundation Utilities.

4. The Foundation Object Model.
The Big Three.
Entity.
Dependent.
Command.
Localization.
Collections.

5. Using the Foundation.
Application Case Study.
Mapping Business Objects to SanFrancisco.
Implementing SanFrancisco Business Objects.
Interfaces and Classes.
Creating an Entity Subclass.
Creating a Dependent Subclass.
Creating a Command Subclass.
Code Generation of SanFrancisco Business Objects.
Using SanFrancisco Business Objects.
The Transaction Model.
The AccessMode Class.
Creating Business Object Instances.
Accessing Existing Business Object Instances.
Accessing and Querying Collections.
Destroying Business Object Instances.
Administering and Configuring a SanFrancisco Application.
Class and Container Configuration.
The Logical SanFrancisco Network.
Schema Mapping.
Security Administration.

III. THE COMMON BUSINESS OBJECTS.


6. An Introduction to the Common Business Objects.
Contents of the Common Business Objects Layer.
Using the Contents of the Common Business Objects Layer.
Common Business Object Categories.
The Company Category.
Representing Your Company Organization and Structure.
Using the Company as the Context for Your Application.
The Active Company.
Patterns.
The Controller Pattern.
The Policy Pattern.
Remaining Patterns.

7. Common Business Object Categories.
General Business Objects.
Address.
Business Partner.
Company.
Credit Checking.
Currency.
Document Location.
Fiscal Calendar.
Initials.
Natural Calendar.
Number Series.
Payment Method.
Payment Terms.
Periodized Calendar.
Process Token.
Project.
Supplementary Charges.
Unit of Measure.
Financial Business Objects.
Bank Accounts.
Currency Gain/Loss Accounts.
Financial Batches.
Financial Calendar.
Financial Integration.
Interface to Banks.
Interface to General Ledger.
Interface to Accounts Receivable/Accounts Payable.
Invoicing.
Generalized Mechanisms.
Cached Balances.
Classification.
Keys and Keyables.
LifeCycle.
Patterns.
Controllers.
Generic Interface.
Token Driven Policy.
Chain of Responsibility Driven Policy.

8. Using the Common Business Objects
The GPSE Customer Classes.
Using the BusinessPartner Common Business Object and the Controller Pattern.
The GPSE Product Classes.
Using the Policy Pattern.

IV. THE CORE BUSINESS PROCESSES.


9. An Introduction to the Core Business Processes.
Contents of the Core Business Processes.
Using the Core Business Processes.
Core Business Process Domains.
Patterns.
Keyed Attribute Retrieval.
List Generation.

10. Core Business Process Domains.
The General Ledger Core Business Process.
The Domain.
The Core Business Process.
GL Business Processes.
The Accounts Receivable/Accounts Payable Core Business Process.
The Domain: Accounts Receivable.
The Domain: Accounts Payable.
The Core Business Process.
AR/AP Processes.
The Warehouse Management Core Business Process.
The Domain.
The Core Business Process.
WM Business Processes.
The Order Management Core Business Process.
The Domain.
The Core Business Process.
OM Business Processes.
-Able/-Ing Processes.
OM Order Types.

11. Using the Core Business Processes.
Application Case Study.
Beta Customer 1: Home Entertainment Store.
Beta Customer 2: Big Electronics Superstore.
Application Requirements.
Mapping to the SanFrancisco.
Core Business Processes.
Application Use Case.
Stock Take Structure.
Stock Take Generation Extension.
Variances and Recounts Extension.
Stock Take List Generation Extension.
Reuse of the Core Business Process.
Use of the Common Business Objects.
Company.
Initials.
Policies.
Controllers.
Properties.
Use of Security.

V. THE CLIENT.


12. Preparing to Build a Client Application.
An Overview of Multithreaded Applications.
A Multithreaded Application without SanFrancisco Interaction.
Adding SanFrancisco Interaction to the Multithreaded Program—?—Almost.
Handling the SanFrancisco Work Area and Finishing the Multithreaded Program.
A Simplified Mechanism for Handling the Work Area.
Transaction Scope.
Locking Strategies.

13. Using Commands in an Application.
Performance Characteristics of Commands.
Setup and Initialization of an Application Using Commands.
Creating a Setup Command.
Creating an Initialization Command.
Running the Setup and Initialization Commands from an Application.

14. The Presentation Layer.
The SanFrancisco User Interface Framework.
The Design.
Constructing a Client.
The Maintainer.
Using Java Foundation Classes in a SanFrancisco Application.
Building the View.
Building the Model.
Model, View, Controller.
Thin Client Construction.

15. SanFrancisco JavaBeans.
How SanFrancisco JavaBeans Work.
SanFrancisco JavaBean Tools.
Using the SanFrancisco JavaBeans with the Sample Application.
Building a New SanFrancisco JavaBean for Product.
Building an Application.

Appendix A: Tools.
Development Tools.
Modeling Tools.
The SanFrancisco Code Generator.
Rational Rose Directive Assistant.
Integrated Development Environments.
Java Development Kit (JDK).
Server Management.
Problem Manager.
HTML Documentation Print Tool.

Appendix B: The CD-ROM.
Index.
Read More Show Less

Preface

IBM's SanFrancisco component framework helps software developers—IBM's business partners—to build business applications for their own use or for distribution to their customers. The SanFrancisco component framework is not designed to be used directly for performing business tasks such as keeping track of inventory. Instead, it provides a flexible infrastructure of preprogrammed, tested, and debugged components that solve difficult problems in object-oriented computing and business domains. IBM's business partners then customize the SanFrancisco component framework to create applications that contain business logic and interfaces tailored to their specific needs.

Procedural Versus Object-oriented Techniques

Today's large, heterogeneous systems perform a broad array of tasks including managing inventory levels in warehouses, handling business ledgers, dealing with accounts receivable and accounts payable, and many more. Many of these large systems were built using procedural programming, a technique designed for creating smaller systems with a more limited range of tasks. Many large systems are even built on top of, or as extensions to, smaller systems. In such an environment, systems become unstable and unmanageable. Procedural techniques are no longer efficient or effective when a large, heterogeneous system is produced.

Object-oriented techniques, on the other hand, provide methods of analysis, design, and implementation that fit more closely the heavy demands of complex applications. Furthermore, object-oriented techniques, such as polymorphism, subclassing, and aggregation, help developers adjust to changing requirements by modifying andenhancing a system with minimal disruption to existing applications. Existing applications may not even need to be recompiled to take advantage of new policies and updated capabilities. Finally, object-oriented techniques allow system creators to reap the benefits of reusing designs and implementations produced by others, thus allowing them to focus on extending and customizing a system for their needs. Development is more efficient and effective when it maintains a tight focus on the unique business logic of a particular module rather than trying to focus on the system as a whole. The SanFrancisco component framework helps developers take maximum advantage of object-oriented techniques.

Goals and Objectives of the SanFrancisco Component Framework

Unlike many other projects, the SanFrancisco project has been driven from its inception by the real-world requirements of its users rather than by technology built in a lab. This requirements-driven, top-down model is a familiar one to software developers—it reflects the working environment in which they produce applications for their customers. This approach differs from a typical technology-driven approach, or bottom-up approach, which many development efforts use. This insight is the result of a 1995 meeting in San Francisco between IBM and its business partners. In this meeting, the developers presented a range of difficult problems they faced in their day-to-day tasks of creating applications.

Chief among the requirements was flexibility. To remain competitive, applications had to meet current requirements while at the same time providing the adaptability developers needed to meet future requirements from the customer base.

One result was that SanFrancisco was built with the object-oriented Java programming language. Through its rich array of built-in class libraries, Java provides portability among various hardware platforms as well as robust support for network-based applica-tions. At the same time, its extensibility allows the SanFrancisco component framework to add numerous layers to the Java base. A key enhancement, for example, is SanFrancisco's Foundation layer, which takes care of generic, low-level details so that developers can concentrate on building the parts of an application that meet specific business requirements.

The problems presented by the business partners in 1995 were specific and wide-ranging. The original goals and objectives of the SanFrancisco project included solutions to the following problems:

  • Large parts of applications needed to be rewritten for a variety of reasons, such as solving year 2000 problems, updating networking capabilities of an application, and dealing with the Euro currency.
  • People needed to be retrained or hired to obtain the skills necessary for updating the common portions of application. The combination of a shortage of skilled computer professionals and long training times for creating new skills made the transition to new technologies expensive or even impossible. It was especially difficult to train procedural application developers—who might be using a waterfall development model with an implementation language such as COBOL—to use the object-oriented development and programming environment.
  • Often, existing business systems could not be adapted fast enough to take advantage of the dynamic business environment. Furthermore, because systems were often being adapted to serve purposes for which they were not intended (such as Internet accessibility and processing of additional data), applications became increasingly fragile over time and with each new capability added to the system.
  • Systems had to be deployed on or ported from new platforms—often because of mergers or acquisitions—creating large-scale porting efforts and ensuing problems with maintenance and infrastructure modifications.

It was from this base of customer requirements that the SanFrancisco project was launched. This precedent of top-down, rather than bottom-up, development continues today as hundreds of international business partners provide input into the content and structure of SanFrancisco.

The SanFrancisco Solution

The infrastructure of the SanFrancisco framework (the "plumbing" for object communication and most system services) is the Foundation layer. The Foundation layer, in addition to providing the system services, defines a strict programming model for use throughout the SanFrancisco component framework. On top of this layer is a set of common business classes, patterns, and techniques called the Common Business Objects layer. On top of this framework are sets of interrelated classes, patterns, and techniques, such as general ledgers, warehousing, accounts receivable, and accounts payable, that are tailored to the needs of particular business domains. The expertise to determine the structure and contents of the layers is provided by application developers and domain specialists for the particular framework being built.1

1 SanFrancisco is a single framework that encompasses many frameworks that apply to different business domains. Each of the frameworks encompassed by SanFrancisco is built with the same programming model. Often, the term SanFrancisco application business components is used. It is interchangeable with the SanFrancisco framework, and both are used in this book. Using broad definitions of components and frameworks, the SanFrancisco framework as a whole adheres to both definitions. (Keep in mind that the term components is not synonymous with JavaBeans, even though JavaBeans are components.)

Within each of the business domains for which SanFrancisco provides a framework, analysts locate common processes as well as places where systems may require custom logic. For example, the credit checking policy at a small hardware store may vary substantially from the credit checking policy at an on-line bookseller. The small hardware store may have a credit policy that extends credit to many customers based on good faith rather than on actual credit records, which an on-line bookstore is likely to use. For such cases, SanFrancisco provides default behavior (such as a default credit checking policy) but documents it as a customization point, allowing a system developer to replace it through an extension mechanism. Customization through extension points isolates the custom logic so that the application's logic remains unchanged. SanFrancisco mechanisms automatically take advantage of a replaced policy.

A key benefit of the SanFrancisco component framework is that a development team can take advantage of the framework's wide-ranging potential for reuse of its components. The development cycle does not differ substantially from that of any other object-oriented approach. Analysts, designers, and programmers take additional time to map requirements, patterns, and functions to those provided in SanFrancisco.

Typically, the SanFrancisco component framework fulfills about 40 percent of an application's needs within its supported business domains (such as General Ledger, Warehouse Management, Order Management, and so on), and it may provide significantly more. The amount of reuse depends on how close an application maps to the provided requirements, design patterns, and common business objects (and their implementations). Implementation reuse is valuable in cutting the number of lines of code that developers must write to implement business logic. Analysis and design reuse can go a long way toward reducing the complexity and sheer number of decisions that must be made in building large business systems.

No matter how much reuse occurs, developers benefit from the thousands of hours spent by the SanFrancisco development team working with solution developers to create a robust architecture and design for the SanFrancisco classes. When developers use the framework, they gain—in addition to a design that encourages extension and reuse— object-oriented design patterns and a robust programming model for consistency and coding guidance.

Reading This Book

This book addresses the SanFrancisco framework using a layered approach that parallels the framework itself. The only exception is the first part of the book, which serves as an introduction to frameworks in general and to the SanFrancisco framework in particular.

As you proceed through the book, the techniques we use to present examples and diagrams vary according to the conceptual level of the material. For example, SanFrancisco's Foundation layer contains the definition of the programming model along with basic functions and utilities. In Part II we present Unified Modeling Language (UML) depictions of many classes and Java code to show how some of the services in the Foundation layer are used. On the other hand, Part IV, The Core Business Processes, has little to do with Java code; instead, it describes particular business domains and explains how the SanFrancisco framework supports them. The samples show how to match an application's business requirements to similar requirements provided by SanFrancisco.

We use the various presentation techniques to reach the target audience of each specific area. After reading about the Foundation layer, a programmer will have an idea of how SanFrancisco is coded and will understand the structure, layout, and techniques used in SanFrancisco's programming model. Because the programming model is used in all layers of the SanFrancisco framework, discussion of how to program while using one of the business domains is not necessary. With respect to business domains, and the SanFrancisco Core Business Processes layer, it is more important to understand the contents of the framework and the approach SanFrancisco uses to support the business domain. As a result, examples are presented in text and non-UML diagrams.

This book provides insight and knowledge about the contents of the SanFrancisco framework as well as how a development shop codes an application that uses it. We delve into various business domains, but first provide a business-oriented background before presenting how the SanFrancisco framework addresses a domain.

The structure of the book is as follows:

  • Part I gives an overview of how the SanFrancisco framework fits with an object-oriented development process and describes the overall architecture of SanFran-cisco. The framework contains several layers. Each layer has a specific purpose and provides capabilities that allow developers to implement business requirements. After reading Part I, you should understand how the SanFrancisco framework fits into the development process. You should also understand the rationale for the layered approach and should be familiar with the contents of the layers. Part I should be read in its entirety by all readers.
  • Part II provides deeper insight into the Foundation layer of SanFrancisco, which contains many of the object-oriented services (such as object persistence, transactions, and distribution). It also establishes the programming model that you use when programming with the SanFrancisco framework. Although many services are provided in this layer, there are no classes that correlate directly to a business application's needs (such as a currency class). On the other hand, there are primitive classes, collections, and helper classes that are used when the business content is built in the upper layers.
  • Part III discusses the Common Business Objects (CBO) layer of SanFrancisco, the first layer to provide requirements-level reuse and implementations of those requirements. This layer provides a set of design patterns and principles that can be reused in their own right within an application. Requirements in this layer address the handling of business partners, currency, Euro transition, and so on. These requirements are implemented using the design patterns and implementation classes defined within this layer, which are built using classes from the Foundation layer.
  • Part IV is a discussion of the Core Business Processes (CBP) layer, where the most reuse for particular business environments can be garnered. Here, the perspective changes from traditional object-oriented development to analysis and design from the perspective of the business processes involved in a particular application. Whereas the earlier parts of the book largely involve reuse of patterns and implementation for developers, this part speaks more to customizations that are particular to a specific business system, explaining how to extend or enhance function within a framework to tailor it for a particular need. The chapters explain business domains using common examples before discussing how SanFrancisco supports the specific business domains.
  • Part V talks about the creation of client applications, returning to programming and client implementation techniques. Whereas most of the book focuses on the framework and class extensions, at some point in development a final, deployable applica-tion must be built. In this part of the book, we discuss many SanFrancisco client development technologies, such as JavaBeans, as well as user interface building techniques.

The topics addressed in this book can be of value to many different people. No matter which of the following categories you fit into, make sure you read Part I. It explains the basis of SanFrancisco.

  • Analysts will get the most from reading Parts III and IV, gaining familiarity with the contents of the Common Business Objects layer and Core Business Processes layerand learning how to exploit these layers for reuse when completing analysis of their own application requirements. An analyst should at least survey Parts I and II to understand the SanFrancisco structure and programming model. Surveying Part V will give analysts an idea of how the developers will complete the application for which the analysts design the business logic.
  • Designers will have much the same task as analysts but should focus more closely on the patterns and implementations discussed in Parts III and IV. Designers should also have some knowledge of the technologies that will be crucial for implementors. As a result, a greater focus on Parts I, II, and III is necessary, and an understanding of Parts IV and V is useful.
  • Implementors should focus on Parts I, II, and V. It is useful for an implementor to have at least a cursory understanding of how analysts and designers come to a particular conclusion, so an understanding of Parts III and IV can be helpful. With SanFran-cisco, software implementors themselves are split into two groups: the framework implementors and the client implementors. Implementors who are putting the designs into use will have much less need for Part V and a heavier reliance on Parts III and IV of this book than those who are actually building clients.

Although we encourage reading the book from cover to cover, we understand that it caters to many different audiences. If your project is committed to using SanFrancisco, it is useful for everyone on the project to have a good understanding of the roles and responsi-bilities of each of the members of the team. At a minimum, the book explains the motiva-tion for the framework and outlines its the benefits. It also looks at the various layers of SanFrancisco and helps you understand each of them in the perspective for which it is most appropriate. Finally, the samples and code will give readers a good starting point for a project involving SanFrancisco.

Where to Find out More about SanFrancisco

On the accompanying CD is the SanFrancisco Evaluation edition. After you install it, you will find a wealth of on-line documentation, including

  • SanFrancisco Programmer's Guide. This reference explains the SanFrancisco programming model in detail. The programming model is introduced in Part IV of the book.
  • SanFrancisco Business Requirements Guides. Complete listings of business requirements and processes that are implemented for the various domains currently addressed by SanFrancisco.
  • JavaDoc. Complete JavaDoc for all publicly accessible classes.
  • On-line documentation. There are thousands of pages of documentation that attempt to fulfill the needs of everyone from a manager to an implementor. In addition to the on-line documentation, the SanFrancisco Web site contains white
  • papers, business case studies, redbook information, and several user's guides for individual business domains. The site is located at http://www.software.ibm.com/ad/sanfrancisco.
  • SanFrancisco Web site: http://www.software.ibm.com/ad/sanfrancisco. A continuously updated Web page with the latest SanFrancisco news, customer forums, and information. Users' Guides for each domain are located here.

Providing complete Rose diagrams for the contents of the SanFrancisco framework is not possible in an introductory book. If you would like to use the Rose diagrams and go further with the SanFrancisco framework, contact IBM for access to the diagrams and other related materials.

Additional books on SanFrancisco will become available from Addison-Wesley that cater to different domains and contents in the framework. Many of the books will be written by authors who helped develop the technologies in SanFrancisco.



Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)