In web-service fundamental, I have heard about "SOAP" and "KSOAP."
What are SOAP and KSOAP?
What is the difference between them?
Why should I use one instead of the other one?
SOAP - SOAP is an XML vocabulary used to describe messaging and
remote procedure calls between distributed components.Any modern
language that works with the Internet is likely to support both XML
and HTTP.
KSOAP - KSOAP is a SOAP API based on kXML,where kXML is a
lightweight Java-based XML parser designed to run on limited, embedded
systems such as personal mobile devices. It is a pull parser which
means it reads a little bit of the document at once
So, KSOAP was specially was designed or developed to deal with small embedded device like mobile devices.
SOAP - Most enterprise-level SOAP toolkits often rely on the use of a Web Services Description Language (WSDL) generated proxy object to make function calls. This is useful if a service has a published description and when the toolkit requires the instantiation of several different client and transport objects.
KSOAP - While kSOAP doesn't support WSDL, it does make calling a service relatively painless. Only two objects are required: the SOAPObject and Http-Transport.
CONCLUSION - SOAP can be a very complex realm to explore, especially the XML mechanisms used to transfer data between disparate systems, languages, and toolkits. The wireless world requires tools of small stature and great power. Luckily when it comes to SOAP, the kSOAP toolkit provides not only small size and great functionality, but also relative simplicity and ease of use for the developer. Using kSOAP, a developer can develop complex SOAP Web services clients in a remarkably short time.
KSOAP is a "lightweight and efficient SOAP library for the Android platform."
SOAP is a protocol used for building web services, and which defines a format used for the exchange of messages that uses XML as base.
You cannot use one instead of the other, as they are two different things: The first is the library necessary to use a protocol, and the second is the protocol used from the first.
Related
I want to learn how to consume web services in android , and i have done some research on it , i have seen that .net web services are in XML format and return response in XML, when PHP web services are give jason array in response , i have used ksoap for .net web services , is ksoap can also used for php web services?
I think you misunderstood. .Net is not only to generate data in XML format.It is also possible to generate JSON data using .NET also and it is also possible to generate XML format using php.Most of the people will use JSON only because it is light weight and its easy parse from client side.Parsing XML data is really pain in my opinion.
And you asked ksoap also used for php?Yes it is.
See the below link
http://www.petetracey.com/2009/11/ksoap-with-php-tutorial/
Above site is my site so thought I'd clear this up a bit -- SOAP is a protocol that uses XML as its underlying format. It's one of many options that use XML. KSOAP (with the K) is the Java library, for blackberry but may be somewhere in the android libs or tacked on somehow. Still I think the better option is JSON, it is lighter weight and parses faster and therefore for mobile with data rates/limited processing power/battery consumption goes up with processor use -- you want to be lean and mean.
So any modern language, be it PHP, .NET, whathaveyou++, has libraries for both JSON and XML - and most have SOAP either built-in or as the 3rd party library somewhere. Which to use is the right tool for the job, and SOAP at this point is pretty much a legacy technology outside of the Sun/Oracle and Microsoft world.
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'm not asking to be spoon fed here, just need some pointers on where to direct my searching
I want to call a SOAP web service, possibly this one
I don't want to use KSoap, is there anyway I can do this using the apache libraries that are included with the Android SDK?
I want to call a SOAP web service, possibly this one
That does not look like a SOAP Web service. Try clicking that link in a browser, and you will see it is a plain XML document.
is there anyway I can do this using the apache libraries that are included with the Android SDK?
Yes. For true SOAP, plan to spend a substantial amount of time writing your own SOAP layer atop HttpClient. However, for consuming a simple XML document like the one you link to above, it should be fairly simple.
I think the XML is not WebService, it is simple XML... To call WebService with SOAP you can use kSOAP2 on Android platform, but I've created an another - proof-of-concept - SOAP client:
http://wiki.javaforum.hu/display/ANDROIDSOAP/Home