Develop Reference

Server-Side design options for mobile application

I am new to mobile application development and wanted to know from experts here on how they approach the server-side design. I need to support cross platform clients (iOS, Android, Windows) and require a scalable backend architecture.
What are the widely deployed server-side strategies
Are there any Mobile specific open source server-side technologies available.
What factors people consider for mobile application back-end.

I agree with half the answer above. You should use REST architecture - it is the most straightforward way to go. I use Ruby on Rails for my mobile projects. It is quick to start building the server code and see it working in somewhere like heroku.com almost instantly.
So I'd pick the following:
ruby on rails - worth your time picking up
heroku.com for deploying / or EC2 if you pick the Rubber gem
Google App Engine is another great option if you know some python / java
REST architecture
store all your heavy images etc with Amazon S3. They have some great SDKs to work with.
get yourself some JSON libraries to communicate with your server
on iOS:
use MKNetwokKit (it will save you lots of trouble down the road. it helps you cache and its a nice architecture all around).
if the app is small, try a data model based on NSArchiver instead of CoreData (SLOWWW). Mogenerator is a good start (this isn't server related..)
If you hate writing server side, I'd advice you to checkout Parse.com. Completely mobile only development with all server code handled for you. For big projects, you really should write your own server stuff.
Some extra things I'd consider:
how would the security work? just a session token in the HTTP header?
tier your app -- networking / MVC
what happens when you're offline? - this is currently something we're dealing with after not having thought early - pain.

I've had good success with creating a server using REST web services and XML data, but would recommend JSON instead. You can create this using Java and host it using Tomcat. This is widely deployed and widely consumable by multiple mobile and even non-mobile technologies.
A couple of factors to consider:
* You'll probably want it in a DMZ and being Internet accessible so think about firewalls, reverse proxies, and encryption via SSL.
* Will you host the server or sell the server to customers? Hosting is easy. If selling, there are many more considerations.

Kaazing vs jWebsocket

Can somebody please compare these two websocket servers. I have to select one of them; I need an expert opinion due to newbie in multiplayer "online" gaming. I would probably have the flash client. What challenges I could face using one over other.
thanks in advance.

Full disclosure: I work for Kaazing and I have not used jWebSocket myself.
A couple of quick points:
0) Production vs. Beta
Kaazing is production-quality software. The download link on the jWebSocket web page points me to a beta version of the product.
1) Client Technologies
Kaazing provides WebSocket libraries for multiple client technologies (JavaScript, Java, .NET/Silverlight, and Flash), It looks like jWebSocket provides JavaScript and Java. You mention you would need a Flash client and AFAIK only Kaazing provides that. jWebSocket uses Flash for emulation (see the next point).
Note: Kaazing now provides AngularJS, ReactJS, Objective-C (iOS), Xamarin (.NET with support for iOS and Android), Java, .NET, and Android clients. However support for SilverLight and Flash have been deprecated.
2) Emulation (for browsers that do not support WebSocket)
jWebSocket requires Flash, Kaazing does not.
Note that Flash emulation for secure WebSocket (wss://) requires you to open a separate port for the Flash x-domain policy file. In many enterprises this is a non-starter.
3) Protocol Support
Kaazing offers a wide range of higher-level protocols on top of WebSocket: JMS (can run against any back-end JMS message broker), STOMP, AMQP, XMPP, etc. I don't know what jWebSocket does in this space.
4) Enterprise Deployment
It is easy to configure the Kaazing WebSocket Gateway in conjunction with existing Directory services (LDAP). It supports Single Sign-On, and the gateway can easily be clustered for HA purposes (again, not quite sure what jWebSocket does here.)
Please take a look at the documentation for these features:
Security configuration:
Using the Gateway to Support High Availability
Secure Network Traffic with the Gateway
5) Open Source
jWebSocket is open source, Kaazing has both an open source Community Edition and an Enterprise Edition.
Hope this helps for now!

