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.
Related
It seems that most of the new kids on the block are using RESTful web services rather than SOAP. I've only dabbled in them enough to know the basics of how they work.
Essentially in a SOAP implimentation, you are able to use a WSDL file that describes data types as well as usable RPC's. Finding a WSDL file and simply adding it as a service reference in visual studio is awesome and easy to impliment.
In a REST web service you have one (or more, depending on overrides) method for each action you are wanting to take (GET, POST, PUT, DELETE). While I can see how this would be beneficial, I can see problems with this... such as still having to deserialize into a local object.
So my question is... can you actually get intellisense when consuming REST web services? When you add a service reference to a WSDL you are able to see the list of usable methods. Otherwise, is the only way to actually see the usable methods through documentation? Is there any "self-containing" document that describes to VS what you can use and/or how to interpret data types without having to deserialize/serialize.
Is there is any possibility (special approach or wsdl2cfc utility) to generate web service (or it’s stub) with complex input output parameters and custom failure messages based on specified WSDL? I’ve read a lot of articles which describe how to consume that type of web services, but I haven’t found any article which describes how to implement them.
you can specify the WSDL a CFC presents with the wsdlfile attribute, so you can certainly present an existing WSDL, if that's what you've got. Getting CF to map things properly when the service is invoked is another matter. I would start by taking the WSDL you have, making a CFC use it and implementing the right method names with no specified arguments and CFDUMPing the arguments structure to see what CF is getting.
You can do quite a lot to present the web service you want by using CFCs with the right names and CFPROPERTY tags in them. You can also specify in a CFARGUMENT that the type="foo[]" and the generated WSDL will expect a list of FOO objects to be passed in.
I've no experience with returning custom errors through a web service, you may have to play with what CFTHROW does from within a web service
I assume you're trying to implement a service that already exists?
I need to use the SOAP service of a printer. There is a windows tool to access this service and I used it to generate SOAP requests and responses of the important functions that I need.
Now I should write a client for Linux using Python and I found the easiest way would be to use the suds library with an WSDL file. But I don't have this WSDL!
As I investigated the windows tool (looked at the hexdump of the executables), I came to the conclusion that there probably is no WSDL file at all.
Now my question is, has anybody experience with "reverse engineering" SOAP services and knows tools which could be useful for creating WSDL files for existing services? (Googleing hasn't brought up anything useful yet).
You mentioned this is the SOAP service of a printer. Is the printer's API documented on the manufacturer's site? Does the documentation include the WSDL? Can you get the WSDL from the manufacturer?
If you can get the WSDL from the manufacturer then you're done!
If not, then you have to build the WSDL by yourself because I doubt you can find a tool that generates WSDLs given SOAP samples (when working with SOAP web services you mainly get two kinds of tools: those that generate code from WSDL + those that generate WSDL from code).
It's not hard to create the WSDL if you are familiar with SOAP, WSDL and XSD. You just need a text editor or maybe even a WSDL editor to speed things up.
If you don't have full confidence in your WSDL knowledge, there are still some tools that can get you most of the way to the complete WSDL. Here is a way you could do it:
1 - First you need to create the XML schema for the SOAP payloads. For this you can find tools, even some online. After you have the schema, tweak it to your needs by adding, changing or removing elements.
2 - Now you can use the XSD to generate a WSDL. There is an online tool that does that. It just needs the request/response element types to end with Request/Response. Make sure you read the instructions.
You take your XSD file, change the names of the operations to add the Request/Response suffix and feed it to the WSDL Generator - Web Tool. You will get your WSDL.
Now tweak this WSDL as you like (remove the Request/Response suffixes if you don't need them) then ...
3 - ... make sure you end up with a valid WSDL.
4 - Now you can take your WSDL and use a tool like SoapUI to generate sample requests and responses from it just to verify that you get the proper results back.
Do the SoapUI messages match the messages you started with? If yes, you are done and can feed the WSDL to suds to create the Linux client. If not, tweak the WSDL until you get the result you are after.
I used WCF to create a restful web service in .NET, by means of a .svc file. The web application automatically produces a WSDL file. AFAIK, the WADL is more natural for a restful web service.
How could I create a restful service in .NET (preferably with wcf) that produces a WADL description?
Note An answer like "RTFM" is accepted, as long as you indicate a suitable manual/tutorial.
This is an old question but having consumed restful services with WADLs they do offer some value. You can import them straight into SOAPUI and it will build a test suite for you automatically. Secondly they tend to contains all the required XSDs for XML based services and are useful for automatically building serialisable classes that your endpoints accept and receive.
Looks like REST Describe & Compile should do the trick.
On the WADL developer site Marc Hadley
maintains a command line tool named
WADL2Java. The ambitious goal of REST
Describe & Compile is to provide sort
of WADL2Anything. So what REST
Describe & Compile does is that it:
Generates new WADL files in a completely interactive way.
Lets you upload and edit existing WADL files.
Allows you to compile WADL files to source code in various programming
languages.
Forgive me for answering a question with a question, but do you really want to do REST? REST really has no need for things like WADL.
Update:
The "hypermedia constraint" (aka HATEOAS) dictates that the user agent discovers content based on links embedded in previously retrieved content. It really is unnecessary to have a separate document that describes all the available content.
Imagine using a web browser to go to a site and instead of going to the home page and navigating from there, you are presented with a page which is a list of all the URLs on the site. You must then looks through the list of available urls, choose the one you are interested in and copy it into the address bar.
WADL is effectively you list of site urls. You just don't need it if your main content is linked together.
Linking content instead of using a WADL "site map" has other advantages. The available links can be dynamic based on particular data values in the content. This capability can vastly reduce the complexity of clients, because the client no longer needs to host the logic to decide when it is allowed to follow a link.
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.