JP2006504194A - 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 present invention relate to substantially adapting COF to a standards-based server-side component model and a remote method invocation protocol. An additional aspect of the present invention relates to horizontal partitioning of a database in an intermediate business application tier on the database tier. Combinations that include staging, change history, and internationalization of fields within objects are yet another aspect of the present invention. Particular aspects of the present invention are set out in the claims, text and accompanying drawings.

Description

  The present invention relates to application development using a common object framework (COF). More particularly, aspects of the invention relate to substantially adapting COF to a standards-based server-side component model and remote method invocation protocol. An additional aspect of the present invention relates to horizontal partitioning of a database in an intermediate business application tier on the database tier. Combinations that include staging, change history, and internationalization of fields within objects are yet another aspect of the present invention. Particular aspects of the present invention are set out in the claims, the following description and the accompanying drawings.

(About copyright)
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner does not challenge any person to reproduce the patent document or patent disclosure as it appears in the Patent and Trademark Office patent file or record, but reserves all other copyright rights. It shall be.

  Multi-tiered applications have become a common solution for deploying business logic in a distributed, reliable and scalable manner. In a multi-tiered system, the system service tier provides a database, transactions, and other infrastructure. Intermediate tiers give access to business logic. The client tier has access to business logic. The client tier may be a user with a poor or sophisticated client, or may be a program such as a web service client. Multi-tiered applications are particularly useful for supporting a large number of customers from a single application platform. Multi-tiered applications can be adapted to handle similarly formatted data for a large number of customers, with advantages including code reuse and expansion.

