REGISTER  |  SIGN IN
United States Patent6453356
Sheard , ; et al.September 17, 2002
Title
Data exchange system and method
Abstract
A system and method for exchanging data between two or more applications includes a data exchange engine and a number of adapters associated with a corresponding number of applications. Each of the adapters is customized to interface with a corresponding application and transforms data being transferred between the application and the data exchange engine. Data produced by a particular application is converted from a technology dependent form to a technology independent form by the corresponding adapter. In one embodiment, the format associated with a data stream is disassociated from the informational content of the data stream by the adapter. The informational content of the data stream is then transformed by the adapter into a common or generic format. The data exchange engine receives data in a technology independent form from each of its associated adapters and coordinates the routing of informational content to particular adapters associated with applications that have requested specific informational content. The adapters receiving the informational content from the data exchange engine transform the informational content having the common format into a data format compatible with, or specific to, their associated applications. A queuing mechanism is employed to construct a reliable asynchronous or pseudo-synchronous interface between disparate applications and systems. The data exchange engine may apply business rules or logic when processing a request for particular informational content. User-specified routing logic may be applied by the data exchange engine to dispatch selected informational content to one or more destination applications.
Inventors:Sheard; Nicolas C. (Palo Alto, CA), Fischer; Larry J.  (Campbell, CA), Matthews; Richard W.  (Redwood City, CA), Himabindu; Gurla  (Sunnyvale, CA), Hu; Qilin  (Mountain View, CA), Zheng; Wendy J.  (Cupertino, CA), Mow; Boyle Y.  (Freemont, CA)
Assignee:ADC Telecommunications, Inc. (Eden Prairie, MN)
Appl. No.:060667
Filed:April 15, 1998
Current U.S. Class:709/231 
Field of Search:709/223,315,100,231,230,329 713/1 717/10,5 345/335
U.S. Patent Documents
4791558December 1988Chaitin et al.
5386568January 1995Wold et al.
5524246June 1996Hurley et al.
5684967November 1997McKenna et al.
5754775May 1998Adamson et al.
5794018August 1998Vrvilo et al.
5812768September 1998Page et al.
6047323April 2000Krause
6067566May 2000Moline
6141691October 2000Frink et al.
6202096March 2001Williams et al.
Foreign Patent Documents
WO 97/37303Oct., 1997WO
WO 99/15986Apr., 1999WO
Other References
Robertson, "Integrating Legacy Systems with Modern Corporate Applications," Communications of the ACM, 40, 39-46 (1997). .
Gilbert, G., "Business Applications Cross the Border," Beyond the Enterprise, 2 pgs. (Oct. 1997). .
Greenbaum, J., "Competitve Linking Update: CrossRoads to the Rescue," Hurwitz Balanced View Research Bulletin, 6 pgs. (Jun. 1997). .
"Managing Emerging Telecommunications Technologies For Competitive Advantage," Versant Object Technolgy25 pgs. (1997). .
"MQSeries Version 5--The Next Generation," 8 pgs. (Undated). .
"ServiceGate.TM. Retail Service Manager Software," Bellcore, 6 pgs. (1997). .
"Software Distributed Services Environment," Softwire, 4 pgs. (1997). .
"Versant ODBMS Release 5," Versant Object Technologies, 8 pgs. (Oct. 1997). .
Product Literature, "SAIC Project Profile," http:www.saic.com/telecom/profiles/ebss.html, 1 pg. (Oct. 1997). .
Product Literature, "DSET Company Profile," http://www.dset.com/company/profile.html, 11 pgs. (Oct. 1997). .
Product Literature, "Crossroads Software," http://www.crossroads-software.com/archsvcs.html, 5 pgs. (Jan. 1998), .
Product Literature, "CrossRoads Customer Interaction,"http//www.crossroads-software.com/customer interaction.html, 1 pg. (Jan. 1998). .
Product Literature, "CrossRoads," http://www.crossroads-software.com/processware.html, 2 pgs. (Jan. 1998). .
Product Literature, "CrossRoads Partner," http://www.crossroads-software.com/partner information.html, 2 pgs. (Jan. 1998). .
Product Literature, "Aberdeen Group," http://www.crossroads-software.com/aberdeenimpact.html, 3 pgs. (Jan. 1998). .
Product Literature, "CrossRoads Management," http://www.crossroads-software.com/mgmt team.html, 3 pgs. (Jan. 1998). .
Product Literature, "Enterprise Management Strategy," http://www.cai.com/products/unicent/whitepap.html, 23 pgs. (Feb. 1998). .
Product Literature, "Computer Associates Press Release," http://www.cai.com/press/97dec/jasmine launch.html, 3 pgs. (Feb. 1998). .
Product Literature, "Computer Associates Unicenter.RTM. TNG," http://www.cai.com/products/tng endorse.html, 6 pgs. (Feb. 1998). .
Product Literature, "Computer Associates Product Description," http://www.cai.com/products/unicent/tng ov.html, 8 pgs. (Feb. 1998). .
Product Literature, "OPAL Version 2," http://www.cai.com/products/opal/wp1.html, 20 pgs. (Feb. 1998). .
Product Literature, "Versant Object Technology," http://www.versant.com/whats new, 27 pgs. (Jan. 1998). .
Product Literature, "SAIC The Vision," http://www.saic.com/telecom/index.html, 4 pgs. (Jan. 1998). .
Product Literature, "Electronic Bonding," http://www.gteds.com/html/eb.html, 3 pgs. (May 1997). .
Product Literature, "CLECs Use Internet Technology to Bond with Bells," http://www.zdnet.com/intweek/daily/97052e.html, 2 pgs. (Jan. 1998). .
Product Literature, "MQSeries Business Partners Index," http://www.software.ibm.com/ts/mqseries/partners/partner.html, 1 pg. (Feb. 1998). .
Product Literature, "MQSeries in General," http://www.software.ibmcom/ts/mqseries/library/brouchures/business, 3 pgs. (Feb. 1998). .
Product Literature, "Massachusetts agencies exchange a wealth of data using MQSeries,"http://www.software.ibm.com/ts/mqseries/solutions/mass.html, 3 pgs. (Feb. 1998). .
Product Literature, "Landmark Announces Performace Managment Solutin for MQSeries," http://www.software.ibm.com/news/2f46.html, 2 pgs. (Feb. 1998). .
Products Literature, "Boole and Babage" http://www.boole.com/news/current/mqseries.html, 2 pgs. (Jan, 1998). .
Product Literature, "Boole and Babage," http://www.boole.com/news/96%5Farchive/Commandmq.html, 2 pgs. (Jan. 1998). .
Product Literature, "MSMQ: Interoperability," http://www.microsoft.com/ntserver/guide/msmq_interoperability.asp, 1 pg. (Jan. 1998). .
Product Literature, "Microsoft Windows NT Server," http://www.microsoft.com./ntserver/community/msmqarchive.asp?A=7&B=5, 1 pg. (Jan. 1998). .
Product Literature, "Microsoft Windows NT Server," http://www.microsoft.com/ntserver/guide/msmq--rev--patsey.asp?A=7 &B=5, 8 pgs. (Jan. 1998). .
Product Literature, "Frontec--The AMTrix.TM. System Technical Overview," http://www.frontec.com/amtrixtechover.html, 5 pgs. (Jan. 1998). .
Product Literature, "Frontec--The AMtrix.TM. System," http://www.frontec.com/amtrixsystem.html, 3 pgs. (Jan. 1998). .
Product Literature, "Introduction to Messaging and Queuing," http://candy1, hursley.ibm.com:8001...r.cmd/book/HORAA101/, 31 pgs. (Jan. 1998)..~
Primary Examiner: Courtenay, III; St. John
Assistant Examiner: Nguyen; Van H.
Attorney, Agent or Firm:Schwegman, Lundberg, Woessner & Kluth, P.A.
Claims

What is claimed is:
1. A method of transporting data, comprising: receiving a data stream from each of a plurality of source applications, each of the data streams comprising informational content and having a technology dependent form associated with a source protocol; converting the data streams from the technology dependent forms to technology independent forms not associated with the respective source protocols and not associated with respective destination protocols of one or more destination applications; identifying the one or more destination applications; transporting the data streams having the technology independent forms; transforming the data streams from the technology independent forms to technology dependent forms associated with the respective destination protocols of the one or more of the destination applications; and transmitting all or a portion of the data streams having the technology dependent forms to the one or more of the destination applications.

2. The method of claim 1, further comprising processing the data streams using pre-established logic associated with each of the data streams.

3. The method of claim 2, wherein the pre-established logic associated with each of the data streams is alterable by a user.

4. The method of claim 1, wherein transmitting the data streams comprises transmitting the data streams asynchronously or pseudo-synchronously to the destination applications.

5. The method of claim 1, wherein identifying one or more destination applications comprises applying routing logic associated with each of the data streams to facilitate transmission of the data streams to the destination applications.

6. The method of claim 5, wherein the routing logic is alterable by a user.

7. The method of claim 1, further comprising tracking each of the data streams during converting, identifying, or transforming operations.

8. The method of claim 7, further comprising logging errors occurring during converting, identifying, or transforming operations.

9. The method of claim 1, further comprising validating the data streams.

10. A method of transporting data, comprising: receiving, from a source application, data comprising informational content in a technology dependent form associated with a source protocol; converting the data from the technology dependent form associated with the source application to a technology independent form not associated with the source protocol and not associated with respective destination protocols of one or more destination applications; identifying the one or more destination applications; transporting the data having the technology independent form; transforming the data from the technology independent form to a technology dependent form associated with the respective destination protocols of the one or more of the destination applications; and transmitting all or a portion of the data in the technology dependent form to the one or more of the destination applications.

11. The method of claim 10, further comprising processing the data in the technology independent form.

12. The method of claim 11, wherein processing the data comprises altering the data according to pre-established logic.

13. The method of claim 12, wherein the pre-established logic is alterable by a user.

14. The method of claim 10, wherein transmitting the data comprises transmitting the data asynchronously or pseudo-synchronously to the destination applications.

15. The method of claim 10, wherein identifying one or more destination applications comprises applying routing logic to facilitate transmission of the data to the destination applications.

16. The method of claim 15, wherein the routing logic is alterable by a user.

17. The method of claim 10, further comprising tracking the data during converting, identifying, or transforming operations.

