Journey to robust web services: installing a WCF 4.0 application on IIS 6.0

Due to budget and other constraints, I'm unable to get my hands on the latest and greatest software for running a WCF application I've been working on, so I'm forced to use what my company's got: Windows Server 2003 and IIS 6.0. Suffice it to say that working with these old bits of software are less than ideal. However, I'm stuck with it. So, moving forward, here's some of the things I found while working on the application:

1. There's no easy way to set certain items in the registry for the Network Service user. (Sorry, for various reasons, I can't elaborate on that statement.)
2. Due to (1), I've decided to run my application as a custom normal (non-Administrator) user that I've created. However in order to use this user with IIS and its applications, certain steps must be taken.

Using a custom user to run an IIS 6.0 application

The following are pre-requisites in order to be able to use a custom user to run an IIS 6.0 application:

• The user must have already been created and should have absolutely the least number of privileges possible.
• Thanks to this question on Stack Overflow, the following must also have the following:
• The "Log on as a service" right (Start -> Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment -> Log on as a service)
• "Access this computer from the network" (similar location as in the step above)
• "Deny logon locally"
• "Log on as a batch job"
•  "Read & Execute", "List Folder Contents" and "Read" access to the file system that underpins the web site/application
• Thanks to this troubleshooting article on MSDN, I also found out that the user must be part of the "IIS_WPG" group.

I now have other problems to worry about with this application, but at least now I know that they're not related to how I'm running the application in IIS.

Journey to robust web services: apparently we shouldn't use 'using'

I recently stumbled across an article stating why we shouldn't use the 'using' keyword with WCF services, and I found it rather interesting. I'd have to re-read it, and re-evaluate it, before I use it but you can read the blog post on the original site.

Journey to robust web services: debugging services and logging messages

One of the quickest and best ways to debug issues with the services you're developing is to log and trace all activity with WCF along with the messages being sent back and forth. This page on MSDN will provide you with the instructions required to setup logging and tracking for WCF.

Journey to robust web services: debugging a net.tcp service

I'm creating a net.tcp-based WCF web service for use with my current project, and so far the learning curve hasn't been very shallow. I've just recently learned, thanks to this post on Stack Overflow, that the default ASP.NET application doesn't support the net.tcp protocol, so IIS must be used instead. With that in mind, I've decided to move on to just using the Web Service I'm creating through a Windows Service via a ServiceHost. However, I've now encountered some problems debugging the Windows Service startup. This page on MSDN contains links and instructions on how to debug the startup of a Windows Service. While attempting to install the Debugging tools, I encountered a failure trying to install them as part of the Windows 7 SDK. This page on Stack Overflow had a solution, but it wasn't quite complete. This page had the missing parts.

Journey to robust web services: configuring your WCF web service

WCF comes with a bunch of handy configuration tools.  You can find an introduction to them on the WCF configuration tools page on MSDN. Once you've created your WCF service project in Visual Studio, you'll need to use these tools to configure the service beyond a simple and basic test environment (which uses a Basic HTTP binding by default).

The specific tool mentioned on this page that you'll want to use is the Service Configuration Editor (svcconfigeditor.exe). This tool is used to edit Web.config files for WCF services. It comes with a handy wizard for adding a new service. When using this wizard, I ran into an error message similar to the following when trying to select the assembly I built containing my service: "Could not load assembly. This assembly is built by a newer runtime than the currently loaded runtime and cannot be loaded.". To solve this, I had to go and change the application configuration file for the program ("svcconfigeditor.exe.config" in the same directory as the program). I added the following under the root 'configuration' element:

 <startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v2.0" />
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
 </startup>

This will allow the program to run using your currently installed framework (mine happened to be 4.0).

XML namespace error with Spring WS

Today I ran into a strange error trying to access a webservice via Spring WS (Spring Web Services). The exception looked like the following :

