| Multiple protocols, same shared object? [message #603995] |
Mon, 05 June 2006 09:07  |
 Roland Tepp
Messages: 336
Registered: July 2009 |
Senior Member |
|
|
Hello,
First off, I must admit, that i don't know a whole lot about ECF, so my
questions might be really naive.
I am building an RCP application for monitoring and controlling remote
devices that are essentially special purpose computers.
These devices communicate with a central server using their own binary
protocol. For speed and networking reasons they also send some
information directly to my monitoring application using the same
protocol. This only applies however in cases when both monitoring
application and the device reside in a same subnet. If monitoring
application is in another subnet, the monitoring application subscribes
to JMS instead to get same information regardless of its location.
Currently this choice is made on the deployment level, where certain
version of the monitoring application uses direct communication with
devices and another uses JMS (different plug-ins).
My question is basically that if ECF allows some sort of automagical
protocol fallback mechanics for shared objects?
So that for example, when direct connection has been made, the online
data will be collected from direct link, but if there is no direct link
(either connection has been lost or the direct connection is not
available for some reason), the JMS (or any other protocol for that
matter) takes over...
--
Roland Tepp
|
|
|
| Re: Multiple protocols, same shared object? [message #603998 is a reply to message #603995] |
Mon, 05 June 2006 19:22  |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Roland,
Roland Tepp wrote:
> Hello,
>
> First off, I must admit, that i don't know a whole lot about ECF, so my
> questions might be really naive.
No problem! More questions are better...we'll do all we can to answer them.
>
> I am building an RCP application for monitoring and controlling remote
> devices that are essentially special purpose computers.
>
> These devices communicate with a central server using their own binary
> protocol. For speed and networking reasons they also send some
> information directly to my monitoring application using the same
> protocol. This only applies however in cases when both monitoring
> application and the device reside in a same subnet. If monitoring
> application is in another subnet, the monitoring application subscribes
> to JMS instead to get same information regardless of its location.
>
> Currently this choice is made on the deployment level, where certain
> version of the monitoring application uses direct communication with
> devices and another uses JMS (different plug-ins).
>
> My question is basically that if ECF allows some sort of automagical
> protocol fallback mechanics for shared objects?
I wouldn't refer to it as automagical :), but yes...it does
allow/support the use of multiple protocols *underneath* the shared
object abstraction.
>
> So that for example, when direct connection has been made, the online
> data will be collected from direct link, but if there is no direct link
> (either connection has been lost or the direct connection is not
> available for some reason), the JMS (or any other protocol for that
> matter) takes over...
This use case is well supported by ECF. Here's a brief explanation of
why/how:
The basic ECF abstraction (IContainer) defines session connect
semantics. The case above could be accomodated like this (psuedo code):
IContainer primary = createAndSetupDirectContainer();
try {
primary.connect(targetDirectConnectID,null);
} catch (ContainerConnectException e) {
// If the primary can't connect, then
// Setup JMS
primary = createAndSetupJMSContainer();
primary.connect(targetJMSConnectID,null);
}
The notion would be that in *both* container setup cases (i.e.
createAndSetupDirectContainer(), and createAndSetupJMSContainer()) the
provider would be queried for support of the ISharedObjectContainer
abstraction...e.g.
ISharedObjectContainer soContainer = (ISharedObjectContainer)
container.getAdapter(ISharedObjectContainer.class);
and then the shared object that implements your custom protocol would be
added to the direct and the JMS container in a similar/same manner via
the ISharedObjectContainer:
MyProtocolSharedObject sharedObject = new MyProtocolSharedObject();
soContainer.getSharedObjectManager().addSharedObject(sharedO bjectID,sharedObject,null);
In this way, all of your custom protocol implementation (i.e. the
app-level sending/receiving of private messages) would be handled in the
MyProtocolSharedObject code...and would be reused/reusable in
either/both contexts (via direct or jms providers).
In general, I believe this is one of the most valuable/useful features
of the ISharedObjectContainer/ISharedObject API...to be able to have
custom protocol implemented through an open API
(ISharedObjectContainer/ISharedObject) above an ECF provider protocol
implementation that supports that API (i.e. returns non-null in response
to container.getAdapter(ISharedObjectContainer.class)).
BTW, current provider implementations of the ISharedObjectContainer API
exist for the following providers:
ECF generic (pub/sub)
JMS (pub/sub)
XMPP (pt-to-pt only...currently)
I expect there will be more/others though...hopefully other folks will
also consider implementing their own providers as well.
Thanks...hope this answers your question.
Scott
|
|
|
Powered by
FUDForum. Page generated in 0.02945 seconds
] 
Search
Help
Register
Login
Home
