"Scripting Language" is not a Four Letter Word

I can admit when I am short sighted and my initial reaction years ago to JavaScript was a little dismissive.  Sure it could do some neat little tricks, but to my Math major mind, it lacked the shear number crunching and algorithmic powress of "real" languages like C.  Over the past 12 years since I first saw JavaScript (I was only a little late to the game, it was invented in 1995), I've come around.  Today I am going to tell you why I had that first unguided reaction, a little about the history of JavaScript since those days and why I think that what makes JavaScript different from compiled languages is exactly why you need to add some real control of this language to your programmer tool box.

So, Why My Reaction and a Little JavaScript History:
First off, as a programmer I believe in the power of names.  Call a variable something stupid and your code becomes infinitely more difficult to read and understand.  Through misunderstanding bugs are harder to see and errors are easier to make.  So, maybe I can blame my reaction to JavaScript partially by its name.  So, the script part of it is right, it is a scripting language, but the Java part is misleading.  The only thing JavaScript has in common with Java is the same thing both have in common with C; slight syntax similarities.  Originally, it had been named LiveScript.  What a great name!  LiveScript implies a little more a what we use it for now.  But, back in the day it was created by Netscape (specifically Brendan Eich) to make Navagator's new Java support more accessible to non-programmers.  Wait, there goes my bias again.  Netscape wanted to allow an easier way to tie into page elements (like images/forms/frames/etc) without a bytecode compiler.  Because seriously, as much fun as manipulating a bytecode compiler is, it does take time.  JavaScript offers a way to harness events without jumping through a lot of hoops.  I know one guy who back in the very early 90’s had to use COM object and dynamically hack into the kernal to get to those sorts of events.  Needless to say, he loves JavaScript.  It’s a much easier solution.  

Of course, my first reaction to JavaScript was many years ago before it had become more robust.  Back then it lacked simple things like exception handling. Also, it was too powerful for its own good.   Try to do some simple things and your browser would crash. Then again, give me a programming language and I’ll show you a thousand examples of devs not leveraging resources properly.

Even then, I did not like that it did not force you to use propper OO techniques.  It did not like that it was not compiled and I did not like that it was not type safe.  Another way to say this is that I did not like how loose and flexible JavaScript is. Because it is so loose and flexible that you can really, really easily write some really, really bad code.  And for whatever reason those really bad code snipets seem to be the ones that are the most quickly proliferated around the Internet and those are the ones that I had seen.  Since it’s got such lose typing any object can at a whim modify any part of any other object leaving it very exposed to malware.  And since it’s not compiled, it will never be as optimal as a C program could be, and any one can steal the logic you created.

But, loose and flexible doesn’t mean bad and just because you can do dumb things, doesn’t make the language dumb.  And these very things that I disliked back then are part of the reason I like it now.

People with little to no experience can rip scripts off the Internet and coax their browsers to do some pretty cool things, opening up possibilities for amatures.  But those of us with a deep theoretical background in computer science can learn quite a bit from this scripting language.

What Now?
I've grown a lot professionally since the mid-nineties.  And so has JavaScript (damn, are we sure we can't re-re-name it back to LiveScript).  The bulk of why I disliked JavaScript a decade ago is still there, but now we can leverage it more.

It’s not perfect, but it is a tool.

I’m not going to argue whether or not it’s an OO lanaguage.  I don’t care.  I care what it can DO.  And, what it can do is a heck of a lot more than what CPM (copy paste modify) coders are leveraging.  And that’s why you need to learn how to really write it.

What JavaScript is, is a Dynamic Language.

So, it’s got loose typing.  As I said, that’s part of the reason I didn’t like it.  But, what that means is that has Dynamic Typing.  It has lambdas.  It has great closure support.  You can dymically add methods.  So, say you get a bit of JSON from the server.  On the client you can take that and mutate any function or property you want.

I also disliked that it was not compiled.  But, what it is, is Interpreted.  Don’t use JavaScript on your webpage when you don’t want to, but want to use it when it’s in the user’s best interest.  You can evaluate things on the fly without having to bother the server.

