I'm writing my first client/server android app, and need an advice regarding server architecture.
My app is not a browser based app, but a stand alone client.
On server side i use hibernate/JPA and would like to transfer objects to client side.
What should I use:
Implement MVC- meaning writing servlets that will handle http requests (via Apache for example).
Write my own stand alone primitive server, meaning using simple sockets connection(in java for example), and handle each client in a different thread.
if you can think on a better way, you're more than welcome to share..
HTTP is definitly your choice since many carrier will block other protocols, since application servers/containers will take care of handling the multiple connexions and since it will also be a base if you decide to have a browser-based version some day ...
REST + JSON based webservices are well suited for android, given its simplicity, lightness and readability, but SOAP is also available via kSOAP2.
In my opinion. writing your own socket server is only warranted if you are required to implement your own wire protocol.
Most likely it's not a case for you.
So stick with http since it's widely adopted and has excellent client support in Android.
As for specific server side technology, you need to enumerate your requirements and do some research.
Don't start with Apache if plan to use Java, though. Pick Tomcat or Jetty. For framework, my personal choice would be Spring MVC.
Well, I have some experience in this very sphere and we used apache + php "covered" with nginx. I believe it's better to use standard approach, such Apache + PHP or Tomcat + servlets, cause it's easy to scale if needed and support... Of course it interesting to write your own application, but you might have some troubles with when traffic grows or server is down etc.
Related
There are some literature on the differences between WebSockets and sockets on Stackoverflow. What I'm trying to understand, is why would I pick web sockets over normal sockets, if I'm writing a normal client/server application, where the server is not necessarily a web server and the clients connecting to the server is a native C++ or a Java client.
There's a huge advantage to WebSockets if you have to deal with browsers, what if I don't have to support browsers, should I still consider using WebSockets?
Edit:
More clarity to what I'm asking: Had WebSockets existed much earlier, would it be appropreate to replace https://en.wikipedia.org/wiki/Unix_domain_socket with WebSocket in the unix tools that use Unix domain socket for instance, or any other context where sockets are used in an IPC context. Another case would be if you were to write an IRC server, would you it be appropriate to use WebSocket instead of the ordinary TCP socket, is there any reason to stay away from WebSocket in this case?
If you're comparing WebSockets to TCP, WebSockets have a number of advantages:
Unicode support
Datagram-oriented interactions
HTTP CONNECT-based firewall traversal
However, this comparison is a bit of a false dichotomy. If you don't use WebSockets, you're not forced to start building directly on TCP. There are many other protocols out there (too many to count) with many great implementations.
Perhaps HTTP itself is well-suited to your application. Or maybe XMPP or Google Protocol Buffers or something else. It all depends on what your application needs to communicate.
Before you can select a protocol (or, rarely, design your own), you need to figure out what kind of communication your application needs to do. Then you can evaluate different protocols and decide which fit your problem well.
That said, the majority of development these days seems to focus around the web. Even if there's nothing inherently web-y about the application, many people choose HTTP as their protocol now. At this point, a ton of work has gone in to standardizing the use of HTTP as the solution for a wide range of problems, as well as building libraries to facilitate this use. Chances are, whatever you're building, HTTP will be a decent fit (again, I don't know what you're building, so this is just a guess).
I have to deploy some Java servers in a bunch of different networks. For each server, I need to monitor its status and send it tasks to be executed in that specific server. Something like distributed workers.
This servers would be used from different platforms and languages so I need to find a way to communicate with them and obtain the needed information. Which is the best way to do this? I've been reading about use JSONs to communicate with my servers but I'm trying to figure out if there is a better approach.
Another solution could be to have a web dashboard and control all through web petitions but I prefer the servers to be standalone. Any ideas on what I can do?
At the moment I would suggest REST interfaces for your Java server. Since REST with Json is easy to implement in other languages too and you can even use HTML and JavaScript to write a Monitor client. So from my point of view this is the most flexible solution.
An other solution would be to use XMPP to "talk" with the server and "ask" them about there state. I remeber this as a solution for machine to machine communication, but this was before the Json and REST boom so I would not suggest to go with this.
When your other platforms consists of Java and C# mostly SOAP could also be a solution, since there are good code generator for both languages which can create the WSDL from code and vice versa. But its kinda difficult to use SOAP in JavaScript (as far as I experienced) and maybe other languages have the same problem with SOAP.
If multiple platforms are involved, web services are probably your best bet. You can have you java servers expose web services (for status and task execution) and you can call them from anywhere/any system.
I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
In my web-app, i need to push specific messages to my clients in real time. Web-sockets would be a good idea, but they don't work in IE, which should be supported as well.
Until recently we have been using StreamHub, but it's license has expired and the project itself seems to be dead. We also considered jWebSockets, but they seem a bit of overkill.
Again, all we need to do is to send messages from the server to specific clients as events happen on the server.
Could you recomend a lightweight, free and opensource solution for that?
Here's an opensource Java implementation of Socket.IO. It allows you to use Ajax mulitpart streaming to simulate WebSockets when your client doesn't support them. I've used it on projects in the past. It's horribly out of date with the most recent implementation of the WebSocket protocol, so if you plan on using WebSocket capable browsers in addition to IE, you'll have to update the source code to comply with the latest protocol. At one point I was researching a maintained replacement for Java Socket.IO and jWebSockets sounded like the way to go.
Take a look at the Atmosphere WebSocket/Comet library. I believe it can use long polling when WebSockets aren't supported.
I was looking for some opinions on the best remote method invocation practices when developing iPhone applications that communicate with Java (java EE) servers.
Many iphone applications these days typically talk to a server back end. I typically prefer to write my servers in java using some Spring libraries. So far I have not found or stuck to a definitive practice for iphone->java server communication.
What are some technical solutions and libraries that you have used to implement this kind of client-server communication?
One thing I always keep in mind is that I want the communication protocols to be simple so that multiple platforms can be added for example, in future adding Android and possibly Blackberry clients, that can use the same protocol to talk to the server.
I'd go with JSON. If you want to use Spring, go with restful webservices. Do some googling on "webservices restful spring json" (without the quotes) and you'll get some pointers.
JSON will suit you fine with other languages as well. I've written an iPhone application that uses JSON, and that was quite easy with the use of
http://code.google.com/p/json-framework. I'm pretty sure that both Android and Blackberry should be capable of reading JSON just fine as well.
Edit: I forgot to mention that I have put this iPhone application under an MIT license and you can browse the code on google code:
http://code.google.com/p/accountadmin/source/browse/#svn%2Ftrunk%2Fiphone%2FFrittRegnskap%2FClasses
I'm currently doing this for work as well. Our backend is Java EE (with Spring) and then of course the front end is iOS. We use JSON as the payload format, as Knubo suggested. All of our web services are also RESTful to make dealing with URL construction and authentication on the phone easier.
I would highly recommend you check out RestKit, which is a pretty comprehensive framework that allows you to easily integrate your RESTful, JSON-based web services with CoreData. We also use YAJL for parsing JSON manually in the rare cases where that is necessary.
Thus far, that tooling has made it a breeze to work with our web services.
http://code.google.com/p/json-framework is really useful.