EP1872285A2 - Query processing for smart services - Google Patents

Abstract

In accordance with embodiments of the present invention, there are provided mechanisms and methods for accessing a service on behalf of a requestor. These mechanisms and methods for accessing a service make it possible for results from the service to be provided to the requestor in the form that the requestor prefers. Some of the many types of forms available to requestors in various embodiments include, without limitation, filtered, alphabetized, numerically ordered, sort ordered, truncated, as well as other types of formatting in accordance with the criteria.

Description

QUERY PROCESSING FOR SMART SERVICES

CLAIM OF PRIORITY United States Provisional Patent Application No. 60/665,944 entitled "SMART

SERVICES", by Naveen Gupta, filed March 29, 2005 (Attorney Docket No. BEAS- 01753US5);

United States Provisional Patent Application No. 60/665,943 entitled "ADHOC QUERIES FOR SERVICES", by Naveen Gupta, filed March 29, 2005 (Attorney Docket No. BEAS-01753US6);

United States Provisional Patent Application No. 60/665,964 entitled "SQL INTERFACE FOR SERVICES", by Naveen Gupta, filed March 29, 2005 (Attorney Docket No. BEAS-01753US7);

United States Patent Application No. 11/341 ,237 entitled "SMART SERVICES", by Naveen Gupta, filed January 27, 2006 (Attorney Docket No. BEAS-01753USD);

United States Patent Application No. 11/341 ,277 entitled "ADHOC QUERIES FOR SERVICES", by Naveen Gupta, filed January 27, 2006 (Attorney Docket No. BEAS- 01753USE); and

United States Patent Application No. 11/340,950 entitled "SQL INTERFACE FOR SERVICES", by Naveen Gupta, filed January 27, 2006 (Attorney Docket No. BEAS- 01753USF).

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The current invention relates generally to accessing services on behalf of applications, and more particularly to a mechanism for processing queries by conforming data provided by services to a form that the client desires the data to have. BACKGROUND

Increasingly, enterprises are looking for ways to simplify access and organization of Information Technology (IT) services. One mechanism for providing such IT simplification is Service Oriented Architecture (SOA). Application of SOA principles promises faster development cycles, increased reusability and better change tolerance for software components.

Unfortunately, enterprises that implement SOA often find that the start-up complexities of SOA delays, if not derails, the expected return on investment. While SOA simplifies the complexity of an IT environment, organizations lack sufficient experience with SOA technology required for a quick, trouble-free implementation. Compounding this experience gap, graphical tools for implementing SOA are not readily available, so that data services for use in SOA environments often must be hand-coded.

For enterprise-class portal and Web applications, for example, a majority of application development time can be spent on managing data access. A number of factors make data programming difficult and time-consuming, including a lack of flexibility in conventional data services. Because conventional data services are hand-coded, these services are capable of returning data only as the service has been defined to return it. Accordingly, such conventional services are known as "opaque" services. Users, however, desire variations in the data that the data services return. Unfortunately, conventional approaches require the designer of the service to anticipate all of the possible variations and provide users of the service with responses for each possible variation hard coded into SQL. Such conventional approaches are unable to support services that do not use SQL at all or that employ multiple databases.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGURES 1A - 1 C are functional block diagrams illustrating an example computing environment in which techniques for accessing a service may be implemented in one embodiment.

FIGURES 2A - 2F are operational flow diagrams illustrating a high level overview of techniques for accessing a service of an embodiment.

FIGURES 3A - 3C are operational flow diagrams illustrating a high level overview of techniques for accessing services and providing a result set in an embodiment. FIGURE 4 is a screen shot illustrating a high level overview of a user interface operable with the techniques for accessing services in an embodiment.

FIGURE 5 is a hardware block diagram of an example computer system, which may be used to embody one or more components of an embodiment.

DETAILED DESCRIPTION

In accordance with embodiments of the present invention, there are provided mechanisms and methods for accessing a service on behalf of a requestor and conforming the result to a form that the requestor desires the result to have. These mechanisms and methods for accessing a service make it possible for results from the service to be provided to the requestor in the form that the requestor prefers. Services providing this capability are termed "smart services". Some of the many types of forms available to requestors in various embodiments include, without limitation, filtered, alphabetized, numerically ordered, sort ordered, truncated, as well as other types of formatting in accordance with the requestor's criteria.

In one embodiment, the invention provides a method for accessing a service. One embodiment of the method includes receiving a request to access at least one service and a criteria indicating a form that the requestor prefers a result to have. The at least one service is accessed on behalf of the requestor. A result set is received from the at least one service responsive to the accessing. The result set is provided to the requestor formatted in the form that the requestor prefers. Selected portions of the result set provided to the requestor are mapped to a view associated with the requestor. In one embodiment, providing the result set in the form that the requestor prefers includes formatting the result set from the service according to the criteria provided by the requestor.

This ability to access a service on behalf of a requestor and return the result set in a form preferred by the requestor makes it possible to attain improved usage from computing resources in a computer system because users can obtain results in a preferred form without the necessity of hard-coding all anticipated preferred forms into each service.

In another method embodiment, the method includes receiving a request to access at least one service and a filter indicating a query to be applied to a result set returned by -A-

the at least one service. The at least one service is accessed on behalf of the requestor. A result set is received from the at least one service responsive to the accessing. A filtered result set is provided to the requestor by applying the filter to the result set received from the at least one service. In one embodiment, providing the filtered result set in includes forming the filtered result set by applying the query to the result set received from the service. Filtering the result set from the service can include one or more of filtering, alphabetizing, numerical ordering, sort ordering and truncating the result set. This ability to access a service on behalf of a requestor and apply queries to results returned by the service makes it possible to attain improved usage from computing resources in a computer system because users can obtain results in a filtered form without the necessity of hard-coding all anticipated filtered forms into each service.

