Scout/Concepts/Server Plug-In

From Eclipsepedia

Jump to: navigation, search


Scout
Wiki Home
Website
DownloadGit
Community
ForumsBlogTwitter
Bugzilla
Bugzilla

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.

Contents

Providing data for the client

In order to deliver data to the client the server provides several services.

Scout Services

Service Types

Services are managed by the service registry. There is a variety of service types:

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 acces “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 assists developers, Scout SDK automatically creates a value structure for every UI wizard that is created and also generates a workflow service for it.

An Outline Service is used to fill the content of the different Outlines (mainly for the TablePages).

A remote file service is used to upload files from the server to the client. See Use RemoteFileService

Accessing persistent data

Database / SQL support

Note.png
TODO
Add description

Statement Builder

See FormDataStatementBuilder.

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

Note.png
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.

Configuration

config.ini

Inside of the config.ini in the server it is possible to override the member variables of services.

For example:

 <your application>.server.services.common.sql.SqlService#directJ dbcConnection=true 

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 config.ini-file).

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.

See also