Declarative driver

A system and method for building a driver are disclosed. In one embodiment, the system includes one or more processors and a memory storing instructions that, when executed by the processor, cause the system to: obtain an interface description; obtain at least one mapping rule; operate a flow controller that controls a flow of operations, the operations using one or more of the interface description and the at least one mapping rule; obtain a protocol adapter; and implement access to a data source based on the operation of the flow controller using the obtained protocol adapter.

BACKGROUND

The specification relates to building a driver.

The amount of data being generated is increasing. There has been a corresponding growth in the number and variety of data sources, including a growing number and variety of cloud data sources, to store this data. A driver, which is used by an application to access the data stored in such a data source, must be built for each data source. Therefore, an increasing number of drivers are being built.

However, existing systems and methods for building drivers fail to deliver a short turnaround time from research to delivery of the driver, fail to develop the driver using descriptive artifacts, fail to provide a protocol neutral platform for access and interaction, which includes pluggable protocol support, and are not extensible and pluggable for custom use cases.

SUMMARY

The present disclosure relates to building a driver. According to one innovative aspect of the subject matter in this disclosure, a system having one or more processors and a memory storing instructions that, when executed, cause the system to: obtain an interface description; obtain at least one mapping rule; operate a flow controller that controls a flow of operations, the operations using one or more of the interface description and the at least one mapping rule; obtain a protocol adapter; and implement access to a data source based on the operation of the flow controller using the obtained protocol adapter.

In general, another innovative aspect of the subject matter described in this disclosure may be embodied in methods that includes obtaining, using one or more processors, an interface description; obtaining, using one or more processors, at least one mapping rule; operating, using one or more processors, a flow controller that controls a flow of operations, the operations using one or more of the interface description and the at least one mapping rule; obtaining, using one or more processors, a protocol adapter; and implementing, using one or more processors, access to a data source based on the operation of the flow controller using the obtained protocol adapter.

Other implementations of one or more of these aspects include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

These and other implementations may each optionally include one or more of the following features. For instance, the interface description includes a declarative file written in a platform/data source agnostic language. For instance, the operations may further include receiving a schema description, the schema description defining a logical schema for the data source. For instance, the operations further include receiving a set of query conditions; and receiving a definition of one or more service identification rules for the set of query conditions. For instance, the operations further include receiving a mapping rule for mapping a query from a client to a data source request; and receiving a mapping rule for mapping a data source response to a logical schema defined by a schema description. For instance, the operations further include reading the interface description; and receiving a query originating from a client. For instance, the operations further include retrieving, from the at least one mapping rule, one or more rules for mapping the query to a data source request; parsing query to get search conditions; converting the query from one semantic space to another semantic space based on one or more data mapping rules. For instance, the operations further include modifying one or more of the interface description, the at least one mapping rule and the protocol adapter that is obtained; and implementing access to a different data source.

These implementations are particularly advantageous in a number of respects. For instance, the technology described herein can rapidly build a driver for any cloud data source using declarative artifacts. It should be understood, however, that this list of features and advantages is not all-inclusive and many additional features and advantages are contemplated and fall within the scope of the present disclosure. Moreover, it should be understood that the language used in the present disclosure has been principally selected for readability and instructional purposes, and not to limit the scope of the subject matter disclosed herein.

DETAILED DESCRIPTION

Systems, methods and interfaces are disclosed. While the systems, methods and interfaces of the present disclosure are described in the context of building drivers that provide accesses to data sources, it should be understood that the systems, methods and interfaces can be applied to other contexts.

FIG. 1illustrates a high-level block diagram of a system100for building a driver according to one embodiment of the present disclosure. The illustrated system100includes client devices106a-106n(also referred to herein individually and collectively as106) that are accessed by users112a-112n(also referred to herein individually and collectively as user112) and a data source120. In the illustrated implementation, these entities are communicatively coupled via a network102.

The client devices106a-106ninFIG. 1are used by way of example. WhileFIG. 1illustrates two client devices106aand106n, the present disclosure applies to any system architecture having one or more client devices106. Furthermore, while only one network102is coupled to the client devices106a-106nand the data source120, in practice one or more networks102can be connected to these entities. Furthermore, while only one data source120is shown, the system100can include one or more data sources120.

