| Weird ECF usage [message #601579] |
Tue, 11 April 2006 16:07  |
 Torsten Uhlmann
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I came across the ecf project and evaluate it for the next version of our monitoring software. The usage scenario is a bit weird or unusual in terms that it does not necessarily fit into the described ecf use cases.
Please allow me to describe our application as it is now and the changes we have planned. I'd like to hear your comments and suggestions (but I understand you are very busy...)
The software is called 'Net-Herald'- it's a monitoring and controlling application for arbitrary observed devices (more on this later).
The application consists of a plain Java 1.5 server based on Spring and an Eclipse client. Both use JMX to communicate. The client uses GEF to display the status for the different observed devices (like a water tank in the field, a pump, if a door is locked and that kind of stuff).
The signals of those devices arrive either over a tcp socket connection, as an SMS from GSM devices or through XMPP (as of now). The server takes the signals, converts them to a unified internal structure, and hands them to other components for further processing. The server must be able to send SMS, Jabber messages, call a telephone line (either CAPI, SIP or IAX- I don't yet know) or send data through the tcp socket connection.
I also might replace the JMX client-server connection by using the ecf framework for this.
So my question boils down to is ecf the right framework for this? For all communication purposes except the client-server (former JMX) part the Java server is just a listener. So for my understanding this is done by building providers for the different protocol types.
I don't yet understand if it is a good idea to replace the JMX connection with ecf- most probably because of my lack of understanding for ecf.
Also as another minor detail I'm planning to replace the Spring Java server part with a headless Eclipse server. This way I can build on my Eclipse knowledge I already have and can build application parts using the same principles.
I'd like to hear your comments on these plans.
Thanks you very much,
Torsten.
|
|
|
| Re: Weird ECF usage [message #601588 is a reply to message #601579] |
Wed, 12 April 2006 03:30  |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Torsten,
Torsten Uhlmann wrote:
> Hi all,
>
> I came across the ecf project and evaluate it for the next version of our monitoring software. The usage scenario is a bit weird or unusual in terms that it does not necessarily fit into the described ecf use cases.
>
> Please allow me to describe our application as it is now and the changes we have planned. I'd like to hear your comments and suggestions (but I understand you are very busy...)
>
> The software is called 'Net-Herald'- it's a monitoring and controlling application for arbitrary observed devices (more on this later).
>
> The application consists of a plain Java 1.5 server based on Spring and an Eclipse client. Both use JMX to communicate. The client uses GEF to display the status for the different observed devices (like a water tank in the field, a pump, if a door is locked and that kind of stuff).
>
> The signals of those devices arrive either over a tcp socket connection, as an SMS from GSM devices or through XMPP (as of now). The server takes the signals, converts them to a unified internal structure, and hands them to other components for further processing. The server must be able to send SMS, Jabber messages, call a telephone line (either CAPI, SIP or IAX- I don't yet know) or send data through the tcp socket connection.
>
> I also might replace the JMX client-server connection by using the ecf framework for this.
>
> So my question boils down to is ecf the right framework for this? For all communication purposes except the client-server (former JMX) part the Java server is just a listener. So for my understanding this is done by building providers for the different protocol types.
Yes, that's right. We already have a provider for XMPP, JMS, a basic
tcp socket connection, IRC, zeroconf/bonjour discovery, and are
anticipating working on a SIP provider as well. It would be very nice
to have an SMS provider also...although we haven't been able to
implement one yet.
>
> I don't yet understand if it is a good idea to replace the JMX connection with ecf- most probably because of my lack of understanding for ecf.
Your application sounds somewhat similar to the application that the
Compuware team demonstrated using the Corona prototype
(http://www.eclipse.org/proposals/corona/). They used a server as a hub
for collecting data about other processes (from a variety of hardware
devices I think), and then they used ECF to distribute the
server-collated events to Eclipse-based clients for notification and
presentation.
>
> Also as another minor detail I'm planning to replace the Spring Java server part with a headless Eclipse server. This way I can build on my Eclipse knowledge I already have and can build application parts using the same principles.
One thought/suggestion: You might want to use the Equinox incubator
'Embedding OSGI in servlet container' work:
http://www.eclipse.org/equinox/incubator/server/embedding_in _a_servlet_container.php
ECF is currently using this servlet container (using tomcat) to run our
ECF 'generic server'...as a bundle/plugin. Equinox/OSGI on servers is
one of the 'hot' areas of Eclipse right now (IMHO), and with ECF this
makes the creation of multiprotocol servers rather easy. Further the
ECF providers can be used without modification in an Eclipse/Eclipse
RCP/OSGI-on-server environments very easily.
>
> I'd like to hear your comments on these plans.
It sounds like ECF could meet your needs here...with a couple of
providers like XMPP, JMS, maybe the ECF generic server, SIP, etc. It
is, fundamentally just a set of Eclipse/OSGI-based APIs for doing group
messaging.
>
> Thanks you very much,
Sure. Hope this helps. Please let us know if we can be of assistance, etc.
Scott
|
|
|
|
Powered by
FUDForum. Page generated in 0.02906 seconds
] 
Search
Help
Register
Login
Home
