Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Simple Client Server Example?
Simple Client Server Example? [message #624323] Mon, 03 November 2008 14:06 Go to next message
Philip Quitslund is currently offline Philip Quitslund
Messages: 24
Registered: July 2009
Junior Member
Hey all,

I've been intrigued by ECF for a while so I was delighted when I found an excuse
to dig in. I poked around in the docs but probably missed the obvious.
(Forgive me for that!) Anyway, I'm looking at implementing a basic client
server protocol to support simple communication between two OSGi/Equinox app
instances. The protocol will be dead simple (essentially just a way to send
remote commands). Is there an example of something like this that I've overlooked?

Here's a sketch of a use case:

* Machine A (the client) wants to send a command to another machine
* Machine A discovers available (server) machines, finding Machine B
* Machine A sends a command request to Machine B
* Machine B receives the command and consumes it
* Machine B responds when it has completed the request

Is there an ECF "Hello World" or test case that approximates something like this?

BTW, if there isn't such a thing (and there's sufficient interest), I'd be happy
to contribute back whatever I get working.

Thanks in advance for any pointers!


-phil
Re: Simple Client Server Example? [message #624324 is a reply to message #624323] Mon, 03 November 2008 15:26 Go to previous messageGo to next message
Scott Lewis is currently offline Scott Lewis
Messages: 966
Registered: July 2009
Senior Member
Hi Phil,

Philip Quitslund wrote:
> Hey all,
>
> I've been intrigued by ECF for a while so I was delighted when I found
> an excuse to dig in. I poked around in the docs but probably missed the
> obvious. (Forgive me for that!) Anyway, I'm looking at implementing a
> basic client server protocol to support simple communication between two
> OSGi/Equinox app instances. The protocol will be dead simple
> (essentially just a way to send remote commands). Is there an example
> of something like this that I've overlooked?


Well, there are several examples of different use cases...but none which
*exactly* match yours (which is good!).

So I have one question to ask about 'sending remote commands'. Do you
want to have your own infrastructure for sending and interpreting the
commands, or would you rather use an RPC/remote service approach?
Reason I ask...ECF has support for both

1) sending arbitrary messages (strings, ints, etc) over a messaging
channel (via datashare API)
2) synchronously and/or asynchronously executing remote methods/services
(remote services).

So if by sending remote commands you mean sending (say) a fixed set of
strings that identify what the receiver should do...and then receiving
the command, interpreting it (by running the appropriate blocks of code
and responding) then '1' would probably be best. If you want support
for proxys, mapping requests to method calls, marshaling/unmarshaling
parameters, calling synchronously/blocking and/or asynchronously, then
'2' would be more helpful.

>
> Here's a sketch of a use case:
>
> * Machine A (the client) wants to send a command to another machine
> * Machine A discovers available (server) machines, finding Machine B


ECF has a discovery API...so if you want the clients to discover via
(LAN-or-WAN-based) discovery, then you can/could use the ECF discovery
API (there are example apps and test code that use the discovery API to
discover external processes of a certain type (i.e. those that
understand your protocol).

But I'm not sure if you want all this for this example/your app...that
is...perhaps you don't want to do network discovery...and if not then
you can have other ways to 'discover' servers/services (e.g. consulting
centralized/web registry, etc).

So it sounds like this (dynamic network discovery or not) is another
design choice point for your app (i.e. network discovery or not).

> * Machine A sends a command request to Machine B
> * Machine B receives the command and consumes it
> * Machine B responds when it has completed the request
>
> Is there an ECF "Hello World" or test case that approximates something
> like this?

There is some test code for the datashare API that is very much like
this. That is, all that happens is that an IChannel is created (with a
specific, unique name), a sender sends a String/command to the other
side, and the other side simply prints out that it received it (rather
than responding).

This code is in org.eclipse.ecf.tests.datashare.ChannelTest...which is
here [1]. Note that there is a fair amount of support code in the
ContainerAbstractTestCase, which is in org.eclipse.ecf.tests project.
But the basic operation of sending a message (String converted to byte[]
is in ChannelTest.testSender().

Also note that the docshare real-time shared editing is built over the
datashare API (i.e. '1' above). So if you want a more complicated
example of sending/receiving messages (in this case serialized objects)
using datashare, then that code is in org.eclipse.ecf.docshare.DocShare
class, which in viewcvs is here [2].

There are also examples of using remote services API in the following
bundles (in /cvsroot/rt
org.eclipse.ecf/server-side/examples/bundles/org.eclipse.ecf .examples.remoteservices.client
org.eclipse.ecf/server-side/examples/bundles/org.eclipse.ecf .examples.remoteservices.common
org.eclipse.ecf/server-side/examples/bundles/org.eclipse.ecf .examples.remoteservices.server
).

This example code also uses the discovery API to publish and dynamically
discover remote services.

>
> BTW, if there isn't such a thing (and there's sufficient interest), I'd
> be happy to contribute back whatever I get working.

That would be great. If you are willing, I will offer to help with the
development given that it can be contributed back.

Thanks,

Scott

[1]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tes ts/bundles/org.eclipse.ecf.tests.datashare/src/org/eclipse/e cf/tests/datashare/?root=RT_Project

[2]
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/fra mework/bundles/org.eclipse.ecf.docshare/src/org/eclipse/ecf/ internal/provisional/docshare/DocShare.java?root=RT_Project& amp;view=log
Re: Simple Client Server Example? [message #624325 is a reply to message #624324] Mon, 03 November 2008 16:54 Go to previous messageGo to next message
Philip Quitslund is currently offline Philip Quitslund
Messages: 24
Registered: July 2009
Junior Member
Hey Scott,

Thanks for the response! Responses below:

>> I've been intrigued by ECF for a while so I was delighted when I found
>> an excuse to dig in. I poked around in the docs but probably missed
>> the obvious. (Forgive me for that!) Anyway, I'm looking at
>> implementing a basic client server protocol to support simple
>> communication between two OSGi/Equinox app instances. The protocol
>> will be dead simple (essentially just a way to send remote commands).
>> Is there an example of something like this that I've overlooked?
>
>
> Well, there are several examples of different use cases...but none which
> *exactly* match yours (which is good!).
>
> So I have one question to ask about 'sending remote commands'. Do you
> want to have your own infrastructure for sending and interpreting the
> commands, or would you rather use an RPC/remote service approach? Reason
> I ask...ECF has support for both
>
> 1) sending arbitrary messages (strings, ints, etc) over a messaging
> channel (via datashare API)
> 2) synchronously and/or asynchronously executing remote methods/services
> (remote services).
>
> So if by sending remote commands you mean sending (say) a fixed set of
> strings that identify what the receiver should do...and then receiving
> the command, interpreting it (by running the appropriate blocks of code
> and responding) then '1' would probably be best. If you want support
> for proxys, mapping requests to method calls, marshaling/unmarshaling
> parameters, calling synchronously/blocking and/or asynchronously, then
> '2' would be more helpful.