The client devices106can be one or more computing devices including one or more memory and one or more processors, for example, a laptop computer, a desktop computer, a tablet computer, a server, a mobile telephone, a personal digital assistant (PDA), a mobile email device, a portable game player, a portable music player, a television with one or more processors embedded therein or coupled thereto or any other electronic device capable of accessing a network102. In one embodiment, the system100includes a combination of different types of client devices106. For example, a combination of a personal computer and a mobile phone. As will be described below, it should be understood that the present technologies can operate on different models other than a client-server architecture. It should also be understood that although only client device106ais illustrated as including a driver109aand a client application119a, each of the one or more client devices106a-106nmay include an instance of a driver109and a client application119. The client device106according to one embodiment is described in more detail with reference toFIG. 2.

The network102enables communications between the client devices106a-nand the data source120. Thus, the network102can include links using technologies including, for example, Wi-Fi, Wi-Max, 2G, Universal Mobile Telecommunications System (UMTS), 3G, Ethernet, 802.11, integrated services digital network (ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc. Similarly, the networking protocols used on the network102can include the transmission control protocol/Internet protocol (TCP/IP), multi-protocol label switching (MPLS), the User Datagram Protocol (UDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), lightweight directory access protocol (LDAP), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications (GSM), High-Speed Downlink Packet Access (HSDPA), etc. The data exchanged over the network102can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In addition, all or some of links can be encrypted using conventional encryption technologies, for example, the secure sockets layer (SSL), Secure HTTP and/or virtual private networks (VPNs) or Internet Protocol security (IPsec). In one embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above. Depending upon the implementation, the network102can also include links to other networks.

The network102may have any number of configurations including a star configuration, token ring configuration or other configurations. Furthermore, the network102may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), and/or any other interconnected data path across which multiple devices may communicate. In one embodiment, the network102may be a peer-to-peer network. The network102may also be coupled to or include portions of a telecommunications network for sending data in a variety of different communication protocols. In one embodiment, the network102includes short-wavelength communication networks or a cellular communications network for sending and receiving data including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, wireless application protocol (WAP), electronic messages, etc.

The data source120may be a non-transitory memory that stores data. For example, the data source120may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory or some other memory device. In one embodiment, the data source120also includes a non-volatile memory or similar permanent storage device and media, for example, a hard disk drive, a floppy disk drive, a compact disc read only memory (CD-ROM) device, a digital versatile disc read only memory (DVD-ROM) device, a digital versatile disc random access memories (DVD-RAM) device, a digital versatile disc rewritable (DVD-RW) device, a flash memory device, or some other non-volatile storage device.

In some embodiments, the data source120is included in a data server122. The data server122may be any class of data server including, for example, a SaaS application, packaged on-premise application, relational application, data warehouse, etc. In one embodiment, the data server122may include one or more computing devices having data processing, storing, and communication capabilities. For example, the data server122may include one or more hardware servers, server arrays, storage devices, systems, etc., and/or may be centralized or distributed/cloud-based. In some implementations, the data server122may include one or more virtual servers, which operate in a host server environment and access the physical hardware of the host server including, for example, a processor, memory, storage, network interfaces, etc., via an abstraction layer (e.g., a virtual machine manager). While one data server122is illustrated, the system100may include any number of data servers122.

A user112interacts with the client device106as represented by signal line110. For example, the user112interacts with the client device106to provide one or more of user input to build a driver (e.g. an interface description) and user input to use the driver (e.g. a query).

It should be understood that the system100illustrated inFIG. 1is representative of an example system for building a driver according to one embodiment and that a variety of different system environments and configurations are contemplated and are within the scope of the present disclosure. For instance, various functionality may be moved from a server to a client, or vice versa and some implementations may include additional or fewer computing devices, services, and/or networks, and may implement various functionality client or server-side. Further, various entities of the system100may be integrated into to a single computing device or system or additional computing devices or systems may be included.

FIG. 2illustrates the client device106according to one embodiment of the present disclosure. In the illustrated implementations, the client device106includes a communication unit208, a processor202and a memory204. These components of the client device106are communicatively coupled to a bus206or software communication mechanism for communication with each other.

The communication unit208is coupled to the network102by signal line104. The communication unit208is also coupled to the bus206. The communication unit208transmits and receives data to and from the data source120. The communication unit208provides other conventional connections to the network102using network protocols, e.g., TCP/IP, HTTP, HTTPS and SMTP. In some implementations, the communication unit208includes a port for direct physical connection to the network102or to another communication channel. For example, the communication unit208includes a USB, SD, CAT-5 or similar port for wired communication with the client device106. In some implementations, the communication unit208includes a wireless transceiver for exchanging data with the client device106or other communication channels using one or more wireless communication methods, including IEEE 802.11, IEEE 802.16, BLUETOOTH® or another suitable wireless communication method.

