Difference between revisions of "Scout/Overview"
|Line 1:||Line 1:|
Revision as of 05:06, 8 July 2010
|Download • Git|
|Forums • Blog • Twitter • G+|
The goal of the Eclipse Scout project is making it easy to build distributed enterprise applications based on the Eclipse platform. It consists of a runtime framework providing transparent service communication between the client and backend part and is shipped with a rich set of common user interface components. The user interface is not built for a particular rendering technology but it encapsulates the core functionality into a headless model. GUI factories are available for rendering the client model into a particular target UI platform. SWT and Swing are supported out of the box and an AJAX GUI factory could be easily added.
Developing Scout applications is supported by the Scout SDK, a plug-in set built on top of Eclipse PDE and Eclipse JDT. The Scout SDK works directly on the bare Java resources and assists the development task by providing an augmented view to the underlying Java code. Additionally it comes with a rich set of wizards and operations for modifying the Scout application project just by editing the underlying Java code. There is no meta-data required. Hence a developer can switch between editing resources using Eclipse’s standard editors and leveraging the features of Scout SDK at any point in time.
Eclipse Scout can be used for creating multi-tier client/server applications, standalone client applications or OSGi-based server applications. Basically, there are three main advantages when choosing Scout as framework for building such applications. First, the Scout runtime is service oriented by design. Almost every functionality is provides as OSGi service. Every OSGi bundle may make use of them. Second, Scout provides a rich set of UI elements being uncoupled from a particular GUI technology. And third, building distributed client/server applications is as easy as if both parts would run within the same local JVM.
Functionality in Scout application is provided as a service. A service is either a plain OSGi service registered by an arbitrary bundle or it is contributed using Scout’s service extension point. In fact, the extension point just enables declarative service contribution and provides flexible means to configure services contributed this way. For instance, it provides a ranking attribute mapping to the OSGi service ranking and it allows specifying a factory class that actually instantiates the service.
Scout simplifies to access services. It provides a convenience accessor class SERVICES that wraps the service lookup operation in the OSGi bundle context. Scout services are typically lazy initialized when loaded the first time.
Scout comes with a set of base services. Examples are access control, SMTP, JMS and SQL. Services contributed in a Scout application typically make use of these base services. Enterprise patterns can be easily implemented using service orchestration. Other patterns required to separate parts of an application to make them exchangeable are just not required because everything is a service. Together with appropriate plug-in structures and different Eclipse product configurations it is easy to meet different requirements for different environments and it just feels natural.
A Scout client application is made up by a main form, called desktop. It consists of the base components like menus, outline tree, outline table, search forms, CTI control, view buttons, and so on. The outline tree and the outline table along with the search form are related to each other. Selecting an entry in the outline shows its details in the outline table part.
Navigating through data is done by drilling-down the outline tree. Different aspects of an object are organized into different tree nodes, called pages. There are two base implementations for a page, one with a table and another with nodes. The former is used to list data of a particular type and the latter groups different types of data belonging to a common root object.
Finally, forms are used to show and edit details of a particular object. Forms may be rendered as dialogs, views or editors (depending on the GUI factory and configuration parameters).
All these elements are created and modified with the Scout SDK and are stored as plain Java resources. Hence they can be modified manually at any point in time. But most time it is much more comfortable to make use of Scout SDK.
Distributed Scout Applications
Page and form content is typically provided by services. These services could be implemented directly by the client. But most likely, they are implemented in the backend part of the application. Scout makes it easy to communicate with remote services.
Client and Server components use a common shared plug-in set. They contain service interfaces and data transfer objects. The server part is implementing these service interfaces and the client part is consuming them. Scout SDK creates all required declarative service entries in the plugin.xml filed of the client and backend plug-in, respectively. In the client plug-in, the service interface is registered using a client proxy service factory. It creates a proxy object that forwards every method call to the particular service implementation in the backend system, completely transparent. The backend on the other side registers an interface implementation using the interface class name as service name.
All the communication is managed by a service tunnel. It packs every service request in a HTTP message and sends it to the backend. The backend is server-side equinox web application running in an ordinary J2EE compliant web container. The Equinox HTTP Servlet Bridge launches the serer-side OSGi framework and bridges all requests. The receiving part is the other end of the service tunnel that unpacks all incoming requests and dispatches them to the requested service implementation. The service’s answer goes along the same path back. The server-side service tunnel endpoint packs the response in a HTTP response and sends it back to the client. There the response is unpacked and forwarded to the caller.
One kind of data transfer objects is directly deduced from the target objects, the forms. Hence they are called form data. From data classes are automatically generated by the Scout SDK whenever the hosting form is changed (in fact, this behavior can be controlled using Java annotations). Forms provide an import and export method, respectively. Therefore loading data into and storing them from a form into a form data is just a single method call.