In a further method embodiment, an SQL query is received. A request to access at least one of a plurality of services based upon the SQL query is prepared. The request is prepared in a form that a service is able to understand. In one embodiment, the request is prepared by mapping the SQL query to an XQuery request for accessing the service(s). The at least one of a plurality of services is accessed using the request to obtain a result set. A virtual SQL table comprising data selected from the result set responsive to the SQL query is prepared.

These mechanisms and methods for providing an SQL interface for a service make it possible for data from a plurality of services to be provided to a requestor so that the data appears to the requestor as having been organized into a single virtual SQL table. This ability of embodiments to provide data from a plurality of services to a requestor so that the data appears to the requestor as having been organized into a single virtual SQL table enables an SQL application making the SQL query to interface with the at least one of a plurality of services to obtain information using SQL format.

As used herein, the term service is intended to be broadly construed to include any application, program or process resident on one or more computing devices capable of providing services to a requestor or other recipient, including without limitation network based applications, web based server resident applications, web portals, search engines, photographic, audio or video information storage applications, e-Commerce applications, backup or other storage applications, sales/revenue planning, marketing, forecasting, accounting, inventory management applications and other business applications and other contemplated computer implemented services. The term result set is intended to be broadly construed to include any result provided by one or more services. Result sets may include multiple entries into a single document, file, communication or other data construct. As used herein, the term criteria is intended to be broadly construed to include any mechanism for informing a computational entity of a need, desire or request by a user that may be human or a computational entity. As used herein, the term view is intended to be broadly construed to include any mechanism that provides a presentation of data and/or services in a format suited for a particular application, service, client or process. The presentation may be virtualized, filtered, molded, or shaped. For example, data returned by services to a particular application (or other service acting as a requestor or client) can be mapped to a view associated with that application (or service). Embodiments can provide multiple views of available services to enable organizations to compartmentalize or streamline access to services, increasing the security of the organization's IT infrastructure. As used herein, the term virtual SQL table is intended to be broadly construed to include any functional equivalent to a real SQL table. Some examples of virtual SQL tables include without limitation, a virtual SQL table comprising data about customers. An application in a business environment may use an SQL query statement such as "SELECT [ALL ) DISTINCT] columnnamel [,columnname2] FROM tablenamel [,tablename2] [WHERE condition] [ and|or condition...] [GROUP BY column-list] [HAVING "conditions] [ORDER BY "column-list" [ASC | DESC] ]" in conjunction with an invocation of one or more services for customer information, "getCustomer()" in order to perform the indicated selection operation(s) on the results returned from the getCustomer function. For example, in a banking application, a requestor at the bank may specify an SQL select statement to operate on retrieved information in a virtual SQL table named "Customers" to the customer entries having a balance in the "balance" column of the virtual SQL table "WHERE balance > 100,000" in order to limit the customers returned a getCustomer query returns to only high net worth customers. In a manufacturing example, a requestor in accounting may specify SELECT Order_amount column from the Ordersjable virtual SQL table WHERE "order amount <= 300,000 units" to see only results of smaller orders in the work in progress (WIP) residing on the factory floor. In the telecommunications field, a requestor desirous of viewing network nodes capable of handling a large bandwidth may specify an SQL statement SELECT Node_bandwidth column from the Nodes_table virtual SQL table WHERE "bandwidth > 1 Mps" for a query requesting node identities in the network in order to cause the server to eliminate any nodes not capable of supporting at least this bandwidth. These and other applications can be enabled by some of the many embodiments provided by the present invention. It is noteworthy that different implementations for the Select command may exist. Accordingly, the foregoing examples are intended to be illustrative and not limiting of the many different applications enabled by various embodiments.

FIGS. 1A - 1 C are functional block diagrams illustrating an example computing environment in which techniques for accessing a service may be implemented in one embodiment. As shown in FIG. 1A₁ a liquid data framework 104 is used to provide a mechanism by which a set of applications, or application portals 94, 96, 98, 100 and 102, can integrate with, or otherwise access in a tightly couple manner, a plurality of services. Such services may include a Materials Requirements and Planning (MRP) system 112, a purchasing system 114, a third-party relational database system 116, a sales forecast system 118 and a variety of other data-related services 120. Although not shown in FIG. 1A for clarity, in one embodiment, one or more of the services may interact with one or more other services through the liquid data framework 104 as well.

Internally, the liquid data framework 104 employs a liquid data integration engine 110 to process requests from the set of portals to the services. The liquid data integration engine 110 allows access to a wide variety of services, including data storage services, server-based or peer-based applications, Web services and other services capable of being delivered by one or more computational devices are contemplated in various embodiments. A services model 108 provides a structured view of the available services to the application portals 94, 96, 98, 100 and 102. In one embodiment, the services model 108 provides a plurality of views 106 that may be filtered, molded, or shaped views of data and/or services into a format specifically suited for each portal application 94, 96, 98, 100 and 102. In one embodiment, data returned by services to a particular application (or other service acting as a requestor or client) is mapped to the view 106 associated with that application (or service) by liquid data framework 104. Embodiments providing multiple views of available services can enable organizations to compartmentalize or streamline access to services, thereby increasing the security of the organization's IT infrastructure. In one embodiment, services model 108 may be stored in a repository 122 of service models. Embodiments providing multiple services models can enable organizations to increase the flexibility in changing or adapting the organization's IT infrastructure by lessening dependence on service implementations. FIG. 1 B is a high level schematic of a liquid data integration engine 110 illustrated in FIG. 1A with reference to one example embodiment. As shown in FlG. 1 B, the liquid data integration engine 110 includes an interface processing layer 140, a query compilation layer 150 and a query execution layer 160. The interface layer 140 includes a request processor 142, which takes the request 10 and processes this request into an XML query 50. Interface layer 140 also includes access control mechanism 144, which determines based upon a plurality of policies 20 whether the client, portal application, service or other process making the request 10 is authorized to access the resources and services required to satisfy the request. Provided that the client, application, service or other process is authorized to make the request 10, the interface layer sends the XML query 50 to the query compilation layer 150.

