Greetings everyone,
Prior to my specific question, I'd like to mention that I am not looking for a step by step solution but for a possible YES or NO whether or not I will be able to achieve my goal with what I'm planning.
What I've got:
A wsdl that was autogenerated by Axis 1.3 an that is RPC/encoded. - I dont have any influence on the Webservice per se.
What I try to achieve:
Generating a Spring WS Client from that wsdl.
What I "know":
RPC/encoded WSDLs are deprecated and not "supported" by Spring WS
Spring WS can deliver any valid XML
I have to get the schema from the WSDL - > .xsd
I'm doomed.
What I'm not sure of:
is the .xsd enough or do I need to generate/write an .xjb to generate the Classes?
The Question:
Is it possible for me to get the .xsd from the RPC/encoded WSDL and generate my Java Classes for the Spring WS Client without too much "hacking around"? Or should I just go along with developing cruel Axis 1.3 generated Classes with all their miseries?
Thank you in advance.
If you don't like Axis 1.3, JAX-RPC is a slightly easier to use alternative.
Related
I have a lot of old web services.
Now the wsdl is public, so i need to hide the wsdl.
My configuration is jax-rpc 1.1 + Weblogic 12.1.3.0.0
I have searched a lot, but none of the solutions found have worked for me:
I don't have the option in Weblogic to hide the wsdl (in the documentation appears this option but in my weblogic not):
#WSDL(exposed = false) (¿not possible in jax-rpc?)
Implementing a class with Filter is not working
Does anyone have any idea how to hide the wsdl with this configuration?
Thanks & Regards.
Finally i solved this blocking the GET operations in the webservice (since all SOAP methods use POST )
I'm consuming a webservice where the WSDL file contains imports to other wsdl and xsd schemas, e.g:
<import namespace="http://my.api.com/" location="http://other.server.com:8888/context/services/MyService?wsdl=1"/>
which in turn can import other files
<xsd:import namespace="http://my.api.com/" schemaLocation="http://other.server.com:8888/context/services/MyService?xsd=1"/>
The client is generated by cxf with a maven plugin. The main WSDL file is added as a classpath resource. However, at runtime it appears that the client actually needs access to other.server.com:8888 to resolve the WSDL completely. So the question is, does a tool exist for importing and resolving all URLs in a WSDL so that it is not dependent absolute server URLs in other imports in the WSDL, and suitable for including in a client project?
We do not control the WSDL, so we can't change it in the source.
Edit: Looking for a tool that works on Linux
Check the ServiceModel Metadata Utility Tool (Svcutil.exe) from Windows SDK.
svcutil /t:metadata http://service/metadataEndpoint
This tool locates or discovers, one or more related documents that describe a particular XML Web service using the Web Services Description Language (WSDL).
I don't know if I understood your question correctly. I'm having my battles with Jax-ws/SOAP too. :)
If you need to generate the java classes needed to call the webservice you can use Apache CXF. Inside it you have a wsdl2java. You can use it on linux.
Another option in Java SDK, on the bin folder there's the wsimport that you can use it too.
Edit: You can change the final URL at runtime using the Service class created by Apache CXF.
new SomeRandomJaxWSService(new URL(wsdl),new QName(namespace, serviceName))
I'm working on a web-service-proxy with auditing (later on with caching = creating own responses) and I need to generate #Endpoints (such that will just forward i.e. call a remote web service or dummy atleast). Marshaling/unmarshaling seems neccessary for the proxy will add "something" to the request...
We are to use spring-ws and JAXB. Got all XSDs and static WSDLs of the proxied web service.
Any hints around? Anyone doing something similar? How are you doing it?
Is there a simple way how to achieve this using spring or spring-integration?
Thanks in advance..
This should be possible using both Spring WS and Spring Integration:
With Spring WS, you can create a proxy class for your remote WS, wrapping around a org.springframework.ws.client.core.WebServiceTemplate to talk to the WS - which has API's to take care of marshalling the request to xml and unmarshalling the response.
With Spring Integration, you can use an outbound Webservices gateway , but you will need to front it with a messaging gateway, which will act as your proxy, along these lines:
<int:gateway id="wsproxy" service-interface="..ProxyInterface" default-request-channel="requestChannel" default-reply-channel="replyChannel"/>
<int-ws:outbound-gateway id="wsGateway" request-channel="requestChannel" uri="http://serviceURL" marshaller="someMarshaller" unmarshaller="someUnmarshaller"/>
However, I would recommend the first approach of using the WebserviceTemplate, as you do not have a very complex integration need here.
Today I can tell how we proceeded without spring-integration. We found two different ways how to generate #Endpoint class.
1) Using XSLT and Freemarker we generated the endpoint class source in pre-compile phase. XSLT transformation walked thru all WSDL files to create one summary file which was then used to generate the source.
2) Using Javassist we copied the template class, then generated methods regarding content of JAXB2Marshaller instance and finally instantiated object using FactoryBean, all at server start-up.
Problem here we met was set of XSD files written in form that caused the root objects were generated without #XmlRootAnnotation. Javassist version we had internally works with Java 1.4 (no generics) so we used global customization file for XJC and forced #XmlRootAnnotation on root objects.
Both solutions have their pros and cons but both are simpler then using ESB.
Background:
I need to consume an existing web service (SOAP over http) that has a couple of issues:
1) The wsdl on the server doesn't even resemble the web service as described in their documentation, which includes a completely different wsdl file
2) The wsdl file provided with their documentation seems to come close to describing the web service on the server, but when I generated java client code using cxf and used it to access the web service, cxf throws exceptions like the following
javax.xml.bind.UnmarshalException: unexpected element (uri:"http://us-labs.companyxyz.com/", local:"searchResponse"). Expected elements are <{http://companyxyz.com/xyz-xml/2.0/}searchResponse>
... 33 more
I'm no SOAP expert, but assuming this means the namespaces in their response don't match those defined in the wsdl.
Since my application is written in java, I was able to connect and get a response using commons http client and a handcrafted SOAP request, so worst case I can fall back to that and parse the response to get what I need.
My questions:
Did I interpret the exception correctly?
If no: any suggestions on how I can debug this?
If yes: can anyone suggest better alternatives to handcrafting http requests and parsing xml by hand? (Getting correct wsdl is, unfortunately, not an option)
Thanks in advance.
Most likely. The response is using the namespace "http://us-labs.companyxyz.com/", but in the WSDL, the same element is declared with namespace "http://companyxyz.com/xyz-xml/2.0/".
I'm not familiar with CXF, but other SOAP frameworks usually offer some kind of logging capabilities. It would probably help you if the SOAP requests and responses are logged somewhere for more specific analysis.
Why is it not an option to get a correct WSDL? If you really are able to "handcraft" correct SOAP requests and expect to be able to "handparse" the responses, you should be able to write the WSDL yourself as well. Of course, the WSDL should be provided to you by the service operator, but if you mean that noone is able to provide you with a correct WSDL, I would consider writing it myself instead of creating and parsing the SOAP messages manually.
I think you interpreted the exception correctly - the namespace is different than expected.
It is also not really unexpected. it is a fact of life that vendor supplied wsdls are not always correct. We actually write our own WSDLs and XSDs for vendor applications for just that reason.
You can use your own WSDL even run-time. There are some SO questions on that, here and here.
You could also have a look here. I haven't tried it, but it could work.
We actually extend the generated service and create a port supplying a WSDL located on the classpath using the JaxWS Service constructor. That works fine for us.
We debug CXF by dumping the incoming and outgoing messages. There seem to be quite a lot of methods to do just that. We use either a proxy between de web service and our client, or recently a cxf.xml file somewhere. Using a -D flag we temprarily configure this.
-Dcxf.config.file=/home/me/cxf-debug.xml
and cxf-debug.xml contains something like:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cxf="http://cxf.apache.org/core"
xsi:schemaLocation="
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
</beans>
http://cxf.apache.org/docs/debugging-and-logging.html
Both responses suggested the same basic approach, which turned out to be the correct one.
I fixed the provided wsdl to make it match the web service, and I was able to use cxf, which saved me a lot of hand coding.
The main problem with their wsdl was in fact a namespace issue. The essence of the problem was as follows: their wsdl defined two namespaces, both of which have a "searchResponse" element.
{http://us-labs.companyxyz.com/}searchResponse
was defined in the wsdl to contain 0 or more
{http://companyxyz.com/xyz-xml/2.0/}searchResponse
But in their response the nested searchResponse wasn't qualified by {http://companyxyz.com/xyz-xml/2.0/} so cxf interpreted it as a {http://us-labs.companyxyz.com/}searchResponse
I fixed it by introducing a new type.
Thanks to both responders.
I have done this on Websphere (re: title of this topic) using wsdl2java for generating wsdl to java mapping xml file.
My endpoint is a generic stateless EJB. The code in EJB is generated by traversing the each wsdl and getting the wsdl operation and stuck it in the generated remote EJB interface.
Each EJB method impl is generic and handles all the services the same.
Used instructions on this doc to do this on WAS: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/twbs_devwbsjaxrpcwsdl.html
Now, I am asking you all for help if anyone has done something similar in Sun AS 9.1.
Starting from existing WSDL (and xsd) files. Knowing the sole EJB service endpoint implementation for each services are the same, and generating an EAR file (webservices.xml, ejb-jar.xml, etc).
Have struggled with wscompile and alike, but not getting anyware in the same fashion I did for WebSphere.
Thanks for help.
You want to create a WS client which runs under Sun AS? I don't know Sun AS in detail and I don't know the WS libraries it supplies. But you may want to use a public WS library:
Apache Axis 2
Apache CXF
For every library there is documentation which describes how to create a project from WSDL.
You could even use Eclipse to create a project from WSDL for you: File -> New -> Other... -> Web Services -> WSDL. Make sure you have the "WST Web Services" Plugins installed.
I've never used it myself, but I just recently read about the wsdlLocation() attribute of the WebService annotation, which is supposed to map the service to a preexisting WSDL document (not sure if you're even using EJB3, though).