Get Familiar With Windows Communication Application Development
By Certification Magazine —
1 | 2 | 3 | 4 | 5 |
Sub-objective: Implement transport-level security.
Multiple answer, multiple-choice
You need to develop a Windows Communication Foundation (WCF) client using the Microsoft .NET 3.5 Framework. The client needs to invoke methods in a Web Services Enhancements (WSE) 3.0-enabled Web service. The WSE 3.0 service uses turnkey security assertions to enforce Web method authorization.
You want to create a WCF client that supports all of the features used by the WSE 3.0 service. You want to use the least amount of developer effort. What should you do? (Choose two. Each answer is part of the complete solution.)
A. Run the Svcutil.exe tool to generate the client proxy class.
B. Run the SvcConfigEditor.exe tool to generate the client proxy class.
C. Run the Wsewsdl.exe tool to generate the client proxy class.
D. Specify a WseHttpBinding binding as the client endpoint.
E. Specify a WSDualHttpBinding binding as the client endpoint.
F. Specify a custom binding that inherits from the Binding class as the client endpoint.
Answer:
A. Run the Svcutil.exe tool to generate the client proxy class.
F. Specify a custom binding that inherits from the Binding class as the client endpoint.
Tutorial:
To provide interoperability between WSE 3.0 Web services and WCF clients, you need to perform the following steps:
- Run the Svcutil.exe to generate the WCF client proxy class just as you would for a WCF service. Because the MEX protocol is unsupported, the Svcutil.exe tool will not retrieve any security assertions.
- Create a custom binding class derived from the Binding class. This class should map WSE 3.0 features to WCF properties.
- Specify the custom binding for the client endpoint.
The following code demonstrates how to derive from the Binding class and support WSE 3.0 security assertions:
public class WseHttpBinding : Binding {
private WseSecurityAssertion _securityAssertion;
public WseSecurityAssertion SecurityAssertion {
get { return _securityAssertion; }
set { _securityAssertion = value; }
}
public override BindingElementCollection CreateBindingElements () {
//Determine the BindingElementCollection based on the SecurityAssertion
}
}
public enum WseSecurityAssertion {
UsernameOverTransport = 0,
MutualCertificate10 = 1,
UsernameForCertificate = 2,s
AnonymousForCertificate = 3,
MutualCertificate11 = 4,
Kerberos = 5
}
The code derives a class named WseHttpBinding from the Binding class and creates a property named sercurityAssertion to support WSE turnkey assertions. The code then creates a BindingElementCollection instance by overriding the CreateBindingElements method. You should also add code in the client application code to set the binding properties.
When WCF clients are configured to use the August 2004 version of the WS-Addressing specification, they are compatible with WSE services. You can use the Svcutil.exe tool to generate a client proxy class. Since WSE services do not support the metadata exchange (MEX) protocol, the client proxy will not have security settings applied to it, so you need to create a custom binding class to provide WSE turnkey security settings.
You should not run the SvcConfigEditor.exe tool to generate the client proxy class because the SvcConfigEditor.exe tool is used to create the WCF configuration file using XML. You should not run the Wsewsdl.exe tool to generate the client proxy class because the Wsewsdl.exe tool is used to generate a WSE 3.0 proxy from an ASMX Web service.
You should not use WSDualHttpBinding class because WSDualHttpBinding binding is not compatible with WSE 3.0 Web services. None of the existing binding classes supports WSE turnkey security settings. You should not use the WseHttpBinding class because it is not a valid binding class. You must create a custom binding class to provide compatibility with the WSE 3.0 services.
References:
1 | 2 | 3 | 4 | 5 |
