| Feedback to Scout framework [message #580516] |
Fri, 07 May 2010 11:36  |
 Urs Bratschi
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
Hi together
Generally I find the approach of the Scout framework quite interesting. The simplicity how you can click together your GUIs and backend component is really nice and efficient. Anyway does scout have some issues in the architecture in my point of view, that could be a killer criteria in the decision for or against Scout.
- The interface between client and server is from technical point of view a webservice, but the formdata objects are serialized and transmitted by a tunneling mechanism. This is not the idea of a webservice. A webservice should be open for other client that wand to use it. This is not really possible in this constellation. It is also not possible to observe the service call from any proxy server.
- The formdata object which is the base of the client/server communication are build from the forms (GUI-Design). According to this there is a service needed to read, store, create and delete the formdata objects. So we have GUI logic on the backend component. If the form changes, there is also a change on the backend service needed. If we have 2 different forms (that shows more or less the same) we will have also 2 different services. The backend should in fact have no knowledge about the implementation in the GUI component.
What my wishes would be for the Scout framework:
- It should be possible to create a real webservice and also generate a WSDL file (for other service users). This would be really cool!
- Between client and server the communication should not be with formdata, but with some kind of business objects. On client side a mapping mechanism from formdata to business objects (and backwards) would be nice.
The advantage of this would also be, that you could use another GUI framework instead the GUI part of scout. The generative approach of forms (like Scout use it) is nice for simple forms (does this exist in the real world?), but for complex constructs always a little bit problematic. I can imagine that a scenario with Scout as framework for client/server communication (I think there is the power of scout) with a own implementation of the forms with SWT, Swing or something else is not so bad.
regards,
Urs
|
|
|
| Re: Feedback to Scout framework [message #580602 is a reply to message #580516] |
Mon, 10 May 2010 20:45  |
Eclipse User |
|
|
|
Hi Urs
Thank you for the feedback. It is pretty nice to see people are getting in touch with Scout.
Web service vs. application services
Scout applications are fully service oriented; we talk about application services. It does not make sense in most cases to provide these application services as web-services. In fact huge application with about 200-250 application services about 10-25 services are usually of common interest and deployed as web-services. Therefore Scout SDK (development environment) provides a menu to deploy a Scout service as a web service (using Axis). Exposed services must implement a fine grained parameter check to ensure fail safety.
Remote services are registered on the 'org.eclipse.scout.service.services' extension point client side with an 'IServiceFactory' to handle a service call. Scout framework contains a client implementation of a 'IServiceFactory' called 'ClientProxyServiceFactory' out of the box. This factory creates a remote proxy service of the server side service implementation using the registered 'IServiceTunnel' implementation set on application start.
To provide a web service call for each application service you can either write your own IServiceFactory (client-side) or an implementation of an 'IServiceTunnel'. Huge companies often make usage of gate keeper. In case of using a web-service for every application service in a gate keeper environment every Scout application service (web service) must be registered on the gate keeper (expensive for new services).
Data binding, communication bean
The complexity of business applications depends strongly on the amount of layers. Every transformation of a bean into another are potentially point of failures. One of the goals of Scout is to keep application development as simple as possible and keep complexity low. Therefore Scout provides the FormData mechanism to transfer data in multi tier applications. The usage of FormDatas is optional and can easily be replaced by other DTOs.
Usage of other domain models
We do have experiences in developing huge applications using a Hibernate domain model. Such applications can use the Hibernate model as communication beans. In such applications the Hibernate domain model is used as DTOs and bound to the form in its form handler ('IFormHanlder').
Client model / GUI
The Scout application model is fully extendible and every UI representation can be exchanged to an own one (see http://wiki.eclipse.org/ExtendingScout). The exchangeable of UI components does not depend on usage of FormData.
GUI-Builder
In general the usage of GUI builder has to be evaluated carefully. Personally I evaluated a lot of GUI builders; without any success.
Scout is not a GUI builder at all. Since Scout provides a model definition of the application it is much more flexible as every GUI builder. This model can be represented by any GUI implementation. SWT/Swing are two examples included in Scout. Furthermore the Scout client model can also be represented in a web environment. We currently have a project together with a university running to build a Scout Wicket (Apache Wicket) representation.
I hope I answered your questions.
Cheers
Andreas
|
|
|
Powered by
FUDForum. Page generated in 0.02941 seconds
] 
Search
Help
Register
Login
Home
