Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Scout » Proposal Feedback
Proposal Feedback [message #523274] Thu, 25 March 2010 18:00 Go to next message
Martin Lippert is currently offline Martin LippertFriend
Messages: 124
Registered: July 2009
Senior Member
Hi Matthias!

You asked me to take a look at the Scout proposal, so here are my thoughts and questions for you guys. Hope this helps!

Cheers,
-Martin


1. Eclipse Scout and Riena:
In what situations do you recommend the Scout framework, for what cases Riena? Should a user use both framworks together? But maybe this doesn't make sense. So people might get confused with framework to use...

2. Eclipse Scout and the enterprise OSGi efforts:
If I only consider the parts of Scout that are not RCP-specific (communication, JEE stuff, etc.), how does this fit with the enterprise OSGi efforts? Do you reuse the other projects (ECF, Gemini, Apache Aries, etc.) or does Scout duplicate some of its functionality? If so, why?

3. Eclipse Scout and third party libraries:
You write in our proposal about support for the integration of third party libraries. Could you elaborate on this point? What kind of support do you mean? A bundle repo with OSGi-fied lib bundles or some runtime magic to let those libs play nicely within OSGi or something completely different?

4. Eclipse Scout and committers outside BSI:
What is your plan to encourage committers outside BSI to join the Eclipse Scout project? Do you have specific people outside BSI in mind that aspire to become Scout commiters? I personally prefer projects having committers from more than a single organisation and I think this is crucial for a healthy community of an open-source project...

5. Eclipse Scout and support for backend implementation:
You don't seem to support the backend implementation directly, or do you? Are backends other than JEE conceivable, such as pure OSGi? What about other lightweight approaches? (Having client support for EJB backends seems to me (IMHO) quite a bit useless since most people I know are moving away from EJB or that stuff towards lightweight RESTful APIs etc.

6. Eclipse Scout and dependency injection, Spring DM, etc.:
You write in your proposal about conformance to the e4 project. What are your views regarding dependency injection? How do you make use of this concept in Scout? Or would there be a meaningful way to combine Scout with Declarative Services/Blueprint/Spring DM/Juice/e4 dependency injection/etc.?

7. Eclipse Scout and unit tests:
And of course I have to ask: Do you have unit tests for Eclipse Scout? What about coverage? I think this is a very crucial element in keeping the project healthy and stable over time.

8. APIs:
What is your API policy? Is there a clear distinction between API and non-API stuff? And what is the projects background on API design? So is there already a stable API existing or did you change the API over the past month and years frequently?

Re: Proposal Feedback [message #523854 is a reply to message #523274] Mon, 29 March 2010 15:51 Go to previous messageGo to next message
Matthias Zimmermann is currently offline Matthias ZimmermannFriend
Messages: 208
Registered: June 2015
Senior Member
1. Eclipse Scout and Riena

Many aspects of building enterprise applications are covered by both frameworks.

Scout comes with strong tooling and offers a low entry barrier into building enterprise applications (without restricting advanced developers later). Among many other things Scout also features a complete application model, abstract UI components that can be linked with both SWT or Swing implementations.

Riena offers its own navigation methaphor and direct support of business components (e.g. mechanisms to transfer only updates of business components between client and server).

Using both frameworks togehter seems like overkill.
Re: Proposal Feedback [message #523991 is a reply to message #523274] Tue, 30 March 2010 08:35 Go to previous messageGo to next message
Ivan Motsch is currently offline Ivan MotschFriend
Messages: 154
Registered: March 2010
Senior Member
> 5. Eclipse Scout and support for backend implementation:
> You don't seem to support the backend implementation directly, or do you?
> Are backends other than JEE conceivable, such as pure OSGi?
> What about other lightweight approaches?
> (Having client support for EJB backends seems to me (IMHO) quite a bit useless since most people I know are moving away from EJB or that stuff towards lightweight RESTful APIs etc.

short answer: yes, scout support backends. yes, scout support many types of backends.
long answer : A client/server scout application consists of a client (rcp with swt, rcp with swing, headless rcp, others..) and a backend that is also an equinox/eclipse (server side equinox, eclipse, ...).
The communication from client to server is based on the simple interface IServiceTunnel with method
Object invokeService(Class<?> serviceInterfaceClass, Method operation, Object[] args) throws ProcessingException;

All client services that are proxies, are using a delegator that calls this service tunnel to call the backend.

The protocol used to communicate with the backend is therefore open.
By default the client uses the HttpServiceTunnel and the server provides a servlet ServiceTunnelServlet.
The content of the http messages is also customizable: The objects passed are ServiceTunnelRequest and ServiceTunnelResponse. The content handler is an interface: IServiceTunnelContentHandler
By default the DefaultServiceTunnelContentHandler is used, which communicates over the SOAP protocol with serialized objects encoded as base64. Certeainly also other handlers can be used.

The serverside is also a normal equinox/eclipse. By default the server-side equinox is used and embedded in a tomcat/jetty/... with the equinox servletbridge. Also a standalone eclipse could be used.
We have applications with offline capabilities where the "server" can (when offline) also be run on the client side. In this case a service tunnel is used that does no http, but simply directly implements the request/response pattern.
As pointed out above, the IServiceTunnel interface is the thing that the client sees. It can be implemented to call a standalone osgi.

The service tunnel is set into the client session (there may be multiple in an osgi) with
IClientSession.setServiceTunnel(IServiceTunnel)


There was a question once, why using a service tunnel and not a full scale web services for each client/server service. We see a basic difference between web services and services from client/gui to server.
Web services are used for process to process communications also known as B2B and normally re-used by other parties.
Gui/server services are of a different nature and only used by THE gui. Therefore an implicit service tunnel bundles the communication of all these services.

However, gui/server services even though make use of the soap protocol for easy firewall and reverse proxy environment. Also gui/server services are fully typed osgi services with remoting capabilities.

See for example the ping service's extensions in the client and server Plug-In.

Plug-In com.bsiag.mail.client.core registers an osgi service with a proxy handler:
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
  <extension point="org.eclipse.scout.service.services">
    ...
    <proxy class="org.eclipse.scout.rt.shared.services.common.ping.IPingService" factory="org.eclipse.scout.rt.client.services.ClientProxyServiceFactory"/>
    ...
  </extension>
</plugin>


Plug-In com.bsiag.mail.server.core registers an osgi service that implements IPingService
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
  <extension point="org.eclipse.scout.service.services">
    ...
     <service class="org.eclipse.scout.rt.server.services.common.ping.PingService"/>
    ...
  </extension>
</plugin>

Re: Proposal Feedback [message #524099 is a reply to message #523274] Tue, 30 March 2010 17:06 Go to previous messageGo to next message
Matthias Zimmermann is currently offline Matthias ZimmermannFriend
Messages: 208
Registered: June 2015
Senior Member
4. Eclipse Scout and committers outside BSI

We have to ensure the stability of existing Scout based applications. In addition, the success of our customer projects depends on the quality of the Eclipse Scout framwork. Therefore, required standars for Eclipse Scout committers are very high.

Initially Eclipse Scout will have four committers from BSI (see proposal). Becoming Scout committer will primarily be based on a consistant set of high quality contributions delivered to the Scout project and is not restricted to employees of BSI.

[Updated on: Tue, 30 March 2010 17:06] by Moderator

Report message to a moderator

Re: Proposal Feedback [message #525297 is a reply to message #524099] Tue, 06 April 2010 07:00 Go to previous messageGo to next message
Andreas Ottiger is currently offline Andreas OttigerFriend
Messages: 5
Registered: April 2010
Junior Member
Matthias' answer sounded a bit harsh for me, so I talked to him.

Although not everyone will become a committer right away, the project is open. Anyone capable has the chance to participate and other committers will be accepted (given the quality of their contributions).
Re: Proposal Feedback API [message #525680 is a reply to message #523274] Wed, 07 April 2010 12:56 Go to previous messageGo to next message
Eclipse UserFriend
8. API
Since Scout as an application framework has been installed about 20'000
times all over the world a stable API is strongly required. Scout has a
clearly defined API layer, makes strong usage of internal packages and
hidden API. People are able to reuse internal code in consideration of
API changes.

A clearly defined API policy will be defined after project creation. So
far committers on the Scout project follow the eclipse version numbering
process (http://wiki.eclipse.org/index.php/Version_Numbering).

Cheers
Andreas


Martin Lippert wrote:
> Hi Matthias!
>
> You asked me to take a look at the Scout proposal, so here are my
> thoughts and questions for you guys. Hope this helps!
>
> Cheers,
> -Martin
>
>
> 1. Eclipse Scout and Riena:
> In what situations do you recommend the Scout framework, for what cases
> Riena? Should a user use both framworks together? But maybe this doesn't
> make sense. So people might get confused with framework to use...
>
> 2. Eclipse Scout and the enterprise OSGi efforts:
> If I only consider the parts of Scout that are not RCP-specific
> (communication, JEE stuff, etc.), how does this fit with the enterprise
> OSGi efforts? Do you reuse the other projects (ECF, Gemini, Apache
> Aries, etc.) or does Scout duplicate some of its functionality? If so, why?
>
> 3. Eclipse Scout and third party libraries:
> You write in our proposal about support for the integration of third
> party libraries. Could you elaborate on this point? What kind of support
> do you mean? A bundle repo with OSGi-fied lib bundles or some runtime
> magic to let those libs play nicely within OSGi or something completely
> different?
>
> 4. Eclipse Scout and committers outside BSI:
> What is your plan to encourage committers outside BSI to join the
> Eclipse Scout project? Do you have specific people outside BSI in mind
> that aspire to become Scout commiters? I personally prefer projects
> having committers from more than a single organisation and I think this
> is crucial for a healthy community of an open-source project...
>
> 5. Eclipse Scout and support for backend implementation:
> You don't seem to support the backend implementation directly, or do
> you? Are backends other than JEE conceivable, such as pure OSGi? What
> about other lightweight approaches? (Having client support for EJB
> backends seems to me (IMHO) quite a bit useless since most people I know
> are moving away from EJB or that stuff towards lightweight RESTful APIs
> etc.
>
> 6. Eclipse Scout and dependency injection, Spring DM, etc.:
> You write in your proposal about conformance to the e4 project. What are
> your views regarding dependency injection? How do you make use of this
> concept in Scout? Or would there be a meaningful way to combine Scout
> with Declarative Services/Blueprint/Spring DM/Juice/e4 dependency
> injection/etc.?
>
> 7. Eclipse Scout and unit tests:
> And of course I have to ask: Do you have unit tests for Eclipse Scout?
> What about coverage? I think this is a very crucial element in keeping
> the project healthy and stable over time.
>
> 8. APIs:
> What is your API policy? Is there a clear distinction between API and
> non-API stuff? And what is the projects background on API design? So is
> there already a stable API existing or did you change the API over the
> past month and years frequently?
>
>
Re: Proposal Feedback [message #526002 is a reply to message #523274] Thu, 08 April 2010 14:08 Go to previous messageGo to next message
Daniel Wiehl is currently offline Daniel WiehlFriend
Messages: 1
Registered: May 2016
Junior Member
6. Eclipse Scout and dependency injection, Spring DM, etc.:

You write in your proposal about conformance to the e4 project. What are your views regarding dependency injection? How do you make use of this concept in Scout? Or would there be a meaningful way to combine Scout with Declarative Services/Blueprint/Spring DM/Juice/e4 dependency injection/etc.?


Scout itself does not make use of dependency injection, but there is no restriction of which DI framework to use for developing your application based on Scout to achieve inversion of control.
The services managed by Scout are plain OSGI services which are exported into the common OSGI service registry. In Scout, this is achieved declaratively by simply register the service to the Scout service extension point. However, Spring DM services also rely on OSGI services which is a perfect match to profit from the many Spring features in your Scout application.
Re: Proposal Feedback [message #526045 is a reply to message #523274] Thu, 08 April 2010 15:12 Go to previous messageGo to next message
Andi Bur is currently offline Andi BurFriend
Messages: 5
Registered: March 2010
Junior Member
7. Eclipse Scout and unit tests:

We absolutely agree on your point that tests help to boost quality and stability. So far, the framework quality was assured by testing Scout in the context of our customer projects. As we plan to participate in next year's release train we have started writing unit tests for new features and bug fixes.
Re: Proposal Feedback - third party libraries [message #526615 is a reply to message #523274] Mon, 12 April 2010 12:40 Go to previous messageGo to next message
Judith Gull is currently offline Judith GullFriend
Messages: 75
Registered: February 2010
Member
3. Eclipse Scout and third party libraries:
You write in our proposal about support for the integration of third party libraries. Could you elaborate on this point? What kind of support do you mean? A bundle repo with OSGi-fied lib bundles or some runtime magic to let those libs play nicely within OSGi or something completely different?

The goal of Eclipse Scout is to make application development on the Eclipse platform more efficient and at the same time not to reduce the flexibility and extensibility.

We tried to achieve this goal by using the tools provided by eclipse, i.e. extension points and OSGI services. For example, Scout has it's own GUI model, but it is easily possible to integrate a 3rd party SWT component in a Scout application.
(see http://wiki.eclipse.org/ExtendingScout)
And of course OSGI services of any application can be accessed easily within Scout. Scout comes with much convenience and utility classes to make osgi service handling and other things easier and more comfortable.

Re: Proposal Feedback [message #531414 is a reply to message #523274] Tue, 04 May 2010 18:48 Go to previous messageGo to next message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
Hi Martin/all,

Thanks for your input.

> 1. Eclipse Scout and Riena:
I mentioned Riena at EFE to BSI already.

2. Java EE
Beside a rather old-fashioned "J2EE" which slipped into the proposal ;-)
I wonder why Gemini isn't listed as potentially related project? After all
it aims at OSGi-enabling nearly all of Java EE and related technologies.

At least the legal issues for javax.mail.* should matter to Gemini in the
same way. And Java bearer Oracle having a lead role in Gemini could make
that a bit easier for them ;-)

3. Business Usage
Scout is already scheduled at Eclipse Banking Day Copenhagen. And it seems
one of the few real business frameworks. As Eclipse Financial is constantly
absent and was proclaimed dead by its committers earlier (also at EFE 09)

I tried to get BSI and the Elexis project (as presented at EclipseCon) in
touch. Although it may exceed their current resources, some of Scout seems
to match this project quite well.

Since a few of their stakeholders probably met you at EclipseCon or even may
have seen Scout presented there, I tried to point members of the Austrian
Telekom RCP CRM team to Scout.
At least 8 out of 9 background items match perfectly with the underlying
values and some of the frameworks used or created by this project.

4. Multi-language support
Although the project has already been created, I'd be happy to join as
Interested Party on behalf of Eclipse Babel!
Another project many may not see, but where the Scout SDK provides reusable
mechanisms for UI support you're in Babel territory ;-)

Cheers,
Werner
Re: 4. Eclipse Scout and committers outside BSI [message #537647 is a reply to message #524099] Thu, 03 June 2010 09:09 Go to previous message
Werner Keil is currently offline Werner KeilFriend
Messages: 1087
Registered: July 2009
Senior Member
You should probably branch the codebase, ensuring by fine grained access /
commit rights for only some to "stable" branches, that those are working for
your customers.

Best practices like send patches first before you can commit are working in
other projects like STEM, too, but you shouldn't restrict it beyond that.
Else participation will suffer and you'll end up with an ill-fated single
person shop like Polarion with Subversive ;-)

Werner
Previous Topic:Logging in Scout Framework
Next Topic:Binding
Goto Forum:
  


Current Time: Mon Dec 09 20:56:36 GMT 2024

Powered by FUDForum. Page generated in 0.04672 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top