REST. Getting closer to the lightbulb moment.

by Matt 14. June 2007 07:13

Does REST need a service description language? Great question. And one I would have initially said a most emphatic "yes" to. Now I'd probably so "no". Or more accurately - "you're asking the wrong question".

I think some of the fundamental differences between WS-* and REST are finally beginning to sink in. I've been viewing them as pretty much the same thing, just with different formats and tool support and stuff. But conceptually, they're actually pretty orthogonal.

WS-* is all about messaging. You send and receive messages to and from an endpoint. That endpoint is simply a processor - by and of itself, it means nothing. It's just an address. The interesting stuff is in the message. This tells the service what to do and with what data. The reply message contains the data relevant to the operation - what happened, the returned data, whatever.

REST is all about interacting with resources. You POST, PUT, GET or DELETE resources. The url is all-important - this identifies the resource. As the above post mentions:

The consequence of [this] is that there isn't much to describe; there aren't any methods or signatures thereof to document, since access to resources is uniform and governed by the verbs defined in RFC 2616 (in the case of HTTP, anyway)

You don't need a service description language, because there isn't a service. You're accessing and operating on resources. The service is pretty much implicit in the HTTP verb.

What you do need is a specification for the media type. And preferably in a machine readable format that can be used to generate code for interacting with the resource's data.

This is the question you should be asking.

The Atom Publishing Protocol is one such media type, and there are libraries (not necessarily tools) for working with that. Interestingly, following the small flurry of (*cough*knee-jerk*cough*) reactions to Dare Obasanjo's posts on Google's (out of date) implementation of the APP spec, (and without reading the spec at all!) it looks like APP is able to act as a kind of REST envelope. By which I mean when you POST a new customer to a resource (such as a collection of users), you can get an Atom doc back detailing the url of the newly added resource (customer). My knee-jerk reaction - is APP REST's SOAP?

I'm being kinda oblique with this - I know I need to study the APP before I can really make remarks like this, and I think this example was how to use the Atom Publishing Protocol to publish non Atom (as in RSS-like media type) entries. But if the cap fits...

(One point made that I really like is how the http protocol provides the optimistic concurrency for the updates via the humble etag. Very clever of the http people, and this really helped with defining the REST ideals for me. But it does mean state is maintained at the transport level, rather than at the resource level, something which SOAP has worked around by trying to be transport neutral. Another difference for you to weigh up.)