I am a jWebSocket developer, we are currently working in the first production version of jWebSocket, I will just mention some advantages of jWebSocket:
- Multiple clients ( JavaScript, C#, Java OS, BlackBerry, Android, GWT(In process), and some others ).
- Multiple WebSocket engines, just switch and run in the configuration, among them (Grizzly-GlassFish, Tomcat, TCP, NIO...) in order to become jWebSocket more widely used and make applications easier to be migrated.
- NFC and SmartCards, Arduino and other technologies.
- A very variated set of Demos in the client side (Games, Chat, sms, WebSocket-Captcha, Sencha, Jquery & jQuery Mobile plugIns, Arduino, Smartcard, SessionStorage, SSH-Remote Shell Control RT in the web, a Ping Pong Game demo, Channels to create full client side applications without need a server side plug-ins, etc... )
We have been working during a long time in a new Documentation, a new Web Site and a new Production release of jWebSocket for our community, jWebSocket is a project created by people from all the world who dedicate their free time to contribute and create a really usable product to be used by all the opensource community. We are trying to give our best to the community.
I wouldn't establish a comparison between Kaazing and jWebSocket, they both have different communities, goals and LICENSES.

For a gaming platform you might want to check out http://www.pubnub.com/. I met their CTO at a developer conference and for your stated purpose, you might just win big with not having to manage the infrastructure on your own. Check out their http://www.pubnub.com/customers/showcase for details on who is using their infrastructure and for what purpose.

For me, the main point is Kaazing has a proprietary license and it's payed. jWebSocket is LGPL and free. If you are developing an application with an ROI that allows you to pay for a service like Kazzing, I think it is a good option (like pubnub.com and pusher.com), but if you want to build a complete solution and host it or you want to contribute with OS community to create a new websocket alternative, jWebSocket is an excellent option.

There are two things I would add to Peter's comment, one is that Kaazing's emulation solution exposes identical APIs to the native WebSocket APIs, so you only have to learn WebSocket not some other proprietary API. You can check out the demos and the doc that Peter referred to for more information.
Secondly, Kaazing just announced the availability of Kaazing WebSocket Gateway AMIs on Amazon EC2 - http://kaazing.com/cloud
Best,
Jonas

I've been working with jWebSockets for the past 3 months or so, and this is the first I hear of Kaazing.
I will describe how I feel about jWebSocket so far to the best of my ability in the hope that it will help.
Setting up the developing environment and getting started wasn't easy but developing using it is rather comfortable. The entire system makes sense and it is quite easy to understand. You program with Java on the server side and js on the client using json based tokens, it makes it very easy to send and receive data.
It is however very lacking in support. There are a lot of missing documentation and the support forum is nearly dead. There is payed support from the developers but I've never tried it.
There are a lot of open source demos that you can use to understand and get started. Most of them were working smoothly. Something I cannot say about kaazing after a brief visit to their demo site.
In the few months I've been working with jWebSocket I've yet to encounter a single bug, The system works smoothly and my only disappointment is the lack of support and documentation.

If you are looking for a pure open source project, look at the Atmosphere Framework. License is Apache 2.
-- Jeanfrancois (creator of Atmosphere)

jWebSocket is a good framework and support almost all servers. It has support of jetty too. Only problem with jWebSocket is slow development and zero support. Websocket specification are changing very rapidly and jWebSocket releases are very slow. I would prefer to wait and watch jWebSocket framework for some time.

Websockets Server in Java (or PHP)

I could need your experience according server implementations for the currently evolving Websockets in HTML5. We want to use this technology for a project using common webbrowsers on the client site. What we now need is a webserver that feeds our requirements. These are:
written in Java or PHP since these are the languages which currently are used and mastered by all the programmers in the project. Since it seems that there are no promising PHP implementations yet, I tend to concentrate on the Java site.
as fast as possible. We don't expect too heavy usage in production but we need to be able to synch two browsers on independent host in nearly real-time.
easy expandable. We will need to implement our own protocol on top of the websockets so we would like the most possible flexibility.
easy to use, well documented and actively developed. Since we have to come to a first running implementation rather quickly and since I expect some changes in the developing people during the time, it would be great if it's not to hard to get into the server programming.
I already had a look on some servers/frameworks which look promising, e.g. Jetty, Netty and jWebSocket. I also found some older discussions of this topic. However, I would be glad about some current experiences or recommendations of those of you who already have used Java (or PHP) to work with Websockets. Is there some implementation which is especially well-fitting or one that we absolutely shouldn't use?
Edit:
For clarity: When I speak of implementing our own protocol on top of Websockets I mean having some kind of plugin mechanism so that we can use a Websocket to send XML-messages to the server and then use a plugin to interpret them into some server actions as we like. I guess every server implementation also supports this but it would be good if it was not too difficult to write such plugins.

I don't have any experience with PHP so I'll give you my opinion for the Java (and python side).
For Java:
You have your very common and safe choice of Tomcat. It's one of the most actively developed servers, its open source, lots of support/help from its very large community, from what I've read (but not tested) it can be fairly scalable and it also has a very mature console to monitor different metrics for your website.
You also have other choices such as Caucho's Resin, who have a very small yet smart team who actively develop their webserver. Their new heartbeat service allows a good degree of scalability (again from what I've read).
And then you also have Google's appengine which is all about scalability. Their API (for both, the server and client side) has started to focus on realtime web applications so it's a bit easier to for creating high performance web applications without having to worry about the server related optimization that you often have to make with other servers. They have APIs for creating "channels" between the server and client side for very realtime applications. The AppEngine team also has a new MapReduce API for analyzing data quickly/efficiently. For these reasons and the personal opinion that they are pioneering new web technologies/standards, I'm personally been leaning towards AppEngine. It's free if you're keeping cpu/data usuage low but if you need full scale deployment it does start to get pricey so do research. If your project is more for fun/school, its free quotas are enough and all its development tools/APIs are free so it's perfect.
For Python:
I'm more Java than Python, but Python is definitely a great language and very very very easy to learn. And the reason I'm recommending Python for consideration here is because AppEngine also allows developers the choice of Python. The author/creater of the Python language is now on the AppEngine team so, even though the Python and Java APIs are pretty much exactly the same, they sometimes have new/better APIs for Python. For example, I think the datastore API offered with Python is a bit easier and optimized for the Google datastore. Also, since you'd be using python, you can use Django with AppEngine.
The second choice that I've recently become aware of is the tornado web server which was developed by FriendFeed and then bought and used by Facebook. It's also actively developed. But the reason I bring this up is that Tornado's focus, much like AppEngine's, is high web application performance and scalability. I have no experience with it but I've become interested in its technology simply because no one can contest that Facebook requires a very high performance/scalable web server.
Some last thoughts:
In general you'll find that it isn't very difficult to build your own protocol on top of the APIs provided from most web servers (even Asp.NET MVC). But from what I've been able to test around with AppEngine, it really focuses on being flexible on what kind of protocol is build on top of it. To me, its pretty much just feels like a RPC server which which works on top of HTTP. And that becomes even more apparent if you use Python just because of some of the language constructs.

