|Download • Git|
|Forums • Blog • Twitter • G+|
The server part of a Scout application (backend) is responsible for processing business objects. In order to do this Scout provides an infrastructure for accessing data and expose it to the client in a simple way. All this is done in a transactional and secure environment which is yet transparent and easy to use.
To increase the simplicity even more osgi is not only used on client side but on server side as well. This gives the possibility to use the same techniques and tools like extension points, osgi services, pde build etc. as on client side.
Providing data for the client
In order to deliver data to the client the server provides several services.
Services are managed by the service registry. There is a variety of service types:
- Data Services
- Lookup Services
- Enumeration/Code Services
- Process Services
- Workflow services
- Outline Services
- Remote File Services
A data service is normally a server service providing read-only data with aggregation and composition logic. Data services offer search and filter capabilities. From the client (frontend) such services are called using service remoting over HTTP(S).
A Lookup Service is normally a server service providing read-only lookup data for dynamic list-of-values such as “Companies”, “Persons”, etc. Lookup Services offer filter and search capabilities and specific data access “by key”, “by display text”, and “by parent key” (for hierarchical lookup data). From the client these services are called using a lookup service call representing the call data.
An enumeration service is normally a server service providing read-only enumeration data for static list-of-values such as “Project State”, “Address Type”, etc. Note that the word “static” does not mean that the data is fixed and constant, but that the character of the data is rather static. Like Lookup services also code services offer filter and search capabilities. From the client these services are called using a code service call representing the call data.
A Process Services is normally a server service providing data manipulation or control operations such as “Company.create”, “Company.modify” etc. From the client these services are called using service remoting over HTTP(S). Most processing services managed by Scout SDK are the backend of UI form models. In order to maximally assist developers, Scout SDK can automatically create a value structure (FormData) for every UI form that is created and also generate a load/store/create processing service for it.
A workflow service is normally a server service providing state machine and workflow control operations such as “AddressChange.start”, “AddressChange.nextStep” etc. From the client these services are called using service remoting over HTTP(S). Most workflow services managed by Scout SDK are the backend of UI wizard models. In order to maximally assist developers, Scout SDK automatically creates a value structure for every UI wizard that is created and also generates a workflow service for it.
A remote file service is used to upload files from the server to the client. See Use RemoteFileService
Accessing persistent data
- Data/Outline Services
- Lookup Services
- Enumeration/Code Services
- Processing Services
- Workflow services
Database / SQL support
Webservice (JAX-WS) support
Since version 3.8 scout provides support for webservices based on JAX-WS. This support lets you easily consume and publish webservices from within Scout applications. It also helps you with transaction handling, logging, authentication, authorization and more. See the following links to learn more about it.
Server Side Equinox
Basically every request to the server is one transaction. This transaction is created by the servlet which receives the request (ServiceTunnelServlet). If the processing was successful (which means the service did not throw an exception) the transaction will be committed when the response is sent to the client.
The servlet which is responsible for that is called ServiceTunnelServlet and registered at /process. The transaction runs under the user's (JAAS) Subject with a ITransaction in the thread context. ThreadContext.get(ITransaction) delivers the "current" transaction. The wrapper of the transaction is always a scout ServerJob. Every resource taking part in the transaction (similar to xa) can register a ITransactionMember to the transaction. Once the transaction is closed it is either committed (2-phase) or rolled back based on the property ITransaction.getFailures() that must be null for a commit.
Inside of the
config.ini in the server it is possible to override the member variables of services.
If the service SqlService has a setter method for the member directJdbcConnection then the member has at runtime the value true.
With Eclipse Scout this works for all classes which extends AbstractService
For other classes it must be done by yourself for example with the class FilterConfigInjection at startup.
Server Side Proxy
If the server application needs to access a server in the web and in between your application server and the server in the web is a proxy that needs authentication, you need to set the proxy parameters (like username or password) somewhere.
In the web you find several sites that tell you to start Java with the following options:
-Dhttp.proxyHost=proxyHost -Dhttp.proxyPort=proxyPort -Dhttp.proxyUser=proxyUser -Dhttp.proxyPassword=proxyPassword
(You can set these options in the Tomcat by right-clicking on the Tomcat tray icon, then click on 'Configure...', go to the Java tab & add the four lines to the Java options)
When the request is sent, the proxy host and the proxy port are known & the request is sent over the proxy. However the authentication does not work. Even though these options are loaded when Java / the Tomcat is started.
Either Java does not care about the options for the username and the password or the proxy we use does the authentication not as expected / usual.
If you have problems with the upper solution, you can solve the problem by setting the proxy informations in Java before you send the request (read the proxy informations from the
Your code could look similar to the following code snippet:
URL url = new URL(myUrl); URLConnection conn; Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(myProxyHost, myProxyPort)); conn = url.openConnection(proxy); String encoded = Base64Utility.encode((myProxyUsername + ":" + myProxyPassword).getBytes()); conn.setRequestProperty("Proxy-Authorization", "Basic " + encoded);
However, with this solution you need to set the proxy parameters for each request anew.