The processor202may include an arithmetic logic unit, a microprocessor, a general purpose controller or some other processor array to perform computations and provide electronic display signals to a display device. The processor202is coupled to the bus206for communication with the other components of the client device106. Processor202processes data signals and may include various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Although only a single processor202is shown inFIG. 2, multiple processors may be included. It should be understood that other processors, operating systems, sensors, displays and physical configurations are possible.

The memory204stores instructions and/or data that may be executed by the processor202. In the illustrated implementation, the memory204stores the driver109. The memory204is coupled to the bus206for communication with the other components of the client device106. The instructions and/or data may include code for performing any and/or all of the techniques described herein. For example, in the illustrated embodiment, the memory204stores the driver109, which is executed by the processor202.

In the illustrated embodiment, the memory204stores a client application119, which may use the driver109to access data stored on a data source120. Depending on the embodiment, the client application may be a web browser, a desktop client, a mobile client or any other application that accesses a data source120. The client application119may be written in Java, C, C++, or any other programming language.

Depending on the embodiment, the client application may use an application program interface (API) to communicate with the driver109. For example, the client application119may be a Java Database Connectivity (JDBC), Open Database Connectivity (ODBC), ADO.NET, or Object Linking and Embedding Database (OLE DB) client. For clarity and convenience, the examples used herein may frequently refer to a JDBC client or an ODBC client as examples of a client application119. However, the disclosure herein is not necessarily limited to such client applications119.

The memory204includes a non-transitory computer-usable (e.g., readable, writeable, etc.) medium, which may be any apparatus or device that may contain, store, communicate, propagate or transport instructions, data, computer programs, software, code, routines, etc., for processing by or in connection with the processor202. In some embodiments, the memory204may include one or more of volatile memory and non-volatile memory. For example, the memory204may include, but is not limited, to one or more of a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory or some other memory device. In some implementations, the memory237also includes a non-volatile memory or similar permanent storage device and media including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device for storing information on a more permanent basis. It should be understood that the memory204may be a single device or may include multiple types of devices and configurations.

The bus206can include a communication bus for transferring data between components of a client device106and/or between computing devices (e.g. between one or more of the client device106and data source120), a network bus system including the network102or portions thereof, a processor mesh, a combination thereof, etc. In some implementations, the schema tool109, its sub-components and various other software operating on the computing device106(e.g., an operating system, etc.) may cooperate and communicate via a software communication mechanism implemented in association with the bus206. The software communication mechanism can include and/or facilitate, for example, inter-process communication, local function or procedure calls, remote procedure calls, an object broker (e.g., CORBA), direct socket communication (e.g., TCP/IP sockets) among software modules, UDP broadcasts and receipts, HTTP connections, etc. Further, any or all of the communication could be secure (e.g., SSH, HTTPS, etc.).

Still referring toFIG. 2, in one embodiment, the driver109includes a declarative driver framework224and artifacts228. The driver109may beneficially be configured to connect to any data source120(e.g. any cloud-based data source) by generating descriptive artifacts228using the declarative driver framework224. The declarative driver framework224uses the descriptive artifacts to allow the driver109to access the data source120. Thus, the declarative driver framework224“builds” the driver109by generating descriptive artifacts and, along with the generated artifacts228, comprises the driver109.

Referring now toFIG. 3, an example of the artifacts228generated and used by the declarative driver framework224is shown according to one embodiment. In the illustrated embodiment, the artifacts228include an interface description302, data mapping rules308and a binding strategy stack310. In one embodiment, the interface description302includes a schema description304and service identification rules306. The various artifacts228are discussed in detail below with reference toFIGS. 3 and 4.

The system and method disclosed herein beneficially enable the building of a driver109by generating a small number of files or “artifacts”228. So, a first driver109instance for accessing a first data source120may be built by generating and using a first set of artifacts228associated with the first driver109instance, and a second driver109instance for accessing a second data source may be built by generating a second set of artifacts228associated with the second driver109instance. Moreover, a driver109for accessing a first data source120may be modified to access a second data source120instead by modifying the artifacts228.