18. The method of claim 17, further comprising logging errors occurring during converting, identifying, or transforming operations.

19. A method of transporting data, comprising: receiving data from a source application, the data comprising information associated with a source format; disassociating the information from its associated source format; converting the disassociated information to information having a generic format not associated with the source application and not associated with one or more destination applications; identifying the one or more destination applications; transporting the information having the generic format; transforming the information having the generic format to information having a format compatible with the respective one or more of the destination applications, the formats of the one or more of the destination applications being dissimilar to the source format; and transmitting all or a portion of the transformed information to the one or more of the destination applications.

20. The method of claim 19, further comprising processing the information having the generic format using pre-established business logic.

21. The method of claim 20, further comprising altering the business logic by a user.

22. The method of claim 19, further comprising applying routing logic to facilitate transmission of the transformed information to the destination applications.

23. The method of claim 22, further comprising altering the routing logic by a user.

24. The method of claim 19, wherein transmitting the transformed information further comprises asynchronously or pseudo-synchronously transmitting the transformed information to the destination applications.

25. The method of claim 19, further comprising: tracking processing of the information having the generic format; and logging errors occurring during the processing of the information having the generic format.

26. The method of claim 19, further comprising producing performance data associated with processing of the information having the generic format.

27. The method of claim 19, further comprising validating the received data.

28. A system for transporting data among applications, comprising: an input data adapter comprising an input interface and an input data converter, the input interface receiving an input data stream comprising informational content and having a technology dependent form associated with a source protocol of a source application, the input data converter converting the input data stream having the technology dependent form to input data having a technology independent form not associated with the source protocol and not associated with a plurality of destination applications; a processor communicatively coupled to the input adapter and coordinating the input data having the technology independent form, the processor coordinating transmission of all or a portion of the input data to the plurality of destination applications; and a plurality of output adapters each communicatively coupled to the processor and a respective one of the plurality of destination applications, each of the output adapters comprising an output data converter that converts the input data having the technology independent form to an output data stream having a technology dependent form associated with a destination protocol compatible with a respective destination application, and each of the output adapters further comprising an output interface that transmits the output data stream to the respective destination application.

29. The system of claim 28, wherein the input data adapter implements logic for processing the input data stream having the technology dependent form.

30. The system of claim 28, wherein each of the output data adapters implements logic for processing the input data having the technology independent form.

31. The system of claim 29, further comprising an interface for altering the logic by a user.

32. The system of claim 30, further comprising an interface for altering the logic by a user.

33. The system of claim 28, wherein the processor comprises a plurality of distributed processing units.

34. The system of claim 28, wherein the processor is coupled to a receive queue and a plurality of send queues, the receive queue receiving the input data having the technology independent form from the input data adapter and the processor coordinating transmission of all or a portion of the input data having the technology independent form to one or more of the send queues.

35. The system of claim 34, wherein the processor communicates control signals to the send queues to coordinate transmission of all or a portion of the input data having the technology independent form to one or more of the output data adapters.

36. The system of claim 35, wherein processor coordinates transmission of the input data having the technology independent form to one or more of the output data adapters in an asynchronous or pseudo-synchronous manner.

37. The system of claim 28, wherein the receive queue operates as a first-infirst-out buffer.

38. A system for transporting data among applications, comprising: a plurality of input data adapters each comprising an Input interface and an input data converter, each of the input interfaces receiving an input data stream comprising informational content and having a technology dependent form associated with a source protocol of a respective source application, the input data converters converting the input data streams having technology dependent forms to input data streams having technology independent forms not associated with the respective source protocols and not associated with a plurality of destination applications; a processor communicatively coupled to the input adapters and coordinating the input data streams having the technology independent form, the processor coordinating transmission of all or a portion of the input data streams having the technology independent form to the plurality of destination applications; and a plurality of output adapters each communicatively coupled to the processor and a respective one of the plurality of destination applications, each of the output adapters comprising an output data converter that converts a respective input data stream having the technology independent form to an output data stream having a technology dependent form associated with a destination protocol compatible with a respective destination application, and further comprising an output interface that transmits the output data stream to the respective destination application.

39. The system of claim 38, wherein each of the input data adapters implements logic for processing the respective input data stream having the technology dependent form.

40. The system of claim 38, wherein each of the output data adapters implements logic for processing the output data stream having the technology dependent form compatible with the respective destination application.

41. The system of claim 38, wherein the processor comprises a plurality of distributed processing units.

42. The system of claim 38, wherein the processor is coupled to a receive queue and a plurality of send queues, the receive queue receiving the input data streams from the input data adapters and the processor coordinating transmission of all or a portion of the input data streams having technology independent forms to the send queues.

43. The system of claim 42, wherein the processor communicates control signals to the send queues to coordinate transmission of the input data streams having technology independent forms to one or more of the output data adapters in an asynchronous or pseudo-synchronous manner.

44. A computer readable medium tangibly embodying a program executable for transporting data, comprising: receiving, from a source application, data comprising informational content in a technology dependent form associated with a source protocol; converting the data from the technology dependent form associated with the source application to a technology independent form not associated with the source protocol and not associated with destination protocols associated with one or more destination applications; identifying the one or more of the destination applications; transporting the data having the technology independent form; transforming the data from the technology independent form to a technology dependent form comprising a destination protocol associated with each of the one or more of the destination applications; and transmitting all or a portion of the data in the technology dependent form to the one or more of the destination applications.

45. The medium of claim 44, further comprising altering the data according to pre-established logic.

46. The medium of claim 45, wherein the pre-established logic is alterable by a user.

47. (New) The medium of claim 44, wherein identifying one or more destination applications comprises applying routing logic to facilitate transmission of the data to the destination applications.

48. The medium of claim 47, wherein the routing logic is alterable by a user.

49. The medium of claim 44, further comprising tracking the data during converting, identifying, or transforming operations.

50. The method of claim 49, further comprising logging errors occurring during converting, identifying, or transforming operations.

51. A system for transporting data, comprising: means for receiving data comprising informational content in a technology dependent form associated with a source protocol from a source application; means for converting the data from the technology dependent form to a technology independent form not associated with the source protocol and not associated with destination protocols associated with one or more destination applications; means for identifying the one or more destination applications; means for transporting the data having the technology independent form; means for transforming the data from the technology independent form to a technology dependent form comprising a destination protocol associated with each of the one or more of the destination applications; and means for transmitting all or a portion of the data in the technology dependent form to the one or more of the destination applications.

52. The system of claim 51, further comprising means for altering the data according to pre-established logic.

53. The system of claim 52, further comprising means for altering the pre-established logic by a user.

54. The system of claim 51, further comprising means for applying routing logic to facilitate transmission of the data to the destination applications.

55. The system of claim 54, further comprising means for altering the routing logic by a user.

56. The system of claim 51, further comprising means for tracking the data during converting, identifying, or transforming operations.
Description
FIELD OF THE INVENTION

The present invention relates generally to information systems, and more particularly, to a system and method for exchanging data among dissimilar applications.

BACKGROUND OF THE INVENTION

A number of proposed solutions have been advanced to address the problem of effecting the communication of data between computer system platforms and applications developed using distinctly different technologies. The increased reliance on distributed data processing systems and architectures, such as those employed to support Internet and Electronic Data Interchange (EDI) activities for example, has created a keenly felt need for improved methods of transporting vast amounts of data of various types and formats between applications having dissimilar interface characteristics.

In an attempt to address the problem of transporting dissimilar types of data between dissimilar systems and applications, various data interchange products and approaches have been developed. A traditional approach of electronically linking a number of disparate systems together involves the creation of custom gateways or interface systems. A typical custom gateway is created to solve a narrowly focused interface problem, such as permitting systems #1 and #2 to exchange data of types `A` and `B` produced by systems #1 and #2, respectively. Such specialized gateways are generally not intended nor designed to accommodate data interchange between a large number of disparate systems and applications. It is understood in the art that modifying an existing custom gateway to address a new and different interface problem is generally unproductive and costly, given the inherent limitations of the original gateway design.

Various information technology standards have been advanced in an attempt to address these and other data interchange problems experienced within a distributed data processing and communications environment. One such standard, referred to in the art as CORBA (Common Object Request Broker), has received much recent attention, as it would appear to solve many of these problems. A critical review of the CORBA approach, however, reveals that CORBA is not designed to act as a data transport mechanism. Rather, CORBA is primarily designed to pass control methods over TCP/IP. The strength of CORBA is its ability to use C++ methods over a network. CORBA requires that all applications must be object oriented, which precludes inclusion of a substantial number of existing applications developed using structured programming techniques. Moreover, although CORBA is referred to as a "standard," there are several product implementations of CORBA which are not compatible, and as such, are incapable of communicating with one another.

Other technologies, such as transaction monitors, have been developed primarily to control complex transactions between multiple applications in a distributed processing environment. Such transaction monitors typically interface applications through rigorous transaction rules applied through defined IDL (Interface Definition Language) interfaces across IPC (Inter Process Communication) methods. A typical transaction monitor has a complex structure that must be conformed to, and is complicated to use and maintain. If any one of the individual transactions that make up a transaction set fails, the entire complex transaction must be backed out, rather than the single failed transaction. Transaction monitors are generally optimized for transaction control, and not for effecting data interchange.

Fourth and fifth generation languages, termed 4GL and 5GL, would appear to offer a partial solution to the data interchange problem. These and other similar languages, such as those used to construct "business objects," are optimized around the construction of applications and user interfaces for the primary purpose of providing powerful querying and reporting tools. The objects created by such languages typically define access paths to data residing in databases. The objects can be combined in various ways to create complex queries and for building powerful report generators. Fourth and fifth generation languages are not well suited for transporting 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 carry with them a certain amount of data, this data is typically data resulting from a query that is transported with an object definition for the purpose of performing additional analysis on the data.

There exists a keenly felt need for a data exchange system and methodology that is capable of exchanging data of varying size, content, and format between dissimilar systems and applications. There exists a further need for such a system and methodology that is independent of any current or future technology. The present invention fulfills these and other needs.

SUMMARY OF THE INVENTION

The present invention is directed to a system and method for exchanging data between two or more applications. The data exchange system includes a data exchange engine and a number of adapters associated with a corresponding number of applications. Each of the adapters is customized to interface with a corresponding application and transforms the data being transferred between the application and the data exchange engine. Data produced by a particular application is converted from a technology dependent form to a technology independent form by the corresponding adapter.

