KR20050065638A - Transparent ejb support and horizontal data partitioning - Google Patents

Abstract

The present invention relates to application development using a common object framework (COF). More particularly, aspects of the invention relate to adapting the COF to be substantially compliant with a standard-based server-side component model and remote method invocation protocol. Additional aspects of the invention relate to horizontal partitioning of databases at a middle, business application tier, above a database tier. Combinations including staging, change history, and internationalization of fields within objects are further aspects of this invention. Particular aspects of the present invention are described in the claims, specification and drawings.

Description

Transparent edge support and horizontal data partitioning method {TRANSPARENT EJB SUPPORT AND HORIZONTAL DATA PARTITIONING}

The present invention relates to application development using a common objact framework (COF). More specifically, a feature of the present invention is that the COF is adapted to substantially conform to the standard-based server-side component model and the remote method invocation protocol. An additional feature of the present invention relates to database horizontal partitioning in the middle business application tier, above the database tier. Another feature of the present invention is a combination that includes staging, change history, and internationalization of fields in objects. Features of the invention are disclosed in the claims, the specification and the drawings.

Multi-tired applications have become a popular approach to leverage business logic in a distributed, reliable and scalable manner. In a multi-tier system, the system service tier provides databases, transactions, and other infrastructure. The middle tier provides access to business logic. The client tier accesses business logic. The client tier can be users with a thin and sophisticated client, or can be a program such as a web service client. Multi-tier applications are particularly useful for supporting multiple customers from a single application platform. Multi-tier applications can be adapted to handle similarly formatted data for multiple customers, which has the advantage of including code reuse and scaling.

J2EE and Enterprise JavaBeans ^TM (EJB) proved to be an architecture for encapsulating and servicing business logic, and integrated with mechanisms for data management in a multi-tier environment. Application servers provide access to system services and infrastructure. The application server manages the storage or persistence of objects that encapsulate both business logic and data. On the other hand, outline guide for the Sun Java ^TM 2 platform ^{(Simplified Guide to the Java TM 2} Platform), see the Enterprise Edition (1999). Microsoft's rival architecture is known as the NET framework and DCOM. Monson-Haefel, Richard, Enterprise JavaBeans 3d ed., P. 17 O'Reilly (2001). The old framework with some similar features is known as CORBA.

The lifetime of a multi-tier, encapsulated business application includes both initial development and subsequent management. (Here, business applications are being used to include commercial and non-commercial applications, including one or more mid-tiers, where so-called business logic resides.) The initial development of multi-tiered, encapsulated business applications is visual object-oriented analysis. And modeling tools, can proceed through a relational database mapping process, and can be utilized as a multi-tier encapsulation application component. Management may include staging and deployment of updated business application components. The batch may require generalization of dynamic data such as product name and description (abbreviated as I18N: "i" and "n" plus 18 characters in between).

The tools used for initial development include visual analysis and modeling tools that conform to a unified modeling language (UML) and create object-oriented models of the application and data to be used. Rational Rose is a leading visual analysis and modeling tool. Other products include IBM's VisualAge, Borland's Enterprise Studio, and Neuvis's NeuArchitect. Drafting tools can also be used for visual analysis and modeling, such as Visio or Flowcharter.

OR tools can also be used for development, to map object-oriented models to relational databases. TopLink is a leading tool for mapping object-oriented models to relational databases. Rival tools are produced by Sun Microsystems, IBM, Borland, Oracle, Microsoft, Thought, Inc., and Tibco. Modeling tools that include some OR mapping capabilities are generally very limited and poorly adaptable to supporting the range of available databases.

Application servers for multi-tier, encapsulated business applications can follow the J2EE standard or a similar standard. Application servers for J2EE and EJB 2.0 are provided by Sun, JBoss.org, Borland, IBM, BEA Systems, Warp solutions, Macromedia, Oracle, and many others. Application servers can rely on various databases for preservation, including databases provided by Oracle, Microsoft, IBM, Siebel, Sybase, and others.

Two disadvantages of the tools available are limited integration and lack of support for features useful in maintenance and deployment. Limited integration requires users to re-enter data or follow detailed programming guidelines, so applications that are used in visual analysis and modeling tools, and mapped to OR tools, are among the rival standards for leveraging multi-tiered, encapsulated business applications. It means to match one. In order not to require developers to run manually using existing tools, features that may be useful to support include staging, history of deployment, and generalization of dynamic data. History refers to the recording of batches and optionally the recording of staging and / or testing of new modules. Generalization of dynamic data supports adding additional fields and tables to support foreign language translation of dynamic data by specifying a language or country to be added to one or more basic languages or countries.

A desirable feature, which is not apparent in current systems, is the partitioning of data horizontally in the middle tier, where the data is located in multiple physical databases that are independent of each other, even in databases formed on platforms of different vendors, such as Oracle Database and SQL Server 2000. It becomes possible. In the following, version "2000" has been used only as a reference and is not intended to suggest any limitation on the version of software that can be used to implement the features of the present invention. Existing mechanisms for horizontal partitioning provided by a database vendor use multiple physical volumes within a single, tightly managed system under the control of the vendor's database administrator. For examples of horizontal partitioning techniques, see US Pat. No. 6,453,313, Database management system and method for dequeuing rows published to a database table (1992) by Klein; US Pat. No. 6,112,198, Optimization of data repartitioning during parallel query optimization (2000); See, US Pat. No. 5,970,495, Method and apparatus for achieving uniform data distribution in a parallel database system (1999). As Klien explained, transparent horizontal partitioning of large database tables is used to scale and distribute computational loads along modes and devices in a cluster. Horizontal partitioning means that a table is divided or partitioned into two or more files, where each partition stores records (tuples) with a corresponding key value range. For example, each of the two or more partitions of the customer table may be used for records corresponding to customer names starting with the corresponding letter A-L range. The table can also be partitioned based on hash values. E.g,. Using the hash function of the record index can have any N values, for example 4, the table can be divided into N partitions, where the hash function determines the partition where each table row is stored. Used to Furthermore, each partition may be stored on a different node, or physical device, of the system to facilitate the distribution of computational load for the system.

Instead of a database administrator, the integration of horizontal partitioning into the mid-tier can be useful to support multiple customers with the same application. Transparent horizontal partitioning support eliminates the need for developers to revise their business logic because additional customers are added or the database is repartitioned.

Thus, it is possible to better support and integrate development at various stages from visual analysis and modeling in the deployment and maintenance of multi-tier, encapsulated business applications.

1 is a high level block diagram of a multi-tier application.

Figure 2 illustrates how the common object framework implements the use of EJBs on a J2EE server while providing a middle tier.

3 illustrates objects and relationships for a visually modeled simple shopping cart application.

4 shows a CBOF tab 401 added to a pop-up window for specifying class properties.

5 shows a CBOF tab 401 added to a pop-up window for specifying operating characteristics.

6 shows a CBOF model that can be adapted to EJB wrapping.

7 is a class diagram illustrating features of classes CmoBase 701, CmsBase 702, and CmoAttribut 703, such as are adapted to support EJB and J2EE.

8-10 illustrate adapting COF tools and models to EJB and J2EE support.

11 generally illustrates horizontal division.

12 illustrates classes that can be used to perform horizontal partitioning in the middle tier in the TopLink environment.

The present invention relates to application development using a common object framework (COF). More specifically, a feature of the present invention relates to adapting COF to substantially conform to the standards-based server-side component model and remote method invocation protocol. An additional feature of the present invention relates to horizontal partitioning of a database in an intermediate business application tier above the database tier. Combinations including staging, change history and generalization of fields in objects are additional features of the present invention. Certain features of the invention are disclosed in the claims, the specification and the drawings.

Hereinafter, the present invention will be described in detail with reference to the drawings. Preferred embodiments have been described for the purpose of illustrating the invention, and are not intended to limit the scope of the invention, which is defined by the claims. Those skilled in the art will recognize that variations within the range of equivalents are possible in the following description.

1 illustrates a J2EE and EJB standard sponsored by Sun that may be used in one embodiment of the present invention. See The J2EE turorial, p 10 Addison Welsley (2002) by Bodoff et al. Sun describes the block in FIG. 1 as follows. J2EE server 120 is the runtime part of the J2EE product. The J2EE server provides EJB 125 and Web 121 containers and manages access to the backend database layer 130. The Enterprise JavaBeans (EJB) container 125 manages the execution of enterprise beans for J2EE applications. Enterprise beans 126 and 127 and their containers 125 run on J2EE server 120. The web container 121 manages the execution of JSP page 123 and servlet 122 components for J2EE applications. Web components 122 and 123 and their containers 121 run on J2EE server 120. The application client container 113 manages the execution of the application client 112 component. Application client 112 and its container 113 run on client 110. The applet container manages the execution of applets. It includes one or more Java plug-ins running on the web browser 111 and the client 110.

More generally, FIG. 1 illustrates a standards-based server-side component model and remote method invocation protocol. The Microsoft.NET framework and CORBA include similar components. See Monson-Haefel, Enterprise JavaBeans, pp 5-18. Features of the present invention are considered to conform to the standard if the feature conforms to a version currently or identified herein at the time of application submission or immediately with an off-shoot or any version of the standard at the time of submission. Practical congruence is useful without requiring an overall congruence. It is known that global consensus with a standard will sometimes require the implementation of features of the standard that are considered unnecessary, too expensive or fluxy. In addition, some implementations may be introduced to improve the product, become non-standard as the standard evolves, and will include proprietary features in which customers claim legacy support. Known. The standard is intended to cover both commitment controlled specifications such as EJB, as well as vendor-controlled specifications such as the .NET framework.

