We're currently in the midst of rewriting our flagship product, and we've reached the point where we have to consider our options for remote and mobile access to our product. In general, our product is purchased and self-hosted by our customers. The current state of things uses a WCF service over NetTcpBinding to handle the interaction with our desktop application, and this is working fine. However, this obviously isn't a suitable option for our web and mobile clients.
Being more experienced with Windows desktop application development, I am a little out of my depth when it comes to choosing a web service technology and strategy, especially when having to consider compatibility with other platforms. What WCF web service technology would you recommend given the following requirements?
Username/password-based authentication
Session (stateful) behavior (though handling all of the session information locally and making the service stateless is an option)
Ability to call the same service from an ASP.NET MVC web application, iPhone/iPad application, and Android application (and perhaps tertiary platforms like WP7 later)
I know that I could just implement a REST-ful service and roll my own solutions for session management and authentication, but I'd prefer to stick to industry conventions if at all possible. Is there a WCF technology (or set of technologies) that deal with these issues in a way that is compatible with the three platforms I've listed?
REST in Windows Communication Foundation (WCF)
REST just uses HTTP protocol so every device acting as HTTP client is able to use it. It is not a protocol - you are defining protocol used over REST. Every mobile platform is able to consume REST services so you should not reach any blocking problem here and if you are not sure simply try to make some proof of concept.
Use WCF and check new Web-API (it is still only preview but it will be future version of WCF) because it simplifies REST service development with WCF and adds new features. For authentication you can use anything available in HTTP - basic authentication with HTTPS will work or you can check OAuth.
I have one big problem with your requirements:
Session (stateful) behavior (though handling all of the session information locally and making the service stateless is an option)
REST states for Representational state transfer. By nature all state should be transferred within request because you are posting new resources, getting existing resources and putting them back. By putting or posting resource you are making state transition defined in resource. Fully stateful communication is for RPC. But it is really hard to think about this more without deep knowledge of your product.
Related
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
I want to create a sort of chat system with a server, and client applications designed for both desktop and mobile platforms. The server and the desktop client would both be written in .NET (for Windows only). The mobile clients, on the other hand, would be native iOS and Android apps.
I’m looking for a way to prepare the server in such a way, that it can be used by all the kinds of clients I mentioned (if possible). I considered WCF, ServiceStack and ASP.NET Web API. Even though I know little about these technologies, they seem to serve client requests only, and there is no permanent connection (right?). So I started wondering how to keep clients up-to-date as far as user statuses are concerned (the clients will show user statuses: online, offline etc.) IMO polling the server is not a good solution.
I will be grateful for your suggestions on:
what technology to use for the server so it is easy to communicate
with from different platforms,
the best/easiest and efficient solution for notifying clients about changes (which
may occur very often in this case).
I'm going to build application for web (asp.net mvc) and mobile (iOS and Android). And all three of them must communicate (share data, user authorization etc.) . What is best way to this ? Using asp.net web api or azure mobile services ?
EDIT
I was also wondering what was best practice for scenario like this: I have data base and business logic in one project which needs to communicate whit web and mobile using service. So which technology is best to develop this service Azure or web api or smth. else ?
Your question is very general.
ASP.NET Web API is just a framework to build RESTful web services which you can host everywhere. It does not help you with your task to "communicate (share data, user authorization etc.)".
Azure Mobile Services is an Azure hosted PaaS that actually provides everything you need and even more. It also provides you with ready-to-go RESTful web services that you might implement using ASP.NET Web API as well, but in addition to that it also provides support for federated identities, data sharing etc.
So, I would say since you seem to be somewhat new to this area, you should try Mobile Service, for they are very well documented and there is plenty of nice tutorials suitable for beginners, here is my favorite one.
You can also download a project template for Android and iOS after you have set up your own mobile service and just extend it. This is really a great help for beginners and hobby developers.
UPDATE:
Let's approach your question with some fictional scenarios for different solutions offered by Azure:
Azure Mobile Services cover the scenarios where you have multiple (mobile) devices running occasionally connected applications that need to synchronize their content through the cloud.
AMS provides you with the possibility to implement the custom processing logic for data requests and updates; it hides the burden of implementing and hosting a web service.
About 90% of the logic is set or written directly in the management portal, the rest is just the client logic.
The main purpose of this service is data sync (this is the core functionality), all other services (authentication, logging, scheduler) are just auxiliary.
The language used for development is JavaScript, the whole development is similar to server-side development using frameworks like Node.js.
Azure Web Sites is the way to host your code within IIS, that usually would be a web page, but nothing hinders you on hosting your web services (Web API based or even full-fledged WCF) here as well. Azure Web Sites are easy to deploy and this is a rather cheap solution for hosting web services, provided you allow other IIS applications (from other users) to run here as well (shared instance), but you can also prioritize your application by going for a reserved IIS instance (and pay more). Sure, you can reuse most (virtually all) of your existing business logic here (unless you need something exotic like interop or shell access that can't be hosted in IIS natively). The disadvantage of this solution is that your logic will run within the context of your web service and for long running processing this might be a non-optimal solution.
Azure Cloud Services allow you to defer the processing of logic rules and to decouple the logic from the service input. In this scenario you can have two kinds of roles, typically called web role and worker role. Web role provides endpoints for your services and queues the requests, the worker roles reads the queue and does processing. This allows you to fine tune your load balancing and capacity planning, increasing the number of parallel instances with web roles and worker roles.
I am trying to develop a system that involves a:
server with a database that will handle the system's logic and manipulate data
an android app that will interact with that server (pull and push data into the server)
a website that will do the same as the android app, but from a website with slightly different data.
What I thought of is to use SQLite with Apache Tomcat installed on the server and deploy a Grails war file on it. That will take care of the 'website' side of the system. But what about the android app? Can it communicate with Tomcat as well?
Tomcat will suit your needs. I would look at hosting options though. Are you hosting your own server, or do you have a hosting provider? Do you have experience hosting a tomcat server etc. Do you have experience with java web applications, or other web frameworks? All of the above, and probably more should lead you to your decision on what type of framework/language to use on the server. This in turn will lead you to your options for hosting, and web-container to use.
Once that is determined all major web frameworks will allow you to publish web-services Rest, Soap, etc. that can be consumed by an android application.
Also, if you are planning on providing a web interface and service at the server level, my guess is you are going to be storing a fair amount of data, I would look into a more robust and scalable database such as mysql or postgres. This post contains some insights into this.
If you have an API that is web accessible, an Android can access it.
Android shouldn't have any problems communicating with Tomcat.
Look at http://grails.org/doc/latest/guide/13.%20Web%20Services.html for more information.
A RESTful web service is most likely what you'll need. Android can consume SOAP web services but it requires more work for less overall functionality.
I have been looking into android development for some time and would really like to create a networked game. I also think this would be an excellent oppurtunity to familiarize myself with the app engine framework, but it seems more app engine applications are built around browser services.
This is not nessecarily a problem for me, but I do not want this to appear as a browser based game (I want live chat, more dynamic interaction/movement/combat). I have been looking into AJAX/Java as a possible solution, but I am having trouble visualizing how i will actually connect the app to the server, since all tutroials I have found seem to be hosted web applications. Are there any resources for android applications hooking transparently into App Engine services?
Or maybe there is a better service similar to app engine I should look into.
Thanks! (if i was unclear about anything let me know)
AppEngine is completely prejudiced towards delivering web applications: HTTP in, HTTP out. So, as long as you can design your game's communication layer to be implementable in HTTP (stateless, finite-life requests) there's no reason that this wouldn't work.
Your game doesn't have to run in a browser to use an HTTP-based API to communicate with the server. I doubt that there are any special "transparent" communication libraries between Andriod and AppEngine, as the web request-style of communication that is possible with AppEngine is effectively indistinguishable from the same techniques that would be used to communicate with any other HTTP-based API running on any platform.
I'm currently developing an application that will involve a browser based webapp and also an iphone "installed app" (that's google's terminology) that connects to the GAE service. I simply GET/POST xml to a basic servlet and it works fine. Just keep in mind that to keep the client snappy, you will have to use memcache extensively as even minor calls to the datastore tend to to take a long time, and a "waiting" dialog in an installed app starts to get old very quickly. I would try to use memcache (as opposed to datastore) extensively to hold game-state data, since this data probably doesn't need to be "permanently" persisted, and memcache is significantly faster than the datastore.
Also I don't think there's any way for clients to be notified of game-state changes, app engine doesn't do "push," so all the clients will have to poll for updates.
You can use the Http Component classes that are in packages org.apache.http.HttpConnect.* classes in the Android SDK.