Operator Console App - Java/Flex

We are in the middle to evaluate the technology choice to re-design an operator console application. The operator console as a hosted contact center has the abilities to queue the inactive calls, and hold, answer, transfer the active calls.
The legacy operator console used Java Swing. We want to use the latest RIA technology (Flex/Silverlight) to retire the legacy one. But the question is Flex/Silverlight can implement the functions like hold, transfer the calls? Based on my experiences, Flex can listen Java socket to receive XML data? Does it work well to receive voice data? Thanks.

Flash / Flex does have native access to the computer's microphone with the introduction of the latest player / AIR runtimes. But, that is probably not what you need.
Yes, Flex supports open sockets and can listn to a server. To receive voice data, you'll be best served using something on the server side, such as Flash Media Server or Red5.
I'm not sure of the technology to integrate such technologies with a traditional phone lines, though. You may look into Ribbit APIs as one solution. I was under the impression that Ribbit used Red5 under the hood; and it designed for these type of telephony applications.

You can use flex and Ribbit for that. Ribbit is a company that offers VOIP solutions for web application. I have used in couple of projects and it's really good.
Here is the link to their deve zone (htey support several technologies):
http://developer.ribbit.com/development-center/flash/flash-center
Hope this helps.

Vehicle Tracking System[java/Java EE]

I am interested in building a vehicle tracking system using GPRS. However, I have some questions for anyone who has done this before:
Is GPRS the best technology to use? Any problems people are aware of?
I am planning on using Java/Java EE - is there any better technologies?
If someone has built this before - do you have some examples of what to see for system requirements?
What are some good web resources you've found working on this?
Is there a step-by-step guide anywhere to getting started?

If you're just doing it for fun/personal use and Amateur Radio licenses are available where you are, look into APRS.

You can use a phone with a GPS receiver (internal or otherwise). External receivers are easier to use because they are addressed by an older Java JSR (http://www.jsr82.com/) and thus better supported in Java ME.
On the client side (phone), you can write midlets in Java (see JaveME) to access the GPS location of the device and then use the phone's data connection (GPRS or 3G) to make a HTTP request to a server that will track the location of the device. The only alternate I see to GPRS/3G is SMS but that makes things more complicated on the server side (you will need access to an SMS gateway with an GSM operator).
For the APIs required to build Java midlets, register with Nokia - they have a developer site that offers all the information you need. Of course, if you use another type of phone Nokia's stuff is not of much help.
There are some existing solutions for the client side - google for TrekBuddy - that can probably be used for a proof-of-concept.
On the server side you can write a servlet that tracks a device by device id and records the coordinates as sent by the phone.

If someone has built this before - do you have some examples of what to see for system requirements?
Some of the questions are too generic to answer, but to specifically answer this one. Here is one example.
Generally the software components (and a hardware component) that you would need are:
GPS tracking device - Capable of reporting the location over internet (or SMS). XeXun TK102 compatible devices are common in under $100 category, but there are plenty of other options.
Server and database - for storing the location / history. Java EE stack is a good choice here.
Map based reporting application - For viewing and analysing the location data. Typically a desktop, mobile or a web application.
Here is one simple open-source Java EE / Spring based vehicle tracking server, database and web-based mobile map application (2-3 above). It uses TK102 compatible GPS/GPRS tracking device (1):
https://github.com/mstahv/tindratracker