One of the most popular JavaScript libraries today is jQuery.  jQuery allows the developer to more quickly (by quikcly I mean with fewer lines of code in this case) do some really cool stuff with JavaScript by acting as a framework to extract away various JavaScript interactions.  It’s not the only JavaScript library, but, it is much more lightweight than it’s competitors.  It has many, many plugins that allow you to do things from dynamically sorting tables of data to asynchronously uploading documents to cascading drop downs that call back to the server when trying to populate the secondary drop down.  

What about jQuery makes it be able to do these things?  jQuery has a very fluid interaction with the DOM making it very simple to traverse.  Those three examples above might sounds simple, but those are very complex client-side interactions.  It’s the simplicity of these client side interactions that made me come around to JavaScript in the first place.  jQuery is like JavaScript on steroids (where those steroids are a library to use JavaScript easier).  And the beautiful thing is, since JavaScript is so dynamic, you can extend these functionalities however you want.  Now, this is why it’s a real programming language.  You’ve got nearly unbridaled access to the DOM.  You’ve got the ability to ping little trickles back to the server.  If you know what you are doing, there are some seriously cool things that you can start doing.

JavaScript and the extensions done on it by jQuery makes AJAX syntax very clean.  The J in AJAX is for JavaScript, but without a powerful library can be clunky.  We can forget about the update panel (which we should since all it does it break the page life cycle) and start using the HTTP protocol like it was meant to be used.  We can post and get what we want when we want it.  And that’s not a toy, my friends, that can get pretty complicated pretty quickly.

And, I love the Intelesense support in VS 2008.  And I love how easy it is to download and how light weight it can be.

Well, I feel like I’ve just gone into a jQuery love-fest.  But, that’s why I stopped hating JavaScript.  I just love the powerful interactions it enables too much.   And that’s what it comes down to.  Everything scary about JavaScript is part of what ends up making it such a powerful tool in my coding arsenal.  

In Conclusion
JavaScript is not the only tool to solve some of these problems and there are more libraries out there than just jQuery, but these are just tools.  Flash and Sliverlight can accomplish many of the same dynamic (aka no page reload) benefits as JavaScript.  But JavaScript, especially when leveraged by it’s jQuery library, can open up amazing doors in the web space.  If Snobby computer science purists, I’m sorry.  I understand where you are coming from, and I usually consider myself among your numbers, but if loving JavaScript is bad then I don’t want to be good.  

There’s a lot more you need to know before you can start really using JavaScript and jQuery.  I just hope that if you feel the way I used to feel about JavaScript, this article has helped you come around at least a little bit.

Basic Intro to WPF

I’m an ASP.NET girl.  I really don’t do much for console applications, but I thought it would be fun to look into WPF (Windows Presentation Foundation) a little bit.  WPF can do both standalone and browser-hosted, but today I want to focus on a standalone application. 

My initial though of WPF is one of joy.  The XAML  formatting on the UI layer is very reminiscent of HTML--which is the point.  If you are a Web Developer trying to do a desktop application you’ll feel very at home with XAML, or at least I did.  In some ways it’s more a throw-back to classic ASP.

WPF is not just for when you need to drag out the graphically impressive guns.  Don’t get me wrong, if you need lots of prettiness then you can leverage WPF in some really cool ways by simply doing triggers and events in XAML, but there is more to it that that.  It’s not just a way gate to a pretty face, but has some very data-centric intenseness that it can delve into.  Yes, it’s newer than WinForms as WinForms has been around since .NET 1.0, but WPF has been in R&D for over five years.  It’s got a lot of meat behind it especially in the data-binding arena. 

That being said, an application that lends itself to looking nice isn’t something to overlook.  People use our software and people like things that look nice.   Since I don’t use WinForms much I can’t really speak to the learning curve as my brain wasn’t “wired to” WinForms and I always roll my own UI layer so don’t care about the tools to build it.  But, there are some logic shifts and new things that you’ll need to understand in order to be in the proper WPF mind frame. 