In one embodiment, the format associated with a data stream is disassociated from the informational content of the data stream by the adapter. The informational content of the data stream is then transformed by the adapter into a common or generic format. The data exchange engine receives data in a technology independent form from each of its associated adapters and coordinates the routing of informational content to particular adapters associated with applications that have requested specific informational content. The adapters receiving the informational content from the data exchange engine transform the informational content having the common format into a data format compatible with, or specific to, their associated applications. In one embodiment, a queuing mechanism is employed to construct a reliable asynchronous or pseudo-synchronous interface between disparate applications and systems.

The data exchange engine may apply business rules or logic when processing a request for particular informational content. An application, for example, may require informational content produced by a number of different applications. The data exchange engine obtains, organizes, and processes the multiple source informational content as dictated by user-specific business logic. Changes to processing and organizational requirements for a particular user or application are effected simply by modifying the user-specific business logic, rather than data exchange engine code.

User-specified routing logic may be applied by the data exchange engine to dispatch selected informational content to one or more destination applications. As with the business logic, changes in routing requirements are effected simply by modifying the routing logic, rather than data exchange engine code.

Process monitoring, tracing, and logging are provided to track the progress of data passing through the data exchange engine and to detect and correct processing errors. In the case of a processing anomaly, the data exchange engine effects a rollback of failed transactions to preclude the loss of data. Performance statistics may also be provided.

A wide variety of interfaces may be developed by appropriate deployment of adapters and one or more data exchange engines. Proprietary back-end systems having only a single user-interface, for example, may be logically transformed into an open system having multi-user Web intefaces. Unreliable applications may be stabilized by employment of the data exchange infrastructure. Disparate business systems, whether they be archaic or state-of-the-art, may be effectively linked together to create electronic bonding gateways, for example.

The above summary of the present invention is not intended to describe each embodiment or every implementation of the present invention. Advantages and attainments, together with a more complete understanding of the invention, will become apparent and appreciated by referring to the following detailed description and claims taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system level diagram of a data exchange architecture in accordance with an embodiment of the present invention;

FIG. 2 illustrates in block diagram form the flow of data between disparate applications within information systems operated by two information service providers in accordance with a conventional approach;

FIG. 3 illustrates the deployment of a data exchange infrastructure within the information system environment of information provider #1 shown in FIG. 2;

FIGS. 4 and 5 illustrate additional embodiments of a data exchange infrastructure deployed to significantly enhance data interchange within existing information system environments;

FIG. 6 is a system block diagram of a data exchange architecture in accordance with another embodiment of the present invention;

FIG. 7 is a depiction of a number of adapters operating in cooperation to effect data exchange in accordance with one embodiment of the present invention;

FIG. 8 is a detailed system block diagram of another embodiment of a data exchange architecture operating in accordance with the principles of the present invention;

FIG. 9 illustrates additional details concerning various control and queuing features of a data exchange architecture operating in accordance with the principles of the present invention;

FIGS. 10-11 are flow diagrams illustrating various processes involving the transport of data through a data exchange engine in accordance with two additional embodiments of the present invention;

FIGS. 12-14 illustrate in flow diagram form various processes involving the transport of data through a data exchange engine in accordance with a further embodiment of the present invention;

FIG. 15 is an illustration of a Common Object in accordance with one embodiment of the present invention represented in containment tree form;

FIGS. 16A-16D illustrate the contents of a Common Attribute when used to represent various types of data supported in a Common Object of the type depicted in FIG. 15;

FIG. 17 is an illustration of an inheritance tree graphically depicting a Common Base Class associated with the Common Object shown in FIG. 15;

FIG. 18 is a class structure diagram showing public and non-public interfaces associated with various file based and database based queuing processes;

FIG. 19 is a pictorial description of the calling structure between data exchange queue classes when dequeueing a Common Object in accordance with one embodiment of the present invention; and

FIG. 20 is a pictorial description of the calling structure between data exchange queue classes when enqueueing a Common Object in accordance with the embodiment of FIG. 19.

While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail hereinbelow. It is to be understood, however, 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 falling within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE VARIOUS EMBODIMENTS

In the following description of the illustrated embodiments, references are made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration, various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, and structural and functional changes may be made without departing from the scope of the present invention.

For purposes of illustrating various features and advantages realized when implementing a data exchange architecture in accordance with the principles of the present invention, reference is made to the Figures, and more particularly, to FIG. 1. In accordance with this illustrative embodiment, it is assumed that dissimilar applications, identified as Applications #1, #2, #3, and #4, produce various types of dissimilar data. The term dissimilar applications as used herein is intended to refer to applications that differ in terms of technology, operation, supporting platforms and operating systems, data, input/output interfaces, communication protocols, and the like. The term dissimilar data is intended to refer to data types that differ in terms of format, structure, protocol, content, and the like.

It is further assumed that each of the Applications shown in FIG. 1 requires information produced by other Applications. Application #3, for example, produces informational content `C` which is required by Application `D,` and requires informational content `A` and `B` produced by Applications #1 and #2, respectively. As such, each of the Applications, although representing distinctly different technologies which may be supported on distinctly different platforms, are dependent upon one another for various informational content. Those skilled in the art well appreciate the difficulties of providing a mechanism to effect the required exchange of information between dissimilar Applications while concurrently addressing a myriad of technological interdependencies.

It can be appreciated that the traditional approach of implementing a customized interface to effect the exchange of information between two disparate applications generally solves a narrowly focused communications problem, but typically results in an inflexible solution intolerant to even slight changes in terms of format, function, or operation. Prior art solutions to developing such interfaces to permit communication between disparate applications are generally dependent upon the technologies inherent in either or both of the application software and/or platform hardware/software supporting the application. Such technology dependencies are well-understood as significantly limiting the ability to modify, expand, and scale an existing communications infrastructure, and significantly complicates or even precludes the integration of new information sources and technologies.

By way of example, and with further reference to FIG. 1, it is assumed that Application #1 produces data of type `A` which may be viewed as constituting two constituent components. The term data, within the context of the environment illustrated in FIG. 1, is assumed to include an informational content component and a format component. The informational content component represents raw information, typically business information, such as accounting information for example. The format component typically represents a technology-dependent construct that provides a means for electronically interacting with the informational content component. The format component, for example, may be defined to include data structures, protocols, scripts, control codes, and other technology-specific content. It is well appreciate in the art that many so-called "compatible" or "compliant" applications are in truth inherently technology-dependent, thus precluding seamless and reliable transport of information between two or more "compatible" applications. As was previously discussed, even standards-based applications are often incapable of communicating effectively with one another without intervening logic or protocol.

Returning again to FIG. 1, Application #1 produces data of type `A` which comprises informational content `A` associated with a format `A.` It is assumed in this illustrative example that Applications #2, #3, and #4 require selected portions of informational content `A` produced by Application #1. The data exchange engine 32, in cooperation with the adapters 34a-34d, facilitate the exchange of required portions of informational content `A` in the following manner. In response to a request for particular data from Application #1, selected data of type `A` is transmitted to the adapter 34a. The adapter 34a processes the type `A` data in such a way as to eliminate any technology dependencies associated with the type `A` data. In particular, the adapter 34a disassociates the informational content component `A,` alternatively referred to as informational content `A,` from its associated format component `A,` and transmits only the informational content `A` to the data exchange engine 32.

In accordance with one embodiment of the present invention, the adapter 34a reformulates the informational content `A` into a common or generic form which is subsequently operated on by the data exchange engine 32. Each of the adapters 34a-34d perform this process of reformulating a technology-specific data stream into a generic or common data form.

Assuming that Application #2 requires selected informational content `A` produced by Application #1, the data exchange engine 32 facilitates the transport of the content `A` information to adapter 34b associated with Application #2. The adapter
34b reformulates the informational content `A` having a common representation to a format `B` representation which is compatible with Application #2. The adapter 34d, in a similar manner, receives from the data exchange engine 32 specified informational content `A` reformulated from format `A` to the common or generic format. Adapter 34d reformulates the informational content `A` from the common representation to a type `D` format suitable for incorporation by application #4. As is also shown in FIG.
1, Application #3 requires selected informational content `A` from Application #1. The specified informational content `A` is converted to generic form by the adapter 34a, transmitted through the data exchange engine 32 to adapter 34c, and converted to a format `C` form for inclusion by Application #3.

It can be seen from FIG. 1 that disparate types of selected data may be effectively and reliably transported between dissimilar applications with relative ease through employment of a data exchange architecture in accordance with the principles of the present invention. The cooperative use of adapters associated with specific applications in conjunction with one or more data exchange engines either eliminates or renders innocuous technology dependencies inherent in the data transferred through the data exchange infrastructure. Such an implementation generally eliminates or significantly reduces the need for customized interfaces otherwise required to facilitate the transport of dissimilar types of data between dissimilar applications. In other words, the traditional N.times.N connectivity problem associated with traditional interfacing approaches may be effectively reduced to a 1.times.N connectivity scenario using a data exchange approach consistent with the principles of the present invention.

To facilitate a better appreciation for the advantages offered by the data exchange infrastructure implemented in accordance with the present invention, reference is made to FIGS. 2-3. In FIG. 2, there is depicted a number of Applications, Applications #1.sub.A -#N.sub.A, which interact within an information systems environment operated by an information provider #1. Information provider #2 operates an information system within which a number of disparate applications, represented by Applications #1.sub.B -#N.sub.B, interact in a specified manner. In addition to communicating information within each respective information systems environment, various types of information must be shared between the 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 inter-exchange carrier. It can be appreciated that the information system architecture associated with each of the information providers #1 and #2 typically represents a complex amalgam of archaic or legacy applications in addition to state-of-the-art applications. This hybrid environment has generally led to an increased dependency on customized data exchange interfaces needed to facilitate sharing of information between dissimilar applications within a given information provider's operating environment. Even simple modifications to a single application typically has significant upstream and downstream ramifications which often require costly and specialized interfacing solutions.

In the illustrative embodiment shown in FIG. 2, it is assumed that local exchange carrier #1 desires to enter the long distance market to expand its service and customer base. The recently passed Telecommunications Act of 1996, however, mandates that local exchange carrier #1 provide equivalent access to its local loops which permits inter-exchange carrier #2 to gain access to the applications and information supported within the information infrastructure operated by local exchange carrier #1. In order to comply with federal regulation, local exchange carrier #1 must tolerate intrusion into its internal information systems by inter-exchange carrier #2. It can be appreciated that the conventional approach of constructing customized electronic bonding gateways to facilitate communications between two dissimilar information provider environments would result in a costly and generally inflexible interface solution.