Within the query compilation layer 150, a query parsing and analysis mechanism 152 receives the query 50 from the client applications, parses the query and sends the results of the parsing to a query rewrite optimizer 154. The query rewrite optimizer 154 determines whether the query can be rewritten in order to improve performance of servicing the query based upon one or more of execution time, resource use, efficiency or other performance criteria. The query rewrite optimizer 154 may rewrite or reformat the query based upon input from one or more of a source description 40 and a function description 30 if it is determined that performance may be enhanced by doing so. A runtime query plan generator 156 generates a query plan for the query provided by the query rewrite optimizer 154 based upon input from one or more of the source description 40 and the function description 30.

The query compilation layer 150 passes the query plan output from the runtime query plan generator 156 to a runtime query engine 162 in the query execution layer 160. The runtime query engine 162 is coupled with one or more functions 70 that may be used in conjunction with formulating queries and fetch requests to sources 52, which are passed on to the appropriate service(s). The service responds to the queries and fetch requests 52 with results from sources 54. The runtime query engine 162 of the query execution layer 160 translates the results into a format usable by the client or portal application, such as without limitation XML, in order to form the XML query results 56.

Before responses or results 56 are passed back to the client or portal application making the request, a query result filter 170 in the interface layer 140 determines based upon filter parameters 90 what portion of the results will be passed back to the client or portal application, forming a filtered query response 58. Although not shown in FIG. 1 B for clarity, filter parameters 90 may accompany service request 10 in one embodiment. Further, query result filter 170 also determines based upon access policies implementing security levels 80 what portions of the filtered query response 58 a requestor is permitted to access and may redact the filtered query response accordingly. Although not shown in FIG. 1 B for clarity, access policies implementing security levels 80 may be stored with policies 20 in one embodiment. Techniques for providing a result set to the requestor in the form that the requestor prefers implemented by query result filter 170 will be described below in greater detail with reference to FIGS. 2A - 2B. Techniques for providing a filtered result set to the requestor implemented by query result filter 170 will be described below in greater detail with reference to FIGS. 2C - 2D. When properly formed, the response is returned to the calling client or portal application.

In an SQL query processing embodiment, as shown in FIG. 1C, before responses or results 56 are passed back to the client or portal application making the request, a query result filter/SQL processor 170 in the interface layer 140 determines based upon an SQL query 90 what portion of the results will be passed back to the client or portal application and in what form or format, forming a virtual SQL table 58. Although not shown in FIG. 1C for clarity, SQL query 90 may accompany service request 10 in one embodiment. Further, query result filter/SQL processor 170 also determines based upon access policies implementing security levels 80 what portions of the virtual SQL table 58 a requestor is permitted to access and may redact the virtual SQL table accordingly. Techniques for providing an SQL interface for a service implemented by query result filter/SQL processor 170 will be described below in greater detail with reference to FIGS. 2E - 2F. When properly formed, the response is returned to the calling client or portal application.

In one embodiment, result sets are returned to the client in a format specified by Service Data Objects (SDO). SDO is a specification published jointly by BEA and IBM (submitted as a Java Specification Request as JSR 235) that defines a data programming architecture and an Application Programming Interface (API). In embodiments employing SDO, Java clients associated with portal applications 94, 96, 98, 100 and 102 of FIG. 1A access data services 112 - 120 via liquid data framework 104 through SDO. When a Java or other client calls a data service read function, it gets data back in the form of a data object. A data object is the basic unit of the SDO model.

In one embodiment, SDO coupled with liquid data framework 104 provides data updates that are seamless to the client — the client simply calls an update function on changed data. The rest of the processing is taken care of by the Liquid Data integration engine 110, which includes deployed services, SDO exits, a mediator, a query engine and the like. In this embodiment, a process for making updates to data will now be described. When one of its read functions is called, a data service 112 - 120 of FIG. 1A returns an SDO data object to the client application 94, 96, 98, 100 and 102 of FIG. 1A, service, or other process. The application may be a Java application, a portal, JSP-based web application, business process model, a service, process or many other things. The application 94, 96, 98, 100 and 102 of FIG. 1A, for example, may modify values in the data object, for example, adding, deleting, or inserting values. Changes are tracked in a change log, a list of value changes that is associated with the data object. When ready, the client application 94, 96, 98, 100 and 102 of FIG. 1A, service or other process submits the changes back to Liquid Data framework 104. Liquid Data framework 104 determines where the data came from. It also checks for custom update modules; extensions to the update process, for example, to apply custom accounting logic to the update or to propagate the update. The Liquid Data framework 104 then propagates the changes back to the data sources associated with services 112 - 120 in FIG. 1A. Accordingly, by insulating the client from the complexity of data update logic as described above, some embodiments can save substantial amounts of the time required to develop portals or similar web applications.