J2EE and Enterprise Java (R) Beans (EJB) have emerged as an architecture for encapsulating and servicing business logic, integrated with data management mechanisms in a multi-tiered environment. Application servers provide access to system services and infrastructure. The application server manages the storage and persistence of objects that encapsulate both business logic and data. See generally Sun, Simply Guided to the Java ^™ 2 Platform, Enterprise Edition (1999). Microsoft's competitive architecture is known as “.NET Framework and DCOM.”, Monson-Haefel, Richard, Enterprise JavaBeans 3d Ed, p17, O'Reilly (2001). An older framework with some similar characteristics is known as CORBA.

  The life cycle of a multi-tiered encapsulated business application includes both initial development and subsequent maintenance. (In this regard, business applications are used to include commercial and non-commercial applications that include one or more intermediate tiers where so-called business logic exists.) The initial development of multi-tiered encapsulated business applications is Beginning with a visual object-oriented analysis and modeling tool, progressing through an object-to-relational database mapping process, and deployed as a multi-tiered encapsulated business application. Maintenance may include staging and deployment of updated business application components. Deployment requires internationalization of dynamic data such as product names and descriptions (I18N: abbreviated as “i” and “n” and 18 characters between them).

  Tools used for early development include visual analysis and modeling tools that are compatible with the Unified Modeling Language (UML) and generate object-oriented models of applications and data that they use. Rational Rose is a leading visual analysis and modeling tool. Other products include IBM's VisualAge, Borland's EnterpriseStudio and NeuVis' NeuArchitect. For visual analysis and modeling, drafting tools such as Visio or Flowcharter may be used.

  An OR tool can also be used for development to map an object-oriented model to a relational database. TopLink was a leading tool for mapping object-oriented models to relational databases. Competing tools are manufactured by Sun Microsystems, IBM, Borland, Oracle, Microsoft, Sort Inc., and Chibuco. Modeling tools that include certain OR mapping capabilities are generally very constrained and are not well adapted to support a range of available databases.

  Application servers for multi-tiered encapsulated business applications may conform to the J2EE standard or similar standards. Application servers for J2EE and EJB 2.0 are Sun, JBoss. org, Borland, IBM, BEA Systems, Warp Solutions, Micromedia, Oracle, and many others. The application server may rely on various persistence databases, including those provided by Oracle, Microsoft, IBM, Sebel, Sybase, etc.

  Two disadvantages of available tools are the limited integration of features useful for maintenance and deployment, and the lack of support. Constrained integration means that an application developed with a visual analysis and modeling tool and mapped with an OR tool can be used by the user to meet one of the competing standards for multi-tiered encapsulated business application deployment. Means that you need to re-enter data or follow detailed programming guidelines. Features useful to help developers avoid having to do it manually using existing tools include staging, deployment history, and internationalization of dynamic data. Staging involves testing a new module against live data and deploying the tested module. Background refers to recording the deployment and optionally recording the staging and / or testing of a new module. Dynamic data internationalization supports the addition of additional fields and tables, and allows foreign language conversion of dynamic data by specifying the language or countries to be added to one or more base languages or countries. It is something to support.

  A desirable feature that is not apparent in the current system is that in the intermediate tier, data can be explored in a number of independent physical databases and databases built on different vendor platforms such as the Oracle database and SQL Server 2000. Partitioning the data horizontally. In the following, version “2000” is used as a reference, but does not imply any constraints on the version of software that can be used to implement aspects of the present invention. Existing horizontal partitioning mechanisms supplied by database vendors use multiple physical volumes within a single tightly managed system, all under the control of the vendor's database manager.

  For examples of horizontal partitioning techniques, see Crane's US Pat. No. 6,453,313, “Database Management System and Method for Dequeuing Rows Published to a Database Table” (1992); 112, 198, “Optimization of Data Repartitioning During Parallel Query Optimization” (2000); US Pat. No. 5,970,495 by Baru et al., “Method and Apparatus for Achieving Uniform Data Distribution in a Parallel Database System” (1999). As Klein explains, transparent (transparent) horizontal partitioning of large database tables is used to scale and distribute the computational load across nodes and devices in the cluster. Horizontal partitioning means that the table is divided or partitioned into two or more files, and each partition stores a record (tuple) with a corresponding range of key values. For example, each of the two or more partitions of the customer table may be used for records corresponding to customer names beginning with a corresponding range of letters A-L. The table can also be partitioned based on the hash value. For example, using the hash value of a recording index, it can have any of N (eg, 4) values, and the table can be divided into N partitions, using a hash function to The partition where the table row is stored is determined. Further, each partition may be stored on a different node or physical device of the system to facilitate the distribution of computational load in the system.

  Integrating horizontal partitioning into an intermediate tier rather than a database manager is useful for supporting multiple customers in the same application. Transparent (transparent) horizontal partitioning support frees developers from revisiting their business logic when more customers are added or the database is repartitioned .

  Thus, the deployment and maintenance of multi-tiered encapsulated business applications creates an opportunity to better support and integrate development at various stages from visual analysis and modeling.

  The present invention relates to application development using a common object framework (COF). More particularly, aspects of the invention relate to substantially adapting COF to a standards-based server-side component model and remote method invocation protocol. An additional aspect of the present invention relates to horizontal partitioning of a database in an intermediate business application tier on the database tier. Combinations that include staging, change history, and internationalization of fields within objects are yet another aspect of the present invention. Particular aspects of the present invention are set out in the claims, the following description and the accompanying drawings.

  Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. The preferred embodiments are illustrative of the invention and are not intended to limit its scope as defined in the claims. Those skilled in the art will appreciate various equivalent modifications from the following description.

  FIG. 1 illustrates the Sun sponsored J2EE and EJB standards that can be used in one embodiment of the present invention. See Bodoff et al., “The J2EE Tutorial”, page 10, Addison Wesley (2002). Sun describes the block of FIG. 1 as follows. The J2EE server 120 implements a J2EE product. The J2EE server provides the EJB 125 and Web 121 containers and manages access to the backend database layer 130. An Enterprise JavaBeans (EJB) container 125 manages the execution of enterprise beans for J2EE applications. The enterprise beans 126, 127 and their containers 125 are executed on the J2EE server 120. The web container 121 manages the execution of JSP page 123 and servlet 122 components for J2EE applications. Web components 122, 123 and their containers 121 are executed on the J2EE server 120. The application client container 113 manages the execution of the application client 112 component. Application clients 112 and their containers 113 are executed on the client 110. The applet container manages the execution of applets. This includes a web browser 111 running on the client 110 and one or more Java plug-ins.

  More generally, FIG. 1 illustrates a standards-based server-side component model and remote method invocation protocol. Microsoft “.NET Framework” and CORBA include similar components. Monson-Haefel, Enterprise JavaBeans, pp. 5-18. Aspects of the present invention are deemed to conform to the standard when conforming to the version indicated herein or at a later time or version of the standard as of the filing of this application or a derivative thereof. Even a substantial fit is useful without requiring a perfect fit. Although full conformance with the standard sometimes requires implementation of the features of the standard, this is unnecessary and is considered too expensive and fluid. In addition, certain implementations may include private features that may be introduced when improving the product and that may become non-standard when the standard evolves and the customer claims legacy support. It is considered to be. A standard means to cover both specifications managed by a committee such as EJB and specifications managed by a seller such as “.NET Framework”.

  FIG. 2 shows how the common object framework is implemented using the EJB on J2EE server to provide an intermediate tier. Many of the components in the figure correspond to those in FIG. 1 and are numbered accordingly. In FIG. 2, one of web container content and enterprise beans is described. In the web container 121, the application includes a common object framework (COF) 240 </ b> A, a role application 241, a web service engine 242, and a collaborative process manager 243. COF supports and provides access to persistent objects, reducing the need for role application 241 developers to handle persistence, transaction management, and related tasks. The COF may optionally support the staging, change history, internationalization and horizontal partitioning by applying the methods described in this application and the application taken as a reference. The web service engine 242 and collaborative process manager are components used by Commerce One to provide web services, and the details of these applications in the web container are not important to the present invention. However, the solid arrow connecting the collaborative process manager 243 to the COF 240A and the dotted line connecting the CPM 243 to the COF 240B and EJB 127 make the service and data support provided by the EJB container 124 available to the COF 240A in the web container 121. Indicates a replacement option. Displaying the COF code in the web container 121 and enterprise bean 126 as 240A, 240B in the same way wraps the COF code with an EJB conforming interface for EJB processing with little or no rewriting of the COF code. Tell what you can do. As shown, the COF can be utilized in either a web container or an EJB container. Applications can access COF components in both containers. An application can have an active session simultaneously with both sets of COF components. Although FIG. 2 illustrates this implementation for an EJB environment, it will be apparent to those skilled in the art that the same solution can be applied to other standard-based server-side component models such as DCOM and remote method invocation protocols. Let's go.

  The so-called common object framework provides basic implementations and tools for managing the entire software life cycle of business objects, which are described in detail in the applications discussed herein. It features design including transparent (transparent) internationalization, staging, change history, and custom attributes, UML model, full code and database generation. Tools are provided to continue to maintain code, data, and database independent 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 exceptions (internationalized), logging, encryption and configuration access. This also includes internationalization features such as resource managers, dates, numbers and text. Business Object Framework for business object design, code generation for persistence, internationalization, data staging, version history, dynamic custom attributes, and full build / read / update / delete (CRUD) functionality used. Included in the framework is business object extensibility, cache synchronization across multiple services, and scheduler support.

  System management tools are based on the business object framework. These include data management tools for creating databases, loading data, upgrading database schemas, and upgrading data breaking changes. There are also extractors and installers for internationalization and localization kits.

  The EJB-compliant or standards-compliant COF can be implemented and interacted with by various software components. Object model design and generation of code or metadata (machine readable data) can be implemented with more than "Rational Rose 2001a". Thereafter, the version “2001a” is also used as a reference only, and does not limit the version of software that can be used to implement aspects of the present invention. When using "rational rose", an add-in is installed to provide the functions shown in FIGS. 4 and 5 and described below. The database uses TopLink 3.6.1, SQL Server 2000, Oracle 8.1.7, or DB2, and a suitable JDBC driver, eg, I-net OPTA 4.15, Seropt or IDS JDBC DC Lite 3.5.4. , Map, shape, and access. EJBs such as WebSphere and WebLogic 7.0 may be used.

  New and improved models of EJB-compliant COF can be combined in a number of useful ways. These models generate remote and local EJB interfaces so that COF objects can be accessed and used as EJBs. They give access to EJB-QL as a query language to find objects using TopLink 4.0 as an OR mapping tool. They manage database server sessions, including supporting simultaneous access to multiple databases and horizontal partitioning of data. Relationships across databases cannot be supported. They provide a client session for application access to the object. They provide a configurable retry mechanism for lost database connections. They support EJB JTA-based transactions and integration with unique linked object IDs that are unique across database servers, store object IDs across database moves, and implement horizontal partitioning.

  Object change event notifications are generated as configurable events for object creation, update and deletion. Callbacks are provided for implemented objects for post-object creation, pre-object update, post-object refresh, and pre-object deletion. Design and code generation tools are provided for Rational Rose. A database creation tool generates a database or DDL script based on a visually modeled design. The tool generates an application server deployment descriptor for the generated EJB. Support for WebLogic 6.1sp2 and WebSphere 5.0 (requires support for the EJB 2.0 specification).

  FIG. 3 shows objects and relationships for a visually modeled simple shopping cart application. The model in this figure is formed using a unique modeling language (UML) representation for class diagrams. In this example, CmsCart object 301 is used to provide a number of exposed methods. Using CmsCart instead of a CmoCart object means that the object exists for a session but does not persist during subsequent sessions, as opposed to persistent customers and orders. The cart 301 is associated with the CmoOrder object 303 by the order 311. In this example, one order object is associated with the shopping cart. The CmoOrder object 303 must be associated with the customer 313 via the CmoCustomer object 302 upon completion. Along the reverse direction of the relationship, persistent customer 302 may be associated with more than one order 303 (312). Order 303 includes one or more CmoProductLineItem objects 305. Related item 314 connects order 303 to its line item 305. Line items 305 are filled with products 304, which are connected to the line items by a product 315 relationship.

  In UML, objects such as shopping carts may be modeled as classes. By default, all top level (ie non-parent class) persistent objects in one embodiment of the present invention inherit from a base object called CmoBase, as described below with respect to FIG. Alternatively, a transient object may be inherited from an object called CmsBase. The base object may be provided in a CAT (or unit) file, which can be loaded into an object modeling program and referenced by other classes. The purpose of the base class is to provide basic functionality for all objects through a common interface and implementation.

  Modeling a class in UML format with an object modeling program includes the following steps. First, a package hierarchy is formed to specify the directory structure where the class should exist and where it is generated. The class name, class documentation, and class properties can then be specified. Supported class properties include: That is, persistence, transient, abstraction, generated code, database table name, Is Stageable, Max Num of Versions, table level database constraints (such as compound unique constraints), is display Is Displayed in GUI (GUI), display name, display description, generation, and GenerateEJB. These use the tools shown in FIG. 4 and described below.

  The class attributes can then be specified. You can specify the attribute name, format, documentation, database column name, database column length, allowed null values, and whether the attribute is unique. Further, the attributes are static, final and / or transient. Attributes may be defined protected so that they can be accessed by subclasses and reflection codes. However, other classes and applications cannot access them without relying on getter and setter methods. The following attribute formats are supported: int, Boolean, float, long, short, double, char, String, Date, Time, Timestamp, Integrer, Boolean, Float, Long, Short, Double, BigIntegr, BigDecimal, BigDecimal EncryptedString, HashedString, and TranslatableString.

  These formats are appropriately mapped to Java-based formats, which may be mapped to database specific formats. Object, byte, and byte may be mapped to BLOB format in the database to store a stream of bytes. char and character may be mapped to CLOB format in the database to store large character streams. The EncryptedString and HashedString formats are special formats, just strings, but the generated code encrypts / hashes the value before setting the attribute and returns the value when the attribute is returned by the getter and setter methods Is decrypted. The TranslatableString attribute is also just a string, but the generated code also generates an additional table with a column to represent the converted value of that attribute. This allows a particular attribute of a class to be specified to indicate that there can be multiple transformation values for that attribute to support the localization of object values stored in the database.

  A class relationship can then be specified. In UML, a line with an arrow from one object to another is used to specify a relationship or association. Each side of this relationship is called a roll. The role name is equivalent to the attribute name in the class from the “from” side of the relationship. Roles must be of protected control (similar to attributes). Each role can specify many. “0..1”, “1” and “0 .. *” are supported. “0..1” specifies that 0 or 1 instances of the object on the roll side can be the relationship. Similarly, "1" specifies that exactly one instance of the object on the role side must be in the relationship (usually null for the column representing the class association on the "from" side of the relationship) Meaning other constraints). Also, “0 .. *” specifies that zero or more instances of the object can be related. This is equivalent to a relationship including a set of associated objects.

  The relationship may be bi-directional. This means that each side of the relationship is visible to the other side. Many permutations of the above may exist in a bi-directional relationship. Furthermore, one side of the relationship can be shown as a grand total (represented using open diamonds on the “from” side of the relationship). The aggregate relationship specifies that the “from” class privately owns the instance (s) of the “to” class. Therefore, it is the responsibility of the “from” class to create and delete instances of the “to” class.

  The object modeling program allows you to define additional properties that can be set for each individual package, class, attribute, relationship, and relationship role. A “CBOF” tab may be added to the properties for each type of object along with the object modeling program, as shown in FIG. This tab lists the specific properties that can be set for each type of object. A model that generates metadata corresponding to a visual model or machine-readable data can access any property of any object. Thus, by adding properties, additional properties of a class can be set to customize the subsequent generation of code and other support for that class.

  In particular, the “rational rose” object modeling program allows the addition of extensions that include additional property values for various objects. When object models are formed, a set of properties can be specified and / or set in these object models (with features such as classes, attributes, associations, etc.). A collection of properties can be extended and added for customization purposes. FIG. 4 shows a CBOF tab 401 added to a pop-up window for specifying class properties. A set or subset of properties may be selected for manipulation (402). As model properties, property name 411, value 412 and source 413 (labeled as default or override) all control the user's manipulation of the property. Properties with non-default values can be highlighted in bold, highlight or otherwise.

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

1. Project properties: A single object model is considered a “project”. It is therefore possible to set some global properties for the overall corresponding project object.
CopyrightNotice—Overrides the copyright notice to be output in the generated code.
ProjectName—Overrides the class name of the OR mapping project class that will be generated.
ProjectDescription—Sets a description that will be stored as a static variable in the generated OR mapping object class.

2. Class property: A class contains a single UML class object that is formed based on a class diagram. By clicking on a set of standard properties, you can add properties to a new tab called “Cmo” that includes:
Generate—set to “no” to avoid generating code for certain classes that exist only for documentation purposes.
GenerateEJB—set to “yes” to generate one or more EJB interfaces to the class.
Override the default table name for the TableName class. By default, the first 27 characters of the uppercase class name become the table name.
IsStageable—set to “false” to avoid generating staging capabilities for this particular class, as further described below.
MaxNumVersion—Sets the number of past changes and sets it greater than 0 to persist a particular class instance.
ReplaceClass--specifies the full path class name of an existing class that this class implementation replaces.
WrapperPackageName-specifies the package name in which the wrapper (ImplC) class is generated.

