I am testing a SOAP web service through SoapUI tool. Web Service is deployed on a server and SaopUI project is hitting that web service. My concern is while testing one request if I do not provide a mandatory input parameter even then I am getting successful response. No error at all. On the other hand, if we call the same through web application then error comes.
WSDL request:
<wsdl:message name="update_request">
<wsdl:part name="name" type="xsd:boolean"></wsdl:part>
<wsdl:part name="flag" type="xsd:boolean"></wsdl:part>
</wsdl:message>
Is it possible to call a request with less parameters through SoapUI? Why there is a difference between these two calling methods?
Using the XML view of a Test Request test step in soapUI you can freely edit what shall be sent.
Example:
<soap...>
<MyUpdateRequest>
<name>true</name>
</MyUpdateRequest>
</soap...>
I am developing a Web service using Apache CXF and contract first approach with schema validation. Problem is, that validation is not working. There is no error, so it like is not activated. But validation is configured.
So, I have took a look to official Apache CXF examples you can find here.
I took a look to wsdl_first example and modify it adding schema validation and some restriction in WSDL:
<!-- HTTP Endpoint -->
<jaxws:endpoint xmlns:customer="http://customerservice.example.com/"
id="CustomerServiceHTTP" address="http://localhost:9090/CustomerServicePort"
serviceName="customer:CustomerServiceService" endpointName="customer:CustomerServiceEndpoint"
implementor="com.example.customerservice.server.CustomerServiceImpl">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature" />
</jaxws:features>
<!-- schema validation-->
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:endpoint>
To my surprise, it doesn't work either.
OK, so I took a look to wsdl_first_xmlbeans example, where according with the README.txt file, it also shows how CXF configuration can be used to enable schema validation.
And for this example, schema validation works. The difference between both examples is that the second one use JAX-WS APIs and with the XMLBeans approach. Does it have something to do? Why schema validation is not working for first example? Probably, I am missing something.
For validation on the service side, it would likely need to have a wsdlLocation attribute set on the jaxws:endpoint so it would load the WSDL (that would then contain the schemas). Currently, the validation in that example is on the client side only. If you run the service, the log shows:
INFO: Creating Service {http://server.customerservice.example.com/}CustomerServiceImplService from class com.example.customerservice.CustomerService
which shows it's not using the WSDL at all.
I'm using CXF to generate an interface to a .NET web service client. However, sometimes when I use the client, I get an error:
WARNING: Interceptor for {http://xxxxxx.com}ChangeRequestWebService#{http://xxxxxx.com/ChangeRequestWebService}GetChangeRequestById has thrown exception, unwinding now
[com.ctc.wstx.exc.WstxLazyException] com.ctc.wstx.exc.WstxParsingException: Illegal character entity: expansion character (code 0x1b
at [row,col {unknown-source}]: [76,44]
From many other sources online, it's obvious that this is because the webservice is encoding its response in XML 1.1, while my CXF client is reading that response expecting XML 1.0, and the special character 0x1b is illegal in XML 1.0. Now, I don't want to argue about whether the .NET service should be using XML 1.1 in its response, when the WSDL is obviously 1.0 (since that's the spec). I just want to be able to read what they send without errors.
Looking at the dependencies in the CXF client, they use WoodStox 4.1.1 which (from their site) clearly supports XML 1.1. What I want to know is, is there any way to configure my CXF client (via binding at wsdl2java time, or during run-time) to use an XML 1.1 parser when receiving responses? All I can find is people saying that they shouldn't be using 1.1, or having the server-side filter these characters. Note that I can't filter the characters client-side, as I have to send the data back to the server, and validation would fail.
As an alternative, I suppose the .NET service could in some fashion SPECIFY that they're using XML 1.1 in their response, but I don't control that service, so it would be more troublesome to figure out their problem for them and then suggest they fix it. Plus, the data they're sending is in a DB, so it's not the web service's fault that it has XML 1.1-only characters in it.
It looks like the answer is... there is no way to pre-configure CXF to expect XML 1.1 by default.
Essentially, if XML comes in without a version tag:
<?xml version="1.1">
Then it isn't XML 1.1. That's the problem here. If the xml header existed and specified XML 1.1, then the parser in CXF would parse it as XML 1.1. .NET web services don't (by default) send any XML header tag, so the parser in CXF parses it (correctly) as XML 1.0.
That said, there might be a way to catch the input stream before it gets parsed by CXF, and "insert" an XML version header that specifies 1.1, which would "fix" the problem for me. If I find a way to get it to work, I'll post it.
Can somebody explain to me the differences between Document and RPC style webservices? Apart from JAX-RPC, the next version is JAX-WS, which supports both Document and RPC styles. I also understand document style webservices are meant for Asynchronous communication where a client would not block until the response is received.
Either way, using JAX-WS I currently annotate the service with #Webservice, generate the WSDL and from that WSDL I generate the client side artifacts.
Once the artifacts are received, in both styles, I invoke the method on the port. Now, this does not differ in RPC style and Document style. So what is the difference and where is that difference visible?
Similarly, in what way does SOAP over HTTP differ from XML over HTTP? After all SOAP is also XML document with SOAP namespace.
Can some body explain me the differences between a Document style and
RPC style webservices?
There are two communication style models that are used to translate a WSDL binding to a SOAP message body. They are:
Document & RPC
The advantage of using a Document style model is that you can structure the SOAP body any way you want it as long as the content of the SOAP message body is any arbitrary XML instance. The Document style is also referred to as Message-Oriented style.
However, with an RPC style model, the structure of the SOAP request body must contain both the operation name and the set of method parameters. The RPC style model assumes a specific structure to the XML instance contained in the message body.
Furthermore, there are two encoding use models that are used to translate a WSDL binding to a SOAP message. They are: literal, and encoded
When using a literal use model, the body contents should conform to a user-defined XML-schema(XSD) structure. The advantage is two-fold. For one, you can validate the message body with the user-defined XML-schema, moreover, you can also transform the message using a transformation language like XSLT.
With a (SOAP) encoded use model, the message has to use XSD datatypes, but the structure of the message need not conform to any user-defined XML schema. This makes it difficult to validate the message body or use XSLT based transformations on the message body.
The combination of the different style and use models give us four different ways to translate a WSDL binding to a SOAP message.
Document/literal
Document/encoded
RPC/literal
RPC/encoded
I would recommend that you read this article entitled Which style of WSDL should I use? by Russell Butek which has a nice discussion of the different style and use models to translate a WSDL binding to a SOAP message, and their relative strengths and weaknesses.
Once the artifacts are received, in both styles of communication, I
invoke the method on the port. Now, this does not differ in RPC style
and Document style. So what is the difference and where is that
difference visible?
The place where you can find the difference is the "RESPONSE"!
RPC Style:
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
#WebService
#SOAPBinding(style=Style.RPC)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
The SOAP message for second operation will have empty output and will look like:
RPC Style Response:
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
Document Style:
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
#WebService
#SOAPBinding(style=Style.DOCUMENT)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
If we run the client for the above SEI, the output is:
123
[123, 456]
This output shows that ArrayList elements are getting exchanged between the web service and client. This change has been done only by the changing the style attribute of SOAPBinding annotation. The SOAP message for the second method with richer data type is shown below for reference:
Document Style Response:
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">123</return>
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">456</return>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
Conclusion
As you would have noticed in the two SOAP response messages that it is possible to validate the SOAP response message in case of DOCUMENT style but not in RPC style web services.
The basic disadvantage of using RPC style is that it doesn’t
support richer data types and that of using Document style is that it
brings some complexity in the form of XSD for defining the richer
data types.
The choice of using one out of these depends upon the
operation/method requirements and the expected clients.
Similarly, in what way SOAP over HTTP differ from XML over HTTP? After
all SOAP is also XML document with SOAP namespace. So what is the
difference here?
Why do we need a standard like SOAP? By exchanging XML documents over HTTP, two programs can exchange rich, structured information without the introduction of an additional standard such as SOAP to explicitly describe a message envelope format and a way to encode structured content.
SOAP provides a standard so that developers do not have to invent a custom XML message format for every service they want to make available. Given the signature of the service method to be invoked, the SOAP specification prescribes an unambiguous XML message format. Any developer familiar with the SOAP specification, working in any programming language, can formulate a correct SOAP XML request for a particular service and understand the response from the service by obtaining the following service details.
Service name
Method names implemented by the service
Method signature of each method
Address of the service implementation (expressed as a URI)
Using SOAP streamlines the process for exposing an existing software component as a Web service since the method signature of the service identifies the XML document structure used for both the request and the response.
An RPC style web service uses the names of the method and its parameters to generate XML structures representing a method’s call stack. Document style indicates the SOAP body contains an XML document which can be validated against pre-defined XML schema document.
A good starting point : SOAP Binding: Difference between Document and RPC Style Web Services
In WSDL definition, bindings contain operations, here comes style for each operation.
Document : In WSDL file, it specifies types details either having inline Or imports XSD document, which describes the structure(i.e. schema) of the complex data types being exchanged by those service methods which makes loosely coupled. Document style is default.
Advantage:
Using this Document style, we can validate SOAP messages against predefined schema. It supports xml datatypes and patterns.
loosely coupled.
Disadvantage: It is a little bit hard to get understand.
In WSDL types element looks as follows:
<types>
<xsd:schema>
<xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/>
</xsd:schema>
</types>
The schema is importing from external reference.
RPC :In WSDL file, it does not creates types schema, within message elements it defines name and type attributes which makes tightly coupled.
<types/>
<message name="getHelloWorldAsString">
<part name="arg0" type="xsd:string"/>
</message>
<message name="getHelloWorldAsStringResponse">
<part name="return" type="xsd:string"/>
</message>
Advantage: Easy to understand.
Disadvantage:
we can not validate SOAP messages.
tightly coupled
RPC : No types in WSDL
Document: Types section would be available in WSDL
The main scenario where JAX-WS RPC and Document style are used as follows:
The Remote Procedure Call (RPC) pattern is used when the consumer views the web service as a single logical application or component with encapsulated data. The request and response messages map directly to the input and output parameters of the procedure call.
Examples of this type the RPC pattern might include a payment service or a stock quote service.
The document-based pattern is used in situations where the consumer views the web service as a longer running business process where the request document represents a complete unit of information. This type of web service may involve human interaction for example as with a credit application request document with a response document containing bids from lending institutions. Because longer running business processes may not be able to return the requested document immediately, the document-based pattern is more commonly found in asynchronous communication architectures. The Document/literal variation of SOAP is used to implement the document-based web service pattern.
I think what you are asking is the difference between RPC Literal, Document Literal and Document Wrapped SOAP web services.
Note that Document web services are delineated into literal and wrapped as well and they are different - one of the primary difference is that the latter is BP 1.1 compliant and the former is not.
Also, in Document Literal the operation to be invoked is not specified in terms of its name whereas in Wrapped, it is. This, I think, is a significant difference in terms of easily figuring out the operation name that the request is for.
In terms of RPC literal versus Document Wrapped, the Document Wrapped request can be easily vetted / validated against the schema in the WSDL - one big advantage.
I would suggest using Document Wrapped as the web service type of choice due to its advantages.
SOAP on HTTP is the SOAP protocol bound to HTTP as the carrier. SOAP could be over SMTP or XXX as well. SOAP provides a way of interaction between entities (client and servers, for example) and both entities can marshal operation arguments / return values as per the semantics of the protocol.
If you were using XML over HTTP (and you can), it is simply understood to be XML payload on HTTP request / response. You would need to provide the framework to marshal / unmarshal, error handling and so on.
A detailed tutorial with examples of WSDL and code with emphasis on Java: SOAP and JAX-WS, RPC versus Document Web Services
Document
Document style messages can be validated against predefined schema.
In document style, SOAP message is sent as a single document.
Example of schema:
<types>
<xsd:schema> <xsd:import namespace="http://example.com/"
schemaLocation="http://localhost:8080/ws/hello?xsd=1"/>
</xsd:schema>
</types>
Example of document style soap body message
<message name="getHelloWorldAsString">
<part name="parameters" element="tns:getHelloWorldAsString"/>
</message>
<message name="getHelloWorldAsStringResponse">
<part name="parameters"> element="tns:getHelloWorldAsStringResponse"/>
</message>
Document style message is loosely coupled.
RPC
RPC style messages use method name and parameters to generate XML structure.
messages are difficult to be validated against schema.
In RPC style, SOAP message is sent as many elements.
<message name="getHelloWorldAsString">
<part name="arg0"> type="xsd:string"/>
</message>
<message name="getHelloWorldAsStringResponse">
<part name="return"
> type="xsd:string"/>
</message>
Here each parameters are discretely specified,
RPC style message is tightly coupled, is typically static, requiring changes to the client when the method signature changes
The rpc style is limited to very simple XSD types such as String and Integer, and the resulting WSDL will not even have a types section to define and constrain the parameters
Literal
By default style. Data is serialized according to a schema, data type not specified in messages but a reference to schema(namespace) is used to build soap messages.
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
Encoded
Datatype specified in each parameter
<soap:body>
<myMethod>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</myMethod>
</soap:body>
Schema free
I'm trying to create a WS based on a WSDL that defines one Request and one Response. The incoming request should be mapped to an endpoint depending on the SOAPAction defined in the SOAP message. To achieve this I'm trying to use the SoapActionEndpointMapping in my servlet.xml config file and define the mappings, as described in the Spring documentation.
<bean id="endpointMapping" class="org.springframework.ws.soap.server.endpoint.mapping.SoapActionEndpointMapping">
<property name="mappings">
<props>
<prop key="http://myCompany/MyService/MyRequest/mySoapActionOne">myFirstEndpoint</prop>
<prop key="http://myCompany/MyService/MyRequest/mySoapActionTwo">mySecondEndpoint</prop>
</props>
</property>
My endpoint extends AbstractMarshallingPayloadEndpoint and should be able to handle the requests.
The problem is that when I try to send a request (with SoapUI) i get the following error in the log:
WARN [EndpointNotFound] No endpoint mapping found for [SaajSoapMessage {http://schemas.mycompany/MyService}MyRequest]
I have used the PayloadRootQNameEndpointMapping with great success earlier but can not this to work.
Any help is appreciated.
Regards.
Do you have a handler adapter bean defined also? You'll need one in order to use a MarshallingPayloadEndpoint, so that spring knows how to perform the marshalling. The adapter is called something like MarshallingEndpointHandlerAdapter, or similar.
In your SOAP client (SOAPUI), you'll need to add the SOAPAction header to your request, to supply spring with the SOAP action to use in its mapping.
E.g. SOAPAction=http://myCompany/MyService/MyRequest/mySoapActionOne
It shouldn't make any difference what type of Endpoint you're using, because currently, you're receiving a 404 response - your request isn't finding its way to any endpoint.