I don't buy that a client shouldn't know about the URI space of the server. For individual resources, yes. But for collections, or resources such as locks or printers, then surely the client needs to know about these (or how else does it add a new customer? Print?) So a description/discovery language of some sort is needed here too - at the least a means of knowing what media type + verb a particular resource endpoint accepts. Perhaps this is where WADL comes in (but I have to agree with Don Box's analysis of WADL vs WSDL)?

And I don't know how security and authentication is solved, either. Whatever happens, this will demand a spec at the least.

So, with all of this, is REST any simpler than WS-*? Or is it just an orthogonal concept, but just as complex?


Fixing JavaScript

by Matt 13. June 2007 15:48

Looks like Microsoft are actually working on a fix for the circular reference memory leak in their JavaScript implementation. About time, perhaps, but I'd love to know the techy details. How do they get their JavaScript garbage collector to know what references (direct or indirect) an unknown COM object holds?

Is there going to be a separate interface that lists references? This would have to be implemented on the HTML element objects, and so would fail with ActiveX COM objects.

Perhaps the GC lists all properties of a (non-JavaScript) expando object and examines them for a known interface to indicate a JavaScript object. This would allow it to know when a circular reference was made, but it wouldn't identify if the original non-JavaScript object was referenced outside of the script engine.

It's an interesting problem.

But there goes my theory about them using the new managed JavaScript from Silverlight...


COM interface types. A quick glossary

by Matt 13. June 2007 06:24

Right. Let's brush away some cobwebs, and write this down so I don't have to google all over the web whenever I need a quick COM 101 refresher:

  • A custom or vtable interface is a COM interface that derives from IUnkown. It only supports early binding through the compiler's vtable.
  • A dispinterface is a purely IDispatch based interface. The methods defined in the IDL file are only callable via IDispatch::Invoke, and not via a vtable. These are usually used as event interfaces (i.e. you implement the interface on your object and pass it to another object that you want to receive events from). Knowing this explains why it's not a cardinal COM sin that Microsoft have been expanding DWebBrowserEvents2 for each release of Internet Explorer.
  • A dual interface is a COM interface that derives from both IUnknown and IDispatch - it's both a vtable interface and a dispinterface.
  • Expando objects implement IDispatchEx and allow you to add methods and properties at runtime. This is how JavaScript, VBScript and Internet Explorer allow you to expand script and HTML objects.

A type library can be used to store interface information. It can contain vtable layouts and the DispId's required to call IDispatch based interfaces.

You can implement IDispatch by hand, with a huge switch statement, if you want to, but remember that you'll need to crack the parameters out of arrays and stuff them back in again for the return value. 

Alternatively, you can let someone else do the heavy lifting for you and use an implementation of IDispatch which is based on a type library. (And seeing how one of the methods of IDispatch is to get a pointer to an ITypeInfo interface representing a type library - you might as well). This works by calling LoadTypeLib to get an instance of ITypeLib, then calling ITypeLib::GetTypeInfoOfGuid. The resulting ITypeInfo can be used to defer the interesting IDispatch methods (including Invoke). This is what ATL's IDispatchImpl does. It's interesting to note that the Invoke method will call vtable based methods on your interface. This is pretty good voodoo.

As far as I can make out, you could also use CreateStdDispatch to create an IDispatch interface for you, which essentially does the same thing as IDispatchImpl. Or, you can implement bits of IDispatch yourself and defer to methods such as DispInvoke and DispGetIDsOfNames.

If you want to support dispinterfaces, you can use ATL's IDispEventImpl. This is an implementation of IDispatch that doesn't require an implementation of each member on the dispinterface. It does this by using a map that routes DispId's to functions - ideal for an interface that doesn't actually have a vtable. You could even use IDispEventSimpleImpl if you didn't want to use a typelib.

Sheesh. It's nice that .net moves well away from all of this malarky, but it's still something that you need to know from time to time...


Customer Debug Probes == Managed Debug Assistants

by Matt 8. June 2007 10:52

In the hopes that I can save someone wasting quite as much time as I just have on this - Customer Debug Probes have changed name and become Managed Debug Assistants. (Google doesn't appear to have joined the dots on these two, so let's hope this helps).

They're exactly the same concept, but have had a bit of an overhaul, including a new name and naturally enough, a completely different way of enabling them. This MSDN page details how to enable and configure them (individually, and in an application.mda.config file).

These are debugger messages, so you have to be in a debugger to view them. One gotcha is that the application.mda.config file doesn't work when in Visual Studio. Instead, you need to go to the Debug menu -> Exceptions window and you can enable and disable the assistants there. In use, they interrupt your running as though an exception were thrown.

This has been a public service announcement on behalf of those struggling with COM interop.


Vista preview handlers

by Matt 5. June 2007 17:07

Here's a right little collection of links for you. I should really put them on my list of Programs What I Run.

Anyway. Vista's got this nice preview pane that allows you to see, well, a preview of a selected file. Handy. Naturally enough, not all of your favourite file types are going to be supported out of the box, so here's a list of shell extensions to add that special magic.

Right. I feel a bullet list coming on.

But first things first. There is an MSDN article that showed how to build these extensions in managed code (which is allowed, because they run out of process. Don't run .net shell extensions in-process.) It adds a whole heap of previewers, but since it comes from a developer centric article, it's not exactly user friendly in terms of either installing or documentation. So, download the file, double click to extract it, go into the Installer directory and read the README.txt.

Now, you should have a previewer for:

  • .bin and .dat files, treated as binary files
  • .csv files displayed in a DataGridView
  • .isf files, which appear to be ink files from table pc's
  • .msi installer files displaying a list of all the files that might be installed
  • .resources files (used to hold strings and images during .net compilation)
  • .resx files (an xml based file that becomes a .resources file)
  • .snk and .keys files, again used by .net compilation to provide a strong name to an assembly.
  • .zip and .gadget. A rather lovely idea - displays a tree view of all the files in a zip based file. Gadget files are also zip files, so are also handled. You could take this further and register it as the previewer for .xpi (Firefox extensions), .jar files, and even .docx (although you might want to keep that one for the proper Word preview handler)
  • .pdf, via the Adobe Acrobat ActiveX control
  • .xaml!
  • Finally, there's an Internet Explorer preview handler. This is rather nifty and just displays the file in an IE control. It's registered for xml files (via the "xmlfile" registry key, not .xml. This means it gets anything that identifies itself as a .xml file, such as .rels). It's also registered for .config and an unknown .psq file type (which this link identifies as a "Product Studio Query File" and this link identifies "Product Studio" as a bug tracker within Microsoft). It also handles .xps files, because IE is the default xps viewer.

Now, a bunch of those preview handlers could handle other file types. The IE handler could display, oh, I don't know, html files? The MSDN article does have a sidebar on how to register other file types with existing extensions, but if that's too much of a drag, you can try this association editor.

And that's all from the same guy. What can anyone else add?

Oh, and these all work in Office 2007 on Vista, too. But not XP. Fortunately, someone has done all the dirty work of back-porting support for Office 2007 on XP. This package also includes most of the preview handlers already mentioned, but with a few more file types registered, such as .html, .htm, etc.


Vista | Shell Extensions | Preview Handlers

Programmatic access to UAC. Kinda.

by Matt 5. June 2007 05:28

I kinda like this web site. It offers a C++ source file with various functions to help in install time situations; functions like IsVista() and IsWow64(). And it also gives some functions to deal with User Account Control. GetElevationType(), IsElevated() and RunElevated() are going to be very useful.

The killer function, though is RunNonElevated(). This is a doozy.

Picture this - I run my installer. It needs to write to C:\Program Files, so gets elevated. Trying to be as nice as I can to my user, I offer them a chance to run my program at the end of the installer, as is common. Unfortunately, since the installer is now running elevated, my newly installed program will run elevated, which is not what I want.

So this function could be very useful. The downside is that Microsoft haven't actually provided any means of running a program non-elevated, so this function has to hack around it by injecting itself into the shell, which it knows is not elevated and getting explorer to spawn the process.

Is it just mean that sees the irony in having to inject code into one process to run another process securely?



Using C# 3.0 from .NET 2.0

by Matt 4. June 2007 18:32

I'm looking forward to Orcas. It's a (mostly) additive release, similar to 3.0. The CLR itself doesn't really change (there is a service pack level update, but you're essentially still running v2). There are updates to the compilers, the IDE and new libraries that add to .net 2 and .net 3.0 (such as System.Core.dll).

One of the nice things Orcas allows is "multitargeting", where you can target different versions of the framework (2.0, 3.0 or 3.5). Of course, if you're targeting a down-level version, you'll lose support of that framework version's assemblies (e.g. no WPF apps in a 2.0 targeted application). What might not be obvious is that the compiler still supports the 3.5 features, including the nice LINQ "select ... from ... where" syntax (although there's a caveat around that one).