ImplPackageName-specifies the package name in which the persistent implementation and its primary wrapper (Impl and ImplW) classes are generated.
StageablePackageName-Specifies the name of the package in which the implementation (ImplS) capable of persistent staging is generated.
Constraint 1 to Constraint 7—specify table level constraints for the class. For example, “UNIQUE (name, OwingMember)”
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, the class name is generated by removing the “Cmo” prefix and then adding a space where the lowercase letter immediately follows the uppercase letter.
DisplayDescription—Sets the description to be displayed for this class.

3. Attribute properties: Attributes can be added to a specific class for the base format attributes described above. The attribute can have a new tab called “Cmo” with the following properties:
ColumnName-Overrides this attribute's default column name in the table for this attribute's class. By default, the first 30 characters of the uppercase attribute name and "-" for separating word boundaries are column names.
I18NConstraintName--overrides the default constraint name for the _IN table that is added for this column (if the attribute is set uniquely).

4). Association property: An association can be added between two specific classes. An association can include two sides called rolls. The association itself can have a new tab called “CBOF” with the following properties:
RelationTableName—If the relationship represents a many-to-many or unidirectional one-to-many relationship, an intermediate or “relationship” table may be added. Set this property to specify the relationship table name. By default, the relationship table name takes the class name on both sides of the relationship and attempts to use “TO” between them. If this name is too large (greater than 27 characters), the class name initial (the first character of the word boundary) followed by the class name string hash code is used.

