| Proposal Feedback [message #523274] |
Thu, 25 March 2010 18:00  |
 Martin Lippert
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 #523991 is a reply to message #523274] |
Tue, 30 March 2010 08:35  |
Ivan Motsch
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 |
Matthias Zimmermann
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 API [message #525680 is a reply to message #523274] |
Wed, 07 April 2010 12:56 |
Eclipse User |
|
|
|
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?
>
>
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03594 seconds
] 
Search
Help
Register
Login
Home