Figure 2 illustrates how the common object framework may provide a middle tier, which may be running using an EJB on a J2EE server. Many of the components of FIG. 2 match and are numbered accordingly. In Figure 2, one of the content and web beans of a web container is described. In the web container 121, the application includes a common object framework (COF) 240A, a role application 241, a web service engine 242, and a collaborative process manager 243. COF provides support and access to persisted objects and reduces the need for the developer of role application 241 to handle persistence, transaction management and related tasks. COF can optionally support staging, change history, generalization and horizontal partitioning, application specification application incorporated as a method and reference described in the application. Web service engine 242 and cooperative process managers are components used by Commmerce One to provide web services; The specification of such an application in a web container is not critical to the present invention. Nevertheless, the solid arrow connecting the cooperative process manager 243 to the COF 240A and the dotted line connecting the CPM 243 to the COF 240B and the CJB 127 correspond to the available services from the COF 240A code. It illustrates the option to replace the services and data support provided by the EJB container 124 for that within the web container 121. Similar labeling of COF code in the enterprise container 126 and web container 121, such as 240A and 240B, can be wrapped for EJB handling with little or no rewriting of COF code and as an EJB-matching interface. It was intended to. As shown, a COF can be made available in either a web container or an EJB container. Applications may have an active session concurrently with or with all of the set of COF components. Although FIG. 2 illustrates this implementation in the context of an EJB environment, those skilled in the art will recognize that the same approach can be applied to other standards-based server-side component models such as DCOM and to remote method invocation protocols.

The so-called common object framework provides basic implementation and tools for managing the overall software life of business objects, which are described in more detail in the incorporated application specification. This includes design including transparent internationalization, staging, change history and customer attributes, UML models, complete code and database generation. Tools are provided for the ongoing maintenance of database-independent code and data schemas. Common object framework components fall into categories that include utility libraries, business object frameworks, and system management tools. Utility library components include common code level utilities such as (generalized) exceptions, logging, cryptography, and configuration access. The component also includes generalization functions such as resource managers, date numbers and text. The business object framework provides business object design, code generation, generalization, data staging, version history, dynamic custom attributes, and full create / read / update / delete (CRUD) capabilities. Used for Support for extensibility of any business object, cache synchronization across multiple servers, and scheduler. System management tools are based on the business object framework. The tool includes a data management tool to create a database, load data, upgrade the database overview, and upgrade release changes in the data. There are also extractors and installers for generalization and local kits.

EJB-conforming COF or standard conforming COF is executed by and interacts with various software components. The design of the object model and the generation of code or meta-data (machine readable data) can be implemented according to Rational Rose 2001a or higher. Also, hereinafter, version " 2001a " is not intended to suggest any limitation as to the software version that can be used only as a reference and can be used to implement the features of the present invention. When using Rational Rose, an add-in is installed to provide the functionality shown in Figures 4-5 and described below. Databases can be mapped, created, and accessed using a suitable JDBC driver such as TopLink 3.6.1, SQL Server 2000, Oracle 8.1.7 or DB2, and I-net OPTA 4.15, Seroptor, or IDS JDBC Lite 3.5.4. have. EJB containers such as Websphere and WebLogic 7.0 can also be used.

The new and improved modules of EJB-matched COF can be combined in many useful ways. These modules create remote and local EJB interfaces to allow any COF object to be accessed and used as an EJB. The modules use TOPLink 4.0, such as the OR mapping tool, to provide access to EJB-QL as a query language for discovering objects. The tool manages database server sessions including supporting simultaneous access to multiple databases and horizontal partitioning of data. Relationships by database cannot be supported. The relationship provides a client session for application access to any object. The relationship provides a configurable retry mechanism for corrupted database connections. The relationship supports integration with EJB JTA-based transactions and unique concatenated object ids that are unique across database servers in order to preserve the object id resulting from database migration and to perform horizontal partitioning. Object change event notifications are generated as configurable events for object creation, update, and deletion. Callbacks are provided to objects executed for post-object creation, pre-object updates, post-object refreshes, and pre-object deletions. Design and code generation tools are provided for Rational Rose. The database generation tool generates a database or DDL script based on a virtually modeled design. The tool generates an application server deployment descriptor for the generated EJB. WebLogic 6.1 sp2, and WebSphere 5.0 support (requires EJB 2.0 spec support).

3 illustrates the objects and relationships for a virtually modeled simple shopping cart application. The model in this figure was generated using a Uniform Modeling Language (UML) notation for class diagrams. In this example, CmoCart object 301 is used to provide a number of exposed methods. Using CmsCart instead of CmoCart means that the object exists during the session and is not preserved for subsequent sessions, as opposed to the customers and orders that are preserved. Cart 301 may be related to CmoOrder object 303 by degree 311. In this example, the primary object is associated with a shopping cart. When committed, the CmoOrder object 303 must be associated with the customer 313 via the Cmocustomer object 302. Along the opposite direction of the relationship, persistent customer 302 may be associated 312 with one or more orders 303. Order 303 includes one or more CmoProductLineItem objects 305. Relationship item 314 connects order 303 to its line item 305. The line item 305 is filled with a product 304 that is connected to the line item by a product 315 relationship.

In UML, objects such as shopping carts can be modeled as classes. By default, in one embodiment of the invention all top-level (ie, no parent class) preservation objects are derived from a base object called CmoBase, as described below in the context of FIG. Alternatively, the transparent object comes from an object called CmsBase. Base objects can be provided in CAT (or unit) files that can be loaded into an object modeling program and referenced by other classes. The purpose of a base class is to provide basic functionality for all objects through a common interface and execution.

Modeling a class in UML format with an object modeling program may include the following steps. First, a package hierarchy is created to specify the directory structure where the class exists and will be created. Thereafter, the class name, class documentation, and class properties can be specified. Supported class properties are, using the tools shown in FIG. 4 and described below, including: persistence, temporaryity, abstraction, code generation, database table name, stability, maximum number of versions, table-level database restriction elements ( For example, complex unique constraints), display in the GUI, name display, description display, generation, and EJB generation.

Next, properties of the class can be specified. The attribute name, type, documentation, database column name, database column length, null values allowed, and whether the attribute is unique can be specified. In addition, the attribute can be static, final and / or temporary. Attributes can be defined as protected to allow subclasses and reflection code to access them. However, other class and application code should only be accessed through getter and setter methods. The following firing types: int, boolean, float, long, short, double, char, string, date, Time, Timestamp, Integer Boolean, Float, Long, Short, EncryptedString, HashString, and Translated String ( TrnaslatableString) is supported.

These types are properly mapped to Java primitive types, which can be mapped to database-specific types. Objects, bytes, and bytes can be mapped to BLOB-types in a database to store streams of bytes. char and Character are databases for storing large character streams and can be mapped to CLOB-types. The EncryptedString and HashedString types are just strings, but the generated code is a specific type that will encrypt / hash the value before setting the property, and decrypt that value when returning the property through getter and setter methods. The TranslatableString attribute is also just a string, but the generated code creates an additional table with columns that represent translated values of the code attribute. This allows certain class attributes to be specified to show that multiple translation values of the attribute may exist to support localization of object values stored in the database.

After that, the relationship of the class can be specified. In UML, using a line with an arrow from one object to another specifies a relationship or association. Each side of the association is called a roll. The role name is equivalent to the attribute name on the class on the "from" side of the association. The roll must be protected controlled (as in the attribute). Each role can specify a multiplicity. "0..1", "1" and "0 .. *" are supported. "0..1" specifies that zero or one instance of an object on that role side may be in a relationship. Similarly, "1" specifies that exactly one object instance on that role side must be in a relationship (which typically means a non-null constraint on the column representing the association on the class on the from side of the relationship). do. Also, "0 .. *" specifies that zero or more instances of the object may be in a relationship. This is equivalent to a relationship involving a set of associated objects.

Relationships can also be bidirectional. This means that each side of the association has visibility to the other side. Any of the state number permutations described above may exist in a bidirectional relationship. In addition, one side of the relationship can be seen as an aggregate (indicated using an open diamond on the starting side of the relationship). The aggregate relationship specifies that the "from" class is unique to an instance of the "to" class. Therefore, it is the responsibility of the "start" class to create and delete instances of the "arrival" class.

Object modeling programs that can be set for each individual package, class, attribute, relationship, and relationship role allow additional properties to be defined. A "CBOF" tab may be added to the properties for each object type with an object modeling program, as shown in FIG. This tab lists the specific properties that can be set for each object type. Modules that generate metadata or machine readable data corresponding to the visible model can access any property of any object. Thus, by adding properties, additional properties of a class can be set to customize subsequent generation of code and other support for that class.

In particular, the Rational Rose object modeling program allows extensions to be added that contain additional property values for various objects. When an object model is created (with characteristics such as Class, Attribute, Association, etc.), a set of properties may be specified and / or set for that object model. The property set can be confirmed and added for customization purposes. 4 shows a CBOF tab 401 added to a pop-up window for specifying class characteristics. The property set or subset 402 can be selected for handling. For the model characteristic, the characteristic name 411, the value 412 and the source 413 (such as the default or override) are displayed. Control all users to handle properties. Properties with non-default values may appear in bold or highlighted.

The following description lists the properties that can be added for each object type, and one or more ways that can be used to control code generation and other support of classes.

1. Project properties: A single object model is considered a "project." Thus, some global properties can be set for the entire corresponding project object.

CopyrightNotice-Overrides the copy notification to be printed in the generated code.

ProjectName-Overrides the class name of the OR mapping project class to be created.

ProjectDescription-Sets the descriptor to be stored as a static variable in the generated OR mapping project class.

