SanFrancisco(TM) Component Framework: An Introduction - Softcover

Monday, Paul; Carey, James; Dangler, Mary

Softcover

ISBN 10: 0201615878 ISBN 13: 9780201615876

Publisher: Addison-Wesley, 1999

Synopsis

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 provides a platform-independent infrastructure and ready-built components for constructing business applications.
Written by key members of the SanFrancisco team at IBM, this book introduces the SanFrancisco product, describes its major components, and shows how to use it to create business applications. SanFrancisco Component Framework provides an overview of SanFrancisco's architecture and comprehensive coverage of its three layers: The Foundation, Common Business Objects, and Core Business Processes.

About this title

About the Author

Paul Monday is an Advisory Software Engineer at IBM.

From the Back Cover

The SanFrancisco Component Framework 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. SanFrancisco enables solution developers to spend less time reinventing functions common to most business applications and more time customizing applications to better serve their end-customersi 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. SanFrancisco Component Framework provides an overview of SanFranciscois 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 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 that addresses such vital topics as multithreaded programs and the SanFrancisco JavaBeans tool. 0201615878B04062001

From the Inside Flap

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 and enhancing 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. A

Edition details

• Publisher: Addison-Wesley
• Publication date: 1999
• Language: English
• ISBN 10: 0201615878
• ISBN 13: 9780201615876
• Binding: Paperback
• Number of pages: 368