Figure 1.1: The desktop client of a Scout enterprise application.
Scout is a mature framework for building business applications. With its multi-frontend support, a single Scout applications may run as a desktop application, in a web browser or on a mobile phone with touch support. The clean separation of Scout’s client model from the user interface technologies allows the developer to concentrate on a single code base. This approach has advantages for end users of Scout applications, Scout developers, and organisations implementing Scout applications. In the text below we will explain Scout from the perspective of these three roles.
End users of enterprise applications typically care about friendly user interfaces (UI) and well designed functionality that support them in doing their job. Depending on the role and the current context of an end users, either mobile, web or desktop clients work best. In the text below, we use a real world enterprise application to highlight how Scout applications can provide user friendly UIs on the desktop, in the browser and on mobile phones.
If the user is working from a desk and frequently engaged in customer calls, good integration with locally installed software such as Lotus Notes or Microsoft Office products can significantly boost productivity. So far, such a scenario still requires a desktop client application. An example screenshot of a Scout desktop client application from a customer relationship management (CRM) solution is provided in Figure 1.1. The screenshot provides a good overview of the general layout of the application. On the left side a tree for simple navigation through the available entities, such as companies, persons and communications is provided. Once an entity is selected, a click on the magnifying glass opens a search form on the right hand side. In this search form a number of search fields is provided. After entering ”eclipse” into the company search field – and clicking the search button at the bottom of the search form – the list of matching entries is presented to the user. With a right mouse click on the desired row, the corresponding company dialog can be opened for editing.
When a user needs to work from a computer that does not have a desktop client installed (or lacks the time or the necessary permission to install software) the natural choice is to work with a web application. As Scout offers multi-frontend capabilities out of the box, a web frontend can easily be provided for Scout business applications. The primary benefits of Scout web applications for end users are a consistent look and feel and behaviour for both the web client and the desktop client. In Figure 1.2 a screenshot of the web client of the CRM Scout application is shown.
Often, user find themselves in meetings or on the move where it is not possible to work with desktop or laptop computers. In such situations, accessing applications via tablets or mobile phones is the only meaningful approach. As shown in Figure 1.3, a screenshot of the familiar CRM application is provided. The user still benefits from the familiar look and feel and the known functionality of the application.
In contrast to desktop and web applications, most tablets and mobile phones are controlled using touch features instead of mouse clicks. In addition, less elements may be presented on a single screen compared to desktop devices. These two aspects makes it impractical to directly reuse the desktop user interface on mobile devices. Using the Scout mobile extension, the user interface of Scout applications can be transformed on the fly to adapt to touch control and the smaller form factor of mobile devices. This transformation can be observed when comparing the company table shown in the background of Figure 1.1 with the company list presented in Figure 1.3. The multi-column table of the desktop client has been transformed into a list providing the content of the first few table columns on separate rows. In addition, the context menu ”New company” is now provided as a touch button. As the navigation in the application and the offered choices remain the same for Scout desktop and mobile applications, the end user feels immediately comfortable working with Scout mobile applications.
For the management, Scout is best explained in terms of benefits it brings to the organisation in question. This is why we are going to concentrate on a (typical) application migration scenario here. Let us assume that to support the company’s business, a fairly large landscape of multi-tier applications has to be maintained and developed. Including host systems, client server applications including desktop clients, as well as newer web based applications.
Usually, these applications interact with each other through a service bus as shown in Figure 1.4. Often, some of the applications that are vital to the organisation’s core business have grown historically and are based on legacy technologies. And for technologies that are no longer under active development it can get difficult to find staff having the necessary expertise or motivation. Sometimes, the organisation is no longer willing to accept the costs and technology risks of such mission critical applications.
In this situation, the company needs to evaluate if it should buy a new standard product or if the old application has to be migrated to a new technology stack. Now let us assume, that available products do not fit the company’s requirements well enough and we have to settle for the migration scenario. In the target architecture, a clean layering similar to the one shown in Figure 1.5 is often desirable.
While a number of modern and established technologies exist that address the backend side (data bases, data access and business services), the situation is different for the UI layer and the application layer. The number of frameworks to develop web applications with Java is excessively large1 , but the choice between desktop application technologies in the Java domain is restricted to three options only. Swing, SWT and JavaFX. Both Eclipse SWT and Java Swing are mature and well established but Swing is moving into ’maintenance only’ mode and will be replaced by JavaFX. However, the maturity of the new JavaFX technology in large complex enterprise applications is not yet established. Obviously, deciding for the right UI technology is a challenge and needs to be made very carefully. Reverting this decision late in a project or after going into production can get very expensive and time consuming.
Once the organisation has decided for a specific UI technology, additional components and frameworks need to be evaluated to cover client server communication, requirements for the application layer, and integration into the existing application landscape. To avoid drowning in the integration effort for all the elements necessary to cover the UI and the application layer a ’lightweight’ framework is frequently developed. When available, this framework initially leads to desirable gains in productivity. Unfortunately, such frameworks often become legacy by themselves. Setting up a dedicated team to actively maintain the framework and adapt to new technologies can reduce this risk. But then again, such a strategy is expensive and developing business application frameworks is usually not the core business of a company.
Can we do better? To implement a business application that covers the UI and the application layer as shown in Figure 1.5, Eclipse Scout substantially reduces both risk and costs compared to the inhouse development presented above. First or all, Scout is completely based on Java and Eclipse. Chances are, that developers are already familiar with some of these technologies. This helps in getting developers up to speed and keeping training costs low.
On the UI side, Scout’s multi-frontend support almost allows to skip the decision for a specific UI technology. Should a particular web framework become the de-facto standard in the next years, it will be the responsibility of the Scout framework to provide the necessary support. Existing Scout applications can then switch to this new technology with only minimal effort. This is possible because the Scout developers are designing and building the UI of an application using Scout’s client model. And this client model is not linked to any specific UI technology. Rather, specific UI renderers provided by the Scout framework are responsible to draw the UI at runtime.
As Scout is an open source project, no licence fees are collected. Taking advantage of the growing popularity of Scout, free community support is available via a dedicated forum. At the same time, professional support is available if the organisation decides for it.
As the migration of aging applications to current technology is always a challenge, it surely helps to have Scout in the technology portfolio. Not only is it a low risk choice, but also boosts developer productivity and helps to motivate the development team.
From the perspective of application developers, Scout offers a Java based framework that covers the complete client server architecture. This implies that – once familiar with the Scout framework – the developer can concentrate on a single framework language (Java) and a single set of development tools.
As Scout is completely based on Java and Eclipse, Scout developers can take full advantage of existing knowledge and experience in these domains. And to make learning Scout as simple as possible, Scout includes a comprehensive software development kit (SDK), the Scout SDK. The Scout SDK helps to create a robust initial project setup for client server applications and includes a large set of wizards for repetitive and error prone tasks. The architecture of a Scout client server created by the Scout SDK is shown in In Figure 1.6.
On the client-side Scout’s flexible client model allows the developer to create a good user experience without having to care about specific UI technologies. The reason for this can be found in Scout’s client architecture that cleanly separates the UI model from the UI technology. This is illustrated in Figure 1.6 and Figure 1.7 where the Scout UI rendering compontents for Swing, SWT and RAP are shown to be part of the Scout framwork itself. The price of this architecture is the fact, that in Scout (almost) every UI component is implemented four times. First the implementation of the UI model component and then, three rendering components for each UI technology supported by Scout. For desktop clients these are the Swing and the SWT technologies, and for the web and mobile support this is Eclipse RAP which in turn takes care of the necessary JavaScript parts.
Not having to worry about Swing, SWT or JavaScript can significantly boost the productivity. With one exception. If a specific UI widget is missing for the user story to be implemented, the Scout developer first needs to implement such a widget. Initially, this task is slightly more complex than not working with Scout. For custom widgets the Scout developer needs to implement both a model component and a rendering component for a specific UI technology. But as soon as the client application needs to be available on more than a single frontend, the investment already pays off. The developer already did implement the model component and only needs to provide an additional rendering component for the new UI technology. In most situations the large set of Scouts UI components provided out-of-the box are sufficient and user friendly applications are straight forward to implement. Even if the application needs to run on different target devices simultaneously.
Client-server communication is an additional aspect where the developers is supported by Scout. Calling remote services in the client application that are provided by the Scout server looks identical to the invocation of local services. The complete communication including the transfer of parameter objects is handled fully transparent by the Scout framework. In addition, the Scout SDK can completely manage the necessary transfer objects to fetch data from the Scout server that is to be shown in dialog forms on the Scout client. The binding of the transferred data to the form fields is done by the framework.
Although the Scout SDK wizards can generate a significant amount of code, there is no one-way code generation and no meta data in a Scout application. Just the Java code. Developers preferring to write the necessary code manually, may do so. The Scout SDK parses the application’s Java code in the background to present the updated Scout application model to the developers preferring to work with the Scout SDK.
Finally, Scout is an open source framework hosted at the Eclipse foundation. This provides a number of interesting options to developers that are not available for closed source frameworks. First of all, it is simple to get all the source code of Scout and the underlying Eclipse platform. This allows for complete debugging of all problems and errors found in Scout applications. Starting from the application code, including the Scout framework, Eclipse and down to the Java platform.
Scout developer can also profit from an increasing amount of free and publicly available documentation, such as this book or the Scout Wiki pages. And problems with Scout or questions that are not clearly addressed by existing documentation can be discussed in the Scout forum. The forum is also a great place for Scout developers to help out in tricky situation and learn from others. Ideally, answered questions lead to improved or additional documentation in the Scout Wiki.
At times, framework bugs can be identified from questions asked in the forum. As all other enhancement requests and issues, such bugs can be reported in Bugzilla by the Scout developer. Using Bugzilla, Scout developers can also contribute bug analysis and patch proposals to solve the reported issue. With this process, Scout developers can actively contribute to the code base of Eclipse Scout. This has the advantage, that workarounds in existing Scout applications can be removed when an upgrade of the Scout framework is made.
Having provided a significant number of high quality patches and a meaningful involvement in the Scout community, the Scout project can nominate a Scout developer as a new Scout committer. Fundamentally, such a nomination is based on the trust of Scout committers in the candidate. To quote the official guidelines2 for nominating and electing a new committer:
A Committer gains voting rights allowing them to affect the future of the Project. Becoming a Committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse Member company or any company employing existing committers.
After a successful election process (existing committers voting for and not against the candidate) the Scout developer effectively becomes a Scout committer. With this new status, the Scout developer then gets write access to the Eclipse Scout repositories and gains voting rights and the possibility to shape the future of Scout.
Below a number of facts around the background and usage of Scout applications is provided in the form of bullet points. And for each of the statements it would be possible to write a story on its own. But instead, we just leave the sentences in the format of an elevator pitch.
The text below provides guidelines on what to read (or what to skip) depending on your existing background.
We first address the needs of junior Java developers that like to learn more about developing enterprise applications. Then, we suggest a list of sections relevant for software wizards that already have a solid understanding of the Eclipse platform, Java enterprise technologies, and real world applications. Finally, the information needs of IT managers are considered.
The good news first. This book is written for you! No prior knowledge of the Eclipse Platform3 is needed. We do not even assume that you have a meaningful understanding of the Java Enterprise Edition (Java EE)4 . Of course, having prior experience in client server programming with Java is helpful. It also helps having used the Eclipse IDE for Java development before — please do not mistake the IDE with the Eclipse platform5 . However, prior knowledge of Java EE and the Eclipse platform is not required for this book.
The “bad” news is, that writing Scout applications requires a solid understanding of Java. To properly benefit from this book, we assume that you have been developing software for a year or more. And you should have mastered the Java Standard Edition (Java SE)6 to a significant extent. To be more explicit, you are expected to be comfortable with all material required for the Java Programmer Level I Exam7 and most of the material required for Level II8 .
Luckily, free online tutorials to learn Java are offered in many places. A good starting point is the official Java documentation site9 . If you prefer to work with video tutorials we recommend “Eclipse and Java for Total Beginners”10 , although the installation used is somewhat out of date. As for printed books, we suggest to start with either “Head First Java”[1] or “Thinking in Java”[3]. Highly recommended but slightly more advanced is “Effective Java”[2].
To solve the really tricky Java problems there is often no way around the Java specification11 itself. Just make sure to pick the right Java version for your context.
We now propose to start downloading and installing Scout as described in Appendix B and do some actual coding. To do so, please continue with the “Hello World” example provided in Chapter 2. You can expect to complete this example in less than two hours including the necessary download and installation steps. Afterwards, you might want to continue with the remaining material in “Getting Started”. Working through the complete “Getting Started” should take no more than two days. This exercise will provide you with a broad overview of Eclipse Scout and enough hands-on material to decide how much Scout will help you with your current and future projects.
Once you work with the Scout framework on a regular basis, you might want to ask questions in the Scout forum12 . When your question gets answered, please ask yourself if your initial problem could have been solved by better documentation. In that case, you might want to help the Scout community by fixing or amending the Scout wiki pages13 . Or this book. If you find a bug in Eclipse Scout that makes your life miserable you can report it. When your bug is fixed, you can test the fix. To help speed up the bug fixing process you can contribute patches. All of these actions will add to the healthy grow of the Scout community. And this is exactly the topic of “Contributing”, the last part of this book.
This means that you are one of these software wizards that get easily bored. You probably hate going through lengthy descriptions of widely known concepts. In that case let us assume that you are prepared to spend two hours to grasp the scope of Eclipse Scout and get an impression of its strengths and limitations. The list below suggests a sequence of sections to digest including a brief motivation for each one.
Being a manager and actually reading this book may indicate one of the following situations:
If you did not already go through Section 1.1 please do so now. Then, flip through Section 5.1 to get an impression of the ”My Contacts” application. In case you like the idea that your developers should be able to build such an application in a single day, you might want to talk to us15 .