2. Class Properties: A class can contain a single UML class object created according to the class diagram. By clicking on the standard property set, a new tab called "Cmo" can be added to the property, including:

Generate-Set to "No" to prevent generating code for some classes that may exist for documentation purposes only.

Set to "Yes" to generate one or more EJB interfaces in the GenerateEJB-class.

TableName-overrides the default table name for the class. By default, the first 27 characters of the uppercase class name can be the table name.

IsStageable-Set to "False" to prevent generating any staging capability for this particular class, as described in detail below.

MaxNumVersions-Set to zero or more to set the number of past changes to maintain a specific class instance.

ReplaceClass-Specifies the full path class name of an existing class that this class execution replaces.

WrapperPackageName-Specifies the package name where the wrapper (ImplC) class is created.

ImplPackageName-Specifies the package name where persistent implementations and their main wrapper (Impl and ImplW) classes are generated.

StageablePackageName-Specifies the package name for which the sustained stable execution (ImplS) is generated.

Specify table-level constraints for the Constraint1 to Constraint7-classes. For example, "UNIQUE (name, owningMember)"

IsDisplayed-Specifies whether the class name should be displayed to the user in a given user interface.

DisplayName-Overrides the default display name of the class. By default, class names are generated by removing any "Cmo" prefix, and by adding a space with an uppercase letter immediately following it.

DisplayDescription-Sets the description that should be displayed for this class.

3. Attribute Properties: Attributes can be added to a specific class for the aforementioned base-type attributes. An attribute may have a new tab called "Cmo" with the following characteristics:

ColumnName-Overrides the default column name for this attribute in the table for this attribute's class. By default, the first 30 characters of the attribute name, which are uppercase with '_' to separate word boundaries, can be column names.

I18NConstraintName (if the attribute is set to unique) Overrides the default constraint name for the _IN table added to this column.

4. Association Properties: Associations can be added between two specific classes. The association may comprise two sides called rolls. The association itself may have a new tab called "CBOF" with the following characteristics:

RelationTableName-If the association represents a many-to-many or bidirectional one-to-many relationship, a middle or "relation" table may be added. Set this property to specify a relation table name. By default, the relationship table name takes the class name of both sides of the relationship and attempts to use "TO" between them. If this name is too large (more than 27 characters), the class name initials (the first letter of the character boundary) followed by the character hash code of the class name are used.

5. Role Properties: A role represents one aspect of an association. The association has a roll side A and a roll side B. Thus, if a property is added to a role object, two additional tabs will be added to the associated property, which are "CBOF A" and "CBOF B", with the following properties.

ColumnName-Overrides the default column name for this association in the table for this association's class. By default, the first 30 characters of a role name capitalized with '_' to separate character boundaries can be column names.

GenerateForeignKeyConstraint-Set to "False" if a foreign key constraint should not be generated for this association aspect.

ForeignKeyConstraintName-overrides the default foreign key constraint name for this association aspect.

As described below, horizontal partitioning may be assigned to include related objects as project properties or as class properties to include groups of objects. Once all classes, attributes, and relationships are modeled, code can be generated.

The operation may also be specified and the characteristics of the assigned pupils are shown in FIG. CBOF add-in tab 501 is shown. At least two properties 521 are accessible indicating whether to create an EJB local interface and / or an EJB remote interface. For each of the properties, a name 511, a value 512, and a source 513 are indicated. More generally, the local interface follows a first protocol with relatively little overhead, adapted to calling and the called objects reside in the same web container 121 or the same package. The remote interface follows a second protocol with greater overhead and is adapted to remote method invocation. Remote method invocation protocols are provided for products and specifications such as CORBA, Java RMI, Microsoft Transaction Server, Microsoft COM / DCOM, Microsoft.NET Framework, and Enterprise JavaBeans (EJB). The choice of creating local and remote interfaces controls the calling overhead and / or interface exposure.

6 shows a CBOF model that can be adapted to EJB wrapping. Referring to FIG. 6, shown is a block diagram of an object framework 610, in accordance with an embodiment of the present invention. In an alternative embodiment, the object framework 610 may easily include various other components or configurations instead of or in addition to the components discussed with the embodiment of FIG. 6.

Useful aspects of COF / CBOF implementation can include the following combinations for modeling objects that have no restrictions on object model design: Use of Rational Rose. Code generation with placeholders or stubs for custom business logic methods. Code generation to support run-time create, read, update, and delete (CRUD) of objects without the need for Rational Rose reverse engineering. Object to relational (OR) mapping with little or no user interaction, beyond the user declaration of a mapping parameter. Definition and mapping information to preserve business objects for a relational database. Definition and creation of relational tables and constraints, including information needed to generate a database overview and tools that use the information to create and / or move databases. Simple method for run-time creation, read, update, and delete (CRUD), accessible through a standard set of APIs for easily creating, reading, updating, and deleting any business object in the framework. Use of a transaction paradigm to create, update and delete a set of objects using atomic transactions in the database. Transactions can survive long because the database is not affected until commit time and optimistic locking are used. Data staging to support changes to business objects without affecting the current product version of the object until the change is tested, approved and utilized. Data change history support, including an audit trail of changes in the underlying attributes of arbitrary objects. Generation of code and information to generate a database overview that can be used for retrieval and transparent storage of translatable string attributes of business objects. Support for adding new attributes to arbitrary objects dynamically in real time without affecting the database overview. Object change notification support comprising options for a business object to be configured to have events generated upon creation, update or deletion of the object. These events can be managed by the event notification service and kept in the database. Also, the business object itself is first updated in memory (init ()), inserted into a database (postInser ()), added to a transaction for update (postAddForUpdate ()), and then updated in a transaction to the database. The method may be executed to perform a predetermined action before (preCommit ()), after being loaded / refreshed from the database (postRefresh ()), and finally before being deleted from the database (preDelete ()).

In the embodiment of FIG. 6, five base class groups are shown above the horizontal axis 614, preferably the base live object class, CmoBaseImpl 630, base interface class, CmoBase 634, base staging class, CmoBaseImplS 638, the base generalization class, CmoBaseI18N 642, and the base wrapper class, CmobaseImplW 644. The functionality and layout of these base classes are discussed briefly in the application incorporated by reference.

In the embodiment of FIG. 6, a root class group is shown between the horizontal axis 614 and the horizontal axis 618, and preferably includes each root class derived from the previous corresponding base class. Can be. In the embodiment of FIG. 6, the root class may preferably include a root live object class AbstractXImpl 646, a root interface class AbstractX 650, a root staging class AbstractXImplS 654, and a root generalization class AbstractXImplC 666. .

In the embodiment of FIG. 6, the sub-class group is shown below the horizontal axis 618 and may preferably include respective sub-classes derived from the preceding corresponding base class and root class. have. In the embodiment of FIG. 6, the sub-class is preferably a sub-live object class, XImpl 670, sub-interface class, X 674, sub-staging class, XImplS 678, sub-universalization class, XI18N 682, sub-wrapper class, XImplW 686, and sub-custom class XImplC 690.

In addition, in the diagram of FIG. 6, the above-mentioned interface class series is shown on the left of the vertical axis 622. A wrapper class series is shown between the vertical axis 622 and the vertical axis 626. In addition, the class groups that are constantly stored in the database 120 are shown to the right of the vertical axis 626. The interface is a generic Java interface exposed to system users. These interfaces define the get, set, add, remove, and custom of business logic methods. The interface also includes the javadoc of the API for reference. This interface should not be modified by hand because modifications made by hand will not remain after subsequent code regeneration.

In one embodiment, this class interacts with TopLink as a software component. Although some of the following descriptions are specific to TopLink, those skilled in the art will recognize that the same approach can be applied to other database mapping and management modules. A persistent class is a class that contains preserved attributes and a class that contains mappings to a relational database. It is an implementation class described as TopLink. Such persistence class types include Impl, ImplS and I18N. The Impl class represents the exact live version of an object in the database. The Impls class represents a shadow or staging version of a live object in the database. All get / set / add / remove methods declared in an interface class are executed in that class. All business logic APIs throw an UnsupportedOperationException. The I18N class contains translatable string attributes and translation locales. The Impl and ImplS classes have a one-to-many relationship to the I18N class. Each time the get / set method of a translatable string attribute is called, the appropriate instance of the I18N class is accessed based on the current location set on the thread. These classes are created and should not be modified by hand.

The wrapper class performs transaction support, staging, change history, and business logic function customization. There are two types of wrapper classes: ImplW and ImplC. The ImplW class is an abstract class that executes only the get / set / add / remove methods from an interface class. These methods check appropriately whether to retrieve or set a value for an Impl object, an Impls object, or a suitable TOPLink transaction clone. The set / add / remove method throws a CeNotInTransactionException if the instance was not added for updating in a transaction. The get method will throw a CeRuntimeException with the message "Invalid wrapper accessed" if an attempt is made to access a replicated wrapper outside the transaction. The ImplC class is a concrete class that is demonstrated when any persistent object is accessed or created. This class is derived from the corresponding ImplW class. The ImplC class can be modified by hand to include the execution of any custom business logic method. The ImplW class is completely created for each playback. The Implc class is typically created and then checked for source control as a separate file that can be maintained. Note the inheritance structure of the ImplW and ImplC classes. The ImplW class comes from ImplC of its superclass. ImplC is from the corresponding ImplW class. Also note that ImplW does not execute the business logic API declared in the interface class. This is done by the Implc class. The class can be declared abstract in the model, which will make the Implc class abstract.