5. Role property: A role represents one side of an association. The relevance has a roll side A and a roll side B. Thus, if a property is added to the role object, two additional tables can be added to the association properties, “CBOF A” and “CBOF B”, with the following properties:
ColumnName—Overrides this association default column name in the table for this association class. By default, the first 30 characters of the uppercase roll name and "-" separating the word boundaries are the column names.
GenerateForeignKeyConstraint—Set to “false” if a foreign key constraint should not be generated on this side of the association.
ForeKeyKeyConstraintName—Overrides the default foreign key constraint name on this side of the association.

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

  Further, as shown in FIG. 5, an operation can be designated and an operation property can be assigned. A CBOF add-in tab 501 is shown. At least two properties 521 can be accessed that indicate whether an EJB local interface and / or an EJB remote interface should be generated. For each property, a name 511, a value 512, and a source 513 are indicated. More generally, the local interface follows a first protocol with relatively low overhead adapted to calling and called objects residing in the same web container 121 or the same package. The remote interface follows a high overhead second protocol adapted for remote method calls. Remote method invocation protocols are CORBA, Java RMI, Microsoft Transaction Server, Microsoft COM / DCOM, Microsoft. Provided for specifications and products such as NET Framework and Enterprise JavaBeans (EJB). The choice of generating local and remote interfaces controls call overhead and / or interface exposure.

  FIG. 6 shows a CBOF model that can be adapted for EJB wrapping. Referring to FIG. 6, a block diagram of an object framework 610 according to one embodiment of the present invention is shown. In another embodiment, the object framework 610 can readily include various other components or configurations in addition to or instead of the components described in connection with the embodiment of FIG.

  Useful aspects of COF / CBOF implementation may include the following combinations: That is, the use of rational roses to model objects without any constraints on object model design. Code generation in placeholders or stubs for custom business logic methods. Generation of code that supports runtime creation, read, update, and delete (CRUD) of objects without the need for rational rose reversal engineering. Object-to-relational (OR) mapping with little or no user interaction beyond the user declaration of the mapping parameter. Generation of persistent mapping information that persists business objects to a relational database. Definition and formation of relational databases and constraints that contain the information necessary to form database schemas and tools that use information to create and / or move databases. A simple method of runtime creation, reading, updating and deleting (CRUD) that can be accessed via a set of standard APIs to easily create, read, update and delete business objects 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 last longer because the database is not affected until commit time and optimistic locking are used. Data staging that supports changes to business objects without affecting the live production version of the object until the change is tested, approved, and deployed. Data change history support, including an audit trail of basic object attribute changes. Generation of code and information to form a database schema that can be used for transparent storage and retrieval of translatable string attributes of business objects. Supports adding new attributes to objects dynamically at runtime without affecting the database schema. Support for object change notification, including options to configure business objects to have events that occur when objects are created, updated or deleted.

  These events are persisted to the database and can be managed by an event notification server. Also, the business object itself is first configured in memory (init ()), inserted into the database (postInsert ()), and added to the transaction for update (postAddForUpdate ()). Perform an action before being updated in a transaction to the database (preCommit ()), after being loaded / refreshed from the database (postRefresh ()), and finally before being deleted from the database (preDelete ()) You can implement a method to

  In the embodiment of FIG. 6, a group of five base classes is shown on the horizontal axis 614, preferably a base live object class CmoBaseImpl 630, a base interface class CmoBase 634, a base staging class CmoBaseImplS638, and a base internationalization. A class CmoBaseI18N642 and a base wrapper class CmoBaseImplW644 can be included. The functions and uses of these base classes are generally described in the patent applications cited herein for reference.

  In the embodiment of FIG. 6, a group of root classes is shown between the horizontal axis 614 and the horizontal axis 618, and may preferably include each root class inherited from the corresponding base class. In the embodiment of FIG. 6, the root classes are preferably the root live object class AbstractXImpl 646, the root interface class AbstractX650, the root staging class AbstractXImplS654, the root internationalization class AbstractXI18N658, the root wrapper class AbstractXImplC66 Can be included.

  In the embodiment of FIG. 6, a group of subclasses is shown below the horizontal axis 618 and may preferably include each subclass inherited from the corresponding base class and root class. In the embodiment of FIG. 6, these subclasses are preferably sublive object class XImpl670, subinterface class X674, substaging class XImplS678, subinternationalization class XI18N682, subwrapper class XImplW686, and subcustom class XImplC690. Including.

  Further, in FIG. 6, the series of interface classes described above is shown to the left of the vertical axis 622. A series of wrapper classes are shown between the vertical axis 622 and the vertical axis 626. Further, groups of classes that are persistently stored in the database 120 are shown to the right of the vertical axis 626. The interface is a public Java interface that is exposed to system users. These interfaces define get, set, add, remove and custom business logic methods. The interface also includes an API javadoc as a reference. Once these interfaces are generated, they must not be changed manually. This is because if you change it manually, you won't survive subsequent chord playback.

  In one embodiment, these classes interact with TopLink as a software component. Some of the description below is specific to TopLink, but it will be apparent to those skilled in the art that the same solution can be applied with other database mapping and management modules. A persistent class is an implementation class described to TOPLink as a class that includes a persistent attribute and mapping to a relational database. The three types of persistence classes include Impl, ImplS, and I18N. The Impl class represents an 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 the interface classes are implemented in these classes. Every business logic API throws in UnsupportedOperationException. The I18N class includes convertible string attributes and the location of the conversion. The Impl and ImplS classes have a one-to-many relationship with the I18N class. When the convertible string attribute get / set method is called, the appropriate instance of the I18N class is accessed based on the current position set for the thread. Once these classes are generated, they must not be changed manually.

  The wrapper class implements transaction support, staging, change history, and custom business logic functions. There are two types of wrapper classes, ImplW and ImplC. The ImplW class is an abstract class that implements only get / set / add / remove methods from the interface class. These methods appropriately check whether the value should be retrieved or set in the Impl object, the ImplS object, or their appropriate TOPLink transaction clone. The set / add / remove method throws CeNotInTransactionException when no instance is added for an update in a transaction. The get method throws CeRuntimeException with an “accessed wrapper invalid” message when an attempt is made to access a clone wrapper outside the transaction.

  The ImplC class is a concrete class that is instantiated when a persistent object is accessed or created. This class is inherited from the corresponding ImplW class. The ImplC class can be modified manually to include the implementation of custom business logic methods. The ImplW class is completely generated with each playback. The ImplC class is usually checked against source control as individual files that can be maintained once generated. Note the inheritance structure of the ImplW and ImplC classes. The ImplW class is inherited from its superclass ImplC. ImplC is inherited from the corresponding ImplW class. Note also that ImplW does not implement the business logic API declared in the interface class. These are implemented by the ImplC class. A class can be declared abstract in the model, which makes the ImplC class abstract.

  Note also that persistent classes and their associated TOPLink transaction clones have references to their corresponding wrappers. Persistent instances in the TOPLink cache point to read-only versions of those wrappers. A clone refers to a writable version of those wrappers. When the clone is committed and merged back into the TOPLink cached instance, the corresponding wrapper becomes invalid. The clone wrapper has a reference to its corresponding read-only wrapper, which can be obtained by calling the getReadOnlyObject () method in the wrapper.

  To describe this fileset, you need a base class hierarchy. FIG. 6 shows one embodiment of this base class hierarchy. At the top of the figure are five base classes, CmoBaseImpl 630, CmoBase 634, CmoBaseImplW644, CmoBaseImplS638, and CmoBaseI18N642.

  CmoBase 634 is an interface class in which all objects 332 are inherited and implemented. This interface contains a declaration of all base attributes and operations that all objects 332 must implement. Various features of the object framework 610 include attributes and methods that are added to the interface so that they can be applied across all objects. CmoBase 634 also serves as a method for marking objects 332 generated by the mechanisms provided in this framework. As shown in FIG. 7, another CmsBase class 702 may be provided as a transient object that does not require persistence.

  CmoBaseImplW644 represents a wrapper object that contains implementations for wrapping access to other enforcement objects (CmoBaseImpl, CmoBaseImplS, and CmoBaseI18N). The CmoBaseImplW class implements the CmoBase interface. The purpose of the CmoBaseImplW class is to determine which instance of Impl (for live objects) or ImplS (for staged objects) should be called to perform the operation. This class has four important relationships. liveObject holds an instance of a CmoBaseImpl object that represents the primary live business object in the database. The shadowObject holds an instance of a CmoBaseImplS object that represents a shadowed or staged version of the live business object in the database. The clonedObject holds a clone copy of the liveObject or shadowObject when the object is put into a create or update transaction. A liveClonedObject holds a clone copy of the liveObject when the clonedObject contains a clone copy of the shadowObject (this happens when the object is staged for update or formation in a transaction).

  LiveObject is given a read-only wrapper. The wrapper is made writable by adding a read-only wrapper to the transaction, which returns a new wrapper containing a clone of the liveObject that can be changed without affecting other users accessing the liveObject. When a transaction is committed, the clone is used to send updates to the database and to merge changes into the liveObject. Once the writable wrapper is committed, it is no longer useful and must access the read-only wrapper (this allows the writable wrapper to collect garbage to save memory). Instances of this class are those that are returned to the user when actions (create, read, access relationship and update) are taken.

  CmoBaseImpl 630 represents a live persistent object in the database. This class includes properties that control object-to-relationship mapping. Such information allows the formation of a schema that includes tables, columns, and constraints. This class includes attributes defined in the object model, including attributes that represent relationships (single relationships with that object type or multiple relationships that use a collection format). This class also implements the CmoBase interface 634. Getters and setters for attributes and relationships are implemented to access related attributes or relationships. Other business logic methods (declared in the model) throw in UnsupportedOperationException to prevent accidental access to the method. Only the ImplW class must access this class, and no business logic methods must be called in the Impl class.

  CmoBaseImplS 638 is essentially an exact copy of the CmoBaseImpl class, but represents the shadow or “staged” value of the Impl instance. These staged values are stored in a separate table and are separate instances, and thus a separate class representing what has been staged is provided and mapped to a separate table. The use of CmoBaseImplS638 is further explained in the patent application taken up as a reference.

  CmoBaseI18N642 is a base class used for internationalization support. This class holds the base attributes required for all tables that hold translatable string values. When an Impl class of an object is generated, an inner class inherited from CmoBaseI18N642 is also generated if the class has a convertible string attribute. An instance of CmoBaseI18N642 corresponds to language conversion of convertible string attributes of the Impl class. Additional instances are given for the staged values of the transformation. A list of transformations is maintained at each level of the class hierarchy. This allows to add / remove translatable string attributes at any time without the need for CmoBaseI18N class and table hierarchy. These features are explained in detail in the patent application taken up as a reference.

  When an object is generated (eg, AbstractX646), the generated class extends the appropriate base class. As shown in FIG. 6, AbstractX646 is an interface inherited from the CmoBase base interface. AbstractXImplW662 is inherited from CmoBaseImplW664. AbstractXImpl 646 is inherited from CmoBaseImpl 630. AbstractXImplS654 is inherited from CmoBaseImplS638. Furthermore, since there is a string attribute that can be converted in AbstractX, AbstractXI18N658 is inherited from CmoBaseI18N642.

  There is also another custom class called AbstractXImplC666 inherited from AbstractXImplW662. The ImplC class contains user-specific business logic code for business logic methods added to the interface in the model. The ImplC class does not include other interfaces or implementations that are code generated. This allows ImplC to be generated only once and is then updated only when business logic code needs to be added, changed or removed. Other class types (interface, ImplW, Impl, ImplS, I18N) are always played back from the object model 320 whenever the model changes. This eliminates the problem that the generated code requires manual custom changes that require reverse engineering to the model, yet allows writing business logic implementations that can change over time. The generated code can be used without requiring code to be written to ImplC. ImplC provides the location of user specific business logic methods to be implemented.

  In addition, FIG. 6 shows how another class called X can further extend the AbstractX class. Each generated class format X is inherited from the appropriate class format in AbstractX. However, XImplW686 is inherited from AbstractXImplC666, so an implementation of XImplC686 can override the business logic method of the AbstractX class as if it were a direct subclass. One aspect of the present invention is to automatically handle inheritance structures and code complexity and manage the relationships between these classes. Intuitively, the user only needs to work on the implementation of visually modeled objects and business logic code in ImplC.

  FIG. 7 is a class diagram illustrating aspects of classes CmoBase 701, CmsBase 702, and CmoAttribute 703 adapted to support EJB and J2EE. Persistent user-modifiable objects are inherited from CmoBase 701. However, many attributes are transient and not user-modifiable, so they can be assigned their static values to working copies of objects formed in memory. These transient attributes may be inherited from CmsBase 702 with properties and attributes adapted to the transient state. Persistent user-modifiable objects at the attribute level include, for example, name, description, maximum version number, and notifyAction. The CmoBase class 701 includes a primary key “id” that is automatically generated. The ID is unique to the row and format in the DB. Thus, a fully and universally unique ID concatenates database identifier, type and ID fields. This concatenated unique identifier satisfies the current EJB 2.0 requirement for a unique ID. The concatenated unique identifier is also useful for horizontal partitioning as described below. This is because the ID in CmoBase 701 is only guaranteed to be unique within the database and format. Additional attributes of CmoBase 701 include the illustrated state, versioning and staging attributes. As shown in FIG. 10 below, the classes CmoBaseLocal and CmoBaseRemote are configured to be inherited from or correspond to CmoBase. CmoAttribute 703 supports custom attributes for objects, as further described in the patent application we take as a reference.

  The adaptation of COF tools and models to EJB and J2EE support is shown in FIGS. Preferably, the business object interface in the system is Javax. ejb. It must be extended from EJBLocalObject 1013. This extended pattern provides access to invocation 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 has the same name as the local interface and is located under the “ejb” package. The remote interface is Javax. ejb. It extends EJObject 1012 and includes only methods that can be accessed remotely. In addition to the local and remote interfaces, the ejb specification requires a home interface for creating and finding ejb objects, as shown in FIG. Each business object is a Javax. ejb. A local home interface 912 extending EJBLocalHome 911; ejb. A remote home interface 902 that extends the EJB Home 901.

  A bean class containing code that implements business logic is usually named by providing the interface name with the suffix “ImplC”. For example, in FIG. 8, PersonImplC842 and EmployeeImplC862 are objects intended to include business logic corresponding to Person and Employee interfaces 821 and 841. Not all business methods in “ImplC” can be accessed remotely. A remote method with local method parameters and a return value set to “Serializable” can be implemented as needed to conform to EJB. To enable this, the framework generates a class with enough “beans” (eg, PersonBean) that can implement additional remote business methods. In addition to providing business logic enforcement, a number of EJB specific callbacks are implemented. These callbacks are called javax.xml in the CmoBaseImplW class (644 in FIG. 6). ejb. Provided for persistent objects by implementing the EntityBean interface 1011.

  Callbacks implemented to provide the EJB function are: ejbCreate (), ejbPostCreate (), ejbFindByPrimaryKey (PrimaryKeykey), ejbLoad (), ejbStore (), ejbStore (), ejbStore (), ejbStore (), ejbStore (), ejbStore () ) And unsetEntityContext (). Among these callbacks, the ejbCreate () method is called when the client calls the create () method in the home interface. The ejb container creates an instance of the bean (ImplC class) and calls the ejbCreate () method on the bean. An implementation must provide methods to get or form a CmoTransaction, add this bean to the transaction, initialize the wrapper object preAllocateObjectId, commit the transaction, and return the PrimaryKeyObject. This method needs to be overloaded in many cases to pass the non-null database constraint parameters needed to initialize the object.

  The ejbPostCreate () method is called by the container immediately after the ejbCreate () method call. This method must have the same number of arguments as ejbCreate (), provide additional initialization, and allocate the resources needed during its lifespan.

  The ejbFindByPrimaryKey (PrimaryKeykey) method is called when the client calls findByPrimaryKey () in the home interface. The implementation must indicate that no transaction is required, find a database object based on the object id (using the CmoClientSession.findById () method), and provide a method that returns a PrimaryKey object. This method needs to be overloaded for custom queries.

  The ejbLoad () callback method roughly corresponds to the “read” function of the entity bean. In one embodiment that implements aspects of the invention, the bean is typically initialized using a TOPLinkOR mapping during the create () or find () method, so that this method is used for certain post-processing operations. Can be used.

  The ejbStore () callback method roughly corresponds to the “update” function of the entity bean. This function is already encapsulated in the CmoTransaction of the present invention, except that the CmoTransaction needs to be started and an object is added to the transaction for update.

  The ejbRemove () callback method removes an object from the data store. CmoTransaction is started and an object for deletion is added.

  During the activation process, the ejbLoad () method is called after the ejbActivate () method on the bean instance is called. Once the bean is activated and its state is properly synchronized to its underlying database record, the business method proceeds. Subsequent calls to the business method are 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 serves to update the database. After updating the database, the container calls itself the ejbPassivate () method on the bean instance, giving itself an opportunity to release resources that were previously allocated before the bean was passivated.

  The setEntityContext (EntityContext ctx) method is called in the bean context during bean initialization. The context is saved for future use. unsetEntityContext () executes the context setting. If the container is determined to release the resources used by the bean, it can perform a pooled bean garbage collection, in which case a transition back to a non-existent state is performed. During this transition time, the container calls this method. This method deallocates resources used by this bean.

  FIG. 8 illustrates applying the EJB-compliant CBOF object model to simple objects for individuals (one and multiple) and employees (one and multiple), with both local and remote access and interfaces. The objects of individuals 821, 824 and employees 841, 834 are implemented from EJBLocalObject 811 and EJBOObject 814. Local object implementation supports local reduced overhead access. The EJBOObject implementation supports remote object access. Standard properties of local objects are inherited from CmoBase 812 as described above. Throughout FIG. 8, the suffixes ImplW and ImplC are used for wrappers and specific implementations. EntityBean 813 is implemented by CmoBaseImplW822. Object implementations for person 821 and employee 841 are inherited from CmoBaseImplW822. These implementations include PersonImplW832, PersonImplC842, EmployeeImplW852, and EmployeeImplC862. As described with reference to FIG. 9, two home objects EJBLLocalHome 853 and EJBHome 833 are provided for the local and remote interfaces. These home object implementations include PersonLocalHome 863, PersonHome 843, EmployeeLocalHome 864, and EmployeeHome 844.

  FIG. 9 is a generalization of a portion of FIG. 8 and shows what conforms to the EJB specification that requires a home for an object. Homes are provided for both remote and local objects and interfaces 901 and 911, respectively. Each business object is a Javax. ejb. A remote home interface 902 that extends the EJB Home 901; ejb. And a local home interface 912 that extends EJBLocalHome 911. The remote and local home interfaces 902, 912 are further extended by CmoApplicationConfigRemoteHome 903 and CmoApplicationConfigLocalHome 913.

  FIG. 10 is also a generalization of a portion of FIG. 8 and shows an additional mechanism for supporting EJB. Object javax. ejb. EJBOObject 1012 and javax. ejb. EJBLocalObject 1013 is expanded to CmoBaseRemote 1022 and CmoBaseLocal 1023.

  The EJB 2.0 specification supports relationships between EJB entities. All three basic relationship main elements (one-to-one, one-to-many, and many-to-many) are supported. Furthermore, these relationships can be navigated using a new query language of the EJB 2.0 specification. Relationships are managed through abstract accessor methods. In the case of a relationship with a large variety of associated objects, the abstract accessor parameter or return value format is a collection class that represents the relationship. This collection class is Java. util. Collection or Java. util. Implement the Set interface. Optionally, the specification is Java. util. Map and Java. util. List may be added as a return format. For a relationship where the diversity of the collection class is 1, the abstract accessor parameter or return value format is a single instance of the associated object.

  Relational accessors in COF have a parameter or return value format as an array of corresponding objects. In order to make them ejb accessible via the remote interface, additional methods for their relationship must be provided at the remote interface and implemented in ImplW. For example, the “employee-address relationship” is very numerous and bi-directional. For example, local and remote methods can be implemented that traverse relationships such as “employee-address relationship”.

  For example, a local method can include public Address [] getAddress (); public void setAddress (Address [] address); public voice addAddressElement (address), address (address), address (address), address (address) Remote method, public Collection getAddressRemote (); public void setAddressRemote (Collection address); public void addAddressElementRemote (Address address); and may include public boolean removeAddressElementRemote (Address address).

  The getAddressRemote () method supports obtaining a list of objectIds for all address objects associated with the employee object. Since no address objects need to be cached, the CmoQueryCursor mechanism can be used for this. Therefore, a new class called CmoObjectCursor extending from CmoQueryCursor is formed to support the remote cursor action of EJB instances. This method supports finding or creating corresponding ejb objects using a remote home interface and storing them in a collection. This returns a collection of ejb objects. The setAddressRemote (Collection address) method supports creating or finding a corresponding ejb object using the local home interface. This stores the object in an array. This calls the corresponding local method to be updated.

  Transaction support is an important infrastructure service offered by the J2EE platform. The specification defines the Java transaction API (JTA). JTA is an interface that gives access to the underlying transaction manager. Some of the major interfaces are Javax. transaction. UserTransaction and javax. transaction. Contains TransactionManager. The UserTransaction is exposed to the application component, while the basic interaction between the J2EE server and the JTA TransactionManager is transparent to the application component. The TransactionManager implementation supports (container-defined) transaction boundary server control. Both JTA UserTransaction and JDBC support are available for J2EE application components. The J2EE platform supports two transaction management paradynes: declarative transaction demarcation and programmatic transaction commit.

  In declarative definition, the container is responsible for starting, committing, and rolling back transactions. The container starts a transaction for each operation on the bean by the client. The client has the ability to obtain JTA transactions and perform multiple operations in one transaction. This gives the flexibility to implement some business logic that has dependencies between operations. The transaction attribute supports declarative transaction demarcation and is passed to the container the intended transaction behavior of the associated EJB component method.

  For container-managed transaction demarcation, six transaction attributes are supported: Required, RequestsNew, NotSupported, Supports, Mandatory, and Never. Methods with Required transaction attributes are executed within a JTA transaction, ie, a new transaction context is created or not based on the environment. If the calling component is already associated with a JTA transaction, the container invokes the method in the context of the transaction. If the transaction is not associated with the calling component, the container automatically creates a new transaction context and attempts to commit the transaction when the method is complete.

  A method with the RequestsNew transaction attribute is executed in the context of a new transaction. If the calling component is already associated with a transaction context, the transaction is put on hold, a new transaction context is formed, and the method is executed in the new transaction's context, after which the calling component Transaction resumes. A method with a NotSupported transaction attribute is not intended to be part of a transaction. If the calling component is already associated with a transaction context, the container holds the transaction, calls a method not associated with the transaction, and resumes the calling component's transaction when the method completes.

  Methods with the Supports transaction attribute support the calling component's transaction state. If the calling component does not have any transaction component, the container executes the method as if its transaction attribute was NotSupported. If the calling component is already associated with a transaction context, the container executes the method as if its transaction attribute was Required. A method having the Mandatory transaction attribute is called from the transaction context of the calling component. Otherwise, the container is Javax. transaction. Input TransactionRequiredException. Methods with the Never transaction attribute must not be called from the calling component's transaction context.

  Programmatic transaction demarcation is the hard coding of transaction management within application code. Programmatic transaction demarcation is an important option for session EJBs, servlets, and JSP components. A programmatic transaction may be either a JDBC or JTA transaction. For the container management session EJB, it is not recommended at all, but it is also possible to mix JDBC and JTA transactions.

  One aspect of the present invention is the ability to stage production data. To solve the problem of not replicating across databases, one embodiment stores the staged value of the data in the same database as the live production value. However, such staged values should not be in the same table as live production values. If the staged data is in the same table, the table performance and size are affected. Therefore, there may be two tables in the database for each object that requires staging capabilities. Since an additional table is required, the OR mapping tool requires another Java class to represent that table. There is an ImplS class corresponding to the Impl class that can be staged. Since class structure and OR mapping are handled automatically with table schema formation, the effort required to add additional tables and / or classes is substantially reduced.

  Copying the attributes of an existing object to a new object is generally easy. However, staging may support changing relationships between objects. A number of rules can be defined to support all the different staging features.

  1. A live production object instance has a reference to its staged instance. An object can only be staged once at a time (in other words, it has a one-to-one bidirectional private ownership relationship with its staged instance).

  2. Once an object is staged, its live instance cannot be changed. If the live instance can be changed, it will be necessary to merge the changes made in the staged value with the live value. This is unnecessarily complicated. Typically, changes need to be staged or changed directly in the live object, but not both.

  3. The relationship must be a live instance, not a staged instance. Otherwise, multiple relationship mappings must be managed (live vs. staging, live vs. live, staging vs. live, and staging vs. staging). Furthermore, when an object changes from staging to live or vice versa, the relationship pointing to it needs to manage the change. This rule simplifies these problems. In addition, the referenced live instance can be staged and has a reference to the staged instance, thus essentially supporting various relationships, though not directly. Can do.

  4). Staging changes must be part of the staging object. One way to manage a set of staging changes is to combine them into a container. Stageable objects keep track of all staged objects. This object can then be deployed, deployed for testing, or canceled.

  5). An object can only be staged once at a time and is only part of a single stageable object at a time. Again, management coalescence is generally not required.

  Supporting a one-to-one relationship is easier with rule # 3 in a staged table. All relationships refer to a live instance, so a column in a staged table that points to another object need only point to a live instance of that other table. One-to-many relationships must use an intermediate relationship table, even if the relationship is bidirectional. This prevents the live object table from having to know the relationship to the staged instance.

  Many-to-many relationships also have an intermediate relationship table that links staged instances to live instances. These intermediate relationship tables must be different from existing live object relationship tables. If the many-to-many relationship is bidirectional, it is necessary to form two intermediate relationship tables, one in each direction. This is because a relationship can be staged from each side of the relationship and can have different values. Additional relationship tables are generated automatically and effectively.

  Yet another aspect of the present invention is horizontal partitioning at an intermediate tier rather than a so-called back office database tier. FIG. 11 generally illustrates horizontal partitioning. In this example, the object model includes components 1 (1101) to n (1102), an account 1103, and a BI 1104. Component 1 is mapped to the main 1111 database, which is a single database. Component n is mapped to both main 1111 and main 1112 databases and is horizontally partitioned across the databases. The component n may be a single object or a group of objects. A facility that specifies a group of horizontally partitioned objects as a group is useful. Such a facility for setting project properties, as described above, will be familiar to users of Rational Rose. Alternatively, facilities can be provided for assigning objects to a group or groups and then setting group default properties or group width properties that are not overridden. In either embodiment, it is useful to have a group of objects that will (or will not) receive horizontal partitioning as a result of a single setting. In this example, components 1. . The mapping of n may be configured by a database declaration. Declarative solutions such as user completion tables or user readable (eg XML) configuration files are used to specify the logical front of the database and / or the logical name of the database to objects and groups of objects Can be connected to. In this example, the account and BI are mapped to the secure 1113 and BI 1114 databases, respectively.

  Classes that support horizontal partitioning in the middle tier are adapted to the interface to the database or database infrastructure, in this instance TopLink. FIG. 12 shows classes that can be used to implement horizontal partitioning in the middle tier. This figure is most easily understood starting from the upper left with CmoServerSession 1221. This object holds the database connection and information needed by the infrastructure. Since the logical identification of the database is static, this object can have static data and static methods and can be shared by many users.

  CmoSystemSession 1231 can be obtained from server session 1221. It is only necessary to create a single system session object for the server. The CmoClientSession object 1241 holds context and status information for each user of the server. This holds user specific information such as the user's location and login. State information similar to the state information maintained for the HTTP session is maintained. Methods getDb and setDb are used to set context information. A client session may include multiple databases. The relationship #dbClientSession between the client session 1241 and the active database session 1242 is 0. . * It is a relationship. When a client session is obtained, there is no active database client session. During the lifetime of a client session, many database client sessions can be active.

  The object CmoTransaction 1251 in this figure buffers the data to be partitioned horizontally. The role of this CmoTransaction is to maintain the state of a transaction including a long-lived transaction until the transaction is read and committed. When a transaction is assembled, information is collected that allows analysis of the database to which the new or changed object belongs. When a transaction is ready to commit, it can be committed in one or more databases by one or more instances of CmoDatabaseTransaction 1252.

  Horizontal partitioning support including intermediate column objects 1212, 1222, 1232, 1242, and 1252 can be added to the existing configuration of infrastructure interfaces 1223, 1243, and 1253 and exposed sessions 1221, 1241, and 1251 Moreover, it does not change the way sessions are exposed or the operational business logic in which they are exposed. For example, horizontal partitioning can be used to support two car manufacturers F and G using the same code and software. All data for F is, for example, partitioned into an Oracle database, and all data for G is partitioned into an SQL database. If the context F or G is set, for example, at a user login, data partitioning becomes transparent to the system. All calls to F data are made to the Oracle database, and all calls to G data are made to the SQL database. The same logic can be applied regardless of whether the data service is given to F or G.

  Code that implements business logic can also be shared. This is because only the context setting identifies or distinguishes F and G data. Partitioning at this level separates customer data. Smaller databases are handled more efficiently. The search by F does not find G data even at the back office database server level. Mixing in SQL, QL, or other database query codes cannot return data from more than one database, which reduces the chance that one customer can access another customer's data again. . This may be the case when plaintiffs and defendants' attorneys share certain components of the database but wish to keep their work outcomes strictly separated, or when competitors use the same value-added service and the service seller Is particularly useful in competing situations, such as ensuring both customers (competitors) have their data secure. Periodic maintenance functions can be achieved by a system administrator that repeats across multiple customer contexts while customer data is kept securely from other customers.

  Intermediate column objects 1212, 1222, 1232, 1242, and 1252 support access to multiple databases based on context, while multiple databases store horizontally partitioned instances of the same object. A CmoDatabaseServerSession object 1222 exists for each database active on the server. The database is logically identified to the CmoDatabaseServerSession object 1222 by a logical name that can be maintained as the key attribute dbName of the object.

  The getAllVersions method supports version management. This method can return an object version or schema version in the database. Code that accesses or allows access to the database must check that the version is not non-conforming. The ComClassConfiguration object 1212 connects the object to the database. One ComClassConfiguration object 1212 represents an object accessible in the database. The CuDatabaseConfig 1232 holds physical database configuration information corresponding to the logical database name. Using this information, multiple physical databases can be connected to a single logical name based on the context set. The CmoDatabaseServerSession 1222 is connected to the infrastructure object ServerSession 1223 by the #serverSession relationship. The ComDatabaseClientSession 1242 manages the client session together with the infrastructure object ClientSession 1243 in consideration of the client context (F or G in the above example).

  Returning to the operation of CmoTransaction 1251, when CmoTransaction is ready to commit the transaction, CmoTransaction calls CmoDatabaseTransaction 1252 with the appropriate context set. This CmoDatabaseTransaction 1252 is connected to an infrastructure object 1253, eg, TopLink UnitOfWork, to handle the one-stage or two-stage commit of the object.

  Two-phase commit is a transaction protocol that commits changes across multiple physical databases in atomic form. In one embodiment, software components that support two-phase commit include a JTS-based application server (any J2EE 1.3 compliant AppServer), distributed transaction support in a JDBC driver (eg, Opta2000 and Seropto), a database Distributed transaction support (eg, SQL Server and Oracle). COF and COF / EJB use TopLink to support transaction integration with JTS-based (Java Transaction Service) transaction managers (usually provided by the J2EE application server). The use of two-phase commit is optional. Two-phase commit is very expensive and is therefore only used when needed. User transactions that affect multiple objects and span multiple physical databases typically use two-phase commit transactions. A two-phase commit is appropriate when the EJB object and the COF object need to be committed in a single transaction. This protocol can be used with combinations of COF objects, horizontally partitioned objects, and EJB objects.

  Horizontal partitioning does not depend on whether COF or another protocol is used directly or encapsulated in EJB or another remote method call encapsulation. Intermediate tier encapsulation handles horizontal partitioning across independent databases without relying on the database manager. This is also referred to as loosely coupled horizontal partitioning because the independent database may be a non-conforming database from different database vendors.

  Again, relatively little business logic or system code needs to be changed to use horizontal partitioning. Some basic rules are listed below.

  1. If only one database is used in the configuration file (which means that the value of the property “database.projects” is single), this database is always used.

  2. If more than one database exists in the configuration file, the database information is analyzed explicitly or implicitly when performing the operation. Clear analysis means that “setDb (CuDataBaseConfig)” is called in the CmoClientSession object and / or CmoTransaction object. This CuDatabaseConfig object is usually created during system setup time. “CmoServerSession.getAvailableDbObjects ()” is used to obtain a list of database objects that can be used for the entire system. For a particular class, “CmoServerSession.getDbObjectsForClass (Class aClass)” and “CmoServerSession.getDbObjectsForClass (String aClassName)” is a CuData that contains a “Catab” that contains a “class” return. Implicit analysis means that the CmoClientSession and / or CmoTransaction object can be intelligently found as to which database will work without calling “setDb (CuDatabaseConfig)”, especially in the application code, as described below. .

  3. When the database information cannot be explicitly analyzed in the CmoClientSession and CmoTransaction objects, the session object attempts to analyze this by using all invoked objects. If any invoked object has some database information (not null), this information is compared with the database information associated with the session object. If the database information for the session object is null, it is set to the database information from the object, or an exception is thrown if the information is not the same. This logic continues for all called objects. To help identify database information for operations and / or transactions, COF has introduced a new interface “CmoDbConflictResolver”. The CmoDb ConflictResolver object is configured for one object. This is because the key is database. confresolver. {All object class names} = {All class names implementing the CmoDbConflictResolver interface}.

  4). The resolver (analyte) is called at the last possible moment. When it means that an object is created, it is not called until an object commit is attempted. This means that the resolver can expect that all attributes of an object have been set for formation and can use them to determine which database an object should belong to.

  In the case seen here, an expression or attribute query or attribute map query is passed so that the resolver can determine which database to query based on the attribute being queried. It is not possible to support queries across databases in a single query. Again, this is only needed if setDb has not yet been called in the clientSession and the object being queried is configured to exist in more than one database.

  A way that CmoDbConflictResolver can be implemented is to inform it of a mapping of an object attribute value to a particular physical database, using some configuration information, or perhaps some other dynamic data. This must be held as easily as possible. For example, the organization id of the object is used to determine which database, and possibly the database is named based on orgId and is a simple mapping. These database names are “logical” names that are determined at configuration / installation time to give the database a name and thus configuration information such as where it is located. Therefore, the name used here is a logical name that represents the name of the database configuration to be accessed, and does not represent the actual physical database name in the database system.

  In a client session, four functions can be used to control database information. They are setDb (CuDatabaseConfig), getDb (), overlapDb (CuDatabaseConfig), and restDb (). getDb () simply returns the current database set in the client session object, and overrideDb (CuDatabaseConfig aNewdb) and resetDb () use a stack mechanism to track changes in db info in the client session. OverrideDb (CuDatabaseConfig aNewdb) pushes the current db onto the stack and sets the current db to the passed “aNewDb”. resetDb () sets the current db to the top element of the stack if the stack is not empty, otherwise silently does nothing. setDb (CuDatabaseConfig aNewDb2) currently sets db to “aNewDb2” and clears the stack. Therefore, if setDb () is called when the stack has any information, the stack is simply cleared. The system client session object, which is a special client session, uses these four functions on a thread basis. Thus, the database information for one thread has nothing to do with another thread.

  The overrideDb (CuDatabaseConfig aDbConfig) and resetDb () functions cannot be called in CmoTransaction, but are subclasses of CmoClientSession.

  CmoDbConflictResolver API is, public CuDatabaseConfigresovleCreate (CmoDbResolverInfo aDbResolverInfo) throwsCeDbNameConflictResolveException; including public CuDatabaseConfigresovleFind (CmoDbResolverInfo aDbResolverInfo) throwsCeDbNameConflictResolveException. CmoDbResolverInfo API is, public CmoClientSession getClientSession (); public Class getMainClass (); public HashMap getAttValuePairs (); including and public CmoSase getNewlyCreatedObject (); public CmoFindObject getFindObject ().

  Once a class that implements the CmoDbConfirmResolver interface is developed, getNewCreateObject () in CmoDbResolverInfo can be used to help implement resolveCreate (CmoDbResolverInfo), and similarly, Useful in the implementation of resolveFind (CmoDbResolverInfo).

  In view of the foregoing description it will be evident to a person skilled in the art that a wide variety of systems and methods may be constructed from the aspects and elements of the invention. One embodiment of the invention includes a method for generating application development code. Alternatively, the method may be implemented as a system or apparatus that performs the steps of the method. The system or apparatus may encompass numerous embodiments, including method steps, aspects, options, and alternative examples. The method may also be implemented as a magnetic medium imprinted with a program that performs the steps of the method. The program may include a number of embodiments that combine the method steps, aspects, options, and alternative examples. Development code generation is particularly applicable to multi-tiered encapsulated business application environments. This method is based on an object-oriented application design object, relationship and operation model. The modeling of these objects, relationships and operations may be performed visually using graphic tools. Properties assigned to objects, relationships and / or operations may include a first property that indicates whether an interface to the modeled object should be generated. This may include a second property that indicates whether to generate a local and / or remote interface to the specified operation. From this model, machine readable data corresponding to the model and its properties is generated. This data may be implemented in an internal model or an exported model. This model may be readable only by a machine, or it may be human readable. Machine readable data is used to map the model to a database.

  In one embodiment, the database is a relational database. Application development code is generated using the mapping and machine readable data. The generated application code can include code for persisting and accessing objects in the database. This can further include an interface to the code for persisting and accessing the object, consistent with the first property. This may further include an interface to the specified operation that is consistent with the second property. The interface to the code and specified operations can be substantially adapted to a standards-based server-side component model and remote method invocation protocol. Alternatively, the application development code may be substantially compatible with Enterprise JavaBean (EJB) standard 2.0 or later. The code for persisting and accessing the EJB object may be substantially compatible with the “Bean Managed Persistence (BMP)” protocol. Alternatively, the application development code may substantially conform to the Microsoft DCOM specification. In another aspect of the invention, object-oriented application design may substantially conform to the “Unified Modeling Language (UML)” standard.

  One aspect of the application development code method includes a stub generation method to which custom business logic is to be added. In the implementation of this aspect of the invention, the code that is played when the object-oriented model of the system is changed is separated from the code that includes custom business logic, and is overwritten or changed when the object-oriented model is changed. Must not be regenerated.

  Another aspect of the present invention further includes a plurality of third properties of objects and relationships, which control the mapping step. These properties are used to map objects and relationships to a basic database such as a relational database. These third properties may include whether to support staging of deployment of modeled objects. They may include whether to record the change history of the deployment of the modeled object. In addition, one or more fields may be dynamically arranged within the modeled object to include whether these fields should be internationalized. In connection with aspects of the invention involving dynamically arranging fields, the code for persisting and accessing the modeled object retrieves which element of the dynamic array based on the specified language. You can analyze what to do. This language may be implicitly specified by data present in the object being handled, or may be explicitly specified by language.

  Yet another aspect of the present invention is that the user can specify what application code is generated, and the method steps for generating, mapping and additionally generating machine readable data require further action by the user. It is to be advanced without.

  Yet another embodiment of the invention resides in a method for assembling a transaction to be processed by at least one database manager that supports transaction processing. Alternatively, the method may be implemented as a system or apparatus that performs the steps of the method. The system or apparatus may encompass numerous embodiments, including method steps, aspects, options, and alternative examples. The method may also be implemented as a magnetic medium imprinted with a program that performs the steps of the method. The method may include providing an object-oriented framework of methods to access and persist data with database manager transaction processing support. It also includes providing a version of the object-oriented framework that is substantially compatible with the standards-based server-side component model and remote invocation protocol. Standards-based server-side component models and remote invocation protocols include, for example, Enterprise JavaBeans (EJB), Distributed Common Object Model (DCOM), and COBRA.

  The method of assembling a transaction may further include accepting or buffering transaction related activities directed to one or more databases. This accepting or buffering can be done simultaneously by the object oriented framework and the conforming version of the object oriented framework. One aspect of this embodiment includes the accepting step buffering the object, and upon command to commit the transaction, the method further includes calling the database manager to process the transaction. This aspect includes accepting transaction related activities by mechanisms other than the database manager. This aspect of the invention may be implemented in any of the standards described above, including EJB, DCOM and COBRA.

  An additional embodiment of the invention resides in a method for assembling a transaction to be processed by at least one database manager that supports transaction processing. As described above, the method may be implemented as a method, apparatus, or magnetic medium that includes a program that implements the method. Another method of this embodiment is a strict variation on the assembly method described above. One variation involves providing an object-oriented framework of how to access and persist data with the database manager's transaction processing support. The method further includes providing a version of the object-oriented framework adapted for EJB standard application handling and invocation. It further includes simultaneously accepting transaction-related activities directed to one or more databases by an object oriented framework and an EJB standard compliant version of the object oriented framework. In the other two variants of this embodiment, the object-oriented framework is adapted to the DCOM specification or COBRA. In any of these variations, the accepting staff may include calling the database manager to process the transaction upon a command to buffer the object and commit the transaction.

  Another embodiment resides in a method for persisting data processed by at least one database manager. As described above, this method may also be implemented as a method, apparatus, or magnetic medium that includes a program that implements it. This method of persisting data includes providing an object oriented framework of methods for accessing and persisting data by a database manager. It also includes providing a conformant interface to methods that access and persist data by the database manager. These standard conforming interfaces may be conforming to EJB, DCOM or COBRA. The method further includes accepting object access and persistence requests directed to one or more databases simultaneously via an object-oriented framework and a standards-compliant interface. When the standard is EJB, object requests may be submitted to the Java transaction service engine by both an object-oriented framework and an EJB standard conforming interface.

  An aspect of the invention that can be applied to any of the above embodiments is that an object-oriented framework is adapted to persist fine-grained objects to a database. Conformance interfaces, including EJB conformance interfaces, are adapted to persist objects in transactions to more than one database.

  Yet another embodiment of the invention resides in a method for assembling a transaction to be processed by at least one database manager that supports transaction processing. As described above, this method may also be implemented as a method, apparatus, or magnetic medium that includes a program that implements it. The method includes providing an object-oriented framework of methods that access and persist data as well as perform additional functions with data manager transaction processing support. This additional functionality may be staging objects for addition and testing to production systems. Further, the change history of the object in the production system may be tracked. Alternatively, the fields may be internationalized by dynamically arranging the fields within the object. These additional functions may be combined as a pair or as a whole. The method of assembling a transaction further includes providing an additional version of an object-oriented framework that is substantially compatible with a standards-based server-side component model and a remote method invocation protocol, which version is Also includes one or more of the typical functions. Another embodiment includes each of the additional functions individually, includes a combination of additional function pairs, and includes all three additional functions. The standard to which this method of assembling a transaction conforms may be EJB, DCOM or COBRA.

  A different embodiment of the invention resides in a method of generating a database and a horizontally partitioned multi-tier business application. As described above, this method may also be implemented as a method, apparatus, or magnetic medium that includes a program that implements it. The method includes modeling objects and relationships and specifying object-oriented application design operations, where object properties include whether the object should be partitioned horizontally across multiple databases. This solution may be applied to either an object or a group of objects. A group of objects may be represented by a single logical name. The method further includes generating machine readable data corresponding to the model, including properties. This machine-readable data may be readable only by a machine, or may be readable by a human as in the case of the XML specification. The method further includes mapping the model to a plurality of databases using machine readable data and additionally generating application development code from the mapping and machine readable data. Application development code includes code for persisting and accessing objects across multiple databases. The code for persisting and accessing objects is part of an intermediate program tier above the database tier. Yet another aspect of the present invention is that code for persisting and accessing objects can call multiple independent databases. These independent databases may be supplied by different database sellers, or may be supplied by a single database seller and operate independently. Yet another aspect of this embodiment is that one or more fields are used to declare a plurality of databases where the object is partitioned and to partition the object or group of objects into a particular database. It may include declaring.

  Yet another embodiment of the invention resides in a method for implementing horizontal partitioning of objects across multiple independent databases in a multi-tier business application including at least a database tier and an intermediate business application tier. As described above, this method may also be implemented as a method, apparatus, or magnetic medium that includes a program that implements it. 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. Also, it is not necessary to establish connections with all databases to which the horizontally partitioned objects belong, but includes establishing connections with multiple databases to which the horizontally partitioned objects belong. Before or after establishing a connection, the method includes searching, forming, or buffering for searching or forming one or more objects, including horizontally partitioned objects. In order to proceed with the search or formation, analyze the specific database to which the object belongs using the declared fields and call the specific database at the database tier to perform the search or formation Including. A similar embodiment is a method for performing horizontal partitioning of objects across multiple independent databases, comprising establishing connections with multiple databases to which at least one horizontally partitioned object belongs. It is in. It also includes setting or identifying the particular database to which the horizontally partitioned objects belong. Before or after this setting step includes searching, forming, or buffering for searching or forming one or more objects, including horizontally partitioned objects. Invoking a specific database at the database tier and performing a search or formation upon command to proceed with the search or formation. Multiple databases to which horizontally partitioned objects belong can be collectively referred to by a single logical name. One or more attributes of horizontally partitioned objects are used to logically map a particular database among multiple databases. These attributes may be fields of the horizontal partition object.

  Although the present invention has been disclosed with reference to the preferred embodiments and examples described above, this is merely illustrative of the invention and is not limiting in any way. In the above embodiment, a computer-assisted process is implied. Accordingly, the present invention provides a method for computer-aided processing, a system including logic that implements the method, a medium that is imprinted with logic that implements the method, a data stream that is imprinted with logic that implements the method, Alternatively, it may be implemented in a computer accessible processing service. Numerous modifications and combinations will become apparent to those skilled in the art without departing from the spirit and scope of the invention as defined in the claims.

