how should I architect my applications to support mobile app's

Question

I am looking for assistance regarding my systems architecture. Let me outline:

I have a sql server and oracle database that is accessed via a set of wcf services.

These wcf services endpoints are consumed by numerous web applications.

All applications are written in .net c# 4.0.

Now there is a requirement for a mobile apps (iphone apps, android apps) to access the data provided by the databases.

My first question is, what is the best medium to supply the data to the mobile apps? Options I believe include via the wcf services that I have in place or a wrapper project (that call the existing wcf services) that exposes a WebApi or MVC controllers that mobile app's can access. Suggestions on the best approach, for mobile application consumption. Baring in mind the requirement for a small payload to the mobile app and that a security measure will also be required to prevent unauthorized mobile applications accessing the services/wrapper project.

My next question is around versioning of the WCF services. I want to be able to seamlessly update the wcf services without affecting a potential wrapper project and vice se versa. As third party mobile applications will be at different release cycles, there will be a need to support multiple versions. I expect this may involve deploying multiple versions of the application but wondering how such a practise is normally handled?

All applications are deployed on windows servers in IIS 7.0.

Answer 1

When in doubt, insert an abstraction. I would imagine the services you have built already as domain services. These services serve several clients with varied needs with a model (DTO) and a updates (APIs). In order to implement that you can easily version and be able to have the flexibility to reduce the content on the wire, introduce a layer for the screens you want to support.

I would recommend building a "mobile services" which can only depend on the domain services and have ways to convert the DTO to mobile consumable chunks. This layer can either be within ASP.NET WebAPI or be outside on vert.x or node.js so that you can spin up capabilities as you require them. In the end, what you want is a Service contract between the domain and the consumer and introducing a layer between them will give you leverage in the long run to replace either end without a huge cost. And it will allow you to version APIs based on either need without having to re-touch the entire stack.

Of course, you would want to consider a way for the client devices to tell you ahead of time, what capabilities would they require from your services so that you can determine the logical end points to reach. This will allow you to open up ways for version negotiation between the client and the domain.

I would recommend checking out LinkedIn infrastructure on how they built their mobile apps (yes, they dont use ASP.NET but the architecture pattern is still sound).

My 2c.

Answer 2

If you want mobile support, you are better off avoiding WCF and use Web API. The reason is, while all native mobile platforms can consume XML and in WCF you can use Basic HTTP binding to simulate old style web services, Web API offers lean and mean communication over HTTP which can be used by the browsers of those platforms too, and not just by native code.

If it is mobile and interoperability, I would not hesitate using Web API.

I would use WCF only in certain conditions.

Answer 3

Well... I'm very interested in hearing other answers, but this is my take on your question.

First of all, I think you should decouple your business logic from your WCF services, if you didn't already. This enables you to setup an ASP.NET Web Api service side by side with your WCF services. Instead of having some MVC or Web Api calling into your WCF, it could stand side by side as an alternative.

You can also just make Json endpoints in your WCF services, even though I like more the idea of having both WCF and Web Api, due to the latest being more interoperable. If you decouple all logic from the services, they should become rather straightforward are share all business logic.

For your mobile iphone and android apps, it's probably easier to consume the Web Api service. I'm not so experienced with maintaining several versions of services Api's, but if you have the mobile apps connected to the Web Api services, you can version by creating multiple folders per api version. This will cause duplication of business logic...

As I said, I'm very interested in other opinions.

Answer 4

I'd definitely look at JSON as my data format, as Dante has said. Also split into n-tier as suggested.

In terms of Auth...

How many third party apps do you have? It doesn't sound like you have a lot, but if you do (and they are genuinely third party i.e. not controlled by you) then you may want to look at an OAUTH solution for this.

If you only have a handful and you're in control then that is overkill IMO, instead I'd just have a simple secret key that each app knows. Each call passes the key and the service checks this. Obviously all transfer should be over SSL so no-one can eavesdrop on what the key or data is.

In terms of checking the key then you'll want to make use of aspects or custom attributes to save you from writing boiler-plate on each function.