This is a really great post about the WPF mind-set.

There are some very powerful applications you can make with WPF leveraging Routed Events and Dependency Properties.  A routed event can invoke handlers on multiple listeners in a set of elements rather than just on the object.  This has been referred to as "event tuneling".  It’s like a built in Observer Pattern.  A dependency property is hard to define and would require several blog posts, but basically it is a static value that isn’t set but is defined by rules based upon values of other properties (that’s why it’s dependent).  The Dependency Property could be based on an expression either directly or from various data-bound sets, property invalidation (aka…your cached object isn’t valid, get a new one). Also, it is a way that WPF uses styling.  It allows for generic behavior that wouldn’t be available any other way except with reflection, but doesn’t involve the performance hit that reflection would cause.  Another thing to note is that Silverlight is a sub-set of WPF, but in this example we are going to be purely XAML.  We’ll do Silverlight another day.

So, I’ve given you a bit of a teaser about some of the power of WPF and either intrigued or scared you with the definitions of Routed Events and Dependency Properties, but let’s do something simple just so we can see how easy it can be!  We’ll be using the Getting Dressed application that I talked about at the end of my Architecture post.

Create a new WPF Application

 

You’ll notice that Visual Studio has created a few files for you by default

 

On MainWindow.xaml grab out a textbox, a button and a textblock and put them on the window.

 

The xaml code for that is:

<Window x:Class="WpfExample.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="MainWindow" Height="350" Width="525">

    <Grid>

        <Button Content="Button" Height="23" HorizontalAlignment="Left" Margin="74,119,0,0" Name="button1" VerticalAlignment="Top" Width="75" />

        <TextBlock Height="74" HorizontalAlignment="Left" Margin="74,205,0,0" Name="textBlock1" Text="TextBlock" VerticalAlignment="Top" Width="237" />

        <TextBox Height="25" HorizontalAlignment="Left" Margin="74,46,0,0" Name="textBox1" VerticalAlignment="Top" Width="200" TextChanged="textBox1_TextChanged" />

    </Grid>

</Window>

So, try to play with it and add a label and we don’t need a function for text changing for textBox1.  Also, those names stink.  Let’s do something better.  I really hate generated code so let’s make it lined up correctly and give it better names.

<Window x:Class="WpfExample.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="MainWindow" Height="350" Width="525">

    <Grid>

        <Label Name="_lblInstructions" HorizontalAlignment="Left" Margin="50,10,0,0" Content="Input values in the textbox below and click Get Dressed for validation" Width="500" />

        <TextBox Height="25" HorizontalAlignment="Left" Margin="50,50,0,0" Name="_txtInput" VerticalAlignment="Top" Width="200" />

        <Button Content="Get Dressed!" Height="23" HorizontalAlignment="Left" Margin="50,120,0,0" Name="_btnGetDressed" VerticalAlignment="Top" Width="75" />

        <TextBlock Height="74" HorizontalAlignment="Left" Margin="50,200,0,0" Name="_txbOutput" VerticalAlignment="Top" Width="250" />

    </Grid>

</Window>

Next, let’s add an event for the button.  You can either double click on the button or add  Click="_btnGetDressed_Click"

 To the button.

Let’s go check out MainWindow.xaml.cs. 

//I removed all the default using

namespace WpfExample

{

    /// <summary>

    /// Interaction logic for MainWindow.xaml

    /// </summary>

    public partial class MainWindow : Window

    {

        public MainWindow()

        {

            InitializeComponent();

        }

        private void _btnGetDressed_Click(object sender, RoutedEventArgs e)

        {

        }

    }

}

Is what we have.  So, hopefully this looks pretty self explanatory.  You click on the button and the _btnGetDressed_Click fires.  Just like in web forms you can access the controls on the UI layer from from the function.  So, what I want to do is listen to what is in  _txtInput and display the result in _txbOutput.  So, how about you put something in the input box and then just display it in the output box.  I’m not going to show you how to.  You try it and use IntelSense to help you figure out how toread and display.