Also note that the persistent class and associated TOPLink transaction clone have a reference to its corresponding wrapper. The persistence instance of the TOPLink cache points to a read-only version of its wrapper. When the clone is committed and absorbed into the cache instance of TOPLink, the corresponding wrapper is invalidated. The clone's wrapper has a reference to its corresponding read-only wrapper, which can be obtained by calling the getReadOnlyObject () method on the wrapper.

A base class hierarchy is needed to describe this set of files. 6 shows a diagram of one embodiment of the present base class hierarchy. At the top of the diagram, there are five base classes: CmobaseImpl 630, CmoBaseImplW 644, CmoBaseImplS 638, and CmoBaseI18N 642.

CmoBase 634 is an interface class from which all objects 332 are derived and executed. This interface includes the declaration of all basic attributes and the actions that all objects 332 should perform. Various features of this object framework 610 include attributes and methods that are added to this interface in order to make them applicable to all objects. CmoBase 634 also serves as a method for representing the objects 332 created by the mechanisms provided in this framework. An alternative Cmsbase class 702 may be provided for transient objects that do not require persistence, as shown in FIG.

CmoBaseImplW 644 represents a wrapper object that includes an execution to wrap access to other execution objects (CmoBaseImpl, cmoBaseImplS, and cmoBaseI18N). The CmoBaseImplW class implements the CmoBase interface. The purpose of the CmoBaseImplW class is to determine whether an instance of Impl (for live objects) or ImplS (for staged objects) should be called to perform an action. This class has four important relationships. liveObject maintains an instance of a CmoBaseImpl object, which represents the primary live business object in the database. The shadowObject maintains an instance of a CmobaseImpls object, which represents a shadowed or staged version of the live business object in the database. clonedObject maintains a duplicate copy of libeObject or shadowObject when the object is put into a transaction for creation or update. liveClonedObject maintains a duplicate copy of liveObject when it contains a duplicate copy of the shadowObject (which occurs when the object is staged to update or create in a transaction).

liveObject is given as a read-only wrapper. The wrapper is writeable by adding a read-only wrapper to the transaction, which returns a new wrapper containing a clone of liveObject that can be modified without affecting other users accessing liveObject. When a transaction is committed, the clone is used to send updates to the database and to merge changes into liveObject. Once a writeable wrapper is committed, the wrapper is no longer useful and a read-only wrapper must be accessed (this causes the writeable wrapper to be garbage collected to save memory). An instance of this class is what is returned to the user when any action (create, read, relationship access, and update) is taken.

CmoBaseImpl 630 represents a live persistent object of the database. This class contains properties that control object-to-relational mapping. This information allows you to create a schema that includes tables, columns, and constraints. This class contains attributes defined in the object model that contain attributes representing a relationship (a single relationship with an object type or multiple relationships using a set type). This class also implements the CmoBase interface 634. Getters and setters for attributes and relationships are executed to access related attributes and relationships. Other business logic methods (declared in the model) throw an UnsupportedOperationException to prevent accidental access to the method. Only the ImplW class should access this class and never call any business logic methods on the Impl class.

CmoBaseImplS 638 is essentially an exact copy of the CmoBaseImpl class, but represents a shadow and "staged" value of the Impl instance. These staged values are stored in separate tables and are separate instances, and are therefore provided to indicate that the separate classes are staged, which maps to separate tables. The placement of CmoBaseImpls 638 is further discussed in the application specification incorporated by reference.

CmoBaseI18N 642 is a base class used for generalization support. This class holds the basic attributes required for all tables that contain translatable string values. When the Impl class of an object is created, an inner class derived from cmoBaseI18N 642 will also be created if the class has a translatable string attribute. An instance of CmobaseI18N 642 corresponds to the language translation of the translatable string attribute of the Impl class. An additional instance is provided for the staging value of the translation. Translation lists are maintained at each class hierarchy level. This allows you to add / remove translatable string attributes at any time without requiring a hierarchy of CmoBaseI18N classes and tables. Such features are described in further detail in the application specification incorporated by reference.

When an object is created (eg AbstranctX (646)), the created class extends the appropriate base class. As shown in FIG. 6, AbstractX 646 is an interface derived from the CmoBase base interface. AbstractXImplW 662 is derived from CmobaseImplW 644. AbstractX 646 is derived from CmoBaseImpl 630. AbstractXImplS 654 is derived from CmoBaseImplS 638. AbstractXImplS 654 is derived from CmoBaseImplS 638. Furthermore, because of the translatable string attributes of AbstractX, AbstractXI18N 658 is derived from CmobaseI18N 642.

There is also another custom class called AbstractXImplc 666, which originates from AbstractXImplW 662. The Implc class contains user-specific business logic code for business logic methods that are added to interfaces in the model. The Implc class does not contain any other interfaces or executions that are code generated. This allows Implc to be created only once and then updated only when business logic code needs to be added, changed or removed. Other class types (Interface, ImplW, Impl, Impls, I18N) are always recreated from object model 320 whenever there is a change in the model. This solves the problem of generated code that requires any custom changes by hand that need to be engineered back into the model, but allows business logic execution to be recorded that can change over time. The generated code can be used without requiring any code to be written to Implc. ImplC provides a place for user-specific business logic methods to be executed.

In addition, FIG. 6 illustrates how another class, called X, can further extend the AbstractX class. Each generated class type of X is derived from the appropriate class type of AbstractX. However, XImplW 686 is derived from AbstractXImplC9666, whereby the execution of xImplc 686 may override any business logic method of the AbstractX class as if it were a direct subclass. One feature of the present invention is the automatic handling of the complexity of code and inheritance structures to manage relationships between classes. Intuitively, users only need to consider visually modeled objects and business logic code execution in ImplC.

7 is a class diagram illustrating the characteristics of classes CmoBase 701, CmsBase 702, and CmoAttribute 703, as adapted to support EJB and J2EE. The persistent user mutable object is derived from CmoBase 701. However, many attributes may be temporary and not changeable by the user, so their static values may be assigned to a working copy of an object created in memory. These temporary properties may originate from CmsBase 702, which has properties and properties that are adapted to transience. Examples of persistent user modifiable objects at the attribute level include name, description, maximum number of versions, and action notifications (notifyAction). The CmoBase class 701 contains the automatically generated primary key "id". IDs are unique across rows and types in the DB. Thus, a complete and globally unique identifier is also useful for the horizontal partitioning described below, because it ensures that the ID in CmoBase 701 is unique in the database and in the type. Additional attributes of the CmoBase 701 include the shown state, versioning, and staging attributes. As shown in FIG. 10 below, the classes CmoBaseLocal and CmoBaseRemote originate from and are made correspondingly. CmoAttribute 703 supports custom attributes on objects as further described in the application specification incorporated by reference.

The adaptation of COF tools and models to EJBs and J2EE is illustrated in Figures 8-10. Preferably, the business object interface in the system should extend from javax.ejb.EJBLocalObject 1013 in FIG. This extension pattern provides access to invoke method calls on EJB objects running on the same Java virtual machine (JVM) without incurring the overhead associated with remote access. Each business object that needs to be accessed remotely requires a separate interface that is located under the "ejb" package with the same name as the local interface. The remote interface extends javax.ejb.EJObject 1012 and includes only methods that can be accessed remotely. In addition to the local and remote interfaces, as shown in FIG. 9, the ejb specification requires a local home interface 912 to create and search for ejb objects. Each business object has a local home interface 912 that extends javax.ejb.EJBLocalHome 911 and a remote home interface 902 that extends javax.ejb.EJBHome 901.

Bean classes containing code execution business logic are typically named by prefixing the interface name with "ImplC". For example, in FIG. 8, PersonImplC 842 and EmployeeImplC 862 are objects intended to contain business logic corresponding to human and employee interfaces 821, 841. Not all business methods in "ImplC" are remotely accessible. The remote method can be executed with the return value set to serializable and the parameters of the local method, as necessary to conform to the EJB. To enable this, the framework creates a class with the suffix "Bean" (eg, PersonBean) on which additional remote business methods can be executed. In addition to providing business logic execution, a number of EJB-specific callbacks are executed. This callback is provided for persistent objects by executing the javbax.ejb.EntityBean interface 1011 in the cmoBaseImplW class (644 in FIG. 6). Callbacks executed to provide EJB functionality are ejbCreate (), ejbPostCreate (), ejbFindByPrimaryKey (PrimaryKey key), ejbLoad (), ejbStore (), ejbRemove (), ejbActivate (), ejbPassivate (), setEntitycontext (Entitycontext ctx), and Contains unsetEntitycontext (). Among these callbacks, the ejbCreate () method is called when the client calls the create () method on the home interface. The ejb container creates an instance of a bean (Implc class) and calls the ejbCreate () method on that bean. The execution is: to obtain or create a CmoTransaction; To add the bean to a transaction; To initialize the wrapper object; To pre-assign object IDs; You must provide a method to return the PrimaryKey object. This method needs to be overloaded in many cases to pass in non-null database constraint parameters needed to initialize the object.

The ejbPostCreate () method is called by the container immediately after the ejbCreate () method is called. This method must have the same number of increments as ejbCreate (), provide additional initialization, and allocate resources for its lifetime.

The ejbFindByPrimaryKey (PrimaryKey Key) method is called when the client calls findByPrimaryKey () on the home interface. Execution is: to indicate that no transaction is needed; To search for an object in the database based on the object id (using the CmoClientSession.findById () method); You must provide a method to return the PrimaryKey object. This method needs to be overloaded for custom queries.

The ejbLoad () callback method roughly corresponds to the "read" functionality of an enterprise bean. In one embodiment implementing the features of the present invention, a bean is typically initialized during a create () or find () method call using TOPLink OR mapping, so that this method can be used for some post processing operation.

