|
|
| (10 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| − | {{ScoutPage|cat=Concepts}}
| + | The Scout documentation has been moved to https://eclipsescout.github.io/. |
| − | 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.
| + | |
| − | | + | |
| − | = Server Side Equinox =
| + | |
| − | | + | |
| − | {{note|TODO|Describe ServerApplication as Startup Point, Jetty as http server, server product}}
| + | |
| − | | + | |
| − | = Transaction Handling =
| + | |
| − | Basically every request to the server is one transaction. This transaction is created by the servlet which receives the request. 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.
| + | |
| − | | + | |
| − | = Accessing data =
| + | |
| − | | + | |
| − | * {{ScoutLink|Concepts|Outline_Service|Data/Outline Services}}
| + | |
| − | * {{ScoutLink|Concepts|Lookup_Service|Lookup Services}}
| + | |
| − | * Enumeration/Code Services
| + | |
| − | * {{ScoutLink|Concepts|Process_Service|Processing Services}}
| + | |
| − | * Workflow services
| + | |
| − | | + | |
| − | == Webservice support ==
| + | |
| − | {{note|TODO|Describe jax-ws support}}
| + | |
| − | | + | |
| − | == Database / SQL support ==
| + | |
| − | {{note|TODO|Add description}}
| + | |
| − | * {{ScoutLink|Concepts|Sql Service|Sql Service}}
| + | |
| − | * {{ScoutLink|Concepts|SqlStyle|Sql Style}}
| + | |
| − | | + | |
| − | == Statement Builder ==
| + | |
| − | | + | |
| − | See {{ScoutLink|Concepts|StatementBuilder|FormDataStatementBuilder}}.
| + | |
| − | | + | |
| − | = Configuration =
| + | |
| − | | + | |
| − | == config.ini ==
| + | |
| − | | + | |
| − | Inside of the config.ini in the server it is possible to override the member variables of services.
| + | |
| − | | + | |
| − | For example:
| + | |
| − | | + | |
| − | com.bsiag.mnet.server.services.common.sql.SqlService#directJ dbcConnection=true
| + | |
| − | | + | |
| − | <br> 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. <br> In the web you find several sites that tell you to start Java with the following options:
| + | |
| − | | + | |
| − | {{code|
| + | |
| − | -Dhttp.proxyHost=proxyHost<br>
| + | |
| − | -Dhttp.proxyPort=proxyPort <br>
| + | |
| − | -Dhttp.proxyUser=proxyUser <br>
| + | |
| − | -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) <br> 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 config.ini-file). <br> Your code could look similar to the following code snippet:
| + | |
| − | | + | |
| − | {{code|
| + | |
| − | URL url = new URL(myUrl); <br>
| + | |
| − | URLConnection conn; <br>
| + | |
| − | Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(myProxyHost, myProxyPort)); <br>
| + | |
| − | conn = url.openConnection(proxy); <br>
| + | |
| − | String encoded = Base64Utility.encode((myProxyUsername + ":" + myProxyPassword).getBytes()); <br>
| + | |
| − | conn.setRequestProperty("Proxy-Authorization", "Basic " + encoded);
| + | |
| − | }}
| + | |
| − | | + | |
| − | However, with this solution you need to set the proxy parameters for each request anew.
| + | |
| − | | + | |
| − | = See also =
| + | |
| − | | + | |
| − | * {{ScoutLink|Concepts|Client Plug-In|Client Plug-In}}
| + | |
| − | * {{ScoutLink|Concepts|Shared Plug-In|Shared Plug-In}}
| + | |
