Infovark Underground

  • news
    • infoblog
    • underground
  • product
  • download
  • buy
  • support
  • about
  • Web Services

    • Looking for an IIS Alternative

      Posted by Dean on December 1, 2009

      One year ago it became clear that Infovark had outgrown the Windows Communication Foundation (WCF).

      We’d decided to use WCF because we wanted Infovark to provide web services, and we liked the fact that we could deploy WCF to client machines. Since WCF is built directly on top of HttpListener, a core part of the Microsoft .NET Framework, we wouldn’t need to use System.Net or Microsoft IIS.

      But we’ve struggled with WCF for a variety of reasons. First, we wanted to use a REST model for our web services, and WCF’s support for REST architectures lags behind its SOAP support.

      Second, there’s no easy way to return HTML from WCF. We tried transforming our XML with XSLT and returning the XHTML results as a Stream. This works, but the programming experience is frustrating.

      Last, because of the previous two reasons, we were left with a website that was way too rigid and programmer-like. It didn’t feel like an organic website. The tool we’d picked was forcing us to compromise on our website design goals.

      Infovark’s primary mission is to help human beings, not other computers. That means that the look and feel of the web interface should be our number one priority. Awesome web services are nice to have, but happy users are more important.

      Web server alternatives

      So for the past few months, we’ve been hunting for an alternative web server. We can’t use IIS because its footprint is too heavy. Most IT departments won’t allow us to install IIS on client machines.

      We could use Apache. It has a nice embeddable version, but interacting with it via C# is tricky. We’d prefer something a little more Microsoft-native.

      That basically leaves us with one commercial option and two open source options.

      1. UltiDev Cassini is a commercial product that’s been around for some time. We’re sure it could do the job, but the licensing model is cost prohibitive.
      2. C# WebServer is an open source project on CodePlex. It’s been around for two years, but the pace of development seems slow.
      3. Open Rasta is the brain child of Sebastien Lambda, an open source framework for the development RESTful development of web sites and services. It’s been getting a lot of attention recently.
      4. Kayak is a promising open source project, but it hasn’t reached its first public release yet.

      (If you know of other web servers worth investigating, please let us know in the comments!)

      Making the switch

      More important than picking an alternative web hosting framework for Infovark is the timing of the switch. We don’t want to impede future development.

      As a stopgap, we might try plugging in the Spark View Engine to replace our current XML-XSLT-XHTML rendering path. Who knows? If it improves our web development flow, we might be able to keep our WCF base after all.

      Continue Reading

    • REST: How to respond to an HTTP POST

      Posted by Dean on March 24, 2009

      I ran into a problem yesterday. I’d sent a HTTP POST request to a collection of resources on our RESTful web service. Our server responded with an HTTP 201: Created status code and the URI of the new resource in the Location header.

      And then… nothing happened.

      This was not what I was expecting. I expected my web browser to follow up with a GET request to the URI I’d provided. But Firefox 3 wasn’t biting. A problem with Firefox? I checked in IE8 and Google Chrome and got the same behavior.

      Had I misread the HTTP spec? Did I misunderstand the REST pattern? I grabbed for my worn copy of RESTful Web Services. Nope. HTTP 201 seemed to be the right status for this situation.

      Had I blundered into some common error? I checked Stefan Tilkov’s useful list of REST Antipatterns. But I couldn’t find anything that quite matched my situation.

      I started Googling, but couldn’t find much apart from this question about HTTP Post on Stack Overflow. There were some cryptic responses (to which I’ve added my own answer now).

      Eventually, I discovered what I needed to know from Ben Ramsey’s article on HTTP redirection. It’s part of his series discussing RFC 2616, which describes the HTTP/1.1 protocol.

      The answer is that while web service clients will often “take the hint” provided by a HTTP 201: Created response, web browsers won’t. If you actually want a web browser to go somewhere else, you need to send a status code in the 3xx series. In this situation, the status code you want is HTTP 303: See Other.

      Once I changed the status code returned by the server, all the web browsers followed up the response with a GET to the new URI.

      Continue Reading

    • Put the “Web” Back in Web Services

      Posted by Dean on February 5, 2009

      I know it’s possible to transmit Internet Protocol by carrier pigeon, but I’m not sure I could recommend it to our customers with a straight face. By the same token, I’m continually surprised to hear vendors and consultants insist that Web Services can be done without the web.

      Yet I’ve seen that claim repeated all over the Internet. Sure, it’s true in the academic sense. Technically, there’s nothing wrong with “webless” web services, just like IP by avian carrier will eventually get the job done (though latency and packet loss are a challenge). But practically speaking, why would you use anything other than HTTP?

      The “webless web services” meme has infected a number of good ideas. The SOAP standard is a case in point. At first, SOAP was a simple XML wrapper around an XML payload. (Remember when the S in SOAP stood for Simple?) Then a variety of industry heavyweights jumped on the bandwagon, and soon SOAP could be used with any protocol.

      With, uh, a few changes. Like five or six additional specifications. And schema. Lots of schema. Maybe a diagram would help? No?

      Why not use REST instead?

      Nicholas Allen recently shared a great presentation on REST and SOA given by Stefan Tilkov at QCon. Stefan makes some great points about how RESTful web service design aligns well with the goals of Service Oriented Architecture (SOA).

      Sure, you could use the WS-* stack if you like, but RESTful web architecture is a proven, scalable and truly simple approach, as long as you don’t mind having to use HTTP.

      Much of the added plumbing in the WS-* stack is there to help transition older computer-to-computer network communication technologies. It allows applications that depend on CORBA or DCOM to tunnel through firewalls. But unless you’re trying to retrofit a system built before, say, 1998, you can skip all that stuff.

      Wasn’t using web protocol the whole point of web services anyway? As Stefan said in his closing comments: “Protocol independence is a bug, not a feature.”

      Use a RESTful architecture for new development. Put the web back in web services.

      Continue Reading

    • WCF Instance Context

      Posted by Dean on May 21, 2008

      I finally figured out the source of my HTTP 400 problem. Apparently the Windows Communication Foundation deals with exceptions differently depending on your InstanceContextMode settings. I had been using the Single setting but I should have used the PerCall setting. In PerCall mode, the try/catch block works as expected.

      I think it has something to do with the way that WCF distinguishes between channel exceptions and message faults.

      Anyway, if you’re building a REST web service, you’ll want to make sure your class is decorated with the following ServiceBehavior attribute.

      1. [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]

      Continue Reading

    • Using WCF for REST, Part 2

      Posted by Dean on May 17, 2008

      In part one of this series, I listed several websites and blogs that had useful information on the Windows Communication Foundation (WCF) and REST. I also mentioned that if I was stating again, I’d probably use something other than WCF. Perhaps deriving my own REST server from System.Net.HTTPListener, for example.

      Vish asked for some additional details in his comment to that post. He works on the Microsoft WCF development team and was curious about our experience.

      I had just begun putting together my response when I noticed Scott Guthrie’s post about Service Pack 1 for the .NET Framework 3.5 beta release. Steve Maine also posted specifics about the ADO.Net Data Services and WCF changes.

      So, Vish, it seems your team’s beaten me to the punch on some of these issues! Many of the difficulties I was having with WCF and REST were addressed by the service pack. Here’s an overview of our key stumbling blocks:

      1. REST requires much greater control over the URI than SOAP does, and the URITemplate class just wasn’t up to the task. We had to hardcode most of our endpoints to compensate. (Fixed in SP1. Hooray!)
      2. Supporting multiple formats, such as serving both XML and JSON, either require you to program against Stream or require twice the number of endpoints.
      3. Existing serializers had trouble with complicated object graphs, forcing us to perform serialization/deserialization ourselves. (This seems greatly improved in SP1.)
      4. WCF allows only one contract/interface per endpoint. This makes it tricky to factor out common contract patterns.
      5. Good REST practice would have you return many kinds of errors as HTTP status messages. SOAP embeds all error information in the returned XML. WCF is closely aligned with the SOAP approach, which means that you’ve got to be very careful distinguishing exceptions from faults when implementing REST in WCF. It was an unpleasant surprise, and we had to do quite a bit of work to deal with that.

      I’ll talk about all five of these areas in more detail in upcoming posts in this series. And I’ll be sure check out the SP1 beta once we get our Infovark Alpha release out the door.

      Continue Reading

    • 1
    • 2
    • Categories

      • .NET (43)
      • AJAX (3)
      • Books (7)
      • HTML (9)
      • Infovark (8)
      • Programming (50)
      • REST (11)
      • SQL (3)
      • Testing (3)
      • Tools (13)
      • UI (3)
      • WCF (11)
      • Web Services (8)
      • WPF (4)
      • XML (4)
    • Archives

    • Get future articles


       

    • Blogroll

      • Ajaxian
      • Anne Van Kesteren
      • Brain.Save()
      • Coding Horror
      • Eric Sink
      • Joel Spolsky
      • John Resig
      • Mark Pilgrim
      • Raymond Chen
      • Scott Hansleman
      • Secret Geek
      • Steve Yegge
      • The Daily WTF
      • The Database Programmer
    • Meta

      • Log in
      • Entries RSS
      • Comments RSS
      • WordPress.org
  • Site map

    • News
    • Product
    • Download
    • Buy
    • Support
    • About
  • Recent Posts

    • Illuminating Lucene.Net slides and code samples
    • Coding for an audience
    • Preparing for my Lucene.NET presentation
    • Review: Brownfield Application Development in .NET
    • Using Modal Dialogs with a Splash Screen in WPF
  • Twitter

Copyright 2013 Infovark, Inc. All rights reserved.