What I am going to do is give you the solution to the problem posed on my Architecture post.  It’s just a quick hacky example, but it’ll be a good base for building from in the future.  I hope you enjoy and stay tuned.  I still owe you an update on oData and some more examples of using different technologies to create this application.  Maybe we’ll try Windows Workflow next.

Is there a technology that anyone would like to see?

Solution zipped up



The Role of an Architect and the Start of a New Experiment

In this post I will talk about what I think an Architect is.  Also, as a result I will be starting a new experiment. 

My favorite thing about programming is that there is no correct answer.  There are wrong answers, but not a correct one.  Each solution has certain advantages and disadvantages.  It is up to us to determine which tools we should select for the job.  My core function at work is one of "Architect".  As such it is my responsibility to understand the tools at my disposal and decide how to implement them.  I think this is one of my favorite bits of my job (thus the blog). 

There are people lined up on both sides of the fence in regards to how technical and deep into the code an Architect should be. As I said (and say often) in programming there is no right answer, but there is a wrong answer.  An architect needs to architect so you can't be a Senior Developer who spends all your time programming.  In order to fully understand the repercussions of your decisions you must know how to implement it.  I don't agree with Architect roles that don't require at least a little bit of programming.  How can you really understand what is going on.  However, there is a fine line between too deep and not deep enough and that line is different for each project and each team.

The software architect should not write all the designs for each sub-system (depending on the resource doing the design), but the Architect should review all designs.  The act of developers participating in the design helps them to understand the rationale behind the architecture and thus can help avoid ignoring the big picture, but the developer doesn't own the big picture, that's the Architect's. If the architect does not own the bigger picture of the application then you've stumbled across the wrong answer.  Performance, availability, scalability, security, audit, extensibility and other concerns need a champion and that champion is the Architect.  An Architect needs to manage risks.  If you are too concerned with the nuts and bolts these trees could prevent you from seeing the grander forest. An Architect needs to enforce standards of design principles (through design reviews) and implementation standards (though code review). 

I think at the core, an Architect is a Leader and this is often a reason to not code.  It's been asked: "can one lead from behind?"  I don't think that being in the code is being behind.  I think it is being along side.  I think that the best leaders understand their team.  The best leaders are willing to do the most sucky tasks.  The best leaders inspire their teams and by example, challenge their team to succeed.  A leader is a coach and a mentor.  You have to know what your team-member is doing if you are to coach or mentor them.

I am very deep into the code.  I've been referred as the quarterback who has to throw passes to herself, which is far from optimal.  I spend about 40 hours a week programming, which would be *really* bad except I work 70 hours so that means that I also spend about 30 hours not coding.  So, if I was working a normal work week I'd be doing only 10 hours coding, which I think is about reasonable.  That’s enough to know what’s going on while leaving enough time to do the other “stuff” that needs to get done.

So, I guess my final response is…an Architect should be hands on, but shouldn’t be involved in all the minutia.  An Architect should be engaged and active in the development process.  They need to understand how the team implements their decisions.  But, regardless of how much an Architect codes for their job, I think that the most important function for an Architect is to continually learn and implement outside of work.  It's like always being in school, but you've got to create your own reading assignments and homework.

So, to this point I thought that a great way to really learn about a bunch of different technologies would be to have a base requirement set and show various implementations. The right tool might not even be a .NET one, but I'm am going to focus on being .NET centric...although if you are very nice I might branch out into Ruby or Haskell.

We are going to use a fairly common example, a state machine for getting dressed.  If it is hot your “types” of clothes are the same but the name is different.  For example, when it is hot you will wear sandals on your feet instead of boots.  When it is cold you need socks, but we are going to follow good clothing styling and will not wear socks with our sandals so socks are only okay for cold weather, as is a jacket.  Below are the commands, the description and the hot vs cold responses.

Command | Description | Hot Response | Cold Response 
--------------------------------------------------------------------