A data exchange infrastructure implemented in accordance with the principles of the present invention greatly simplifies the task of interfacing numerous disparate applications to facilitate reliable communication of information between two information provider environments such as those depicted in FIG. 2. As is shown in FIG. 3, a data exchange infrastructure in accordance with one embodiment of the present invention may be deployed to accommodate the access requirements of inter-exchange carrier #2 and the security considerations of local exchange carrier #1.

This illustrative solution offers a number of advantages heretofore not attainable using conventional interfacing approaches. In particular, expandability, flexibility, and scalability is introduced into the information system environment of the local exchange carrier #1 which was not previously realizable using the original architecture shown in FIG. 2. Moreover, none of the applications or data supported or produced by the applications (i.e., Applications 1.sub.A -N.sub.A) need be changed when deploying a data exchange infrastructure in accordance with the principles of the present invention.

In this illustrative example, each adapter A-N is associated with a corresponding data stream D.sub.1 -D.sub.N. Data stream D.sub.1, for example, may represent EDI data generated by Application #1 running on a back-end proprietary system. It is understood in the telecommunications industry that EDI represents a generally accepted standard for passing electronic messages between telecommunications service providers. However, it is also understood in the industry that various EDI dialects exist which necessitates some form of data transformation to occur in order to facilitate effective communication between back-end systems.

Adapter A is configured to disassociate the informational content transported within the EDI data stream D.sub.1 from its associated EDI format and dialect. The EDI informational content extracted by adapter A is reformatted to a common representation and then transported through the data exchange engine 62 to a destination application within the inter-exchange carrier #2 environment. The adapter 120, in this embodiment, is configured to translate the EDI information content having a common format to an EDI format and dialect required by the destination application. Adapter 120 also converts source EDI information transmitted from inter-exchange carrier #2 into the common or generic form.

The data exchange infrastructure depicted in FIG. 3 effectively isolates the proprietary information and systems of local exchange carrier #1 yet provides the required access to inter-exchange carrier #2 mandated by current federal regulations. In addition, deploying the data exchange architecture shown in FIG. 3 provides for the development of new interfaces not contemplated or easily achievable given the limitations of the original system architecture. For example, an adapter, such as adapter W, may be deployed to facilitate communication and data exchange via the Internet. By way of further example, a Web browser interface may be developed to convert a single-user interface of a proprietary back-end system to a multi-user, Web browser interface without the need to modify the back-end system or applications running thereon. A Web browser interface, represented as application WWW in Fig,. 3, may thus be implemented with little effort and cost.

In FIG. 4, there is illustrated another embodiment of an information interchange environment within which the data exchange infrastructure in accordance with the present invention may find particular application. The data exchange infrastructure may be implemented to enhance workflow or process management systems which interact with any number of legacy or proprietary applications, remote data stores, or various user and application work queues. In this embodiment, the data exchange infrastructure provides for reliable application integration, data movement, and remote work queues. In this configuration, unreliable system implementations, such as screen scraping applications or networks with poor line condition, may be transformed into reliable implementations through use of the data exchange infrastructure. In particular, this unreliable to reliable conversion is achieved, for example, through the use of persistent queues, rollback processing upon transaction failures, which provides for transactional integrity, and transaction retry processing as necessary.

FIG. 5 depicts a data 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 Web-based interfaces. In this regard, archaic or legacy applications may be provided with state-of-the-art interfaces to facilitate substantially enhanced 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 proprietary application. In response to a user inquiry, for example, selected data generated by the legacy or proprietary application is processed through the data exchange infrastructure to provide user access through a Web-based interface. As in previous examples, neither the EDI data nor the legacy/proprietary applications require modification, as all accommodations to dissimilar data formats and applications are provided for through the data exchange infrastructure.

Referring now to FIG. 6, there is illustrated an expanded depiction of one embodiment of a data exchange infrastructure implemented in accordance with the principles of the present invention. In this embodiment, the data exchange infrastructure provides for the effective and reliable transport of information among any number of disparate applications, data streams, and platforms associated with two or more information providers. Information provider #1, for example, produces data streams of various types which, when processed by associated adapters, are received by a data exchange engine 62 in a generic or common format. Associated with each of the data streams produced by information provider #1 is control or request information which is further processed by the data exchange engine 62. The information or raw data component associated with the control or request information is buffered in a data store 64.

The data exchange engine 62 cooperates with a routing logic module 66 to determine one or more destination applications within the information provider #2 systems environment that require particular data streams from information provider #1. It is noted that the content of a particular data stream, such as data stream A.sub.1, may have been requested by more than one information provider #2 application. Assuming that three such applications within the information provider #2 systems environment have requested all or selected portions of the data stream A.sub.1 content, three corresponding adapters are employed to convert the data stream A.sub.1 content from a generic format into corresponding pre-determined formats specified for the three destination applications.

The data exchange engine 62 also cooperates with a business logic module 68 to process the content of one or more data streams in a particular manner desired by a user. By way of example, an application running within the system environment operated by information provider #2 may require data that is derived through computation or manipulation from data streams B.sub.1 and C.sub.1 produced by corresponding applications running within the system environment operated by information provider #1. The data exchange engine 62 operates on data streams B.sub.1 and C.sub.1 in the manner dictated by user-specified business logic stored in the business logic module 68.

In contrast to a custom interface implemented in accordance with a prior art approach, the data exchange architecture illustrated in FIG. 6 and in other Figures provides a system administrator or end-user the ability to modify routing logic, business logic, or the format of a given data stream/application without requiring any modification to programs or configurations within the data exchange engine 62. By way of example, if an application or format of a particular data stream requires modification, such a change may be accomplished in the data exchange architecture by simply modifying the interface logic of the implicated adapter. If, by way of further example, a particular data stream produced by information provider #1 is required by two, rather than one, application within the information provider #2 systems environment, a simple change to the routing logic 66 and the addition of another adapter may be effected to satisfy this additional need. Further, if new or additional processing is required for a particular data stream in order to satisfy a new need by either a source or destination application, a simple change to the business logic 68 will satisfy this additional need.

It will be appreciated by the skilled artisan that the cooperation between easily modifiable adapters and one or more data exchange engines having user-modifiable routing and business logic provides for enhanced scalability, expandability, and flexibility to meet current and future information exchange requirements. In contrast to conventional interfacing schemes, a data exchange architecture implemented in accordance with the present invention is not subject to obsolescence, primarily due to its inherent ability to readily accommodate 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 in accordance with one embodiment of the present invention will now be described with reference to FIGS. 7 and 10. In FIG. 7, there is shown a number of systems, S.sub.1 -S.sub.N, which may or may not be similar in terms of platform configuration. Each of the systems, S.sub.1 -S.sub.N, implements one or more applications, A.sub.1 -A.sub.N, that produce various types of data, denoted as D.sub.1 -D.sub.N. As was discussed previously, each of the data types has an associated informational content component and format component, such as informational content component I.sub.1 and format component F.sub.1 associated with data type D.sub.1.

Each of the adapters 150, 170, 190 include an interface module 152, 172, 192 and an object converter 154, 174, 194, respectively. As is shown in FIG. 10, data of type D.sub.1 produced by application A.sub.1, for example, is received 280 by the interface module 152 of adapter 150. The interface module 152 typically includes a validation module which validates the type D.sub.1 data received from application A.sub.1. The object converter 154 converts 282 the informational content component I.sub.1 of the type D.sub.1 data to a Common Object data structure, CO.sub.1. Reference information, which may be viewed as control or identification information, associated with the Common Object or Objects is placed 284 onto an input queue of the data exchange engine 132.

The data exchange engine 132 processes and/or manipulates 286 the informational content I.sub.1 of the type D.sub.1 in a manner required by the business logic module 136. Routing logic 134 is used by the data exchange engine 132 to place 290 the processed informational content I.sub.1 on one or more selected output queues (not shown). One or more adapters (not shown) having a structure equivalent to adapter 150 and individually configured for specified destination applications convert 290 the informational content I.sub.1 from the common format to a specified output format for transmission 294 to one or more destination applications.

FIGS. 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, of a destination service provider. The adapter 208 receives 302 the message generated by the OSS. The application interface 208a of the adapter 208 receives the OSS message and data associated with the OSS message transmitted from the OSS. The OSS message and/or associated data is validated and converted 304 to a Common Object representation by the validater/converter 208b of the adapter 208. The API 208c of the adapter 208
represents an application programmer's interface that allows Common Objects to be readily constructed, manipulated, and enqueued. After the request has been converted into Common Object form, the adapter 208 invokes 306 an enqueue interface 208d to place the OSS message into the receive queue 240 of the data exchange engine 202. The informational content component or raw data associated with the OSS message is transferred to the data store 201 coupled to the data exchange engine 202.

A processing thread received from a processing thread pool 262 from the gateway core 204 is implemented 310 to dequeue any incoming requests by relative priority. The API for the custom-specific rule code is then invoked 312 to process the incoming request in compliance with customer-specific business rules received from the rules module 232. After the business rules have been applied, requests to one or more destination OSS applications are then routed 316 to a corresponding send queue
242, 244, 246 for delivery. An adapter, such as adapter 218, associated with a specific destination OSS may then invoke a corresponding dequeue API 318 associated with its corresponding send queue 244. The API 218b and converter 218c cooperate to convert 320 the requested information represented in Common Object form to a format and structure specified by the particular OSS. The converted data is then transmitted from the application interface 218d of the adapter 218 to its corresponding OSS.

FIGS. 12-14 provide additional processing details concerning the transport of data through employment of a data exchange infrastructure in accordance with an embodiment of the present invention. As is shown in FIG. 12, a packet of data is received 332 from an external source. The received data then undergoes a validation process 334. If the data is considered corrupt 336, an error in the data packet received from the external source is verified 338, and, in response, is removed or deleted 340 for purposes of further processing. If the data from the external source is determined to be valid 336, a data exchange transaction is then initiated 342.

