Skip to main content
Jump to: navigation, search

Difference between revisions of "Scout/Concepts/Server Plug-In"

(Description)
Line 1: Line 1:
 
{{ScoutPage|cat=Concepts}}
 
{{ScoutPage|cat=Concepts}}
 +
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 =
  
== Description ==
 
 
The server Plug-in provides Services for the client.
 
 
* {{ScoutLink|Concepts|Outline_Service|Data/Outline Services}}  
 
* {{ScoutLink|Concepts|Outline_Service|Data/Outline Services}}  
 
* {{ScoutLink|Concepts|Lookup_Service|Lookup Services}}  
 
* {{ScoutLink|Concepts|Lookup_Service|Lookup Services}}  
Line 10: Line 21:
 
* Workflow services
 
* Workflow services
  
=== Using a database ===
+
== Webservice support ==
{{note|TODO|Add description: using a database}}
+
{{note|TODO|Describe jax-ws support}}
 +
 
 +
== Database / SQL support ==
 +
{{note|TODO|Add description}}
 
* {{ScoutLink|Concepts|Sql Service|Sql Service}}
 
* {{ScoutLink|Concepts|Sql Service|Sql Service}}
 
* {{ScoutLink|Concepts|SqlStyle|Sql Style}}
 
* {{ScoutLink|Concepts|SqlStyle|Sql Style}}
  
== See also ==
+
== 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&#61;proxyHost<br>
 +
-Dhttp.proxyPort&#61;proxyPort <br>
 +
-Dhttp.proxyUser&#61;proxyUser <br>
 +
-Dhttp.proxyPassword&#61;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 &amp; add the four lines to the Java options) <br> When the request is sent, the proxy host and the proxy port are known &amp; 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 &#61; new URL(myUrl); <br>
 +
URLConnection conn; <br>
 +
Proxy proxy &#61; new Proxy(Proxy.Type.HTTP, new InetSocketAddress(myProxyHost, myProxyPort)); <br>
 +
conn &#61; url.openConnection(proxy); <br>
 +
String encoded &#61; 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|Client Plug-In|Client Plug-In}}
 
* {{ScoutLink|Concepts|Shared Plug-In|Shared Plug-In}}
 
* {{ScoutLink|Concepts|Shared Plug-In|Shared Plug-In}}

Revision as of 17:52, 31 October 2011


Scout
Wiki Home
Website
DownloadGit
Community
ForumsBlogTwitterG+
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.

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.

Accessing data

Webservice support

Note.png
TODO
Describe jax-ws support


Database / SQL support

Note.png
TODO
Add description

Statement Builder

See 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


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

Back to the top