we've been asked to outline our roadmap for the near and mid-term future of Scout. As this topic might be of interest to a wider audience, we want to share the discussion and get feedback/input from both Scout committers and Scout adopters.

Below we've compiled a list of things that some of us believe should become available for Scout in the period over the next two years.

Regarding the roadmap, I would like to see much better JUnit support integrated into Scout SDK, which would be great for TDD. For example, Scout SDK could create a test case when creating a form or a new service operation.

The SDK could also provide a simple way to start the tests (all of them, a specific test)... For the moment projects create some additional product files to start the tests and there is the DevTestMarker annotation. There is place for improvements...

I think the items selected for 3.9 are the current "hot items" when it comes to software development and will become a necessity in the coming months.

However I would like to suggest to add the following to your list for the 3.9 release to help people creating solid applications quickly & fast :

- include a reporting engine
- include a rule engine
- include a bpmn / proces flow engine
- include an ESB like bus (e.g. camel with activeMQ)
- auto creation of initial forms based on the database tables

One could argue that these all can be added by the individual developper using Scout in his own projects.
This is true, however not everybody is interested in doing a selection process in selecting the necessary packages. On top this could make deployment a little bit more complex.
For most individual developpers, it is easier if everything is sitting together in the Scout package.

> However I would like to suggest to add the following to your list for the 3.9 release > to help people creating solid applications quickly & fast :
>
> - include a reporting engine
> - include a rule engine
> - include a bpmn / proces flow engine
> - include an ESB like bus (e.g. camel with activeMQ)
> - auto creation of initial forms based on the database tables

Tore, what is your opinion for each of these items regarding the following aspects:
1) how much of the selection pain you mention can be addressed by a working tutorial?
2) what would be the use case the tutorial should focus on?
3) which projects/products do you recommend to consider (e.g. camel/service mix for esb integration)?

Compared with Google App Engine the above mentioned PaaS seem to rely more on open standards (and vendor lock-in seems to be less pronounced). Don't get me wrong, our experience base is still very weak and the above ideas are just conclusions from a single article...

Good tutorials on the items mentioned (reporting, rule engine, proces flow, esb) would (in my opinion) have for a consequence that you as a company need to make a selection on these. The workload involved for documentation, creating examples etc would be forcing you to make a selection on these items. Even if available resourcing would be unlimited, it is nearly impossible to document several possible solutions on these items. Hence the selection proces itself would have been done, and I think for most developers this would already give a kick start.
The documenting of the use of the mentioned items would force you to look at the Scout environment as a full solution for modern development techniques.
Personally I think that the days of developing everything yourself are gone. You need to have a fully integrated platform allowing you to create a UI, put business logic in a combination of ruling engines and proces flow engines and glue different systems to each other with an "ESB" like tool.

The uses cases should focus in this setup to demonstrating the combined strength of the platform.
E.g.
- The Scout Platform allows for getting very easy from the user interface to the server.
- At the server you could put complex validation / calculation rules in the ruling system.
- Once validations have been done, an approval proces could be started by the proces flow engine
- part of the approval proces could be publishing information on a webservice. As we are not sure if the webservice is available we put the information on the ESB who is acting as a local proxy with a message queue in case the service is unavailable.

Take the following example

You need to create a transportation from a warehouse to other warehouses.
First step create transport and add delivery notes to it.
Second step : calculate routing based on the delivery notes you have added to the transport you created. -> this would be executed by the ruling engine.
Third step : request delivery slots in the different warehouses and update status of the delivery notes -> this would be executed by proces flow in combination with the ESB
Fourth step : if necessary re-calculate routing based on the delivery slots obtained from the warehouses.- > this would be executed by the ruling engine.
Fifth step : inform the initiator of the transport that the transport is ready for dispatching and request approval -> this would be executed by proces flow

This example is something that can be done with Scout in combination with some tools and shows the strength of the total platform.

With regards to the products I would recommend : I am still myself in the "pain" of doing the selection.

For the moment it looks like i would consider a combination of Scout with for
- reporting :Jasperreports
- rule engine + process flow : drools
- ESB like : camel in combination with Active MQ.

As said I am still in the proces of putting the puzzle together on the platform I need.

I am also stil trying to figure out what would be the best way to approach the DB : the traditional way via SQL statements or with something as Hibernate.

Lastly what realy would be a big help is the autogenaration of the base screens based on the database layout (or object layout if hibernate is used).
For each of table or object you need to create maintenance screens, having these created automatically for most part would drastically improve development performance.

we've recently started a tutorial on maven tycho integration. There you can find a way of how to get a very basic maven tycho setup for an existing Scout application. After that you can setup a CI build server like Hudson or Jenkins and you are almost there...

According to an article by Michael Yuan CloudBees, OpenShift and maybe Amazon Beanstalk look interesting to me.

Matthias, thanks for this interesting article on different PaaS offerings. Personally, I would very much like to see Scout applications running on CloudBees or OpenShift.

Quote:

I would like to see Eclipse Scout support and/or compatibility for Google App Engine and Google Cloud SQL.

As far as I can tell from earlier investigations on this topic, it seems not very likely that we will see Scout applications running on Google App Engine. The restrictions of GAEs sandbox make it quite hard (if not impossible) to get an OSGi/Equinox environment running. There have been efforts [1],[2] in that direction with partial success, but there doesn't seem to be any recent activity on this topic...

Thanks for you input. When we start to work on a JavaFX UI layer for Scout, this will first become an additional option (and not a replacement for Swing).

Before we abandon the Swing layer, we would want to discuss this topic with the Scout community well in advance. We will probably be driven by Oracle policy as they have alread stated that JavaFX will replace Swing in the future.