For my purposes, I think '1' would suffice.

>>
>> Here's a sketch of a use case:
>>
>> * Machine A (the client) wants to send a command to another machine
>> * Machine A discovers available (server) machines, finding Machine B
>
>
> ECF has a discovery API...so if you want the clients to discover via
> (LAN-or-WAN-based) discovery, then you can/could use the ECF discovery
> API (there are example apps and test code that use the discovery API to
> discover external processes of a certain type (i.e. those that
> understand your protocol).
>
> But I'm not sure if you want all this for this example/your app...that
> is...perhaps you don't want to do network discovery...and if not then
> you can have other ways to 'discover' servers/services (e.g. consulting
> centralized/web registry, etc).
>
> So it sounds like this (dynamic network discovery or not) is another
> design choice point for your app (i.e. network discovery or not).

Ultimately I do want dynamic network discovery.

>> * Machine A sends a command request to Machine B
>> * Machine B receives the command and consumes it
>> * Machine B responds when it has completed the request
>>
>> Is there an ECF "Hello World" or test case that approximates something
>> like this?
>
> There is some test code for the datashare API that is very much like
> this. That is, all that happens is that an IChannel is created (with a
> specific, unique name), a sender sends a String/command to the other
> side, and the other side simply prints out that it received it (rather
> than responding).
>
> This code is in org.eclipse.ecf.tests.datashare.ChannelTest...which is
> here [1]. Note that there is a fair amount of support code in the
> ContainerAbstractTestCase, which is in org.eclipse.ecf.tests project.
> But the basic operation of sending a message (String converted to byte[]
> is in ChannelTest.testSender().

Perfect. I'll look at this example.

> Also note that the docshare real-time shared editing is built over the
> datashare API (i.e. '1' above). So if you want a more complicated
> example of sending/receiving messages (in this case serialized objects)
> using datashare, then that code is in org.eclipse.ecf.docshare.DocShare
> class, which in viewcvs is here [2].

Great. Thanks!

> There are also examples of using remote services API in the following
> bundles (in /cvsroot/rt
> org.eclipse.ecf/server-side/examples/bundles/org.eclipse.ecf .examples.remoteservices.client
>
> org.eclipse.ecf/server-side/examples/bundles/org.eclipse.ecf .examples.remoteservices.common
>
> org.eclipse.ecf/server-side/examples/bundles/org.eclipse.ecf .examples.remoteservices.server
>
> ).
>
> This example code also uses the discovery API to publish and dynamically
> discover remote services.

Good deal. I'll take a look.

>
>>
>> BTW, if there isn't such a thing (and there's sufficient interest),
>> I'd be happy to contribute back whatever I get working.
>
> That would be great. If you are willing, I will offer to help with the
> development given that it can be contributed back.

I'm willing. Like everyone, pulled in lots of directions at once, but
definitely keen to give back.

I'll let you know where I get and we'll go from there.

Many thanks!


-phil
Re: Simple Client Server Example? [message #624327 is a reply to message #624324] Thu, 06 November 2008 11:02 Go to previous message
Oliver Wong is currently offline Oliver Wong
Messages: 47
Registered: July 2009
Member
Scott Lewis wrote:
>
> ECF has a discovery API...so if you want the clients to discover via
> (LAN-or-WAN-based) discovery, then you can/could use the ECF discovery
> API (there are example apps and test code that use the discovery API to
> discover external processes of a certain type (i.e. those that
> understand your protocol).
>
> But I'm not sure if you want all this for this example/your app...that
> is...perhaps you don't want to do network discovery...and if not then
> you can have other ways to 'discover' servers/services (e.g. consulting
> centralized/web registry, etc).

Are there any examples of consulting a centralized registry, or just
directly hardcoding a connection string for particular services?
Previous Topic:Can ecf.provider.jms support Cola/DocShare?
Next Topic:FTP API in eclipse?
Goto Forum:
  


Current Time: Tue Jul 29 02:39:51 EDT 2014

Powered by FUDForum. Page generated in 0.02185 seconds