FIG. 2A is an operational flow diagram illustrating a high level overview of a technique for accessing a service of one embodiment. The technique for accessing a service shown in FIG. 2A is operable with an application sending data, such as Materials Requirements and Planning (MRP) system 112, an purchasing system 114, a third-party relational database system 116, sales forecast system 118, or a variety of other data- related services 120 of FIG. 1A, for example. As shown in FIG. 2A, a request to access at least one service and a criteria indicating a form that the requestor prefers a result to have are received (block 202). The at least one service is accessed on behalf of the requestor (block 204). A result set is received from the at least one service responsive to the accessing (block 206). A result set comprised of selected portions of the result set(s) received from the one or more services is provided to the requestor formatted in the form that the requestor prefers (block 208). The selected portions of the result set provided to the requestor are mapped to a view associated with the requestor. In one embodiment, providing the result set in the form that the requestor prefers includes formatting the result set from the service according to the criteria provided by the requestor. Formatting the result set from the service can include one or more of filtering, alphabetizing, numerical ordering, sort ordering and truncating the result set in accordance with the criteria. Liquid data framework 104 can map the portion of the result set provided to the requestor to a view associated with the requestor. In one embodiment, the method illustrated by blocks 202 - 208 may be advantageously disposed in the interface processing layer 140, query compilation layer 150 and query execution layer 160 of FIG. 1 B.

FIG. 2B is an operational flow diagram illustrating a high level overview of a client process operable with the technique for accessing a service illustrated in FIG. 2A. The technique for receiving data in an indicated form shown in FIG. 2B is operable with an application sending data, such as applications application 94, 96, 98, 100 and 102 of FIG. 1A, for example or a service, such as Materials Requirements and Planning (MRP) system 112, an purchasing system 114, a third-party relational database system 116, sales forecast system 118, or a variety of other data-related services 120 of FIG. 1A. As shown in FIG. 2B, a request to access a service and a criteria indicating a preferred form for a result is sent to a server (block 212). A result set is received from the server responsive to the request (block 214). The result set is in the preferred form.

FIG. 2C is an operational flow diagram illustrating a high level overview of a technique for applying queries to results returned by services of one embodiment. The technique for applying queries to results returned by services shown in FIG. 2C is operable with an application sending data, such as Materials Requirements and Planning (MRP) system 112, an purchasing system 114, a third-party relational database system 116, sales forecast system 118, or a variety of other data-related services 120 of FIG. 1A, for example. As shown in FIG. 2C, a request to access a service and a filter indicating a query to be applied to a result returned by the service are received (block 222). The service is accessed on behalf of the requestor (block 224). A result set is received from the service responsive to the request (block 226). A filtered result set is provided to the requestor by applying the filter to the result set received from the service (block 228). The liquid data framework 104 maps the result set to a view associated with the requestor. In one embodiment, providing the filtered result set in includes forming the filtered result set by applying the query to the result set received from the service. Filtering the result set from the service can include one or more of filtering, alphabetizing, numerical ordering, sort ordering and truncating the result set in accordance with the filter. In one embodiment, the method illustrated by blocks 222 - 228 may be advantageously disposed in the interface processing layer 140, query compilation layer 150 and query execution layer 160 of FIG. 1 B.

FIG. 2D is an operational flow diagram illustrating a high level overview of a client process operable with the technique for accessing a service illustrated in FIG. 2C. The technique for receiving filtered data shown in FIG. 2D is operable with an application sending data, such as applications application 94, 96, 98, 100 and 102 of FIG. 1A, for example or a service, such as Materials Requirements and Planning (MRP) system 112, an purchasing system 114, a third-party relational database system 116, sales forecast system 118, or a variety of other data-related services 120 of FIG. 1A. As shown in FIG. 2D, a request to access a service and a filter indicating a query to be applied to a result returned by the service is sent to a server (block 232). A result set is received from the server responsive to the request (block 234). The result set is filtered according to the query and mapped to a view associated with a requestor. FIG. 2E is an operational flow diagram illustrating a high level overview of a technique for providing an SQL interface for a service of one embodiment. The technique for providing an SQL interface for a service shown in FIG. 2E is operable with an application sending data, such as Materials Requirements and Planning (MRP) system 112, an purchasing system 114, a third-party relational database system 116, sales forecast system 118, or a variety of other data-related services 120 of FIG. 1A, for example. As shown in FIG. 2E, an SQL query is received (block 242). A request to access at least one of a plurality of services based upon the SQL query is prepared (block 244). The request is prepared in a form that a service is able to understand. In one embodiment, the request is prepared by mapping the SQL query to an XQuery request for accessing the service(s). The at least one of a plurality of services is accessed (block 246) using the request to obtain a result set. A virtual SQL table comprising data selected from the result set responsive to the SQL query is prepared (block 248). In one embodiment, the method illustrated by blocks 242 - 248 may be advantageously disposed in the interface processing layer 140, query compilation layer 150 and query execution layer 160 of FIG. 1C.

FIG. 2F is an operational flow diagram illustrating a high level overview of a client process operable with the technique for accessing a service illustrated in FIG. 2E. The technique for receiving data from a service via an SQL interface shown in FIG. 2F is operable with an application sending data, such as applications application 94, 96, 98, 100 and 102 of FIG. 1A, for example or a service, such as Materials Requirements and Planning (MRP) system 112, an purchasing system 114, a third-party relational database system 116, sales forecast system 118, or a variety of other data-related services 120 of FIG. 1A. As shown in FIG. 2F, a request to access a service is sent to a server (block 252). A result set is received (block 254) from the server. The result set includes a portion that has been prepared by the server from one or more services so that the data appears to the requestor as having been organized into a single virtual SQL table. FIG. 3A is an operational flow diagram illustrating a high level overview of another technique for accessing services and providing a result set in a form preferred by a requestor in one embodiment of the present invention. The technique for accessing a service shown in FIG. 3A is operable with an application sending data, such as the applications described above with reference to FIG. 2A. As shown in FIG. 3A, a request for information from a plurality of services and a criteria indicating a form that the requestor prefers the result to have are received from a requestor (block 302). A first database associated with a first service is accessed (block 304). A second database associated with a second service is accessed (block 306). A first result set is received from the first service (block 308). A second result set is received from the second service (block 310). A result set comprising content selected from the first result set and the second result set formatted according to the form that the requestor prefers is provided to the requestor (block 312). The result set provided to the requestor is mapped to a view associated with the requestor. In one embodiment, at least one of the first database and the second database is a non-SQL format database.

