A report based on this material has been submitted for
publication as a technical forum section of the IBM Systems Journal.
© Copyright International Business Machines Corporation 1997. All rights reserved.
adapted for presentation by A. Eliëns (VU), see README
slide: San Francisco Project Technical Summary
Table Of Contents
slide: Table of Contents
Software developers face significant challenges as they attempt to modernize their current application suites to take advantage of the benefits of distributed objects. The cost of architecting and building their next generation of applications as industrial strength distributed object solutions will be prohibitive for many software vendors because their skills are in developing procedural applications. Some of these vendors have indicated that as much as eighty percent of their development cost is spent writing and supporting the basic, noncompetitive functions that are essentially the same for any application solution offered in a specific domain.
IBM's San Francisco project addresses these problems by providing application developers with a base set of object oriented infrastructure and application logic which can be expanded and enhanced by each developer in the areas where they chose to provide competitive differentiation. The Business Process Components, which use the JavaTM language, are intended to lower the barriers to widespread commercial implementation of distributed object solutions. This report provides an overview of the San Francisco project and the business frameworks which are being developed. It is intended to provide the reader with a high level understanding of the architecture and content of the frameworks.
slide: Abstract
The San Francisco project 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, there were several barriers preventing them from being able to update their applications. One barrier was the problem of how to retrain
their development staffs to be able to effectively use object oriented technology. The task is greater than just learning another programming language. This is required, but it is also necessary to learn how to analyze a problem in terms of objects, and how to use that analysis to design an object oriented solution. In effect, a whole new approach to building systems must be learned, and a whole new set of skills and tools must used.
A second barrier was the risk involved in moving to a new technology. Often the first solution that is built with a new set of skills, and a new technology is less than perfect. A poor design will manifest itself in problems such as code that won't function properly, poor performance, or a solution that is hard to use. This type of result is a necessary step to learning how to apply a new technology, but the number and magnitude of the problems must be kept at a level that will allow a business to keep operating while the change to the new approach is learned.
A third barrier associated with moving to object oriented technology was the cost of making the change. The software developers realized they needed some basic infrastructure upon which to base their applications. Many of the companies could not afford to develop this infrastructure themselves. They also could not afford to rewrite their entire product line at one time. They needed to be able to spread the cost of upgrading their applications over time by having the object based portions of the application interoperate with portions that had not yet been
updated.
The San Francisco project helps to solve these problems by offering solution developers Business Process Components, designed as frameworks that provide an object oriented
infrastructure, a consistent application programming model, and some default business logic that can be used to start building applications. The frameworks make it easier to move to object
oriented technology because developers use well tested services instead of building their own. They can design their solutions using a proven programming model instead of developing their
unique approach. Finally, the use of a shared architecture will make it easier to integrate solutions from different software vendors.
The frameworks provide some basic business logic that can be enhanced and extended instead of having to build the entire application from scratch. Developers can build their applications by modifying and extending the default business objects and logic instead of having to start their applications from raw requirements statements. This allows developers to apply more development resources on the functions that will give them a competitive advantage since much of the basic application function is supplied by the framework. The frameworks are designed so that it is easy to extend them in areas where our partners have told us they differentiate themselves from their competitors.
San Francisco is being developed in collaboration with several hundred international ISVs to insure applicability across a broad range of Small to Medium Enterprise (SME) business solutions. These international ISVs are working with IBM to design, develop, and
validate frameworks, create development tools, and develop integrated applications using the San Francisco frameworks.
Feedback from companies that tested early versions of the code are that the frameworks
provide about 40% of a typical working application within the supported domains. ISVs would develop the remaining 60% of the application business processes, user interfaces, and services on top of San Francisco and bundle both the IBM and ISV code into a single solution which the ISV will then license to customers. The customers will realize significant value using applications built on San Francisco frameworks, because of improved application flexibility to meet changing business needs, improved availability and affordability of customized multi-platform business solutions, and improved application inter-operability.
slide: Introduction
FIGURE 1 - Business Frameworks Overview
slide: Overview
The San Francisco project is building three layers of reusable code for use by application developers. The highest layer, called the Core Business Processes, provides business objects
and default business logic for selected vertical domains. The second layer, called the Common Business Objects, provides definitions of commonly used business objects that can be used as the foundation for interoperability between applications. The lowest layer, called the Base, provides the infrastructure and services that are required to build industrial strength applications in a
distributed, managed object, multi-platform applications. The Base isolates an application from the complexities of multi-platform network technology, and frees the application provider to focus on unique elements that drive value to their customers.
Application developers can choose to exploit the frameworks at any of the three layers. For example, they could build directly on the Base, and develop their own frameworks and
business objects. Or, they could use the Core Business Processes, and just make the extensions needed to complete their application. Application developers may also use the framework technology for only portions of their application. San Francisco is designed to coexist with existing business applications, preserving existing application investments.
As referenced in Figure 1, San Francisco offers application developers a choice of various levels of framework exploitation. At the lowest level, application developers can utilize the Base
infrastructure to provide a consistent programming interface and structure for building distributed multi-platform applications. Application developers can select the next layer of Common Business Objects (CBO) as the basis for application integration. It provides a common foundation for building interoperable business solutions. At the highest level, application specific business frameworks will provide core business processes that can be easily extended to provide a complete business solution. Initially, the San Francisco project has examined business
frameworks in the domains of accounts receivable, accounts payable, general ledger, order management (sales and purchase), and warehouse management. Over time, these business frameworks will be extended and enhanced with additional business processes, objects,
and access to more framework interfaces, providing greater application flexibility.
San Francisco is implemented using the Java language. This makes the frameworks, and applications developed using the frameworks, portable across many platforms. It also allows developers to use the many tools and class libraries that the industry is producing for Java development. We expect most development in San Francisco will take the form of Java
applications. However, application developers can create applets to work with San Francisco objects as well.
The following information reflects the current direction for the San Francisco frameworks. IBM has not committed to ship all of the functions and reserves the right to make changes to functions listed in this document. We are working with our advisory groups to help validate and prioritize how functions will be delivered over time. Current plans are to ship the Base technology, several Common Business Objects, and portions of the General Finance vertical domain
frameworks in the initial release.
slide: Overview
The lowest level of framework which can be exploited by application developers is the Foundation. It provides the underlying infrastructure that is used to build the Common Business Objects and the Core Business Processes. It allows San Francisco to hide differences in underlying technology from application developers. This helps to make it easier to support an application on multiple platforms while still exploiting platform specific advantages. The Foundation layer also provides a consistent programming interface and structure for building applications.
The Foundation layer provides two categories of functions which are directly usable by developers. They are the Foundation Object Model Classes and Utilities. To support the distributed, mission critical requirements of San Francisco based applications, the Foundation layer also provides a set of kernel services. In most cases, the kernel services are not directly visible to developers. Instead they are invoked indirectly by the Foundation Object Model interfaces. This approach makes the application programming model much simpler to use. It also allows application developers to use new underlying technology that IBM incorporates into the infrastructure without having to modify their application code. The interfaces that
application developers use remains consistent; only the underlying implementation of the infrastructure changes.
Many of the services are based on the object service definitions from the Object Management Group (OMG). For example, the kernel service provides an object transaction service, collections, communication between distributed objects, and persistence management.
However, San Francisco does not provide a CORBA compliant Object Request Broker. The Foundation merges and combines OMG defined functions with functions provided by Java. It also simplifies the OMG definitions when possible, as well as adding additional function when necessary. For example, instead of supporting all of the locking types defined by OMG we are supporting only optimistic locking (to allow greater concurrent access to data) in addition to the traditional pessimistic locking approaches used by many infrastructures. The industry is currently working on the convergence of CORBA and Java technology, and we will use additional capabilities (such as support for OMG's Interorb Interoperability Protocol (IIOP)) as they evolve.
The kernel services also contain extensions that we found were necessary for our Java frameworks. For example, we use Java's Remote Method Invocation (RMI) as the basis for the communication infrastructure. In addition we have extended the RMI function to include support for areas such as server process management. We do anticipate that some kernel services will be provided by products from other vendors that compliment the Foundation. Examples of this include licensing and encryption technology.
slide: Foundation Layer
Foundation Object Model Classes
The first category of the Foundation functions callable by application developers is the Object Model Classes. These classes provide the basic structure for San Francisco objects and frameworks. In effect they define the application model that is used when building San Francisco applications and frameworks. The classes contain both complete methods that are inherited and used by application developers as well as abstract definitions for methods that may be implemented by developers of application business objects.
The Object Model Classes provide a consistent object model that will fit a wide range of distributed applications. Application developers build OO applications and frameworks by using the base classes and interfaces instead of defining their own object architecture and coding to platform specific interfaces. They allow the developers to specify different options such as
default location and locks, or object identification approach. The interfaces may be implemented
differently, to exploit the advantages of each platform, but the behavior seen by the developer is the same regardless of which platform is used.
slide: Foundation Object Model Classes
Some of the main concepts found in the Object Model Classes are:
- Command - a group of operations on an object or collection of objects. Commands are used to contain logic that does not 'belong' to a single business object. The commands contain many of the functions and procedures for an application or framework. They can be distributed to either clients or servers and can be targeted to affect either individual entities or collections of entities.
- Entity - the independent, shareable, objects (persons, things) that are used in the operation of the business. Entities are often associated with the data that is core to an application or framework. An entity may be persistent (associated with an underlying persistent storage mechanism on a server) or transient. Entities may also be used for temporary caching of data on clients while processing is taking place. The methods associated with each entity generally deal with getting and setting the state (attribute) values or business logic that involves only a single object. A subtype of entity called dynamic entity allows property/value pairs to be associated with the entity at execution time. This provides great flexibility in customizing entities to specific business requirements.
- Dependent - provides a way to have objects with less system overhead than entities. Dependent objects can not exist outside of the scope of an entity. This means they can not be shared, referenced, or take part in transactions, independently. Dependents often contain additional information about their owning entity.
- Collection/Iterator - provide grouping and traversal over sets of objects. Collections are used to group objects together. Some collections are structured so that individual elements may be accessed by a key. Others function as a set of elements. Iterators associated with the collection are used to access the elements and traverse across the collection. For example, an iterator may provide a next method to enable scrolling through a collection.
- Factory - manages the instances of the objects during framework execution. The Factory provides the functions needed to manage the instances of the business objects. This includes functions such as creating and deleting entities, commands, and collections. Different implementations of the factories will allow application developers to target different platforms and persistent storage mechanisms with minimal or no change to the business objects themselves.
slide: Object Model Classes
Utilities:
The second category of Foundation functions invoked by application developers is the Utilities. These utilities provide services that will be needed by most applications built using the San Francisco frameworks. The utilities provide 'completed function' and are designed to be used as is, rather than being extended or modified.
Several different types of Utilities are provided. Administration supports the definition and maintenance of Application Security and System Configuration information. Conflict Control allows a system administrator to block commands that should not be executed at the same time from running concurrently. The Installation utility helps application developers install and
maintain the frameworks, and applications built using the frameworks. The Audit Trail utility provides a way for application developers to keep a history of which users accessed which objects.
Many of the utilities will be provided by using function that already exists in the operating systems or other products. San Francisco will ensure that the functions are well integrated and
provide a consistent look and feel for users. And, as was the case with the kernel services, the Utilities will provide additional capability when needed. An example of this is in the area of Application Security where the utility adds support for items such as grouping users and the methods they can access. Another example is in the area of Conflict Control, which allows
administrators to block the concurrent execution of two sets of logic that should not be executing at the same time.
slide: Utilities
The next layer of the frameworks is the Common Business Objects layer (CBO). It is composed of several independent frameworks that fall into one of two categories: business objects common to multiple domains and common application level services. Speaking in general terms, the business objects represent those entities which a person knowledgeable in the domain would reference when describing how to perform a business task in non-technical terms. The common application services are more likely to be identified when discussing an approach for automating a process.
Business Partner is an example of a business object that we found in multiple domains. It encapsulates the characteristics of a customer or supplier, such as default currency, description,
and the languages used by the partner. Another example of this type of CBO is Address. Address provides a generic way to describe a location, including a postal location. It provides
support for different formatting controls for the address data, and relationships of an address to other objects such as locale and language. An example of the services type of CBO is the
Decimal Structure. It provides the capability to define the number of decimal positions and rules about how the number is to be processed, such as rounding on input or output of the number.
For many of these common business objects, part of the basic structure and behavior is required by multiple application domains and part is unique to an individual domain. An example
of this would be Business Partner where much of the structure related to currencies, languages, and addresses would be required by multiple domains while the structure and behavior associated
with the product supplier relationship would be unique to the logistics domain. In such an instance the common portions are implemented within CBO and the unique structure and behavior is implemented as part of the application domain framework referencing the CBO structures.
slide: Common Business Objects Layer (CBOs)
FIGURE 2 - Core Business Processes Layer
slide: Core Business Processes Layer
The top layer of the frameworks contains the Core Business Processes. The objective for this layer is to create a sound architecture and highly extensible objected-oriented implementation for the basic structure and behavior which any application provider delivering a solution in the selected application domains would require. On top of this basic structure and behavior we implement a very limited set of application functionally so that the frameworks will actually do something as they come out of the box. Feedback from the software vendors we have worked with tells us that the combination of CBO and the Core Business Processes will approximate 40% of a typical working application. It is anticipated that the application provider will in all cases extend the frameworks to add their user interface, country and industry specific requirements, business rules, competitive differentiators, and complementary application
functions. The extension points at which application providers will add or replace business logic are carefully defined during the frameworks design phase.
The application domains which have been addressed in the initial requirements and design phases for the San Francisco project include business financials (accounts payable, accounts receivable, and general ledger), order management (sales orders and purchase orders), and warehouse management (movement of material into and out of warehouse(s)). Figure 2 shows the framework structure of the Core Business Processes Layer. The initial toolkit for San Francisco contains the General Ledger framework, several Common Business Objects, and the Base infrastructure. Additional frameworks and business objects will be staged overtime, based on customer requirements.
The Accounts Receivable and Accounts Payable Ledger frameworks provide the structure and default behavior related to recording and processing accounts receivable and accounts payable items. An example of one of the business tasks included is Payment, which supports both receiving payments from and creating payments to business partners. Another example is the business task Transfer Item, which supports the transfer of an item to a different account or a different business partner.
The General Ledger framework contains the structure and default behavior related to managing the accounts on the general ledger for a company or hierarchy of companies. Examples of
business tasks that are supported include Journaling (create, validate, process, and post GL journals) and Closing (close the books for a GL accounting period and/or year).
The Sales Order Management framework contains the structure and default behavior related to managing quotations, sales orders, and sales order contracts throughout their respective lifecycles. Support is included for business tasks such as determining Pricing and Discounts (maintain, retrieve or calculate sales prices and discounts) and establishing Sales Contracts (create and maintain sales contracts, track customer compliance).
The Purchase Order Management framework contains the structure and default behavior related to creating and managing purchase orders and supply contracts throughout their respective lifecycles. This includes support for business tasks such as establishing Purchase Orders(create, maintain, and confirm purchase orders) and management of Back to Back Orders (manage
Purchase Orders directly linked to specific sales orders).
The Order Management framework provides an abstract model and default behavior for those aspects of order processing that are common across several order related processes (eg. sales
orders, purchase orders, quotations). For example, the Order Data Interchange is an abstract model for managing order data interchange between several sources. It enables preprocessing to
select and normalize data before passing it to where the actual processing will take place.
The Warehouse Management framework supports warehouse logistics tasks. For example, the Internal Replenishment task supports recommendations for stock movements between warehouses. Support for Kit Assembly tracks the stock activity and movements associated with kit assembly. An example of a business object supported is the Product, which includes base product definition, as well as structure and behavior for areas such as product policies, leadtime, and reserves/balances.
slide: Core Business Processes Layer (2)
Much work is taking place in the industry to develop standards in the areas of Java, business objects, and business object infrastructure. One area that is being explored is the relationship between Java and Object Request Brokers (ORBs) such as the standards defined by the Object Management Group (OMG). Another area that is being explored is the type of infrastructure
that is required to support business objects in distributed computing environments. Work is also taking place to see if agreement can be reached on common definitions for some business
objects.
The San Francisco project is participating in many of these discussions. We are working, along with other projects in IBM, to submit proposals to OMG in the areas of Business Object Facilities and Common Business Objects. Developing standards for the industry in these areas will help customers to be able to more easily combine software from several vendors into an
integrated solution. It will also make it easier for application developers to learn to use distributed objects to build their next generation of products. However, the software vendors we
are working with have told us that we should not wait for all of the standards questions to be answered. We are proceeding with building and deploying the frameworks even if standards have not been adapted in many areas.
slide: Standards Activity
Businesses will tend to upgrade and replace their mission critical applications in pieces rather than replacing all of them at once. It is clear that a business will not replace all of their
mission critical applications with San Francisco based applications at one time. San Francisco will provide ways for applications based on the frameworks to coexist with existing business systems.
The first part of accomplishing this is to allow integration with legacy databases. San Francisco provides for the use of schema mappers to allow developers to access relational databases
as San Francisco objects. These databases may be part of a new application design, or could be from existing applications. An open interface is used so that relational databases from several vendors are supported. Our goal is to allow shared, concurrent, update access between legacy and San Francisco-based applications.
A second area to address for coexistence is the interoperation of legacy code with San Francisco objects. We plan to demonstrate that San Francisco objects can call functions provided by applications written in traditional languages. This provides access to a large set of legacy application function. The ability for other programs and objects (such as OLE/COM objects) to invoke San Francisco objects is also being examined. We observed many groups, both within and outside of IBM (including MicrosoftTM working on this problem. We are providing sample code to help ISVs better understand the interoperability requirements for migration and
coexistence.
A final area to consider in migrating to San Francisco-based applications is how to reeducate the developers to the use of the new technology. Developers must learn how to design and develop objects. They must also understand what functions the San Francisco frameworks provide, and how to extend and customize them for their own applications. IBM will provide training to
help teach them the new skills they will require. We are working with tool vendors to ensure their tools make effective use of the frameworks.
slide: Migration and Coexistence Requirements
The ultimate goal of the San Francisco frameworks is to enable rapid application development by providing a base set of constructs for reuse by developers in building application solutions. The developers will be coming from several different application disciplines.
San Francisco will allow them to integrate several different types of approaches into their
applications. For example: compound documents, business process modeling and control (workflow), and internet/intranet and Java. It is our plan to provide sample demonstrations of how these technologies can be integrated to enable rich application solutiondevelopment.
- Compound Documents
Application development in the compound document environments include Lotus Notes and scripting, Java Beans , and OLE (ActiveX)5 desktop centric document style of applications. It focuses on how a document is presented to the end user and how the information/data is represented. Attached to the various sections or parts of the form are scripts containing the functional extensions.
An example is a form representing a sales order. As the form passes through its life cycle, parts are executed and data values populate the form, such as name and address are retrieved for the heading information, inventory items are parts of the body, totals and discounts are calculated for the totals area.
San Francisco frameworks can be used as a basis for these parts, providing the functional extensions for these compound documents.
- Business Process Modeling and Control
Business Process Reengineering is giving focus to a number of technologies, including modeling tools and workflow process control engines. Workflow technology enables a layer of control, outside of the normal application solutions. This allows for flexibility to modify business process to market demands, and at the same time keeping controls and audits for existing processes. Customers are focusing on their business processes, trying to streamline and control them for increased efficiency and cost savings.
Application developers in this environment need to have the ability to use San Francisco frameworks as business activities within a process, and also the ability for the frameworks to initiate business processes. They will use workflow products to "glue" various new and existing applications together into a coherent business process, passing parameters between application activities via workflow products.
- Internet/Intranet and Java
This is currently one of the fastest growing and exciting technologies, enabling distributed application solutions. Applications may be designed and configured to either include execution of objects on the client or to have all execution on the server. Solutions will need to allow seamless integration between Java and non-Java environments.
slide: Technology Integration
Building applications from the business frameworks will be approached in several ways. The simplest of these is when it is possible to use the objects and classes in the frameworks without
changing them. In this case, the developer will write client code that uses a factory object to manage access to the framework business objects. Access could be gained through a command
supplied in the framework. For example, the factory would be used to manage a command (and the associated transaction) that would create, delete, or update a business object.
A second approach to developing applications using the frameworks is to change the frameworks by creating new domain classes from the base object model classes. This will most likely be done when a new business task or process is being added on top of the frameworks. Developers who make these types of changes will need to understand the methods and programming guidelines for creating, deleting, and updating frameworks objects. For example, they will need to understand how to use the factory methods which create and delete business objects.
They would also need to understand how to build the command(s) which implement the new business task.
A third approach in using the frameworks is to change the frameworks by extending the supplied domain classes and methods. For example, it may be necessary to add additional attributes to a class, or to replace the logic in one of the methods. We worked closely with software vendors to identify the types of changes that will be necessary. We then designed the frameworks to make these types of changes easy, with as little impact to other parts of the frameworks as possible. Developers should understand and follow the application model
of the base object classes to ensure consistency with unchanged parts of the frameworks.
slide: Building Applications From Framework
The San Francisco frameworks are designed to make many types of extensions easy for application developers. These include overriding the default business logic in supplied methods, adding additional attributes to existing classes, adding additional methods to existing classes, and adding new classes to the frameworks. Complete documentation will be provided that describes the function of each part of the framework and which leads the developer to the correction section of code they wish to override.
slide: Extension Example
FIGURE 3 - Simple Framework Extension
slide: Extension example (figure)
Figure 3 shows a simple example of one way we expect application developers to extend and modify the frameworks. The fragment of the framework shown includes two classes, Receipt, and Purchase Order Line. Each class has default attributes and methods associated with it. One of the methods on the Receipt class determines if a quality inspection is required. The default
business logic for this method is a simple check of the value of the Quality Inspect attribute for the related Purchase Order Line.
The example shows that the application developer wishes to enhance this logic. They accomplish this by subclassing from the framework Receipt class and overriding the inspection method. In this example they wish to change the logic to include checks against supplier tables, and previous receipts from the supplier. They also wish to ensure that hazardous and high
value products are always checked.
After the developer has made the necessary code changes they compile and reinstall the modified code. The new logic would then be in effect for quality checks, while the remainder of the
framework functioned as before.
slide: Simple Framework Extension
Effective use of frameworks (and object technology in general) in application development will provide value in terms of application quality, development productivity and reduced maintenance cost. To achieve these benefits requires a different development approach than typically used developing procedural applications. The following is a brief overview of a development process
tailored to using frameworks in application development.
slide: Development Methodology
Application development using frameworks consists of four steps. These steps address Business Architecture, Framework/Componentry, Application Architecture and End User/Solution Environment. Following this approach will maximize the value of frameworks in developing applications.
- To start, domain experts must define the business problem to be solved. This involves gathering requirements from experts, users and existing systems. The business problem is broken down into business processes. These are viewed as functional requirements, sometimes referred to as use cases. At this point a search is conducted of the framework repository for available processes that match, or can be extended to match, the functional requirements. The required processes are assembled in an OMD (object model diagram - static model) to analyze the design. The use cases are used to define scenarios that are then used in conjunction with the OMD to define OID (object interaction diagrams) to dynamically analyze the design.
- The focus now moves to using and defining reusable parts. The repository is browsed to find parts that meet or can be extended to meet the functional requirements incorporated into the Model. In some cases the function needed may already exist in the repository. In other cases developers may need to use combinations of existing frameworks, and/or modify existing frameworks to meet specific needs. This may include adding/deleting activities/nodes, or modifying the sequences of activities. If the function does not exist in their repository one may consider buying a framework to incorporate into the design.
- In still other cases you will need to develop new code. In this case, developers will want to design using OO techniques to maximize potential for reuse of the code.
- Developers are now ready to build the application. This will include incorporating the UI with the functions needed to meet all design requirements. The application is assembled by pulling together the selected frameworks and developing any additional code that is not included in the frameworks. The application is prototyped and tested. The frameworks are changed and extended as needed to meet application needs. There should be two to three design cycles, all the way from analysis through prototyping. This is critical to ensure the base design is right. It will become the foundation for defining and testing incremental improvements to the application. Following this step, the application is ready to deploy.
- End User/Solution Environment
- In this step, the application is deployed and integrated into the business environment. For simple applications, this can be as simple as the customer installing and configuring the application (shrink wrap case). For complex applications, this can involve validating the application via process modeling and analysis, testing with end users, integrating the application with other applications, incorporating new requirements and ultimately putting the application in production.
slide: Methodology for Development with Frameworks
The San Francisco project was started because of requests from software vendors to help them find a way to take advantage of object oriented technology. We have continued to keep them
involved as the project has evolved by reviewing our plans and designs with them at scheduled advisory group meetings. Their input and guidance are used to ensure that the frameworks that we are building will help them as they build their future products. More information on becoming involved in the San Francisco project can be found at our frameworks homepage,
www.ibm.com/java/sanfrancisco.
One question that has been pervasive from software vendors is what should they do to prepare their development organizations for using object oriented technology and the San Francisco
frameworks. To help answer this question we are offering a number of education courses to help them prepare. Introductory courses cover basic object oriented concepts and the Java programming language. Additional courses are available on object oriented analysis and design, and how to select initial projects that will have a high likelihood of succeeding. Finally, courses
are given on the San Francisco frameworks, and how to use them as the basis for designing and building frameworks based applications.
slide: Early Partner Involvement
The San Francisco project is targeted at helping application developers rapidly build distributed, object oriented applications. It is doing this by providing a base set of object oriented infrastructure and application logic which can be expanded and enhanced by each developer. This report has given an overview of the San Francisco project and the Business Process Components which are being developed. It was intended to provide the reader with a high level understanding of the architecture and content of the frameworks. The initial toolkit contains the General Ledger Component, several Common Business Objects, and the Foundation infrastructure. Additional frameworks and business objects will be staged over time, based on customer
requirements.
slide: Summary
- IBM, San Francisco and its bridge design are trademarks or registered trademarks of the International Business Machines Corporation in the United States or other countries or both.
- Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc.
- Lotus is a trademark of Lotus Development Corporation.
- Microsoft is a registered trademark of Microsoft Corporation.
Other company, product, and service names may be trademarks or service marks of others.
slide: Trademark Summary
Ivar Jacobson, Object-Oriented Software Engineering
et al Addison-Wesley (ISBN 0-2015-4425-0)
James Rumbaugh, Object-Oriented Modeling & Design
et al Prentice Hall (ISBN 013629849)
David A Taylor Business Engineering With Object Technology
John Wiley & Sons, Inc
Laura Lemay Teach Yourself Java in 21 Days
Charles Perkins Sams.net Publishing
Gamma, Helm, Design Patterns: Elements of Reusable Object-Oriented Software
et al Addison-Wesley
slide: Reading List
|
    
|