Referring now toFIG. 4, the declarative driver framework224is described in more detail according to one implementation. In one embodiment, the declarative driver framework224includes a driver interface module422, a query processing module424, a data mapping module426, an interface description module428, a flow controller module430and a protocol management module432. Each of these components is coupled for communication with each other and the other components of the driver109.

The driver interface module422can be software or routines for handling communications between the driver109and the client application119. In one embodiment, the driver interface module422is a set of instructions executable by the processor202. In one embodiment, the driver interface module422is stored in the memory204of the client device106and is accessible and executable by the processor202. In one embodiment, the driver interface module422is adapted for cooperation and communication with the processor202and other components of the client device106.

The driver interface module422handles communications between the driver109and the client application119. In one embodiment, the driver interface module422receives a query from a client application119and returns results to a client application119. For example, assume the client application119is a JDBC (or ODBC) client and uses structured query language (SQL); in one embodiment, the driver interface module422receives a SQL query from the JDBC (or ODBC) client and transmits a result using SQL to the JDBC (or ODBC) client. Query as used herein may refer to any request. Examples of queries include, but are not limited to fetching, writing, modifying, updating and inserting data stored by the data source120and modifying a structure stored in the data source (e.g. add/drop a table, column, relationship, etc.).

In one embodiment, the driver interface module422passes a query to the query processing module424. In one embodiment, the driver interface module422stores the query in memory204(or any other non-transitory storage medium communicatively accessible), and the other modules of the declarative driver framework224(e.g. the query processing module424) may retrieve the query from the memory204(or other non-transitory storage medium).

In one embodiment, the driver interface module422returns results to a client application119. For example, in one embodiment, the driver interface module422passes results, which are converted by the data mapping module426from the semantic space of the data source120to that of the client application119, to the client application119.

The query processing module424can be software or routines for processing a query. In one embodiment, the query processing module424is a set of instructions executable by the processor202. In one embodiment, the query processing module424is stored in the memory204of the client device106and is accessible and executable by the processor202. In one embodiment, the query processing module424is adapted for cooperation and communication with the processor202and other components of the client device106.

The query processing module424processes a query. In one embodiment, the query processing module424processes a query for use by the flow controller module430. For example, in one embodiment, the query parsing module424obtains the query (e.g. from the driver interface module422), processes the query, and sends the processed query to the flow controller module430.

In one embodiment, processing a query may include one or more of parsing a query, validating a query and generating a query plan. Parsing a query may beneficially identify errors prior to execution of a flow controller. For example, assume, again, that the client application119is a JDBC (or ODBC) client and therefore the query is a SQL query. In one embodiment, the query processing module424parses the query and identifies the operation(s) (e.g. SQL statements) and parameters (e.g. table names, column names, values to be inserted, etc.) and determines whether the query is semantically and syntactically correct. For example, the query processing module424may determine the query “SELECT last name, email FROM contacts” is semantically and syntactically correct and passes the query, which may be referred to occasionally as a processed query, to the flow controller module430, but may determine “SELECT last name” is a fragment, which is syntactically incorrect, and does not pass the query fragment to the flow controller module430. In one embodiment, the query processing module424may validate the query by determining whether the client application119has the appropriate privileges to make such a query.

In one embodiment, the query processing module424passes the processed query to the flow controller module430. In one embodiment, the query processing module424stores the processed query in memory204(or any other non-transitory storage medium communicatively accessible), and the other modules of the declarative driver framework224(e.g. the flow controller module430) may retrieve the processed query from the memory204(or other non-transitory storage medium).

The data mapping module426can be software or routines for generating data mapping rules308. In one embodiment, the data mapping module426is a set of instructions executable by the processor202. In one embodiment, the data mapping module426is stored in the memory204of the client device106and is accessible and executable by the processor202. In one embodiment, the data mapping module426is adapted for cooperation and communication with the processor202and other components of the client device106.

The data mapping module426generates data mapping rules308. Data mapping rules308may include one or more rules used to convert from one semantic space to another. For example, assume the client application119is a JDBC client and the data source120is a cloud-based Eloqua database; in one embodiment, the data mapping module426uses the data mapping rules308to convert a SQL query (i.e. a first semantic space query) to one or more requests native to and recognizable by Eloqua (i.e. a second semantic space) and for converting a response received from Eloqua (i.e. first semantic space) into SQL results (i.e. second semantic space). In another example, the data mapping rules may convert Java objects to XML/JSON objects.

