|
| Re: ECF WebSocket provider [message #1219225 is a reply to message #1219217] |
Mon, 02 December 2013 18:09   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
[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.
|
|
|
|
| Re: ECF WebSocket provider [message #1219424 is a reply to message #1219331] |
Tue, 03 December 2013 18:37 |
Eclipse User |
|
|
|
On 12/03/2013 12:36 PM, Maxim Petrov wrote:
>
> I even think that I can "copy-pase" bunch of code from existing classes.
> What do you think?
Would you be willing to open source such a provider?
Thanks
Markus
|
|
|
|
|
| Re: ECF WebSocket provider [message #1219574 is a reply to message #1219536] |
Wed, 04 December 2013 16:11 |
| Eclipse User |
|
|
|
On 12/04/2013 02:40 PM, Maxim Petrov wrote:
> Yes, as soon as we create some working model, we publish our code and
> make it open.
It is up to you, but I'd like to encourage you to push it to Bitbucket
or Github right from the start. You will get feedback earlier if we can
see your code.
Thanks
Markus
|
|
|
|
| Re: ECF WebSocket provider [message #1219970 is a reply to message #1219948] |
Sat, 07 December 2013 17:15 |
| Eclipse User |
|
|
|
On 12/07/2013 09:49 AM, Maxim Petrov wrote:
> Please review!
> github.com/videonext/ECF-WebSocket
>
> Our WebSocket implementation is based on the Jetty and can work in the
> embedded Jetty instance (see examples) or in the standalone instance we
> actually used. RSA and Discovery work. Distributed Event Admin I did not
> test, but I think it should work out of the box, because SO API was
> fully reused.
Hi Maxim,
I had a glance at the code (haven't run it yet), but assuming you are
willing to contribute it to ECF, you will have to adapt the license
headers. Right now it says 2004 Composent inc. when most of the
copyright should be yours.
M.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04835 seconds
] 
Search
Help
Register
Login
Home
.