FIG. 3B is an operational flow diagram illustrating a high level overview of another technique for accessing services and applying filtering to a result set according indications received from a requestor in one embodiment. The technique for accessing a service shown in FIG. 3B is operable with an application sending data, such as the applications described above with reference to FIG. 2C. As shown in FIG. 3B, a request for information from a plurality of services, and a filter indicating a query to be applied to a result received from the plurality of services are received from a requestor (block 322). A first database associated with a first service is accessed (block 324). A second database associated with a second service is accessed (block 326). A first result set is received from the first service (block 328). A second result set is received from the second service (block 330). A result set comprising content selected from the first result set and the second result set is provided to the requestor in accordance with the filter (block 332) and mapped to a view associated with the requestor. In one embodiment, at least one of the first database and the second database is a non-SQL format database.

FIG. 3C is an operational flow diagram illustrating a high level overview of an example application employing one technique for accessing services and applying SQL format commands to a result set according indications received from a requestor in one embodiment. The technique for accessing a service shown in FIG. 3C is operable with an application sending data, such as the applications described above with reference to FIG. 2E. As shown in FIG. 3C, a request for information from a plurality of services, and an SQL statement indicating a query to be applied to a result received from the plurality of services are received from a requestor (block 342). A first database associated with a first service is accessed (block 344) using the SQL query mapped to a form that the service understands. A second database associated with a second service is accessed (block 346) using the SQL query mapped to a form that the service understands. A first result set is received from the first service (block 348). A second result set is received from the second service (block 350). A result set comprising content selected from the first result set and the second result set is provided to the requestor as a virtual SQL table in accordance with the SQL statement (block 352). In one embodiment, at least one of the first database and the second database is a non-SQL format database. FIG. 4 is a screen shot illustrating a high level overview of a user interface operable with the technique for accessing a service illustrated in FIGS. 2A - 3C. As shown in FIG. 4, screen 400 includes a viewing area 402 in which results from one or more data services may be displayed. A requestor may enter an amount to filter results by and select the apply filter button 404 in order to filter on a data service. The processing of FIGS. 2A - 3C will apply this input to ensure that results from the one or more services are filtered according to the amount entered by the requestor. Similarly, the requestor may select one or more column headings 406 in order to cause the processing of FIGS. 2A - 3C to sort the results from the service(s) by the field(s) corresponding to the selected column heading. Screen 400 also includes other mechanisms for controlling the results of services, such as pagination or truncation selection buttons 408 and a "submit all changes" button 410 to invoke batched updates to the results returned by the services.

The operation of one embodiment will be described in further detail with reference to examples of usage scenarios. In the illustrated embodiment, a client makes queries about Customers, each having 0 or more nested Orders in XML format. Using techniques provided herein, the client is able to obtain results from services in a desired form without the necessity of becoming fluent in preparing XQuery statements.

The client instantiates an instance of an XQueryFilter object defined in Table 1 that can be passed to an XQuery engine (along with Function Name defined in XDS).

Table 1: XQueryFilter object

¹ public class XQueryFilter extends J ava . lang . Obj ect implements j ava . io . Serializable

The XQuery engine processes these filters/orderderby list, generates and executes an appropriate XQuery. This approach is especially useful in situations where an XML Data Service (XDS) returns a document that contains nested objects and the user wants to see different views based on certain conditions. For example, if the returned document is: (CUSTOMERS/CUSTOMER/ORDER), i.e., CUSTOMERS is the toplevel document element. CUSTOMER is a sequence inside CUSTOMERS that can be repeated. ORDER is a sequence inside CUSTOMER that can be repeated. Table 2 illustrates an example XML data for Customers, having nested Orders:

Table 2: Customers with nested orders i <customers>

2 <customer id="CUSTOMER_1 ">

3 <name>JOHN_l</ name>

4 <order id="ORDER_ID_1_0">

5 < T0TAL_0RDER_AM0UNT> 1000</TOTAL_ORDER_AMOUNT>

6 </order>

7 < order i d= " ORDER_ID_1_1 " >

8 < T0TAL_0RDER_AM0UNT> 1500</TOTAL_ORDER_AMOUNT>

9 </order>

10 </customer>

11 < cus tomer id= " CUSTOMER_10 ">

12 <name>JOHN_10</name>

13 <order id="0RDER_ID_l0_0">

14 < T0TAL_0RDER_AM0UNT> 1000</TOTAL_ORDER_AMOϋNT>

IS </order>

16 </customer>

17 <customer id="CUST0MER_2">

18 <name>J0HN__2</ name>

19 <order id="0RDER_XD_2_0 ">

20 < T0TAL_0RDER_AM0UNT> 1000< /T0TAL_0RDER_AM0UNT>

21 </order>

22 < order Id= " 0RDER_ID_2_l " >