FIG. 6 is a high level block diagram of a multi-tiered application. FIG. 6 illustrates how a common object framework is implemented using an EJB on J2EE server to provide an intermediate tier. FIG. 3 illustrates objects and relationships for a visually modeled simple shopping cart application. It is a figure which shows the CBOF tab 401 added to the popup window for designating a class property. It is a figure which shows the CBOF tab 401 added to the popup window for designating an operation property. It is a figure which shows the CBOF model which can be adapted to EJB wrapping. FIG. 6 is a class diagram illustrating aspects of classes CmoBase 701, CmsBase 702, and CmoAttribute 703 adapted to support EJB and J2EE. FIG. 4 illustrates the adaptation of COF tools and models to EJB and J2EE support. FIG. 4 illustrates the adaptation of COF tools and models to EJB and J2EE support. FIG. 4 illustrates the adaptation of COF tools and models to EJB and J2EE support. FIG. 3 is a diagram generally illustrating horizontal partitioning. FIG. 6 illustrates classes that can be used to implement horizontal partitioning at an intermediate tier in a TopLink environment.

Claims (46)

In a method of generating application development code for a multi-tiered encapsulated business application,
(1) visually modeling objects and relationships and specifying object-oriented application design operations, wherein the properties of the objects, relationships and / or operations are:
(a) a first property indicating whether an interface to the modeled object should be generated; and
(b) including a second property that indicates whether to generate a local and / or remote interface to the specified operation;
(2) generating machine-readable data corresponding to the visual model, including the properties;
(3) mapping the visual model to a database using the machine readable data;
(4) additionally generating application development code from the mapping and machine readable data, the code comprising:
(a) code for persisting and accessing the modeled object in the database;
(b) an interface to the code for persisting and accessing the object consistent with the first property; and
(c) including an interface to the specified operation that is consistent with the second property;
With a method.   The method of claim 1, wherein the application development code substantially conforms to Enterprise Java (R) Beans (EJB) standard 2.0 or later.   The method of claim 2, wherein the code for persisting and accessing the object is substantially compatible with a “Bean Managed Persistence (BMP)” protocol.   The method of claim 1, wherein the application development code substantially conforms to a “.NET Framework” specification.   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 include a plurality of third properties of the objects and relationships that control the mapping step.   The method of claim 6, wherein the third property that controls the mapping step includes whether to support staging of deployment of the modeled object.   The method of claim 7, wherein the third property controlling the mapping step further includes whether to record a change history of the deployment of the modeled object.   The object properties further include one or more fourth properties that indicate whether one or more fields should be dynamically arranged within the modeled object to internationalize fields. The method described in 1.   The method of claim 9, wherein the code for persisting and accessing the object analyzes which element of the dynamic array is to be searched based on a specified language.   The user specifies what to generate and the steps of generating, mapping and additionally generating the machine readable data are performed without requiring further action by the user. The method described in 1.   The method of claim 1, wherein the database is a relational database. In a method of assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods to access and persist data with transaction processing support of the database manager;
Additionally providing a version of an object-oriented framework that substantially conforms to a standards-based server-side component model and a remote method invocation protocol;
Accepting transaction-related activities directed simultaneously to one or more databases by the object-oriented framework and a conforming version of the object-oriented framework;
With a method.   The method of claim 13, wherein the standard is Enterprise JavaBeans (EJB).   The method of claim 13, wherein the standard is “Distributed Common Object Model (DCOM)”.   The method of claim 13, wherein the standard is CORBA.   The method of claim 14, wherein the accepting step includes buffering the object and further includes invoking a database manager to process the transaction upon a command to commit the transaction.   The method of claim 15, wherein the accepting step includes buffering the object, and further includes invoking a database manager for processing the transaction upon a command to commit the transaction.   The method of claim 16, wherein the accepting step includes buffering the object, and further includes invoking a database manager for processing the transaction upon a command to commit the transaction. In a method for assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods to access and persist data with transaction processing support of the database manager;
Additionally providing a version of an object-oriented framework adapted to handling and invoking EJB standards;
Accepting transaction-related activities directed simultaneously to one or more databases by the object-oriented framework and an EJB-compliant version of the object-oriented framework;
With a method.   21. The method of claim 20, wherein the accepting step includes buffering the object, and further includes invoking a database manager for processing the transaction upon a command to commit the transaction. In a method of assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods to access and persist data with transaction processing support of the database manager;
Additionally providing a version of an object-oriented framework adapted to DCOM specification conformance handling and invocation;
Accepting transaction-related activities directed simultaneously to one or more databases by the object-oriented framework and a DCOM-compliant version of the object-oriented framework;
With a method.   23. The method of claim 22, wherein the accepting step includes buffering the object and further includes invoking a database manager for processing the transaction upon a command to commit the transaction. In a method for assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods to access and persist data with transaction processing support of the database manager;
Additionally providing an object-oriented framework version adapted for CORBA conformance handling and invocation;
Accepting transaction-related activities directed simultaneously to one or more databases by the object-oriented framework and a CORBA-compliant version of the object-oriented framework;
With a method.   25. The method of claim 24, wherein the accepting step includes buffering the object, and further includes invoking a database manager for processing the transaction upon a command to commit the transaction. In a method of persisting data processed by at least one database manager,
Providing an object-oriented framework of methods for accessing and persisting data by the database manager;
Providing an EJB standard compliant interface to the method for accessing and persisting data by the database manager;
Accepting object access and persistence requests directed simultaneously to one or more databases by the object oriented framework and the EJB standard compliant interface;
With a method.   27. The method of claim 26, wherein the object requests are submitted to a Java transaction service engine regardless of whether they are made via an object-oriented framework or via an EJB standard compliant interface.   The object-oriented framework is adapted to persist fine-grained objects without the EJB-compliant interface, and the EJB-compliant interface is adapted to persist fine-grained objects; 27. The method of claim 26, wherein the EJB standard conforming interface is adapted to persist an object in a transaction to two or more databases. In a method for assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods for accessing and persisting data with the database manager's transaction processing support and also staging objects for addition to a test and manufacturing system;
Providing an additional version of an object-oriented framework that substantially conforms to a standards-based server-side component model and a remote method invocation protocol, including staging of objects;
With a method.   30. The method of claim 29, wherein the standard is Enterprise JavaBeans (EJB).   30. The method of claim 29, wherein the standard is "Distributed Common Object Model (DCOM)".   30. The method of claim 29, wherein the standard is CORBA. In a method for assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods for accessing and persisting data with the database manager's transaction processing support and also tracking object modification history in the manufacturing system;
Providing an additional version of an object-oriented framework that substantially conforms to a standards-based server-side component model and a remote method invocation protocol, including tracking the change history;
With a method.   34. The method of claim 33, wherein the standard is Enterprise JavaBeans (EJB).   34. The method of claim 33, wherein the standard is "Distributed Common Object Model (DCOM)".   34. The method of claim 33, wherein the standard is CORBA. In a method for assembling a transaction to be processed by at least one database manager that supports transaction processing,
Providing an object-oriented framework of methods for accessing and persisting data through the database manager's transaction processing support and also dynamically arranging the fields in the object to internationalize the fields;
A version of an object-oriented framework that substantially conforms to the standards-based server-side component model and remote method invocation protocol, including a version that dynamically arranges fields to internationalize them The steps provided in
With a method.   34. The method of claim 33, wherein the standard is Enterprise JavaBeans (EJB).   34. The method of claim 33, wherein the standard is "Distributed Common Object Model (DCOM)".   34. The method of claim 33, wherein the standard is CORBA. In a method of generating a database within a multi-tiered business application that is horizontally partitioned,
Modeling objects and relationships and specifying object-oriented application design operations, wherein the object properties include whether the object should be partitioned horizontally across multiple databases;
Generating machine readable data corresponding to the model, including the properties;
Mapping the model to a plurality of databases using the machine-readable data;
Additionally generating application development code from the mapping and machine readable data, the code including code for persisting and accessing the object across the plurality of databases; The code for persisting and accessing the object is an intermediate program tier above the database tier;
With a method.   Declares a plurality of databases that partition the object and declares one or more fields of the object used to partition the object into a particular database between the plurality of databases 42. The method of claim 41, further comprising a step. In a method for performing horizontal partitioning of objects across multiple independent databases in a multi-tiered business application including at least a database tier and an intermediate business application tier,
Declaring one or more fields in at least one horizontally partitioned object that can be used to designate a particular object to a particular database;
Establishing connections with a plurality of databases to which the horizontally partitioned objects can belong;
Buffering one or more objects to be explored or formed, including the horizontally partitioned objects;
Upon command to proceed with the search or formation, the specific database to which the object belongs is analyzed using the declared field and the specific database is called at the database tier to search for or form A step of performing
With a method. In a method for performing horizontal partitioning of objects across multiple independent databases in a multi-tiered business application including at least a database tier and an intermediate business application tier,
Establishing connections with a plurality of databases to which at least one of the horizontally partitioned objects can belong;
Setting a specific database to which the horizontally partitioned object belongs;
Buffering one or more objects to be explored or formed, including the horizontally partitioned objects, before or after the setting step;
Invoking the specific database at the database tier and instructing the search or formation to execute the search or formation;
With a method.   45. The plurality of databases are collectively referenced by a single logical name, and further, a particular database between the plurality of databases is logically mapped to one or more additional attributes. The method described in 1.   46. The method of claim 45, wherein the additional attribute is a field of the horizontally partitioned object.

Images