Jump to: navigation, search

Difference between revisions of "Scout/Concepts"

m
(Big Picture - Main Architecture of Scout)
Line 7: Line 7:
 
[[Image:Scout_main_architecture.png|thumb|right|200px|Scout Main Architecture]]  
 
[[Image:Scout_main_architecture.png|thumb|right|200px|Scout Main Architecture]]  
  
Scout is told to be a framework for creating modern business applications. Such applications are typically seperated into multiple tiers where each tier is responsible for a specific part of the application like presenting information to the user or processing business logic and persisting data.
+
Scout is told to be a framework for creating modern business applications. Such applications are typically separated into multiple tiers where each tier is responsible for a specific part of the application like presenting information to the user or processing business logic and persisting data.
  
Scout comes up with these requirements by providing a seperation of such tiers out of the box. The two main tiers of Scout are the client part and the server part.
+
Scout comes up with these requirements by providing a separation of such tiers out of the box. The two main tiers of Scout are the client part and the server part.
  
Scout is also told to be a framework which is simple to use but yet flexible. This is achieved, amongst other things, by using a stable platform as the basement namely Eclipse / Equinox. By using this basement on client and server side it is possible to use the same technologies and tools for creating the server and the client part. Even though these tiers are seperated there is no need to use different Eclipse workspaces or even different developers for each tier. One developer is able to create a multi tier application in one Eclipse workspace and still has a strict seperation of client and server thanks to OSGI/Equinox.
+
Scout is also told to be a framework which is simple to use but yet flexible. This is achieved, amongst other things, by using a stable platform as the basement namely Eclipse / Equinox. By using this basement on client and server side it is possible to use the same technologies and tools for creating the server and the client part. Even though these tiers are separated there is no need to use different Eclipse workspaces or even different developers for each tier. One developer is able to create a multi tier application in one Eclipse workspace and still has a strict separation of client and server thanks to OSGI/Equinox.
  
Another thing which makes it so simple is the communication between these tiers. There is no need to explicitly define webservicse and exchange wsdls in the same application only to show some information on a dialog (not meaning it is not possible to do so, it is!). Instead osgi services are used where only an interface is sufficent. That interface for a service including the data transfer objects (dto) is known on client and server side which is enabled by having another tier, the shared part. With that mechanism it is possible to provide a service tunnel which actually is one webservice tunneling every osgi service call from client to server.
+
Another thing which makes it so simple is the communication between these tiers. There is no need to explicitly define webservice and exchange WSDLs in the same application only to show some information on a dialog (not meaning it is not possible to do so, it actually is!). Instead OSGi services are used where only an interface is sufficient. That interface for a service including the data transfer objects (DTO) is known on client and server side which is enabled by having them in the shared part. With that mechanism it is possible to provide a service tunnel which actually is one webservice tunneling every OSGi service call from client to server.
  
 
=== Plugin-Set ===
 
=== Plugin-Set ===
Line 23: Line 23:
 
* Server Plug-In (eg <code>your.application.server</code>)
 
* Server Plug-In (eg <code>your.application.server</code>)
  
Since the Scout runtime relies on a strict seperation of business code and presentation code additional plugins are provided where gui specific code is placed. Depending on the gui implementation these plugins can be one of the following:
+
Since the Scout runtime relies on a strict separation of business code and presentation code additional plugins are provided where GUI specific code is placed. Depending on the GUI implementation these plugins can be one of the following:
 
* SWT UI Plug-In for native desktop applications (eg <code>your.application.ui.swt</code>)
 
* SWT UI Plug-In for native desktop applications (eg <code>your.application.ui.swt</code>)
 
* Swing UI Plug-In for individual desktop applications (eg <code>your.application.ui.swing</code>)
 
* Swing UI Plug-In for individual desktop applications (eg <code>your.application.ui.swing</code>)

Revision as of 07:16, 2 November 2011


Scout
Wiki Home
Website
DownloadGit
Community
ForumsBlogTwitter
Bugzilla
Bugzilla


The Concepts pages define concepts and elements used in the Eclipse Scout Framework.

Big Picture - Main Architecture of Scout

Scout Main Architecture

Scout is told to be a framework for creating modern business applications. Such applications are typically separated into multiple tiers where each tier is responsible for a specific part of the application like presenting information to the user or processing business logic and persisting data.

Scout comes up with these requirements by providing a separation of such tiers out of the box. The two main tiers of Scout are the client part and the server part.

Scout is also told to be a framework which is simple to use but yet flexible. This is achieved, amongst other things, by using a stable platform as the basement namely Eclipse / Equinox. By using this basement on client and server side it is possible to use the same technologies and tools for creating the server and the client part. Even though these tiers are separated there is no need to use different Eclipse workspaces or even different developers for each tier. One developer is able to create a multi tier application in one Eclipse workspace and still has a strict separation of client and server thanks to OSGI/Equinox.

Another thing which makes it so simple is the communication between these tiers. There is no need to explicitly define webservice and exchange WSDLs in the same application only to show some information on a dialog (not meaning it is not possible to do so, it actually is!). Instead OSGi services are used where only an interface is sufficient. That interface for a service including the data transfer objects (DTO) is known on client and server side which is enabled by having them in the shared part. With that mechanism it is possible to provide a service tunnel which actually is one webservice tunneling every OSGi service call from client to server.

Plugin-Set

Plugin-Set of a Scout Application

A Scout project is composed of different Eclipse plug-ins (each plug-in is an Eclipse Project).

  • Client Plug-In (eg your.application.client)
  • Shared Plug-In (eg your.application.shared)
  • Server Plug-In (eg your.application.server)

Since the Scout runtime relies on a strict separation of business code and presentation code additional plugins are provided where GUI specific code is placed. Depending on the GUI implementation these plugins can be one of the following:

  • SWT UI Plug-In for native desktop applications (eg your.application.ui.swt)
  • Swing UI Plug-In for individual desktop applications (eg your.application.ui.swing)
  • Rap UI Plugin for web (2.0) applications (eg your.application.ui.rap)

Overview of the concept pages

See also