IQE Concepts

The IQE design is based on a number of concepts that were adopted by InterQuery in response to three key requirements or guiding principles: performance, flexibility and ease-of-use.

Multi-threaded Query Processing

InterQuery has developed a sophisticated multi-threaded Java-based environment that allows to query multiple data sources in real-time concurrently. This environment allows users to fully benefit from multi-processor hardware architectures, which creates shorter user response time The multi-threaded environment also allows the system administrator to setup thread and resource usage to obtain optimum performance, favoring either response-time or number of concurrent transactions.

Abstraction Layer

InterQuery uses an intermediate format, or Abstraction Layer, to internally represent queries and results. This intermediate format allows the data manipulation functions (see below) to be applied to data regardless of the syntax, format and origin of the data. When a query is received by the IQE through any of its application interfaces (J2EE, HTTP, XML or SOAP), the query parameters are mapped into this intermediate format, and then passed on to the appropriate connectors. The connectors then translate the query from its intermediate representation into the native format required by the data source, and return the data directly into the intermediate format. The data manipulation functions are then applied before the data is sent to the requesting client application.

The internal format of the query parameters and result set was designed for both flexibility and performance. Through this Abstraction Layer, InterQuery can, in a plug-and-play manner, very easily add support for other Client Interfaces and Connectors.

Base Views

A Base View represents a generic re-usable view of a data source that is made available to requesting applications through Application Views (described next). The definition of a Base View, created at design time, includes the definition of the query parameters, the definition of the data columns of the result set, and connection information about the data source participating in the view.

Application Views

An Application View represents a generic re-usable query that is the unit of work manipulated by the requesting Client Application. When a Client Application sends a request to the IQE platform, the request carries which Application View is requested by the application, and what the query parameters are. The definition of an Application View, created at design time, includes the definition of the query parameters, the definition of the data columns of the result set, and transformations, business rules, and mappings that need to be applied at that time. Typically, Business Users design Application Views to meet their current reporting and/or analytic needs. They have a choice of creating "broad" views (of which there is usually a small number) that can be used for many purposes or creating a large number of "narrow" views that are each very specific in nature.

Information Maps and Metadata

Metadata is commonly defined as "data about the data". Metadata is also often referred to as "information maps". InterQuery's metadata or information maps are encapsulated by the system's collection of Base Views, and contain data about the data sources and the structure of data they hold. Example of metadata elements include the network protocol and location of the data source (i.e. how to communicate with the data source), the type of data source (i.e. which type of connector will be used to connect to the data source), and the mapping of the data structure from the native data structure (or schema) to the InterQuery Abstraction Layer format.

Data Manipulation

InterQuery's platform includes added-value data manipulation features that traditionally belong in the application layer, but have been incorporated by InterQuery in its core engine. These features include:

• Data congruence. Because of the diversity in the format of the data, there is a need to transform data before passing it to the application layer so the application layer receives a uniform data set. For example, the data representing an employee in an HR system may code male as a "1", and another system as "m". A simple rule will make the IQE transform both into "M".

• Data transformation. This feature allows such operations such as field composition and de-composition and arithmetic conversions. For example, airline flight numbers can be represented in one field including both the airline code and flight number (e.g. FlightNumber=UA123) in one system, or it could be represented in two fields in another system (e.g. Airline=UA, Flight=123). Examples of arithmetic conversion include currency conversion and percent calculation.

• Data filtering. Some sources of data are not fully capable of responding to a detailed query, and return too much data. Filters can be applied to data sets from specific sources.

• Priorities. In cases where business logic dictates it, the IQE is capable of assigning priorities to the data sources, and to return results from higher priority data sources before results from lower-priority data sources.

• Business logic. This feature allows the application developer or administrator of the platform to perform business logic on the data before it is passed to the application layer. Simple examples of business logic include applying discounts.

• Custom business logic. Well-documented APIs allow application developers to develop custom java classes to extend the functionality of the IQE, and add custom business logic.

• Data streaming and caching. As query results are received from the connectors, the various data manipulation functions are applied to it, and the data is then immediately streamed to the requesting client application. The IQE does not wait until the entire result sets have been received from connectors to pass them to the application. At the request of the client application, the data can be returned in chunks of configurable size. Results are also cached temporarily.

Non-intrusive to the Data Sources

To protect existing investments in expensive databases and enterprise software, and to avoid disruption of operational systems, InterQuery's connectors to data sources do not require any software agent running on these systems. The InterQuery connectors are totally non-disruptive and non-intrusive to data sources.

The Role of XML

As many other data integration product suites, InterQuery's IQE makes use of XML as a common intermediate data representation mechanism suitable for exchanging data between systems. XML is used both as a way to exchange information with the Client Application, and as a way of getting data from external data sources. However, for performance reasons, XML was not chosen as the internal intermediate format of the Abstraction Layer. InterQuery's product strategy is not to rely entirely on XML, but rather give programmers and users added flexibility by allowing them to interface to the IQE with the tools of their choice, such as ODBC, J2EE and SOAP, in addition to XML.

Multiple Client Application Interfaces & Environments

InterQuery's strategy is to support as many operating environments as possible to give users and programmers the widest choice of integration methods. This allows users and programmers to focus on the business processing of data, and makes them immediately productive in their familiar environment. Five operating environment have been selected, and many others will become available over time.

• HTML or XML via HTTP. HTTP is quick, light, and available on almost every application platform. Web browsers exist everywhere and, in many cases, are the desired end-user client application platform itself (often referred to as a zero-client application footprint). The IQE is able to return XML via HTTP to requesting apps (ASPs, JSPs, Servlets, CFMs, Perl CGIs, and so on), or return HTML results directly to the browser using a pre-configured presentation template.

• Java 2 Enterprise Edition (J2EE). J2EE is an open software specification designed to simplify enterprise application development, deployment and integration. J2EE-compliant platforms allow developers to create business applications using a variety of loosely coupled modular components. These components are highly portable and re-usable, and can be deployed on any J2EE-compliant Application Servers with minimum effort. Leading J2EE-compliant Application Servers include BEA WebLogic™, IBM WebSphere™, and HP Bluestone™.

• Stand-alone Java Application. The InterQuery IQE can operate in the simplest Java environment where all is required is a Java Virtual Machine. Both Web Services and ODBC (see below) Client Interfaces can be run as stand-alone Java applications.

• Web Services. Web Services is a service-oriented model in which distributed, heterogeneous and loosely coupled services collaboratively provide business data processing that can be accessed via the Internet. Web Services available for consumption are listed in private and public online directories, so that applications can dynamically locate and access these services in a secure manner. Web Services standards include a mechanism to exchange requests and responses between services: the Simple Object Access Protocol (SOAP); a registry of available Web Services: Universal Description Discovery and Integration (UDDI); and a language for describing services interfaces: Web Service Description Language (WSDL).

• ColdFusion. Special ColdFusion tags allow ColdFusion applications to invoke the services of the IQE applications.