I have been given WSDL and XSD files for Tibco Web service. Along with that I have Tibco queue details.
I need to hit the Tibco sync queue and get the response from the queue.
My question is hot to create the java stub(client) with appropriate endpoint address.
When I create the stub using CXF, it says "nvalid endpoint address" while I running the stub client.
There is another option to send request to queue using spring's WebServiceTemplate. But to construct the input XML message.
Does any one call the Tibco webservice from Java? Which is the best way?
I think it would be helpful if you post the actual WSDL you have problems with.
I assume the WSDL was generated with TIBCO Businessworks. TIBCO supports exposing WSDL's with JMS Transport bindings a long while in a proprietary way before a SOAP over JMS standard from W3C was defined.
CXF implemented the W3C standard so it won't understand the binding and you ll have to do some hand wiring for the transport of your client like described e.g. here:
http://cxf.apache.org/docs/using-the-jmsconfigfeature.html
Make sure that the problem is actually in the generated client, and not the WSDL or the given endpoint is worng, First try to test the wsdl with SOAP UI or any similar tool.
if it works then you can check what is wrong with the generated client.
Related
I'm experienced in creating soap webservice clients with cxf and jaxb.
However now I have a jaxb java mapping class, and have to send this as XML using HTTP POST/1.1 to a URL path.
Question: can this be done using cxf? Or if not, with spring? I especially need (de)-serialization of request and response, automatic logging, etc. Just as it is the case with cxf soap clients.
Yes, you can use CFX for JAXWS clients. You simple need the WSDL from the service provider. Then you use wsdl2java tool to turn the WSDL into Java stub code that you then compile along with your application.
There is a really good guide here.
Before anything else, I want you to know that I can already connect to the web service server. I'm asking this question because I want to gain a deeper knowledge on how a wsimport generated client works. Based from my research, wsimport uses JAXWS. Please note that I have no knowledge from JAXWS.
I generated my client using wsimport. The WSDL I used is from an Axis2 web service and was automatically generated by Axis2. The classes below are the results of wsimport:
Under com.datamodel.xsd
DataBeanRequest.java
DataBeanResponse.java
ObjectFactory.java
package-info.java
Under com.service
MyWebService.java
MyWebServicePortType.java
MyMethod.java
MyMethodResponse.java
ObjectFactory.java
package-info.java
With the classes above, I can that tell that com.datamodel.xsd contains the beans used by the web service server (excluding ObjectFactory and package-info). Meanwhile, MyMethod and MyMethodResponse are also beans used to set the request and response parameter of the web service method/operation.
Below are my questions: (You don't really have to answer all of it if you don't know the answers on some of my questions. :) And please feel free to share any info that you think I might find useful.)
Am I correct with
Am I correct with my assumptions above?
What are the function of the other classes?
I inspected MyWebService and it contains an annotation referring to the absolute location of the WSDL I used to generate the client. What is the relevance of specifying the wsdllocation in the client? How does the client use that info?
I noticed that the actual URL of the web service is not declared in any of the classes generated. How does the client know where it needs to connect to?
Was the WSDL file annotated so that the client can read the URL on the WSDL file upon connection? If so, then does it mean that the WSDL file is always read when a new connection must be established?
Since there's a need for me to compile my application and install it on a different server, the will become invalid. Can I set it to a relative path instead of an absolute path? How? (Answer: Yes, it can be set to a relative path. The wsimport command has a wsdllocation attribute wherein the value of the wsdllocation can be specified.)
What if I need to connect to an HTTPS. How can I set the server certificate?
Is there any difference when I generate my client using wsimport and when I generate it using Axis2 or Apache CXF.
Before I answer the questions, some clarification: JAX-WS is a specification for implementing web services in Java. It describes how WSDL artifacts can be mapped to Java classes and how this mapping can be applied using annotations. You can download the specification here. The tool wsimport is part of the reference implementation of this specification and the reference implementation is part of the Java class library. There are several alternative implementations, such as Axis2, CXF or Metro, that enhance the basic JAX-WS support with support for additional standards such as WS-ReliableMessaging or WS-Security.
Now to your questions:
Am I correct with my assumptions above?
Yes, you are.
What are the function of the other classes?
The package-info exists to map the XML namespace used in the web service to the package in which your implementation classes reside. The namespace normally looks different from a Java package name (normally, it is a URL) and this makes the mapping necessary.
The ObjectFactory allows you to create any of the messages sent and received by the service. You need this if you want to hook in code in front of your stub class, provide modified messages or similar things.
I can't see the content of your classes, but if I understand it right MyWebServicePortType is an interface that resembles the portType in your WSDL. That is, it maps the operations and their signatures in the WSDL to Java methods. If you want to provide the service (which you don't, you are asking about the client), you would need to implement this interface. As you implement the client, you simply use it.
Finally, the class MyWebService contains the client stub you need if you want to invoke the web service.
I inspected MyWebService and it contains an annotation referring to
the absolute location of the WSDL I used to generate the client. What
is the relevance of specifying the wsdllocation in the client? How
does the client use that info?
The interface you generated contains the signature of the portType of the service, but it does not explain how you can talk to the service. This is part of the binding in the WSDL. The most basic setting is a document/literal style for the messages using SOAP over HTTP. Other configurations, such as SOAP over JMS, are possible and your client needs to know what protocol to use. Therefore it needs the binding WSDL. Also, as you state later, there is no endpoint address in your Java files. This address is also read from the WSDL.
I noticed that the actual URL of the web service is not declared in
any of the classes generated. How does the client know where it needs
to connect to?
It reads the address from the port of the service in the WSDL. This is located of the end of the WSDL.
Was the WSDL file annotated so that the client can read the URL on the
WSDL file upon connection?
No, the port is a typical element of a concrete web service endpoint. There's nothing special needed here.
If so, then does it mean that the WSDL file is always read when a new
connection must be established?
Well, there could be caching at the client side (I don't know about the details of the reference implementation on this one). From a conceptual point of view: yes, it is.
What if I need to connect to an HTTPS. How can I set the server
certificate
This can be tricky, I can't give you an out-of-the-box answer. I would suggest to read through questions on this topic, such as this one.
Is there any difference when I generate my client using wsimport and
when I generate it using Axis2 or Apache CXF
Yes, there is. wsimport is better, don't use wsdl2java. Here is a description, why.
You asked: I noticed that the actual URL of the web service is not declared in any of the classes generated. How does the client know where it needs to connect to?
If the WSDL was downloaded using a browser and passed as input to wsimport, then the local wsdl file location is embedded into the generated code. That is why you don't see the actual service location in the generated code. It also means if you deleted the local copy of the wsdl file the generated code will not work (when inovked using a main method) .
If the URL of the wsdl was passed as input to wsimport then that URL is embedded in the generated code, which is further used to get the actual service location. The idea is that the WSDL locations are fixed. They are expected to be in a UDDI or as a local file. This allows the actual services to move around and if they do move, you just have to modify the local copy of the wsdl file alone or update the wsdl in the UDDI. [mostly this does not happen as service locations are never IP but DNS names]
This is why it is never a good idea to publish the wsdl in the same server where your webservice is running
edited the question to improve clarity.
I am trying to learn SOAP based Java Web services.
I created a simple web service using the #WebService annotation. I published it in my local machine and I consumed the service in my local machine. I found out that the WSDL file is auto generated and the SOAP messages are 'under the hood'. I was able to track the SOAP messages only through TCP/IP monitor.
I later found that Java SOAP API give the option to create SOAP messages ourselves and transmit them using classes/interfaces like MessageFactory and SOAPMessage.
My question is, if WSDL and SOAP messages are generated and handled automatically, why would we need SOAP handlers to manually create and send SOAP messages using the Java SOAP API?
My question is, if WSDL and SOAP messages are generated and handled
automatically, why would we need SOAP handlers to manually create and
send SOAP messages using the Java SOAP API?
Because you might want to have more control over SOAP communication, building a SOAP message etc. When mentioning MessageFactory and SOAPMessage, you're actually referring to SAAJ. Compared to JAX-WS, SAAJ is operating at lower level with all pros and cons that this approach brings. From Java rocking:
JAX-WS versus SAAJ
From a practical standpoint, using SAAJ means that you don’t use tools
such as 'wsimport' or 'wsdl2java'. Those are for use with JAX-WS, and
are the means by which a client can generate domain objects and
operate almost as if they were not using web services at all. With
SAAJ, you have no domain view of a service. You are really working
with the plumbing. Development with JAX-WS can be much quicker and
easier, and generally does not cause you any loss in control. But
JAX-WS is a convenience layer, and it can be comforting to know that
if you wield some command of SAAJ, you’ll be ready to do anything that
a WSDL interface requires of you.
Personally, I would always go with JAX-WS.
You don need to use Java SOAP API explicitly when you use JAX-WS. But you choose to write SOAP messaging applications directly, then these APIs come into picture.
An hypothetical example would be that you want more control over the SOAP message parsing. You do not want to process the entire XML but a part of it using xpath.
So I have a simple xml-rpc server (xml over http) provided to me to use. But the thing is, the server is not equipped with wsdl. I don't have access to the server code, so I don't know about their implementation of it
How can I develop an xml-rpc client in Java, with no wsdl provided, without using 3rd party library like the Apache xml-rpc client?
Please help.
The wsdl is only really useful with a 3rd party library, because it helps you generate objects that can be serialized to xml without hand-coding the xml.
If you don't have the wsdl, you must either hand-code each xml message you send and hand-parse each message you receive, or create a set of objects on your own and serialize and deserialize them appropriately.
Wsdl file will only help out, without that you'll be unable to generate client and neither you can test your application. Even if you have connectivity to server.
I would like to be able to see the XML Stream generated by my CXF generated from WSDL client.
Is there a way to do this ?
For example, I'm building my request with Java objects, and I would like to see the XML stream built by CXF before it sends it to the server.
Thank you for your answer !
You can use the LoggingInterceptors CXF includes.
See:
http://cwiki.apache.org/CXF20DOC/debugging.html
You can use TCPMon to capture the web service requests and responses as they're sent and received.