Ok, so we made a bit of progress. More answers inline.
Hadrian
On 11/14/2011 09:51 PM, newbiee wrote:
Thank you very much to all for your time and valuable feedback.
Let me answer the questions that have been asked:
Q. does the server know in advance the IP address of each digi device? Are
they static?
A. IP addresses are dynamic. Digi device has Connect ware manager through
which the IP address are registered and device is maintained. DNS server
will be used to pull the IP address.
Good, dynamic addresses are ok, DNS is ok. However, you need to know the
host names then, right? How do you know those?
The nugget above points to a dynamic router [1], probably a routing slip
[2] as being part of the solution.
I don't have any code yet. We need to write the code. Since I am learning
CAMEL (as part of my MSc degree) and to some extent have felt it's power, I
want to introduce it at my job place therefore, I am trying to find if CAMEL
can be used in this project.
It probably can :).
I will need to write a client program that will send commands to digi
devices. digi devices will respond back with the message. My program will
need to send commands to digi devices every 15 minutes.
Good. Now a good practice, which is actually extremely easy with Camel
is to mock your endpoints. That is you can test your logic *without*
talking to the *real* digis, but to some endpoints that (ideally) use
the same message formats. You can also test your 'occasionally
connected' scenarios. That would also be a great learning opportunity
for you (in terms of how Camel works).
Q: is it ok for the digi gadgets to contact the 'home' central dispatcher?
A. I also thought this approach, but the problem is that not all digi
devices are up all the time. (all trucks are not on all the time, digi
device is up if the truck is turned on). I was thinking may be we can write
python script and push it to digi device, but since digi device will not be
up all the time, it will be maintenace issue if we push the code on digi
device and let digi device send the data to offboard.
I don't want to debate this with you :), but I don't quite agree. If
there is no connection it doesn't matter who initiates it. You can use
Camel for instance to push your new 'firmware' of sorts (python scripts,
whatever) once and then let them try to connect. Whenever a collection
is established you'll get new data pushed by the digi. It's no better
nor worse than 'home' calling the digis and imho it'll scale better.
That would be my choice, but it doesn't matter much, both approaches work.
Therefore, I have said I will need to write a client program and open the
socket connection. So, my offboard program will be client and the digi
device will the the server. My client program will be sending command to
many trucks every 15 minutes. Following application level protocols are
allowed in my network:
Just to make sure I got this right. I am not sure what exactly you mean
by 'client program'. Camel should be your client program and it can do
what you describe with very little code (if any).
Now that's the Camel thing you should understand. You don't need to open
a socket explicitly, Camel will do that for you. This is one of the main
reasons why Camel is more powerful and interesting than other
integration frameworks, it abstracts the underlying protocols for you.
The only thing you need is to use either camel-http (if you use https),
or camel-netty or camel-mina if you prefer raw IP connections, or
camel-ftp if you want to use camel-ftp (but that sounds kinda odd to
me). From your description, if I were to choose, I would go with https
(and use camel-http).
Then you need to know the format of the message (both request and
reply). Is it already enforced by those who wrote the code on the digi
or is something for you to define? At this point this is the most
important question you need to answer. So how does the message you send
look like, and what's the content of the response?
If something above is not clear, please ask. Hopefully the answers will
be useful to other Camel users.
Cheers,
Hadrian
[1] http://camel.apache.org/dynamic-router.html
[2] http://camel.apache.org/routing-slip.html