23 < T0TAL_0RDER_AM0ϋNT> 1500< /T0TAL_0RDER_AM0JMT>

24 < /σrder>

25 < order id= " 0RDER_ID_2_2 " >

26 < T0TAL_0RDER_AM0UNT> 2000< /T0TAL_0RDER_AM0UNT>

27 </order>

28 </customer>

29 </customers>

A hypothetical user may want to see large orders (i.e. TOTAL_ORDER_AMOUNT > 1000). Four example cases in which the user can filter service data having the XML schema provided in Table 2 will be described:

1. Only CUSTOMER objects that have at least one large order and view All ORDER objects for such CUSTOMER

2. All CUSTOMER objects but Only Large ORDER objects

3. Only CUSTOMER objects that have at least one large order and view only Large ORDER objects (basically 1 & 2) 4. Only CUSTOMER objects that have only large orders (i.e. ORDER_AMOUNT > 1000).

Instead of writing XQuery for each of these 4 cases, the user need only pass the XqueryFilter object as parameter when invoking a service via the liquid data framework 104 of FIG. 1A, for example.

In a first case scenario, the user would like to filter based upon customers (top level object) only, by applying criteria to the lower level object (i.e. order/TOTAL_ORDER_AMOUNT). All Customers that have aϊ least one large order will be returned with all orders (i.e. orders will not be filtered). An example of adding the filter at the client is depicted in Table 3:

Table 3: Client AddFilter to filter only customers

