Patent Application
20090157719
1. Field of the Invention
The present invention relates generally to after image data. Still more particularly, the present invention provides a mechanism to convert after image data to a delta level change.
2. Description of the Related Art
The Service Data Objects (SDO) framework provides a unified framework for data application development. With a Service Data Objects framework, a user does not need to be familiar with a technology-specific application protocol interface (API) in order to access and utilize data. A user needs to know only one application protocol interface, the Service Data Objects framework application protocol interface, which lets the user work with data from multiple data sources, including relational databases, entity Enterprise JavaBeans (EJB) components, Extensible Markup Language (XML) pages, Web services, the Java™ Connector Architecture, JavaServer™ Pages pages, and more.
Although the word “framework” is used, framework is analogous to the Eclipse framework. Eclipse is designed so that tools can be integrated together thanks to its solid and extensible base. The Service Data Objects framework is similar in the sense that it provides a framework to which applications can be contributed and these applications will all be consistent with the Service Data Objects framework model.
Unlike some of the other data integration models, the Service Data Objects framework does not stop at data abstraction. The Service Data Objects framework also incorporates a good number of Java™ 2 Platform Enterprise Edition (J2EE™) patterns and best practices, making it easy to incorporate proven architecture and designs into user applications. For example, the majority of Web applications today are not (and cannot) be connected to backend systems 100 percent of the time; so the Service Data Objects framework supports a disconnected programming model. Likewise, today's applications tend to be remarkably complex, comprising many layers of concern.
Extensible Markup Language (XML) is becoming ubiquitous in distributed applications. For example, the Extensible Markup Language Schema (XSD) is used to define business rules in an application's data format. Also, the Extensible Markup Language itself is used to facilitate interaction: Web services use the Extensible Markup Language based Simple Object Access Protocol (SOAP) as the messaging technology. Extensible Markup Language is a very important driver of Service Data Objects framework and is supported and integrated in the framework.
Data objects are the fundamental components of the Service Data Objects framework. Data objects are the Service Data Objects framework representation of structured data. Data objects are generic and provide a common view of structured data built by a data mediators services (DMS). Data objects hold their “data” in properties. Data objects are linked together and contained in data graphs.
Data graphs provide a container for a tree of data objects. They are produced by the data mediators services for the Service Data Objects framework clients to work with. A data graph contains a root data object, all of the root's associated data objects, and a change summary (more on change summaries in a moment).
An Enterprise Information System (EIS) is comprised of applications that comprise the existing system of an enterprise for handling company-wide information. Examples of enterprise information systems include: an enterprise resource planning (ERP) system, a mainframe transaction processing system, and a legacy database system. A hub is a virtual data area between different enterprise information systems where data in a format of the particular enterprise information systems may be converted to data in a format of another enterprise information system.
Data that flows around a hub may have three different natures:
There are scenarios where an application requires delta level changes but the data it needs is in an enterprise information system after image format.
The different aspects of the present invention provide a method, data processing system, and computer usable code for converting after image data into a delta level change. A first after image business graph is transformed from an enterprise information system into a generic after image business graph. Another transformation of the generic after image business graph into a second after image business graph is performed. Delta information from another enterprise information system is used to create a delta business graph. Yet another transformation is performed to convert the delta business graph into a generic delta business graph
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The aspects of the present invention provide a method, data processing system and computer usable code for converting after image data into a delta level change. A delta level change describes the changes to an object graph by annotating each property change in the object graph as a create, update, or delete. The data processing device may be a stand-alone computing device or may be a distributed data processing system in which multiple computing devices are utilized to perform various aspects of the present invention. Therefore, the following
With reference now to the figures,
In the depicted example, server 104 and server 106 connect to network 102 along with storage unit 108. In addition, clients 110, 112, and 114 connect to network 102. These clients 110, 112, and 114 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 are clients to server 104 in this example. Network data processing system 100 may include additional servers, clients, and other devices not shown.
In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
With reference now to
In the depicted example, data processing system 200 employs a hub architecture including north bridge and memory controller hub (MCH) 208 and south bridge and input/output (I/O) controller hub (ICH) 210. Processing unit 202, main memory 204, and graphics processor 218 are connected to north bridge and memory controller hub 208. Graphics processor 218 may be connected to north bridge and memory controller hub 208 through an accelerated graphics port (AGP).
In the depicted example, local area network (LAN) adapter 212, audio adapter 216, keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224, hard disk drive (HDD) 226, CD-ROM drive 230, universal serial bus (USB) ports and other communications ports 232, and PCI/PCIe devices 234 connect to south bridge and I/O controller hub 210 through bus 238. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM 224 may be, for example, a flash binary input/output system (BIOS).
Hard disk drive 226 and CD-ROM drive 230 connect to south bridge and I/O controller hub 210 through bus 240. Hard disk drive 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. Super I/O (SIO) device 236 may be connected to south bridge and I/O controller hub 210.
An operating system runs on processing unit 202 and coordinates and provides control of various components within data processing system 200 in
As a server, data processing system 200 may be, for example, an IBM eServer™ pSeries® computer system, running the Advanced Interactive Executive (AIX®) operating system or LINUX operating system (eServer, pSeries and AIX are trademarks of International Business Machines Corporation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both). Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors in processing unit 202. Alternatively, a single processor system may be employed.
Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 226, and may be loaded into main memory 204 for execution by processing unit 202. The processes for embodiments of the present invention are performed by processing unit 202 using computer usable program code, which may be located in a memory such as, for example, main memory 204, read only memory 224, or in one or more peripheral devices 226 and 230.
Those of ordinary skill in the art will appreciate that the hardware in
In some illustrative examples, data processing system 200 may be a personal digital assistant (PDA), which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data.
A bus system may be comprised of one or more buses, such as bus 238 or bus 240 as shown in
A mechanism is provided for converting after image data into a delta level change. A first after image business graph from an enterprise information system is transformed to a generic after image business graph. An after image business graph is the result of a query against a data source after the data source has had some type of change. Translating this after image business graph into a canonical form results in a generic after image business graph. Another transformation is performed transforming the generic after image business graph into a second after image business graph, using delta information from another enterprise information system is used to create a delta business graph. A final transformation is performed to convert the delta business graph into a generic delta business graph. The delta business graph is used by business process logic that requires a delta business graph as part of its data contract.
Turning to
Turning now to
Enterprise repository 430 is comprised of metadata driven interface 432, multi-level query data management subsystem 434, and object data management subsystem 436. Both multi-level query data management subsystem 434 and object data management subsystem 436 have interfaces 438 and 440 to interact with metadata driven interface 432 of enterprise repository 430. Interfaces 412, 432, 438, and 440 may be any type of interface such as an extensible markup language (XML), Internet inter-ORB protocol (IIOP), or interface definition language (IDL) interface.
Asynchronous distributed object oriented framework 442 provides the framework for client applications 444 and 446 through Internet 448 to access enterprise repository 430 and software runtime component services 402 and 404. In this approach, new services are created as new run-time deployable components. The services are built from the collaboration of business objects 414, 416, 418, and 420 that are themselves runtime deployable components 402 and 404. In a normal component, the information model is mapped directly to the enterprise repository 430. It is this tight coupling between the business objects 414, 416, 418, and 420 and its enterprise repository 430 that induces inflexibility into a typical enterprise. The metadata aware business objects approach removes the rigid constraints between business objects 414, 416, 418, and 420 and enterprise repository 430. With the metadata interface, enterprise repository 430 needs of business objects 414, 416, 418, and 420 can be dynamically created on the fly. In addition, new relationships and associations between component model specifications can also be dynamically created. This approach paves the way for a new breed of enterprise software, one in which arbitrary interaction and interoperation may be made between components to define the services offered by the enterprise. Software component services 402 and 404 are services that are offered by an application such as enterprise applications 310, 312, and 314 of
The transformation performed by transformation component 606 may be performed by mapping the application specific object graph that comes into a generic object graph. The precise semantics of this mapping depends on the object graph coming in, which is application specific, and the target object graph, which is the generic form. The mapping will be unique for each to/from set of object graphs. For example, an application specific business object is SAPCustomer, which has fields in it that are specific to SAP. Customer is a generic business object, which has fields in it that are related to customer but do not pertain to any one specific enterprise information system.
A reverse mapping is then performed to transform G after image business graph (G AIBG) 608 into Y after image business graph 612 (Y AIBG). Forward mapping is SAPCustomer to Customer, a reverse mapping example would be Customer being mapped to SAPCustomer—the opposite mapping. The transformation follows the normal pattern leveraging of transformation component 610 that transforms G after image business graph (G AIBG) 608 into Y after image business graph 612 (Y AIBG). Thus, the transformation performed in transformation component 610 is conceptually similar to the transformation performed in transformation component 606, but instantiated very differently. That is, for example, the transformation performed in transformation component 610 is responsible for mapping from SAPCustomer to Customer, or from Customer to SAPCustomer, or from PSFTCustomer to Customer, or vice versa. In other words, one mapping is SAPCustomer to Customer, while the other mapping is Customer to PeopleSoftCustomer.
A key portion of this exemplary conversion is the utilization of information available from enterprise information system Y 614 that is used to transform the Y after image business graph 612 (Y AIBG) into a Y delta business graph (Y ABG) 618 through the normal pattern leveraging of transformation component 616. A delta level change describes the changes to an object graph by annotating each property change in the object graph as a create, update, or delete. The information may be new information or previously stored information with relation to previous conversions.
Thus, for example, an earlier conversion may have consisted of four elements but a current conversion consists of only five elements. Thus, enterprise information system Y 614 can provide transformation information that elements previously converted are not part of this conversion.
Normal pattern leveraging of transformation component 620 transforms Y delta business graph (Y ΔBG) 618 into G delta business graph (G ΔBG) 622. Finally, an exemplary demonstration of a potential use of the above described mechanism is shown by using G delta business graph (G ΔBG) 622 in Flow Manager or Adaptive Entity process 624. Flow Manager or Adaptive Entity process 624 may be any type of business object graph that requires a delta form as part of its contract. That is Flow Manager or Adaptive Entity process 624 has an expectation of this type of data, which is standardized as part of the SDO specification.
To reiterate the utilization of information available from enterprise information system Y 614 as the key concept, the following example is provided. If the upstream system is an order taking/modification system, and an order is created, initially, that order and all the order's line items are passed to the downstream system. The same order, with, for example, four line items exists upstream and downstream in both persistent stores. Then, when the upstream system is updated, through a user adding an order line item to the order and modifying one of the existing order line items, the upstream adapter queries the upstream system to determine the after image, which is an order, with five order line items. The after image does not have the “delta” information yet, that is, the after image does not know that one was added and one was modified, the after image merely knows what the new version looks like.
Continuing with the example, the data is then passed to the downstream system, through the canonical mapping pattern of going X to G (606) and then G to Y (610). The downstream code in transformation component 616 looks in the database at the first version of the order, and compares it to the current version of the order. Thus, it is able to determine that the fifth order line item was added, and the order line is annotated to the delta object graph with some information that describes that this fifth line item is “created”. The transformation component 616 also identifies that one of the existing line items was modified, and annotates the delta graph that one of the properties in the modified order line item was “modified” or “updated”. Now, the delta business graph is of type Y, and understood by the Y system, so it is, for example, a PSFTCustomer, understood by the PSFT enterprise information system. The delta business graph is then transformed through transformation component 620 back into a generic object of type G. Now that this has occurred, some business logic that requires a G object in delta form can now process that data.
As a key point in this exemplary operation, information obtained from a second enterprise information system is utilized to transform the third after image business graph into a first delta business graph using a third transformation (step 708). A fourth transformation is then performed to transform the first delta business graph into a second delta business graph (step 710), with the operation ending thereafter.
Thus, the described mechanism converts an after image data into a delta level change. Delta information from a second enterprise information system is used in conjunction with a transformed after image business graph to produce a delta business graph.
The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11187044 | Jul 2005 | US |
| Child | 12392522 | US |
