| ECF WebSocket provider [message #1219217] |
Mon, 02 December 2013 11:40  |
Eclipse User |
|
|
|
We tried to use "Generic Container" and were fully satisfied, because it give us automatic discovery, RSA and EventAdmin. But our domain security does not allow us to open additional TCP ports on the server side. And all communication between client and server should be passed only over HTTPS.
There is REST container and also I saw SOAP examples, but they don't give us discovery and EventAdmin out of the box.
Therefore we are thinking of replacing TCP implementation used by "Generic Container" to WebSocket. Could you recommend us right way for this extension?
|
|
|
| Re: ECF WebSocket provider [message #1219225 is a reply to message #1219217] |
Mon, 02 December 2013 13:09  |
| Eclipse User |
|
|
|
[quote title=Maxim Petrov wrote on Mon, 02 December 2013 11:40]We tried to use "Generic Container" and were fully satisfied, because it give us automatic discovery, RSA and EventAdmin. But our domain security does not allow us to open additional TCP ports on the server side. And all communication between client and server should be passed only over HTTPS.
There is REST container and also I saw SOAP examples, but they don't give us discovery and EventAdmin out of the box.
/quote]
Although you are correct about EventAdmin (not available with REST and SOAP providers)...with the use of OSGi Remote Services you should be able to use whatever discovery provider that you wish.
Quote:
Therefore we are thinking of replacing TCP implementation used by "Generic Container" to WebSocket. Could you recommend us right way for this extension?
Coincidently, I (Scott) have been contemplating a WebSocket-based provider for some time...just not had the time nor driving use case to complete it.
I can quickly think of three ways to go about this technically:
1) Create a websocket provider implementation and implement these APIs from 'scratch': IContainer, IRemoteServiceContainerAdapter, EventAdmin
2) Create a websocket provider implementation based upon the ECF 'shared object' API...and extend/use the the ECF generic provider as a base. This would probably involve extending classes like ClientSOContainer and ServerSOContainer from the generic provider, and implementing ISynchAsyncConnection API...based upon websocket of course. The advantage of doing things this way would be that essentially no work would be required to get the implementations of IRemoteServiceContainerAdapter and EventAdmin, because for the generic provider these two APIs are already implemented as 'shared objects' (which depend upon a container that implements the shared object API).
3) Create a websocket provider implementation based upon the JMS provider. This is essentially a variant of '2', ans the JMS provider takes the strategy described by '2'...and so allows the reuse of IRemoteServiceContainerAdapter and EventAdmin for any container implementations based upon it as well. This is what I recently did for the MQTT protocol...i.e. see:
https://github.com/ECF/Mqtt-Provider
and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=420896
The MQTT provider only took me a week to create...using strategy '3'.
Personally, I would be inclined to do '2' or '3' for a websocket-based provider...but the difficulty of doing that is that detailed knowledge of the shared object API and the JMS provider code is very important to be able to do these correctly. Also...thee '2' or '3' strategy does reuse existing code...and so possibly would pull in functionality which wouldn't be needed/desired (although you've already stated above that you apparently want both remote services and distributed EventAdmin support).
One option: I can/could possibly setup a contractual relationship with you to quickly create such a provider...in open source or not...depending upon your/your company's approach. I could be available for such a thing during December 2013, and would welcome the opportunity to develop it...either in the open/for more general consumption...or for your company only. Since I designed and implemented both the shared object API, and the JMS provider...as well as most of the OSGi RS/RSA impl...I believe I could create a websocket provider (i.e. using '2' or '3') very quickly (e.g. less than one month). If you would like to discuss this possibility directly, please contact me via email at: slewis at composent.com .
Another option: you open a bug/enhancement for ECF team and wait for an existing committer to take on the job. It might, however, take some time as ECF committers are unfortunately rather busy these days with other projects, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05979 seconds
Home
.