org.springframework.ws.soap.saaj.SaajSoapEnvelopeException: Could not access envelope: Unable to create envelope from given source: ; nested exception is com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source: 
Caused by: 
com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source: 
 at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:95)
 at com.sun.xml.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelopeFromSource(SOAPPart1_1Impl.java:51)
 at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:106)
 at org.springframework.ws.soap.saaj.Saaj13Implementation.getEnvelope(Saaj13Implementation.java:145)
 at org.springframework.ws.soap.saaj.SaajSoapMessage.getEnvelope(SaajSoapMessage.java:84)
 at org.springframework.ws.soap.AbstractSoapMessage.getSoapHeader(AbstractSoapMessage.java:42)
 at org.springframework.ws.soap.server.SoapMessageDispatcher.handleRequest(SoapMessageDispatcher.java:91)
 at org.springframework.ws.server.MessageDispatcher.dispatch(MessageDispatcher.java:189)
 at org.springframework.ws.server.MessageDispatcher.receive(MessageDispatcher.java:166)
 at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handle(WebServiceMessageReceiverObjectSupport.java:78)
 at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:60)
 at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:819)
 at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:754)
 at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:399)
 at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:364)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
 at java.lang.Thread.run(Unknown Source)
Caused by: javax.xml.transform.TransformerException: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
 at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
 at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source)
 at com.sun.xml.messaging.saaj.util.transform.EfficientStreamingTransformer.transform(EfficientStreamingTransformer.java:371)
 at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:83)
 ... 30 more
Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
 at com.sun.org.apache.xerces.internal.dom.AttrNSImpl.setName(Unknown Source)
 at com.sun.org.apache.xerces.internal.dom.AttrNSImpl.(Unknown Source)
 at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createAttributeNS(Unknown Source)
 at com.sun.xml.messaging.saaj.soap.SOAPDocumentImpl.createAttributeNS(SOAPDocumentImpl.java:142)
 at com.sun.org.apache.xerces.internal.dom.ElementImpl.setAttributeNS(Unknown Source)
 at com.sun.xml.messaging.saaj.soap.impl.ElementImpl.setAttributeNS(ElementImpl.java:1190)
 at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.startElement(Unknown Source)
 at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(Unknown Source)
 at com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(Unknown Source)
 at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.startElement(Unknown Source)
 at org.xml.sax.helpers.XMLFilterImpl.startElement(Unknown Source)
 at com.sun.xml.messaging.saaj.util.RejectDoctypeSaxFilter.startElement(RejectDoctypeSaxFilter.java:157)
 at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
 at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
 at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
 at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
 at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
 at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
 at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
 at org.xml.sax.helpers.XMLFilterImpl.parse(Unknown Source)
 at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(Unknown Source)
 ... 34 more

As it turns out, the Java 6 JDK comes with its own integrated versions of Apache Xerces and Apache Xalan. The problem is that the integrated versions are old. Updating your project's POM to ensure versions of Apache Xerces >= 2.8.1 and Apache Xalan >= 2.7.0 are in your classpath will remedy the problem.

A quick note on ActiveResource in Ruby on Rails

I've learned a bunch of new things about Ruby on Rails in the past few days, specifically when it comes to RESTful web services.

• ActiveResource uses the built in Ruby XML::Mapping library for its OXM (Object to XML mapping) layer


• Apparently, no Ruby library out there properly handles namespaces. Not a one : REXML, ROXML, XML::Mapping


• ActiveResource can be highly customized to adjust to other RESTful web service schemes, just not when it comes to the generated XML.

Unfortunately this makes it very hard to integrate (in ruby) with the RESTful web service that I've written for our company's production web site. Ironically, I wanted to make the service very Ruby friendly. I really wish there was more in depth documentation out there for Ruby APIs. It would have made things so much easier when I was designing our API, which runs in Java, using JAXB.

Software developers are arrogant assholes

Like the title of this post says, software developers are arrogant assholes. I can say that because I am one. The reason I say this is that I've been Googling like a mofo for articles related to RESTful development and RESTful web services servers using Ruby on Rails, and I must say that it's a real pain in the ass. The vast majority of the articles I'm able to find are in blog format, and are (as is typical with blog-style articles / tutorials) very vague, and don't provide enough detail for a learner to get going. Essentially, they make the assumption that you already know something about Ruby on Rails, and it's a rather hypocritical assumption for a tutorial / article to make. I will admit that I've been somewhat guilty of doing this same thing in my own blog whenever I've provided code examples, so it stops now. Any future "tutorials" on this blog are going to be as complete as possible, time constraints at work be damned. Vagueness cannot be allowed to continue.