1 IBM SanFrancisco Product Evaluation Negotiated Option Presentation By Les Beckford May 2001

2 Introduction The purpose of this presentation is to : Discuss the SanFrancisco Framework product at a high-level Evaluate SanFrancisco on the basis of characteristics common to successful frameworks

3 Definitions What is SanFrancisco? SanFrancisco is a Commercial Business Application Framework that is designed to enable the construction of distributed and standalone mission critical business applications. What is a Framework? A collection of cooperating classes that together defines a generic or template solution to a family of domain specific requirements. A reusable design expressed by classes and their relationships and responsibilities - white-box (inheritance), black-box (components). A collection of classes whose patterns of collaboration satisfy some well documented purpose. A set of interacting components designed to facilitate application development for a specific domain.

4 IT Problems That Motivated The Creation Of SanFrancisco The difficult task of retraining in-house development staff effectively to use OO technology. The risk involved in moving to new technology. The speed at which the business environments change - requirements often change faster than development staff could update their solutions.

5 Architecture Overview SanFrancisco is made up of three layers of reusable code

6 Architecture Overview Top Layer : Common Business Processes(CBP) consists of business process components for key business activities.

7 Architecture Overview Second Layer - Common Business Objects(CBO) are a set of “mini” frameworks that are of three general types: Business objects, Business object interfaces, and Objects that implement useful design patterns for business applications.

8 Use of Patterns to Promote Quality and Consistency The concept of design patterns has evolved to help designers and developers solve problems by reusing structures that have successfully been applied in similar situations. This approach improves the quality of the solution because proven design concepts are being reused and because the consequences of those design decisions are well understood. In addition, it is easier for developers to understand the system because they can learn a handful of patterns, rather than having to understand unique designs in each solution. The method also provides greater consistency and quality across solutions because the same proven techniques are reused.

9 Architecture Overview

10 CBO - Business object interfaces Architecture Overview

11 Architecture Overview Lowest Layer - The Foundation, provides the infrastructure that is used to build the CBOs and the Core Business Processes Base classes residing at this layer include: Entity—support for independent, shareable objects Dependent—support for objects that must be owned by an Entity Command—support for a group of operations on one or more objects Factory—manages lifetime and access of instances of objects

12 Programmers can extend the Entity class whenever they need to create business objects that are inherently persistent, that can be shared among multiple processes, and that can participate in a transaction.

13 Using a relational database (RDB) as the persistent store for IBM San Francisco Business Objects requires a mapping, or correlation, between an object model and a relational model.

14 Binding Schema to Containers

15 Binding Schema to DataStore

16 BOP & Persistence

17 A Logical San Francisco Network (LSFN) is a group of client and business object processes that share the same instance of the Global Server Manager (GSM) process.

18 Execution Environment

19 The GSM Process contains several service objects that are critical to LSFN functioning. Global Server Manager is in charge of all the Business Object Processes. It holds all of the BOP configuration information, tracks all active and inactive BOPs, and is responsible for connecting clients with specific BOPs. Global Distributed Process Manager Service tracks all active clients in its LSFN. Global Name Service is responsible for managing the naming space of the LSFN. The component knows: How to resolve the user aliases Which classes ultimately have to be used to create instance of business objects. Where these instances must be created How containers are configured How security is configured What commit protocol is in use

20 Processes and services in a logical SanFrancisco node

21 Security Configuration

22 Access Rights Administration Security can be implemented either at the application level or at the system level.

23 Versioning

24 Architecture Overview