Java WS-Addressing: A Comprehensive Guide - Quiz

Total: 61 questions

1. What the WS-Addressing specification is used for?
To give an interoperable way of communicating between senders and receivers by providing a transport-neutral mechanism to address Web services and messages.
2. Primary concepts of WS-Addressing.
- Endpoint references - Message addressing properties
3. Describe Endpoint references concept.
Endpoint references give a mechanism to encapsulate information about endpoints. Endpoint references can be propagated to other parties and then used to target the Web service endpoint that they represent.
4. Describe Message addressing properties concept.
MAPs are a set of well-defined WS-Addressing properties that can be represented as elements in SOAP headers and provide a standard way of conveying information, such as the endpoint to which to a direct message replies, or information about the relationship that the message has with other messages.
5. How to enable WS-Addressing?
Configure policy sets or use annotations in code.
6. Which tasks can be performed by using JAX-WS 2.1 annotations and feature classes?
- It is possible to enable WS-Addressing on the server or the client. - Have more control over the behavior of WS-Addressing when using policy sets. - Specify whether WS-Addressing is enabled and whether to use synchronous or asynchronous messaging patterns. - Specify actions to be associated with a Web service operation or fault response.
7. Is WS-Addressing support disabled by default for web service clients?
Yes.
8. Is WS-Addressing support enabled by default for web service providers?
Yes.
9. 

Additional features of the JAX-WS enhancements?

a) Java representations of WS-Addressing endpoint references.

b) It is possible to create Java endpoint reference instances for the application endpoint, at run time.

c) It is possible to create Java endpoint reference instances for endpoints in other applications by specifying the URI of the endpoint reference.

d) It is possible to use annotations to specify whether WS-Addressing support is enabled and required on services or clients.

e) It is possible to configure client proxy or dispatch objects by using endpoint references.

f) Java support for endpoint references that represent WS-Resource instances.

g) Reference parameters can be associated with an endpoint reference at the time of its creation to correlate it with a particular resource instance.

h) It is possible to extract the reference parameters of an incoming message in targeted web services, so that the web service can route the message to the appropriate WS-Resource instance.

10. Which annotation does specify the use of WS-Addressing with the SOAP 1.1/HTTP or SOAP 1.2/HTTP binding?
@Addressing
11. Can @Addressing annotation be used with other then SOAP 1.1/HTTP or SOAP 1.2/HTTP binding?
It is undefined.
12. Which annotations are used in with @Addressing?
WebService, WebServiceProvider and WebServiceRef annotations.
13. If @Addressing is used with a @WebService, where this annotation should be placed?
On the service endpoint implementation class.
14. If @Addressing is used with a @WebServiceRef, when this annotation can be used?
It can be used only when a proxy instance is created.
15. Parameters of @Addressing.
- enabled; - required; - responses;
16. What @Addressing.enabled is used for?
To specify if the feature is enabled or disabled.
17. Default value of @Addressing.enabled?
True.
18. What @Addressing.required is used for?
If addressing is enabled, the property specifies whether the endpoint requires WS-Addressing. If required is true, WS-Addressing headers MUST be present on incoming messages.
19. Default value of @Addressing.required?
False.
20. What @Addressing.responses is used for?
If addressing is enabled, the property defines whether endpoint needs the use of anonymous responses, non-anonymous responses or all.
21. Possible values of @Addressing.responses?
- Responses.ALL - Responses.ANONYMOUS - Responses.NON_ANONYMOUS
22. Default value of @Addressing.responses.
Responses.ALL
23. Example of using @Addressing with @Action.
@WebService() @Addressing(enabled = true, required = true) public class ExamWS { @WebMethod(operationName = "addExam") @Action( input="http://addExam.com/input", output="http://addExam.com/output") public String addExam(@WebParam(name = "name1") String name1, @WebParam(name = "name2") String name2) { return name1 + name2; } }
24. 

Example of portType and binding sections of wsdl with @Action.

<portType name="ExamWS">
	<operation name="addExam">
		<input wsaw:Action="http://addExam.com/input" message="tns:addExam"/>
		<output wsaw:Action="http://addExam.com/output" message="tns:addExamResponse"/>
	</operation>
</portType>

...

<binding name="ExamWSPortBinding" type="tns:ExamWS">
	<wsaw:UsingAddressing/>
	...
</binding>
25. 

Which element in the binding section signifies that it is set up for WS-Addressing?

<wsaw:UsingAddressing/>
26. What @Action annotation is used for?
To indicate endpoint and its client WS-Addressing actions.
27. How to create WS-Addressing-compliant SOAP faults?
Using @FaultAction annotation.
28. If endpoint is using addressing, should it be indicated in WSDL? In which section?
Endpoint's use of addressing should be indicated in the wsdl:binding or wsdl:port sections of the WSDL 1.1.
29. 

Write WSDL(Addressing section) for this example: 

@WebService()
@Addressing
public class ExamWS {}
<wsam:Addressing wsp:Optional="true">
	<wsp:Policy/>
</wsam:Addressing>
30. 

Write WSDL (Addressing section) for this example:

@WebService()
@Addressing(required = true)
public class ExamWS {...}
<wsam:Addressing>
	<wsp:Policy/>
