1 / 24

IBM SanFrancisco Product Evaluation

IBM SanFrancisco Product Evaluation. Negotiated Option Presentation By Les Beckford May 2001. Introduction. The purpose of this presentation is to : Discuss the SanFrancisco Framework product at a high-level

sela
Télécharger la présentation

IBM SanFrancisco Product Evaluation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Architecture Overview CBO - Business object interfaces

  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

More Related