The data received from the external source is then packed 344 into a Common Object in accordance with meta-data rules and identified using a unique name or tag. The Common Object is then enqueued 346 on the incoming queue of the data exchange engine. The data exchange transaction is then committed. If the transaction is not successful 350, a rollback of the transaction is then initiated 352. If the transaction is successful 350, the data packet from the external data source is then removed or deleted 354. The above-described process is then repeated for subsequent data packets received from the external source 332.

Referring now to FIG. 13, additional details concerning a data exchange transaction will now be described. When a data exchange transaction is initiated 362, a prioritization scheme is employed to dequeue 364 the next Common Object from the incoming queue of the data exchange engine. During the dequeue operation, the custom rule/route API associated with the Common Object is called 366. If the custom rules are successfully applied 368, another data exchange transaction is initiated 362. If the custom rules cannot be applied successfully 368, the data exchange engine 370 determines the default routing of the Common Object from the configuration routing table.

If the routing has not been previously defined 372, the Common Object is enqueued 374 on an error queue. If routing has been previously defined 372, the Common Object, or a clone of the Common Object if more than one enqueue operation is applicable, is enqueued on every outgoing queue identified in the routing table. The data exchange transaction is then committed 378 and if successful 380, the associated data packet is removed or deleted 384 from the external data source. If the data exchange transaction is not successful 380, roll-back of the transaction is initiated 382. A subsequent data exchange transaction 362 is then initiated.

Additional steps associated with Common Object dequeueing are shown in FIG. 14. Assuming that a data exchange transaction has been initiated 392, the data exchange engine dequeues 394 the next priority Common Object from a configured outgoing queue. The data associated with the Common Object in the outgoing queue is then validated 396 and packed into a specified structure having a format and name appropriate for the outgoing or destination external data source. If the data validation process is not successful 398, then the data is deemed corrupt and the Common Object is enqueued 400 on the error queue. If the data is valid 398, the external data packet is transmitted 402 to the outgoing or destination external data source. The data exchange transaction is then committed 404 and if deemed successful 406, a subsequent data exchange transaction is initiated 392. If unsuccessful, the transaction is subject to rollback 408 by the engine exchange.

Referring once again to FIG. 9, a processing thread pool 262 stores a number of processing threads which are selectively implemented when performing dequeue operations. The processing thread pool 262 represents a pool of threads whose number is externally controlled. Its function is to provide a thread of control for the custom logic portions of the system. This thread will control the dequeueing of requests, the invocation of the rule/routing stub API, and the enqueueing of the send request. A processing thread may make use of additional system resources, including persistent storage 268, writing to and reading from the error queue 272, and writing to an error log 274.

Also shown in FIG. 9 is a statistics monitor module 264 and an associated statistics log 276 which are used to provide monitoring and tracking of data as it moves through the data exchange system. The statistics monitor module 264 also provides historical performance information on queues and historical information on system resource usage. As will be described in greater detail hereinbelow, the statistics monitor module 264 provides a means for logging and tracing a given application. Logging reveals the state of the application at the time of an error, while tracing provides a description of all software events as they occur. The tracing information may be used for tracking the application, state, and other related operations. The tracing information may be used in conjunction with the logging information to determine the cause for an error since it provides information about the sequence of events prior to an error.

FIGS. 15-20 illustrate various aspects of one embodiment of a data exchange infrastructure implemented in an object oriented program environment. It is to be understood that the foregoing description represents one of many possible approaches to implementing a data exchange architecture in accordance with the principles of the present invention, and that other hardware and software implementations may alternatively be employed, such as an implementation using structured programming techniques.

The architecture for implementing the data exchange infrastructure in accordance with this embodiment is intended to provide a series of modular building blocks that may be used in varying combinations to implement a wide range of information exchange solutions. Each of the blocks described below is intended to provide an abstract level of functionality, where the underlying components and their specific implementation are transparent to the user, such as developers and administrators.

The basic architecture described hereinbelow provides a queue interface, basic system infrastructure, and stub API hooks that allow implementation of customer specific code. The blocks described within this architecture may be organized as a single or separate executables. All modules within the context of this embodiment are intended to be completely modular.

As was briefly described previously, all requests processed within this architecture are converted into a Common Object format that provides for a generic construction and behavior for all requests. All request and request field naming is externally defined in a meta-data store which provides for data definition and/or processing behavior changes without modification of the data exchange engine code.

The basic architecture configuration is intended to provide for a highly scaleable system. All gateway operations can run multiple distributed instances since, in this embodiment, the only shared resource is the request queuing mechanism. System resource allocations may be controlled by an external configuration file and may be dynamically configurable. The various alterable resources include number of processing threads, system and message timeout thresholds, and audit trail and message logging levels. All extensions to business logic may be implemented in customer specific code that is invoked through a stub API.

As was described previously, one function performed by an adapter is to disassociate the informational content of a particular data stream from its associated format, protocol, and/or structure. The adapter then transforms the informational content into a Common Object form which represents a generic format used for containing all information transported through and processed by the data exchange engine. FIG. 15 is a depiction of one embodiment of a Common Object represented graphically as an object containment tree.

A Common Object within the context of this illustrative embodiment represents a C++ container object that is used to contain multiple portions of attribute data within a single flexible object. A Common Object comprises two lists, a Private List and a Public List. Both lists contain one or more attribute/value pairs (AV pairs). These AV pairs represent objects referred to as Common Attribute Objects, each of which comprises an attribute name, value, and type. Common Attribute classes are available for all of the basic types plus some complex types as well.

The Public List represents a sequence of two types of user-defined attributes, which are instances of an Attribute class or a Common Object. The Private List contains attributes that are used internally by the system for a variety of purposes, such as naming, routing, and identifying ancestry information. The Public List contains data that the user has defined, which may include other Common Objects. Each list may contain two types of attributes, type specific AV pairs or objects. Contained objects may either be List Objects or other Common Objects. The Private List does not include contained objects since this List is only used for simple tags or header information.

The following illustrative examples are intended to demonstrate the behavior of attributes within the Common Object. A type specific attribute within a Common Object named "Employee" might be of type String with an attribute name of "Name" and a value of "John Doe." A List Object is typically used to represent multi-value attributes, where a single attribute name can represent multiple values or multiple Common Objects. For example, a List Object may be used within a Common Object named Department. The "Employees" attribute may constitute a List Object containing numerous "Employee" Common Objects.

As can be seen in the illustration of a Common Object shown in FIG. 15, each node in the containment tree represents an attribute identified by its name. The Distinguished Name of an attribute represents the containment path from the root node to the node represented by the attribute. In accordance with this scheme, it is mandatory that each attribute have a unique Distinguished Name within the object containment tree. By way of example, a Common Object named "foo" may have an attribute name "bar." The Distinguished Name for this attribute is thus "foo.bar." If a second attribute were added, it would require a unique name such as "bar1" and would be addressed as "foo.bar1." This unique naming requirement is automatically enforced by the Common Object.

The Common Object provides the ability to access attributes that are contained in both the Private List and the Public List. The Private List attributes are developer or system defined attributes used as tags that allow the encoding of information that is used in later processing of the object. The Private List attributes are generally not seen by the user since they are developer defined and not user defined. The Public List is used to contain all user-defined attributes, meaning those that specify what the data looks like and how it is named. All logic developed to process data through the data exchange environment is based on the attributes and their values contained in the Public List.

The Common Base Class is an abstract base from which the Common Object Class is derived. An inheritance tree graphically depicting the Common Base Class is shown in FIG. 17. The main purpose of this class is to provide a single object naming and typing mechanism to aid in object tree searches and traversals. The Common Base Class is characterized in the following code-level example.

EXAMPLE #1

class: DX_CommonBase : public RWCollectable { RWDECLARE_COLLECTABLE(DX_CommonBase); protected: char* Name; int Type; void SetName(const char* inName); public: char* GetName() { return name; } int GetType() { return type; } virtual void PrintContents()=0; char* GetTypeName(int type); };

The following constant types are used within the data exchange environment and may be defined and located in a header file named "DX.sub.13 Defs.h".

EXAMPLE #2

enum EclassTypes { DX_OBJECT = 0, DX_ATTRIBUTE, DX_LIST, DX_MULTIVALUE, DX_INTEGER, DX_STRING, DX_STRINGVAL, DX_DATE, DX_TIME, DX_REAL, DX_BLOB, DX_BLOBVALUE, DX_VERSION, DX_OID_CLASS }; enum EreturnCodes { NOT_FOUND = 0, SUCCESS, FAILED, TIME_OUT, ACCESS_DENIED, DUPLICATE_OBJECT, NO_OBJECT, NO_ATTRIBUTE, INVALID_ATTRVAL, INVALID_ARGS, INVALID_OPERATION, SYSTEM_ERROR }; enum EstorageTypes { FLATFILE = 0, DATABASE }; enum ElistType { PUBLIC = 0, PRIVATE }; static const int MAX_NAME_LEN=255; static const int MAX_DOTTED_NAMELEN=8096; static const int MAX_MULTI_VAL=255; static const int MAX_BLOB_SIZE=2048; static const int OID_LEN=128; static const int MAX_FILE_NAME=256; static const int MAX_PID_LEN=12; static const int MAX_LINE_SIZE=100;

Various Common Object access methods have been developed to provide the ability to access attributes contained within the Common Object. Several of these methods involve Boolean operations, thus producing either a pass (i.e., true) or a fail (i.e., false) result. Any specific failures are logged within the called method. Any application specific error handling that depends on a called method should be added by the application developer. The Common Object is characterized in the following code-level example.

EXAMPLE #3