The ejbStore () callback method roughly corresponds to the "update" feature of an enterprise bean. This feature is already encapsulated in our CmoTransaction, in addition to the fact that CmoTrasaction needs to be started and objects are added to the transaction for updating.

The ejbRemove () callback method removes an object from the data store. CmoTransaction starts and adds an object to delete.

During the activation process, the ejbActivate () method on the bean instance is called following the ejbLoad () method. When the bean is activated and its state is properly synchronized to the underlying database record, the business method is processed. Any subsequent call to the business method will be delegated directly to the bean instance.

ejbPassivate () is used during passivation. During the passivation process, the container calls the ejbStore () method on the bean instance. The bean instance is responsible for updating the database. After the database is updated, the container calls the ejbPassivate () method on the bean instance, giving it a chance to free up any preallocated resources before the bean is passivated.

The setEntityContext (Entitycontext ctx) method is called in the bean's context during bean initialization. The phrase is stored for future use. unsetEntitycontext () satisfies the set syntax. The container may garbage-aggregate pooled beans if it decides to free the resources used by the bean and in this case no transition to the existing state occurs. During this transition period, the container invokes the method. The method deallocates any resources used by the bean.

8 shows an application of an EJB-conforming CBOF object model for a simple object for person (s) and employee (s), with local and remote access and interfaces. Person 821, 824 and employee 841, 834 objects execute from EJBLocalObject 811 and EJBObject 814. Execution of local objects supports local reduced overhead access. Execution of EJBObject supports remote object access. Standard properties of local objects are derived from CmoBase 812 as described above. Throughout Figure 8 the suffixes (ImplW and ImplC) are used for wrappers and specific implementations. EntityBean 813 is executed by cmoBaseImplW 822. Execution of the person 821 and employee 841 objects is derived from CmoBaseImplW 822. Such implementations include PersonImplW 832, PrsonImplC 842, EmployeeImplW 852, and EmployeeImplC 862. As discussed in the syntax of FIG. 9, two home objects EJBLocaHome 853 and EJBHome 833 are provided for local and remote interfaces. Execution of such a home object includes PersonLocalHome 863, PersonHOme 843, EmployeeLocalHOme 864, and emPlyeeHome 844.

9 illustrates in accordance with an EJB convention that generalizes part of FIG. 8 and requires a home for an object. Homes are provided for remote and local objects and interfaces 901 and 911, respectively. Each business object has a remote home interface 902 that extends javax.ejb.EJBHome 901 and a javax.ejb.EJBLocalHome 911 local home interface 912. Remote and local home interfaces 902 and 912 are further extended by ComApplicationConfigRemoteHome 903 and comapplicationconfigLocalHome 913.

FIG. 10 also illustrates additional mechanisms for generalizing parts of FIG. 8 and supporting EJ. Objects javax.ejb.EJBObject 1012 and javax.ejb.EJBLocalObject 1013 extend to CmobaseRemote 1022 and CmoBaseLocal 1023.

The EJB 2.0 specification supports relationships between EJB entities. All three basic relationship cardsinalities (one-to-one, one-to-many and many-to-many) are supported. In addition, these relationships are handled using the new query language of the EJB 2.0 specification. Relationships are managed through abstract accessor methods. In the case of a relationship with multiple associated objects, the parameter or return value type of the abstract accessor is a collection class representing the relationship. These set classes implement the java.util.collection or java.util.Set interface. Optionally, the specification may add java.util.Map and java.util.List as return types. In the case of a multiplicity relationship of a set class in 1, the parameter or return type of the abstract accessor is a single instance of the associated object.

The relationship accessor in the COF is a parameter or return value type as the corresponding object array. In order to make the accessor ejb accessible via the remote interface, additional methods for the relationship are provided in the remote interface and executed in ImplW. For example, the Employee To Address relationship can be one-to-many and bidirectional. Local and remote methods can be executed that traverse a relationship, such as an employee-to-address relationship example. For example, local methods are: public void set AddressesRemote (Collection address); public void addAddressElementRemote (Addressaddress); And public boolean removeAddressElementRemote (Address address). The remote method is: public boolean removeAddressElement (); public void setAddressesRemote (Collection address); public void addAddressElementRemote (Address address); And public boolean removeAddressElementRemote (Address address). The getAddressesRemote () method supports collecting an objectID list of all address objects associated with an employee. You can use the CmoQueryCursor mechanism because you do not need to cache arbitrary address objects. Thus, a new class called CmoObjectCursor that extends from CmoQueryCursor is created to support remote cursoring of EJB instances. This method supports retrieving or creating the corresponding ejb object that uses the remote home interface and stores it as a collection. This returns a collection of ejb objects. The setAddressesRemote (collection address) method supports creating or retrieving the corresponding ejb object using the local home interface. This stores the objects in an array. This is called to update the corresponding local method.

Transaction support is an important infrastructure service provided by the J2EE platform. The specification describes the Java Transaction API (JTA). JTA is an interface that provides access to underlying transaction managers. Some of the major interfaces include: javax.transaction.UserTransaction and javax.transaction TransactionManager. UserTransaction is exposed to application components, while the underlying interaction between J2EE server and JTA TransactionManager is transparent to application components. TransactionManager execution supports server control over (container-demarcated) transaction boundaries. Both JTA UserTransaction and JDC's transaction support are available for J2EE application components. The J2EE platform supports two transaction management paradigms: declared transaction boundaries and programmed transaction boundaries. At declarative demarcation, the container is responsible for initiating, committing, and rolling back the transaction. The container initiates a transaction for all operations on the bean by the client. Clients have the ability to acquire JTA transactions and perform multiple operations in one transaction. This will provide the flexibility to enhance certain business logic with dependencies between operations. Transaction attributes support declared transaction boundaries and convey the intended transactional behavior of the methods of the associated EJB component to the container.

Six transaction attributes: Required, RequiresNew, NotSupported, Supports, Mandatory, and Never are supported for container-managed transaction boundaries. A method with the Required transaction attribute is executed within the JTA transaction; Depending on the situation, new transaction statements may or may not be generated. If a calling component is already associated with the JTA transaction, the container will invoke the method in the syntax of that transaction. If the transaction is not associated with the calling component, the container will automatically create a new transaction and commit the transaction when the method is committed. Methods with the RequiresNew transaction attribute execute on the syntax of the new transaction. If the calling component is already associated with a transaction statement with a transaction pending, a new transaction statement is created, and the method executes on the new transaction's syntax after the commit of the transaction of the calling component is restarted. Methods with the NotSupported transaction attribute are not intended to be part of a transaction. If the calling component is already associated with the transaction syntax, the container suspends the transaction, invokes a method that is not associated with the transaction, and restarts the calling component's transaction at the time the method commits. Methods with the Suppports transaction attribute support the calling component transaction situation. If the calling component does not have any transaction syntax, the container will execute the method as if the transaction attribute was Notsupported. If the calling component is already associated with a transaction syntax, the container will execute the method as if the transaction attribute were Required. Methods with mandatory transaction attributes are called from the transaction syntax of the calling component. Otherwise, the container throws a javax.transaction.TransactionRequiredException. Methods with a Never transaction attribute MUST NOT be called from the transaction syntax of the calling component.

Programmatic transaction demarcation is the hard coding of transaction management in application code. Program transaction boundaries are viable options for session JEB, servlet, and JSP components. The program transaction may be either a JEDBC or JTA transaction. For container-managed session EJBs, although not recommended, it is possible to mix JDBC and JTA transactions.

One feature of the present invention is the ability to stage product data. To solve the problem of not replicating according to the database, one embodiment stores the step values of the data in the same database as the live product values. However, these step values should not be in the same table as the live product values. If the step data is in the same table, the performance and size of the table will be affected. Thus, for every object that requires staging capability, two tables can exist in the database. Since additional tables are then required, the OR mapping tool requires another Java class to represent the table. For the stageable Impl class, there is a corresponding Impls class. Since the class structure and OR mapping are handled automatically, as table outlines are generated, the effort to add additional tables and / or classes is substantially reduced.

Copying the properties of an existing object to a new object is usually easy. But staging can also support changes in the relationships between objects. To support all the various staging features, a number of rules can be defined, such as:

A live production object instance has a reference to a staging instance. An object can be staged once at the same time (in other words, the object has a one-to-one bidirectional dedicated relationship to the staged instance).

2. Once the object is staged, the live instance cannot be modified. If the live instance can be modified, merging of changes made to the staging value and the live value will need to occur. This is unnecessarily complicated. Changes typically need to be directly staged or modified for the live object, or not both.

3. The relationship must be for a live instance, not a staged instance. If not, many relationship mappings (such as live to staging, live to live, staging to live and staging to staging) must be managed. In addition, when an object is changed staging versus live or vice versa, the relationship indication for the object needs to manage that change. This rule simplifies the above problems. Furthermore, the live instance to be referenced can be staged and have a reference to the staged instance, so that although not directly, inherently various relationships can be supported.

4. Staging change must be part of a stageable project. One way to manage a staging change set is to combine the changes in some containers. The staging project keeps track of all the staged objects. The project can then be utilized, used for testing, or canceled.

5. An object can be staged only once at the same time and can be part of a single stageable project at the same time. In addition, it is generally not necessary to manage the merge.

Supporting a one-to-many relationship is easy in a staged table due to rule # 3 described above. Every relationship can reference a live instance, so a staged table column that references another object needs to refer to a live instance of another object. One-to-many relationships should use intermediate convention tables even when the relationship is bidirectional. This prevents the live object from having to recognize any relationship to the staged instance.