For clarity and convenience, some of the examples herein may refer to Eloqua. However, it should be noted that Eloqua is just one example of a data sources120and one example of a cloud based data source, which the driver109may be built, using the declarative driver framework224, to access and that other data sources120and other cloud-based data sources exist and may be used without departing from the teachings herein.

The data mapping module426generates data mapping rules308based on user input. For example, in one embodiment, the data mapping module426includes an Expression Language (EL) based data mapping framework and the user inputs one or more XML based rules for manipulating data. In one embodiment, the data mapping rules308includes a plurality of rules and the plurality of rules may be one or more of hierarchical (to the nthdegree), conditional, looped and grouped. An example data mapping rules308is shown inFIG. 13.

The mapping rules indicate how to map a query received from the client application119to a request for the data source120and a response from the data source120to results for the client application119. In one embodiment, the data mapping module426executes one or more of the data mapping rules308at the direction of the flow controller module430to map a query (or response) from one semantic space to another. For example, assume the client application119is a JDBC client and the data source120is a cloud-based Eloqua database. Also assume that the query processing module424has processed the query and the flow controller module430using the service identification rules306has identified one or more services and/or operations based on the processed query. In one embodiment, the data mapping module426applies the data mapping rules308to the processed query data to convert a SQL query (i.e. a first semantic space) to a request native to and recognizable by Eloqua (i.e. a second semantic space), to invoke the identified one or more services and/or operations. The data mapping module426may also applydata mapping rules to convert a response subsequently received from Eloqua (i.e. a first semantic space) into SQL results (i.e. a second semantic space).

A query, or processed query, that has been mapped, or converted, by the data mapping module426is occasionally referred to herein as a “request” or a “data source request.” In one embodiment, the data mapping rules308passes a request to the protocol management module432. In one embodiment, the data mapping module426stores the request in memory204(or any other non-transitory storage medium communicatively accessible), and the other modules of the declarative driver framework224(e.g. the protocol management module432) may retrieve the request from the memory204(or other non-transitory storage medium).

A response from a data source120that has been mapped, or converted, by the data mapping module426is occasionally referred to herein as “converted results,” “mapped results” or simply as “results.” In one embodiment, the data mapping rules308passes converted results to the flow controller module430. In one embodiment, the data mapping module426stores the converted results in memory204(or any other non-transitory storage medium communicatively accessible), and the other modules of the declarative driver framework224(e.g. the flow controller module430) may retrieve the converted results from the memory204(or other non-transitory storage medium).

The interface description generation module432can be software or routines for generating an interface description. In one embodiment, the interface description module428is a set of instructions executable by the processor202. In one embodiment, the interface description module428is stored in the memory204of the client device106and is accessible and executable by the processor202. In one embodiment, the interface description module422is adapted for cooperation and communication with the processor202and other components of the client device106.

The interface description module422generates an interface description. In one embodiment, the interface description module422generates an interface description based on user112input. Referring now toFIG. 4, in one embodiment, an interface description302is one of the artifacts228that is generated by the declarative driver framework224and used by the declarative driver framework224to provide a client application119access to data stored in a data source120. In one embodiment, an interface description302includes a schema description304file and a service identification rules306file including one or more service identification rules.

The schema description304describes a logical schema of the data source120the driver109is to access once built. For example, assume the driver109is being built to access Eloqua as a data source120; in one embodiment, the schema description304describes the logical schema of the Eloqua database to be accessed. In one embodiment, the interface description module422generates the schema description by receiving user input. For example, in one embodiment, the interface description module422receives a schema description304from the user112. In one embodiment, the interface description module422invokes an API associated with the data source and automatically generates a schema description using the API.

In one embodiment, the schema description304uses a platform/data source agnostic language. A platform/data source agnostic language is a language that does not depend on the platform (e.g. the operating system of the client device106and/or the type (e.g. Java, C, C++, etc.) of client application119) and/or the data source120(e.g. the type data source120, the query language used, etc.) For example, in some embodiments, the schema description304is written by a user112using the Interface Description Language (IDL) (i.e. a platform/data source agnostic language) and defines the schema of the data source120. For example, assuming again that the driver109is being built to access an Eloqua database (i.e. a cloud-based data source120); in one embodiment, the interface description module422receives a declarative description of the schema (e.g. the tables, table columns, indexes, relationships such as foreign key relationships between tables, etc.) of the Eloqua database in a platform/data source agnostic language. An example of at least a portion of a schema description304using the IDL is shown inFIG. 11.