XQueryFilter filter = new XQueryFilter (); filter . addFilter ( "CUSTOMER" , "CUSTOMER/ORDΞR/ORDER_AMOUNT

", ">", "1000") ;

The corresponding XQuery generated for the client's addfilter invocation in Table 3 is shown in Table 4:

Table 4: Query for filter only customers

For $c in document (Customers) /Customers/Customer

Where some $o in $c/order satisfies $θ/T0TAL_0RDER_AMOUNT > 1000 Return $c

This query will produce the output shown in Table 5. Note that CUSTOMER_10, lines 11 - 16 of Table 2, is not returned in the output of Table 5, because there are no orders larger than 1000 associated with CUSTOMER_10. Also note that no orders were filtered even though orders with less than or equal to 1000 units exist in the data returned by the service. Table 5: Output for filter only customers i <customers>

2 <customer id="CUSTOMER_l"> 3 <name>JOHN_l</ name> 4 <order id= "ORDER_ID_1_0 "> S < T0TAL_0RDER_AM0UNT> 1000< /T0TAL_0RDER_AM0UNT> 6 </order> 7 < order i d= " ORDER_ID_1_1 " > a < T0TAL_0RDER_AM0ϋNT> 1500</TOTAL_ORDER_AMOUNT>

9 </order>

10 </customer>

11 < customer id= "CUST0MER_2 ">

12 <name>J0HN_2</ name>

13 <order id= "ORDER_ID_2_0 ">

14 < T0TAL_0RDER_AM0UNT> 1000</TOTAL_ORDER_AMOUNT>

15 </order>

16 < order id= " 0RDER_ID_2_l " > n < TOTAL_ORDER_AMOUNT>1500</TOTAL_ORDER_AMOUNT>

18 </order> 19 < order id= "0RDER_ID_2_2 "> 20 < T0TAL_0RDER_AM0UNT> 2000</TOTAL_ORDER_AMOUNT> 21 </order> 22 </customer> 23 </customers> 24

In a second case scenario, the user would like to see only larger orders and only those customers that have these orders. An example of adding the filter at the client for this scenario is depicted in Table 6:

Table 6: Client AddFilter for only larger orders and only those customers with these orders i XQueryFilter filter = new XQueryFilter () ;

2

3 filter. addFilter ("CUSTOMER" , "CUSTOMER/ORDER/ORDΞR_AMOIMT" ,

">", "1000") ;

Table 7 illustrates corresponding XQuery generated for the client's addfilter shown in Table 6: Table 7: Query for filter only larger orders and. only those customers with these orders

2 2 For $c in document(Customers)/Customers/Customer

3 Where some $o in $c/order satisfies $o/TOTAL_ORDER_AMOUNT >

4 1000

5 Return

6 <customer id = {$c/@id}>

7 {$c/name}

8 {$c/othet customer elements except order}

9

10 {

For $ord in $c/order

11

12 Wliere $ord/TOTAL_ORDER_AMOUNT > 1000

13 Return $ord

}

</customer>

This query will produce the output shown in Table 8. Note that, in Table 8, the output has been filtered by the nested object (order) as well as by the first level object (customer).

Table 8: Output for filter only larger orders and only those customers with these orders i <customers>

2 < cus toitier i d= "CUSTOMER_1 "> 3 <name>JOHN_l</ name> 4 < order id= " ORDER_ID_1_1 " > 5 < T0TAL_0RDER_AM0UNT> 1500</TOTAL_ORDER_AMOUNT> 6 </order> 7 </customer>

< customer id= " CUST0MER__2 " >

9 <name>J0HN_2</ name>

10 < order id= " 0RDER_ID_2_l " >

11 < T0TAL_0RDER_AM0UNT> 1500</TOTAL_ORDER_AMOϋNT>

12 < /order>

13 < order id= "0RDER_ID_2_2 ">

14 < T0TAL_0RDER__AM0UNT> 2000</TOTAL_ORDER_AMOϋNT>

15 </order>

16 </customer>

17 </ customer s>

18 In a third case scenario, the user would like to see all customers (i.e. no filter at top level), however, only large orders. In other words, there should be nothing displayed for customers who do not have any large orders. An example of adding the filter at the client for this scenario is depicted in Table 9:

Table 9: Client AddFilter for filter only larger orders but show all customers

XQueryPilter filter = new XQueryPilter () ; filter . addFilter ( "CUSTOMER/ORDER" , "CUSTOMER/ORDER/ORDER_AMOUNT^I

1000") ;

Table 10 illustrates a generated XQuery corresponding to Table 9:

Table 10: Query for filter only larger orders but show all customers i For $c in document(Customers)/Customers/Customer

2

3 Return

4 <customer id = {$c/@id}>

5 f$c/name}

6 {$c/othet customer elements except order}

7 {

S For $ord in $c/order

9 Where $ord/TOTAL_ORDER_AMOUNT > 1000

10

11 Return $ord

12 }

This query will produce the output shown in Table 11. Note that, in lines 8 - 10 of Table 11 , the output will include CUSTOMERJ 0, but no orders for CUSTOMER_10 are shown because no large orders (i.e., > 1000) are associated with this customer in the data schema in Table 2.

Table 11 : Output for filter only larger orders but show all customers

<customers>

<customer id="CUSTOMER_1 "> <name>JOHN_l</ name>

<order id="ORDER_ID_1_1 ">

<TOTAL_ORDER_AMOUNT>1500</TOTAL_ORDER_AMOUNT> </order>

In a fourth case scenario, the user would like to see only those customers that have exclusively large orders. An example of adding the filter at the client for this scenario is depicted in Table 12:

Table 12: Client AddFilter for filter only larger orders but show all customers

XQueryFilter filter = new XQueryFilter (); filter . addFilter ( "CUSTOMER/ORDER" , "CUSTOMER/ORDΞR/ORDER_AMOUNT'

"1000") ;

Table 13 illustrates an XQuery generated for the addfilter case shown in Table 12:

Table 13: Query for filter only those customers that have only large orders

For $c in document(Customers)/Customers/Customer

Where every $o in $c/order satisfies $o/TOTAL_ORDER_AMOUNT >

1000 Return $c

In this example, since there are no customers that have only large orders in the data in Table 2, the above query will return an empty set. While the foregoing example illustrates the use of techniques for filtering the information returned by a service prior to providing the information to the user, the techniques provided by the present invention are not nearly so limited, and can provide other forms of customizing, ordering or truncating data provided by services.

In other aspects, the invention encompasses in some embodiments, computer apparatus, computing systems and machine-readable media configured to carry out the foregoing methods. In addition to an embodiment consisting of specifically designed integrated circuits or other electronics, the present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art. The present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of rotating media including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, and magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, and user applications.

Included in the programming (software) of the general/specialized computer or microprocessor are software modules for implementing the teachings of the present invention, including, but not limited to providing mechanisms and methods for accessing a service as discussed herein. FIG. 5 illustrates an exemplary processing system 500, which can comprise one or more of the elements of FIGS. 1A - 1C. Turning now to FIG. 5, an exemplary computing system is illustrated that may comprise one or more of the components of FIGS. 1A - 1 C. While other alternatives might be utilized, it will be presumed for clarity sake that components of the systems of FIGS. 1A - 1C are implemented in hardware, software or some combination by one or more computing systems consistent therewith, unless otherwise indicated.

Computing system 500 comprises components coupled via one or more communication channels (e.g., bus 501) including one or more general or special purpose processors 502, such as a Pentium®, Centrino®, Power PC®, digital signal processor ("DSP"), and so on. System 500 components also include one or more input devices 503 (such as a mouse, keyboard, microphone, pen, and so on), and one or more output devices 504, such as a suitable display, speakers, actuators, and so on, in accordance with a particular application. (It will be appreciated that input or output devices can also similarly include more specialized devices or hardware/software device enhancements suitable for use by the mentally or physically challenged.)

System 500 also includes a computer readable storage media reader 505 coupled to a computer readable storage medium 506, such as a storage/memory device or hard or removable storage/memory media; such devices or media are further indicated separately as storage 508 and memory 509, which may include hard disk variants, floppy/compact disk variants, digital versatile disk ("DVD") variants, smart cards, read only memory, random access memory, cache memory, and so on, in accordance with the requirements of a particular application. One or more suitable communication interfaces 507 may also be included, such as a modem, DSL, infrared, RF or other suitable transceiver, and so on for providing inter-device communication directly or via one or more suitable private or public networks or other components that may include but are not limited to those already discussed.

Working memory 510 further includes operating system ("OS") 511 elements and other programs 512, such as one or more of application programs, mobile code, data, and so on for implementing system 500 components that might be stored or loaded therein during use. The particular OS or OSs may vary in accordance with a particular device, features or other aspects in accordance with a particular application (e.g. Windows, WindowsCE, Mac, Linux, Unix or Palm OS variants, a cell phone OS, a proprietary OS, Symbian, and so on). Various programming languages or other tools can also be utilized, such as those compatible with C variants (e.g., C++, C#), the Java 2 Platform, Enterprise Edition ("J2EE") or other programming languages in accordance with the requirements of a particular application. Other programs 512 may further, for example, include one or more of activity systems, education managers, education integrators, or interface, security, other synchronization, other browser or groupware code, and so on, including but not limited to those discussed elsewhere herein.

When implemented in software (e.g. as an application program, object, agent, downloadable, servlet, and so on in whole or part), a learning integration system or other component may be communicated transitionally or more persistently from local or remote storage to memory (SRAM, cache memory, etc.) for execution, or another suitable mechanism can be utilized, and components may be implemented in compiled or interpretive form. Input, intermediate or resulting data or functional elements may further reside more transitionally or more persistently in a storage media, cache or other volatile or non-volatile memory, (e.g., storage device 508 or memory 509) in accordance with a particular application.

Other features, aspects and objects of the invention can be obtained from a review of the figures and the claims. It is to be understood that other embodiments of the invention can be developed and fall within the spirit and scope of the invention and claims. The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.

Claims

In the Claims:

1. A method for accessing a service, the method comprising: receiving, from a requestor, a request to access at least one service and a criteria indicating a form that the requestor prefers a result to have; accessing the at least one service on behalf of the requestor; receiving at least one result set from the at least one service responsive to the accessing; and providing, to the requestor, a result set comprised of selected portions of the at least one result set formatted in the form that the requestor prefers, wherein the selected portions of the result set provided to the requestor are mapped to a view associated with the requestor.

2. The method of claim 1 , wherein providing, to the requestor, the result set in the form that the requestor prefers comprises: formatting the result set from the service according to the criteria.

3. The method of claim 2, wherein formatting the result set from the service according to the criteria further comprises at least one of: filtering, alphabetizing, numerical ordering, sort ordering and truncating the result set in accordance with the criteria.

4. The method of claim 1 , wherein receiving, from a requestor, a request to access at least one service and a criteria indicating a form that the requestor prefers a result to have comprises: receiving, from a requestor, a request to access at least one service and a filter indicating a query to be applied to a result returned by the at least one service.

5. The method of claim 4, wherein providing, to the requestor, the result set in the form that the requestor prefers comprises: providing a filtered result set by applying the filter to the result set received from the at least one service, wherein the filtered result set is mapped to a view associated with the requestor.

6. The method of claim 5, wherein providing a filtered result set further comprises: forming the filtered result set by applying the filter to the result set received from the service.

7. The method of claim 6, wherein forming the filtered result set by applying the query to the result set received from the service further comprises at least one of: filtering, alphabetizing, numerical ordering, sort ordering and truncating the result set in accordance with the filter.

8. The method of claim 1 , wherein the service includes a computer resident application capable of providing services to a requestor or other recipient.

9. The method of claim 8, wherein the service includes at least one of: a network based application, a web based server resident application, a web portal, a search engine, a photographic, audio or video information storage application, an e-Commerce application, a backup or other storage application, a sales/revenue planning, marketing, forecasting, accounting, inventory management applications or other business application.

10. The method of claim 1 , further comprising: sending to the server a request to access at least one service and a criteria indicating a preferred form for a result; and receiving, from the server, a result set from the at least one service responsive to the request, wherein the result set is formatted in the preferred form, and wherein the result set is mapped to the view associated with a requestor.

11. The method of claim 10₁ wherein sending to a server a request to access a service and a criteria indicating a preferred form for a result further comprises: sending to a server a criteria indicating that the preferred form for the result is at least one of filtered, alphabetized, numerically ordered, sort ordered and truncated.

12. The method of claim 1 , further comprising: accessing a first database associated with a first service; accessing a second database associated with a second service; receiving a first result set from the first service; receiving a second result set from the second service; and providing, to the requestor, a result set comprising content selected from the first result set and the second result set formatted in the form that the requestor prefers, wherein the result set provided to the requestor is mapped to a view associated with the requestor.

13. The method of claim 12, wherein at least one of the first database and the second database is a non-SQL format database.

14. The method of claim 1 , wherein receiving, from a requestor, a request to access at least one service and a criteria indicating a form that the requestor prefers a result to have comprises: receiving an SQL query.

15. The method of claim 14, wherein providing, to the requestor, the result set in the form that the requestor prefers comprises: preparing a virtual SQL table comprising data selected from the result set responsive to the SQL query.

16. The method of claim 15, wherein preparing a virtual SQL table comprising data selected from the result set responsive to the SQL query comprises: providing data from the plurality of services to the requestor so that the data appears to the requestor as having been organized into a single virtual SQL table.

17. The method of claim 14, wherein receiving an SQL query comprises: receiving an invocation of a service comprising an embedded SQL command.

18. The method of claim 14, wherein the at least one of a plurality of services comprises an XQuery interface; and wherein preparing a virtual SQL table comprising data selected from the result set responsive to the SQL query enables an SQL application making the SQL query to interface with the at least one of a plurality of services to obtain information using SQL format.

19. The method of claim 14, wherein accessing the at least one service on behalf of the requestor comprises: preparing a request to access at least one of a plurality of services based upon the SQL query.

20. The method of claim 19, wherein preparing a request to access at least one of a plurality of services based upon the SQL query comprises: mapping the SQL query to an XQuery request for accessing at least one of a plurality of services.

21. The method of claim 20, wherein mapping the SQL query to an XQuery request for accessing at least one of a plurality of services comprises: determining whether syntax of the SQL query and preparing the XQuery request if the syntax of the SQL query is correct.

22. The method of claim 20, further comprising: determining to refrain from preparing the XQuery request if the syntax of the SQL query is not correct.

23. A computer-readable medium carrying one or more sequences of instructions for accessing a service, which instructions, when executed by one or more processors, cause the one or more processors to carry out the steps recited by claims 1 - 22.

24. A proxy server, comprising: a processor; and one or more stored sequences of instructions which, when executed by the processor, cause the processor to carry out the steps of: receiving, from a requestor, a request to access at least one service and a criteria indicating a form that the requestor prefers a result to have; accessing the at least one service on behalf of the requestor; receiving at least one result set from the at least one service responsive to the accessing; and providing, to the requestor, a result set comprised of selected portions of the at least one result set formatted in the form that the requestor prefers, wherein the selected portions of the result set provided to the requestor are mapped to a view associated with the requestor.