I am wondering if anybody knows if wiremock has support for WS-Policy in regards to SOAP webservices?
What I'm after is to give wiremock a WSDL that has some WS-Policy in it, that contains the "reciepe" for what the response should look like. Ie timestamp in the header, signed body, etc.
So, ideally I'd just specify the soap body and wiremock would apply the WS-Policy and add the necessary signatures.
I found this github issue that mentioned SOAP support, but the impression I got from that support was that it was just an arbitrary text response without having actual SOAP understanding/processing.
Would it be possible to plug-in Apache CXF to get proper JAX-WS/WS-Policy support if I were so inclined? Or would it be difficult to offload response processing to a third party library?
No such support I'm afraid. SOAP requires a lot of tooling to in test contexts.
I posted my solution to this problem in another similar question. The crux of it was some hand crafted SOAP manipulation and WireMocks CustomRequest matchers.
Related
I am calling a soap web service from Apache Camel, which is having header (for authentication) and the body. My Dataformat is POJO (tried with PAYLOAD too) Nothing got succeeded.
echange.getIn().setHeader() is not working (Checking the request using tcpmon)
Any suggestion or coding will be helpful.
Please refer http://camel.apache.org/cxf.html
Hope this is helpful.
I have a JAX-WS #WebServiceProvider and would like to support both SOAP 1.1 and 1.2 protocols. I handle creation of response SOAPMessage of proper version manually. I have WSDL describing bindings for both, 1.1 and 1.2 protocol.
But the service endpoint is only able to support either version at a time.
I would appreciate either a solution or a pointer to a piece of doc where it's stated that it's impossible.
P.S. i'm using WebSphere 7 app server, which is bundled with JAX-WS 2.0 (which is Axis2 based)
I experienced the same problem. The main issue for me is that it is not possible to compile the class with both #BindingType(value = SOAPBinding.SOAP12HTTP_BINDING) and #BindingType(value = SOAPBinding.SOAP11HTTP_BINDING). Have a look to this http://www-01.ibm.com/support/docview.wss?uid=swg1PK96819, and this http://www-01.ibm.com/support/docview.wss?uid=swg1PK83482, it should be possible to set #BindingType(SOAPBinding.SOAP_HTTP_BINDING) to have the both SOAP version to be delivered. Unfortunaltely, i did not compile also with the Websphere runtime environment, what i don't understand.
I recently dealt with a service deployment issue related to trying to simultaneously enable both SOAP 1.1 and 1.2 for a service (on WebSphere v7.0). Unfortunately, I don't think that your question gives enough information to provide a specific solution.
It IS possible to support both bindings at the same time, but there are some considerations. I think the main thing is that the server has to be able to listen on separate endpoints (URLs) for each binding. As near as I can tell, this requires appropriate entries in your web.xml and/or your webservices.xml configuraiton files.
For an annotation based service, these configuration entries are theoretically optional; but when you try to enable multiple bindings for a given service without the "optional" configuration entries, the WAS Axis2 extension fails with various possible exceptions.
If you could provide more detail about your wsdl, and the relevant portions of web.xml and webservices.xml (if any), as well as any error messages reported in the WAS log(s) during deployment and application startup, then I could probably give a better answer.
I am new to Spring web services. I am going to create an xml request, and send it as a SOAP request to a web service and receive the response.I read different documents but still confused as I could not find a working sample yet.
I know that I should use WebServiceTemplate and WebServiceMessageSender, SaajSoapmessageFactory (please let me know if I am wrong) but not sure how to use them.
Do I need WSDL? if yes why?
If you have any sample code please send me to get clear on it.
Thanks
If you want to send SOAP requests, you would like to be a SOAP client. Seems like you want to use spring-ws project. Check out their great documentation on the client side. The same documentation will guide you through the process of creating a server. There are plenty of examples and ready-made configuration snippets waiting for you.
Spring-WS is built on top of XML Schema description of your message, so you will need WSDL to generate e.g. JAXB models of your requests and responses.
AFAIK, for "web services" , the WSDL file is the machine blueprint of the "ports" as they are called However! ports in WSDL "means" java language(or any other programming language used with a routine or sub or procedure or function) method and has a specific naming scheme associate the .wsdl xml file(template of the service). Each WSDL port(language method) has specifications of return value and data specifications for how to feed it arguments and their type values.
I am using cxf framework in order to expose some web services.
When i tested it using soap-ui, it works great. But one of our customers that uses different soap client complains that the message ends with:
/soap:Envelope>
--uuid:91c5694a-93f5-404c-ab2b-8c220b7f289f--
I searched the web, and i found that this line apears not only in our system. But I couldn't figure out whether this suffix is valid and well-formed, or not.
Is there any reference that document this issue?
Is it really valid?
How can I remove it?
Thanks!
It sounds like you have MTOM enabled on the server side. In that case, the SOAP message is wrapped in mime wrappers (which is per spec). The --uuid thing is a marker of a mime part. If the client is having issues with those, then it sounds like that client cannot handle MTOM. You COULD turn MTOM off for those clients.
If I need a web service to pass back and forth a complex object, is there a reason I should prefer SOAP over REST? Here is an example of the possible SOAP message:
<soap:Envelope>
<soap:Header>
<Credentials>
<User>Joe</User>
<Password>abc123</Password>
</Credentials>
</soap:Header>
<soap:Body>
<MyComplexBusinessObject>
<Search>
<First>Joe</First>
<Last>Smith</Last>
</Search>
...
...
</MyComplexBusinessObject>
</soap:Body>
</soap:Envelope>
Using REST, I would be asking the client to POST the following xml and authenticate using Basic Authentication:
<MyComplexBusinessObject>
<Search>
<First>Joe</First>
<Last>Smith</Last>
</Search>
...
...
</MyComplexBusinessObject>
The SOAP message is slightly more complicated, but not by much. They are still both XML, but SOAP comes with a WSDL and most programming environments will generate proxy classes for you. However, most people I talk to say I should use REST instead because it's easier to use. But I don't see how SOAP is any harder to use.
Am I missing something?
Your first requirement of "passing back and forth a complex object" constrains your architecture to eliminate many of the benefits of REST. SOAP is designed for accessing remote objects, REST is not. REST supports passing media-types as simple as text/plain, which is far more primitive than dealing with an object.
If you haven't seen it already, this question and its answers cover most of the REST vs SOAP issues.
One major benefit of REST is that all you need to call and use it is a browser and a HTTP stack - pretty much every device and machine has that. So if ease of use and reach are you main goal - use REST.
One of the major benefits of SOAP is that you have a WSDL service description and you can pretty much discover the service automatically, and generate a useable client proxy from that service description (generate the service calls, the necessary data types for the methods and so forth).
So if discoverability and a strict, formal service description are more important to you, use SOAP (with the downside that you need a full-fledged SOAP client to call your service - your web browser won't be sufficient).
SOAP isn't harder to use - but it's just not quite as "pervasive" in terms of being available - any browser can call a REST service and get an answer - but then it needs to parse and interpret that response. SOAP gets nice data structure, but you need a SOAP client for this.
I view SOAP and REST as orthogonal APIs, designed to do different things.
SOAP is basically a fancy RPC, so if you want to send a computation request over to the server and get the result back, you use SOAP. If it would be local, it would be a method call to an object instance.
REST is a way to create, retrieve, update and delete remote objects, not in the sense of POO, using a uniform API. If it would be local, it would be like working with a file.
So they actually respond to different needs. You can bastardize one to do the work of the other, but you mangle the meanings.
If you develop both the service and the client, using SOAP is as easy as REST (actually easier).
You may prefer SOAP over REST if these conditions meet:
The entire service API is complex, not just one object.
The service is used within a relatively small network, and performance is not an important requirement.
You decide to spend the minimum amount of time to develop both the service and the API documentation.