1  | Put on footwear | "sandals" | "boots" 
2  | Put on headwear | "sunglasses" | "hat" 
3  | Put on socks | fail  | "socks" 
4  | Put on shirt | "shirt"  | "shirt" 
5  | Put on jacket | fail  | "jacket" 
6  | Put on pants | "shorts" | "pants" 
7  | Leave house | "leaving house" | "leaving house" 
8  | Take off pajamas| "Removing PJs" | "Removing PJs"

Here is the state machine for prereqs for the various states.  Some things can occur in parallel (ie…you can put your socks on before or after your pants) and others have to have something complete before it can be done (ie, you can’t put on your shoes until your pants are on).

Every so often I will post another technology soloving this problem, which is simple enough to be trivial but still leaves us with some interesting options.  I hope you enjoy!

Stay tuned for more and let me know your opinions of how much an Architect should program and what his or her role should be.

Cloud Computing: Azure and it's Competition

As a child I would often get yelled at for having my head up in the clouds.  Little did anyone know, but one day I would be programming on Windows Azure, a Microsoft platform that runs my web app and stores its data in the cloud.  So, while my head isn’t in the cloud, my ideas are.

The “cloud” is getting a lot of talk recently.  It’s a fun word that everyone can latch on to, and many of us are already using cloud applications.  Google Docs, anyone?  The term "cloud" is a convient metaphor for what is going on.  The “stuff” you are using isn’t local it’s out there somewhere in the ether…or cloud.  What’s nice is that, like the electricity grid, resources are shared.  This makes the cloud very scalable.  So, if you need electricity you don’t have to make your own and have all the equipment, you just buy the power from the electricity company.  So, from a server side, if you don’t need to own the box that transmits the data and you just need the ability to transmit it then why would you want the overhead of that box?  You can avoid the capital expenditure for the hardware, server software, etc and just pay for the service.

There are lots of reason why I am using Azure for my new social networking venture with Pete Amundson.  First, we already mentioned the avoidance of some of the capital expenditure, which is big for us.  Also, since this new venture could expand quickly (fingers crossed) we want something super agile that can rapidly expand as load increases.  We’ll make it scalable, of course, but it’s much easier to make software scalable than it is hardware.  Furthermore, we don’t need to have the hardware to handle our peak load at all times.  Since the resources are shared we can grab and drop as need be in the same way that I don't have to pay for the electricity to power a light bulb that isn't on.  Until I flip the switch I am not chewing through my financial resources.  The cloud gives us that.

There are other features of the cloud that Sippity will not utilize but that other companies, like my day job, might utilize.  Now, my day job, which does Software as a Service, isn’t on Azure right now and there are no immediate talks to move over, but it’s a potential on the horizon.  We’ve got a system running on traditional servers and it’s working and our leasing agreement has a while until it’s up.  It’s something that I will seriously consider once it’s time to.  Reliability will improve for us as there will be multiple redundant sites.  Since we are software as a service already we don’t have to worry about installation on everyone’s machine, but think about Google Docs, which is documents in the cloud.  You don’t need to install anything.  It just works once you go to the website.

Microsoft is touting Azure as the “operating system of the cloud.”  Azure is a cloud platform that allows applications to run at Microsoft data centers and includes services built upon REST, HTTP and XML for development, management and hosting of web applications off-site.  It’s where we as service providers can create cloud applications.   Sounds like an operating system to me. 

Basically we are abstracting pieces of an old-school hosting platform.  And by old-school I mean current, but trust me, soon it will seem very old school.  You don’t need to worry about the physical pieces if you only care about the resources.  Basically take the concept of Software as a Service and apply it to hardware and to the operating system and you’ll get what Azure is trying to do.

Azure isn't the only way to host your cloud applications.  SliceHost was the first time I heard of a concept of being able to grab on demand.  Now, they aren't as flexible as true cloud hosting and are owned by RackSpace which also has Cloud Computing offerings.  Amazon was one of the first to hop on the cloud hosting bandwagon.  These are very cool in their own rights and might actually work better for some people over Azure in the same way that PHP might work better than .NET in certain instances, but probably not enterprise level ones. 

