I have a requirement of creating a Web Service interface using multiple existing WSDLs files having different namespaces. Some of the methods parameters in these WSDL have common name e.g. userID is used as parameter in multiple methods/operations.
I tried generating proxy classes for each file and then manually copy pasting required methods web service project. Using IntelliJ Axis2 resulted WSDL definition differs from actual WSDLs definition e.g. userID parameter gets renamed as userID0 and UserID1. Using visual studio (wsld.exe) resulted WSDLs definitions are close match of actual WSDL definition but when I deploy service on server parameters always received null may be due namespaces issue.
I was just wondering if some one can guide me what are the best practice/way of creating a single web service interface from multiple existing WSDLs having same definitions as of original WSDLs.
Related
I have a web application that is using (calling) two identical webservices, they only differ in URL. I use Netbeans 8 to generate the webservice clients, both of which are in the same separate project but in two separate packages. The main application packages everything in a super jar.
Deploying the super jar to Weblogic causes a JAXBException, name collision. The relevant part of the error message:
Two classes have the XML type with uri http://yet.another/useless/namespace/url and name fault.
All of the classes have identical names, yet it's the one with the name fault that is bothering Weblogic.
I could totally separate these web services into different enterprise applications of course but that seems like overkill.
I read the WSDLs from a remote server and don't really have a chance to convince our contractor to change namespaces.
I just worked around it: I'm using Axis2 to generate client side code as I'm free to perform whatever refactoring is necessary on it to avoid name collisions. Morale of the story: Avoid IDE wizards (if they cause trouble).
My messaging provider gives me two different kinds of WSDLs to use.
http://my.amazonaws.com:8000/webservice/?wsdl
http://my.amazonaws.com:8000/webservice/?singleWsdl
The first one is an embedded WSDL. Can NOT use it to generate WSDL2java packages and
can NOT use JAX-WS to create a connection.
The second one is a single WSDL. It can generate Java packages with CXF 3.0's WSDL2java and can use JAX-WS to create a connection. It works very well.
Please let me know what is the difference between these two kinds of WSDLs.
Without knowing what those links return we can only guess, but here are some details that might help you....
Suffixing the web service endpoint with ?wsdl get's you a WSDL file. The WSDL can be generated by the framework at runtime based on the web service skeleton code or can be an actual physical file that the server just sends back when the URL parameter is specified.
The WSDL contains an XML Schema that can be specified either inside the WSDL itself or as separate files that are imported by the WSDL. And now a problem occurs...
Some web service stub generators can only handle a full WSDL, with the Schema inside. If the WSDL imports other files the tools can't resolve the imports and fails. This made web services hard to consume because clients had issues creating stubs to interact with the web service. So much so that service providers either used an actual WSDL to respond to the ?wsdl request or started writing all sorts of hacks and plugins to make the web service generate the full WSDL.
But some providers didn't even bother so clients had to write the hacks to parse the WSDL or they had to download all files, assemble them manually into a single file and use that instead.
With time people recognized this as a problem and frameworks adapted to provide the full WSDL, not one with imports. But this generated another problem. Changing what the ?wsdl URL returned could break all those hacks created around it to fix the import problem. For this reason another convention was chosen to return the full WSDL: ?singleWsdl.
So there are frameworks that generate a full WSDL, some that generate it with imports, some allow you to specify an actual physical file, some that support the ?singleWsdl convention, some that don't. Not relevant to this question, but just for completion, there is also a ?wsdl2 convention that get's you a WSDL 2.0 definition (?wsdl get you a WSDL 1.1). Some frameworks support ?wsdl2, some don't.
My guess is the issues you have are caused by Schema imports, but without the WSDLs themselves I can't tell. Hope at least that these details help you better identify the problem.
Is it mandated by any standard that a web service should provide a WSDL by appending ?wsdl to the endpoint address?
Is it OK if the WSDL is hosted at a different URL (without appending ?wsdl)?
For example:
Endpoint: http://abc.xyz.com/MyService
WSDL: http://abc.xyz.com/MyServiceDefinition.pqr
Note that I'm even using a different extension for the WSDL definition.
Does using this approach violate any standards or one can host the thing the way they want?
Is it mandatory to have a WSDL definition accessible using ?wsdl?
No, it's not.
A WSDL is used to describe a web service contract and is provided because it allows tools to automate generation of client stub code for calling the specified web service. Exposing the WSDL at the same location as the web service with ?wsdl appended to it is just very handy and that's the convention everybody uses.
People and tools look for the WSDL at that location and frameworks automatically expose it at that location but it's just a convention. As to my knowledge this isn't specified in any specification (or at least none that I could find).
Sometimes though you don't want to provide a WSDL that everybody can look at and try to create a client because it's a private web service and you only want to give access to your partners, not to everybody. At that point you can disallow the ?wsdl URL and provide the WSDL only to your partners by using an alternative channel. You can even e-mail it if you don't want it exposed online.
So you can choose whatever channel to expose it. Just remember that because people and tools are following this convention they are used to see it there and some (poorly written) tools might choke in a different extension, for example.
P.S. One other thing I wanted to mention - which isn't strictly related to this answer but kinda reinforces the convention - is the new ?singleWsdl option in WCF 4.5.
WCF, as most other tools, exposes the WSDL at the ?wsdl address but uses xsd:import statements with external schemas. Some frameworks were not able to process WSDL with imported dependencies so people started to write customizations over WCF to have a flat WSDL exposed, so much so that in the latest version of WCF Microsoft decided to add this feature out of the box.
But for backward compatibility they needed to keep the ?wsdl endpoint as it was (returning a WSDL document with xsd:import statements inside) and were forced to add a new query parameter for the flat WSDL: ?singleWsdl. I'm sure this idea will be picked up by other web service vendors and providers as well.
No, Its not mandatory to have ?wsdl access, but its recommended way.
Its worth noting that most clients will try to append "?wsdl" to your URL and will try to access WSDL file, Hence its highly recommended to setup it.
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 am trying to consume multiple Web Services that redefine some of the same common classes in their wsdl. I currently have them referenced in a Web Site, but I want to convert to Web Application.
Since some of the same classes are redefined from multiple Web Service, the problem is that when adding them in a web Application there is no way to make the namespaces the same across multiple Web Services, like you can in a Web Site.
Is there any way to do what I am looking for?
Show all files in your project, then hand-edit the autogenerated Reference.cs files to change the namespaces (and remove duplicates)? Ugly, but it ought to work.
Alternatively, use wsdl.exe from the command line -- it can generate a single proxy for multiple services -- and then add the generated file to the project manually. The syntax is something like: wsdl http://svr/foo.asmx http://svr/bar.asmx /namespace:Fnord.Proxies