Home » Archived » Eclipse Communications Framework (ECF) » explanation about the server role and the communication protocol
|
| Re: explanation about the server role and the communication protocol [message #606329 is a reply to message #606320] |
Sat, 08 July 2006 17:40   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ilaria,
Ilaria Manno wrote:
>
> We are studying ECF to use it as a framework to build a collaborative
> face to face problem solving application within the Lead project
> (http://lead2learning.org).
>
> We are analyzing the following plugins: - org.eclipse.ecf
> - org.eclipse.ecf.discovery
> - org.eclipse.ecf.collab
> - org.eclipse.ecf.presence
> - org.eclipse.ecf.provider
> - org.eclipse.ecf.ui
> and we are realizing (a draft of) a schema of the client server
> communication protocol.
Just to be clear, I expect that you are looking at the ECF 'generic'
client/server protocol...correct? (as different providers have their own
transport-level protocols, of course).
>
> From our initial study, it seems that the server receives messages from
> one client and forward them to the other connected clients in the
> bootstrap phase while other messages (such as awareness messages in the
> chat view "nickname IS ARRIVED") are directly exchanged among clients.
Yes. This example application is written as a singleton shared object
(with the ID "chat").
When the IContainer.connect call is made it initiates a connect sequence
with the server, and upon successful connection the server notifies all
participating containers of the membership change (i.e. new client
container).
Then once connected the "chat" shared object sends messages directly
between clients/peers to exchange information about chat participants,
send text messages for chat, send messages for other collab functions
(e.g. share URLs, etc).
In the case of this application ("chat"), the server has no replica of
the shared object, and so does not participate in the application
protocol...it simply passes through all of the messages (serves as a
message reflector).
>
>
> We would like to know if really exist messages that do not go through
> the server and if the server can read and manipulate the content of the
> messages (i.e., we need to log every exchanged message).
The messages *do* go through the server, but in this example application
they are not touched/logged/etc.
These messages *can* be read and manipulated, however, if the design of
your application requires it.
One way to do this, is to have a replica of the "chat" shared object run
on the server...and then have that replica receive all messages sent to
the other "chat" replicas (on clients)...and then log them, etc.
Although this allows/supports logging, it doesn't allow the server
"chat" replica to actually change the contents of the message...because
the server "chat" replica is just another receiver. But I'm not sure if
this is necessary based upon your requirements for 'read and manipulate'
above.
In any case, if sufficient this is simple to do...all that's necessary
is to modify the server so that it creates an appropriate instance of
the "chat" object...and that the code for that instance receives and
then logs the messages received.
>
> In addition, we would like to know if it is feasible to develop an our
> specific server and embed it the ecf framework.
Yes, of course. ECF's provider architecture allows you/anyone to create
new server and/clients and have them be accessed at runtime via:
IContainer container =
ContainerFactory.getDefault().createContainer(<your provider name here>);
These providers can then be setup to support as many of the ECF
'extension' APIs as desired...e.g. IChannelContainer (datashare),
IDiscoveryContainer (discovery), ISharedObjectContainer (shared
objects), IFileShareContainer (file sharing), ICallContainer, other APIs
yet to come...and/or be created by others.
Note that the ISharedObjectContainer API is currently supported by the
ECF generic provider (implemented in org.eclipse.ecf.provider), and the
JMS provider (available via http://ecf1.osuosl.org). The source is
available for both/either of these, and you can also use them as the
basis of your own servers/clients as well (by extending classes in
org.eclipse.ecf.provider.generic for example...or by extending the
classes in the JMS provider).
Hopefully this helps. Just let me know if you want specific pointers
into the generic provider code, into this example app shared object
implementations, etc. Since this is provider and example app code
rather than API code it's not had as much focus for documentation and
refactoring, etc. But at least it's open :)
>
> Many thanks in advance.
Sure. Thanks for questions.
Scott
|
|
|
| Re: explanation about the server role and the communication protocol [message #606337 is a reply to message #606329] |
Mon, 10 July 2006 10:23 |
Ilaria Manno
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Scott Lewis wrote:
> Hi Ilaria,
> Ilaria Manno wrote:
>>
>> We are studying ECF to use it as a framework to build a collaborative
>> face to face problem solving application within the Lead project
>> (http://lead2learning.org).
>>
>> We are analyzing the following plugins: - org.eclipse.ecf
>> - org.eclipse.ecf.discovery
>> - org.eclipse.ecf.collab
>> - org.eclipse.ecf.presence
>> - org.eclipse.ecf.provider
>> - org.eclipse.ecf.ui
>> and we are realizing (a draft of) a schema of the client server
>> communication protocol.
> Just to be clear, I expect that you are looking at the ECF 'generic'
> client/server protocol...correct? (as different providers have their own
> transport-level protocols, of course).
Yes.
>>
>> We would like to know if really exist messages that do not go through
>> the server and if the server can read and manipulate the content of the
>> messages (i.e., we need to log every exchanged message).
> The messages *do* go through the server, but in this example application
> they are not touched/logged/etc.
> These messages *can* be read and manipulated, however, if the design of
> your application requires it.
> One way to do this, is to have a replica of the "chat" shared object run
> on the server...and then have that replica receive all messages sent to
> the other "chat" replicas (on clients)...and then log them, etc.
> Although this allows/supports logging, it doesn't allow the server
> "chat" replica to actually change the contents of the message...because
> the server "chat" replica is just another receiver. But I'm not sure if
> this is necessary based upon your requirements for 'read and manipulate'
> above.
Really, we have thought of a dummy client to log, but we expect a solution
that allows to change the contents of the message, so we are thinking to
develop a our server.
however, we need to log messages details, such as
<10/09/06, 11.22 - Ilaria has said "bla bla bla">,
maybe in a more structured way :)
so, we would like to know how it is possible to access the content of the
message (the sender and the sent text for a chat application, for
example): so far we have accessed only serialized (i.e. unloggable for our
needs) information.
Many thanks.
|
|
|
| Re: explanation about the server role and the communication protocol [message #606342 is a reply to message #606337] |
Mon, 10 July 2006 14:40 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ilaria,
ilaria manno wrote:
> Scott Lewis wrote:
>
>> Hi Ilaria,
>
>> Ilaria Manno wrote:
>>>
>>> We are studying ECF to use it as a framework to build a collaborative
>>> face to face problem solving application within the Lead project
>>> (http://lead2learning.org).
>>>
>>> We are analyzing the following plugins: - org.eclipse.ecf
>>> - org.eclipse.ecf.discovery
>>> - org.eclipse.ecf.collab
>>> - org.eclipse.ecf.presence
>>> - org.eclipse.ecf.provider
>>> - org.eclipse.ecf.ui
>>> and we are realizing (a draft of) a schema of the client server
>>> communication protocol.
>
>> Just to be clear, I expect that you are looking at the ECF 'generic'
>> client/server protocol...correct? (as different providers have their
>> own transport-level protocols, of course).
>
> Yes.
>
>>>
>>> We would like to know if really exist messages that do not go through
>>> the server and if the server can read and manipulate the content of
>>> the messages (i.e., we need to log every exchanged message).
>
>> The messages *do* go through the server, but in this example
>> application they are not touched/logged/etc.
>
>> These messages *can* be read and manipulated, however, if the design
>> of your application requires it.
>
>> One way to do this, is to have a replica of the "chat" shared object
>> run on the server...and then have that replica receive all messages
>> sent to the other "chat" replicas (on clients)...and then log them,
>> etc. Although this allows/supports logging, it doesn't allow the
>> server "chat" replica to actually change the contents of the
>> message...because the server "chat" replica is just another receiver.
>> But I'm not sure if this is necessary based upon your requirements for
>> 'read and manipulate' above.
>
>
> Really, we have thought of a dummy client to log, but we expect a
> solution that allows to change the contents of the message, so we are
> thinking to develop a our server.
> however, we need to log messages details, such as <10/09/06, 11.22 -
> Ilaria has said "bla bla bla">,
> maybe in a more structured way :)
> so, we would like to know how it is possible to access the content of
> the message (the sender and the sent text for a chat application, for
> example): so far we have accessed only serialized (i.e. unloggable for
> our needs) information.
> Many thanks.
One way to go about this:
a) create an instance of an object with ID "chat" on the server (of
class org.eclipse.ecf.example.collab.share.EclipseCollabSharedObje ct)
b) This object will then receive text messages (via
EclipseCollabSharedObject.handleShowTextMsg and
EclipseCollabSharedObject.handleShowTextMsg) from the "chat" instances
(clients) that are sending messages to one another
c) Change the code in these methods (actually I would suggest that you
create a new class similar to EclipseCollabSharedObject) to log (if on
group manager/server or present on GUI...as they do now).
The idea here is just to create an instance of an object with ID "chat"
(or whatever you wish to call it) on the server that will be passed the
serialized shared object messages by the container...and then change the
server-side behavior (i.e. context.isGroupManager() returns true) so
that the handlers that get called when a text message is received result
in logging.
Ultimately it probably would work best if you were to create new shared
object classes...for both the server and the clients to do with as you
wish. Note that there is an extension point for adding sharedobject
classes, and creating them via a factory (its the
org.eclipse.ecf.sharedObjectFactory extension point).
Let me know if this is what you are looking for.
Thanks,
Scott
>
>
>
|
|
|
| |
  |
Goto Forum:
Current Time: Thu Apr 25 05:43:13 GMT 2024
Powered by FUDForum. Page generated in 0.03330 seconds |
] 
Search
Help
Register
Login
Home