If you are a .NET shop and you use SharePoint, Microsoft CRM, Exchange, etc, then Azure's existence as a platform rather than just hardware as a service should pique your interest.  Azure resources are dynamically adjusted to your immediate needed levels. Azure is set up to pool systems into a network that can automatically mange resource, load balance and geo-replicate.  This is great because then the apps that run on Azure don’t have to worry about all that stuff.  It just works.  That makes me happy.  It's important to note that this is a big difference between Azure and Rackspace/Amazon.  They don't give you these pieces of functionality, which for my site is important.  That being said, Amazon has annouced that they will be adding these features to their system.  A fourth option, which is my favorite for smaller sites, I think, is the Google App Engine.  With GAE you aren't going to pay anything until your app grows to a decent size whereas it's $100 a month for Azure regardless of traffic.  GAE's payment is also much less "blocky".

The real thing is that Azure, GAE, Amazon and RackSpace Cloud aren't directly comparable so a direct price compare doesn't make sense.  You often get what you pay for, but in the case of Azure, that might mean you need it or it might mean overkill depending upon your application.  Amazon and RackSpace are much more "do it yourself", which frankly, I personally don't want to do.  If you want to talk cost, that time is expensive and I'd rather use it elsewhere.  Google Apps seems to work the easiest out of the gate which isn't always the best since it's not as customizable.  If your app is small it might make the most sense.  Azure has a nice middle ground of being feature rich while looking familar to me as a .NET developer.  Beyond that, if you want to use function programming, Azure's ability to use F# is amazing.  (Although you could use hascall on Amazon). For more information check out this great article comparing Google Apps, Amazon and Azure.

So enough about the cloud in general.  Let’s talk about Azure in particular. There are three main pieces of Azure: Windows Azure, Microsoft SQL Azure and AppFabric.

Windows Azure is the hosting platform and development tools which makes it often also mean SQL Azure and AppFabric, but that’s kind of like saying that Windows Server includes IIS and MSSQL.  Definetly not implying that AppFabric is like IIS, because it’s not.  But, SQL Azure is like MSSQL.

Microsoft SQL Azure extends Microsoft SQL Server to the cloud as web-based services, which is a big benefit of Azure over some of the other cloud offerings.  It’s also hosted by Microsoft thus, just like Google Docs, you don’t have to install anything to work with it.  Fault-tolerance and high availability just comes with it without patches, installations, etc.  Azure SQL Services can do relational databases, reporting, analytics, and data synchronization for multiple users/offices/etc.

Windows Azure platform AppFabric is the stuff formally known as .NET Services.  AppFabric in general is meant to offer connectivity as a service to build bridges of connectivity between disparate systems.  The two most important parts of AppFabric are the Service Bus and Access Control.  Both are RESTful web-based developer services which enable interoperability between Azure and other Windows Server Assets.  You can also get AppFabric SDKs for PHP, Java and Ruby.  AppFabric Access Control creates a way for you to deal with the rules for connecting.  AppFabric Service Bus provides flexibility for communication regardless of communication pattern.  Streaming, Direct-Connect, Buffered, Publish-Subscribe.  Whatever.   So, AppFabric Access Control controls the access and AppFabric Service Bus allows for the movement.

So I was going to go through what to do in order to set up an application for the Cloud, but this is already pretty big.  So, I guess this is just an overview.  But, now you should have a better understanding for what the cloud is and how Azure fits into that.  For a great example of code using Azure go checkout the Azure Issue Tracker.  And stay tuned for more info here at LaurenAmundson.com :)



OData: Part 1 of 5 - Introduction

I'm really glad that I started this blog when I did.  VS 2010 is out.  .NET 4.0 is out of beta.  There's just lots of super cool new toys to play with and explore.  One of those is OData.  Our world runs on data.  We are like Number Five from Short Circuit.  Need more Input!  OData, which is the Open Data Protocol is here to help us consume and expose our data in a standard way.  