Thanks to Daniel Moth for all this info!


.net tools

Amazon's SQS service

by Matt 4. June 2007 05:57

Wow. I've only just realised how impressive Amazon's web services are. I've always liked their Simple Storage Service (S3), but well, that's just data storage - it's not terribly exciting (although I keep meaning to look into the opportunities for backup-to-the-cloud).

Today I stumbled across their hosted message queue service. This is all a bit more, well, enterprise-y. It's a B2B type solution, and normally, if you needed a message queue in your enterprise architecture, you'd host it yourself. Now you don't have to. Instead, you can pay Amazon to do it - per message, per amount of data in and per amount of data out.

And on top of this, Amazon have released a WCF transport for it, making it nice and easy to use from your favourite Microsoft messaging library. (Although looking at it, it's a community sample, albeit one provided by the Amazon team - the download is hosted on Microsoft's .net 3 sandbox site.)

Microsoft have recently dipped their toes in this area, too, with the release of a CTP version of their BizTalk Services (of course, Amazon's queue is already released). Microsoft's offering is perhaps broader in scope (as always), including identity federation (via the marvelous CardSpace) and a service relay, which is, at a squint, the closest match to Amazon's queue, although it's most definitely not a queue. It looks like Workflow hosting will come soon, too, which will be one to watch.

These are interesting moves, pulling key enterprise architecture out to hosted providers. I wonder where this will go, and who will use it? And I wonder if the people who do use these types of queues will still have queues at their end of the wire?


Snooping WPF applications

by Matt 29. May 2007 17:42

Rob Relyea has just posted a couple of links to WPF utilities to check out.

Firstly, there's a debugger visualiser for the element tree. Haven't tried it yet, but I do like the idea of these kind of visualisations.

The one I did try was Snoop, which is a very impressive tool to interrogate the visual tree of a running application, and display the tree, plus properties and events. Dead useful - think Spy++ for the 21st century. It's a little intrusive (it injects itself into the application being viewed), but I can live with that.

And that took me on a nice little stroll to see how WPF draws the navigation UI for the Frame class. Starting with this incredibly in-depth article (far too good to be simply a blog post) from the always brilliant Ian Griffiths on how WPF defines the default Template for a control, which then took me to the BAML decoder plugin for Reflector, which showed me the XAML for the resources in PresentationFramework.Aero.dll, which opened my eyes to the very nifty way that WPF handles resources and Templates and how a control's visuals can be made up with other controls. I like this WPF thing.


EV cert support for Firefox

by Matt 29. May 2007 04:10

IE7 introduced support for Extended Validation SSL certificates (aka High Assurance certificates). Any time you hit a site with one of these certs, the address bar changes colour to green. I've previously posted links to a couple of sites Microsoft host that allows you to test this.

While scouring the net looking for ways of integrating this into a project that hosts IE's web browser, I came across this article on Wikipedia, which contained this link to a plugin to enable the nice green address bar in Firefox. And it's written by VeriSign, which is nice of them (considering other CA's certs are going to be in competition with them).

Unfortunately, its support is not as complete as IE7. Currently, it only knows about EV certs from VeriSign, Thawte and GeoTrust. (Wikipedia lists 7 other CA's that support EV.) But it's a good start.

And if you're interested in how EV certs are implemented, just download the Firefox .xpi file and change the extension to .zip. You can see it's got a certs folder, containing various new root certs for the CAs. I don't pretend to know why they need new root certs, or why the old ones can't be used. The chrome folder has a .jar file, which can again be renamed to .zip and extracted. This contains a bunch of css files, some images and some Javascript.

evcextension.js is the file with all the goodies. And it's here where you can really see how messy the EV implementation is. Each CA has their own OID that marks a cert as being EV. (OID is an object identifier. Think of it as the way a cert identifies each of it's properties.) And since each CA has their own, they're all different. So, the process is to walk the certificate chain. If the certificate contains one of the recognised OIDs, the hash of the chained root cert must match the expected hash of the OID matching CA's root cert.

Fairly simple process, but messy - the addin must know about all CAs, all of their root certs and the OID they choose to identify their version of EV. (And there are other parts to implement too, such as changes to the revocation list checking.) So any change to a CA root cert, or adding new, known CA's requires an update to the addin.

The above linked Wikipedia article lists 10 CA's. Theoretically, it should be easy to add support for all of them. Just add the OID's and the matching root certs. Of course, finding all the root certs might be a bit tricky, especially when there looks like there are new ones that need to be downloaded and installed. I wouldn't like to mess here - just leave it to the people who know about this stuff.

Of course, the nice test site run by Microsoft doesn't work because the Firefox addin doesn't know about Microsoft's test root cert. That is something that I wouldn't mind hacking.

So, now we know how to support EV certs. We've got to do a lot of leg work and find out all the CA's that support it, what their OID's are and what their root certs are. If any of them change, we won't get notified. If we do find out they've changed, it's an update to our implementation (and we'd have to be careful about putting that data in config - we don't want it hacked so that any cert can be labeled EV).

Wouldn't it be nice if Internet Explorer exposed its implementation for the rest of us to hook into, especially when hosting the WebBrowser control?



Month List


Comment RSS