SmartGWT DataSources

SmartGWT supports two general classes of client-server operations

A visual component which has been bound to a DataSource will originate DataSource Operations, either automatically in response to user actions, or manually in response to calls to the DataBound component methods. Data Integration is the process of satisfying those requests by adapting SmartGWT to your existing servers or to third-party services you wish to consume.

You can integrate with any DataSource operation in either of two places:

The following diagram shows the available server-side and client-side data integration paths in more detail:

Data Integration Paths

These paths roughly correspond to the following types or levels of application development:

Development Type Paths
Rapid Prototyping (SmartGWT EE) 1a
Java Server Integration (SmartGWT EE) 1b, 1c
SOA (Service Oriented Architecture) Integration (SmartGWT LGPL) 2, 3, 4

For a large application, you may choose to follow different integration paths at different stages of development. For example, you could start prototyping an application immediately with the Relational DataSource connector (1a), move to custom DataSource connectors (1b) or DMI (1c) as your business logic is finalized, and move to XML (3) or SOAP (4) integration when your business logic provides stable service interfaces.

You may also use any or all of these paths in parallel within the same application. For example, you could use Java server integration (1b, 1c) for your internal business logic, JSON service integration (2) to integrate an external search engine like Yahoo!, and WSDL/SOAP integration (4) to integrate hosted enterprise services like salesforce.com.

SmartGWT provides this range of integration options so you can choose the best approach for the job at hand. These approaches are discussed in more detail in the following sections.

Rapid Prototyping (path 1a)

You can use pre-fabricated DataSource connectors to bind directly to a SQL data store. This is the fastest way to get started with SmartGWT development. You can implement many common interactions and many complete, simple applications without writing any server-side logic. Note that this path requires the SmartGWT EE.

You can user HSQL, or external DB2, Oracle, SQL Server, MySQL, and PostgreSQL databases. The Java Data Integration -> CRUD -> Relational Connector illustrates an example of this.

You can also have SmartGWT EE map your datasource to transparently create a Hibernate mapping, the corresponding table, and populate it with sample data. Using this path the DataSource operations go via Hibernate without the user writing any server-side logic. The Java Data Integration -> CRUD -> Hibernate (Prototype) illustrates an example of this.

The SmartGWT EE Admin Console provides a browser-based GUI to configure these database connections, generate database tables from your DataSource descriptors, and populate those tables with test data.

Java Server Integration (paths 1b, 1c)

In this approach, DataSource requests issued by DataBound components arrive on the server as Java Objects. You deliver responses to the browser by returning Java Objects. Note that this path requires the SmartGWT EE.

There are two approaches for routing inbound requests to your business logic:

Which approach you use is largely a matter of preference. Direct Method Invocation (DMI) may allow simple integration without writing any SmartGWT-specific server code. RPCManager dispatch integration provides an earlier point of control, allowing logic that applies across different DataSource operations to be shared more easily.

Service-Oriented Architecture (paths 2, 3, 4)

SmartGWT supports declarative, XPath-based binding of visual components to web services that return XML or JSON responses. This is supported by SmartGWT LGPL.

To display XML or JSON data in a visual component such as a ListGrid, you bind the component to a DataSource which provides the URL of the service, as well as a declaration of how to form inputs to the service and how to interpret service responses as DataSource records.

An XPath expression, the recordXPath, is applied to the service's response to select the XML elements or JSON objects that should be interpreted as DataSource records. Then, for each field of the DataSource, an optional valueXPath can be declared which selects the value for the field from within each of the XML elements or JSON objects selected by the recordXPath. If no valueXPath is specified, the field name itself is taken as an XPath, which will select the same-named subelement or property from the record element or object.

WSDL Integration

SmartGWT supports automated integration with WSDL-described web services. This support augments capabilities for integrating with generic XML services, and consists of:

WSDL services can be contacted by using XMLTools.loadWSDL() to load the service definition, then invoking methods on the resulting WebService object. WebService.callOperation() can be used to manually invoke operations for custom processing. The Webservices (WSDL) and RSS -> WSDL operation illustrates an example of this.

To bind a component to a web service operation, call WebService.getFetchDS(operationName,elementName) to obtain a DataSource which describes the structure of an XML element or XML Schema type named elementName, which appears in the response message for the operation named operationName. The Webservices (WSDL) and RSS -> WSDL databinding (Google Search) illustrates an example of this.

Generic RPC operations (advanced)

Generic RPCs allow you to make arbitrary service calls and content requests against any type of server, but they also require you to implement your own request/response processing and GUI integration logic.

Generic RPC

As with DataSource operations, RPC operations sent to the SmartGWT EE Java Server can use two methods to route requests to appropriate server-side code: Direct Method Invocation (DMI) or RPCManager dispatch.