class: DX_CommonObject: public DX_CommonBase { RWDECLARE_COLLECTABLE(DX_CommonObject); friend class DX_ListObject; friend class DX_FileSubQueue; public: virtual.about.DX_CommonObject(); // Constructors /*****************************************************************/ //If name==NULL, the name is set to "NOT_SET". //If name is ""or contains a "." it will be set to "INVALID_NAME" /*****************************************************************/ DX_CommonObject(const char* name=0); /*****************************************************************/ //Create a copy of an entire DX_CommonObject, //but with it's own unique OID value /*****************************************************************/ DX_CommonObject* Clone(); /*****************************************************************/ //All AddAttribute and AddPvtAttribute methods take ownership of //the pointers passed in to them. Do NOT delete the pointers after //a call to AddAttribute and AddPvtAttribute. The pointers will be //deleted when the container DX_CommonObject or DX_ListObject is deleted. // //NOTE: When using the following two methods for creating a DX_STRING attribute // // AddAttribute(const char* name, const int type, const void* value) // and AddPvtAttribute(const char* name, const int type, const void* value) // // the value is defaulted to be of type const char* and not UNICHAR* // Misuse will lead to unexpected behavior. /*****************************************************************/ EreturnCodes AddAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddAttribute(DX_ListObject* newAttr); EreturnCodes AddAttribute(DX_CommonObject* newAttr); EreturnCodes AddAttribute(const char* name, const int type, const void* value); EreturnCodes AddPvtAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddPvtAttribute(DX_ListObject* newAttr); EreturnCodes AddPvtAttribute(DX_CommonObject* newAttr); EreturnCodes AddPvtAttribute(const char* name, const int type, const void* value); /*****************************************************************/ //DeleteAttribute and DeletePvtAttribute will remove the named attribute //from the container DX_CommonObject or DX_ListObject and delete the named //attribute's pointer /*****************************************************************/ EreturnCodes DeleteAttribute(const char* name); EreturnCodes DeletePvtAttribute(const char* name); /*****************************************************************/ //RemoveAttribute will remove the named attribute from the container //DX_CommonObject or DX_ListObject but will not delete the named //attribute's pointer /*****************************************************************/ EreturnCodes RemoveAttribute(const char* name); EreturnCodes RemovePvtAttribute(const char* name); /*****************************************************************/ //Do NOT delete the pointer that is returned to you, it still is owned by //the container DX_CommonObject or DX_ListObject. You CAN use the any of //the attribute class methods for the pointer. /*****************************************************************/ void* GetAttribute(const char* name); void* GetPvtAttribute(const char* name); void PrintContents(); //The caller of Demarshal is responsible for object's memory allocation static DX_CommonObject* Demarshal(char* ObjOid, int type, int ContextIndex); EreturnCodes Marshal(int type, int ContextIndex); static EreturnCodes DeleteStorage(const char* oidVal, int type, int ContextIndex); //The caller of GetOID is responsible for deleting the memory of the returned char* char* GetOID(); EPriorityCode GetPriority(); protected: void* Find(const char* name); static EreturnCodes RestorePersistentObject(const char* oidVal); static EreturnCodes DeletePersistentObject(const char* oidVal, int type); private: //Data Members DX_ListObject* PrivateList; DX_ListObject* PublicList; static void Delete(RWDlistCollectables* list); static int Copy(RWDlistCollectables* dest, const RWDlistCollectables *src); static EreturnCodes CopyPersistentObject(char* filename); static EreturnCodes CopyFile(char* filename,char* copyfilename); void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); const int check() const; DX_Boolean updateListOids(DX_ListObject* Plist, DX_OID *Poid); DX_Boolean updateObjectOids(DX_CommonObject* Pobj, DX_OID *Poid); DX_Boolean ValidateNaming(const char* name); #ifdefDX_DATABASE EreturnCodes InsertIntoTable(char* filename, int ContextIndex); static EreturnCodes RetrieveFromTable(char* filename, char* oid, int ContextIndex); EreturnCodes UpdateTable(char* filename, int ContextIndex); #endif //use to cal. the number of bytes needed to store an object using RWFile RWspace binaryStoreSize() const;}; };

The following methods are implicated when accessing the Public List: AddAttribute; GetAttribute; DeleteAttribute, and RemoveAttribute. The following methods are implicated when accessing the Private List: AddPvtAttribute; GetPvtAttribute; DeletePvtAttribute, and RemoveAttribute. The AddAttribute, DeleteAttribute, and RemoveAttribute methods for manipulating a Common Object are characterized in greater detail in the following code-level examples:

EXAMPLE #4 AddAttribute: Adds attribute to CommonObject tree EreturnCodes AddAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddAttribute(DX_ListObject* newAttr); EreturnCodes AddAttribute(DX_CommonObject* newAttr); EreturnCodes AddAttribute(const char* name, const int type, const void* value); EreturnCodes AddPvtAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddPvtAttribute(DX_ListObject* newAttr); EreturnCodes AddPvtAttribute(DX_CommonObject* newAttr); returnCodes AddPvtAttribute(const char* name, const int type, const void* value);

EXAMPLE #5 DeleteAttribute: Removes attribute from CommonObject tree and destroys attribute EreturnCodes DeleteAttribute(const char* name); EreturnCodes DeletePvtAttribute(const char* name);

EXAMPLE #6 RemoveAttribute: Removes attribute from CommonObject tree EreturnCodes RemoveAttribute(const char* name); EreturnCodes RemovePvtAttribute(const char* name);

The following Common Object retrieval methods are used internally by the GetAttributeValue( ) and SetAttributeValue( ) methods to search the attribute list of a Common Object and to locate a specific Common Attribute instance. These retrieval methods may be used by application developers as well. Each of these methods require a fully dot(.) delimited Distinguished Name and will recursively walk all relative levels of nesting to retrieve the relevant object/attribute.

EXAMPLE #7 void* GetAttribute(const char* name);

where, GetAttribute returns a pointer to a Common Attribute derived object or Common Object stored within a Common Object's Public List.

EXAMPLE #8 void* GetPvtAttribute(const char* name);

where, GetPvtAttribute returns a pointer to a Common Attribute derived object from within a Common Object's Private List.

The following Common Object methods require that the attribute name be represented in its dot(.) delimited fully distinguished name. This naming convention should be followed at all levels of object nesting starting from the name of the object instance from which the method is invoked. These methods also require the user to provide and manage memory allocation for attribute values. Additional usage examples are given as follows:

EXAMPLE #9 EreturnCodes AddAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddAttribute(DX_ListObject* newAttr); EreturnCodes AddAttribute(DX_CommonObject* newAttr); EreturnCodes AddAttribute(const char* name, const int type, const void* value); EreturnCodes AddPvtAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddPvtAttribute(DX_ListObject* newAttr); EreturnCodes AddPvtAttribute(DX_CommonObject* newAttr); EreturnCodes AddPvtAttribute(const char* name, const int type, const void* value); EreturnCodes DeleteAttribute(const char* name); EreturnCodes DeletePvtAttribute(const char* name); EreturnCodes RemoveAttribute(const char* name); EreturnCodes RemovePvtAttribute(const char* name);

Further examples of AddAttribute and AddPvtAttribute method usage are provided as follows:

EXAMPLE #10 i int *xx=new int(321); if (PtestObj->AddPvtAttribute("TestObject.PvtIntAttr", DX_INTEGER, (void*)xx)==SUCCESS) { . . . } delete xx;

A further example of GetAttribute method usage is provided as follows:

EXAMPLE #11 DX_XXX*PtrAttr=objInstance->GetAttribute("commonObjName.attrName"); DX_XXX*PtrAttr=objInstance->GetAttribute("commonObjName.listObjName .attrName");

A further example of GetAttributeValue method usage is provided as follows:

EXAMPLE #12

struct DX_AttributeValue tmpAttrVal; if (PtestObj->GetAttributeValue("TestObject.IntAttr", tmpAttrVal) == SUCCESS) { int* newInt = (int*)tmpAttrVal.value; if (newInt) { // do something delete newInt; } }

A further example of SetAttributeValue method usage is provided as follows:

EXAMPLE #13 int* newVal=new int(555); if (PtestObj->SetAttributeValue("TestObject.IntAttr", (void*)newVal)==SUCCESS) { . . . } if (newVal) delete newVal;

In general, each Common Object is given a unique Object Identifier or OID so that any child or related objects can be associated with each other. All objects created as a result of this original OID require that this initial OID be stored as part of the object, regardless of whether the new object is a direct child object or whether the original object still exists. If the original OID were not stored, it would not be possible to correlate response objects with the initial request object. The OID value is automatically set during instantiation. Parent OID values are updated automatically when AddAttribute( ) is invoked, including all Common Objects that are contained within a ListObject.

The OID is typically a concatenation of count, pid, time, hash, and hostid in order to guarantee its uniqueness. An illustrative example is provided as follows:

EXAMPLE #14

class: DX_OID: public DX_ComrnonAttribute { RWDECLARE_COLLECTABLE(DX_OID); friend class DX_SysConfigObject; friend class DX_CommonObject; friend class DX_ListObject; protected: DX_OID(char* value); DX_OID(const char* name, char* value); public: // constructors DX_OID(); virtual.about.DX_OID(); /*****************************************************************/ // Get a copy of type specific value. User should new a pointer for the // return value and then delete the pointer after use /*****************************************************************/ EreturnCodes GetAttributeValue(void* value); EreturnCodes GetAttributeValue(char* value); void PrintContents(); private: static unsigned long OIDCOUNT; #ifndef HPUX static DX_Mutex lockOidCount; #endif char *AttrValue; char *storeFileName; char *storeDirName; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); EreturnCodes SetAttributeValue(void* value); char* GetDirName(); char* GetFileName(); static DX_Boolean CheckOIDFormat(char* oidVal); };

The use of reference counting greatly reduces the amount of time and memory that is required to copy objects. Use of a third-party foundation class library, such as one developed by Rogue Wave Software, Inc., automatically supplies a number of the copy constructors. Also, methods within the DX_CommonObject class itself make use of the Rogue Wave copy methods as well. It is noted that the DX_StringAttribute and DX_BlobAttribute classes provide their own copy optimization through reference counting, as objects of these classes could be of a substantial size.

The Common Attribute is an object that is contained within a Common Object and is used to contain attribute data. The Common Attribute contains a private attribute that denotes the specific attribute type and a set of public attributes for name and value. A Common Attribute may be a simple attribute of a specific data type, name, and value or it may contain another object, such as a List Object or Common Object. The type specific Common Attribute classes all inherit their capabilities from the generic Common Attribute class so all classes will behave in an equivalent manner. Reference is made to FIGS. 16A-16D, which illustrate the contents of a Common Attribute when used to represent some of the supported data types.

The Common Attribute class is an abstract base class from which type specific Attribute classes are derived, a characterizing example of which is given as follows:

EXAMPLE #15

class: DX_CommonAttribute : public DX_CommonBase { public: virtual EreturnCodes GetAttributeValue(void* value) = 0; virtual EreturnCodes SetAttributeValue(void* value) = 0; virtual void PrintContents()=0; };

The following attribute value access and modification methods, termed GetAttributeValue and SetAttributeValue, are intended to provide access to the attribute value. It is noted that the caller is responsible for the memory allocated in the storage type. Two usage examples are provided as follows:

EXAMPLE #16 DX_CommonAttribute* Pattr=0; Pattr=(DX_CommonAttribute*)PrestoredObj->GetAttribute("TestObject. ListObject.IntAttrInList3"); int* intVal=new int; if (PmyOID && PmyOID->GetAttributeValue(intVal) !=SUCCESS) { . . . } if (intVal) delete inVal;

EXAMPLE #17 int* newVal=new int(555); if (PtestObj->SetAttributeValue("TestObject.IntAttr", (void*)newVal)==SUCCESS) { . . . } if (newVal) delete newVal;

In one embodiment, a set of overloaded operators are provided for performing attribute value comparison operations. In another embodiment, the following comparison operators are supported for Attributes: "==" or equal operator; "!=" or not equal operator; ">" or greater than operator; and "<" or less than operator.

The following non-exhaustive list of attribute types supported by the Common Attribute are given as follows: Integer; String; Date; Time; Real; Blob; Version, MultiValue, ListObject, and ListObjectIterator. It is noted that the MultiValue attribute type represents a container attribute that may have multiple values, and that the ListObject attribute type typically contains a number of attributes or objects to represent a multi-valued attribute. It is further noted that Object version control is implemented by using a private Version object attribute. Any changes to object or attribute makeup will be converted transparently when any new version is introduced.

Code-level examples of various type specific attribute classes that are supported are provided as follows:

EXAMPLE #18

attribute class: DX_IntegerAttribute /******************************************************************** * CLASS NAME : DX_IntegerAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides storage for integer attributes ********************************************************************/ class DX_IntegerAttribute:public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_IntegerAttribute); public: /********************************************************************/ // If name==NULL, the name is set to "NOT_SET". // If name is ""or contains a "." it will be set to "INVALID NAME" /*************************************************************/ DX_IntegerAttribute(const char* name=0); DX_IntegerAttribute(const char* name, int value); virtual.about.DX_IntegerAttribute(); /*************************************************************/ // The memory for the value argument is allocated and deallocated // by the caller. The library function GetAttributeValue just writes // to the value argument and the SetAttributeValue just reads the // argument to reset the value of the attribute /*************************************************************/ EreturnCodes GetAttributeValue(void* value);// argument assumed to be int* EreturnCodes GetAttributeValue(int& value); EreturnCodes SetAttributeValue(void* value);// argument assumed to be int* EreturnCodes SetAttributeValue(int value); void PrintContents(); private: int AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #19

attribute class: DX_StringAttribute /******************************************************************** * CLASS NAME : DX_StringAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides storage of strings. ********************************************************************/ class DX_StringAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_StringAttribute); public: /*************************************************************/ // If name==NULL, the name is set to "NOT_SET". // If name is "" or contains a "." it will be set to "INVALID NAME" /*************************************************************/ DX_StringAttribute(const char* name=0), DX_StringAttribute(const char* name, const char* value); DX_StringAttribute(const char* name, const UNICHAR* value); DX_StringAttribute(const char* name, const DX_String& value); virtual.about.DX_StringAttribute(); /*************************************************************/ // Get a copy of char* value. The library will allocate the // appropriate storage, the user should delete the pointer after use. /*************************************************************/ EreturnCodes GetAttributeValue(void* value);// assumes char** is passed // Get a copy oftype specific value. The library will allocate the // appropriate storage, the user should delete the pointer after use. /*************************************************************/ EreturnCodes GetAttributeValue(char* &value); EreturnCodes GetAttributeValue(UNICHAR* &value); EreturnCodes GetAttributeValue(DX_String* &value); /*************************************************************/ // The memory for the value argument is allocated and deallocated // by the caller. The library functions just read the value // argument to reset the value of the attribute. // NOTE: the method taking (void* value) assumes const char* /*************************************************************/ EreturnCodes SetAttributeValue(void* value); EreturnCodes SetAttributeValue(const char* value); EreturnCodes SetAttributeValue(const UNICHAR* value); EreturnCodes SetAttributeValue(const DX_String& value); void PrintContents(); private: DX_String* AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #20 class: DX_String The DX_String class is a reference counted container class used by the DX_StringAttribute to store the attribute's value. It provides the user a way to keep down the overhead associated with having to copy the data.

class DX_String : public RWCollectable { RWDECLARE_COLLECTABLE(DX_String) friend class DX_StringAttribute; public: DX_String(); DX_String(const char* value); virtual.about.DX_String(); void PrintContents(); private: char* StringValue; int* len; int* refCount; DX_String& operator=(const DX_String& rhs); void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #21

attribute class: DX_DateAttribute /******************************************************************** * CLASS NAME : DX_DateAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides storage for Date attributes * * NOTE: This class only stores the date related fields of the struct tm* * The time related fields are initialized to 0, any data passed in * the struct tm* time related fields will be discarded. ********************************************************************/ class DX_DateAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_DateAttribute); public: /*************************************************************/ // If name==NULL, the name is set to "NOT_SET". // If name is ""or contains a "." it will be set to "INVALID_NAME" /*************************************************************/ DX_DateAttribute(const char* name=0); DX_DateAttribute(const char* name, const struct tm value); virtual DX_DateAttribute(); /*************************************************************/ // The struct tm passed as an argument for GetAttributeValue // is to be allocated and deallocated by the caller // The library function just copies the value into the // structure. /*************************************************************/ EreturnCodes GetAttributeValue(struct tm& value); EreturnCodes GetAttributeValue(void* value); // assumes struct tm* is passed /*************************************************************/ // The memory for the value argument is allocated and deallocated // by the caller. The library functions just read the value // argument to reset the value of the attribute /*************************************************************/ EreturnCodes SetAttributeValue(void * value); EreturnCodes SetAttributeValue(const struct tm value); void PrintContents(); private: RWCollectableDate *AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #22

attribute class:DX_TimeAttribute /**************************************************************** ** CLASS NAME : DX_TimeAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides storage of time values in form of SSE. ****************************************************************/ class DX_TimeAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_TimeAttribute); public: /*********************************************************/ // If name==NULL, the name is set to "NOT_SET". // If name is ""or contains a "." it will be set to "INVALID_NAME" /*********************************************************/ DX_TimeAttribute(const char*name=0); DX_TimeAttribute(const char*name, unsigned long value); virtual.about.DX_TimeAttribute(); /*********************************************************/ // The memory for the value argument is allocated and deallocated // by the caller. The library function GetAttributeValue just writes // to the value argument and the SetAttributeValue just reads the // argument to reset the value of the attribute /*********************************************************/ // argument assumed to be unsigned long* EreturnCodes GetAttributeValue(void* value); EreturnCodes GetAttributeValue(unsigned long& secondSinceEpoch); // argument assumed to be unsigned long* EreturnCodes SetAttributeValue(void* value); EreturnCodes SetAttributeValue(const unsigned long value); void PrintContents(); private: RWCollectableTime* AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #23

attribute class:DX_RealAttribute /**************************************************** * CLASS NAME : DX_RealAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides storage of float types ****************************************************/ class DX_RealAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_RealAttribute); public: /**************************************************/ //If name==NULL, the name is set to "NOT_SET". //If name is ""or contains a "." it will be set to //"INVALID_NAME" /***************************************************/ DX_RealAttribute(const char* name=0); DX_RealAttribute(const char* name, float value); virtual .about.DX_RealAttribute( ); /***************************************************/ //The memory for the value argument is allocated and //deallocated by the caller. The library function //GetAttributeValue just writes to the value argument //and the SetAttributeValue just reads the argument //to reset the value of the attribute /***************************************************/ EreturnCodes GetAttributeValue(void* value); //argument assumed to be float* EreturnCodes GetAttributeValue(float& value); EreturnCodes SetAttributeValue(void* value); //argument assumed to be float* EreturnCodes SetAttributeValue(float value); void PrintContents( ); private: float AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #24

