I am writing an interface for our VXML application that will allow access to a SOAP service.
Because of the difficulties inherent in trying to use javascript to make SOAP calls and the limitations of VXML, as in making external resource calls are pretty much limited to HTTP requests, GET and POST.
I designed a java servlet that would act as a service provider to the VXML application. It can call this servlet with arguments indicating the web service type, the method name to invoke and the arguments to pass to it. The servlet then makes the appropriate web service call and returns the response in a standardized VXML document response.
The issue is I severely underestimated how difficult SOAP really is. I thought I could just simply construct the soap call and do it in java, however its looking to me like this is something a little more involved, requiring things like Apache Axis2.
I read somewhere that listeners for Axis could be HTTP servlets, which sounds a lot like what I am doing already.
Am I re-inventing the wheel here?
Is there any suggestion out there for me as to how to do this better?
I am pretty invested in the way I'm doing it now and so would be very receptive to an easy way to accomplish the SOAP call and process the response from a jsp servlet.
EDIT - After taking the advice here I've delved a little further into Axis.
As it turns out, Axis2 is Apache's third generation of Apache SOAP. Whats unfortunate about this is that after extensive searching I cannot find a single solitary place where the original Apache SOAP implementation can be downloaded.
I might not care if:
A) Axis would allow me to integrate a few jars and jsps rolled
into a standalone WAR app
B) everything .. i mean everything up to this point has been done using
examples from ApacheSOAP (the book i was using, the code I've
written thus far .. everything).
So I google some more thinking .. hey, there has to be some kind of stand alone library for Java that would just simply allow me to make a single solitary simple SOAP call and parse the results.
But no, no such luck!
Apparently if you want to use Java and SOAP you have either the gigantic incomprehensibly thick and complicated axis or .. you roll your own soap implementation from the ground up. I am so burned on this. I don't get why soap is so wonderful given the last 7 13 hour days I've spent just trying to get a simple hello world request to work from JSP.
A library like Axis is definitely the solution, you do not want to attempt to build/parse SOAP messages on your own.
Look at using wsdl2java (another link, and another) to create client proxies for which you can invoke the web services. This will generate a bunch of Java code which you can call into from your code, and then Axis will handle packaging your arguments into XML messages, sending it across the wire to the server, de-serializing the response, etc.
Related
When I'm tasked with dealing with connecting to web services, I've always found the appropriate .wsdl file, ran WSDL2Java.bat, and incorporated those Java files into my Java project. Then I've successfully completed my project that needs to access data via web services.
My question is, are there other ways to use the .wsdl file to access web services? ( I'm not talking about creating classes for different languages ). For example, I have documentation describing one company's web services. The examples it shows in it's documentation are essentially dumps of HTTP Post requests. Is this "web services"? It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right? I really feel like I'm missing something here.
Am I a web-services illiterati?
To call a SOAP web service over HTTP you just need to send it a properly formatted XML with a POST request. That's it! How you build the request is irrelevant as long as it conforms to the SOAP protocol and the payload corresponds to a proper web service operation that exists on the particular web service you are calling.
But how do you know how to build the proper payload?
The web service needs to have some sort of documentation otherwise you don't know what to put inside the XML. The documentation can be whatever you like as long as people can use it to build valid requests. WSDL fits this criteria but has an extra advantage: you can feed it to a tool that generates code. That code knows how to handle all the SOAP details and exposes objects and methods to your application.
What would you prefer? Generating code from the WSDL in a few minutes and be able to call whatever operation on the web service or, build the requests and parse the responses by hand and spend hours or days doing so. What would your boss or company prefer? :)
It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right?
Right! But you also have to consider your productivity as an employee in one case as opposed to the other.
I am a bit confused about the difference between the two.
What I have been making till now is just deploying a web application that gets invoked by a URL and returns a response(json/XML) .
what I have read about rest web services
Its a way to communicate with web applications and to reveal your methods to the world.
Question 1
But in my case I did the same revealing the URL .
Platform independent
The rest features say that its Language-independent (C# can talk to Java)
Question 2
But in traditional approach also any language can invoke any web service by simple request (get/post) which ever implemented.
Question 3
What is rest and how to get started with it (specifically in terms of django) if possible.?
You are doing REST.
REST is not a library, or a format, it's simply a technique. What you call the "traditional approach" is exactly what REST is: simple requests via GET and POST (as well as PUT and DELETE) to an endpoint that returns JSON or XML.
That is in contrast to the previously-dominant way of making API requests, ie SOAP, which requires all sorts of up-front configuration of WSDL files and service discovery, along with particularly specified request formats.
Is SOAP over HTTP a subset of XML over HTTP since I assume SOAP also an xml that confirms to a schema (SOAP schema)? I assume XML over HTTP service can either be accessed using GET or POST method. Does SOAP over HTTP always use POST method? In case of XML over HTTP I assume the disadvantage is that schema file has to be shared with all the consumers whereas in case of SOAP over HTTP it will be a single WSDL file. Would it be possible to help in letting me know the difference and also advantage of one over the other?
SOAP is a specialization of XML, as it has a schema, such as http://www.xmlsoap.org/soap/envelope/, whereas XML is more general.
For using GET, you can read through this discussion: http://www.coderanch.com/t/463869/Web-Services/java/SOAP-request-HTTP, but basically SOAP is done via POST, though Axis2 appears to have support for GET, as a way to have SOAP work in a world where REST seems to rule.
And, according to this IBM article (http://www.ibm.com/developerworks/xml/library/x-tipgetr/index.html) SOAP 1.2 introduces GET.
As you mentioned, SOAP is a standard, so there are tools that can easily work with it, including dynamic client generation, as shown in this question, dynamic proxy soap web service client in java?, whansere the client generates the stubs needed upon connection.
If you use XML over http, it may be better, depending on the need, as a way to transfer data, but in the use cases I can think of it would seem better to just use JSON and REST, but, if you want to transfer XML, or send XML, then you could look at using REST.
POST would be the better option though as GET has size limitations (maximum length of HTTP GET request?), which is probably why SOAP is almost always POST.
The WSDL is not necessarily a single file, in WCF, if I remember, there are many xml files that need to be put together for the WSDL to be complete.
The advantage depends on what your use case is, but I find that use REST and allowing the user to select the type is useful as it can be trivial to switch between JSON and XML, for example, and is the better choice for XML over HTTP.
SOAP is best when integrating with older technologies as that may be all they can easily use. For example, when I have made webservices for SAP integration, it can be more work to have it not use SOAP, depending on the ability of the ABAP programmer.
You may find this question of use:
How SOAP and REST work with XML/JSON response?
and for a discussion about JSON and XML in webservices you may find this helpful:
http://digitalbazaar.com/2010/11/22/json-vs-xml/
I forgot this link, as they do a brief comparison, but in the end you can easily support both. In WCF I had a controller that had the business logic, and had to .aspx files, one for SOAP and one for REST, and some webservices supported both, as it was just a matter of handling the request and response differences. So, if you want to provide support for both, and have a business case showing it makes sense, then pick a framework that will make it easy to do.
http://digitalbazaar.com/2010/11/22/json-vs-xml/
Basically, the goal is to provide services to clients via the web. What clients are going to connect? How will the clients find it easiest to reach out? How much data is being passed in the request?
These types of questions will lead to the best solution for your needs.
After going through the following article I came to know that if Axis2 is used on both ends, we could expect high improvements in performance.
Link : http://wso2.org/library/91
I'm writing code to consume a webservice. I'm just curious to know the framework used on the server side. How do I do it programatically using Axis2.
Server side you can use any java class.The following are the server side styles that axis provides.
Service Styles - RPC, Document, Wrapped, and Message
Also see the documentation here.
There is no such API available as such. Of course, such API is not supposed to be there at all. The whole point of using web services is interoperability i.e. the server doesn't care how the client is implemented and the client does not care how the server is implemented. Defining such an API does not make any sense, adds no business value except curiosity as in your case above.
Albeit, It still might be possible to do so, unofficially. Try to send some parameter value which is not correct business value. From the fault that is generated, it might also give stacktrace of the server through which you can probably guess the server side framework being used.
It was very easy to use Apache CXF to develop a client for a SOAP web service. All I had to do was call wsdl2java and all the required classes were present. Is there such a client for lisp? If not, what can I do to write a soap client for lisp? The only restriction is that I don't have access to commercial implementations such as franz/lispworks or macs.
There's CL-SOAP which I tried earlier this year. The nice thing about it is that it can read a WSDL file and use that to generate the client proxy. I couldn't get it to work against my SOAP service, and gave up that attempt at some point (I used SBCL). CL-SOAP itself feels a little abandoned, with the last update dated 2005. It might work for you out of the box. If not, the code is straightforward and may do what you need with some modification.
CL-XML is said to have a "SOAP module", which I didn't try out.
The question appears to be asked periodically on comp.lang.lisp, with more-or-less similar answers. You may find more pointers there.
Allegro Common Lisp has both a SOAP server and a SOAP client. I've used both with success, and they're currently maintained and supported (unlike CL-SOAP).
My SOAP server easily handles a few hundred requests a second (from both Java and .NET clients), so I'm happy with the performance.