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.
Related
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.
A mobile app I'm working on requires the server to communicate with it frequently over a short period of time, including real-time (or very close) things for the app to show (from other users).
It will be an iOS and Android app.
I was researching C2DM and on this page http://code.google.com/android/c2dm/quotas.html, at the bottom it recommends considering "implementing XMPP or your own protocol to exchange messages".
What I want to communicate between the server and the app does not fall easily into XMPP's usual chat roll, how would you go about actually implementing it?
Would it be a case of choosing appropriate XMPP libraries for the server and mobile app languages, then making a custom server (and client side)? Wouldn't this drain the battery on the phone? Can it be done over a RESTful architecture?
(If it helps, there are currently no decisions made for the server - other than it has to be highly scalable).
If what you want to communicate can be easily represented as XML and is not too large, then it can be easily done via XMPP. XMPP is very extensible. You will have to write the client side (to be expected) and use one of many available servers. Customization on the server usually means writing a component (generic and supported by the spec) or some sort of plugin (this will be server specific), but without more information I couldn't tell you if that would be required or not.
It is used for much more than just chat apps, although that would be the most common usage. Pretty much any text based instant messaging can be handled (as well as others). There are a huge number of extensions to the base protocol to support a wide variety of functionality.
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.
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!