A many-to-many relationship will also have an intermediate relationship table that links the staged instance with the live instance. This intermediate relationship table must be different from any existing live object relationship table. If the many-to-many relationship is bidirectional, two intermediate relationship tables need to be created, one for each direction. This is because relationships can be staged from either side of the relationship and have different values. Additional relationship tables are created automatically and efficiently.

An additional feature of the invention is the horizontal division in the middle-tier, as opposed to the so-called back office, database tier. 11 generally illustrates horizontal division. In this example, the object model includes components 1 1101 through n 1102, an account 1102, and a BI 1104. Component 1 is mapped to the main 1111 database, which is a single database. Component n is mapped to main 1111 and main 1112 and split horizontally along databases. Component n may be a single object or a group of objects. A facility to group and specify which groups of objects are divided horizontally can be useful. Such a facility for setting project properties is described above and will be familiar to users of Rational Rose. Alternatively, a facility may be provided for assigning objects to one group or for assigning objects to multiple groups, and then setting group default properties or group-general properties that should not be overridden. In either embodiment, it is useful to have groups of objects in the horizontal partition (or not partition) as a result of a single setup. Component 1..n of this example may be configured by a database declaration. Declarative approaches, such as user committed tables or user readable (eg XML) organization, can be used to link the logical name of the database to a specific and / or object and group of objects. In this example, the account and BI were mapped to the secure 1113 and BI 1114 databases, respectively.

Classes that support horizontal partitioning in the middle tier are adapted to interfaces to databases or database infrastructures, in this example to TopLink. 12 shows classes that can be used to perform horizontal division in the middle tier. This diagram is most easily understood as starting from the top left of CmoServerSession (1221). This object holds information and database connections obtained by the infrastructure. Since the logical identification of the database is static, the object can have static data and static methods and can be shared by multiple users. CmosystemSession 1231 can be obtained from the server session 1221, CmoSystemSession 1231. Only a single system session object needs to be created for the server. The CmoclientSession object 1241 holds state information and syntax for each user of the server. The object holds user specific information such as the user's locale and login. Status information similar to that maintained in HTTP is maintained. The methods getDb and setDb are used to set the syntax information. Client sessions can include multiple databases. The relationship between the client session 1241 and any active database session 1242 is a .dbClientSessions relationship. The database client session is not active when a client session is obtained. During a client session, many database client sessions can be active.

The object CmoTransaction 1251 of this figure buffers the data so that it is divided horizontally. The role of CmoTransaction 1251 is to maintain the state of the transaction, including the long transaction, until the transaction is about to be committed. When a transaction is called, information is collected that allows for the resolution of the database to which the new or modified object belongs. When a transaction is about to be committed, it can be committed in one or more databases by one or more instances of CmoDatabaseTransaction 1252.

Horizontal segmentation support, including middle column objects 1212, 1222, 1232, 1242, and 1252, can be added to existing infrastructure interfaces 1223, 1243, and 1253 plus exposed sessions 1221, 1241, and 1251. It does not change the way the session is exposed or the business logic that operates on the session. For example, horizontal segmentation can be used to support two car manufacturers F and G using the same code and software. All data for F must be partitioned into an Oracle database, for example, and all data for G can be partitioned in an SQL database. For example, if a phrase (F or G) is set at user login, the partitioning of data should be transparent to the system. Every call to F's data can crash the Oracle database, and every call to G's data can crash the SQL database. The same logic can be provided regardless of whether the data service is provided to F or G. Code that executes business logic may be shared because only the syntax configuration identifies or separates the data in F and G. Partitioning at this level should separate customer data. The smaller the database, the more efficiently it can be processed. The search by F never finds G's data, even at the back office database server level. Mix-up in WQL, QL, or other database queries cannot return data from more than one database, which reduces the chance of one customer gaining access to another customer data. This is especially true when plaintiff and defendant attorneys share some database components but want their work to be strictly separated, or when competitors use a service with the same value and the service provider uses data that is secure. This is useful in shared competition situations, such as when you want to ensure all of your customers (competitors). The customer's data is kept safe from other customers, but periodic maintenance can be accomplished by a system administrator who repeats along multiple customer statements.

Middle column objects 1212, 1222, 1232, 1242, and 1252 support access to multiple databases based on syntax, where multiple databases store horizontally partitioned instances of the same object. A CmodatabaseServerSession object 1222 exists for each database that is active on the server. The database is logically recognized in cmoDatabaseServerSession by logical name, which may be maintained as the keyed attribute dbName of the object. The getAllVersions method supports versioning. This method returns the version of the object in the database or outline version. The code that accesses the database or the code that guarantees access to the database checks that the versions do not conflict. The CmoClassConfiguration object 1212 connects the object to the database. One cmoClassConfiguration object 1212 represents an object that can be accessed from a database. CuDatabaseconfig 1232 holds physical database configuration information corresponding to logical database names. This information can be used to link multiple physical databases to a single logical name, depending on the syntax set. CmoDatabseServerSession 1222 is connected to the infrastructure object ServerSession 1223 by a #serverSession relationship. CmoDatabaseClientSessiob 1242 manages client sessions as infrastructure object ClientSession 1243, taking into account the syntax of the client (which is F or G in the above example).

When a transaction is about to be committed, in case of reinviting the operation of CmoTransaction 1251, CmoTransaction calls CmoDataTransaction 1252 with the appropriate syntax set. CmoDatabaseTranaction 1252 connects with infrastructure object 1253, which is, for example, UnitOfWork in TopLink to process one or two-phase object commits.

