Sunday, June 3, 2012
Requiring SSL over HTTP WCF with an upstream proxy
Its a common problem with WCF services that you have a deployment infrastructure that will strip the SSL before the traffic arrives at your service. This is so the site only needs one certificate but can still use a farm of servers to respond to requests. A proxy or firewall holds the certificate and strips the SSL out before forwarding traffic onto the server farm. There are reasons why you may still require specifying TransportEncryption (SSL) in your service config. When you do the service will fail because SSL is expected but traffic received is not encrypted.
To fix this problem Michelle Leroux Bustamate of IDesign has provided a solution here.
There is also a hot-fix published by Microsoft, that adds the enableUnsecuredResponse attribute and this is reputed to solve the issue as well. Although I haven't personally tried it.
To fix this problem Michelle Leroux Bustamate of IDesign has provided a solution here.
There is also a hot-fix published by Microsoft, that adds the enableUnsecuredResponse attribute and this is reputed to solve the issue as well. Although I haven't personally tried it.
A word of warning regarding manual GC
I was party to an email conversation discussing manual manipulation of the GC. Originally the thread was discussing extreme memory and performance management. Stephen Cohen, Senior Architect at Microsoft added the following response:
A quick word of warning;
Calling the GC is possible but generally not wise. In many scenarios you will find performance drops. Worse yet, the GC is not limited to a single application (unless you are the only application on a device/server). Calling GC might seem good for you but what about any other application that could be impacted?
In my experience wanting to call the GC directly should raise a flag on the application design and set of a deep design review to investigate before implementing a change. With rare exception you can find a way to manage the flow of data, the size of chunks, number of instances, use of critical sections or parallel processing, etc that will remove the need to call the GC.
That said, it can be done but you should allocate a lot of time to test with enough instrumentation that you can both validate a positive result … better performance than the baseline… and confirm no negative side effects.
A quick word of warning;
Calling the GC is possible but generally not wise. In many scenarios you will find performance drops. Worse yet, the GC is not limited to a single application (unless you are the only application on a device/server). Calling GC might seem good for you but what about any other application that could be impacted?
In my experience wanting to call the GC directly should raise a flag on the application design and set of a deep design review to investigate before implementing a change. With rare exception you can find a way to manage the flow of data, the size of chunks, number of instances, use of critical sections or parallel processing, etc that will remove the need to call the GC.
That said, it can be done but you should allocate a lot of time to test with enough instrumentation that you can both validate a positive result … better performance than the baseline… and confirm no negative side effects.
Manipulating the GC will affect other .NET applications running on the server.
Tuesday, May 29, 2012
WCF Service Diagnostics Part 2
In the previous post on this topic I gave an outline of the most common tools used to look into problems with WCF. In this post I'll give some more information on more advanced tools and approaches for more insidious problems.
SOAP Xml verfication.
It is quite common to use WCF services as the boundaries between different parties or boundaries between responsibilities of teams. Just like defining an interface so two developers can work on either side in parallel, one developing the interface implementation and the other the consumer; so can service WSDL be used. In this scenario parties often swap SOAP xml requests and responses as files and check them against their own code.
Tools that can be used are:
SOAP Xml verfication.
It is quite common to use WCF services as the boundaries between different parties or boundaries between responsibilities of teams. Just like defining an interface so two developers can work on either side in parallel, one developing the interface implementation and the other the consumer; so can service WSDL be used. In this scenario parties often swap SOAP xml requests and responses as files and check them against their own code.
Tools that can be used are:
- SOAP UI. Basically this tool allows you to copy and paste SOAP Xml into its UI and then send it to a service. It will also allow you to see the response SOAP. Obviously however it is specific to the SOAP protocol and HTTP. It does appear to have loads of other functionality that could be useful particularly for JAVA based diagnostics.
- Fiddler can be used as well. I have used it to look and record the HTTP traffic before, but apparentely you can also use it as a proxy to return preconfigured responses as well (although I personally haven't tried this).
- WsdlSoapXmlValidator. This is a rough tool I have written to take request and response SOAP xml and verify them against the embedded XSD schemas within WSDL (it assumes the WSDL includes Schema and will not work otherwise) and then host a dummy service compliant with the WSDL and using the request and response xml against the service to test actual WCF deserialisation of the samples.
- WireShark is another tool I have reached for on odd occasions to view network traffic. This is useful for TCP/IP and binary based protocols.
- WCF Load Test Tool. This is a free codeplex tool written by the Visual Studio ALM Rangers.
Subscribe to:
Posts (Atom)