Omniscient's Foundation - Blog

Recently I've been called to work on an exiting project and that involved creating a basic authentication module for IIS and ASP.NET. I've already done modules in the past so that wasn't really new to me, but I took the time to go deep into that and see where that could lead us.

Basic authentication is part of the http specification and involves sending an "www-authenticate" header to the client agent (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47), along with error code 401 (Unauthorized). In turn, the agent prompts for a username and password and replays the request, taking care to include the "Authorization" http header. That header has a value encoded in base64 (the most basic "encryption" (with quotation marks big as a house - I should rather use the term "obfuscation")). That value, once decoded, has the form "username:password", with whatever values provided by the end user. As a side-note, it should be clear that basic authentication should never occur on an unprotected channel.

Read more »

Contrary to WPF, Silverlight doesn't really support Commands in the xaml. For example, the Button class doesn't have a Dependency Property called Command that allows to bind to a command. The command pattern is at the heart of the Model-View-ViewModel pattern (M-V-VM), and this pattern is probably the most important in WPF and Silverlight. Thus, we had to find a way to have it in Silverlight!

Read more »

In my last post, I discussed how object relations (references and collections) should be kept away from an Entity but for extraordinary cases where an entity cannot live without being attached to other entities (strong relations). I discussed that if one describes relations directly in the entity (a reference to another entity, or a collection of entities), then one adds a lot of complexity to their system, because they have to tell the backend how "deep" entities should be loaded, how deep it should look for dirty entities upon saving, deal with circular references and somehow flag the references to tell when there's just no data as opposed to when the reference is lazy loaded. Plus, one looses the ability to quickly define different object graphs with their entities.

Read more »

As discussed in Part I, an entity is all about data. Since an entity is also a POCO (Plain Old Clr Object), it's quite easy to code the entity so that it defines relations to other entities. Just think of a Parent entity that would have a collection of Child. Most of the ORMs (object relational mappers) I know concentrate on how to deal with such relations, often coming with a DSL to describe constraints put on those relations (e.g. "OK ORM, load all Parents that have at least one Child whose Age is greater than 5"). When I built ObjectSpace (a proprietary ORM used by my first employer), I fell in the same trap. Yah, I just meant it, a trap.

Read more »

Recently SOA (service-oriented architecture) has became just another buzzword. Everybody talks about it, books have been written on the subject and most people look at it as a complex technology one should master in order to live an accomplished life.

Thing is, SOA is ridiculously simple. It's just about hiding a set of functionality (service) behind known contracts (most of the time, a single contract - interface, in other words) and defining a generic way of discovering (instantiating or otherwise getting a grab on) those services. The goal is that service consumers (the coder) don't have to bother with details as to what technology the service is written with (.NET, COM, Java, Web Services, name it), where the service's code will execute, how to instantiate such service, what version is this, etc etc. That's it. Simple, I told you.

Now, Foundation supports (and advocates) SOA since the very first day of its creation. As I just demonstrated, SOA definition stands in a single paragraph. Why try to make it any more complicated in the code? Keep it simple, baby!

Read more »