Two-stage commit is a transactional protocol that commits changes across multiple physical databases in atomic fashion. In one embodiment, the software component for supporting two-phase commit includes a JTS-based application server (any J2EE 1.3 compliant App Server), distributed transaction support and a database (e.g., in a JDBC driver (e.g. Opta2000 and Seropto). For example, it includes distributed transaction support within SQL Server and Oracle. COF and COF / EJB support transaction integration with JTS-based (Java Transaction Service) transaction managers (typically provided by J2EE application servers). Use TopLink The use of two-phase commit is an option Two-phase commit is very expensive, so it is only used when needed User transactions that affect multiple objects and extend multiple physical databases are typically two-phase commit transactions EJB objects and COF objects need to be committed in a single transaction When it is suitably in the two-phase commit. This protocol may be used by any combination of the COF objects, the divided objects and horizontal EJB object.

Note that horizontal partitioning does not depend on whether COF or other protocols are used directly or encapsulated in EJB or other remote method call encapsulation. Middle tier encapsulation handles horizontal partitioning along an independent database without depending on the database manager. This may be referred to as loosely coupled horizontal partitioning, because an independent database may be an incompatible database supplied from different database providers.

Also, relatively small business logic or system code may need to be changed to use horizontal partitioning. Some basic rules are listed.

1. If only one database is used in the configuration file, meaning that the value "database.projects" for a property is single, the database will always be used.

2. If more than one database is present in the configuration file, database information is resolved either explicitly or implicitly when the operation is performed. Explicit resolution means that "setDb (cudatabaseconfig)" is called a CmoClientSession object and / or a CmoTransaction object. CuDatabaseConfig objects are typically created during system startup time. "CmoserverSession.getAvailableDbObjects ()" is used to get a list of available database objects for the entire system. For a particular class, "CmoServersession.getDbObjectsforClass (Class aClass)" and "CmoServerSession.getDbObjectsForClass (String aClassName)" return a list of CuDatabaseConfig objects in which "class" resides. Implicit resolution means that the cmoClientSession and / or CmoTransaction objects can be found intelligently without having to specifically call "setDb (CuDatabaseConfig)" in the application code as described below.

3. When database information cannot be resolved explicitly on the CmoClientSession and CmoTransaction objects, the session object will attempt to resolve it by using all the objects to be included. If any object included has some (non-null) database information, this information will be compared with the database information associated with the session object. If the database information for the session object is null, the information will be set to database information from the object; If the information is not, an exception will be thrown. This logic will continue for every object it contains. To assist in identifying database information for operation and / or transaction, COF introduces a new interface "CmoDbConflictResolve". The CmoDbConflictResolve object is configured for one project. This can be done in a configuration where the key is database.conflictresolver. {Full class name of the project} = {full class name to run the cmoDbConflictResolver interface}.

4. The resolver is called at the last minute. Because it means that the object is created, it is not called until the object is about to be committed. This means that the analyzer can expect all attributes of the object to be set for creation, and that the attributes can be used to determine the database to which the object belongs.

For search cases, expressions, attribute queries, or attribute map queries are passed through so that the analyzer can make decisions based on the attributes being queried for the database being queried. Queries based on databases within a single query cannot be supported. This is also required if setDb is not yet called on the clientSession and the object being queried is configured to exist in one or more databases.

The way CmoDbconflictResolver can be executed is to use some other dynamic data or some configuration information that allows some object attribute values to be mapped to a particular physical database. This should be kept as simple as possible. For example, to determine which databases or databases are named based on orgID, we use the organization's organization id, which allows for simple mapping. This database name is a "logical" name that is determined at configuration / installation time to name the database and configuration information about where the database is located. Thus, the name used is a logical name and represents the name of the database configuration to be accessed, not the actual physical database name within the database system.

Four functions are available in the client session to control database information. These are: setDb (CuDatabaseConfig); getDb (); overrideDb (CuDatabaseconfig); And resetDb (). getDb () returns the current database set in the client session object; overrideDb (CuDatabaseConfig aNewdb) and resetDb () use a stack mechanism to track changes to db info in client sessions. overrideDb (CuDatabaseConfig aNewDb) pushes the current db onto the stack and sets it to be "aNewDb" passed through the current db. resetDb () sets the current db to be the top element of the stack if it is not empty; If not, nothing will be done. setDb (CuDatabaseConfig aNewDb2) will set the current db to be "aNewDb2" and empty the stack. Thus, if setDb () is called when the stack has some information, the stack will be empty. A specific client session, the system client session object, uses these four functions per thread base. Thus, database information on a thread does nothing to that on another thread.

The overrideDb (CuDatabaseconfig aDbconfig) and resetDb () functions cannot be called in CmoTrasaction even though they are subclasses of CmoClientSession.

The CmoDbConflictResolver API: public CuDatabaseConfig resolveCreate (CmoDbresolverInfo aDbResolverInfor) throws a CeDbNameconflictResolveException; public CuDatabaseConfig resolveFind (CmoDbResolverINfo aDbResolverInfo) includes publishing CeDbNameconflictResolverExceptiion. The CmoDbResolverInfo API is: public CmoClientSession getClientSession (); public Class getMainClass (); public HashMap getAttValuePairs (); public CmoFindObject getFindObject (); And public cmoBase getNewlyCreatedObject ().

When a class is developed that implements the CmoDbConflictResolver interface, getNewlyCreatedObject () in CmoDbResolverInfo can be used to assist in the execution of resolverCreate (CmoDbResolverInfo); Similarly, getAttValuePaires () and / or getFindObject () in CmoDbResolverInfor may be useful in the execution of resolverFind (cmoDbResolverInfo).

From the above description, it will be apparent to those skilled in the art that a wide variety of systems and methods can be made from the features and components of the present invention. One embodiment of the invention includes a method for generating application development code. The method may alternatively be implemented as a system or device to perform the steps of the method. The system or device may include a number of embodiments, combinations of steps, features, options and alternative embodiments of the invention. The method may also be executed as a magnetic medium in which a program for performing the method steps is implemented. The program can include multiple embodiments, combination of steps, feature options and alternative embodiments of the method. Generation of development code is particularly applicable to multi-tiered and encapsulated business application environments. The method is based on the object model and the behavior and relationships of object-oriented application design. Modeling of such objects, relationships, and actions can be performed visually using graphical tools. Properties assigned to an object, relationship, and / or action may include a first property that indicates whether to create an interface for the modeled object. The characteristic may include a second characteristic indicating whether to generate a local and / or remote interface for the specified operation. From the model, machine-readable data is generated corresponding to the model and its characteristics. This may be data implemented in an internal model or an extracted model. The model may be machine readable only or human readable. Machine-readable data is used to map models to databases. In one embodiment, the database is a relational database. Application development code is generated using mapping and machine-readable data. The generated application code may include code to preserve and access objects in the database. The code may further include an interface for a particular operation that matches the first characteristic. The interface to the code and the specific behavior can be substantially consistent with the standards-based server-side component model and the remote method invocation protocol. The application development code may alternatively be substantially consistent with Enterprise JavaBeans (EJB) Standard 2.0 or later. Code that preserves and accesses EJB objects can be substantially matched with the bean managed persistence (BMP) protocol. Alternatively, application development code can be substantially consistent with Microsoft's DCOM specification. In another aspect of the invention, the object-oriented application design may be substantially consistent with the Unified Modeling Language (UML) standard.

One feature of application development code methods that generate method stubs is that custom business logic is added. In order to implement this feature of the invention, code that is regenerated when the object-oriented model for the system is modified must be separated from code containing custom business logic and not overwritten or regenerated when the object-oriented model is modified. . Another aspect of the invention further includes a plurality of third characteristics of the objects and relationships, which control the mapping step. These properties are used to map objects and relationships to underlying databases, such as relational databases. This third property may include whether to support batch staging of the modeled object. The property may include whether to record a change history of the placement of the modeled object. This may further include whether to dynamically arrange one or more fields in the modeled object to generalize the fields. In accordance with features of the present invention, including dynamically arranging fields, code that preserves and accesses modeled objects can analyze elements of a dynamic array to search based on a specified language. This language may be implicitly specified by the data present in the object being processed or may be explicitly specified by the language.

Another feature of the present invention is that the user can specify the application code to generate and the method steps of generating, mapping and additionally generating machine-readable data can proceed without requiring further action by the user. .

Another embodiment of the present invention is that the transaction convocation method is handled by at least one database manager that supports transaction processing. This method can be implemented as a system or device that performs method steps. The system or device may include a number of embodiments, step combinations features, options, and alternative embodiments of the method. The method may also be executed as a magnetic medium in which a program for performing the method steps is implemented. The method may include providing an object-oriented framework of how to access and preserve data through transaction processing support of the database manager. In addition, it provides a version of an object-oriented framework that substantially matches the standards-based server-side component model and the remote invocation protocol. Examples of standards-based server-side component models and remote invocation protocols include Enterprise JavaBeans (EJB), Distributed Common Object Model (DCOM), and COBRA. The method of convening a transaction may further include accepting or buffering the intended transaction-related activity into one or more databases. Such acceptance or buffering can occur simultaneously through standard conforming versions of object-oriented frameworks and object-oriented frameworks. One feature of this embodiment may include buffering the object, and in the direction of committing the transaction, the method further includes calling a database manager to process the transaction. Such features include accepting transaction-related activity by mechanisms other than the database manager. This feature of the invention can be implemented with any of the standards mentioned above including JEB, DCOM and COBRA.

An additional embodiment of the present invention is that the transaction convocation method is handled by at least one database manager that supports transaction processing. As above, the method may also be implemented as a method, device or magnetic medium containing a program for executing the method. The alternative method of this embodiment is a very close variant of the above-mentioned convocation method. One variation includes providing an object-oriented framework of how to access and retain data through the database manager's transaction processing support. The method additionally includes providing a version of the object-oriented framework adapted to EJB standard-matching processing and invocation. The method also includes accepting transaction-related activity directed to one or more databases simultaneously through an object-oriented framework and an EJB-standard compliant version of the framework. In two other variations of this embodiment, the object-oriented framework is adapted to COBRA or in line with the DCOM specification. In any such variant, the accepting staff may include buffering the object, and invoking the database manager to process the transaction, in the direction of committing the transaction.

Another embodiment is a method of preserving data processed by at least one database administrator. As above, the method can be implemented as a method, device or magnetic medium containing a program for executing the method. The present method of preserving data includes providing it with an object-oriented framework of a method of accessing and preserving data through a database manager. The method also includes providing a standard-consistent interface to a method of accessing and retaining data through a database manager. This standard-matching interface can match EJB, DCOM or COBRA. The method also includes intended object access and persistence requests to one or more databases simultaneously through an object-oriented framework and standard conformance interface. When the standard is an EJB, object requests can be provided to Java transaction services by both an object-oriented framework and an EJB standard-matching interface.

A feature of the invention that can be applied to any previous embodiment is that the object-oriented framework is adapted to persistent fine-grained objects in the database. Standard-matching interfaces, including EJB standard-matching interfaces, are adapted to persistent objects in a transaction to one or more databases.

Yet another embodiment of the present invention is that the transaction convocation method is handled by at least one database manager that supports transaction processing. As above, the method may also be implemented as a method, device or magnetic medium containing a program for executing the method. The method includes providing an object-oriented framework of how to perform additional functions and access and preserve data through transaction processing support of the data manager. An additional function may be to stage the object in addition to the production system and for testing. Alternatively, the feature may be to dynamically arrange the fields within the object to generalize the fields. These additional functions may be combined in pairs or all together. The method of convening a transaction also includes additionally providing an object-oriented framework version that substantially matches the standards-based server-side component model and the remote method invocation protocol, which version is also the one mentioned above. The above additional functions are included. A separate embodiment includes each of the additional functions individually, a combination of additional function pairs, and all three additional functions. The standard followed by this method of assembling transactions can be EJB, DCOM or COBRA.

A different embodiment of the present invention is a method for creating a multi-tier business application and database that is horizontally partitioned. As above, the method can be implemented as a method, device or magnetic medium containing a program for executing the method. The method involves specifying the behavior of an object-oriented application design and modeling objects and relationships, where the properties of the object include whether to split the object horizontally along multiple databases. This approach can be applied to any of the objects or groups of objects. Object groups can be represented by a single logical name. The method also includes generating machine-readable data corresponding to the model, including the characteristics. The present machine-readable data may be only machine-readable and human readable, as in the XML specification. The method also includes mapping the model to multiple databases using machine readable data and additionally generating application development code from and from the machine-readable data. Application development code includes code for maintaining and accessing objects along multiple databases. Code that maintains and accesses objects is part of the middle program tier beyond the database tier. An additional feature of the present invention is that code that maintains and accesses objects can invoke multiple independent databases. Such independent databases may be provided by different database providers, or may be supplied by a single database provider and operate independently. Additional features of this embodiment include declaring multiple databases into which the object is partitioned, and declaring one or more fields to be used to partition the object or group of objects into a particular database.

Yet another embodiment of the present invention is a method for executing horizontal partitioning of objects along multiple independent databases in a multi-tier business application, including at least a database tier and a middle business application tier. As above, the method may also be implemented as a method, device or magnetic medium containing a program for executing the method. This embodiment includes declaring one or more fields in at least one horizontally partitioned object that can be used to assign a particular object to a particular database. This does not need to be made in every database to which the horizontally partitioned object belongs, but involves creating a connection to multiple databases to which the horizontally partitioned object belongs. Before or after making the connection, the method includes buffering one or more objects to find, create, retrieve, or create, including the horizontally divided objects. During the search or creation process, analyzing a specific database to which the object belongs calls a specific database in the database tier and uses the declared fields to perform the search or creation. A similar embodiment is a method of performing object horizontal partitioning according to multiple independent databases, including making a connection with multiple databases to which at least one horizontally partitioned object can belong. Furthermore. Sets or identifies the specific database to which the horizontally partitioned object belongs Before or after the decision step, buffer one or more objects to retrieve, create or retrieve or create, including the horizontally divided objects. During a search or creation process, a specific database in the database tier is called to perform a search or creation. Multiple databases to which horizontally partitioned objects can belong may be referred to collectively as a single logical name. A particular database between multiple databases is logically mapped using one or more horizontally partitioned object attributes. These attributes may be fields of the horizontally divided object.

Although the present invention has been described with reference to preferred embodiments and examples as described above, it should be understood that these examples are intended to be illustrative rather than restrictive. Computer-assisted processing is included in the described embodiments. Thus, the invention may be implemented in a method for computer-assisted processing, the system comprising logic to execute the method, a medium on which logic to perform the method, a data stream on which logic to perform the method, or a computer Include accessible processing services. Various modifications and combinations may be made within the scope of the invention, but it will be apparent to those skilled in the art that such modifications and combinations are within the scope of the invention as defined by the claims.

Claims (46)

A method of generating application development code for a multi-tier encapsulated business application. Visually modeling objects and relationships and specifying operations of an object-oriented application design, wherein the properties of the objects, relationships, and / or actions indicate a first property indicating whether to create an interface to the modeled object And a second characteristic indicating whether to generate local and / or remote interfaces to the specified operation; Generating machine readable data corresponding to the visual model, including the characteristics; Using the machine readable data, mapping the visual model to a database; And Additionally generating application development code from the mapping and the machine readable data, the code for maintaining and accessing the modeled objects in the database, and for maintaining and accessing the objects consistent with the first property. And including interfaces to the code and interfaces to the specified operations that are consistent with the second characteristic. 2. The method of claim 1 wherein the application development code substantially conforms to a version of Enterprise JavaBeans (EJB) standard 2.0 or later. 3. The method of claim 2 wherein the code for maintaining and accessing objects substantially conforms to a Bean Managed Persistenc (BMP) protocol. 2. The method of claim 1 wherein said application development code substantially conforms to a, NET framework specification. 2. The method of claim 1 wherein the object-oriented application design substantially conforms to a unified modeling language (UML) standard. The method of claim 1, wherein the properties further comprise third properties of a plurality of objects and relationships that control the mapping step. 7. The method of claim 6 wherein the third properties controlling the mapping step include whether to support staging of the placement of the modeled object. 8. The method of claim 7, wherein the third properties controlling the mapping step further comprise whether to record a history of placement changes of the modeled object. 2. The application development code generation of claim 1 wherein the properties of the objects further comprise one or more fourth properties that indicate whether to dynamically arrange one or more fields in the modeled object to generalize the fields. Way. 10. The method of claim 9 wherein the code holding and accessing the objects analyzes which element of the dynamic array to retrieve based on a specified language. The method of claim 1, wherein the user specifies to generate, and wherein the machine readable data, mapping, and additional generating step proceed without requiring additional actions by the user. 2. The method of claim 1 wherein the database is a relational database. A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods for accessing and maintaining data through transaction processing support of the database manager; Additionally providing a version of the object-oriented framework that substantially conforms to a standards-based server-side component model and a remote method invocation protocol; Accepting transaction-related activity directed simultaneously to one or more databases through the standard conforming version of the object-oriented framework and the object-oriented framework. 14. The method of claim 13, wherein said standard is Enterprise JavaBeans (EJB). 14. The method of claim 13, wherein said standard is a distributed common object model (DCOM). The method of claim 13, wherein said standard is CORBA. 15. The transaction of claim 14, wherein the accepting step comprises buffering objects, and further comprising invoking the database manager to process the transaction during the committing of the transaction. Convocation method. 16. The method of claim 15, wherein the accepting step comprises buffering objects, and further comprising invoking the database manager to process the transaction during the committing of the transaction. 17. The method of claim 16, wherein the accepting step includes buffering objects, and further comprising invoking the database manager to process the transaction during the committing of the transaction. A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods for accessing and maintaining data through transaction processing support of the database manager; Additionally providing a version of the object-oriented framework adapted to EJB standard-matching handling and invocation; Accepting transaction-related activity directed simultaneously to one or more databases through the object-oriented framework and the EJB-standard compliant version of the object-oriented framework. 21. The method of claim 20, wherein said accepting step comprises buffering objects, and further comprising invoking said database manager to process said transaction while committing said transaction. . A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods for accessing and maintaining data through transaction processing support of the database manager; Additionally providing a version of the object-oriented framework adapted to DCOM specification-match handling and invocation; Accepting transaction-related activity directed simultaneously to one or more databases through the object-oriented framework and the DCOM specification-consistent version of the object-oriented framework. 23. The method of claim 22, wherein the accepting step comprises buffering objects, and during committing the transaction, calling the database manager to process the transaction. A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods for accessing and maintaining data through transaction processing support of the database manager; Additionally providing a version of the object-oriented framework adapted to CORBA-matching handling and invocation; Accepting transaction-related activity directed simultaneously to one or more databases via the object-oriented framework and a CORBA-consistent version of the object-oriented framework. 25. The method of claim 24, wherein the accepting step comprises buffering objects, and further comprising invoking the database manager to process the transaction while committing the transaction. . A method of maintaining data processed by at least one database manager, comprising: Providing an object-oriented framework of methods for accessing and maintaining data through the database manager; Providing EJB standard-matching interfaces to methods for accessing and maintaining data through the database manager; And Accommodating object access and persistence requests directed simultaneously to one or more databases via the object-oriented framework and the EJB-standard conforming interfaces. 27. The method of claim 26, wherein the object requests are provided to a Java transaction services engine, regardless of whether the requests are made through the object-oriented framework or the EJB standard-matching interfaces. 27. The method of claim 26, wherein the object-oriented framework without the EJB standard-matching interfaces is adapted to maintain micro-element objects, and the EJB standard-matching interfaces are adapted to maintaining objects in a transaction to one or more databases. Transaction convocation method, characterized in that. A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods to access and maintain data through transaction processing support of the database manager and to stage objects for addition and testing to a production system; And Additionally providing a version of the object-oriented framework that substantially conforms to the standards-based sub-side component model and the remote method invocation protocol, wherein the version includes staging of objects. How to call a transaction. 30. The method of claim 29, wherein said standard is Enterprise JavaBeans (EJB). 30. The method of claim 29, wherein said standard is a distributed common object model (DCOM). 30. The method of claim 29, wherein said standard is CORBA. A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods for accessing and maintaining through transaction processing support of the database manager and for tracking the history of changes in objects in a production system; Additionally providing a version of an object-oriented framework that substantially conforms to a standards-based sub-side component model and a remote method invocation protocol, the version comprising tracking the change history. Characterized by a transaction convocation method. 34. The method of claim 33, wherein said standard is Enterprise JavaBeans (EJB). 34. The method of claim 33, wherein said standard is a distributed common object model (DCOM). 34. The method of claim 33, wherein said standard is CORBA. A method of assembling transactions to be processed by at least one database manager that supports transaction processing, the method comprising: Providing an object-oriented framework of methods to access and maintain data through the database manager's transaction processing support and to dynamically arrange the fields in an object to generalize the fields; And Additionally providing a version of the object-oriented framework that substantially conforms to a standards-based server-side component model and a remote method invocation protocol, the version including a dynamic arrangement of the fields to generalize the fields. Transaction convocation method comprising the step of. 34. The method of claim 33, wherein said standard is Enterprise JavaBeans (EJB). 34. The method of claim 33, wherein said standard is a distributed common object model (DCOM). 34. The method of claim 33, wherein said standard is CORBA. A method for creating a database in a horizontally partitioned multi-tier business application. Modeling objects and relationships and specifying operations of object-oriented application design, the properties of the objects including whether to horizontally partition objects according to multiple databases; Generating machine readable data corresponding to the model, including the characteristics; Using the machine readable data, mapping the model to a plurality of databases; And Additionally generating application development code from the mapping and the machine readable data, including code to maintain and access the objects in accordance with the plurality of databases, wherein the code to maintain and access the objects is a database. And a middle program tier of a tier or more. 42. The method of claim 41, further comprising: declaring a plurality of databases into which the object is partitioned, and declaring one or more fields of the object used to partition the object into specific databases among the plurality of databases. Database generation method comprising the. In a multi-tier business application comprising at least a database tier and a middle business application tier, a method of performing horizontal partitioning of objects along multiple independent databases, comprising: Declaring one or more fields in at least one horizontally partitioned object that can be used to assign a particular object to a particular database; Making a connection with a plurality of databases to which the horizontally divided object can belong; Buffering one or more objects to retrieve or create, including the horizontally divided object; And During processing of the search or generation, analyzing the specific database to which the object belongs using the declared fields and calling the specific database in the database tier to perform the search or generation. How to perform horizontal division of objects. In a multi-tier business application comprising at least a database tier and a middle business application tier, a method of performing horizontal partitioning of objects along multiple independent databases, comprising: Making connections with a plurality of databases to which at least one horizontally divided object can belong; Setting a specific database to which the horizontally divided object belongs; Buffering one or more objects to retrieve or create, including before or after the setting step, including a fraud horizontally divided object; And In the course of processing the search or generation, calling a particular database in the database tier to perform the search or generation. 45. The method of claim 44, wherein the plurality of databases are collectively referred to by a single logical name, and particular databases among the plurality of databases are logically mapped to one or more additional attributes. Way. 46. The method of claim 45 wherein the additional attributes are fields of the horizontally segmented object.