Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Hyperscale Messaging in .NET with Amazon's Simple Queuing Service (SQS) : Page 3

Amazon SQS makes queuing messages across organizations over HTTP a snap with its Web service interface and Amazon-backed infrastructure. This article walks you through the process to get started using Amazon SQS to create and control queues and messages.


advertisement
Building the SQS Dashboard
To build the SQS Dashboard, create a new Windows Forms project in your C:\Hyperscale folder.

You'll need to enable WSE and create a security policy named "Hyperscale" that the project can use. You can use the "WSE Settings 3.0" Wizard available in Visual Studio as shown in the Figures below. However you can use the Wizard only to initially create the policy file; for the policy file to actually work with Amazon SQS (because of MutualCertificate10Assertion incompatibility) you will need to modify the file manually (more on this later). Unfortunately, after you modify it, you will no longer be able to use the Wizard to modify it.

To create the security file, launch the Wizard by selecting "WSE Settings 3.0…" from the right-click menu of the project item. Then follow the procedure illustrated in the figures in this article. The first two screens are simple; check the boxes as shown in Figure 2 and Figure 3, then click the "Add" button shown in Figure 3 to edit the application policy.

 
Figure 2. Enable WSE: The figure shows the first step in the WSE Wizard—enabling "Web service Enhancements" for the project.
 
Figure 3. Enabling Security: Check the "Enable Policy" checkbox to enable a security policy for the project, and click 'Add' to add a project-specific policy.
Enter "HyperscalePolicy" for the Policy Friendly Name as shown in Figure 4, then select the options shown in Figure 5.

 
Figure 4. Name the Policy: Name the new security policy "HyperscalePolicy" as shown in this figure.
 
Figure 5. Select Appropriate Options: Choose the "Secure a client application" option and select "Certificate" as the authentication method.
Now you need to choose client certificate that your application will use (see Figure 6). Uncheck the option "Specify the X.509 Certificate in Code" because the application relies on WSE's default functionality to attach the client certificate. Be sure to select the "AWS Customer" certificate that you installed earlier in the "Certificate Information" section.

The Wizard will prompt you for a "Server Certificate." Your application and WSE will not be using this information, so you can choose the same "AWS Certificate" as in Figure 6.

Finally, as shown in Figure 7, uncheck the "Enable WS-Security 1.1 Extensions" and the "Establish Secure Session" checkboxes, and select the "Sign-Only" protection order.

Your application is now set up with a WSE policy as shown in Figure 8.

 
Figure 6. Select the 'AWS Customer' Certificate: Uncheck the "Specify X-509 Certificate in Code" option, and select the AWS Customer certificate as shown in this figure for both the client and the server certificate.
 
Figure 7. Set Message Protection: For this application, set the protection order to "Sign Only." The application does not use the "WS Security 1.1. Extensions" or "Secure Session" options.
 
Figure 8. Policy Applied: The figure shows the final "HyperscalePolicy"' application policy added to the WSE Wizard.
Overcoming the WSE061 Error
Completing the policy procedure in the WSE Settings Wizard as described in the preceding section creates a wse2policyCache.config file in the root folder of the project—but there's a catch. Using this file (as created) with Amazon SQS will cause the application to throw a WSE exception, containing this inner exception:

{"WSE061: The Timestamp header's <Created> element is not valid."}

This error occurs because of an incompatibility between Amazon's SQS SOAP response and WSE's Microsoft.Web.Services3.Design.MutualCertificate10Assertion.

To overcome this incompatibility you will need to swap WSE's MutualCertificate10Assertion class with one of your own. This new assertion class must override the CreateClientInputFilter function.

Open the wse2policyCache.config file in Notepad or your favorite text editor and find the following entry:

<extension name="mutualCertificate10Security" type= "Microsoft.Web.Services3.Design.MutualCertificate10Assertion..>

Modify the preceding line so it reads:



<extension name="mutualCertificate10Security" type="Hyperscale.HyperAssertion, Hyperscale" />

Now create a project-specific HyperscaleAssertion class that extends MutualCertificate10Assertion as shown below

using Microsoft.Web.Services3; using Microsoft.Web.Services3.Design; namespace Hyperscale { class HyperAssertion : MutualCertificate10Assertion { public override SoapFilter CreateClientInputFilter( FilterCreationContext context) { return null; } } }



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap