public interface ServerDataIntegration
install the       Smart GWT Java Server Framework into any J2SE/J2EE     
 environment, including any existing web application create DataSources via an XML declaration,
 possibly on-the-fly from existing metadata.   Client-side Data Integration in which
 client-side DataSources are configured to send and receive HTTP messages containing XML, JSON
 or other content. Server-side Request Processing
 Client-side DataBoundComponents will send DSRequests to the Smart GWT Server as background
 communications transparent to the user.  Integrating Smart GWT's DataSource layer with your
 data model is a matter of handling these DSRequests and sending back DSResponses, in order to
 fulfill the 4 basic operations of the DataSource Protocol. 
 Out of the box, Smart GWT is set up to route all DSRequests through a
 special servlet called IDACall. 
Note that the Smart GWT SDK includes detailed Javadoc reference for this servlet and all shipped Smart GWT Java server classes.
 Requests
 that go through IDACall have the  following lifecycle: 
RPCManager to manage the processing of the entire queue of transactions.  For
 every DSRequest in the queue, this RPCManager:server scripting or DMI - in other words, your code -       and passes the
 request to this logic.       As described later in this section, your code can perform some custom logic here: either completely fulfilling the request, or alternatively modifying the request and causing the default processing of the request to continue
execute method to obtain a
 DSResponse.This basic request handling flow can be customized at a number of points:
IDACall servletDataSource.serverType specification
 within your .ds.xml configuration     file is used to specify a standard
 server-side connector to service your requests.OperationBinding        allow you to modify the dataSource request
 dynamically at transaction-processing time, using        built-in Velocity support.Transaction
 Chaining to dynamically set data values        according to the results of earlier
 transactions.DataSourceField.validators defined in
 the .ds.xml        file will be processed on both the client and the server. In
 addition to the built-in validator       types, entirely custom server validation logic may be
 implemented using       "serverCustom" type
 validators.SQL Templating to change, add        to or even completely replace the SQL sent to the
 database, including calling       stored proceduresDataSource.serverConstructor
 allows you to specify an explicit custom DataSource       subclass to create as your DataSource
 instance. This must be a subclass of        BasicDataSource.IDACall servlet, they will be passed to
 standard methods on this DataSource, which       can be overridden for custom behavior.validate() method.execute(), method which can be overridden directly,       or
 developers may override the operation-specific        methods executeFetch(),
 executeAdd(), executeUpdate,       or executeRemove()
 called from the standard execute() implementation.SQLDataSource, or       create an entirely custom implementation
 from scratch.custom server
 dataSource overviewDirect Method
 Invocation to call directly into your own Java        classes. An operation configured to use
 DMI will invoke the specified method instead of       running through the standard DataSource
 execute() method directly - the DMI       implementation can then use
 dsRequest.execute() to call the default behavior.       This means DMIs allow you
 to modify the DSRequest before it executes,       modify the
 DSResponse before it returns, or replace the default behavior with       unrelated
 actions. Note that DMI can be applied        to all operations, or to        individual operation bindings,
 and can be used       in conjunction with a custom dataSource.server scripting to add small amounts of business logic 
 right in your .ds.xml file (either        per operation, or as standard
 handling for       all operations).
 DMI scripts allow you to add business       logic just like normal DMIs, but don't require the
 logic to be in a separate .java       file.RPCManager.processRequest() within your Spring Controller or 
 whatever the equivalent is in the framework in use.  However, note carefully that taking
 this approach is often a sign that the Smart GWT  architecture has not been correctly
 understood.  Smart GWT is architected for  client-server data communication, as
 opposed to early web MVC frameworks which  do everything on the server.  In particular, it is
 absolutely incorrect to represent every  individual DataSource operation - or even every
 DataSource - as a separate  Spring Controller because this implies different URLs for different
 operations.  All  DataSource operations should go through a single URL in order to allow 
 transaction queuing - see these  @see Queuing examples.
 For more information on the DMI
 subsystem, see the DMI overview,  DMI class and
 the  DMI
 example in the Feature Explorer. 
 Note that, as you continue to integrate your prototype
 with your backend, you can use a mixture of DataSources that have been fully integrated with
 your backend and DataSources that are running in "client-only" mode (see ClientOnlyDataSources). 
Important methods for handling DataSource requests
The basic flow of logic for handling DataSource requests is:
| 1. Determine operation type (Fetch, Add,
 Update, Remove) for a single request.  Not  necessary if you follow the recommendations for writing a custom DataSourceand provide
 your  implementation viaexecuteFetch(), executeAdd(), et al. | dsRequest.getOperationType() | 
| 2. Get inbound values (Add, Update) and/or criteria (Fetch, Update, Remove) for this request. | dsRequest.getFieldValue() dsRequest.getValues() dsRequest.getCriteria() | 
| 3. Business logic, validation, calls to data and service tiers... anything you can code. | execute custom logic | 
| 4. Set status and data for the response. | dsResponse.setStatus() dsResponse.setData() | 
 For more
 information, see the RPCManager documentation, and
 the  Custom
 ORM DataSource example.
DSDataFormat, 
DSServerType, 
DataSource.getDataFormat(), 
DataSource.getDataProtocol(), 
DataSource.getRequestProperties(), 
DataSource.serverType, 
DataSource.tableName, 
DataSource.quoteTableName, 
DataSource.dbName, 
DataSource.configBean, 
DataSource.forceSort, 
OperationBinding.forceSort, 
DataSource.defaultSortField, 
DataSource.getDefaultTextMatchStyle(), 
DataSource.defaultBooleanStorageStrategy, 
DataSource.useAnsiJoins, 
DataSource.audit, 
com.smartgwt.client.data.DataSource#getServerObject, 
OperationBinding.getRequestProperties(), 
RestDataSource.getDataProtocol()