I am in confusion as when to use SOAPBinding.ParameterStyle.BARE and SOAPBinding.ParameterStyle.WRAPPED .and which binding style is more preferred.what are the differences between them.
ParameterStyle.Bare and ParameterStyle.Wrapped affects your wsdl definitions of request and response messages only.
Lets take an example, we have a webservice with a method "test" which has 2 input "string1" and "string2" and it is returning a string as "rstring".
ParameterStyle.BARE
Your parameter's name will be visible as part name in your wsdl.
Request message:
<message name="test">
<part name="string1" element="tns:string1"/>
<part name="string2" element="tns:string2"/>
</message>
Response message:
<message name="testResponse">
<part name="rstring" element="tns:rstring"/>
</message>
In your xsd test and testResponse will be defined like below, and your wsdl element directly referring elements under test and test response from xsd.
<xs:complexType name="test">
<xs:sequence>
<xs:element name="string1" type="xs:string" minOccurs="0"/>
<xs:element name="string2" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:complexType name="testResponse">
<xs:sequence>
<xs:element name="rstring" type="xs:string" minOccurs="0"/>
</xs:sequence>
ParameterStyle.WRAPPED
In this style your request and response message will be wrapped in single input as "parameter" and output as "result". and they will refer that particular element in xsd for all elements within.
Request message:
<message name="test">
<part name="parameters" element="tns:test"/>
</message>
Response message:
<message name="testResponse">
<part name="result" element="tns:testResponse"/>
</message>
In your xsd test and testResponse will be defined as same as above,
<xs:complexType name="test">
<xs:sequence>
<xs:element name="string1" type="xs:string" minOccurs="0"/>
<xs:element name="string2" type="xs:string" minOccurs="0"/>
</xs:sequence>
<xs:complexType name="testResponse">
<xs:sequence>
<xs:element name="rstring" type="xs:string" minOccurs="0"/>
</xs:sequence>
In above example , you can spot the difference. This is the only difference they implicate in wsdl.
Note: Above example is explained for Document type soap binding, in RPC, no xsd is involved so RPC.Bare is applicable only.
The document/literal wrapped style is the best approach and is also
the default. Wrapped document style with literal encoding has the
following advantages:
There is no type encoding info.
Everything that appears in the soap:body is defined by the Schema, so you can easily validate the message.
You have the method name in the soap message.
Document/literal is WS-I compliant, but without the WS-I restriction that the SOAP.body should have only one Child. The wrapped
pattern meets the WS-I restriction that the SOAP messages SOAP.body
has only one Child.
But in few cases you might have to use another style. If you have
overloaded operations, you cannot use the document/literal wrapped
style. WSDL allows overloaded operations, but when you add the wrapped
pattern to WSDL, you require an element to have the same name as the
operation, and you cannot have two elements with the same name in XML.
So you must use the document/literal, non-wrapped style or one of the
RPC styles.
Source: Which style of WSDL should I use?
Related
What are the conceptual and technical disadvantages of this request/response structure:
A)
<xs:element name="OrderRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderID" type="xs:integer"/>
<xs:element name="OrderType" type="xs:integer"/>
<xsd:element name='OrderAttributes' type='xsd:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
where OrderAttributes element will contain string in the following XML structure:
<OrderName> xy </OrderName>
<OrderDate> xy </OrderDate>
<OrderDetails> xy </OrderDetails>
....lots of other attributes
compared to this request/response structure
B)
<xs:element name="OrderRequest">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderID" type="xs:integer"/>
<xs:element name="OrderType" type="xs:integer"/>
<xsd:element name="OrderAttributes">
<xs:complexType>
<xs:sequence>
<xs:element name="OrderName" type="xs:string"/>
<xs:element name="OrderDate" type="xs:date"/>
<xs:element name="OrderDetails" type="xs:string"/>
....lots of other attributes
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
I need to design web service interface for orders processing, and I am thinking about the two alternatives mentioned above.
Version A, is more generic, so interface doesn't need to change, when OrderAttributes structure changes in any way.
But schema validation is not possible.
And my question is, what are other disadvantages compared to version B. I am analyst, not programmer, so I cannot say, if there is some impact on parsing requests, generating code from contract etc...
First note that your generic use of the word attribute to refer to a property can be confusing in XML, where attribute refers to a specific construct that stands apart from element:
<element attribute="attribute value">
<childElement>child element value</childElement>
</element>
Then, while doing design, you might consider which properties you wish to represent as XML attribute and which you wish to represent as XML elements. See XML attribute vs XML element for help deciding.
Regarding your A vs B proposed designs, note that A simply is not viable -- you cannot have unescaped markup within an element declared to have xs:string content as you've shown. Furthermore, A would then require further parsing of the OrderAttributes contents anyway whereas B would leverage the XML parser to process OrderAttributes contents. (And, like you said, B would not leverage XSD validation either.)
For future expansion, consider instead the use of xs:any, which supports various interpretations of wildcard contents via its processContents attribute values of strict, lax, or skip.
I'm going to generate java code from the xsd. I want to know how to remove xsd element when converting xsd to java using jaxb. My goal is to ignore message
Ex:
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:string" name="name"/>
<xs:element type="xs:string" name="message"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Java Variables
#XmlElement
protected String name;
In here you can see that message element got removed. I want to know how to do that?
If I understand you correctly, to sum it up you want to ignore a mandatory element and still want the result to validate correctly. My short answer is that this is contradictory and does not make sense. JAXB is built to do it correctly and you want do it wrongly(?).
You have several options, eg.
Live with the extra constructor argument.
Generate no-arg constructor instead.
Don't generate, but hand code JAXB annotated classes. Maybe turn off some validation.
Don't use JAXB, use something else (dom4j et. al.) or handcraft the xml
Possibly you can add some overriding in a binding file or even a plug-in, but I wouldn't think it was worth it.
Can you alter the .xsd ?
The current Element "note" tells that both "name" and "message" are mandatory. If you want "message" to be conditional you probably need to add minOccurs="0" attribute:
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element type="xs:string" name="name"/>
<xs:element type="xs:string" name="message" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
I am trying to construct an XML document using org.w3c.dom.Document to create some XML for another existing tool. The problem I am having is that the tool seems to have the XML namespaces in a strange way. How can I replicate this using the Java API's?
<ns1:myroot xmlns:ns1="http://foo.com/ns1/">
<ns2:bar xmlns:ns2="http://foo.com/xml/bar/">
<ns2:bar_thing>abc</ns2:bar_thing>
</ns2:bar>
<ns3:data xmlns:ns3="http://foo.com/xml/special-ns">
<!--These are not namespaced for some reason. If I use the ns3 prefix, or
use a default xmls="...", the tool fails to load the document, saying the
elements have invalid values.
-->
<a>Element without namespace</a>
<b>
<bi>1</bi>
<bii>2</bii>
</b>
</ns3:data>
</ns1:myroot>
I can build most of the document easily with createElementNS and setAttributeNS. However I can't get the ns3:data contents to be correct.
Trying to use the non-namespace createElement still left an xmlns="http://foo.com/xml/special-ns"> on my a and b elements, as did using createElementNS with an empty namespace, and obviously a non-empty namespace puts them in a namespace.
The schema for http://foo.com/xml/special-ns has a bunch of declarations like these below, not sure what the tns thing is about, but otherwise does not seem special (although I am not 100% sure the tool actually does anything with the XSD and I don't have access to the source).
<xs:schema version="1.0" targetNamespace="http://foo.com/xml/special-ns">
<!--Bunch of xs:element such as this-->
<xs:element name="data" type="tns:data" />
<!--types declared after-->
<xs:complexType name="data">
<xs:sequence>
<xs:element name="a" type="tns:aDataObj" minOccurs="0"/>
<xs:element name="b" type="tns:bDataObj" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="aDataObj">
<xs:restriction base="xs:string">
<xs:pattern value="[a-zA-Z0-9 ]+" />
</xs:restriction>
</xs:simpleType>
<xs:complexType name="bDataObj">
<xs:sequence>
<xs:element name="bi" type="xs:string"/>
<xs:element name="bii" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
we are moving a topdown (wsdl first) ws from jboss4 to jboss7 and are having some difficulties with CXF. I am noticing that the large wsdl file located in
standalone\data\wsdl\x.ear\x.war\x.wsdl
is not generated off the supplied xsd set, it seems to be generating off the classes. For instance our definition from JBoss4 reads (obfuscated)
<element name="x">
<complexType>
<sequence>
<element minOccurs="0" name="x" type="x"/>
<choice>
<element name="x" type="x"/>
<element name="x" type="x"/>
<element name="x" type="x"/>
<element name="x" type="x"/>
<element name="x" type="x"/>
</choice>
</sequence>
</complexType>
</element>
and the one generated by CXF has all the coice element replaced with minoccurs = 0, totally invalid for our actual use.
<xs:element name="x">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="x" type="xs:string"/>
<xs:element minOccurs="0" name="x" type="ns1:x"/>
<xs:element minOccurs="0" name="x" type="ns1:x"/>
<xs:element minOccurs="0" name="x" type="ns1:x"/>
<xs:element minOccurs="0" name="x" type="ns1:x"/>
<xs:element minOccurs="0" name="x" type="ns1:x"/>
</xs:sequence>
</xs:complexType>
</xs:element>
This is because wsconsume builds our java classes and annotates them well enough to be parsed by cxf, but not well enough to actually present the initial intent of the complexTypes, so after much looking, how do you get Jboss 7 to use the WSDL definition of your choosing, without having CXF generate a wsdl? We will not be using Spring to make this happen, so... Discuss!
so setting the wsdlLocation in the #webservice annotation lead to the error described here
http://mail-archives.apache.org/mod_mbox/cxf-users/200806.mbox/%3C1932ACF3-DCD2-4073-83DD-981FC0F68F53#apache.org%3E
so it turned way simpler after reading it
the directions there list two options:
1) Update the #WebService annotation on the FooDocumentImpl class to
have the serviceName/portName attributes that match the values in the
wsdl.
2) Update the element in your config to add the
qnames for the service name and portname.
the first is if you are not using Spring, so after explicitly bringing the #WebService annotation to:
#WebService(endpointInterface = "main.package.InterfaceWS", serviceName = "InterfaceWSService", name = "InterfaceWS", targetNamespace = "http://Interface.namespace.main", wsdlLocation = "WEB-INF/wsdl/InterfaceWS.wsdl" ,portName="InterfaceWSPort")
to match the service description in the InterfaceWS.wsdl:
<service name="InterfaceWSService">
<port binding="tns:InterfaceWSSOAPBinding" name="InterfaceWSPort">
<soap:address location="http://localhost:8080/publishedLocationOfInterface />
</port>
</service>
it worked like a charm
I have a WSDL for a soap-based web service that contains a custom header:
<message name="Request">
<part element="common:Request" name="Request"></part>
<part element="common:myHeader" name="Header"></part>
</message>
<operation name="processRequest">
<soap:operation soapAction=""/>
<input>
<soap:body parts="Request" use="literal"/>
<soap:header message="tns:Request" part="Header" use="literal"></soap:header>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
The header type is defined in a separate schema file:
<xs:element name="myHeader" nillable="false" type="tns:myHeaderType"/>
<xs:complexType name="myHeaderType">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="JobID" type="tns:JobIDType" minOccurs="1" maxOccurs="1"/>
<xs:element name="TransactionID" type="xs:string" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
Furthermore, I am validating against the definition of myHeaderType to make sure that the required elements are there, formatting constraints are met, etc. This all appears to be working correctly, in that well-formed requests are accepted and incorrectly formatted requests are rejected.
My problem arises with a consumer who uses Apache Axis (hidden behind a proprietary tool) to generate their web-service client. As described in another StackOverflow question here, Axis inserts some optional attributes on myHeader that are allowed by the SOAP standard (as nearly as I can tell):
<soapenv:Header>
<com:myHeader soapenv:mustUnderstand="0" soapenv:actor="">
^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
<JobID>myJobId</JobID>
<TransactionID>myTransactionId</TransactionID>
</com:myHeader>
</soapenv:Header>
Because of the tool that my consumer is using, it is not feasible to modify the Axis-generated stubs to omit these attributes, as has been suggested elsewhere. Furthermore, it seems these attributes should be allowed by my service, if I'm going to claim to be a soap service. My question is, how can I modify my header definition to accommodate these optional attributes, and ideally plan for attributes that I might not be anticipating. Is there a standard type that I can extend for my header type definition, or a general best practice for this situation?
I was able to find a couple of solutions to my problem today. They both solve the problem, but I'm not confident in my judgement of which is really the better of the two, so I'll present them both here.
Both solutions center around modifying the definition of myHeaderType so that it can accommodate the unanticipated SOAP-defined attributes.
Within the SOAP WSDL schema definition (http://schemas.xmlsoap.org/wsdl/), there is a type called tExtensibleAttributesDocumented that includes the following very flexible attribute definition:
<xs:anyAttribute namespace="##other" processContents="lax"/>
By extending this abstract type, I was able to incorporate this liberal allowance for unanticipated attributes into my type. Here is the resulting code:
<xs:complexType name="myHeaderType">
<xs:complexContent>
<xs:extension base="wsdl:tExtensibleAttributesDocumented">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="JobID" type="tns:JobIDType" minOccurs="1" maxOccurs="1"/>
<xs:element name="TransactionID" type="xs:string" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Note that this does not check the contents of mustUnderstand or actor, and allows other attributes, including complete garbage, so long as it comes from a namespace that I have defined in my XML request.
The other alternative was to directly include the <xs:anyAttribute> in my type:
<xs:complexType name="myHeaderType">
<xs:sequence minOccurs="1" maxOccurs="1">
<xs:element name="JobID" type="tns:JobIDType" minOccurs="1" maxOccurs="1"/>
<xs:element name="TransactionID" type="xs:string" minOccurs="1" maxOccurs="1"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
This has basically the same effect, as far as I was able to determine.
If there are any subtle differences between these solutions that I'm not aware of, I'd love to hear about it. If there is an accepted standard for this situation, I was not able to find it. Another weakness of this solution is that I was not able to get the attributes to validate against their definitions in the schema. Changing the processContents attribute to strict prevented even the well-defined mustUnderstand and actor attributes from being processed.
Yes, you can modify with Altova XMLSpy editor. Use functionally for 30 days.