MXPA00010063A - Visual data integration system and method - Google Patents
Visual data integration system and methodInfo
- Publication number
- MXPA00010063A MXPA00010063A MXPA/A/2000/010063A MXPA00010063A MXPA00010063A MX PA00010063 A MXPA00010063 A MX PA00010063A MX PA00010063 A MXPA00010063 A MX PA00010063A MX PA00010063 A MXPA00010063 A MX PA00010063A
- Authority
- MX
- Mexico
- Prior art keywords
- components
- information
- data
- visual
- visually
- Prior art date
Links
- 230000000007 visual effect Effects 0.000 title claims abstract description 135
- 238000000034 method Methods 0.000 claims abstract description 56
- 238000005516 engineering process Methods 0.000 claims abstract description 26
- 238000004458 analytical method Methods 0.000 claims abstract description 14
- 230000001419 dependent Effects 0.000 claims abstract description 8
- 230000001264 neutralization Effects 0.000 claims abstract description 3
- 238000004891 communication Methods 0.000 claims description 31
- 230000004044 response Effects 0.000 claims description 9
- 230000005540 biological transmission Effects 0.000 claims description 3
- 230000001131 transforming Effects 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 27
- 238000011161 development Methods 0.000 description 15
- 230000018109 developmental process Effects 0.000 description 15
- 230000000875 corresponding Effects 0.000 description 14
- 238000009826 distribution Methods 0.000 description 13
- 239000000969 carrier Substances 0.000 description 12
- 238000003860 storage Methods 0.000 description 12
- 230000004048 modification Effects 0.000 description 10
- 238000006011 modification reaction Methods 0.000 description 10
- 206010040007 Sense of oppression Diseases 0.000 description 8
- 230000003068 static Effects 0.000 description 6
- 238000010276 construction Methods 0.000 description 5
- 238000010200 validation analysis Methods 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 230000003213 activating Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 229920002574 CR-39 Polymers 0.000 description 2
- 210000004544 DC2 Anatomy 0.000 description 2
- 101710045257 UFL1 Proteins 0.000 description 2
- 238000011030 bottleneck Methods 0.000 description 2
- UIIMBOGNXHQVGW-UHFFFAOYSA-M buffer Substances [Na+].OC([O-])=O UIIMBOGNXHQVGW-UHFFFAOYSA-M 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 230000002452 interceptive Effects 0.000 description 2
- 230000002530 ischemic preconditioning Effects 0.000 description 2
- 230000004301 light adaptation Effects 0.000 description 2
- 230000000670 limiting Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000002085 persistent Effects 0.000 description 2
- 238000003825 pressing Methods 0.000 description 2
- 238000007619 statistical method Methods 0.000 description 2
- VOXZDWNPVJITMN-ZBRFXRBCSA-N 17β-estradiol Chemical compound OC1=CC=C2[C@H]3CC[C@](C)([C@H](CC4)O)[C@@H]4[C@@H]3CCC2=C1 VOXZDWNPVJITMN-ZBRFXRBCSA-N 0.000 description 1
- 101710009141 ASN1 Proteins 0.000 description 1
- 101700076374 ASNS Proteins 0.000 description 1
- 229910000497 Amalgam Inorganic materials 0.000 description 1
- 102100018316 CMIP Human genes 0.000 description 1
- 101700075796 CMIP Proteins 0.000 description 1
- 101700082984 PARN Proteins 0.000 description 1
- 206010037742 Rabies Diseases 0.000 description 1
- 101700050571 SUOX Proteins 0.000 description 1
- XCCTYIAWTASOJW-XVFCMESISA-N Uridine-5'-Diphosphate Chemical compound O[C@@H]1[C@H](O)[C@@H](COP(O)(=O)OP(O)(O)=O)O[C@H]1N1C(=O)NC(=O)C=C1 XCCTYIAWTASOJW-XVFCMESISA-N 0.000 description 1
- 230000004308 accommodation Effects 0.000 description 1
- 230000001154 acute Effects 0.000 description 1
- 230000003044 adaptive Effects 0.000 description 1
- 230000003542 behavioural Effects 0.000 description 1
- 150000001768 cations Chemical class 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000000994 depressed Effects 0.000 description 1
- 238000005315 distribution function Methods 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000016507 interphase Effects 0.000 description 1
- 150000002500 ions Chemical class 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000003278 mimic Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000036961 partial Effects 0.000 description 1
- 239000003247 radioactive fallout Substances 0.000 description 1
- 230000002829 reduced Effects 0.000 description 1
- 230000036633 rest Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 235000010384 tocopherol Nutrition 0.000 description 1
- 235000019731 tricalcium phosphate Nutrition 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
- 230000003442 weekly Effects 0.000 description 1
Abstract
A visual data integration system architecture and methodology is disclosed. The system architecture includes a transport framework that represents a technology-independent integration mechanism that facilitates the exchange of technology-dependent data between disparate applications. A visual interface facilitates the design, deployment, and runtime monitoring of an integrated information system implementation. An integrated information system is developed visually through use of the visual interface by dragging and dropping components within a canvas area of the interface. The components are graphical representations of various telecommunications hardware and software elements, such as information stores, processors, input/output devices and the like. Various components may be packaged together as business extension modules that provide specific business integration capabilities. Interconnections between components are graphically established using a mouse to define sources and destinations of specified data. An underlying configuration/runtime information framework operating above and in concert with the transport framework effectively transforms the graphical interconnections into logical or physical interconnections, which results in the contemporaneous generation of an integrated runtime system. Format neutral data meta-models are employed to model the input and output data requirements of disparate systems and system components so as to remove any cross-dependencies that exist between the systems and technologies implicated in a data integration project. The visual interface enables runtime control and analysis of the business information and system aspects of an integrated system implementation. Visual views onto the live deployment provide consistent management and control for system integrators, business integrators, system managers, and business managers using a single visual interface.
Description
SYSTEM OF INTEGRATION OF VISUAL DATA AND METHOD
Field of the invention Uk 5 The present invention relates in general to information systems and, more particularly, to a system and method that employs an interface to visually integrate disparate information technologies. BACKGROUND OF THE INVENTION Several proposed solutions have been presented to face the problem of effecting data communication
^ between computer systems platforms and applications developed using different technologies. Increased reliability over processing systems and architectures
distributed data, such as those used to support
Internet and electronic data exchange activities
(EDI) for example, has created a need for an improved approach to designing and deploying an integrated information system capable of transporting vast amounts of data of various types and formats between applications having different interface characteristics. In an attempt to address the problem of transporting different types of data between different systems and applications, several products have been developed.
data exchange and approaches. A traditional approach to electronically link several disparate systems together involves the creation of client ports or interface systems. A typical client port is created to solve a narrowly focused interface problem, such as allowing systems # 1 and # 2 to exchange data of types? ' and 'B' produced by systems # 1 and # 2, respectively. These specialized ports are generally not intended or designed to accommodate the exchange of data between a large number of disparate systems and applications. It is understood in the art that modifying an existing client port to deal with a new and different interface problem is generally unproductive and expensive, given the inherent limitations of the original port design. Several information technology standards have been advanced in an attempt to deal with this and other data exchange problems experienced within a distributed data communications and processing environment. One of these standards, known in the art as CORBA (common object request broker), has received a lot of recent attention, as it would seem to solve many of the aforementioned problems. A critical review of the CORBA approach, however, reveals that CORBA is not designed to act as a data transport mechanism. Instead, CORBA is primarily designed to pass control methods over TCP / IP. The strength of CORBA is the ability to use C ++ methods over a network. CORBA requires that all applications must be object oriented, which avoids the inclusion of a substantial number of existing applications developed using structured programming techniques. Moreover, although CORBA refers to a "standard", there are several implementations of the CORBA product that are not compatible, and as such, they are able to communicate with each other. Other technologies, such as transaction monitors, have been developed primarily to control complex transactions between multiple applications in a distributed processing environment. These transaction monitors typically connect applications through stringent transaction rules applied through IDL (interface definition language) interfaces defined through IPC methods (interprocess communications). A typical transaction monitor has a complex structure and must conform to, and is complicated to use and maintain. If any of the individual transactions that configure a set of transactions fail, the entire complex transaction must be rolled back, instead of the only failed transaction. Transaction monitors are generally optimized for transaction control, and not to perform data exchange. The languages of fourth and fifth generations, called 4GL and 5GL, would seem to offer a partial solution to the problem of data exchange. These and other similar languages, such as those used to build "business objects" are optimized around the construction of applications and user interfaces for the primary purpose of providing powerful interrogation and reporting tools. The objects created by these languages typically define access paths to the data residing in the databases. Objects can be combined in various ways to create complex interrogations and to build powerful report generators. The languages of fourth and fifth generation are not well adapted to transport vast amounts of data from one application to one or more other applications in a reliable and efficient manner. Although business objects constructed using 4GL and 5GL techniques do not carry with them a certain amount of data, this data is typically data resulting from an interrogation that is transported with an object definition for the purpose of further analysis of the data. Further complicating the technical problems associated with prior art data integration approaches is the recognition that disparate information sources are typically integrated to serve business needs and objectives. A proposed technical solution to the data integration problem should not inhibit a user's ability to obtain important information derivable from the data that passes through the proposed system. On the contrary, a proposed technical solution must meet or exceed the user's business information needs, 5 and must also provide an extensible structure capable of easily accommodating new sources and information technologies. Conventional data integration tools are typically designed to reduce the
The effort and cost spent on integrating different information systems from a technical perspective, but generally are used with little or no concern given the potential limiting impact that the resulting solution may have on business information requirements. The integration to
The business level is typically carried out using tools very different from those used to perform the data integration. Moreover, the runtime environment of a conventional data integration deployment typically is maintained through the use of a set
separate from system administration tools. The incompatibilities of varying severity frequently arise from the system in which the technical integration solution rests on a foundation or structure different from the one that supports the integration solution of the
business. These incompatibilities generally limit the user's ability to interact efficiently with an integrated integration system conventionally implemented during the design and deployment phases, and significantly complicates the effort of extracting an important system and the integration / business administration information for the system. There is an acute need for an improved data integration system and a methodology capable of effectively integrating data produced by applications of different technologies. There is an additional need for this system and methodology that employs a single intuitive user interface that provides various types of information to users who have different output and data entry requirements. There is also a need for this system and methodology to be easily extensible and independent of any current or future technology. The present invention fills these and other needs. SUMMARY OF THE INVENTION The present invention is directed to an architecture and methodology of visual data integration systems. The architecture of the system includes a transport structure that represents an integration mechanism independent of the technology that facilitates the exchange of data dependent on the technology between different applications. A visual interface facilitates the design, deployment and monitoring of the execution time of an integrated information system implementation. An integrated information system is displayed visually through the use of the visual interface by dragging and dropping the component icons into the interface scrutiny area. The component icons are graphic representations of various elements of data processing and telecommunications hardware and software. Several component icons can be packaged together in business extension modules to provide users with specific business integration capabilities. The interconnections between components placed in the counting area are graphically established using a mouse to define specific data sources and destinations. An underlying configuration and runtime information structure effectively transforms graphical interconnections into logical or physical interconnections, which results in the contemporary deployment of an integrated analog runtime system. Metamodels of format-neutral data are used to model the input and output data requirements of disparate systems and system components to remove any cross-dependencies that exist between the systems and technologies applied in the data integration project. The use of metamodels in this way effectively composes the data integration project system, thereby allowing interconnections between established and modified system components using visual drag-and-drop metaphors and mapping of metamodels. The visual interface provides a control and analysis of the execution time of the businesses and the technical aspects of an integrated information system deployment. Visual views about the deployment of the runtime system provide consistent management and control for a variety of users who have different data input / output reports, and interface requirements. In one embodiment, the transport structure comprises a data exchange infrastructure that includes several adapters associated with a corresponding number of applications. Each of the adapters is adapted to the client to connect with a corresponding application and transforms the data that is being transferred between the application and the data exchange infrastructure. The data produced by a particular application is converted in a technology-dependent way to an independent form of the technology through the corresponding adapter. The data exchange infrastructure receives data in an independent form of technology from each of its associated adapters and coordinates the routing of information content towards particular adapters associated with applications that have requested specific information content. The adapters that receive the information content from the data exchange infrastructure transforms the content and information that has a common format into a format compatible with, or specific to, its associated applications. A queuing mechanism is used to build reliable asynchronous or pseudo-synchronous interfaces between disparate applications and systems. The data exchange infrastructure can apply business rules or logic as soon as it processes a request for a particular information content. An application, for example, may require information content produced by several different applications. The data exchange infrastructure obtains, organizes and processes the information content of multiple sources as dictated by the specific business logic of the business. Changes to processing and organization requirements for a particular user or application are made by simply modifying the user's specific business logic, the time of the data exchange infrastructure code. The routing logic specified to the user can be applied by the data exchange infrastructure to dispatch content of selected information to one or more target applications. As with business logic, changes in routing requirements are made by simply modifying the routing logic, rather than the data exchange infrastructure code. Process monitoring, tracking, and logging are provided to track the progress of data passing through the data exchange infrastructure and to detect and correct processing errors. In the case of a processing anomaly, the data exchange infrastructure is rolled back from failed transactions to avoid data loss. You can also provide performance statistics. Various statistics / analysis charts and business-related diagrams can be made available to the user through the visual interface using system-oriented views and business. A wide variety of interfaces can be developed by the proper deployment of adapters from one or more processing / logic units of the data exchange infrastructure. Proprietary rear end systems that have only a single user interface, for example, can logically be transformed into an open system that has multiple user network interfaces. Unreliable applications can be stabilized through the use of data exchange infrastructure. The disparate business systems, whether archaic or state-of-the-art, can effectively link together to create electronic link ports, for example. The above compendium of the present invention is not intended to describe each embodiment or each implementation of the present invention. The advantages and scope, together with a more complete understanding of the invention, will be apparent and may be appreciated referring to the following detailed description and the claims taken along with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a system level diagram of a visual data integration architecture according to an embodiment of the present invention.; Figure 2 illustrates in block diagram form the flow of data between disparate applications within the information systems operated by two information service providers according to a conventional data integration approach; Figure 3 illustrates the deployment of a visual data integration architecture of the present invention within the information system environment of the information provider # 1 shown in Figure 2; Figures 4, 5A and 5B illustrate additional modalities of the visual data integration architecture deployed to significantly increase data exchange within existing information systems environments, - Figure 6 is a block diagram of an architecture system of integration of visual data according to another embodiment of the present invention; Figure 7 is a representation of several adapters operating in cooperation to perform data integration according to an embodiment of the present invention; Figure 8 is a block diagram of the detailed system of another embodiment of a visual data integration architecture implemented in accordance with the principles of the present invention; Figure 9 illustrates additional details conforming to various queuing and control characteristics of a visual data integration architecture implemented in accordance with the principles of the present invention; Figures 10-11 are flow charts illustrating various processes involving the transport of data through a data exchange infrastructure according to two additional embodiments of the present invention; Figures 12-14 illustrate in a flowchart several procedures involving the transport of data through a data exchange infrastructure according to another embodiment of the present invention; Figures 15 and 16 are conceptual models of a visual data integration architecture that includes a transport structure, visual interface, a configuration structure and runtime information, and one or more business extension modules implemented in accordance with one embodiment of the present invention; Figure 17 is a representation of a visual interface for building, deploying, monitoring, and managing a data integration display according to an embodiment of the present invention; Figure 18 is a graphic illustration of an actual data integration system implementation as seen using a System Integration view; Figure 19 is a representation of a layout planning panel of a visual interface of the present invention that provides a tree view of a network environment currently in operation for a selected data integration project; Figure 20 is a graphical illustration of the implementation of the data integration system shown in Figure 18 as seen using an Integration view of
Business; Figure 21 is an illustration of a tail status diagram developed for the data integration implementation shown in Figure 18 using a System Administration view. Figure 22 is an illustration of a business information graph developed from the data integration implementation shown in Figure 18 using a Business Administration view; Figures 23 and 24 are displays of queue views of a queue management utility that allows the user to adjust, correct, or otherwise modify the
• content of a common object; and Figures 25A-25C define a directory structure of the runtime information structure and configuration of a visual data integration architecture within which configuration files are placed and manipulated in accordance with an embodiment of the present invention. . Although the invention lends itself to several modifications
• and alternative forms, those specific thereto have been shown by way of example in the drawings and will be described in detail hereinafter. However, it will be understood that the intention is not to limit the invention to the particular embodiments described. On the contrary, the invention is intended to cover all modifications, equivalents and alternatives that fall within the spirit and scope of the invention as defined by the appended claims. Detailed description of the different modalities In the following description of the modalities illustrated, reference is made to the accompanying drawings which form a part thereof, and in which is shown by way of illustration, several modifications in which it is possible to practice the invention. It will be understood that other embodiments may be used, and structural and functional changes may be made without departing from the scope of the present invention. In Figure 1 there is illustrated an architecture of visual data integration according to an embodiment of the present invention. The system 30 shown in Figure 1 provides a transport structure 33 and a visual interface 31 to facilitate the design, deployment and monitoring of the execution time of an integrated information system comprising several disparate applications. In broad and general terms, the transport structure 33 provides an integration mechanism independent of the technology that facilitates the exchange of technology-dependent data between disparate applications. The transport structure 33 allows reliable and scalable information routing between different applications and different technologies. The visual interface 31 allows the rapid design, deployment and control and analysis at the time of execution of the business information and aspects of the system / technicians of an integrated system implementation. An integrated information system is visually developed through the use of the visual interface 31 typically by dragging and leaving building blocks of components within a representation of the graphic system using a mouse or other input device. These component building blocks are graphic representations of various hardware elements and data processing and telecommunications software, such as information stores, processors, input / output devices, bridges, routers, and the like. The interconnections between the component building blocks are typically graphically established by using the mouse to define specified data sources and destinations. An underlying configuration and runtime information structure that operates on and in concert with the transport structure effectively transforms graphical interconnections into logical or physical interconnections, which results in the contemporary generation of a deployment of the runtime system correspondent. As soon as it is completely configured, and with any necessary adaptation to the completed client, the oppression of a button activates the execution of the execution time of an integrated information system.
Visual views on live deployment provides consistent management and control for system integrators, business integrators, and system administrators, and business managers. In order to illustrate various features and advantages realized when implementing a visual data integration architecture in accordance with the principles of the present invention, it is assumed in Figure 1 that several different applications, identified as applications # 1, # 2, # 3, and # 4, produce several different types of data. The term "different applications" as used herein is intended to refer to applications that differ in terms of technology, operation, support platforms and operation systems, data, input / output interfaces, communication protocols, and the like. The term "different data" is intended to refer to data types that differ in terms of format, structure, protocol, content and the like. It is also assumed that each of the Applications shown in Figure 1 requires information provided by other Applications. Application # 3, for example, produces the information content 'C' which is required by Application 'D', and requires information content? ' and 'B' produced by Applications # 1 and # 2, respectively. As such, each of the Applications, although distinctly representing different technologies that can be supported on different platforms, depend on each other for various information contents. Those skilled in the art will appreciate that the difficulties of providing a
• mechanism to effect the required exchange of information between different applications at the same time that a myriad of technological independencies are faced. A traditional approach to implement an interface adapted to the client to effect the exchange of information between two different applications generally resolves a
communications problem narrowly focused, but
• typically results in an inflexible, intolerant solution to even the slightest changes in terms of format, function, or operation. The solutions of the prior art to develop these interfaces to allow the
Communication between different applications generally depends on the inherent technologies in either or both of the application software and / or the hardware / software platform that the application supports. These dependencies on technology are well understood as significantly limiting the
ability to modify, extend, and scale an existing communications infrastructure, and significantly complicate or even impede the integration of new sources of information and technologies. Moreover, the integration tools
Conventional organizations are generally unable to integrate disparate information systems in a way that satisfies both system and business requirements using a consistent and consistent methodology. These conventional j? Tt integration tools generally fail to provide a
interface that allows the user to efficiently develop an integrated system design, which easily perceives different hardware and software components and design interconnections, effectively transforms a graphic system representation into a live runtime deployment,
and monitor design effectiveness during both the development phase and the subsequent deployment phase. As will be described in detail hereinafter, a data integration approach consistent with the principles of the present invention provides a
transport mechanism that is completely free of dependencies in technology, and also provides an intuitive visual interface that allows the rapid design, deployment, and control of the execution time, monitoring and analysis of the business / information and aspects of
system / technicians of the integrated information system implementation. With further refce to Figure 1, it is assumed that Application # 1 produces data of type 'A' which can be seen as comprising two constituent components. The term
Data, within the context of the illustrated environment of Figure 1, is assumed to include an information content component and a format component. The information content component represents unprocessed information, typically business information, such as accounting information for example. The format component typically represents a technology-dependent construction that provides a means to electronically interact with the information content component. The format component, for example, can be defined as including data structures, protocols, writings, control codes, and other technology-specific content. It will be appreciated in the art that many so-called "compliant" or "compliant" applications are indeed inhtly dependent on the technology, thy preventing the seamless and reliable transport of information between two or more "compatible" applications. As previously discussed, even standards-based applications are often unable to effectively communicate with each other without the intervention of a logic or protocol. In Figure 1, Application # 1 produces data of type? ' which comprises the information content 'A' associated with the format? ' . It is assumed in this illustrative example that Applications # 2, # 3, and # 4 require selected portions of information content? produced by Application # 1. The transport structure 33, which in this embodiment comprises a data exchange infrastructure 32 in cooperation with the adapters 34a-34d, facilitates the exchange of required portions of information content < fl? ' as follows. In response to a request for 5 particular data received by Application # 1, the selected data of type? ' they are transmitted to adapter 34a. The adapter 34a processes the 'A' type data so as to eliminate any technology dependence associated with the data type 'A'. In particular, adapter 34a disassociates the
information content component? ' , alternatively known as the information content? ' , from the associated format component 'A', and transmits only the information content? ' to the data exchange infrastructure 32. In accordance with one embodiment of the present invention, the adapter 34a reformulates the information content 'A' in a common or generic form which is subsequently operated on the data exchange infrastructure 32. Each of the 34a-34d adapters performs this
The process of reformulating a technology-specific data stream in the form of generic or common data independent of the technology. Assuming that Application # 2 requires selected information content 'A' produced by Application # 1,
the data exchange infrastructure 32 facilitates the transport of the content information? ' to adapter 34b associated with Application # 2. Does adapter 34b reformulate the information content? which has a common representation in an 'A' format representation that is compatible with Application # 2. The adapter 34d, similarly, receives from the data exchange infrastructure 32 the specified information content 'A' reformulated from the format? ' to the common or generic format. The adapter 34b reformulates the information content 'A' from the common representation to a convenient 'D' type format for incorporation by Application # 4. Also shown in Figure 1, Application # 3 requires that the information content selected? ' of Application # 1. The information content specified? ' it is converted in a generic way by means of the adapter 34a, it is transmitted through the data exchange infrastructure 32 to the adapter 34c, and converted to a form of 'C' format for inclusion by Application # 3. It can be seen from Figure 1 that disparate types of selected data can be effectively and reliably transported between different applications with relative ease through the use of the data exchange architecture in accordance with the principles of the present invention. The cooperative use of adapters associated with specific applications together with one or more processing / logic units of the data exchange infrastructure either eliminates or renders harmless the technology dependencies inherent in the data transferred through the data exchange infrastructure. data This implementation generally eliminates or significantly minimizes the need for client-adapted interfaces that are otherwise required to facilitate the transport of different types of data between different applications. In other words, the traditional connectivity problem N x N associated with traditional connection approaches can be effectively reduced to a 1 x N connectivity scenario using a data exchange approach consistent with the principles of the present invention. To facilitate a better appreciation of the advantages offered by the data integration infrastructure implemented in accordance with the present invention, reference is made to Figures 2-3. In Figure 2, a number of Applications, Applications # 1A- # NA, are represented, which interact with an information systems environment that operates through an information provider # 1. Information provider # 2 operates an information system within which several disparate applications, represented by Applications # lB- # Nß, interact in a specified manner. In addition to communicating information within each information systems environment, various types of information must be shared between two information providers # 1 and # 2. By way of example, and assuming that information providers # 1 and # 2 provide telecommunications services, information provider # 1 may represent a local exchange carrier while information provider # 2 may represent an exchange carrier. It can be appreciated that the architecture of the information system associated with each of the information providers # 1 and # 2 typically represents a complex amalgam of archaic or legacy applications in addition to the state-of-the-art applications. The hybrid environment generally leads to an increased dependence on customer-integrated data integration interfaces, such as client ports, necessary to facilitate sharing information between different applications within an operating environment of the given information provider. Even simple modifications to a single application typically have significant upstream and downstream ramifications that often require specialized and costly connection solutions. In the illustrative mode shown in Figure 2, it is assumed that the local exchange carrier # 1 wishes to enter a long distance market to extend its service and customer base. The recently approved telecommunications law of 1996 (in the United States of America), however, mandates that the local exchange carrier # 1 provide "equivalent" access to its local cycles, which allows the interchange carrier # 2 have access to the applications and information supported within the information infrastructure operated by the local exchange carrier # 1. In order to comply with federal regulations, the local exchange carrier # 1 must tolerate the intrusion into their internal information systems by the interchange carrier # 2. HE You may appreciate that the conventional approach of building electronic link ports tailored to the client to facilitate communications two or more different information provider environments would result in a costly and generally inflexible interface solution. A data integration infrastructure implemented in accordance with the principles of the present invention greatly simplifies the task of connecting numerous different applications to facilitate reliable communication of information between two information provider environments such as those depicted in Figure 2. As shown in Figure 3, a data exchange infrastructure according to one embodiment of the present invention can be deployed to accommodate the access requirements of the inter-exchange bearer # 2 and security considerations of the local exchange bearer # 1.
This illustrative solution offers several advantages hitherto not achievable using conventional connection approaches. In particular, the capacity for expansion, flexibility, and scalability is introduced into the information exchange environment of the local exchange carrier # 1 which was not previously feasible using the original architecture shown in Figure 2. Moreover, none of the Applications or data supported or produced by the applications (ie, 1A-NA applications) need to be changed when a data exchange infrastructure is deployed in accordance with the principles of the present invention. Also, the visual interface 61 can be extended to visually develop an integrated runtime system solution, such as that shown in Figure 3, which mimics the required functionality and the interconnections of the systems shown in Figure 2 in a manner efficient and effective in cost. In this illustrative example, each adapter A-N is associated with a corresponding data stream. Data stream Dl7 for example, may represent EDI data generated by Application # 1 running in a proprietary back end system. It is understood in the telecommunications industry that EDI represents a generally acceptable standard for passing electronic messages between telecommunications service providers. However, it is also understood in the industry that several EDI dialects exist which need some form of data transformation that is presented in order to facilitate effective communication between the back end systems. Adapter A is configured to disassociate the content of information transported within the EDI Di data stream from its associated EDI and dialect format. The EDI information content extracted by the adapter A is reformed to a common representation and then transported through the data exchange infrastructure 62 to a destination application within the environment of the inter-exchange bearer # 2. The adapter 120, in this mode, is configured to translate the content of the EDI information having a common format to an EDI format and dialect required by the target application. The adapter 120 also converts source EDI information transmitted from the inter-exchange carrier # 2 in common or generic form. The data integration infrastructure represented in Figure 3 effectively isolates the owner information and the systems of the local exchange carrier # 1 still provides the required access to the inter-exchange carrier # 2 mandated by the current federal regulations. Furthermore, by deploying the data exchange architecture shown in Figure 3, the development of new interfaces not contemplated or easily achievable is provided given the limitations of the architecture of the original system.
For example, an adapter, such as the W adapter, can be deployed to facilitate communication and data exchange via the Internet. As a further example, a network browser interface can be developed to convert a single-user interface from a proprietary back end system to a multi-user network lookup interface without the need to modify the system. back end or the applications that run on it. A network search interface, represented as
WWW application in Figure 3, can thus be implemented
• with little effort and cost. In Figure 4, another modality of an information exchange environment is illustrated within which the data exchange infrastructure according to the
The present invention can find a particular application. The data exchange infrastructure can be implemented to increase workflow or process management systems that interact with any number
• of legacy or proprietary applications, data warehouses
remote, or multiple user work queues and applications. In this mode, the data exchange infrastructure provides reliable application integration, data movement, and remote work queues. In this configuration, implementations of unreliable systems, such as
scratch screen applications or networks with bad line condition, can be transformed into reliable implementations through the use of data exchange infrastructure. In particular, this conversion from unreliable to reliable is achieved, for example, through the use of persistent queues, rolling processing again after transaction failures, which provides transaction integrity, and transaction retry processing as appropriate. necessary. Figure 5A represents an exchange infrastructure implemented within an existing information exchange environment. In this illustrative example, a data exchange infrastructure is implemented to provide reliable interfaces between legacy or proprietary applications and newer interfaces, such as network-based interfaces. With respect to this, archaic or legacy applications can be provide interfaces of the state of the art to facilitate substantially increased user interaction. In this example, an EDI data stream is processed through the data exchange infrastructure as a received transaction initiated by a legacy or owner application. In response to a user request, for example, the selected data generated by the legacy or owner application is processed through the data exchange infrastructure to provide user access through a network-based interface. in previous examples, neither the EDI data nor the legacy / owner applications require modification, since all the accommodations to different data formats and applications are provided through the data exchange infrastructure. Figure 5B is an illustration of a data integration architecture implemented to significantly increase the functionality of, and accessibility to, a back end proprietary information system administered by a telecommunications service provider. In this illustrative example, customer telephone number records are kept using a back end system 80 which is accessible only through the use of a single user terminal interface 82. According to a traditional approach of transferring information from the customer. telephone number of the customer from the back end system 80 to a database system managed by another service provider, such as the database 90, telephone number records of selected customers are printed on paper, dispatched via facsimile or by mail, and manually re-entered into the database 90 using an attached user interface 92. The data integration approach consistent with the principles of the present invention completely solves the duplicate manual reintroduction of the customer's telephone records into the database 90, and greatly increases the functionality of, and accessibility to, the s disparate applications 80, 90. As shown in Figure 5B, a screen scraper 84 is employed to transform the terminal interface before a single user 82 into an interface providing interconnectivity with multiple applications and interfaces. An EDI 94 adapter, for example, may be connected to the screen scraper 84 to provide telephone number data of EDI formatted clients to another telecommunications service provider. By way of another example, the information obtained by the screen scraper 84 can be processed by a results / analysis module 96, and the processed data can be formatted by an HTML formatter (hypertext markup language) 98. The data formatted in HTML can then be communicated to several e-mail receivers via an e-mail adapter 100. The owner database 90 can be effectively, although securely, opened for increased use by using the ODBC (open database connectivity) adapter 106. The information extracted from the database 90 and processed by the ODBC adapter 106 can be transmitting to a link module 102. The information extracted from the customer telephone registration system 80 using the screen scraper 84 can also be transmitted to the linker module 102.
A composite data stream produced by the jointer module 102 can then be formatted by an HTML formatter 104 which, in turn, communicates the composite data stream formatted to a DGI adapter (common port interface) 86. 5 telephone registration of the selected customer can be transported between the system 80 and the disparate billing application 118 via the CGI adapter 86 and the screen scraper 114 coupled with the terminal interface 116. The CGI adapter 86 provides connectivity to a network server. to facilitate the exchange of data between
• the disparate applications depicted in Figure 5B. Referring now to Figure 6, an extended representation of a modality of a data integration infrastructure implemented in accordance with
with the principles of the present invention. In this modality, the infrastructure of visual data integration provides the transport of effective and reliable information among any number of disparate applications,
• data, and platforms associated with two or more providers of
information. The information provider # 1, for example, produces data streams of various types which, when processed by the associated adapters, are received by the data exchange infrastructure 62 in a generic or common format. Associated with each of the currents of
The data produced by the information provider # 1 is the control or request for information that is further processed by the data exchange infrastructure 62. The information or the raw data component associated with the control information or request is stored in a data store 64. The data exchange infrastructure 62 cooperates with a routing logic module 66 to determine one or more destination applications within the system environment of the information provider # 2 that require particular data streams from the information provider # 1. It is noted that the content of a particular data stream, such as the data stream Ai, may have been required by more than one information provider application # 2. Assuming that three of these applications within the environment of the information provider systems # 2 have requested all or selected portions of the content of the data stream Ai, three corresponding adapters are used to convert the content of the data stream Ai of a generic format in the corresponding predetermined formats specified for the three target applications. The data exchange infrastructure 62 also cooperates with the business logic module 68 to process the content of one or more streams of data in a particular manner desired by a user. By way of example, an application running within the system environment operated by the information provider # 2 may require data that is derived through the calculation or manipulation of the Bi and Ci data streams produced by the corresponding applications that are run within the system environment operated by information provider # 1. The data exchange infrastructure 62 operates on the data streams Bi and Ci in the manner dictated by the business logic specified by the user stored in the business logic module 68. In contrast to the client infrastructure implemented in accordance with an approach of the prior art, the data exchange architecture illustrated in Figure 6 and in other Figures provides a system administrator or the end user with the ability to modify the routing logic, the business logic or the format of a stream of data / application given without requiring any modification to programs or configurations within the data exchange infrastructure 62. As an example, if an application or format of a particular data stream requires modification, this change can be carried out in the data exchange architecture by simply modifying the interface logic of the adapter involved, typically through the use of the visual interface 61. Yes, by way of another example, a particular data stream produced by information provider # 1 is required by two, rather than one, application within the information provider systems environment # 2, a simple change to the Routing logic 66 and the addition of another adapter can be done to satisfy this additional need. In addition, if new or additional processing is required for a particular data stream in order to satisfy a new need by either a source or target application, a simple change to business logic 68 will satisfy this additional need. These modifications to the routing logic, business logic, and adapter logic can be effected using the visual interface 61. It will be understood that the data exchange infrastructure 62 is typically implemented, but not necessarily in a distributed manner. According to a distributed approach, several components of the routing logic module 66 and the business logic module 68 can be distributed between different logical or physical locations within the infrastructure 62, such as in different work stations, for example. It will be further understood that the data store 64 can also be implemented in a distributed manner, so that the storage elements of the infrastructure 62, such as several queues defined for example, can be stored in different logical or physical infrastructure locations, such as places within different work stations. A distributed data warehouse 64 provides a highly scalable data exchange infrastructure which can be easily implemented within a distributed network system architecture. It will be appreciated by the experienced technician that the cooperation of easily modifiable adapters and one or more processing / logic units of the data exchange infrastructure having routing and user modifiable business logic provides increased scalability, expandability, and flexibility to meet the
current and future information exchange requirements.
• In contrast to conventional interface schemes, an exchange architecture implemented in accordance with the present invention is not subject to fallout, mainly due to its inherent ability to adapt
easily to new and unforeseen applications, platform technologies, data types and formats, and logic and routing requirements. A more detailed description of various aspects of
• an adapter according to one embodiment of this
The invention will now be described with reference to Figures 7 and 10. In Figure 7, several systems, S? -SN, are shown, which may or may not be similar in terms of platform configuration. Each of the systems, S? -SN, implements one or more applications, A? -AN, which produce several
types of data, denoted as D? -DN. As discussed previously, each of the data types has an information content component and a format component, such as the information content component 11 and the format component Fi associated with the data type Di. Each of the adapters 150, 170, 190 includes an interface module 152, 172, 192 and an object converter 154, 174, 194, respectively. As shown in Figure 10, data of the type Di produced by the application Ai, for example, are received 280 by the interface module 152 of the adapter 150. The interface module 152 typically includes a validation module that validates the data. of the type Di received from the application Aj. The object converter 154 converts 282 the information content component Ii of the D type data into a Common Object data structure, COi. The. Reference information, which can be viewed as control or identification information, associated with the Common Object or Common Objects is placed 284 of an input queue of the data exchange infrastructure 132. The data exchange infrastructure 132 processes and / or manipulates 286 the information content Ii of the data type D ^ in the manner required by the business logic module 136. The routing logic 134 is used by the data exchange infrastructure 132 to place 290 the information content processed Ii in one or more selected output queues (not shown). One or more adapters (not shown) that have a structure equivalent to adapter 150 and individually configured for specific target applications convert 290 the information content
• 5 Ii of the common format in an output format specified for 294 transmission to one or more target applications. Figures 8, 9, and 11 provide additional details of various data exchange operations associated with one embodiment of the present invention.
Initially, an adapter, such as adapter 208, receives 300 an externally generated message from an application, such as an Operation Support System (OSS) application, from a destination service provider. The adapter 208 receives 302 the message generated by the system of
operation support. The application interface 208a of the adapter 208 receives the message from the operation support system and the data associated with the operation support system message transmitted from the operating system.
• operation support. The message of the support system of
The operation and / or the associated data is validated and converted 304 into a Common Object representation by the validator / converter 208b of the adapter 208. The application program interface (API) 208c of the adapter 208 represents an interface of the programmer.
the application that allows Common Objects to be easily constructed, manipulated, and queued. After the request has become a Common Object form, the adapter 208 invokes 306 a queuing interface 208d to place the message of the operation support system on the receive queue 240 of the exchange infrastructure. data 202. The information content component or raw data associated with the message of the operation support system is transferred to the data store 201 coupled with the infrastructure of
data exchange 202. It is noted that Figure 8 illustrates the
# distributive capacity of the data exchange infrastructure of the present invention. In particular, the queues 240, 242, 244, 246, 248 and the data store 202 can be distributed in different physical and logical places within the
implementation of the data exchange system, such as in different workstations or processors / memory located in logically or physically distinct locations of the network system. • A processing thread received from the warehouse
processing threads 262 from the port core 204 is implemented 310 to remove any incoming requests by relative priority from the queue. The application program interface for the client-specific rule code is then invoked 312 to process the incoming request in
Compliance with the client-specific business rules received from rule module 232. After the business rules have been applied, requests to one or more applications of the operation support system are then routed to a queue 316 of corresponding shipping 242, 244, 246 for delivery. An adapter, such as the adapter 218, associated with a destination operation support system may then invoke an application program interface to remove from the corresponding queue 318 associated with its corresponding send queue 244. The application program interface 218b and the converter 218c cooperate to convert 320 the required information represented in the Common Object form to a format and structure specified by the particular operation support system. The converted data is then transmitted from the application interface 218d of the adapter 218 to its corresponding operation support systems. Figures 12-14 provide additional processing details that relate to the transport of data through the use of a data exchange infrastructure in accordance with an embodiment of the present invention. As shown in Figure 12, a data packet 332 is received from an external source. The received data then undergoes a validation process 334. If the data is considered corrupt 336, an error is verified in the data packet received from the external source 338, and, in response, 340 is removed or deleted for the purposes of post processing. If the data from the external source is determined to be valid 336, then a data exchange transaction 342 is initiated. The data received from the external source is then packed 344 into a Common Object according to the metadata rules and they are identified using a unique name or label. The Common Object is queued 346 in the input queue of the data exchange infrastructure. The data exchange transaction is then committed. If the transaction is not successful 350, a return loop of transaction 352 is then initiated. If the transaction is successful 350, the data packet of the external data source is removed or deleted 354. The process described above is repeated for the subsequent data packets received from the external source 332. Referring now to Figure 13, further details concerning the data exchange transaction will now be described. When a data exchange transaction is started 362, a hierarchy scheme is used to remove from the queue 364 the next Common Object of the incoming queue of the data exchange infrastructure. During the queue operation, the client rule / route application program interface associated with the Common Object is called 366. If the client rules are successfully applied 368, another data exchange transaction is started 362 If the client's rules can not be applied successfully 368, the exchange infrastructure
• Data 370 determines the default routing of the Common Object to 5 from the configuration routing table. If the routing has not previously been defined 372, the Common Object is queued 374 in an error queue. If the routing has been previously defined 372, the Common Object, or a clone of the Common Object without more than one operation to put in
queue is applicable, it is queued in every output queue identified in the routing table. The data exchange transaction is then committed 378 and if 380 is successful, the associated data packet is removed or deleted 384 from the external data source. If the transaction of
data exchange is unsuccessful 380, the new turn of transaction 382 is started. A subsequent data exchange transaction 362 is then initiated. Additional steps associated with taking the queue out of the queue
• Common Object is shown in Figure 14. Assuming that a
When the data exchange transaction is started 392, the data exchange infrastructure moves from queue 394 to the next Priority Common Object from a configured output queue. The data associated with the Common Object in the output queue is then validated 396 and packaged in a
specific structure having a format and a name Also shown in Figure 9 is a statistics monitoring module 264 and an associated statistics record 276 that are used to provide monitoring and tracking of data as they move through the system and exchange of data. The statistics monitoring module 264 also provides historical performance information on queues and historical information on the use of system resources. The statistics monitoring module 264 provides a means to record and track a given application. The record reveals the status of the application at the time of an error, while the trace provides a description of all software events as they are presented. The tracking information can be used to track the application, status, and other related operations. The trace information can be used together with the registration information to determine the cause of an error as it provides information about the sequence of events before an error. Having previously discussed various embodiments of a data transport mechanism within the context of the present invention, a description of a visual interface implemented in accordance with the principles of the present invention will now be provided in greater detail. Figures 15 and 16 are conceptual models of a visual data integration architecture employing a transport structure 502, the visual interface 501, which is appropriate for the destination external data source or output. If the validation process is not successful 398, then the data is considered corruptive and the Common Object is queued 400 in the error queue. If the data is valid 398, the external data packet is transmitted 402 to the external data source of output or destination. The data exchange transaction is committed 404 and if 406 is successfully considered, a subsequent data exchange transaction 392 is started. If it is unsuccessful, the transaction is returned to again 408 by the infrastructure exchange. Referring again to Figure 9, a processing thread store 262 stores several processing threads that are selectively implemented when performing operations to remove from the queue. The processing thread deposit 262 represents a thread deposit whose number is controlled externally. Its function is to provide a control thread for the logical portions of the system's client. One or more processing threads control the exiting of the request queue, the invocation of the rule / routing application application program interface, and the queuing of the send requests. A processing thread can make use of additional system resources, including persistent storage 268, write to and read from error queue 272, and write to an error log 274.
configuration structure and runtime information 503, and one or more business extension modules 505 implemented in accordance with one embodiment of the present invention. As discussed previously, transport structure 502 provides a technology-dependent integration mechanism that allows reliable and scalable information routing between different applications and technologies. The visual interface 501 allows the rapid design, deployment and control of execution time and business analysis and aspects of the system of an integrated information system implementation. An underlying configuration and runtime information structure 503 cooperatively cooperate with the visual interface 501 and the transport structure 502 to effectively transform the graphic interconnections established between the components of the system using the visual interface 501 in logical or physical interconnections, which results in the contemporary generation of an integrated runtime system deployment. The complexity of conventional integration approaches and the general inability to integrate available businesses and systems integration tools greatly complicates the effort to provide and maintain consistency in an integrated information system design. For example, existing data integration tools typically focus on horizontal technical aspects of system integration. Existing business tools typically focus on addressing the problems of horizontal business integration, such as meeting business needs using information derived from data held within the information system. A conventional approach to designing an integrated information system usually involves solving technical / system integration problems before, and often with little relation to, addressing business integration objectives. As such, system and business integration efforts often progress along separate development paths in a manner dictated by different design objectives. The consistency of vertical integration, which is critical for an integrated solution with complete success, is generally impractical if not impossible to achieve using an additional systems integration approach. A visual integration system developed in accordance with the present invention advantageously harmonizes the system integration / administration requirements of a given business problem using data integration consisting of a system development methodology. The configuration and information structure of execution time 503 and transport structure 501 of the present invention provide consistent vertical and horizontal system and business integration. The visual interface 501 of the present invention provides high level modeling of an integrated information system, wherein both the business 5 and the technical aspects of a system design can be jointly represented, created and controlled. Business extensions 505 represent business functionality modules that can be used in visual interface 501 to provide integration capabilities of
specific businesses. The business extension module # 1, f for example, can include a set of components that make legacy applications available through Internet-type technologies. The components of the business extension module # 1 allow the easy creation of interfaces of
standardized web search engines for existing applications without changing or affecting the application. Interfaces of multiple users can easily be created using the components of business extension module # 1. The adapters associated with the components of the module
business extension # 1 may include the following: screen scraper adapters (for example, Telnet,
HTTP / SHTTP, IBM 3270, VTXXX, and HP700 / 9X); Network adapters
(for example, CGI, HTML); file adapters (for example, ASCII); mail / caller / fax adapters (for
example, SMTP, MIME, SMS); printer / fax adapters (for example, LP, Printserver); write adapters (for example, Shell, Perl, Batch); and JAVA adapters (for example, JAVASCRIPT).
• The business extension module # 2, as a further example, can include a set of components that provide full database interface capabilities. The adapters associated with the components of the business extension module # 2 may include the following: certified adapters with Oracle and SQL server;
adapters for any ODBC; and adapters for X / Open.XA. The business extension module # 3 can include a set of components that add internalization capabilities to an application allowing, through suitable adapters, the storage of data in the
following internationalized character sets: UTF-8 up to 7-bit ASCII conversions; UTF-8 up to 8-bit ASCII conversions; UTF-8 up to 16/32 bit UNICODE conversions; and UTF-8 up to 5-bit BAUDOT conversions. The
• adapters can provide ITU compliance and support
international letters. The business extension module # 2 can also provide a visual message catalog / publisher capability generator. The business extension module # 4 may include a set of components that provide the construction of
sophisticated network management interfaces. The components and adapters of the business extension module
# 4 can, for example, provide management capabilities of TMN (telecommunication network management) services, such as management-level service agreements, to provide interaction with service providers, and maintain interconnections between services. TMN business management capabilities can be provided, such as inter-operator management agreements. Monitoring systems can be developed without altering existing applications for several purposes, including: OSS access verification for local / long-distance service providers; ensure interfacing with standards-based network management products (eg, HP OpenView, ADC Metric, and ADC INMG); identify bottlenecks of the system; and verify system-to-system equivalence and business process improvements. Other capabilities may include implementing visual alarm level setting tools and visual tuning interfaces. The business extension module # 5 can include a set of components that allows the complete integration or componentization of any system or interface MICROSOFT
WINDOWS. The components and adapters of business extension module # 5 can provide the following capabilities: conversion of single-user WINDOWS applications to distributed applications of multiple users; connect to WINDOWS applications via the Internet or any other protocol mechanism; and the sophisticated automation of WINDOWS application interfaces, including controlled logic responses, dialog boxes control, heuristic adaptive agent interfaces, and ActiveX connection. The business extension module # 6 may include a set of components that provide the development of e-commerce interfaces (ie, E-commerce). The adapters associated with the business extension module components # 6 may include the following: EDI adapters to support various EDI dialects; and security control adapters to provide user verification and access authorization, cryptically encoded transactions, non-repudiation of complete transactions, and control of system access and transactions. The business extension module # 7 may include a set of components that provide for the construction of sophisticated business management interfaces. The components and adapters of the business extension module # 7 can provide the transaction representation of the end-to-end visual system and the development of interfaces of the visual billing system. A visual user interface rules controller can be developed that provides the following capabilities: routing definition and control and data mapping; construction of metadata model to provide structural definition of complex objects and mapping to external systems; and convergence / composition of
• data. The components and adapters of business extension module # 7 can also provide the development of external visual monitoring record, including the ability to define data structures and components that are to be archived for external monitoring purposes, and the development of an external supervision record reporter.
Other capabilities may include the development of converters
• Common Object data exchange and backup generators (for example, ASN1, IDL, and GDMO). The business extension module # 8 may include a set of components and adapters that provide the
development of workflow interface, including workflow interfaces based on standards. Other capabilities may include support for various workflow systems and process management and control of multiple visual part rules. 20 The business extension module # 9 may include a set of components and adapters that allow the complete integration or componentization of any system or interface. The business extension module # 9 can represent a comprehensive toolkit that
provide the creation of data exchange adapters for easy integration with intermediate software systems. The platforms supported through the use of business extension module # 9 may include, for example, Visual C ++ 5.0 or higher of MICROSOFT, HP ANSI C ++, and SUN C ++ Wor shop 5 Compiler 4.2 or later. The comprehensive toolkit also allows integration with CORBA, DCOM, and TMN (CMIP, CMIS), and includes programming interface libraries with IPC for FORTRAN and COBOL. A common object file translator, common object packer source code, and code
adapter guard source can also be included in
• the comprehensive toolkit of the business extension module # 9. A set of deployment examples is typically included with each of the extension modules of
business A typical deployment example leads a user through the design and deployment phases of a hypothetical system integration scenario such as a tutorial or introduction to the characteristics and capabilities of a module
• Private business extension. The use of business extension modules in cooperation with the configuration and runtime information structure 503, the visual interface 501, and the transport structure 502 provide a very flexible, albeit consistent, approach to implementing a system of
integrated information that satisfies both system integration and business requirements. Because there is no direct dependency between structures 501, 503 and business extension components 505, it can be developed
And deploying an integrated information system using a transport structure 502 different from the data exchange infrastructure structure of the adapter described hereinafter in detail. The absence of a direct dependency between structures 501, 503 and business extension components 505 also provides the
development and deployment of an integrated information system
• without requiring the use of the visual interface 501, such as manually configuring the system. In general, the visual interface 501 provides a visual structure within which all aspects of
configuration, deployment and execution time of a design or deployment of the information system can be accessed. The visual interface 501 provides a user with the ability to graphically construct an information system and effect physical connectivity between storage, processing, and
information transmission components so that an integrated information system is implemented graphically and physically. In accordance with the embodiment shown in Figure 17, the visual interface 501 includes a 540 count that
represents the main area of the visual interface 501 where the data integration displays are constructed and managed. A system selection button 532 provides the user with the ability to select among various deployments or information system projects. A business extension selection button 533 provides the user with the selection of any of the different business extension modules 505 that are made available to the user. Business extension modules purchased by a user are typically loaded into the system and automatically
are available when properly selected using
• the business extension selection button 533. For example, the palette 530 shown in Figure 17 includes a set of components / adapters that are part of the business extension module # 1 shown in Figure 16.
discussed previously, these components / adapters provide access to legacy applications through the use of Internet-like technologies. The selection of business extension module # 1 by the user is indicated by the
• "Internet" status of the extension selection button
business 533. Pressing a business extension module by selecting using the 533 selection button results in displaying the constituent components / adapters associated with the selected business extension module.
Each of the components or adapters that constitute a given business extension module is represented as an icon / button on the 530 palette. In Figure 17, for example, the contents of the legacy-to-business extension module. Internet displayed in the form of an icon on the 530 palette includes adapters for HTML 534 response, HTML 536 formatter, e-mail 538, FTP (file transfer protocol) 539, and fax 542. The 530 palette is provided with a rolled-up bar that accesses adapters that are not currently displayed in the available space of the palette 530. The upper area 542 of the visual interface 501 contains an animated logo 543 for the data integration tool. This logo 543 becomes animated when the system is running, thereby providing an easily perceptible indication of the system's status. Area 545 to the left of the 543 logo is available for toolbars that are considered necessary or desirable. A toolbar can be developed to provide a shortcut to the desired primary menu items. Each button of a toolbar included within the upper area 545 generally provides indications of highlighting tools associated with it. In the lower left corner of the visual interface 501 is an Xchange 544 button. Activating the Xchange 544 button opens a menu that flows from common system commands and configuration controls. A first group of menu buttons, which can be accessed via a properly configured toolbar or by activating the Xchange 544 button, can operate on project files, and include the following activable buttons: new, open, save , delete, and print. A second group of buttons may include starting, shutting down, pausing and resuming system buttons, for example. Menu items can be disabled when their operation is not appropriate for a given context. The lower limit 546 of the visual interface 501 is available for high level status information and for help tips that may be useful during configuration. The scrolling 540 of the visual interface 501 includes four tags 520, 522, 524, 526 to activate four different available views of an information system project. The four activatable views using the tags 520, 522, 524, 526 include System Integration, Business Integration, System Administration, and Business Administration views, respectively. The System Integration view, which can be activated using tab 520, provides the capability using drag and drop techniques to visually build and configure a data integration implementation using a palette of material integration adapters typically packaged as part of a business extension module. Figure 18 illustrates a data integration implementation as seen using the System Integration view. The Business Integration view, which can be
• Activate using tag 522, allows an integration of 5 implementation data that will be adapted to the client with business analysis capabilities and external supervision using business oriented adapters. Figure 20 illustrates the data integration implementation of Figure 18 as seen using the Business Integration view. 10 The System Administration view, which can be
»Activate using tag 524, provides a view on the runtime status of a data integration implementation, allowing system production and bottlenecks to be examined and analyzed. The runtime environment of a data integration implementation can be examined and analyzed using visual diagrams and maintenance plug-in modules. Figure 21 illustrates the data integration implementation of
• Figure 18 view using the Administration view of the System. The Business Administration view, which is activated using the 526 tag, allows the business manager to analyze information trends and review external monitoring records derived from the data that passes through the system using plug-in diagrams. Figure 22 illustrates the data integration implementation of Figure 18 as seen using the Business Administration view. Pressing one of the tags 520, 522, 524, 526 alters the information displayed in the count 540 and the operations were performed in the 540 count as appropriate for the selected view. For example, a double oppression on an adapter in the System Integration view (for example, see Figure 18), results in the deployment of a configuration utility invoked for the selected adapter. In contrast, selecting the same adapter when the System Administration view (for example, see Figure 21) is active results in the deployment of any runtime errors associated with the adapter. By providing different views within an integrated visual structure, the vertical consistency of the system and the business layers of the integrated data solution is maintained. The functionality of the visual interface 501 is extensible through the use of plugged and administration components. execution time. A variety of plug components can be installed in the form of business extension modules focused on solutions or as stand-alone elements. The plugged-in components can also be used in stand-alone mode outside the data integration structure for purposes of resolving individual user requirements. A particular user, for example, may only wish to see a specific diagram, and running the complete visual interface 501 to obtain a single diagram may be an unnecessary burden. In such a case, the diagram plug component can be decoupled from the visual interface 501 and placed either in a separate execution applet or included as part of a personal network page, for example. As best depicted in Figures 15 and 16, the visual interface 501 can be seen as constituting a thin-walled interface layer built on a well-defined runtime configuration and information structure 503. The configuration and information structure runtime 503 provides a level of indirection between the visual interface 501 and the underlying business extension modules 505 and the transport structure technology 502. By removing dependencies through these layers, this indirection provides a significant degree of flexibility with respect to the way in which the different components are implemented and interconnected in a given data integration solution. The configuration and runtime information structure 503 controls the adapters that are available for use in a given data integration deployment. Structure 503 also controls adapters that are configured as active adapters in a given deployment, along with its actual configuration. The structural design of the data integration display, such as the particular queues that are being used to allow the data to flow between the selected adapters, is also controlled by the configuration structure and runtime information 503. The structure 503 also it is used to control the definition of the metamodel that is being used by each adapter, and the mappings of the metamodels between adapters. As previously discussed, the metamodels represent neutral format models of the input and output data requirements of the disparate systems of a data integration project. The use of metamodels removes any cross-dependency that exists between the different systems and technologies involved in the data integration project, and allows the establishment and modification of interconnections between system components using visual drag and drop metaphors and mapping of metamodels . When the visual interface 501 is being used either in the System Integration or Business Integration view mode, the actions within the visual interface 501 result in the corresponding adjustments to various configuration scenarios. These configuration scenarios, in turn, are read by the applicable business extension modules 505 and the transport structure 502 during the execution time to specify how a particular deployment will operate. During the execution time, the business extension modules 505 and the transport structure 502 also record in the configuration structure and runtime information 503 the information or references to the information that is being transported through the system. integrated information. For example, if the data exchange infrastructure 32 and adapters 34 shown in the embodiment of Figure 1 constitute the transport structure 502 shown in Figures 15 and 16, then the transport information would be recorded in the queues and the storage warehouse. common object of the data exchange structure. Also recorded in the configuration structure and runtime information 503 are the error logs, the performance of execution time and production information, and the data and business information with external supervision that will be used for records. legal or trend analysis / statistics. The exact nature of the information recorded in the configuration structure and runtime information 503 is typically controlled by the configuration scenarios. This information can be viewed graphically using the different visual interface plug utilities and the diagram applications either in the Systems Administration or Business Administration views. Figures 25A-25C define a structure of • fc directory of the configuration structure and runtime information 503 within which the configuration files are placed and manipulated according to an embodiment of the present invention. Examples # 3 - # 5 provided later in this document provide the contents of various configuration files in accordance with
this modality. The first three types of files of
^ Q settings are project files (see Example # 3), component instance configuration files (see
Example # 4), and component configuration files (see
Example # 5). Typically there is an associated project file
with each data integration implementation. The project file contains the top-level definition of the adapters that are part of the data integration implementation and defines how the adapters are
^) structurally connected to each other. Included in the file
of the project there are references to the component and component instance configuration files of a given deployment. The information in the project file is used by the visual interface 501 to return a data integration implementation image on its 540 count. 25 Typically there is a component configuration file for each adapter that has been installed. It is noted that if a particular adapter is used more than once in a data integration project or in multiple projects, there is still only one component configuration file associated with the particular adapter. The component configuration file contains a definition of how the adapter participates in the data integration implementation. For example, the component configuration file contains information such as the definition of adapter integration capabilities, for example, the number of input queues read by the adapter and the number of output queues to which the adapter can write . Other information contained in the component configuration file includes the commands used to run, stop and pause the adapter, operations that must be performed when a user double-clicks the adapter icon on the different views, and the default configuration of the adapter . Typically, there is a component instance configuration file for each instance of the adapter used in a given data integration implementation. The instance configuration contains individual configuration scenarios for that instance of the adapter. The component configuration files provide the capability of adapters to be fully defined as plug-in components in the visual interface 501 and the transport structure 502. Neither the visual interface 501 nor the transport structure 502 need to be implemented with full knowledge of all the adapters that can possibly be developed in the future. The adapters, how and when they were created, can simply be installed in the existing directory and the configuration structure in order to become usable components in the data integration project. This allows the data integration approach of the present invention to be highly extensible. Additionally, customer adapters can be developed in a way that conforms to the standard design and configuration. These client adapters can then be used and reused in projects in the same way as standard adapters. This is particularly significant as it is believed that few robust deployments can be completed with some degree of client adaptation. A centralized store of all project files is defined in the configuration structure and runtime information 503. When a new data integration project is being started, a default project file is created. Typically a menu is presented to the user. An open menu item can be activated by the user to invoke a file selection dialog in order to load an existing project file. It is noted that only one data integration project can be opened typically at the same time. When a user changes to another project, it highlights a dialog to request if the user would like to save any changes made to the current project. A delete item is enabled only when a project is selected. The print menu button is made available only when a project is deployed on scrutiny 540 of the visual interface 501. As previously discussed with respect to the Figure
17, the design of a data integration project is defined within the 540 scrutiny of the visual interface 501. The views of System Integration and Business Integration are used mainly for the design of data integration. The 530 palette is populated with suitable business extension modules and associated adapters when each of these views is activated. When using the System Integration view, the components that populate the 503 palette represent adapters of a technical nature that are used to integrate the technologies and protocols of the different elements of the system. When the Business Integration view is used, the components that populate the palette 503 represent adapters directed to the external supervision, processing, and analysis of the business information. The adapters and components that are made available to the user are determined by the visual interface 501 at the same time that the contents of the component directory are examined (see, for example, Figures 25A-25C). In typical use, the user designs a data integration project when the system integration view is activated by selecting several adapters and components deployed in the palette 530 of the visual interface 501. This is accomplished by dragging selected adapters from the 530 palette and leaving them on the 540 count using a mouse or other input device. This operation results in the creation of a new entry for the selected adapter in the project file, and additionally, results in the creation of an instance configuration file in the project directory using a copy of the default derived configuration of the component configuration file. After two or more adapters or components have been moved to scrub 540, the selected adapters / components can be linked together by pulling the mouse with the depressed key of the source adapter to the destination adapter. The component configuration files associated with the source and destination adapters are verified to ensure that this new connection will be valid and will not exceed the maximum number of source adapter outputs or the maximum number of entries of the target adapter. Assuming that the new connection is valid, an arrow connecting the two adapters is pulled. A unique queue name is created for the connection, and the instance configuration files for the project and two adapters are updated to include the name of the newly created queue. By connecting two or more adapters together with a tail, a communication channel is created between the adapters. However, in order for the connection to be valid, it is additionally important to confirm whether the information passed through the queue is understood at the destination to ensure that the source and destination adapters communicate effectively. Confirming the integrity of the communication channel established between two adapters is carried out by comparing the metadata models of the source and destination adapters and determining if the models are compatible. As will be described later in greater detail, an adapter has associated with it a defined input and output metadata model that indicates the data that the adapter is waiting to receive and dispatch. By comparing the metadata models of two connected adapters, it is possible to determine if the two metadata models are compatible. If the two metadata models are determined to be incompatible, the two adapters in question are visually marked at scrutiny 540 to indicate the presence of a configuration error, such a warning. In order to rectify a configuration error, a user can double-click on the adapters involved either in any of the Integration views of
• 5 Systems or Business in order to display configuration screens associated with each of the adapters. The actions carried out, and the application launched, as a result of the double oppression are defined in the component configuration file for each of the four
views. If there is no configuration application or
• applet for a particular adapter, a default configuration applet will be launched. The user can alter a defined metamodel of the adapter using the configuration screens associated with the adapter. For example, him
Metamodel of an ODBC adapter can be modified by changing the SQL statement of the adapter in order to alter the data need for the SQL query, thereby changing the results generated by the SQL query. • Configuring the adapters in this way, the
incompatibilities that exist or arise between two or more interconnected adapters can be rectified. If, for example, the incompatibilities are caused simply because different labels are used for the same data field for the interconnected adapters, then a
visual mapping tool can be launched to define the mapping between two labels to face this problem. The default configuration application can also be used to change the adapter / component icon labels. An icon has a separate label for Business views and System views to allow adequate explanations to be displayed for different users. The configuration application can be used to modify the adapter labels, as well as several standard adapter settings adapted to the client. After the metadata model problems have been resolved, a valid data integration link is created between the two adapters. By repeating the design process described above with multiple adapters, a complex multi-component data integration implementation can be constructed. After all adapter instances have been created, all necessary links have been established, and configuration errors have been resolved, the integrated information system is ready for operation at runtime. The views of the Administration and Business Administration System, respectively shown in Figures 21 and 22, are typically used to control the operation at the time of execution of a data integration project. The transport structure 502 collects output information of several queues that can be displayed in a graphics application by double-clicking on a selected queue while in the System Administration view. The content of a specific queue can be managed by correct oppression on a queue and by selecting Queue Management from the menu. Double oppression on a selected adapter while in the System Administration view the configuration screen for the adapter is displayed. Settings to the configuration scenarios of a selected adapter are saved by the configuration or applet application to the appropriate instance configuration file, and these configuration scenarios are adjusted during runtime in response to a configuration reset signal received by the selected adapter. The Business Administration view is mainly used to graph statistical analysis carried out by the business extension modules. Double oppression on a component, such as the Business Analysis component, results in the display of information trend graphs and distributions associated with the Business Analysis component. The integration of data across multiple platforms and multiple work stations is coordinated through the use of a distribution planning facility. Activating the Xchange button 544 results in the presentation of a menu item that allows the user to invoke a distribution planning panel. The distribution planning panel 550, a modality of which is shown in Figure 19, includes a panel 552 that provides a tree view of a network environment currently in operation for a selected data integration project. Each node in the first level 554 of the tree represents the name of a project. The knots of the second level 556 under the 554 project nodes indicate the names of the work stations over which specified components are operating. A third knot level 558 indicates the different components that operate in a particular workstation. A fourth node level 560 indicates details of either component elements or queues defined at a third node level 558. For example, the components shown in panel 552 of Figure 19 include six individual adapters, namely, CGI, ODBC , Mail, Printer, Caller, and Monitor Adapters. The monitor adapter represents a monitoring process knot that typically differs from the other adapter knots in terms of color or typeface. It is noted that the mapping of the network file system used to access remote machines is typically fixed by a system administrator outside the visual interface environment.
The distribution planning panel 550 retrieves and stores information from the project file. The scrolling 540 of the main visual interface panel 501 also uses the project file. In this regard, the distribution planning panel 550 and scrutiny 540 of the manual visual interface panel 501 represents the same display from two different perspectives. The distribution planning panel 550 is used from the global navigation point of view, while the scrutiny 540 of the main visual interface panel 501 is used from the data flow point of view. The right portion of the distribution planning panel 550 includes a property sheet 562 that is used to display the data associated with a selected article. More specifically, property sheet 562 represents configuration data, error / alert record information, and a performance data chart for a component process or monitoring process. For example, the property sheet of a selected queue displays various queue properties, including queue contents in a table format and queue monitoring data in a graphical format. Certain data, such as error / alert records, performance data graphs, queue views, and queue monitoring data, presented on property sheets 562 are read-only deployments. The operations that a user can perform using the property sheet 562 include, for example, deleting a queue entry from a queue, disappearing a queue, changing a configuration of a component, changing the configuration for
• tail monitoring. 5 The functional reporting and information graphics area of the distribution planning panel 550 provides the ability for users to easily see and analyze the substantial amount of technical and business data collected by the system. A graphic module is
implements to read the monitor record files of
• Performance and generates basic system administration queues graphs. The graphing module also reads the statistical report files and generates basic business administration statistics graphs. The graphics module
is able to perform several other tasks, including deployment graphs, take snapshots of report files periodically, and dynamically update the graphs. The time interval for updating graphics is configurable. Before a graph is displayed, a
The configuration form appears to allow the entry of various parameters configurable by the user, such as parameters associated with graph ranges and measurement frequency. A graph is generated using the user's configurable parameters. 25 Each adapter process has a set of log files generated for performance monitoring purposes. The performance monitoring log files for the adapter processes are stored in a previously defined directory, such as the one represented in Figures 25A-25C. The data stored in each performance monitoring log file that allows graphs to be carried out includes the following: time stamp, number of data items queued in a time interval by priority, number of data items taken out of the queue in a time interval by priority, an average message processing time in a time interval by priority, and an average message instant memory time in a time interval by priority data. Performance monitor log files are generated by adapters when a monitor flag is ON. The data used to produce statistical reports based on business information include data of time stamp and data with respect to attribute value and number of occurrence in pairs in a time interval. A statistics report, such as the one shown in Figure 22, is generated using a business statistics adapter. The report is typically based on attributes. The reporting time interval is configured in the business statistics adapter. All statistics reports are stored in a previously defined directory, such as the one represented in Figures 25A-25C. The graphics are typically configurable by the user. During a graphing operation, a form of graph configuration is presented to the user. For graphics of
• 5 queues, the configurable parameters include the deployment period, although established periods are available to simplify the graph configuration procedure. For business statistics graphs, configurable parameters include attribute name, value list,
attribute, and deployment period. It is noted that the value of
• Configuration parameters are passed to the graph generation function. In one mode, the graphs are generated using JAVA AWT 1.1 and JFC 1.1. A graph typically unfolds in a window
of frame, which can be adjusted to the size with the use of horizontal scroll bars. A panel with a tab is used to display the different subpanels, each of which with its own file folder style tab. Each subpanel represents a type of diagram. The subpanel can be
repaint. The diagram is typically displayed in color. The color legend is displayed on the right side of the panel. If the diagram is updated dynamically, the time stamp of the diagram is displayed in the upper left corner of the panel. A renewal button can be provided for
refresh the diagram on request.
When the visual interface 501 is in the System Administration view mode, double oppression in a queue link will create the diagram application in a separate thread.
• A configuration form highlights by requesting a period of 5 user deployment. When the "ACCEPT" button in the configuration form is pressed, the configuration form disappears and the diagram window stands out. The menu selections for the diagrams related to the system, as shown in menu 525 of Figure 21, include the total of
queued, the queue speed, the distribution, the total queue removed, the queue removed speed, and the back register. The default diagram is the diagram of the total queue, an example of which is presented in Figure 21. 15 When the visual interface 501 is in the Business Administration view mode, double oppression in the statistical analysis adapter will create the application of diagrams in a separate thread. One way of configuration
• highlights by asking the user for a deployment period, name
attribute, and list of value. When the "ACCEPT" button in the configuration form is pressed, the configuration form disappears and the diagram window highlights. Menu selections for business-related diagrams, as shown in menu 527 of Figure 22, include Trend and
Distribution. The default diagram is Trend.
DrawEnqGraph (Qname, displayPeriod) DrawDeQGraph (Qname, displayPeriod) DrawBackLog (Qname, displayPeriod)
• } public void DrawBusinessManagementViewWindowO. { Construct the configuration form Construct the tabbed pane with tabs: "Trend", "Distribution", the subpanel by
omission is • "Trend" The subpanels are: DrawTrendGraph (attrName, displayPeriod) DrawDistributionGraph (attrName,
displayPeriod, char valueList [])
} The calculations related to the diagram and the deployment operations involved in Example # 1 above are carried out as follows. DrawEnQGraph searches for all performance monitor reports from the queue in the monitor log directory, reads each file, finds the time stamp column and the enQMsgNum column, performs the sum 25 over the column in QMsgNum, and saves the string of time and in QMsgNum in a two-dimensional array in memory. The graph is generated from the data of the two-dimensional array. • DrawDeQGraph searches for all 5 performance monitoring reports from the queue in the monitor log directory, reads each file, looks for the time stamp column and the column for the MMSgNum, performs the sum in the MsgNum column, and saves the time chain and the processedMsgNum in a two-dimensional array in memory.
The graph is generated from the two-dimensional array data. EGetQBackLog searches for all performance monitoring reports from the queue in the monitor log directory, reads each file, looks for the time stamp column and the
column of cachedMsgNum, performs the sum of the column cachedMsgNum, and saves the time string and the cachedMsgNum in a two-dimensional array in memory. The graph is generated from the two-dimensional array data.
• EgetQPerformance searches for all reports of
tail performance monitoring in the monitor log directory, read each file, find the time stamp column and the msgProcessNum column, perform the sum in the msgProcessNum column, and save the time string and the msgProcessNum in a two-dimensional arrangement in memory.
The graph is generated from the data of the two-dimensional array. EgetSpaceUsage reads in any of the system information reports from the queue in the monitor log directory, finds the time stamp column, and saves the
# 5 data entries that fall within the specified time period in a two-dimensional array in memory. The graph is generated from the two-dimensional array data. EgetlncomingRate searches for all reports of
monitor the performance of the queue in the monitor log directory, read each file, find the time stamp column and the enQMsgNum column, perform a speed calculation on the column in QMsgNum, and save the time string and velocity of enQMsgNum in a two-dimensional array in
the memory. The graph is generated from the data of the two-dimensional array. EoutgoingRate searches for all performance monitor reports from the queue in the monitor log directory,
• Read each file, look for the time stamp column and the
Column of processedMsgNum, performs a speed calculation on the MsgNum-built column, and saves the time-chain and velocity of MsgNum-processed in a two-dimensional array in memory. The graph is generated from the data of the two-dimensional array. 25 The Trend function performs the following operations: it reads the statistics report, applies a filter, and generates the graph. The statistics report provides the time stamp, the attribute name and the number of occurrence data. The Distribution function performs the following operations: read the statistics report, apply a filter, and generate the graph. The statistics report provides time stamp, attribute name, and number of occurrence data. For the purposes of system administration, access to the content of the queues is made available to the user. When a queue is seen, records contained within different priorities of a queue are displayed as shown in Figures 23 and 24. Priority-based queuing is provided so that requests of high importance can be dealt with quickly. Multiple queues are used to provide this level of functionality, but the implementation is logically transparent to the user. A user perceives that there is only one logical queue with objects of different priority in it. The file or database storage tables for the queue are created at runtime and are cleared by the queue management process. There are four types of pre-defined queue priority: NO URGENT; NORMAL; URGENT; and INTERACTIVE in order to increase the priority. INTERACTIVE is the highest priority, which can block any request that has other priorities. The priority algorithm ensures that the queue operation always returns successfully when the queue is not empty, avoids the depletion of lower priority entries, and ensures 5 more frequent visits in higher priority queues. The priority algorithm is implemented on a weighting basis of each priority. The available operations of the dialog associated with the queue deployments shown in Figures 23 and 24
include deleting an entry from a queue, moving an entry from
# one queue to another, and display the contents of an entry, such as the common queued object shown in Figure 24. The queue management utility, including the queue view displays shown in Figures 23 and 24,
allows the user to adjust, correct, or otherwise modify the content of a common object. The configuration of the visual data integration system according to the present invention is facilitated to
• through the use of a configuration application. A
The default configuration application is made available to create a configuration dialog to obtain and fix the configuration for adapters and components. This default configuration application is used when a client dialog for an adapter is not available. 25 The configuration application reads the configuration file and dynamically builds a configuration form based on an SMI file. The configuration form is constructed in a generic form of two columns. The column on the left of the configuration form is used to display parameter name labels. The column on the right is used to display the value of the parameter. The value of the parameter is pre-loaded with a default value or the present value if it exists. The mechanism used to avoid the parameter can be selected from a range of existing radio buttons, lists that fall down, and edit boxes as defined by the SMI file. For each workstation that participates in the data integration project, there should generally be a monitoring process that runs as Daemon on it on a continuous basis. This monitoring process should be able to monitor all the processes of components that are executed or that should be executed in a work station for the given project. The monitoring process should read the project file to determine all the component processes that should be executed on the workstation, and how to execute the process, such as on a daily, weekly or monthly basis for example. Each component process that runs on the workstation is recorded with the monitoring process. It is desirable that the monitoring process be able to initiate and close any instance of a user's request process. The monitoring process is typically a process of
• multiple strands. A thread is implemented to monitor all the adapter processes registered with it. Another strand is implemented to listen to requests coming from, for example, the JAVA graphical user interface. An implementation involves sending the requests via a system administration queue. Alternatively, the communication
can be done through the use of a protocol type soquets. If this approach is taken according to a modality, the process must understand both JAVA and C ++. An approach to implement this process involves using either native JAVA interface (JNI), which can integrate the native C ++ code into
JAVA, or the use of user datagram protocol soquets (ÚDP). For distribution purposes, the solution of baseball is preferred. According to this approach, when a project is opened in the JAVA GUI at run time, the
JAVA GUI establishes a UDP sóquet accessible to all monitoring processes through the work stations of a given data integration project. The JAVA GUI then controls each of the components via the monitoring process layer. 25 As discussed above, a metamodel approach is made to provide a broad specification of object system and content attribute definitions that can be used to illustrate object design, object instances, and provide translation of a class 5 metadefinida in another. Each adapter accepts data in a specific metamodel definition, manipulates the data, and produces output data in a new metamodel definition. By comparing the input and output metamodels of two interconnected adapters, it is possible to determine if the data
exchanged between the adapters are valid.
• Minor consistencies in the data requirements of two communication adapters can be adjusted by defining mappings between the two data metamodels. In severe compatibilities between definitions of metamodels are indicative
of more fundamental data problems that may require some degree of redesign to correct. The use of a metamodel approach allows the validity of a data integration implementation that is verified, errors that are highlighted,
• and problems that are corrected. 20 Metamodel storage is typically implemented using a file-based approach that advantageously removes any dependency on a particular database technology. Each object definition is contained in a separate file in order to
isolate its definition and eliminate confusion between multiple definitions and objects. Each class defined by goal is stored in a separate file that is named using a class plus some extension convention. The content should be displayed as a structure as flat as possible. 5 Each attribute consists of a single line that includes its name, type and behavioral characteristics. Each line that represents an attribute can conform to the following design: NAME | DX_DATOTIPO | REQUIREMENT | RANGE (optional) j default value (optional) 10 As another example, it is provided immediately
# a sample configuration of an object class named Client: CustomerName | DX_STRING jMANDATORY 256 Bank DX_STRING MANDATORY 256"Bank of Rico" 15 Account Number DX_INTEGER MANDATORY 0-9999999J Balance | DX_REAL | OPTIONAL | | 0 The following example is provided using the Client object class defined above: • CustomerName DX_STRING ¡MANDATORY ¡¡20 CuentaLista ¡DX_LISTOBJECT ¡MANDATORY | | BEGIN Account Number | DX_INTEGER | ANDATORY 0-9999999J Balance! DX REAL I OPTIONAL! I END: 25 Savings Account DX COMMONOBJECT I MANDATORY 0-9999999J BEGINNING: AccountNumber | DX_INTEGER ¡MANDATORY ¡0-9999999¡ Balance | DX_REAL | OPTIONAL ¡¡ 0 END: MoneyMktAcct DX_COMMONOBJECT | OPTIONAL ¡BEGIN: CuentaNumero | DX_INTEGER | MDATORY 0-9999999J Balance DX_REAL | OPTIONAL | | 0 END: END:
Any two defined objects can map attribute values from one object to another as long as the DATATYPE is the same. For example, the Client object class has an attribute named CustomerName, while the Judgment object class has an attribute named Accused. Each time the application receives a Client object, it attempts to create a Judgment object and, the ClientName value of the Client object and inserts it into the named Judgment attribute Defendant. In order to provide additional granularity to the mapping, each adapter can retain a copy of its own specific mappings. This allows different types of adapters to map the same objects in different ways based on their own specific need. As an example, a mapping file named Client-Juice.map is created and contains an entry in the form of the following example: Client. CustomerName = Judgment. CuentaLista CheckAct. Judgment Account Number. OmissionAct
If it is determined that this approach is too cumbersome, a global mapping directory can be maintained. If a standardized flat structure and format for all data and objects is employed, a set of general-purpose utility functions for inserting and extracting values of objects / attributes to and from a parameterized data stream based on a meta-object definition can be provided. This allows adapter developers to rely on a single way to pass the data so that the object is instantiated based on the metamodel. In accordance with one embodiment of the present invention, the following methods involving meta-defined objects are described for purposes of illustration. DX_CommentObject * StreamToObject (chat * data) is a method that accepts marked values from an internally marked data stream format and produces a DX_CommonObject * corresponding to the meta-definition that matches the data fields of the checked data stream. During the instantiation, field and value validation is done based on the meta definition. Given a DX_CommonObject, the char * ObjectToStream method (DX_CommonObject &: Obj) flattens the attributes of the object and the values in a stream of internally marked data. The DX_CommonObject * MapObjects method (DX_CommonObject
&srcObj), given a DX_CommonObj et, instance and returns a new DX_CommonObj ect with the automatically populated values using the conditions specified in the mapping file. This method is typically invoked by the dequeue operation. This method also invokes a ValidateQbject () method to ensure that the mapped input objects satisfy all the specified criteria. The EreturnCodes ValidateObject method (DX_CommonObject & scrObj) is automatically invoked by the form queue operation to verify that the object being queued matches the metadefinition of the object. Several metamodel conversion utilities can be deployed for use with the most commonly used object models. For example, a JAVA applet that performs lexical mapping can be integrated into the visual interface. A set of useful conversion utilities may be available to convert the following modeling standards into the metamodel employed in the visual data integration architecture of the present invention: GDMO (guidelines for designing managed objects), ASN.l (syntax notation) abstract version 1), IDL (interphase definition language), and UML (unified modeling language). Each time an adapter is deployed, a set
• metadefinition files are supplied corresponding to
the specific functionality of the adapter. This allows new adapters to be easily added to the system without requiring the user to manually add these metadefinitions. Metadefinitions define one or more input objects, one or more output objects and, optionally, provide a
internal definition of the operation that is carried out when
• receives a specific input object. It is noted that if a definition of modifiable internal operations is provided, storage, editing, retrieval, and internal field mappings must be provided by the developer of the
adapter. For example, a database adapter can specify the following objects in the meta-format: Example # 2 • Getemployeeld (input object) 20 EmployeeName DX_STRING MANDATORY 256 RequestOperation (Optional internal editable SQL operation supplied by the adapter developer) Getemployeeld = "Select < EmployeeId > from Employees where EmployeeName = EmployeeName 25 GetemployeeldResponse (output object) E ployeeld DX_INTEGER¡ MANDATORY 09999999
f As previously discussed, and as shown in
Figure 18, when a data integration project is configured using the visual interface 501, a user typically selects at least two adapters, and then connects them to a line representing a queue. When the line connects the two adapters, the user interface 501
performs a query to the metamodels for each of
• the adapters and then compare them. If the models are inconsistent, the color or other visually perceptible feature of the interconnection line is changed to alert the user that the two models can not be "plugged in and
play "without performing any degree of client mapping." When a user wishes to perform mapping, the visual interface 501 provides two levels of mapping Initially, a side-by-side view of the metaclasses of the adapter is provided to allow the user to connect the two
definitions with a line. As soon as the definitions are connected, the visual interface 501 presents a new side-by-side graphical view of the detailed metadefinitions in an abstract but simple object model view, which may show containment. From this point of view, the user
can then connect lines in the attributes of two metadefinitions. When the user is finishing the mapping of the attributes and selecting the "accept" button, the user session compares the attribute types for type discrepancies and generates a mapping file. This procedure is repeated for each of the metadefinitions that the user wishes to manually map. When an adapter starts a runtime, instantly reads and stores the metadefinitions of the objects that will be processed and any associated mapping files. The object metadefinitions are used as a template object for the purpose of providing rapid instantiation of an object. When an object is removed from the queue, a query is made to determine if the object requires mapping. If the object is going to be mapped from one type to another, a mapping method MapObjects O object is used to perform the validation and mapping. The adapter then performs its specific function. When the queuing operation is performed, a queuing method Enqueue () invokes validate ValidateObject () object to verify that the output object adheres to the definition in the metamodel. According to one embodiment of the invention, all adapters are written in C ++ and the visual interface is written in JAVA. Communication between the C ++ processes and the JAVA visual interface is provided through interaction with the configuration files, although an approach that mixes direct file access with buffered writes can be used to prevent simultaneous access or data half-written The direct file access approach supports non-distributed systems or distributed systems over shared file systems. The most advanced distribution can be supported through protection buffers and communication techniques by soquets. For example, a visual interface that runs on machine A can send a request for
GetQView to the monitoring process running on a machine
# B. The monitoring process can then execute the GetQView process from the protection, take its exit from the stdout buffer, and send the result again via a socket. 15 The JAVA foundation class (JFC) provides a comprehensive set of components that can be used to implement a visual interface of the present invention that has some or all of the features described in
# I presented. The convenient version of JFC is version 1.0.1,
that you can meet with JDK 1.1. * And the JAVA WORKSHOP 2.0. The visual interface of the present invention can be implemented as a separate JAVA application, rather than an applet, which removes any dependency on a particular network browser JAVA support. As stated above, examples # 3- # 5 below define the contents of various configuration files used by the visual data integration system in accordance with one embodiment of the present invention. In particular, example # 3 provides a detailed content definition for the Project File configuration, example # 4 provides a detailed content definition for the Component Instance configuration, and Example # 5 provides a detailed content definition for the Component configuration. The Project File configuration, which references a list of instance configurations to be created at the time of deployment, is read and updated only by the visual interface 501, an example of which, including descriptions textual, is provided below as Example # 3: Example # 3 Project File < project name > . sxp [configuration project]% storage type, either using file storage or some other database storage% Note - copied to < inst name > . cfg in scenario Storage type = [FILE] | [ORACLE]% name of the error queue to be used for this project% Note - copied to < inst name > . cfg in scenario Error Queue = < string > % There is a group that starts with [< instance name > ] for each component BP instance defined in the project 5 [instance name]% name of the component to be displayed in the system view of Ul System Name = < string > % component name to be displayed in view of 10 Ul business • Business Name = < string > % X coordinate to return the icon to (origin on the left-right increase) X-Coordinate = < int > 15% Y coordinate to return the icon in (origin in top -increment below) Y coordinate = < int > % Component name this instance corresponds to Component Name = < string > 20 Subdirector displaced component component io
'Component' Component Path = < string > % Optional - Icon to display for the component (base icon name without% status) - implement for second version! 25 Iono Name = < string > [instance name] The component instance configuration, an example of which is given below as Example # 4,
• is created by the GUI as component deployment time. 5 Some of these parameters are copied from the file
< project name > .sxp or the file < Comp name > .cfg. Example # 4 < inst name > .cfg [configuration project] 10 this is the configuration that is created at the time of component development% in the lab and should not be adapted to the client name of the error queue to be used by this project collected from < project name > . sxp when changing there 15 Error Queue = < string > [Configurable Static] this setting whose omission is fixed at component development time% time, but can be changed during deployment if component 20 is not% running Optional - Queue entry for this component Input Queues = < tail name > , ... < tail name > % Optional - Queue Output for this component 25 Queue Output = < tail name > , ... < tail name > • §- List of supported default input metamodels Input Metamodels = < data definition; », ... < data definition >
% List of default input metamodels supported «Output Metamodels = < data definition > , ... < data definition > 5 [Configurable runtime]% instantiated, this is copied from the component configuration file to the instance configuration file. These are parameters whose omission is set at the component development time, but can be changed during deployment even when
• the component is running This parameter controls the maximum size at which the trace / record file grows the value is an integer - unit is Kbytes. 15 Trace or Register File Size = 100% This parameter represents the level of error currently reached Error Level = NONE) CRITICAL GREATER WARNING »% The following parameters are used to turn ON / OFF 20 levels of individual traces Trace Application = OFF Trace System = OFF Application Information = OFF System Information = OFF 25 External Monitoring = OFF% These parameter controllers will allow the maximum number of threads that the% Thread Controller would allow to run at the same time.
• Maximum Thread = 10 5% This parameter determines the size of the stack for threading operations when the thread handler object is used Stack Size = 1024% This parameter determines the number of threads dedicated for 10 to perform •% queue operations for each input queue Pull off Queue = 2% This parameter is used to turn the queue performance monitor ON / OFF 15 Tail Monitor = ON% This parameter is used to turn ON / OFF the system performance monitor System Resource Monitor = ON% This parameter controls the interval in which the% statistics are reported by the performance monitor. Monitor Interval = 10% This parameter controls the maximum size at which% the performance monitor record grows. 25 Monitor Register File Size = 100 The component configuration is created by the developer of a component at development time. There are four types of parameters, including non-configurable, configurable static, configurable at runtime, 5 and configurable parameters of the project. The non-configurable parameters are parameters that are defined by the developer and do not intend to be modified in the deployment time or execution time. Static configurable parameters are parameters whose omission is set at the time of
development of the component, but it can be changed in
• deployment, such as providing overshoot definitions in the < project name > .sxp. The static configurable parameters do not intend to be changed at runtime. 15 The configurable parameters at runtime are parameters that are copied in the instance creation to the file < inst name > . cfg. These parameters can be modified at runtime through the interface
• visual and the new values or parameters are stored in the
file < inst name > .cfg. The configurable parameters of the project are parameters that are copied from the file < component name > .cfg to the file < project name > .sxp at the time of creation of the project, and can be modified in the file < project name > .sxp at runtime. Noticeable
that each component can have specific groups of components, and that these groups behave as configurable parameters at runtime. A set of parameters associated with a typical component configuration file are provided further
• go ahead in Example # 5: Example # 5
< comp name > .cfg [ParamNamc »lwith Na me GroupNamc ^ Project Copfigurablc • Commcnt = Dcfauit icon to display for the compos nt Type» Stripg Rangc ^ Dcfault- < icon n »mc > .fco Rcad? ccess ~ < SysIntegration | SysManagement | BusIntegrat¡on | BusManagemcnl | (Jser Name >; Wrhe? Cccsss < Syslntcgration | SysMapagement | BuslntegrationjBusManagcment | Uscr ame > ] r ParamNamc = Systen? Ñame GroupName = * Project Configurable Co ment »Dcfault ñame to be displayed in System View of UI Type ^ Strinß • Range« = Default- < default value Read? c ess- < Syslntegration | Sys anagement | Buslptegration | BusManagement | liser Name > rkeAccess- < SysIntegration | SytManagement | BusIntegration | BusManagement | l) be Name > ] ParamNamcBusincjj Ñame GroupNamc ^ Project Configurable Commcpt "Üefault ñame of the comp.lo it is displayed ip Business View. • Type-String Range" Dcfault = <defaull value> Rcad? Ccess = <Syslntegration | SysManagement | Buslntegratiop | BusManagementHJscr Name > WritcAccess = < SysIntegration | SysManagement | BusIntegration | BusManagep? e ?? t | User Name > 1
[ParamNamc-- in Ippul Queues Comment »Minimal number of input queues for the component Typc = Numeric • Rangc = Dcfault- < default value > ReadAccess: e = < SysIntegration | SysManagemcpt | BusIptegration | BusManagement | llser Namc > ritcAccess = - < SysIntegration | SysManagemcnt! BusIntegration¡BusManagement | User Name > ]
[ParamNamc = Max Input Qucues GroupNamc] Non-Configurable Commcpt-Maximum number of input queue for the component Typc = Numeric Range- Default ~ < default value ReadAccess- < Syslntegratifln | SysManagement¡Buslntegration | BusManagement | llser Name > WriteAcccss- < Syslntegration¡SysManagcment | Buslntcgrat¡on | BusManagement | User Name > ]
r For Name-Min Output Queues • GroupName-Non-Configurable Commcnt-Minimal number of output queues for (he component Typc = Numeric Range- Dcfault »<default valu Read? ccess- <Sys Integration | SysManagcmcnt | Buslntcgration | BusManagcment | l) be Namc > Wri (eAccess- < SysIptegratiopfSysManagementjBusIntcgration | Bu «Managcment | (Jser Name >]
[ParamNamc = Max Output Queues • GroupNamc = Non-Copfigurablc Commcnl = Maximum number of output queued for the compose! Typc = Numeric Rangc = Dcfaulí = < default vaiue > ReadAcccss8 < SysIntegration | SysManagemcnt | Buslntegratiop | BusManagemen (| User Namc> WritcAccess = <SysIntegratiop | SysManagement | BusIntegp? Tion | BuslVlanagement | User Namo 1 1
Parn Namc = S) slntegration Dblclk GroiipNamc-lSon-Configurable Commcnl- System integration command to be torn «lien dbl-click on with. • Tyno = String Rangc = Dcfault = < dcfault value > ReadAcccss = < Sy ?? ntegration¡SysManaEement | 3uslniegration¡BusManageroent | l) ser Name > riteA cess- < SysIntegrat¡onlSys anagement¡BusIntfgration | BusManagcmept | User Name > 1 Px'3m ap? C = SysMapttgement Dblclk GroupName = Non-Con Rgu rabie Comment = System Munagement commapd to be run when double cllckcd on comp Typc = String Rangc = Default = < default value > Read? C css = < Syslntegrat¡onjSysManagemept | Buslntegration | BusMar gcment | User Namc > WriteAcccss = < SyslntegrationlSysManagemcnt | BusIntegration | BusManagemcnt | User Name >
ParamName-Buslptegraíion Pblclk
• GroupNamc-Non-C.'onfigurable Commenl »Buslpe.u Integration command to run when dbl-clk on Ic Typc-String Rangc = Dcfault = < default value > RcadAcccss- < SysIntegration | SysManagemep (| Buslntegration | BusManagement | llser Name> Write? Ccess- <Syslntegration | SysManagement | BusIntegration | BusManagement¡Uscr Name> 1
[ParamName = BusManagement Dblclk GroupNamc = Non-Copfigurablc Commcnt = Buss. Management command to be run when double ciicked on icon Typc-String Range "Defauit = <default value> ReadA ccss- <Syflntegration | SysManagement | Busintegration | BusManagement | User Name> WriteAcccss» <Syslntegration | SysManagement | Buslntegratiun | BusManagement | Uscr Name>] ParamNamc = Run Command GroupNamc ° Non-Configurable Comment- Cnmmand to run the component. Typc-String Range- Default- <default valu ReadAccess ^ <SysIntcgration | SysManagemcnt¡ßuslntcgratíop | BusMapagemeptj (Jser Name > Write? Ccess = < SysIptegration | SysManagement | BusIntegration | BusManagement | User Name > 1
(ParamName = Stop Command GroupNamc = Non-Configurable Comment = Command to stop the componet • Tync = Strip Range = Ocfault- <default value> ReadAcccss = <SysIntegrationJSysManagement | Busintegration | BusManagement | llser Name> ritcAccess = < SysIntegration | SysManagemcnt | BusIntcgration | BusManagement | User Name >]
[ParamName- econfig Command GroupNamc-Non-Configurable
Comment- Command to reconfig the componept Typc »String • Range- Default = < dcfault value > RcadAccess »< Syslptegrat¡on | SysManagcmcnt | Buslntegration | BusManagementHJser Name > riteAcccss- < Sys! Ntegratíon | Sys \ iapagemcpt | BusIptegration | BusManagement | User Namc > 1 [ParamNa e = Ipput Queues GroupName = Sta (ic Copfurable Comment = Input Queues for this component • Type = String Rangc = Defaul (= <default value> RcadAccess = «<Sysln (egration | SysManagement | Bu? Intcgration | BusManagement | lJser Name> ritc? Ccess = < SysIntegration | SysManagement | Buslptegration | BusManagement | llser Ñamo]
l ParamNamcOutpul Queues GroupNamc * = Static Configurablc Co ment- Output Queues for this compose! • Typc-String Rapg = Default = < dcfault val RcadAccess- < Syslntegratíon | SysManagcment [BusIntegration | BusManagement | User N e > Wr¡teAccess3 > < Sy3lntegration | SysManagement | Buslntegration | BusManagement | User Name > I
[ParamNamc = Inpuf MetaModels GroupName = Static Configuous Comment = List of default ipput mela-modeis supported Typc = String Range > = Uefault = < default value > ReadAcccsss < SysIptegration¡SysManagement | Buslntegration | BusManagement | User Name > riteAccesss < SysIntegration | SysManagement | BusIntegration | Bu.sManagementIUser Name > J < <
106
I ParamName-Output MetaModels GroupNamc-Static Configurable • Commcnt = List of default output meta-models supported Type = Str¡ng Rangc- Dcfault = < default valued RcadAcccss = < Syslntegration | SysManagement | Buslntcgration | BusManagemepl | User Namc > WritcAcccss = < Sysintcgratiop | SysManagement¡BusIntcgration | BusManagemept | User amc > ]
[ParamNatne-Trace Or Log Ule Sizc GrsupName-Ruptime Configuratic Comment- the m ximum size to which trac iog file Type = Numeric Range = Dc = IOO ReadAcccss = < SyslntcgrationJSysManagement! Buslptegration | BusMapagement | L) be Name > WritcAcccss = < Syslntegration | SysManagement) Buslntegration | BusManagement | User Name > ]
l ParamName-Error Level GroupNamc = Runtime Configblc Comment = (I have error-level that is currently turned op Typc-String • Rangc = »Default-IWONE ReadAcccss = > < Sysintegra (ion | .SysManagementlBusIptegrat¡np | BusMapagemeptjUser Name > WritcAcccss- < Syslptegra (ionfSysManagemcnt | ßusln (egrati? P | Bus.Managemept | llser Name> ParamName = Application Trace GroupNamc-Runtime Copfigurablc Commcnt = AppIication level trace switch Type = Stripg • Range = Dcfault = OFF ReadAccess- <SysIptegration SysManagement | BusIntegration! BusManagement | User Name> WritcAccess = < Sysíntegration | SysMapagemcnt | BusIntegration | BusManagemept | User Namo 1
ParamNamc-System Trace GroupNamc-Runtime Configurable Commept »= System levcl trace switch Type-String Rangc =
Dcfaul? »OFF ReadAcccss- < Syslntegratlon | SysManagemcn (| BusIntegrati (in | BusManagemcntlUser Name> WrileAcccss- < Sys! Ntegration | .SysManagement | BuslnIegration | Bu3Man »gement | User Name > 1
ParamNamc = Application information GroupName-Runtime Configurable Commept = Appl¡cation information level trace switch Typc = String Rangc = DcfaulfOFF • ReadAccess «< Syslntegration | SysManagement | Buslntegration | BusManagement | liser Namc > Write? Ccess- < SysIntegration | SysMapagement | BusIntegration | BusManagement | User Name > 1
-v -r 108 I ParamNamc = System Information GroupNamc = Runtime Configurable Comment = System Info. Level trace switch Type-String Range3 Dcfault-OFF ReadAcccss- < Sy5lntegration | SysManagemcnt | Buslplegration | BusMapagement | Uscr Name > WriteAcccss- < Syslntegration | SysManagemept | BusIntegration | BusManagement | User Name >
[ParamNamc-? Udit GroupNamc = Runtime Configurablc Conimcnt-Audit switch Typc = String Range = Default =? FF ReadAccess = < SysIntcgration | SysMapagcmcnt | Buslptegratiop | BusManagement | User ame > WritcAccess = < Syslntcgration | SysManagement | Buslntegration | BusManagemcntHJser Name > 1
ParamNamc-Maximum Threads GroupName-Runtime Copfigurable Comment = »Max threads that ThreadControlier would allow concurrently Typc = Numeric Range = Default-10 RcadAccess- < SysJntegratlon | Sy? M «nagemcnt | Buslnlegration | BusManagement | User Name > ritcAcccss- < SyslplegrationlSysManagement | Buslnlegration | BusManagement | Hser Name >
* «109
ParamNamc-Stack Size GroupName-Runtime Configuous Commenl »the size of the ttack for threadcd operations • Type = Numeric Range = Dcfault = 1024 RcadAccess = < SysIntegration | SysManagement | Buslntegratiop | Bu5Management | User Name >
\ VritcAcccss- < Syslntegration | S > sNtanagement | Bustntegration | Bt? sManagcmen (llIscr NamO 1
[ParamNamcDcqueue Threads GroupNamc = Configurable Runtime • Comment '# threads dedicated to perform dcqueue from each input queue Typc = Numeric Rangc = DcfaulP = 2 ReadAccess «= < Syslptegralion | SysManagemenl | Buslntegrat¡on | BusMapagement | User Name > rite? cccss = < SysIntcgrationlSysManagement | Buslntegraiion | BusManagemeBtlUserName > 1
ParamName = Queue Monitor GroupNamc = Configurable Runtime Comment = Qucue Performance Monitor switch Type-String '' Range- Defaull-OFF ReadAcccss = < Syslntegration | SysManagement | Buslntegration | BusManagement | l) be Nan? E > WrUeAcccss = Syslntegration | SysManagemeBt | Buslntcgralion | BusManagement | Uscr Namo 1 ParamNamc = System Resource Monitor GroupNamc-Runtime Configurable Comment-thc system performance monitor switch • Typc-String Rangc = Default-OrF ReadAcccss3 < SysIntegration | SysManagement | BusIntegration¡BusManagement | User Name > ritcAcccss = < Syslntegration | SysManagement | BusIntegration | BusManagement¡User Name > ]
For Namc Monitor interval GroupNap = Runtimc ConFigurable Comment = interval (in secs) at which statistics are reportcd Typc-Numeric Rangc = Default-600 ReadA cess- < SysIntegration | SysManagement | BusIntegration | BusManagement | User Name > Write? Cccss- < SysIntegration [Sy $ Management | BusIntegration | BusManageme ?? t | User Name >
I ParamName-Monllor Log File Size Configurable GfOupNamc-Ruptlme Comment- the maximum size to which the monitor monitor grows the Type-Numeric Range- Dcfault = 100 Read? Ccess- < Syslntegration | SysManagement | BusIntegrationjBusManagement | (Jser Name> WriteAccess = <SysIptegral¡onlSysMapagement | BusIntegration | BusManagement | User Name> J The above description of the different embodiments of the invention has been presented for purposes of illustration and description. be exhaustive or limit the invention to the precise form described Many modifications and variations are possible in light of the above teachings It is intended that the scope of the invention is not limited by that detailed description but by the claims appended thereto.
Claims (46)
1. A method of visually implementing an information system, comprising: constructing a graphic representation of source elements and the destination elements of the information system; establish graphic connections between the selected elements of origin and destination to produce a graphic representation of the information system; determine the validity of graphic connections using input / output request models associated with each of the connected source and destination elements; transform the graphic representation of the information system into a display of the information system's execution time; and presenting, to a user, selected information developed from the display of the information system execution time using one of a plurality of user selectable visual views.
The method according to claim 1, further comprising manually mapping the graphical connections between the particular source and destination elements using models of associated input / output requirements in response to an incompatibility between the particular source and destination elements.
3. The method according to claim 1, wherein the presentation of the selected information comprises • also present business information associated with data 5 transmitted through the graphic connections.
4. The method according to claim 1, wherein presenting selected information further comprises presenting system information associated with the source and destination elements of the information system.
5. The method according to claim 1, wherein presenting the selected information further comprises presenting performance information associated with the transmission of data through graphic connections.
6. The method according to claim 1, wherein presenting the selected information further comprises presenting error information associated with the data transmitted through graphic connections.
7. The method according to claim 1, in • where to build the graphic representation of elements of The origin and destination elements further comprises moving the source and destination icons respectively representative of the source and destination elements from a first visual interface region to a second visual interface region.
8. The method according to claim 7, wherein establishing graphical connections between the selected source and destination elements further comprises establishing graphical links between the icons of selected source and destination elements within the second region of the • visual interface.
9. The method according to claim 8, wherein establishing graphic connections between the selected source and destination elements further comprises marking erroneous graphic links with indications of incompatibility between the first and second elements. 10
10. A method to visually develop a # communication interface, comprising: visually representing a first component and a second component; visually link the first component with the 15 second component to visually define the communication interface; and transform the visually defined communications interface into an execution time display of • communication interface.
11. The method according to claim 10, further comprising determining the validity of the visual link between the first and second components of the system.
12. The method according to claim 10, wherein visually linking the first and second components 25 further comprises using a first and second models to define the visual link between the first and second components, the first and second models defining the input and output requirements of the respective first and second components.
13. The method according to claim 10, wherein visually linking the first and second components further comprises using first and second models to verify the effectiveness of the visual link between the first and second components, the first and second models defining the input and output requirements of the respective first and second components .
The method according to claim 12, further comprising manually mapping the visual link between the first and second components using the first and second models in response to an incompatibility between the first and second components.
The method according to claim 10, further comprising presenting to a user selected information developed from the deployment at the time of execution of the communication interface.
16. The method according to claim 10, further comprising presenting to a user, selected information developed from the display deployment of the communication interface using one of a plurality of user selectable visual views.
17. The method according to claim 10, further comprising presenting to a user, business information, performance, or error associated with data transmitted to • through the communications interface.
18. The method according to claim 10, further comprising presenting to a user, system information associated with the first and second components of the communication interface.
19. The method according to claim 10, 10 wherein visually representing the first and second components further comprises moving the first and second icons of the respectively representative components of the first and second components from a first region of a visual interface to a second region of the visual interface.
20. The method according to claim 19, wherein visually linking the first and second components further comprises establishing a graphic connection between the first and second component icons within the second one. • region of the visual interface.
21. The method according to claim 20, wherein visually linking the first and second components further comprises marking the graphic connection with indicators indicative of an incompatibility between the first and second components.
22. A method for visually developing a communication interface, comprising: visually representing a first component and a second component; visually link the first component with a • 5 second component to visually define the communications interface; and verify the effectiveness of the visual link between the first and second components using first and second models, defining the first and second models the requirements of 10 input and output of the respective components first and • second .
23. The method according to claim 22, further comprising manually mapping the visual link between the first and second components using the first and second components. 15 models in response to an incompatibility between the first and second components.
24. The method according to claim 22, further comprising transforming the communication interface • visually defined in a run-time deployment of 20 the communications interface.
25. The method according to claim 24, which further comprises presenting to a user, selected information of business, system, performance or error, developed from the deployment in execution time of 25 the communications interface.
26. The method according to claim 22, further comprising presenting to a user, system information associated with the first and second components of the communication interface. •
27. The method according to claim 22, wherein visually representing the first and second components further comprises moving the first and second icons of respectively representative components of the first and second components from a first region of a visual interface to a visual interface. second region of the visual interface. •
28. The method according to claim 22, wherein visually linking the first and second components further comprises establishing a graphic connection between the first and second component icons with the second region. 15 of the visual interface.
29. The method according to claim 28, wherein visually linking the first and second components further comprises marking the graphic connection with indicators that • indicate an incompatibility between the first and second 20 component.
30. A system for visually implementing an information system, comprising: a deployment; an input device that can be activated by a user to place graphic representations of source components and target components of the information system in the deployment, the input device can also be activated by a user to establish graphic connections between selected elements of origin and destination so as to produce a graphic representation of the information system; and a processor coupled to the input device and the display, the processor that transforms the graphic representation of the information system into an information system execution time display.
The system of claim 30, wherein the processor determines the validity of the graphic connections between the selected source and destination components.
32. The system of claim 30, wherein the processor determines the validity of the graphic connections between the selected source and destination components using the associated origin and destination input / output request patterns, defining the input request models. / departure of origin and destination the entry and exit requirements of the respective origin and destination components.
The system of claim 30, wherein the input device is activatable by the user to manually map erroneous graphic connections between incompatible origin and destination components.
34. The system of claim 30, wherein the input device is activatable by the user to selectively display selected information developed from the display of the information system's execution time.
35. The system of claim 30, wherein the input device is activatable by the user to select one of a plurality of visual views to present developed information of the display time of the information system in the deployment. 10
36. The system of claim 35, wherein the ^ Information comprises business information, performance, or error associated with the data transmitted through the information system.
37. The system of claim 35, wherein the information comprises the system information associated with the source and destination components of the information system.
38. A system for visually implementing an information system, comprising: a visual display; 20 an input device operable by a user to place graphic representations of source components and target components of the information system in the visual display, the input device further activatable by a user to establish graphic connections between the source components and selected destination to produce a graphic representation of the information system; and a processor coupled with the input device and the visual display, the processor that verifies the 5 efficiency of the graphic connections between the selected source and destination components using associated source and destination input / output requirements files, defining the source input / output requirements files and destination the input and output requirements of the components of source 10 and destination respectively. •
39. The system of claim 38, wherein the input device is activatable by the user to manually map erroneous graphical connections between incompatible origin and destination components.
40. The system of claim 38, wherein the processor transforms the graphic representation of the information system into an information system execution time display. ^ B
41. The system of claim 40, wherein the The input device is activatable by the user to selectively present selected information developed in the visual display developed from the execution of the information system at the time of execution.
42. A system for visually implementing an information system, comprising: an element for constructing a graphic representation of source elements and destination elements of the information system; an element to establish graphic connections between the selected elements of origin and destination to produce a graphic representation of the information system; elements for determining the validity of the graphic connection using models of input / output requirements associated with each of the connected source and destination elements; and elements to transform the graphic representation of the information system into a display of the information system's execution time.
43. A system for visually developing a communication interface comprising: an element for graphically representing a first component and a second component; an element for graphically linking the first component with the second component to graphically define the communication interface; and an element for transforming the graphically defined communication interface into a runtime display of the communication interface.
44. A system for visually developing a communication interface comprising: an element for graphing a first component and a second component; an element to graphically link the first component mm with the second component to define visually 5 the communications interface; and an element for verifying the efficiency of the graphic link between the first and second components using the first and second models, the first and second models defining the input and output requirements of the first and second respective components. •
45. A computer-readable medium that tangibly incorporates an executable program for visually implementing a communication interface, comprising: visually representing a first component and a second component; visually link the first component with the second component to visually define the communication interface; and ^ transform the communications interface 20 visually defined in a runtime display of the communication interface.
46. A computer readable medium that tangibly incorporates an executable program for visually implementing a communication interface, comprising: visually representing a first component and a second component; visually link the first component with the second component in order to visually define the communication interface; and verifying the effectiveness of the visual link between the first and second components using first and second models, the first and second models defining the input and output requirements of the respective first and second components. SUMMARY An architecture and methodology of a visual data integration system is disclosed. The system architecture includes a transport structure that represents an integration mechanism independent of the technology that facilitates the exchange of technology-dependent data between disparate applications. A visual interface facilitates the design, deployment, and monitoring of the execution time of an integrated information system implementation. An integrated information system is visually developed through the use of the visual interface, dragging and leaving the components within an area of scrutiny of the interface. The components are graphic representations of different elements of telecommunications hardware and software, such as information stores, processors, input / output devices, and the like. Different components can be packaged together as business extension modules that provide specific business integration capabilities. Interconnections are established graphically between the components using a mouse to define the sources and destinations of the specified data. An underlying configuration / execution time structure, which operates above and in concert with the transport structure, effectively transforms the graphic interconnections into logical or physical interconnections, which results in the contemporary generation of an integrated runtime system. Meta-models of formal neutral data are used to model the input and output data requirements of disparate systems and system components, in order to remove any cross-dependencies that exist between the systems and the technologies involved in a project. data integration The visual interface enables the control of the execution time and the analysis of the business information, and the system aspects of an integrated system implementation. Visual views of the live display provide consistent management and control for system integrators, business integrators, system administrators, and business administrators, using a single visual interface.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09060667 | 1998-04-15 | ||
| US09093162 | 1998-06-08 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| MXPA00010063A true MXPA00010063A (en) | 2001-09-07 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6208345B1 (en) | Visual data integration system and method | |
| Olsen | Systems engineering using SDL-92 | |
| US6334158B1 (en) | User-interactive system and method for integrating applications | |
| US8478616B2 (en) | Business application development and execution environment | |
| US5301270A (en) | Computer-assisted software engineering system for cooperative processing environments | |
| US6470388B1 (en) | Coordinated extendable system for logging information from distributed applications | |
| US6269460B1 (en) | Dynamic enhancement of error condition handling and displayed error messages in computer operations | |
| US7693974B2 (en) | System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network | |
| US6275977B1 (en) | Application cooperation method and apparatus | |
| TW526429B (en) | Graphical editor for defining and creating a computer system | |
| KR100652482B1 (en) | Method and apparatus for providing direct transaction access to information residing on a host system | |
| US7467198B2 (en) | Architectures for netcentric computing systems | |
| US6324576B1 (en) | Management interworking unit and a method for producing such a unit | |
| US20040139176A1 (en) | Systems and methods for improving service delivery | |
| US20020120919A1 (en) | Monitoring execution of an hierarchical visual program such as for debugging a message flow | |
| US20080209392A1 (en) | Systems and Methods for Definition and Execution of Batch Processing Services | |
| Steffen et al. | Hierarchical service definition | |
| WO2001025919A2 (en) | Architectures for netcentric computing systems | |
| JPH11234276A (en) | Management system based on bean | |
| US6658644B1 (en) | Services-based architecture for a telecommunications enterprise | |
| EP1226495A2 (en) | Architectures for netcentric computing systems | |
| US20070198562A1 (en) | Method and Apparatus for Ensuring Business Process Integration Capability for one or more Distributed Component Systems in Communication with one or more Legacy Systems | |
| US20060120353A1 (en) | Systems and methods for VolP service delivery | |
| Hämmäinen et al. | Distributed form management | |
| KR20070083786A (en) | Business process management system and method |