Electrical computers and digital processing systems: interprogra – Interprogram communication using message – Object oriented message
Reexamination Certificate
1999-04-01
2004-06-01
Courtenay, III, St. John (Department: 2126)
Electrical computers and digital processing systems: interprogra
Interprogram communication using message
Object oriented message
Reexamination Certificate
active
06745388
ABSTRACT:
BACKGROUND THE INVENTION
The present invention relates generally to computing systems, and more particularly to a method and apparatus for providing collaboration between applications operating in an information system.
Corporations have spent billions of dollars a year to implement custom, standalone information systems that address specific business domain functionality requirements such as accounting, payroll, manufacturing, and distribution. By creating these separate, standalone systems, each individual section of the business process became isolated from the others.
Over time, Corporate Information Technology (CIT) departments began shifting away from in-house development of these custom systems and have attempted to minimize costs by purchasing enterprise applications on the outside. Enterprise applications are more generic, providing general business functionality in a pre-packaged product. Typically, enterprise applications include heterogeneous combinations of application systems, hardware platforms, operating systems, third- and fourth-generation languages, databases, network protocols, and management tools. While these applications bring tremendous benefits to the companies that implement them, on an enterprise level, they only exacerbate the proliferation of “process islands” because they are not readily integratable.
Stand-alone enterprise applications provide powerful tools for handling many business processes. However, some functionality is often duplicated in separate applications, driving up the cost when bundling enterprise applications. Custom functional integration between enterprise applications, while desirable, is generally cost prohibitive, and defeats the benefits of the make-versus-buy decision to purchase the enterprise application in the first place. Tool and middleware vendors offer solutions for data integration, but not function integration, and even those solutions require significant custom coding to implement.
A collaboration system is described in commonly owned U.S. Pat. No. 5,913,061 entitled “Modular Application Collaboration” to Prashant Gupta et. al., filed Jan. 8, 1997, the contents of which are expressly incorporated herein by reference. Therein a modular application collaborator was described for providing inter-operability between applications. The collaborator included two or more connectors for communicating with applications and an interchange server. The interchange server was a non-distributed single server and provided an object-oriented, multi-user transactional execution environment for execution of collaborations. The interchange server included an application collaboration module and service module. The service module transferred messages between connectors and the application collaboration module. The application collaboration defined the inter-operability between two or more applications.
The collaboration system included a simple object model. A single, generic format for each business object in the system was provided. Each application connector included an application specific version of that business object. The application collaboration only deals with the generic forms of the objects. This results in an n-1-n conversion scenario for any object type.
The primary shortcoming of this model is the large and monolithic character of the generic object. Having a single generic object requires a great deal of cross-application analysis in order to extract the “best practice” combination of attributes, and is close to impossible in some cases. In addition, the collaborations/business objects, were not inheritable/extensible. The lack of inheritance makes it difficult to design business objects that are specific to subject areas and yet share several common attributes.
In addition, the interchange server was not completely componentized. This limited the ability to plug and play third party components into the server, and also limited the availability to take advantage of third-party services usable by well componentized systems.
The proposed object transformation scheme relied on a third party tool that provided inadequate programmatic interfaces, causing inconsistency between the specification of a business object and the specification that the tool used, inadequate diagnostic support during execution, and poor performance.
The communication between the connectors and interchange server always used ‘store and forward’ message queues, even when ‘store and forward’ facilities were not needed. This also limited data throughput. A proper versioning mechanism that allows a way to specify version dependencies between components and a way to manage the dependencies was not provided by the existing system.
As described above, the basic object model proposed was a simple one designed to create generic business objects. However, difficulties arise when implementing a generic object. Turning to a particular example, let us examine a generic customer business object. Some Customer Interaction Management (CIM) or Enterprise Resource Planning (ERP) applications define customer objects and store a customer's address data as dependent records of the customer object. In other words, the addresses do not exist independently of the customer data and can be accessed only through their parent customer object. These addresses are not used by more than one customer object (“SoldTo” customer). Examples of applications that store information in this way are applications produced by Baan, Oracle, Vantive, and Trilogy.
Alternatively, some CIM and ERP applications store customer data in a hierarchy of independent objects. The customer role at the top of the hierarchy represents the customer with whom an order can be placed. This “SoldTo” customer links to other customer objects through roles. Examples of roles include a “ShipTo”, “BillTo” and “Payer” roles.
FIG. 1
illustrates a typical SoldTo customer with its relationship to other customer objects.
In these applications, the subordinate customer objects can be associated with more than one customer object (“SoldTo customer”) and can be created before the customer object is created. Because the customer object stores the links to its related customers, the subordinate customers must exist before the customer object can contain the links to them. Examples of applications that store information this way are applications produced by SAP, PeopleSoft, and Clarify. Problems arise when trying to create a generic business object that supports both of these types of object definitions.
SUMMARY OF THE INVENTION
An object model and system is provided wherein customer's address data or subordinate customers are represented as a separate “customer partner” business object. Synchronization occurs as a multi-step process in which the customer business object is created, customer partner business objects are defined and the relationships between the Customer and its related customer partners are updated. The Customer and customer partner business objects are created so that the relationship between a customer object and its subordinate customer or address is always stored in the parent object (that is, the Customer business object references the customer partner business object). Applications that store the relationship in the child object are configured to trigger an application-specific business object that maps to the customer business object.
The current business object model has been extended to support a hierarchy of objects, providing the ability to inherit and extend more generic business objects into those specific for a subject area. In addition, business objects provide multiple views, allowing different collaborations to view the same object in different ways. Collaborations support inheritance to allow them to be inherited and extended.
The component model proposed herein allows the subsystems (services, collaborations, connectors) in the interchange server to adhere more strictly to a component model, interacting with other subsystems via well-defined interfaces. This allows services from
Bentley Glen
Bhat Suresh
Gupta Prashant
Mellen-Garnett Katrina A.
Orban Susan George
Courtenay III St. John
Holland & Knight LLP
Strimaitis Romualdas
LandOfFree
Expanded object model including roles does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Expanded object model including roles, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Expanded object model including roles will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3353216