attribute class:DX_BlobAttribute /******************************************************* * CLASS NAME : DX_BlobAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Attribute storage class to store raw * binary stream * stored in a unsigned char* * Takes/returns DX_Blob struct *******************************************************/ class DX_BlobAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_BlobAttribute); public: /**************************************************/ //If name==NULL, the name is set to "NOT_SET". //If name is "" or contains a "." it will be set to //"INVALID_NAME" /***************************************************/ DX_BlobAttribute(const char* name=0); DX_BlobAttribute(const char* name, const DX_Blob& value); DX_BlobAttribute(const char* name, unsigned char* value, unsigned int size); virtual .about.DX_BlobAttribute( ); /**************************************************/ //Get a copy of DX_Blob* value. The library will allocate the //appropriate storage, the user should delete the pointer after use. /**************************************************/ EreturnCodes GetAttributeValue(void* value);//assumes DX_Blob** /**************************************************/ //Get a copy of type specific value. The library will allocate the //appropriate storage, the user should delete the pointer after use. /**************************************************/ EreturnCodes GetAttributeValue(DX_Blob* &value); EreturnCodes GetAttributeValue(unsigned char* &value); /**************************************************/ //The memory for the value argument is allocated and //deallocated by the caller. The library functions just read //the value argument to reset the value of the attribute. // //NOTE: the method taking (void* value) assumes //const DX_Blob* /***************************************************/ EreturnCodes SetAttributeValue(void* value); EreturnCodes SetAttributeValue(const DX_Blob& value); EreturnCodes SetAttributeValue(const unsigned char* value, unsigned int size); unsigned int GetBlobSize( ); void PrintContents( ); private: DX_Blob* AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #25

class: DX_Blob The DX_Blob class is a reference counted container class used by the DX_BlobAttribute to store the attribute's value. It provides the user a way to keep down the overhead associated with having to copy the data. class DX_Blob : public RWCollectable { RWDECLARE_COLLECTABLE(DX_Blob); friend class DX_BlobAttribute; friend class DX_MultiValueAttribute; public: DX_Blob( ); DX_Blob(const unsigned char *value, unsigned int size); .about.DX_Blob( ); DX_Blob& operator=(const DX_Blob& rhs); void PrintContents( ); unsigned int GetBlobSize( ); EreturnCodes GetValue(unsigned char** value); private: int* refCount; unsigned int* BlobSize; unsigned char* BlobValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #26

