I am developing a chat website that makes use of the Openfire XMPP server, with the client side using Smack API. The web project that makes use of the Smack API is implemented using the Play! framework making it RESTful. I chose Play! because of its Asynchronous Programming offerings (Comet Sockets/WebSockets).
Basically, my architecture, so far, is like below:
Openfire <-> Webserver <-> User/Browser.
In order to support Android devices too, and to maximize code-reuse, should I implement the XMPP client side code as a RESTful webservice that is common for both the web site and the Android clients?
Openfire <-> Webservice <-> Website <-> Browser/User.
Openfire <-> Webservice <-> Android App.
I’m afraid of scalability issues, because of the introduction of an intermediate web service? Would I be introducing latency in the communication as a result of having to go through multiple components?
Any advice on the above would be helpful. Thanks.
The key to scalability is decoupling. So in an essence you can think of the problem in terms of “If one of the components fail, will the other components continue to work normally?”. In addition to avoiding end of the world scenarios you can also independently scale horizontally each component.
With that in mind lets now move on to your specific use case. Layers for the sake of layers are what still make me see nightmares about some Java EE architectures around. Not only does it introduce unnecessary latency, it also makes it harder to pinpoint a problem. If your service fails, was the failure caused by the web server, android application or the web service?
If you want code reuse, reuse code instead of duplicating components. That`s what libraries are for. Take your common code and extract as a library and use it in both the web server and Android application.