Honestly, I am inspired to drill into this topic because I'm excited for the OData Live WebCast by Douglas Purdy tomorrow afternoon.  It's going to be awesome.


So, a disclaimer.  Anything involving data access isn't going to be able to be discussed very succinctly so if this piques your interest I would recommend drilling in further or grabbing a book or stay tuned for the other parts of this series.

Basically the goal of OData is to kick all of the data silos around the data-world to the curb and replace the myraid of different data-handleing "standards" with a real single standard to query and update data.  Tall order, and not what you as an architect/designer/developer might want, or is could be the next best thing for data access since <insert something witty />.  

OData is not Microsoft's.  It used to be, but now it is its own thing released under the OSP (Open Specification Promise).  Microsoft, after hearing that we devs and architects wanted to increase utilization of standard-based-approaches has created OData and is working to create an independent community around it.  The whole developing something and then calling it a standard does sound so Microsoft.  But, there is a need for a standard way to deal with data and someone has got to do it.  For what it's worth, so far it looks like they are doing it very well.  This isn't Microsoft's first forrey into open source as AJAX.NET is open source and seems to be going very well...I use it and have gotten wonderful results.

Microsoft's OData functionality is the protocol formally known as Astoria which encapsulates ADO.NET and is the next step of ADO.NET. It combines the best of HTTP, REST, AtomPub and JSON.  I'm going to assume you all know what the HTTP protocol is.  REST's stateless communication leverages these HTTP verbs in web services often unlocking AJAX functionality.  AtomPub is an application-level protocol that uses HTTP to publish and edit web "stuff".  JSON is a string representation of a JavaScript object and is also extremely helpful in AJAX.  Each was only a sentence so that's a bit simple to the point of almost being wrong, but at least we have a starting point to know what OData is built upon/using.  OData is RESTful extensions to AtomPub which uses JSON and ATOM to expose the data which can be both read and edited using HTTP.

The reason why OData is so awesome is because it gives us a standard thus simplifying how we deal with disparate data sources.  Sure there is XML which gives us a standard way to see and display data, but there's no standard for really dealing with the data.  We can navigate the data and query it.  OData gives us modeling enabling CRUD operations, something that XML is too lightweight to do.  It also gives us semantics and common behaviors.  XML has no inherent behaviors.  It just is.  So building upon existing ways we deal with HTTP, REST, AtomPub and JSON and creating semantics and behaviors which thus locks in consistency gives us huge power and possibilities.

Regardless of whether the greater development community embraces OData, there is still a need to leverage it to communicate across disparate Microsoft systems both by Microsoft and those written using .NET.  SharePoint 2010, Azure, Reporting Services, and even Excel 2010 through PowerPivot all have the ability to leverage OData and simplify your life when trying to deal with them. 

If your application doesn't talk to anything except it's own database then this might be overkill for you and I'd probably go Entity Framework and LINQ because you've got to extract the data to a Logic Layer anyways and to use OData you'd encapsulate that data in the OData layer, exposing it to your application.  Which isn't a bad thing persey.  If your UI layer might expand to a phone, OData can be a great way to get your data from you Business Logic Layer to your UI layer.  OData has annouced an OData SDK for Objective C thus making any .NET-centric company that wants to develop an iPhone app's life much simpler.  Also if you need to get data in and out of Excel or want to directly expose it, baring security concerns, then OData might be helpful.  You can expose the data in one spot and grab it up through many other places.  

You'll notice this is part one of five.  In the other four posts I am going to focus on these four products (SharePoint 2010, Azure, Reporting Services, and Excel 2010 through PowerPivot) and how OData has enabled better communication with them.  We'll go from this cheerleading session of why OData is neat and really see the powerful new ways we can now access data.  I intend to publish this series weekly and will publish other topics in addition.

Side note, Netflix has exposed its catalog via OData.  Check it out to get a better feel for what exactly is going on