• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java web application which maintains a dedicated socket with a c++ daemon server  RSS feed

 
Abhishekk Gupta
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I need to create a Java web application which would have to fetch backend data through a dedicated socket connection made to C++ daemon server either directly or through a middle layer(to be designed again as a part of the web application backend support). The web based interface would allow the user to perform some actions by sending string commands through the socket to the server and also listen for synchronous and asynchrnous data and events from the server again through the socket . Is such an architecture feasible under technologies like Servlets and JSP ?
It would be really helpful for me to plan my project if I can get some inputs in this regards from you guys.

Thanks in advance
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, Java web apps can open connection to other machines; it doesn't matter what language the process on the other end is written in. If the connection is to be kept open beyond a single HTTP request, then a background thread would be the place to do this (as opposed to a request-handling servlet). JSPs would play no part in this.
 
Abhishekk Gupta
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulf,
Thanks for the quick reply.
Can you be a please elaborate on how to actually implement it or plan the design using some existing web frameworks.
How will the web application interact with the background thread which will provide a mediation service (dedicated).
 
Costi Ciudatu
Ranch Hand
Posts: 74
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can implement this with both servlets and even JSP. But this is not the kind of work that a servlet (not to mention JSP) is usually supposed to handle.

Try to consider having all this stuff hidden in some service component. At a minimum, keep all the logic that handles communication over the socket in one class that is used by the servlet.





One step further with the decoupling would be to define a "DataService" interface that would expose the getData() / sendCommand() /... methods and make the SocketConnector class implement that interface. The servlet will only make use of the interface (without knowing anything about the actual implementation, so that you will be able to change your business tier without touching the servlet): For this you can make use of some dependency injection container (Spring, EJB 3, ...) or simply have a factory method returning the actual implementation.




The above servlet in this case will look like this:



As you can see, your servlet doesn't even import the SocketConnector anymore, so you can switch the actual data provider without any modification required in your servlet. Just have the DataServiceFactory return some other implementation.

With a framework like Spring (and maybe making use of Spring MVC), you don't need the factory and you can simply "inject" your service into the controller.

 
Abhishekk Gupta
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Costi,

Thank you very much for the thorough reply . This plan certainly looks promising with regards to my requirements.
One more thing about which I was wondering and so I would ask the same.
Actually I was trying to port the client part of the existing client-server application to a web based client which is the need for today in the era of cloud computing where the customer does not want the overheads of installations.Currently different UI portions of the client have separate event listener threads to listen to events from the daemons in real time without any explicit request from the client which is then reflected in the client UI components.
How are we gonna achieve this vis-a-vis a web based client?
 
Costi Ciudatu
Ranch Hand
Posts: 74
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your servlet would need to benefit of the new "Comet" model / async support, so that it will simply push data to the clients as soon as it's available. Alternatively, the classical (but only "almost"-real-time) solution would be to poll the servlet via AJAX once every few seconds and see if anything has arrived. The servlet itself will simply register as an observer for the service I was talking about (that will handle both sync and async communication over the socket) so that it will be notified of any new messages and it will be able to push them (or serve them) to browsers.

For the business tier async communication you could also have a look at some JMS implementation and make use of a message queue, if you'll find this suitable.
 
Abhishekk Gupta
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Costi,
Thank you very much for your imputs. Even I came across the Comet programming model during my investigation but I found a lack of
online documentation on the same.
Anyways I'll be starting my rough prototype now and I'll be bugging you guys with more problems regarding this
 
Devaka Cooray
Marshal
Posts: 5569
716
Chrome Eclipse IDE Google App Engine IntelliJ IDE jQuery Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"chadhti Javani", please check your private messages regarding an important administrative matter.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!