The service identification rules306identify the services and/or operations that may be invoked at the data source120. In one embodiment, the service identification rules306include one or more declarative rules. For example, in one embodiment, the service identification rules306include one or more XML based rules. In some embodiments, the service identification rules306support conditionality and may be modified to insert new behavior as new query conditions or data source120services and/or operations are introduced (e.g. through updates to the client application119and/or data source120).

In one embodiment, the interface description module422generates the service identification rules306by receiving user input. For example, in one embodiment, the interface description module422receives a set of query conditions from the user112and service identification rules describing the operations/methods that should be invoked at the data source120when a query condition is met. For example, assuming the client application119is a JDBC client and the data source120is a Cassandra database, which is a NoSQL database, the user112may define query conditions such as a SQL query and/or SQL query type (e.g. SELECT, INSERT, DELETE, UPDATE, etc.) and service identification rules such as how that query or query type is invoked in Cassandra Query Language (CQL), which may require invoking one or more operations defined by the service identification rules306.

In one embodiment, the interface description module428passes the interface description302to the flow controller module430. In one embodiment, the interface description module428stores the interface description302in memory204(or any other non-transitory storage medium communicatively accessible), and the other modules of the declarative driver framework224(e.g. the flow controller module430) may retrieve the interface description302from the memory204(or other non-transitory storage medium).

The flow controller module430can be software or routines for controlling an execution flow. In one embodiment, the flow controller module430is a set of instructions executable by the processor202. In one embodiment, the flow controller module430is stored in the memory204of the client device106and is accessible and executable by the processor202. In one embodiment, the flow controller module430is adapted for cooperation and communication with the processor202and other components of the client device106.

The flow controller module430controls an execution flow by determining what to invoke and in what order and by supplying contextual information. For example, in one embodiment, the flow controller module430receives a processed query from the processing module424, invokes the service identification rules306to identify an operation, invokes a binding a strategy stack310directing the data mapping module426to create a data source request and invokes the protocol management module432to pass the data source request and any associated data to the data source120. In another example, the flow controller430receives a data source response after the protocol management module432has stripped the associated protocol from the response, invokes a binding strategy (e.g. a mapping binding strategy, which invokes the data mapping module426to convert the response into results), determines whether the results are complete and, if the results are complete, passes the results to the driver interface422to be sent to the client application119. If the results are not complete, the flow controller module430may invoke the data mapping module426to create another data source request to repeat the previous operation or may invoke the service identification rules306to identify a different operation and invoke the data mapping module426to create a data source request for the next operation.

In one embodiment, the flow controller module430invokes and executes a binding strategy stack310. In one embodiment, the binding strategy stack310is a Spring Configuration file to permit the inclusion of additional binding functionality by adding an entry to the Spring Configuration file.FIG. 5illustrates an example of a binding strategy stack310according to one embodiment. In one embodiment, a binding strategy stack310includes a root nested binding strategy502which includes one or more of a mapping binding strategy504(which may itself include a post-mapping binding strategy510), a rules based binding strategy506and an authentication scheme specific binding strategy508. The vertical ellipses inFIG. 5indicate that any number of binding strategies may be included and nested at any level in the root nested binding strategy.

In one embodiment, the mapping binding strategy504commands, or “invokes,” the data mapping module426causing the data mapping module to execute and apply the data mapping rules to map from one semantic space to another. In one embodiment, the post-mapping binding strategy510allows for one or more of exception handling (e.g. when an error occurs when mapping from one semantic space to another), and data beautification (e.g. data cleaning or massaging). In one embodiment, the rules based binding strategy506allows the binding to comply with one or more rules. For example, assume a data source120and/or client application119require as a rule that a query or a result include a certain piece of information (e.g. each query and/or result is tagged with an employee ID, session ID, user ID and password, or some other information). In one embodiment, the rules based binding strategy506applies that piece of information to comply with the rule. In one embodiment, an authentication scheme specific binding strategy508may handle any security certificates and authentication handshakes that may be required between the client application119and the data source120.