attribute class:DX_VersionAttribute /******************************************************** * CLASS NAME : DX_VersionAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides a integer value that * : can be used to mark the version of * : an object in process. *******************************************************/ class DX_VersionAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_VersionAttribute); public: /***************************************************/ //If name==NULL, the name is set to "NOT_SET". //If name is "" or contains a "." it will be set to //"INVALID_NAME" /**************************************************/ DX_VersionAttribute(const char* name=0); DX_VersionAttribute(const char* name, int value); virtual .about.DX_VersionAttribute( ); /**************************************************/ //The memory for the value argument is allocated and //deallocated by the caller. The library function //GetAttributeValue just writes to the value argument //and the SetAttributeValue just reads the argument //to reset the value of the attribute /**************************************************/ EreturnCodes GetAttributeValue(void* value); //argument assumed to be int* EreturnCodes GetAttributeValue(int& value); EreturnCodes SetAttributeValue(void* value); //argument assumed to be int* EreturnCodes SetAttributeValue(int value); void PrintContents( ); private: int Attrvalue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

A MultiValue attribute by definition is a single named attribute that contains multiple individual values of the same type where the multiple individual values make up the attribute's single value. These multiple values are generally not individually addressable from the attribute level. Examples of a MultiValue attribute and usage of same are given in the following examples.

EXAMPLE #27

/******************************************************** * * CLASS NAME : DX_MultiValueAttribute * INHERITED FROM : None * INHERITS : DX_CommonAttribute * DESCRIPTION : Provides storage of multiple values * for a single attribute instance given * that all attribute values MUST be the * same type. ********************************************************/ class DX_MultiValueAttribute : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_MultiValueAttribute); public: /***************************************************/ //If name==NULL, the name is set to "NOT_SET". //If name is "" or contains a "." it will be set to //"INVALID_NAME" /**************************************************/ DX_MultiValueAttribute(const char* name=0); DX_MultiValueAttribute(const char* name, const struct DX_MultiValStruct* value); virtual .about.DX_MultiValueAttribute( ); /***************************************************/ //Get a copy of type specific value. User should new a //pointer for the return value and then delete the //pointer after use /**************************************************/ EreturnCodes GetAttributeValue(DX_MultiValStruct* value); EreturnCodes GetAttributeValue(void* value); EreturnCodes SetAttributeValue(const struct DX_MultiValStruct* value); EreturnCodes SetAttributeValue(void* value); void PrintContents( ); private: RWDlistCollectables* AttrValue; void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

EXAMPLE #28

class: DX_MultiValStruct The DX_MultiValStruct is a container class used by the DX_MultiValue to store the attribute's value. It contains the attribute type information, the number of individual attribute values and an array of pointers to the attribute value elements. struct DX_MultiValStruct { int valType; int entries; voic* valPtrArr[MAX_MULTI_VAL]; };

EXAMPLE #29

Instantiation: int *int1 = new int(1); int *int2 = new int(2); struct DX_MultiValStruct tmpStruct; if (int1 && int2) { tmpStruct.valType = DX_INTEGER; tmpStruct.entries = 2; tmpStruct.valPtrArr[0] = int1; tmpStruct.valPtrArr[1] = int2; } DX_MultiValueAttribute *PmvAttr = 0; PmvAttr = new DX_MultiValueAttribute ("MultiValuedAttribute",&tmpStruct); //cleanup if (int1) delete int1; if (int2) delete int2;

EXAMPLE #30

GetAttributeValue: struct DX_MultiValStruct *retStruct = new DX_MultiValStruct; if (retStruct) { if (PmvAttr.>GetAttributeValue((void*)retStruct)) { for (int i=0; i<retStruct->entries; i++) { int *retInt = (int*)retStruct->valPtrArr[i]; if (retInt) { //Do stuff delete retInt; } } } else cerr <<"###### GetAttributeValue FAILED for Integers ######"<<end1; delete retStruct; }

As was discussed previously, a List is a sequence of attributes, i.e., instances of attribute classes and/or Common Objects, an example of which is given as follows:

EXAMPLE #31

/******************************************************** * CLASS NAME : DX_ListObject * INHERITED FROM : None * INHERITS : DX_CommonBase * DESCRIPTION : Provides sequential storage for all * DX_*Object and DX_*Attribute * classes. When used with a * DX_ListObjectIterator the list can * be walked an element at a time * and perform a recursive operation. *******************************************************/ class DX_ListObject : public DX_CommonAttribute { RWDECLARE_COLLECTABLE(DX_ListObject); friend class DX_ListObjectIterator; friend class DX_CommonObject; protected: //Data Members RWDListCollectables* Attrvalue; char *Parent; DX_ListObject(const char* name, char* parent); public: //Constructors /***************************************************/ //If name==NULL, the name is set to "NOT_SET". //If name is "" contains a "." it will be set to //"INVALID_NAME" /***************************************************/ DX_ListObject(const char* name=0); DX_ListObject(const DX_ListObject& ref); virtual .about.DX_ListObject( ); /**************************************************/ //All AddAttribute methods take ownership of the pointers //passed in to them. Do NOT delete the pointers after a //call to AddAttribute. The pointers will be deleted //when the container DX_ListObject is deleted. // //NOTE: When using the following two methods for creating //a DX_STRING attribute // // AddAttribute(const char* name, const int type, // const void* value) and AddPvtAttribute(const char* name, // const int type, const void* value) // // the value is defaulted to be of type const char* // and not UNICHAR* // Misuse will lead to unexpected behavior. /***************************************************/ EreturnCodes AddAttribute(DX_CommonAttribute* newAttr); EreturnCodes AddAttribute(const char* name, const int type, const void* value); EreturnCodes AddAttribute(DX_CommonObject* newObj); EreturnCodes AddAttribute(DX_ListObject* newObj); /**************************************************/ //Do NOT delete the pointer that is returned to you, //it still is owned by the container DX_ListObject. //You CAN use the any of the attribute class //methods for the pointer. /**************************************************/ DX_CommonBase* GetAttribute(const char* name); /**************************************************/ //Removes from list, but does not delete /**************************************************/ EreturnCodes RemoveAttribute(const char* name); /***************************************************/ //Removes from list, and deletes the pointer /***************************************************/ EreturnCodes DeleteAttribute(const char* name); DX_CommonBase* Find(const char* name); void PrintContents( ); private: void saveGuts(RWFile& file) const; void saveGuts(RWvostream& stream) const; void restoreGuts(RWFile& file); void restoreGuts(RWvistream& stream); };

The ListObject iterator enables a user to incrementally retrieve and use objects or attributes contained within a ListObject, an example of which is given as follows:

EXAMPLE #32

/******************************************************** * CLASS NAME : DX_ListObjectIterator * INHERITED FROM : None * INHERITS : DX_CommonBase * DESCRIPTION : Provides sequencial retrieval for all * DX_*Object and DX_*Attribute * classes store within a * DX_ListObject. *******************************************************/ class DX_ListObjectIterator : public DX_CommonBase { private: RWDlistCollectablesIterator *listIter; public: DX_ListObjectIterator(const DX_ListObject& PlistObj); virtual .about.DX_ListObjectIterator( ); void toFirst( ); void toLast( ); void* next( );//returns nil when end of list is reached void* getCurrent( ); };

An example of ListObject usage is provided as follows:

EXAMPLE #33 Assumes a populated DX_ListObject identified by a pointer "PlistObj" // Instantiate the DX_ListObjectIterator for DX_ListObject pointer PlistObj DX_ListObjectIterator PlistIter(*PlistObj); // Set the iterator to the beginning of the list PlistIter.toFirst( ); DX_CommonBase *PcurrentObj=0; PcurrentObj=(DX_CommonBase*)PlistIter.getCurrent( ); while(PcurrentObj) { // Do something with object/attribute . . . PcurrentObj=(DX_CommonBase*) PlistIter.next( ); }

Having discussed in detail various aspects of the Common Object design hereinabove, a more comprehensive description of a data exchange system infrastructure in accordance with one embodiment of the present invention is provided below. The various aspects of the system infrastructure described in greater detail hereinbelow include: configuration management; logging and tracing; context definition; performance and statistics monitoring; administration and maintenance; security; processing thread pool; internationalization; and process procedures.

Configuration management involves managing the static and run time configurable parameters of the various components of the data exchange system. When a component in the data exchange system is initiated, it reads a specific text file, referred to as the configuration file (<component_name>.cfg, specified either in directory $(DX_HOME)/DX_Config or current working directory) to determine the initial values of the parameters. It is noted that each component has its own configuration file, but multiple instances of a component share the same file. Default values are assumed for parameters not specified in the configuration file. If there are multiple entries for a parameter, all entries except the first entry are ignored.

Parameters of a component, such as trace/log settings, may be changed at run time. For this purpose, configuration management tools provide a command line interface and a Web interface for viewing and configuring various parameters at run time. It is noted that various components of the data exchange system may be running on different machines. Thus, the configuration management utility provides the ability to view and modify the parameters of a component running on a different machine, possibly on a different platform. The Web interface of the configuration management utility provides the requisite connectivity to a remote machine and provides the capability for performing remote configurations.

When initiated, a component creates an instance of a System Configuration Object (DX_SysConfigObject) that stores the current parameter settings. The component also registers for a Signal/Event so that it is informed of changes to the configuration using the dynamic configuration command line interface/web interface. When a user wants to change the run time parameters of a component (identified by the process ID and the machine on which it is running), a signal/event is sent to the component to update its configuration. A signal/event handler invokes the ReconfigParameters( ) method on the DX_SysConfigObject, which takes care of reconfiguring the various controller objects, such as DX_TraceLogObject, DX_QueueManager, and DX_ThreadController for example. The System Configuration object, DX_SysConfigObject, is a singleton object that initializes and controls the configuration of a component in the data exchange system, such as logging/tracing levels, thread controller, queuing, and performance monitoring. A singleton object, as understood in the art, refers to a C++ nomenclature meaning that only a single instance of the class may exist within a single executable. A singleton object is most commonly used when controlling system wide resources.

Two macros, DX_SYSINIT and DX_SYSEXIT, are used to manage initialization and destruction of the DX_SysConfigObject, respectively. A usage example of these two macros is given as follows:

EXAMPLE #34 #define DX_SYSINIT(ComponentName) .backslash