If a SOAP web service is working well via SoapUI (producing the correct SOAP responses), while building a web service client in Java using different APIs/frameworks to call this web service is facing different issues, is it safe to consider this web service stable and the issues are from the consumer side?
I'm asking a generic question in here, I have already asked a detailed one which is probably too long to read. I'm interested in the concept more than my actual implementation, so if you can answer my question without referring to my longer post, please do.
UPDATE:
I have realized that even if the WSDL is WS-I compliant and it's functioning correctly via SoapUI, this is still not enough to conclude that the web service is not broken. As #jtahlborn said, SoapUI is very tolerant to broken web services, and it could easily trick you to believe your web service is working fine, which is what happened in my case.
I'm constructing the SOAP response in the ESB and my issue was that I used a namespace that was defined in the WSDL but not in the schema. SoapUI received the response and showed it to me (with the wrong namespace); this issue could have been avoided if I turned on the response validation option.
It's also noteworthy to mention that in the Java web service client I created to test my web service, the response could not be loaded into the output object (a NullPointerException error showed up when I tried to access the output object), this was due to the namespace issue and it started working correctly once I fixed the namespace.
SoapUI is a fantastic product. one of the things which makes it a great product, however, is that it is very tolerant of poorly defined webservices. in our product, we deal with lots of webservices, and a frequent comment on an issue in our product is "it works fine in SoapUI". we have learned the hard way that SoapUI will tolerate all kinds of broken webservices. so, in summary, working with SoapUI is not a proof that your webservice is well-defined.
There are WS-I testing tools to check your web service for conformance to the Web Services Interoperability profiles. If your service adheres to the WS-I basic profile, and SoapUI can call it, the issues are definitely on the consumer side.
EDIT: well, or in between the both...
SoapUI can check your wsdl for WS-I compliance, see http://www.soapui.org/SOAP-and-WSDL/working-with-wsdls.html.
It's most likely that the consumer (client) is buggy... If the client is generated using wsdl2java it's a big chance to have bugs in it... and if you are using some special functionalities that are valid (conforming w3c) then don't be surprised... the generated clients sometimes do this... even some libraries used to generate java classes or libraries to generate the webservices are full of bugs...
A lot of things are not supported by known and frequently used libraries... (I don't want to give names -- but wsdl4java is not perfect)..
If you are using security or something ... higher chances to have bugs on both server and client side :)
maybe if you tell us what is the problem we can help you...
Related
This question already has answers here:
RESTful Services - WSDL Equivalent
(8 answers)
Closed 3 years ago.
I am implementing a web service and I have implemented both a REST and SOAP version to see which suited my needs.I have decided to choose REST because of its simplicity and that I will probably be developing an iPhone app to consume it. My question is simple really, is it possible to create a WSDL or WADL for my REST service and is it necessary?
Thanks
With a good RESTful service, it's not necessary to generate WADL (let alone the much-less-well-fitting WSDL) for it because it will self-describe. By “self-describe” I specifically mean that it will deliver documents describing all the (relevant) resources published by the service, and that using a standard HTTP OPTIONS request on any of these will produce basic information about how to interact. The only real benefit to using WADL is that it allows the caller to discover the schemas for the complex documents it needs to work with ahead of time; REST itself provides no help there (and some RESTians believe that doing such things is counter-productive, which I'm not sure I agree with).
Of course, that doesn't capture the deeper interaction patterns, but neither do the vast majority of WSDL descriptions of services so no change there.
For the record, I use Apache CXF to create RESTful services (using JAX-RS) and that publishes WADL for them.
The W3C has made a formal recommendation for a REST documentation standard based on [WSDL 2.0][3]. Here is a quote from the IBM article:
The term Web services is typically associated with operation- or
action-based services using SOAP and the WS* standards, such as
WS-Addressing and WS-Security. The term REST Web services generally
refers to a resource-based Web services architecture that uses HTTP
and XML. Each of these architectural Web service styles has its place,
but until recently, the WSDL standard didn't equally support both
styles. The WSDL 1.1 HTTP binding was inadequate to describe
communications with HTTP and XML, so there was no way to formally
describe REST Web services with WSDL. The publication of WSDL 2.0,
which was designed with REST Web services in mind, as a World Wide Web
Consortium (W3C) recommendation means there is now a language to
describe REST Web services.
As #GiuliaDiFederico said, "of course it's possible" (with WSDL2), showing a good source link about how to do. #DonalFellows, by other hand, does not encouraged the use of WSDL...
I think the use of WSDL is a question of
FORMALIZATION LEVEL: with WSDL you can express more formally all relevant details of your webservice.
STABILITY LEVEL: if you need long term contracts, and avoid risks of changes in the enviroment where your webservice is exposed, WSDL helps to mantain stability.
NEED FOR STANDARDS: if customers prefer webservices that can be said "standard compliant", use standards. The only one is W3C, and W3C requires XML, SOAP and WSDL.
RestDoc tries to create a simple documentation framework for REST resources.
A browser is available via restdoc-renderer.
It also offers Java annotations to enable on-the-fly creation of RestDoc documetnation. Implementations are available for Jersey 1.x and JAX-RS 2.0.
Of course it's possible, but for answer if it is necessary or not, you didn't provide enough info.
I suggest you to take a look on the ibm's developerworks site that provide an interesting article on subject
Strictly, with WSDL 1.0 you can' t, but with WSDL2 you can, because was developed for accept this kind of demand,
"... WSDL 2.0 in a WS-I profile that addressed the requirements
for REST style Web services. The addition of GET in SOAP 1.2 and several
additions in WSDL 2.0 such as operation safety, the ability to describe
messages that refer to other Web services, and the improved HTTP binding
now make it possible to describe REST style Web services.", Arthur Ryman.
I think WSDL is not appropriate for REST and WADL is not necessary. HTTP exposes already what WADL could describe in a separate file. For example the "Allow" header returns allowed HTTP method, and Content Negotiation is for choosing the right format.
WADL is not necessary. But, If Client side code is already present in an application and you want to make a new rest call then it is good practice that you use wadl for generating the client side java stub(POJO). By this way, client side POJOs will be in sync with service side POJOs. For example, If you are replacing EJB/SOAP service call with Rest service call in an existing application then It is very safe and good practice to use WADL.
You can generate client side java stubs from WADL by using wadl2java maven plugin.
I'm working with a client that's on a currently purely-MRI Ruby/Rails stack, but we have a 3'rd party service we need to start interfacing with that is built on .Net with WCF and the only way to access it is SOAP. They are using MS-LWSSP (MS documentation) as a security protocol and none of the Ruby SOAP libraries seem to understand how to connect to it.
We are considering adding JRuby to the tech stack (as a separate small application) to connect to this service, as Java has offers more choices for dealing with SOAP. However, I'm not familiar with any of the Java SOAP libraries.
I have seen some other posts about using a Java client to connect to a .Net SOAP service, but I have not seen any specifically addressing using this security protocol. Their SOAP service is SOAP version 1.2 and it does have a WSDL we can access.
Has anyone done this? Could you please provide me with information about what libraries would be helpful in doing so?
Thank you very much for any suggestions or information.
This is an old question now, but I'll respond with what worked for us. Or more correctly, what never worked for us.
None of the Ruby SOAP libraries were compatible with the protocol we had to use. We spent quite a bit of time on trying them out but they simply didn't work with the client. We considered look into implementing the protocol ourselves, but that was far more effort than we wanted to spend on this.
In the end, we requested the client to give us access via a non-SOAP route and that worked out much better.
The moral of the story: try asking if you can have non-SOAP access. It'll save you a lot of effort and headaches.
Here is the situation. I have received a WSDL (and included XSD) from someone that is generated by an Apache/Tomcat server (Java). The company i do a project for, prefers .NET so i used wsdl.exe to generate a partial class and created the webservice.
Then I created a .NET client (in this case I am using VB.NET) that has a web reference to the java wsdl. This works fine. Then I change the url using code and make it point to my newly created .NET service but i cannot seem to get it to work.
Doing it the other way round, also doesnt seem to work.
Been fiddling a bit with the namespaces and the service name but can't seem to crack it. Keeps giving me an error about HTTP header unable to find . as a method. This indicates a transport problem.
I really do not want to revert to plan B, being the creation of a Java Webservice and then linking this to the .NET environment. I know this will work since you will never have to change the urls.
Any suggestions ?
So to summarise you have:
SERVER SIDE: java, WSDL: java generated
.NET client -> java server - WORKS .NET client -> .NET server -> FAILS
If thats the case this has not much to do with Java!
But I do know as I aluded to earlier that .NET servers are fussy about the soap action header.
Is there a soapAction in your WSDL?
If so, you need to send that value, but I don't know how to do this in .NET (Google would be your friend here).
If not, check out the comments in this question for how to determine the required soap action header value: stackoverflow.com/questions/2262781/soap-action-wsdl
After a bit of searching through the devine knowledge base (Google), i have managed to get this fixed.
In addition to being very carefull in specifying the portnames (the default ones are not always what is requested so you need to override it) but most importantly, i found that adding
as part of the asm class header solved my problem. Now all I need to do is find out why?
But trust me, it works...
I found the solution here
I am new to consuming web services. I am trying to consume a SOAP service. This is currently in the test environment. What I have done is
Use wsdl2java to generate a wsdl that I have copied to my domain folder.
Use the API to send requests and receive responses.
What concerns me is do I need CXF or Spring WS to wire the service or is what I have sufficient. I am asking this because I have seen elsewhere like
What I don't get is where I would generate property when environments are switching from development to QA to production. And do I need to use CXF or Spring WS or are the annotated classes (#WebServiceClient sufficient) to consume the SOAP service. Basically, how to connect to different endpoints.
I apologize if this is rudimentary question. Thanks.
Spring-WS and Apache CXF are primarily useful for creating web-services. They are alternative web service implementations to the one that ships with Java6.
You can use them for writing clients, but there's not really much point, unless you're really keen on the alternative API that those provide.
The standard JAX-WS artifacts generated by wsdl2java should be perfectly sufficient for what you need.
As for your second question regarding how to target different prod/QA endpoints, you should ask a separate question for that, with full examples of what you have.
We have a small app with Restlet on the GAE server and GWT and Android clients. Restlet serves GWT-serialized replies to GWT clients and JSON to Android clients.
All is ok with GWT-serialization both locally and on AppEngine production servers.
All is ok with Android (JSON) clients talking to local dev server.
Android taking to production AppEngine server GETs JSON replies, but POST fails. There is no error or warning in logs. The function on server gets called but parameter passed is null.
This is the offending code:
#Post("json")
public void createLocationJSON(Location location) { // location is always null
// do something with 'location'
}
Just to let everybody know: I managed to get GAE+Restlet+JSON+GWT working after much fiddling. The process was really chaotic (reminded me of days programing for the Win32): I was just changing settings until it started working.
The problem that I was having is:
It was serving the wrong representation (JSON, XML, GWT) to the wrong clients. Later it turned out that I had to pay attention to the order of methods inside the class. WTF??
I could not get it to work on sub-path, e.g. /rest/*.
I'm not going to use Restlet for the following reasons (hint to authors):
Documentation is scarce, inaccurate and sometimes contradictory (explaining thing in different ways in different parts of documentation).
Configuration is not standard JAX-RS. I know they have an option to configure it as JAX-RS, but all examples in docs are not based on this.
Since then I switched to Jersey.
You encountered a limitation of GAE that several Restlet users faced.
Some time ago, GAE stopped supporting accepting chunked HTTP entity. We reproduced this issue with both POST and PUT and raw GAE Servlets, so this isn't Restlet related. See GAE issue:
http://code.google.com/p/googleappengine/issues/detail?id=129
The only workaround we found is to not chunk entities, meaning being able to compute their size in advance.
In Restlet 2.1 M3 version that we just released, we added a simple "entityBuffering" property on ClientResource to facilitate this (set to 'false' by default).
We are in the process of upgrading our "First Application" example to illustrate the workaround. We also had to cope with GWT 2.2 breaking compatibility with its previous GWT 2.1 core API, so Restlet 2.1 will only work on GWT.
Addition details are available on this page:
http://wiki.restlet.org/docs_2.1/13-restlet/21-restlet/318-restlet/303-restlet.html
Best regards,
Jerome
Restlet ~ Founder and Technical Lead ~ http://www.restlet.org
Noelios Technologies ~ http://www.noelios.com