As mentioned above, the flow controller module430may provide contextual information. For example, in one embodiment, when the flow controller430executes a binding strategy to create a data source request, the flow controller430may pass information associated with the query, i.e., contextual information. For example, assume a query is to insert data; in one embodiment, the flow controller module430passes the data to be inserted (i.e. contextual data from the processed query) to the data mapping module426and the data mapping module426creates the appropriate data source request.

In one embodiment, the flow controller module430passes the result of the binding to the driver interface module422. For example, the flow controller module430determines whether mapped results received from the data mapping module426is complete and sends the mapped result to the driver interface module422to be sent to the client application119.

The protocol management module432can be software or routines for managing one or more protocols for communicating with a data source120. In one embodiment, the protocol management module432is a set of instructions executable by the processor202. In one embodiment, the protocol management module432is stored in the memory204of the client device106and is accessible and executable by the processor202. In one embodiment, the protocol management module432is adapted for cooperation and communication with the processor202and other components of the client device106.

The protocol management module432manages one or more protocols for communicating with a data source120. In one embodiment, the protocol management module432manages the one or more protocols by determining a protocol to use and configuring the determined protocol. Depending on the data source120the driver109is built to access, the protocol may vary. For example, some cloud-based data sources may communicate using REST protocol, others may communicate using Web Services (WS) and still others may communicate using Java Messaging Service (JMS). It should be recognized that REST, WS and JMS are merely examples of protocols and that other protocols exist and may be used without departing from the disclosure herein.

In one embodiment, the protocol management module432determines a protocol based on a user input. For example, in one embodiment, the protocol management module432receives an input indicating that the data source120uses REST, determines to use a REST protocol and configures the REST protocol. For example, the protocol management module432receives a query that has been converted into the semantic space of the cloud-data source and applies the REST protocol to that query. The protocol management module432receives a response from the data source120, determines the response received uses the REST protocol and strips the protocol from the response and sends the response to the data mapping module426to be mapped to a client result. In one embodiment, the protocol management module432sends the response (stripped of the protocol) to the data mapping module426at the direction of the flow controller module430. In one embodiment, the driver interface module422passes a data source request to the data source120using the determined protocol. In one embodiment, the protocol management module432passes a data source request to the data source120using the determined protocol at the direction of the flow controller module430.

In one embodiment, the protocol management module432can allow the interaction between a protocol and any protocol specific component. In one embodiment, the protocol management module432can plug any protocol specific component to interact with the protocol by providing configurability of protocol specific processors. In one embodiment, the protocol management module432can plug any protocol specific component to interact with the protocol by providing configurability of open-source endpoints. For example, the protocol management module432can build the protocol in and provide the configurability of Apache Camel endpoints.

In one embodiment, the protocol management module432can provide inbuilt support for one or more common protocols including, for example, REST, WS and JMS invocations. In one embodiment, the protocol management module432can provide integration for open source frameworks (e.g., CXF) for protocol specific invocations. The protocol management module432can provide inbuilt support for advanced features for these frameworks. For example, the advanced features may include WS-Security and WS Reliable Messaging.

Example Methods

FIGS. 6-10depict various methods performed by the system described above in reference toFIGS. 1-5.FIG. 6is a flowchart of an example method600for building a driver according to one embodiment. The method600begins at block602. At block602, the interface description module428generates an interface description. At block604, the data mapping module426generates data mapping rules. At block606, the flow controller module430configures a binding strategy to control the flow of information between driver components. At block608the protocol management module432determines a protocol adapter and configures, at block610, the protocol adapter.

FIG. 7is a flowchart of an example method700for generating an interface description according to one embodiment. The method700begins at block702. At block702, the interface description module432defines a schema description of a data source. At block704, the interface description module432defines one or more service identification rules. At block706, interface description module generates an interface description configuration file based on the schema description and the one or more service identification rules.

FIG. 8Ais a flowchart of an example method800A for the runtime operation of a driver109according to one embodiment. The method800A begins at block802. At block802, the driver interface module422receives a query from the client. At block803, the query processing module424parses the query. At block804, the flow controller module430obtains an interface description. At block805, the flow controller module430identifies and operations/service to invoke using the one or more service identification rules included in the interface description. At block806, the data mapping module426maps between semantic spaces based on the data mapping rules. At block808, the protocol management module432receives a data source response including results. At block814, the data mapping module426converts the results received at block808for the client based on the data mapping rules. At block816, the driver interface module422since the converted results to the client.

