I am looking forward to build a mobile application, android for now but will be extendable to iOS and also a Web app. I am planning to build a common backend and use REST and expose the API's which will be consumed from different applications.
I am looking for suggestions for a technology stack best suitable for this kind of architecture?
I would strongly suggest Nancy. The main advantage being that it is super easy to set up and it does all the things you would normally expect from a REST service. JSON serialization, routes, parameters etc...
And you can code it in C# .NET, without having to write the boilerplate code that is usually necessary to get this sort of simple functionality running.
Related
I have started working on a university project. I have to test various REST frameworks for Android and see which one is the most efficient/stable currently.
Which are most popular REST frameworks currently for Android? I have heard about Spring.
Secondly, how do you create a RESTful service for Android?
There a number of REST libraries that do more or less for you. Arguably, the most popular for Android are Retrofit (https://github.com/square/retrofit) and my personal favourite RoboSpice (https://github.com/stephanenicolas/robospice) for two simple reasons: runs as a service and works alongside Activity lifecycle.
Answering which one is the best would start a flame war.
Keep in mind that ANY library that can do a HTTP request with POST and GET can be "weaponised" as RESTful library, it's only a matter of how much boilerplate you want to write on your own and how much control over each aspect you require.
What's the best way to design a Java server architecture that interacts with a client-side GWT application, but also responds correctly to various other client-requests from other platforms? Specifically, I'd like to use the same servlet layer to respond to not only my GWT application, but to corresponding iOS and Android applications.
The first approach I thought of would be to implement the GWT client layer using "RequestBuilder" rather than the usual RPC method service interfaces. Using this approach, I could code generic servlets that respond to HTTP requests in a RESTful manner by processing variables encoded in something like JSON or XML. Although this would work, it would be somewhat labor-intensive to have to encode and decode my objects/parameters in JSON on both the client and server, especially when RPC provided such an elegant solution.
The other approach (which I think is better), would be to find out the specification Google uses to serialize and deserialize their RPC method calls and implement some sort of library that does the same thing for iOS (in Objective-C) and Android. The problem is that I haven't been able to find good documentation about this encoding standard, nor have I found libraries that implement it for iOS or Android (although I did find something like it for PHP at www.gwtphp.com).
Could anybody steer me toward a specification for how GWT serializes/deserializes their objects or, even better, libraries for iOS and/or Android that implement RPC interfaces?
Make a "service" layer, i.e. a set of business classes that return POJOs.
Then you can easily have GWT-RPC and REST calling the service layer.
This is pretty easy and straightforward. Your issue is going to be how to create a business layer that only returns POJOs. But that's another story.
If you are truly trying to have a platform-independent server that clients can interact with, then your best bet is going to be to use a "least common denominator" approach, which is often simple data passing and surfacing handles for various actions to occur.
To that end, a RESTful interface, likely with either JSON or XML for encoding the data, is going to be your most supported bet.
The main advantage of going this way is that there are already lots of libraries that deal with serializing / deserializing JSON and XML, and you are keeping your service as flexible as possible, which means that you are not limiting your client base by requiring them to do very much other than deal with text and make web requests (at the most basic level).
It does put a bit more work on making the server-side of the connection do what you want, but that's the trade-off between the flexibility of fairly generic REST that any client can deal with and a much more target RPC-based service that, while it makes some implementations easier, does limit the clients to those that can deal with the specific RPC implementation.
GWT-RPC is really a bad choice when you don't control the clients' deployment, because the clients have to be updated each time you make a change to your classes. This is one of the reasons that led to RequestFactory being developped. And it'll work as-is on Android.
That said, I concur with Peter Knego: build protocol-specific public APIs on top of a single service layer.
Also, you can use GSON, Jackson and/or GWT AutoBeans to serialize objects to JSON.
I'm going to develope an application based on web services (axis2) and android (clients).
I'm now planning the logic architecture for my system and I supose that it should be like a SOA architecture. I have seen that a SOA architecture is based on layers.
So, this would be a "correct" logic architecture for my application? (with some changes of course)
http://geeks.ms/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/unai/DDD_5F00_NLAYER_5F00_ARCHITECTURE_5F00_SMALL_5F00_6ADA95E1.png
Android code (activities) would be on Presentation Layer?
EDIT
April 2014
Now, 3 years later with some more experience... REST is the best :)
Warning, it may that this answer is not at all an answer to you question but anyway, here is my thoughts.
I'm definitely not a SOA specialist but since SOA can be implemented with REST, it should not have any consequences on a SOA architecture. Android is REST-ready (see that Google IO 2010 session on REST) and there is only little SOAP support on android (afaik, but I may be wrong).
At some point, you'll have to evaluate the feasibility of the interop. between your Axis WS-* with any existing android SOAP support (the well-known ksoap2 project for example). The result could be not without impact on your architecture design.
The point here is: if you do use Rampart to use WS-Security, for example, on top of Axis2, it seems to me there are little chances that ksoap may interact at all (technically) with your service provider. On the one hand, if the service is simple and can be bound with ksoap2, great, go on. On the other hand, if you would use a not so simple security or authentication scheme, it could just be a nightmare to get the things done with the simple SOAP support on android. In the latest case and as the REST approach seems to be the preferred philosophy on android, you may be confronted to the decision to have a REST proxy dedicated to android between your Axis2 business WS and the android client-side application.
In the hope it may be of any help.
Perhaps you could even try SOAP. Android supports SOAP web services and provides ksoap2 libraries which you can use for sending request and getting response from your server easily.
For starters just check this out. Now, the latest version of ksoap also supports passing of Object Arrays.
For more information of ksoap2, I suggest to read this
Cheers
All the best
I want to build a server that communicates with an android phone
based on a request/response model
At first i thought i will use Httpservlets and communicate with the android
by Http messages. but i need to be able to access a pretty big object with every
request so i guess i cant really transfer the object to the servlet.
so i know this is a pretty newbish question but iv'e been searching for days
what kind of java EE tech should i use(i thought of EJB but as i understand they cant communicate with android)?
Thanks in advance
I think the right question is how to implement service layer for your android application:
Basically there are two options REST based web services and SOAP. Android's support for SOAP is inadequate and I personally prefer REST over soap any day. If you have decided to go with REST, your options in Java are Jersey, RESTlets or Spring Rest services. I will prefer Jersey, but you can also look in to Spring ( although not strictly complaint with the JSR).
(note: look in "SO" for comparison on various rest based frameworks in Java)
I've been hired to develop a mobile framework for a webservice created by my employer. Ideally management would like to have some reusable components that can be shared across mobile platforms (initially iOS & Android, probably Windows Phone 7 at some later point).
I've been wondering how feasible this is. One of the requirements is a native interface, so we would use Cocoa Touch on iOS & whatever (Java-based) toolset is used to create a native UI for Android. The application will interact with webservices, mainly the ones that we've been creating internally. The webservices have been developed in .NET.
As far as reusable components go, I guess we could use some C++ code to make webservice calls and perhaps even more of the backend of an application, yet I wonder if this would be a good approach. Apple's Foundation Framework has some excellent capabilities build-in to access webservices, not to mention other open-source libraries, e.g. ASIHttpRequest, SBJSON, etc... I guess the same would be true for Android (though I have no real Android experience for now). Also, when looking at projects done by companies like Google, Twitter & Facebook, each of these companies offers native libraries built for the major mobile OS platforms. If the big companies take this approach, it seems logical for us to follow suit.
Perhaps we should focus more on a general architecture that we should offer across platforms instead of an implementation that can be shared.
Would anyone advise us to make use of C/C++ to develop such a framework (shared library) for the mobile site of our webservices? If so, why?
It really depends on what level of customized code you want to have. I worked at a game company previously, and we made two games for both iPhone and Android, and at least 90% of the codebase was shared between the two platforms in c++ code. Sometimes it is significantly easier to implement elements with specialized third-party libraries, like for Facebook and the like, but maintaining that code means continually doing it for both platforms. That was one of the reasons why we even implemented our own UI objects in c++ for our games. Because even though the initial setup would have been easier to do with Interface Builder and Android's XMLs, the maintenance and tweaking necessary ended up being significantly less because we went with a shared codebase.
In short, I would highly recommend writing any shared customized code in C/C++, and things that are significantly easier in their native codebases (java for android, or obj-c for iphone) and you don't expect to change much, to keep separate.
Depending on which WS protocol you use it may be more or less hard to do, but anyway I see little advantage in doing that in C/C++ for a mobile platform.
If you were using SOAP, I'd never consider C/C++, even for a desktop app. I already used SOAP libraries for C++ and they are a lot harder to use than their Java/.net counterparts, and the way they are implemented (mapping SOAP objects to C structs) is very prone to crashes if the format changes. Not to mention that you have to recompile your client when the WSDL changes.
As I understood in your case you plan to use REST. I never found a good REST library for C/C++, but recently I did a desktop project in which I implemented a C++ REST client using simply WinHTTP (in Windows) and libCURL (in Linux). Of course, they provide just the HTTP part, so I had to add cppdom for XML parsing. If you use JSON, there are many good libs like jsoncpp, libjson.
I'd say to you that even in a desktop environment it was harder to do than would be in .net or java, and was only done this way because it was part of a larger application already written in C/C++.
Anyway, you'll have more work and not much advantage since all those modern mobile platforms provide rich libraries that do the same thing, and probably the user of your API will develop in the platform's main language, so you'll have the double extra work of implementing the WS access code AND the binding code. As I assume all (or at least most) of your logic is in your server, not the client, there's not much common code between the platforms to justify using C/C++.