| Eclipse Scout Architecture: Why is there a Web Server / Web Container? [message #808302] |
Mon, 27 February 2012 16:22  |
 Kai Wähner
Messages: 4
Registered: February 2012 |
Junior Member |
|
|
After looking at the architecture of Eclipse Scout several times and doing some hello world stuff, I wonder why there is a web server / web container?
To get a better understanding, can you please explain:
1) Is it a web container or a web server? The examples use a Tomcat Web Container (JEE Servlet Container) - which can also be used as Web Server. The architecture graphics show a Web Server, therefore a "simple" Apache Web Server would be sufficient? Or do you need a Servlet Container?
2) Eclipse RCP can be used without a Web Container, nevertheless you can communicate between a Client and a Server using several protocols, right?
The "Service Tunnel" of Eclipse Scout just uses plain HTTP to transport XML (SOAP) messages. There is no Servlet or JAX-WS usage for this communication?
Therefore, there is no need to deploy on a Web Server / Web Container for just using Eclipse Scout client and server, right?
3) Is a Web Server / Web Container used respectively required for RAP?
4) Is a Web Server / Web Container used respectively required for distributing the Scout client, i.e. the user can download it from the web browser link?
5) Is only question 3 and / or 4 the reason for using a Web Server / Web Container? Or are there other reasons? If not: Could I use Eclispe Scout without Web Server / Web Container if I do not want to use RAP or online distribution of the client?
Thank you in advance for some explanations.
Best regards,
Kai
[Updated on: Mon, 27 February 2012 16:35] Report message to a moderator |
|
|
| Re: Eclipse Scout Architecture: Why is there a Web Server / Web Container? [message #808514 is a reply to message #808302] |
Mon, 27 February 2012 21:44  |
Eclipse User |
|
|
|
Answers 1-4 are valid with Scout client server and server only applications. For client only applications there is of course no web container required (see answer 5).
1) Servlet Container vs. HTTP Container
Short answer: Server side a (thin) servlet container or an OSGi supporting web container (Jetty) is required.
Scout applications make large usage of SOA patterns. So a common service infrastructure server and client side is a huge advantage. To get there, having a common programming pattern and use all benefits of OSGi - Scout client and server parts lives both in an OSGi container. The server side bridging between servlet container and Equinox is standard usage of Server Side Equinox (http://www.eclipse.org/equinox/server/).
2) Client Server communication
Short answer: Yes the communication is exchangeable. There is a servlet used for client server communication.
Scout server comes with a generic service dispatching servlet (org.eclipse.scout.rt.server.ServiceTunnelServlet). The registration of this servlet is in the (ch.abc.myapplication.server/plugin.xml) as an extension point (/process) and could be replaced by any other technique. All remote service requests getting dispatched by that single servlet. The advantage here is to have exactly one communication channel from client to server, one point of authentication/authorization, one channel to reverse proxy and to enable in entry servers. The requests are either full SOAP (XML) requests or an optimized SOAP (XML) envelop with serialized zipped Java objects as content for better performance. Every single Scout service can be provided as JAX WS for external usage. With any implementation of org.eclipse.scout.rt.client.servicetunnel.IServiceTunnel the client-server communication can be fully exchanged (see: ClientSession.execLoad).
3) Scout and RAP
Same same. The RAP server part is nothing else than an OSGi container and requires a servlet container or an OSGi supporting web container.
4) Web container for Client download location
As a download container for Scout clients any HTTP container/FTP access is fair enough. The packed (exported) client application is typically a zip archive. Usually we provide the client download in the same WAR file as the server itself. The resource servlet (org.eclipse.scout.rt.server.RemoteFileServlet) helps for this kind of requirements.
5) Client only application
Yes you can... use Scout as a framework to build client only applications. In the current versions (Scout 3.7) there is some finger work to do to disable any attempt to access a server.
How to get there:
- Create a new scout project and uncheck the server node
Open Desktop.java and remove the BookmarkMenu:
@Order(25)
public class BookmarkMenu extends AbstractBookmarkMenu{
public BookmarkMenu(){
super(Desktop.this);
}
}
- Open ClientSession and remove the two lines:
setServiceTunnel(new HttpServiceTunnel(this,getBundle().getBundleContext().getProperty("server.url")));
CODES.getAllCodeTypes(org.eclipse.test.shared.Activator.PLUGIN_ID);
Thank you for this good question set.
-andreas
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03681 seconds
] 
Search
Help
Register
Login
Home
