Transcript 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, multi platform applications.
The second layer, Common Business Objects, provides definitions of commonly used business objects that can be used as the foundation for interoperability between application.
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 SanFrancisco.
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 persistence.
3. Separation of command and selection logic from business data and user interface.
4. Distribution of business processing to allow for optimum performance.
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 multi platform 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, 1977.
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 object oriented 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 follows: Intent
States the intent of the pattern or the problem it is intended to solve.
Concept
Gives a high-level description of how the pattern fulfills the intent.
Benefits
Explains how the pattern serves the goals of extensibility and reuse.
SanFrancisco Patterns
Factory class replacement Commands Property container Policy Chain of responsibility driven policy Token driven policy Controller Keys and keyables Cached balances Keyed attribute retrieval Extensible item Life cycle Hierarchy level information “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 library.
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 exists.
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
Model-View-Controller
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.
Model-View-Controller
Summary
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 market.
However, several barriers prevented them from being able to update their applications.
Summary
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.
Summary
SanFrancisco helps solve these problems by offering solution developers business process components, that provide an object oriented infrastructure, a consistent application programming model, and some default business logic which can be used to start building applications.
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.
Reference
IBM www.ibm.com
IBM SanFrancisco http://www-4.ibm.com/software/ad/sanfrancisco/ IBM SanFrancisco - http://www 4.ibm.com/software/ad/sanfrancisco/support.html
IBM SanFrancisco http://www 4.ibm.com/software/ad/sanfrancisco/about.html
IBM SanFrancisco http://www6.software.ibm.com/dl/sanfran/sfidp-p IBM SanFrancisco http://www 4.ibm.com/software/ad/sanfrancisco/prd_summary.html
IBM SanFrancisco http://www 4.ibm.com/software/ad/sanfrancisco/concepts.html
IDC http://www.itresearch.com/alfatst4.nsf/UNITTOCX/W18221?OpenDocument
EarthWeb http://www.earthweb.com/dlink.resource jhtml.72.1129.|repository||certification|content|certification|1998|01|01|GC_325 |GC_325~xml.0.jhtml?cda=true