Configurations with local and remote applications types
With SMA and LLA, the applications always connect to a local solidDB® server (SMA server or LLA server); the application and solidDB® server are located on the same node. In addition to handling requests from the local SMA or LLA application, the SMA or LLA server can also handle requests from remote applications, which connect to the server through communications protocols such as TCP/IP. A dual-mode application can also be written; it switches modes between local and remote, depending upon how it is compiled and linked.
The SMA or LLA application is a local application; the server and the application are located on the same node. For example, calls to ODBC functions go directly to the server, rather than going through an ODBC driver and the communications protocol (such as TCP/IP).
A remote application is not linked to the SMA driver or LLA library. It is a separate executable that must communicate with the server using a network connection (such as TCP/IP) or other connection. Remote applications are usually run on a different node from the one that is running the server, but the application is also considered remote if it uses a network communication protocol to communicate with the server. A single node can run a local SMA or LLA application, while running one or more remote applications as separate processes.
The remote applications see the SMA and LLA server as similar to any other solidDB® server, while the local application sees a faster, more precisely controllable version of the solidDB® server.
Most applications are either local (linked to the SMA driver or LLA library) or remote (never linked). However, it is also possible to write a dual-mode application that uses both local and network-based connections. For example, the application can use the same C-language application code in either local or remote mode. The application is linked to a different library when in local mode than when in remote mode.
Dual-mode applications may be useful for example in the following cases:
▪You want to test your local application first before linking it with the SMA or LLA library.
▪You want all users/processes to have the same application logic whether they are local or remote.
The remote applications may be a mix of C and Java programs. The language in which the local client is written does not restrict which languages the remote clients can be written in. For example, if you use LLA with Java, the remote client programs may use C, Java, or both.
SSC API and SA API libraries for remote applications
Remote applications that contain SSC API or SA API function calls must link to separate libraries.
Platform
SSC API stub library
SA API library
Default location
Windows
solidctrlstub.lib
solidimpsa.lib
<solidDB® installation directory>\lib
Other platforms
solidctrlstub.a
solidsa.a
<solidDB® installation directory>/bin
The SSC API stub library is required for remote applications because the SSC API functions included in the SMA and LLA libraries cannot be used with remote applications. For example, assume that you have a local application (containing SSC API functions) that links to a standard ODBC library. You want to run the same application remotely. By linking to the SSC API stub library, you avoid having to remove the SSC API function calls from your code. In this way, you can easily turn your LLA or SMA application into a normal remote client application.
Note The SSC API stub library contains “do-nothing” functions; if you call them in a remote application, they have no effect on the server. The SSC API stub library does not actually give your remote application control of the server. Instead, it allows you to compile and link your application as a remote application, without getting link-time errors from solidDB® with LLA or SMA.