</wsam:Addressing>
31. 

Write WSDL (Addressing section) for this example: 

@WebService()
@Addressing(responses = Responses.NON_ANONYMOUS)
public class ExamWS {...}
<wsam:Addressing wsp:Optional="true">
	<wsp:Policy>
		<wsam:NonAnonymousResponses/>
	</wsp:Policy>
</wsam:Addressing>
32. 

Example of specifying Addressing in webservices.xml.

<xsd:element name="addressing"
             type="javaee:addressingType"
             minOccurs="0"
             maxOccurs="1">
    <xsd:annotation>
        <xsd:documentation>
            ...
        </xsd:documentation>
    </xsd:annotation>
</xsd:element>
33. What AddressingFeature is used for?
To control the use of WS-Addressing by JAX-WS.
34. Which bindings AddressingFeature is supported with?
With the SOAP 1.1/HTTP or SOAP 1.2/HTTP bindings.
35. Which annotation does AddressingFeature correspond to?
To the @Addressing.
36. What does AddressingFeature make by enabling it on the server?
It is possible to consume and respond to WS-Addressing headers.
37. What does AddressingFeature cause by enabling it on the client?
It will cause the JAX-WS runtime to include WS-Addressing headers in SOAP messages.
38. Will disabling of AddressingFeature prevent a JAX-WS runtime from processing or adding WS-Addressing headers from/to SOAP messages even if the associated WSDL specifies?
Yes.
39. When disabling of AddressingFeature can be useful?
When a client or endpoint needs to implement Addressing themselves.
40. What the AddressingFeature's required property is used for?
To control whether all incoming messages MUST contain Addressing headers.
41. What the AddressingFeature's responses property is used for?
To control whether the endpoint requires the use of anonymous, non-anonymous and all responses.
42. Is AddressingFeature automatically enabled if the WSDL indicates the use of addressing?
Yes.
43. 

What should be done to write a portable endpoint and its corresponding client?

An endpoint should explicitly specify WS-Addressing Actions to be used via the Action and FaultAction annotations. The client should explicitly enable addressing via the AddressingFeature, and for each invocation, the client should explicitly set the BindingProvider. SOAPACTION_URI_PROPERTY.

44. Describe the effect of AddressingFeature being enabled.
At runtime, WS-Addressing headers should be consumed by the receiver and produced by the sender even if the WSDL declares otherwise. The mustUnderstand="0" attribute should be used on the WS-Addressing headers.
45. Describe the effect of AddressingFeature being disabled.
WS-Addressing will be disabled even if an associated WSDL specifies otherwise. At runtime, WS-Addressing headers MUST NOT be used. WS-Addressing may be explicitly disabled to prevent a JAX-WS implementation from consuming and producing WS-Addressing headers. If an application has implemented WS-Addressing itself, it MUST explicitly disable this feature.
46. Which AddressingFeature property can be used to specify whether WS-Addressing headers MUST be present on incoming messages?
Required property.
47. When AddressingFeature.required property only has meaning?
When used on the endpoint and has no affect when used on the client.
48. Default value of AddressingFeature.required property.
False.
49. Constructors of AddressingFeature.
- AddressingFeature() - AddressingFeature(boolean enabled) - AddressingFeature(boolean enabled, boolean required)
50. Is the @Action annotation applied to the methods?
Yes.
51. What @Action is used for?
It is used to specify the input, output, fault WS-Addressing Action values associated with the annotated method.
52. Attributes of @Action.
- input - output - fault
53. What does @Address.input attribute specify?
Explicit value of the WS-Addressing Action message addressing property for the input message of the operation.
54. Default value of @Action.input attribute.
"".
55. What does @Address.output attribute specify?
Explicit value of the WS-Addressing Action message addressing property for the output message of the operation.
56. Default value of @Address.output.
"".
57. What does @Address.fault attribute specify?
Explicit value of the WS-Addressing Action message addressing property for the fault message(s) of the operation.
58. What the @FaultAction annotation is used for?
It is used within the @Action annotation to specify the WS-Addressing Action of a service specific exception.
59. Attributes of @FaultAction.
- Class className(); - String value() default "";
60. Example of associating Action and FaultAction with input, output and fault messages of the mapped WSDL operation.
@Action( input = "http://exampclouds.com/input", output = "http://exampclouds.com/output", fault = { @FaultAction(className = AddExamException.class, value = "http://examclouds.com/fault") }) public String addExam(String name1, String name2) throws AddExamException { ... }
61. 

Write WSDL(operation section) for this example: 

@Action(
    input = "http://ec.com/input",
    output = "http://ec.com/output",
    fault = {
        @FaultAction(className = AddExamException.class, value = "http://ec.com/fault")
    })
    public String addExam(String name1, String name2) throws AddExamException {
	...
}
<operation name="addExam">
  <input wsaw:Action="http://ec.com/input" message="tns:addExam"/>
  <output wsaw:Action="http://ec.com/output" message="tns:addExamResponse"/>
  <fault message="tns:AddExamException" name="AddExamException" wsaw:Action="http://ec.com/fault"/>
</operation>
Page 1 of 1