I want to use android application to pass and get data from webservice, I have the wsdl of that webservice. So which of the one i can use for data manipulation ksoap2 or retrofit 2 which is better.And if i use one of these what else is needed.
It depends on the architecture in which your services are written. Retrofit is used for rest services where as ksoap is used for soap services.
REST vs. SOAP
There are significant differences between SOAP and RESTful web services. The bullets below break down the features of each web service based on personal experience.
REST
RESTful web services are stateless. You can test this condition by restarting the server and checking if interactions survive.
For most servers, RESTful web services provide a good caching infrastructure over an HTTP GET method. This can improve the performance if the information the service returns is not altered frequently and is not dynamic.
Service producers and consumers must understand the context and content being passed along as there is no standard set of rules to describe the REST web services interface.
REST is useful for restricted-profile devices, such as mobile, for which the overhead of additional parameters are less (e.g., headers).
REST services are easy to integrate with existing websites and are exposed with XML so the HTML pages can consume the same with ease. There is little need to refactor the existing site architecture. As such, developers are more productive because they don't need to rewrite everything from scratch; instead, they just need to add on the existing functionality.
A REST-based implementation is simple compared to SOAP.
SOAP
The Web Services Description Language (WSDL) describes a common set of rules to define the messages, bindings, operations and location of the service. WSDL is akin to a contract to define the interface that the service offers.
SOAP requires less plumbing code than REST services design (e.g., transactions, security, coordination, addressing and trust). Most real-world applications are not simple and support complex operations, which require conversational state and contextual information to be maintained. With the SOAP approach, developers don't need to write plumbing code into the application layer.
SOAP web services, such as JAX-WS, are useful for asynchronous processing and invocation.
SOAP supports several protocols and technologies, including WSDL, XSDs and WS-Addressing.
Consuming a web service via a database stored procedure allows users to straight away update a database with information from different sources. Users can also schedule a job at regular intervals to get data updated periodically in the database.
For further details visit following link:
http://searchmicroservices.techtarget.com/tip/REST-vs-SOAP-Choosing-the-best-web-service
Retrofit, A type-safe HTTP client for Android and Java
Retrofit can be used to consume any type of web services, be it REST or SOAP, though typically used for REST APIs. I do not know much about SOAP standards but you can definitely do SOAP using Retrofit.
https://github.com/asanchezyu/RetrofitSoapSample
Related
what is best approach for consuming Soap based webservices in android
A web service is any piece of software that makes itself available over the internet that can be remotely invoked using HTTP, that is, it can be activated using HTTP requests. XML is used to encode all communications to a web service. Web services allows you to expose the functionality of your existing code over the network but code are completely invisible to Web site surfers and software users. Their job is to run silently in the background,For example, a client invokes a web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications,thus providing a way for applications to work with each other to get the user the information or functionality he needs.
Along with XML, Web Services uses standardized industry standard protocol for the communication. All the four layers (Service Transport, XML Messaging, Service Description and Service Discovery layers) uses the well defined protocol in the Web Services protocol stack. This standardization of protocol stack gives the business many advantages like wide range of choices, reduction in the cost due to competition and increase in the quality.
Read This Tutorial for entire information.
And read this previous Question on same topic.
We need to develop a website that can be browsed from desktop browser. We also need to develop an android application for the same website. We are thinking of using ASP.NET MVC using C#, Microsoft SQL Server and Windows Communication Foundation, Linq To Entity with Repository Framework.
WCF will access database using Linq to Entity using Repository Framework and return JSON.
Question 1
Android application will call WCF service. Are we thinking correct?
Question 2
ASP.NET MVC website will call WCF service. Making ASP.NET MVC application call WCF service is better or ASP.NET application directly communicating with database without having WCF in the middle is better?
My idea is to use WCF only for android application and make ASP.NET MVC interact directly with database using linq to entity framework using repository pattern without WCF in the middle. Will this be a good approach?
Question 3
If ASP.NET MVC website will call WCF service, where do i need to implement DI. I think it must be between repository framework and WCF service and DI will have nothing to do between ASP.NET MVC and WCF. Right?
This may be a simple question but I want to know how others are doing if they have same kind of requirement. Like website and android application. I am not familiar with DI and how to use it. I have been reading about DI and am not quite getting it. So I wanted to know where DI will exist?
Your Android app cannot call your database directly, so you need a service in between. This can be WCF or another popular option is ASP.NET Web API.
You should not let your MVC app communicate with the database indirectly through a WCF service, unless this is really needed (because of security or organizational concerns for instance), because this extra layer of indirection costs performance. There is a lot of overhead in communicating with WCF that just doesn't seem necessarily.
If you decide to let your MVC app call into a WCF service, both the MVC and WCF application get their own Composition Root. This means that they each have their own DI configuration and their own way of injecting dependencies. They might share a lot, but this doesn't have to be.
I expect you might found my answer disturbing. You are probably concerned with the development overhead of having a both a WCF service and MVC app that both communicate to the database, instead of having only a WCF service that talks to the database.
This doesn't have to be the case though. In fact, this SHOULDNOT be the case. When you're doing that, you're doing things wrong. A WCF service itself should be nothing more than a really thin layer on top of your business layer. The same business layer that your MVC app uses. In fact, when applying the correct abstractions, you would be able to swap your MVC app from using the database to using the WCF service in a matter of minutes.
You can do this by placing your business operations behind a generic abstraction and use a message-based architecture. Your WCF service (or Web API) can in that case simply excepts those messages and forwards them to the business layer. If you do this correctly, you'll find out that you can write your WCF service or Web API service in such way that they become maintenance free, which means: you won't have to change them when the system grows; when new business operations are added to the system.
I advice you to read the following articles:
Meanwhile... on the command side of my architecture
Meanwhile... on the query side of my architecture
Writing Highly Maintainable WCF Services.
If you're -after reading those articles- in doubt about how to implement this, take a look at the Highly Maintainable Web Services project. This is a reference architecture application that shows how to apply these concepts using both WCF and Web API.
I am creating an app in android. It will be calling a webservice to fetch some confidential info. I need to verify that the user is authenticated to access the info and the service shouldn't be called from any other source even if the user has all the required credentails to access the service.
What should be used to ensure the security.... REST or SOAP?
For security you should use SSL with client authentification and possibility to revoke cvlient certificates (though not every appplication server will support this). SOAP or REST do not have differences in this context.
In my experience REST is easier to build and has less overhead. I used to build soap services with CXF, which is really easy, but now I use Restlet for the server, which is even easier and quicker. Restlet has integration for Json, Guice, JPA, and all the good stuff. At the Android side, I use a simple rest interface with httpClient, Roboguice and Jackson.
I have a set of computations that I am currently running on the Android. I want to move these computations from Android to a cloud (possibly google c2dm architecture or any other free service) but I dont have enough knowledge on how to use the c2dm. I will be sending a list of strings to the cloud, do lots of computations on the cloud and then return the rearranged list of strings to android.
Can anybody help me with this (as to how to connect the cloud with an android app)?
Thanks
Anks
You could use HTTP POST-GET requests to communicate with server, send and receive JSON/xml data.
EDIT that's almost enough to leverage client-server communication in your app.
http://developer.android.com/reference/java/net/HttpURLConnection.html
http://www.ibm.com/developerworks/opensource/library/x-android/
http://www.ibm.com/developerworks/xml/library/x-andbene1/
I am unsure what you mean by "google cloud".
One way to achieve this would be to use Google App Engine. It allows you to run server applications developed in Java/Python on Google's infrastructure.
What this means is that you can develop the server side yourself, and therefore implement any protocol you like to communicate with clients, that is, create your own web service.
As Mighter mentioned you could perform raw HTTP requests. However, there are a number of existing protocols for remote procedure call: SOAP, XML-RPC, etc..
I personally tend to like JSON-based protocols. It's easy to make your own implementation for that type of protocol, but you may be interested by this JSON-RPC library for Android, as an example.
Also check this other question: How to call a SOAP web service on Android
Once you'll have your web service ready, whether using SOAP, JSON-RPC or else, then you should be able to create a client, and expose the remote service calls through Java classes. If well designed, it could 1. feel as if you were calling methods on a local object, and 2. allow you to swap with a local implementation in case the network is unavailable.
I think it depends of how heavy your computations are, or how much computation power do you need. you can try to write a simple app engine server which handles post requests and return a JSON format answer. in case your computations are complex i would use google compute engine and install my custom stack.
in both cases you would need to write a server side to handle your data. if you use google app engine you can write it in java, python, php or go. if you use compute engine you can basically write it in any language that you can run on linux.
hope it helped!
I want to create a very simple rest-like web service to be used by an android application. The web service just needs to offer a way to add user entries to a simple database and retrieve other users' entries.
What would you recommend as a platform to accomplish this?
I was thinking google app engine might be a good way to get this going without worrying about hosting but asp.net mvc or django are other possibilities.
I know this isn't a direct answer but I would shy away from any sort of offical XML-based web services. I've found that JSON is far less verbose and generally leads to faster response times as opposed to full blown SOAP messages. I would urge you to evaluate JSON as your "transport" mechanism.