FIG. 8Bis a flowchart of an example method800B for the runtime operation of a driver109according to another embodiment. The method800B begins at block802. At block802, the driver interface module422receives a query from the client. At block803, the query processing module424parses the query. At block804, the flow controller module430obtains an interface description. At block805, the flow controller module430identifies and operations/service to invoke using the one or more service identification rules included in the interface description. At block806, the data mapping module426maps between semantic spaces based on the data mapping rules. At block808, the protocol management module432receives a data source response including results.

At block810, the flow controller module430determines whether the same operation needs to be invoked to receive query results based on the parsed query and one or more service identification rules. When the flow controller module430determines that the same operation needs to be invoked to receive query results (810—Yes), the method800B continues at block806and block806,808and810may be repeated until the flow controller module430determines that the same operation does not need to be invoked to receive query results (810—No). When the flow controller module430determines that same operation does not need to be invoked to receive query results (810—No), the method800B continues at block812.

At block812, the flow controller module430determines whether another operation needs to be invoked to receive query results based on the parsed query and one or more service identification rules. When the flow controller module430determines that another operation needs to be invoked to receive query results (812—Yes), the method800B continues at block805and block805,806,808and810may be repeated until the flow controller module430determines that another operation does not need to be invoked to receive query results (812—No). When the flow controller module430determines that another operation does not need to be invoked to receive query results (812—No), the method800B continues at block814.

At block814, the data mapping module426converts the results for the client based on the data mapping rules. At block816, the driver interface module422sends the converted results to the client.

FIG. 9is a flowchart of an example method900for generating a schema description according to one embodiment. The method900begins at block902. At block902, the interface description module428defines columns using a declarative, platform/data source agnostic description language. At block904, the interface description module428defines indices using a declarative, platform/data source agnostic description language. At block906, the interface description module428defines one or more foreign key relationships using a declarative, platform/data source agnostic description language. At block908the interface description module428stores the definitions of blocks902,904and906for use by the driver109.

FIG. 10is a flowchart of an example method1000for generating one or more service identification rules according to one embodiment. Method1000begins at block1002. At block1002the interface description module428determines a set of query conditions. At block1004the interface description module428defines one or more service identification rules for the set of query conditions.

In the above description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it should be understood that the technology described herein may be practiced without these specific details. Further, various systems, devices, and structures are shown in block diagram form in order to avoid obscuring the description. For instance, various implementations are described as having particular hardware, software, and user interfaces. However, the present disclosure applies to any type of computing device that may receive data and commands, and to any peripheral devices providing services.

The technology described herein may take the form of an entirely hardware implementation, an entirely software implementation, or implementations containing both hardware and software elements. For instance, the technology may be implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

A data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements may include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) may be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems, storage devices, remote printers, etc., through intervening private and/or public networks. Wireless (e.g., Wi-Fi™) transceivers, Ethernet adapters, and modems, are just a few examples of network adapters. The private and public networks may have any number of configurations and/or topologies. Data may be transmitted between these devices via the networks using a variety of different communication protocols including, for example, various Internet layer, transport layer, or application layer protocols. For example, data may be transmitted via the networks using transmission control protocol/Internet protocol (TCP/IP), user datagram protocol (UDP), transmission control protocol (TCP), hypertext transfer protocol (HTTP), secure hypertext transfer protocol (HTTPS), dynamic adaptive streaming over HTTP (DASH), real-time streaming protocol (RTSP), real-time transport protocol (RTP) and the real-time transport control protocol (RTCP), voice over Internet protocol (VOIP), file transfer protocol (FTP), WebSocket (WS), wireless access protocol (WAP), various messaging protocols (SMS, MMS, XMS, IMAP, SMTP, POP, WebDAV, etc.), or other known protocols.

Finally, the structure, algorithms, and/or interfaces presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method blocks. The required structure for a variety of these systems will appear from the description above. In addition, the specification is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the specification as described herein.

The foregoing description has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the specification to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims of this application. As will be understood by those familiar with the art, the specification may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the specification or its features may have different names, divisions and/or formats.

Furthermore, the modules, routines, features, attributes, methodologies and other aspects of the disclosure may be implemented as software, hardware, firmware, or any combination of the foregoing. Also, wherever a component, an example of which is a module, of the specification is implemented as software, the component may be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future. Additionally, the disclosure is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure is intended to be illustrative, but not limiting, of the scope of the subject matter set forth in the following claims.