DeepCodeBlog

Expand a virtual PC VHD file and extend the partition

2008-11-18T21:41:55Z

Ran into a few problems today, for one client who uses a VPN that doesn't work at all well with Vista, I have an XP development virtual PC. I needed to install visual studio sp1 (yet again) on it but my boot drive only had 4Gb of free space - the temporary installer needs more than that.

After finding the excellent VHD Resizer I was able to resize by virtual disk by an additional 10Gb, however it doesn't extend the disk into this space and diskpart won't let you issue and extend command on the boot disk.

The solution? Boot off another VHD with the resized disk as a second drive, then extend under this environment before shutting down and setting it back to the newly extended drive.

Full answer here...

http://www.enusbaum.com/blog/2008/02/07/expand-a-virtual-pc-vhd-file-and-extend-the-partition/

Using attached properties to compose new behaviour

2008-11-16T21:31:00Z

I was inspired by a posting on stackoverflow.com - "How do I drag an image around a canvas in WPF" - where the first response in most peoples heads is to work with mouse up/down/move events, track offset positions and move the UI element around in response - pretty reasonable right?

Seeing as WPF's principles favours composition over inheritance and such like, what if instead we used the power of attached properties to attach new behaviour to a UIElement? Here's how to do it, first the code for the dependency property:

public class DraggableExtender : DependencyObject
{
    // This is the dependency property we're exposing - we'll 
    // access this as DraggableExtender.CanDrag="true"/"false"
    public static readonly DependencyProperty CanDragProperty =
        DependencyProperty.RegisterAttached("CanDrag",
        typeof(bool),
        typeof(DraggableExtender),
        new UIPropertyMetadata(false, OnChangeCanDragProperty));

    // The expected static setter
    public static void SetCanDrag(UIElement element, bool o)
    {
        element.SetValue(CanDragProperty, o);
    }

    // the expected static getter
    public static bool GetCanDrag(UIElement element)
    {
        return (bool) element.GetValue(CanDragProperty);
    }

    // This is triggered when the CanDrag property is set. We'll
    // simply check the element is a UI element and that it is
    // within a canvas. If it is, we'll hook into the mouse events
    private static void OnChangeCanDragProperty(DependencyObject d, 
        DependencyPropertyChangedEventArgs e)
    {
        UIElement element = d as UIElement;
        if (element == null) return;

        if (e.NewValue != e.OldValue)
        {
            if ((bool)e.NewValue)
            {
                element.PreviewMouseDown += element_PreviewMouseDown;
                element.PreviewMouseUp += element_PreviewMouseUp;
                element.PreviewMouseMove += element_PreviewMouseMove;
            }
            else
            {
                element.PreviewMouseDown -= element_PreviewMouseDown;
                element.PreviewMouseUp -= element_PreviewMouseUp;
                element.PreviewMouseMove -= element_PreviewMouseMove;
            }
        }
    }

    // Determine if we're presently dragging
    private static bool _isDragging = false;
    // The offset from the top, left of the item being dragged 
    // versus the original mouse down
    private static Point _offset;

    // This is triggered when the mouse button is pressed 
    // on the element being hooked
    static void element_PreviewMouseDown(object sender, MouseButtonEventArgs e)
    {
        // Ensure it's a framework element as we'll need to 
        // get access to the visual tree
        FrameworkElement element = sender as FrameworkElement;
        if (element == null) return;

        // start dragging and get the offset of the mouse 
        // relative to the element
        _isDragging = true;
        _offset = e.GetPosition(element);
    }

    // This is triggered when the mouse is moved over the element
    private static void element_PreviewMouseMove(object sender, 
        MouseEventArgs e)
    {
        // If we're not dragging, don't bother
        if (!_isDragging) return;

        FrameworkElement element = sender as FrameworkElement;
        if (element == null) return;

        Canvas canvas = element.Parent as Canvas;
        if( canvas == null ) return;
        
        // Get the position of the mouse relative to the canvas
        Point mousePoint = e.GetPosition(canvas);

        // Offset the mouse position by the original offset position
        mousePoint.Offset(-_offset.X, -_offset.Y);

        // Move the element on the canvas
        element.SetValue(Canvas.LeftProperty, mousePoint.X);
        element.SetValue(Canvas.TopProperty, mousePoint.Y);
    }

    // this is triggered when the mouse is released
    private static void element_PreviewMouseUp(object sender, 
        MouseButtonEventArgs e)
    {
        _isDragging = false;
    }
}

As you can see, we hook into the events exposed from the target element whenever we detect the property being changed. This allows us to inject any logic we like!

To use the behaviour, we include the namespace in XAML:

<Window x:Class="WPFFunWithDragging.Window1"
        xmlns:local="clr-namespace:WPFFunWithDragging"

And then just attach the behaviour to the elements we want to be able to drag like so;

<Canvas>
       <Image Source="Garden.jpg" 
              Width="50" 
              Canvas.Left="10" Canvas.Top="10" 
              local:DraggableExtender.CanDrag="true"/>
   </Canvas>

Cool huh? Sample code attached....

The Enterprise Stack

2008-11-16T18:57:18Z

What makes good software? Separation of concerns has got to be up there in a big way, ensuring you have relevant tiers to your application that deal with a particular set of concerns, but what does an enterprise software stack look like? I've been asked this question a number of times, so thought I would put up one of the ways in which I write software for SOA environments.

To avoid being short down in flames, let me be clear, I'm not advocating any particular dogmatic approach here, just presenting one way that's worked for me in several situations in service oriented environments.

So, here's the simplified picture of the stack:

Database
At the very top of the stack we have the database or persistence engine - the place where our application is going to store it's data. This doesn't have to be a SQL database, but is more a concept of a place to store information. To this end this box could be satisfied by XML, an object database, text files, other external services and so on - indeed there may even be multiple boxes.

The Data Abstraction Layer
This layer is responsible for hooking repositories up to persistence. It should expose an engine flexible enough to work with a variety of types of physical repositories in a natural manner. Generally you won't write your own data abstraction layer, but will instead re-use one of many different technologies already available such as NHibernate, LINQ to Entities, LINQ to SQL and so on.

Repositories
The repositories are responsible for fulfilling requests to obtain and modify data. This allows a further level of abstraction that describes the purpose of the code rather than the implementation. IE: A service will ask a repository to "SelectAllCustomers" rather than directly execute some LINQ query.

Repositories deal in one thing and one thing only - Domain entities. Their inputs and outputs are usually one or more entity objects from the domain (see below). For example, suppose you were writing a pet shop application, you may have a repository for dealing with customers as follows;

As you can see we have methods for retrieving customers and for updating them. This makes working with customers extremely clear and self describing. The first method - SelectAll() will simply return all of the customers in the system (as customer Domain objects). SelectQuery will allow the description of how to get data, sort it and present it.... eg, using the CustomerQuery, one might be able to specify the sort order and direction, filters on fields, along with which rows to return for pagination.

Each type of conceptual data would have it's own repository in the stack.

(One alternative to using repositories is the active record pattern where entities expose methods and functions similar to those exposed from repositories)

Domain Entities
The domain model (in this instance) is a representation of the various entities that make up the problem you are describing along with their relationships and any operational logic (business rules).

The following is an example of a simple domain model, working again with the fictitious pet shop example.

In the diagram above we can see we have a customer entity, which has attributes describing the customer. It also contains a collection of Order entities representing the orders that this customer has made. Each order must have a customer, but a customer can have 0 or more orders.

Where an order exists, this will have attributes of it's own to describe the order, along with a collection of order lines (0 or more). Each order must have one and only one customer.

Moving down the graph, the order line will know which order it belongs to and also reference a product that the line of the order corresponds to. Each order line can only be within one order and it must also reference a product.

As you can see, the domain model is just the object graph of the entities it represents. There may of course be more meat on the bones of your real life domain model, including operations on entities to implement business rules and such like.

So, how does the repository return all of this information - where we simply invoke SelectById(10) to get the customer entity with an ID of 10? Well, the answer is actually in the DAL and repository layer.

NHibernate and other OR/M technologies allow for something called Lazy loading - where the initial query loads the Customer object, but then wraps it's properties (called proxies) so that when they are invoked, it actually automatically goes back to the database to get the entities required.

A second alternative is to describe how deep you want the graph to load in the repository implementation (or even make this a factor of the query parameter to allow control further down the stack). Again, most OR/M's allow you to specify what you want to load from the graph - such as specifying to load the orders and order lines for a customer at the same time as it gets the customer. This usually offers some performance gains too as only one query is executed. (And in fact is your only option if you are using LINQ to entities as of V1, which doesn't support lazy loading).

Regardless, your DAL or your repositories should be able to hydrate an object graph based on a request from further down the stack, and should also ensure that when you do get an object from the database, it only get's one instance of it!! (IBATIS for example doesn't do this by default and you must implement your own Identity Mapper pattern that is used by repositories).

Service implementations
These are the actual end-points of your service - the ASMX you call, or in the case of WCF (my preference), the endpoints you've defined and implemented through service contracts.

The service is responsible for taking an in-bound request object, working out what to do next, then invoke the appropriate repository methods to get or affect data before then assembling a response back to the caller.

In other words, the service is invoked using a data contract in the form of a data transfer object (see below), it then, if necessary hydrates a domain object graph ready for use by repositories before invoking them and getting back domain objects. When it does, it uses assemblers (see below) to convert the full data representation from the domain into a structure of data that the client application is actually interested in (DTOs).

Data Transfer Objects - DTOs
The purpose of DTOs is to represent the data needed to complete an activity in it's most minimal form for transmission over the wire. For example, where a client application is interested in customers, but is only interested in the customer's name and ID, but not the other 20 fields, your DTO would only represent customers as name and ID. They are lightweight representations.

Communication between client applications and the service tier is done only through the use of DTO objects.

Interestingly DTO type objects may be present in your domain (but not called DTOs). You may have several different representations of customer for instance in order to optimise how much information flows across the network between the domain model and the database. The trade off is how simple you want to keep your domain versus how much control you want over database performance.

Assemblers
The assemblers are used by the service implementations to map between the conventions of DTO and Domain. For example, if you have a DTO contract for updating a customer, an assembler would take this DTO and map it to a valid customer domain object. This would then be passed to the repositories for serialisation.

Service Proxies
Hopefully this requires very little explanation, the service proxy is a client side implementation of the service implementation that maps to the communications channel and invokes the actual code on the service tier. Your client application works exclusively with the service proxies and the DTO's that it expects and returns.

Conclusion
This is just one way to build scalable N-tiered enterprise applications. Several of the concepts presented here are interchangeable with other methods - such as active record instead of domain + repository. Speaking from personal experience I have seen the above work very well on large scale implementations.

It is also worth mentioning some supporting concepts. To truly realise benefit from the above implementation, one would need to use interface driven development to allow any piece of the stack to be mocked and unit tested effectively. In addition, dependency injection can make your life easier as the scale of the system grows, automatically resolving dependencies between various objects between the tiers.

In the future I will post a simple example application with source code that uses all of the above techniques to demonstrate the implementation specifics. I hope this was worth writing and someone finds it useful.

Microsoft Tech-Ed is over, I'm going back to work for a REST

2008-11-14T21:36:04Z

It's a shame that it's over for another year, and its been a fantastic, if somewhat tiring, week that I've thoroughly enjoyed. They cram in as much information as they can in the 5 days of the conference and provide you with everything you need to stay comfortable during the duration.

On the social front, things were also good, the country drinks event was great on Wednesday night, and Barcelona overall was a cool place to hang out and chat about the day.

The inhabitants of Barcelona must think there's a geek invasion or something though as every third table in the restaurants was debating Azure, L2E, federation in the cloud or whatever - but if that didn't convince them, then watching the games at the country drinks evening would have.

One of the games during the night out was a form of bowling using a tennis ball. After the person had bowled, the ball was thrown back to the bowler. You could tell we were at a geek conference though as not one person managed to catch the ball!!!

If anyone is thinking about Tech-Ed 2009 (in Berlin next year), I wouldn't hesitate to recommend it.

Day 5 - 15:15 : The TechEd Daily Scrum

2008-11-14T21:22:08Z

Presented by Stephen Forte again (second time inside of a single day!), this final session at Tech-Ed was a review of what SCRUM is, how it's working for people and then it turned over to mass debate.

Again, we find religious arguments coming to a head in this scenario between the agile purists and the more pragmatic fixed price bid guys.

Personally, I'm somewhere in between, where, given the opportunity to do a time + materials project using SCRUM, I would prefer to, but often we must be realistic and offer fixed price contracts to clients, even though doing so is difficult because up front design is always wrong and this is why SCRUM rejects this outright.

(Saying this though, even in fixed price bid contracts, one can still apply and benefit from the principles of SCRUM (backlogs, sprints, daily scrums, business owner involvement etc). Doing so will just expose problems earlier, which is a positive thing.)

Big design up front wise - the minute a specification is published it starts to go out of date and becomes incorrect. Never have I (nor had anyone else in the room) seen a specification written before a project and been able to go back and compare the delivery with the original specification to find an exact match.

<Ranting>

These differences, errors and omissions add time to the project, but in relation to total project time, not just in relation to the slippage felt by the initial mistake. For example, If I have a 4 month project and during month 1, I find slippage of 1 week, does my project length get extended by 1 week only?

No - it gets extended as a factor of the time so far consumed and remaining.

My project was 4 months, and in the first month I found an omission that has cost me 25% of the time I've spent so far, so it's a reasonable assumption that I'll find a similar quantity of omissions in the remaining development, so my overall increase isn't 1 week, it's 1 month - this is a fact that causes many development projects to be seen as failures that have gone drastically over time and over budget.

This principle, which has been proven many times was written by Fred Brookes in an essay back in 1975 and it is as valid today as it was back then. I recommend reading the book: mythical man month for more information on this and many other principles - including the famous Brookes Law - adding more manpower to a late project makes it later.

</Ranting>

Anyway, back to the session - it was highly enjoyable and despite the presence of significant dogma - I think everyone was able to learn something new from each other and from the presenter.

Day 5 - 13:30 : An introduction to Oslo (mostly M)

2008-11-14T20:52:17Z

This session, run by Jon Flanders focused on the new M modelling language - specifically MSchema and MGrammar. To be honest the entire session concentrated on using MSchema to generate T-SQL to create a database which I didn't feel was a great example and certainly wasn't real world.

We already have a perfectly good textual DSL for building databases - it's called T-SQL, and just like the DSL, it can be split across multiple files, can generate data, and can be stored in source control for versioning.

I really like Jon Flanders, he's a great guy, and he did a much better job of presenting M that I ever could, but I honestly didn't enjoy this session one bit.

Day 5 - 10:45 : Data access smackdown! Making sense of Microsoft's new data access strategy (DAT02-IS)

2008-11-14T20:41:02Z

Stephen Forte, Chief Strategy Officer from Telerik, started this interactive session reviewing the history of Microsoft's data access offerings and then discussing the latest multitude of choices. As this was an interactive session, there were lots of questions, comments and debates going on throughout.

A quick history - Microsoft gave us ODBC, then DAO with JET was sat on top of this, RDO wrapped DAO and ODBC, and then there was ODBCDirect. I can remember working with all of these technologies, so I must be getting on a bit now! (not really, I'm 35, technology just changes quickly). Anyway, from this they gave us ADO and with the release of .NET, we got ADO.NET.

Today we have a bunch of options available and moving forward into the future, we're going to have even more choice. Sat atop of ADO.NET we have the conceptual model LINQ technologies (LINQ to SQL, XML, Entities, REST) along with cloud services (Azure) and SSDS (now SDS). That's without even thinking about 3rd party solutions like NHibernate, SubSonic etc - although these were also discussed.

The debate was on-going concerning which technology should be used in which context, and as ever - there is "No Silver Bullet" - the stock answer to such a question is, and should be, it depends.

Choosing which data access strategy you use should be one that gives the highest return for least complexity - not just the one that seems the most technically pure as this is purely subjective - eg: "objects first" people are going to look for OR/M, "data first" guys are looking for T-SQL and so on....

If this means you want OR/M and are using TDD or you need facilities like lazy loading (and you don't always!), then avoid the entity framework - which doesn't cope well with either. In that scenario, perhaps you'd stick to NHibernate. On the other hand if you want highly optimised database queries and you want full control over them for whatever reason, use plain old ADO.NET. Maybe if you're writing a system that doesn't need lazy loading or you're not using TDD, then perhaps the entity framework is a great way to very quickly get started using entities with very little code.

I get frustrated by dogma and elitists saying there's only one way to do things - the way they do it! We all have our preferred way of working, and I'm the first to promote various strategies and techniques as being good options, and sure, I'm occasionally guilty of being dogmatic, but dogma hurts objectivity - we should always consider the project in question and what is best for it rather than fly flags and banners.

Stephen was questioned about, and acknowledged the vote of no-confidence and it's validity - and he made a very, very good point - this is V1 of the framework. The guys involved in EF are aware of it's limitations and are working to resolve them, but are heading in the right direction at least. Personally, I feel I came out of this session a little less dogmatic and a little more objective.

Day 5 - 09:00 : Identity and cloud services (ARC302)

2008-11-14T08:51:26Z

Vittorio Bertocci presented this session on how to work with identity across services and environments using the cloud.

Traditionally in enterprise we have a set of users and a set of resources that they can access. Each time the user accesses a resource, the user is validated against this source and granted or denied access etc. This scenario starts to become more complex when you wish to allow other environments to access your resources or for your users to access resources in other environments.

The solution is to outsource aspects of identity management to the cloud, allowing relationships and credentials to be managed across technologies, services and environments. Where two systems, organisations or environments have no trust between them, we can use a claims transformer or resource security token system (R-STS) in the cloud that is trusted by both.

This provides a natural point of trust brokering with customers and partners along with a natural point of authorisation evaluation and enforcement.

Azure provides this type of service through the .NET services access control service. In this service, every solution gets a dedicated R-STS instance. The application has it's own policy which remains the same, whilst rules are created for how to transform between your various customers or partners tokens (or windows live credentials etc) to your own through the R-STS.

Day 4 - 17:30 : Building and consuming REST based data services for the web. (WUX313)

2008-11-13T21:35:03Z

In this session, Mike Flasko demonstrated the new ADO.NET data services framework that enables developers to create services that expose data over a REST interface using industry standard formats and semantics such as JSON and AtomPub.

The reason I attended this session was to find out what this was all about because on the face of it, the idea of a data services framework worries me for a variety of reasons, including;

Why would I ever expose my entire data model over a REST interface?
Surely doing so breaks separation of concerns? My clients should be invoking a service or REST interface that returns targeted and focused results based on a strict request/response model.
Isn't the data services framework tied to LINQ to Entities?
Opening up an interface direct to my data sounds extremely dangerous and opens it to all manner of abuses!
What if I have business logic executed when I manipulate data within my service - using data services this can't be expressed!

Taking each in turn;

Why would I ever expose my entire data model over REST?
Quite simply, data is what drives much of web 2.0 - it drives mash-ups and makes data driven AJAX, flash and Silverlight applications possible.

Normally we may expose this data through a bunch of services (possibly REST) with tightly defined semantics such as GetCustomers, GetCustomer(1) and so on. The data services team suggest however that as the application complexity and size increases, managing these interfaces can become cumbersome and tedious and may be serviced better by interfacing directly to the data via a specific data service.

These data services are exposed as REST, allowing access to your data model by navigable URL. For example, lets say you have a data model of People with Contact telephone numbers, you could access this data with the following HTTP conventions;

To get a list of people you would execute a standard GET verb request against the resource URL which might be something like: http://yourdomain.com/yourservice.svc/data/people

To filter people, you would pass over parameters to the URL, perhaps like this: http://yourdomain.com/yourservice.svc/data/people?$filter=A$field=Name

Whilst to get a specific person with an ID of 12, you might look at http://yourdomain.com/yourservice.svc/data/people(12)

From here you can get a list of that persons contact details: http://yourdomain.com/yourservice.svc/data/people(12)/contacts

To make changes to the data, you simply change the HTTP verb. Eg: to update a record, you would POST it, to insert, you would PUT and to remove you would DELETE (standard rest interface), and the results would be returned back in the format requested in the header (ie: you can set the accept type header value to specify that you want atom or JSON etc) - the outcome of any given action would also have a status response, which again map to the standard HTTP status codes - (eg: people(12) where no person exists with ID 12 would generate a 404 not found status error).

When data is returned it also has relative navigable references to other parts of the data model. Again this is a common REST feature which describes not only the data that is being returned, but also how to navigate it by invoking the service with more specific information.

On the client side, you are able to query against your data service using a LINQ query, offering a powerful and intelligent way to request the data you want from the web service, but this is also one of my concerns.

Isn't this breaking the principle of separation of concerns?
I believe it is because your calling code is tightly coupled to the semantics of your entity model, rather than being coupled only to the DTO that it is expecting to be returned. This might be a problem in some situations, but in others it may be perfectly fine, so there isn't a hard and fast rule here.

Isn't the data services framework tied to LINQ to Entities?
My next concern was the reliance of the data services framework on LINQ to entities, of which I'm not a big fan. I'm led to believe however that this isn't true. Apparently, your data service is able to expose any object model in any way you see fit, but in a limited 75 minute session, this wasn't covered in any detail. I'm assuming though that this will at least require that the context of your data (eg, an NHibernate session) implement the IQueryable interface to allow LINQ queries to run against it. Again, I'll reserve judgement on this until I've seen an implementation of a data service that isn't exposing a LINQ to entities model.

Opening up an interface direct to my data sounds extremely dangerous and opens it to all manner of abuses!
In terms of security however, my concerns were unfounded. One of the things I really liked about data services was the ability to lock down your data with any rule you can code. You use standard authentication and authorization mechanisms (this is just HTTP after all) to govern, with fine granularity, access permissions at entity level, row level and field level - this will please SPROC aficionado's who often argue they don't use OR/M technologies because they lose row level security on their data.

Business rules
Finally, the business rules and logic issue is still perfectly valid. If you need to carry out rules processing during invokation of operations on your model, then a conventional approach would be more suitable as you don't get this opportunity under data services. When a request arrives to manipulate data - it is surfaced straight into the data services framework and executes against your data.

Overall I thought the technology was interesting and could see uses for it in numerous areas. In enterprise applications with distinct layers and business rules however I'm not sure it's that applicable, and I'd also like to see it surface a non-L2E model.

Day 4 - 15:45 : An overview of the Azure services platform (ARC201)

2008-11-13T20:20:09Z

David Chappell is perhaps one of my favourite speakers from the conference. He tackled an objective look at Microsoft's new Azure platform in this session and gave what I thought was the clearest overview of the vision.

Azure is Microsoft's new distributed platform that they define as "Windows in the cloud" and "Infrastructure in the cloud". It's like having a huge data centre available on-tap, without having to invest heavily in capital expenditure, you simply rent the size of cloud you want, and scale up/down as needed.

It offers not only the ability to deploy your applications to a scalable platform but also provides the ability to consume standard Azure service offerings including (amongst several others);

.NET Services
SQL Data services
Live services

The fabric of Azure essentially provides a layer on top of thousands of virtual machines, all running windows server 2008, 64bit. Each virtual machine has a 1:1 relationship with a physical processor core. The fabric layer provides an abstraction on top of this virtualised hardware, so we can't access the virtual machines directly (eg: RDP to them), but we can build .NET applications in certain roles and deploy out to them.

This is an extremely beneficial deployment model for whomever is building the next facebook, myspace or amazon out there - being able to build for the cloud and deploy incrementally to a scalable off-premises infrastructure allows new killer applications to fail fast or scale fast without huge capital outlay.

This of course is not actually new - Amazon's elastic compute cloud, storage solutions, google's app engine, gears etc all offer the same sorts of cloud infrastructure and utility computing. In fact, for existing apps that can't be ported to use Azure functionality like storage, Amazon's EC2 platform provides a good alternative as this allows you to supply virtual machine images into the infrastructure, whereas Azure abstracts this away.

The roles initially available are the web role and worker role. These correlate directly to an IIS hosted web application and standard .NET executable applications respectively, but deployed and hosted through the Azure fabric and the core services that this provides.

These core services include the storage service which allows us to store;

Blobs

Storing a simple hierarchy of any binary representation of data directly into the Azure storage services.

Tables

Storing structured data into hierarchical tables (not RDBMS tables).

Queues

Storing data into queues that allow communication between web and worker role instances.

Data in storage is exposed to applications via a RESTful interface with a query language based on the LINQ C# syntax. Data can be accessed by Applications or from other on-premises or cloud based applications.

In addition to the core Azure components of the web / worker roles and storage, it also offers a suite of pre-built ancillary services that can be consumed as mentioned above - presumably we'll pay extra for these, but the only comment Microsoft would make on pricing during the conference was that they will be competitive.

Azure .NET services
This provides;

Access control services
Service bus
Workflow

Access control services
Different organisations identify users with tokens that contain different claims. Each organisation might have different semantics and applications, especially across organisations, can be presented with a confusing mess.

Azure's solution to this problem is to have an access control service that implements a security token service (STS) in the cloud. It accepts an incoming token (of various types if necessary) and issues out another one that may or may not differ from the incoming one. This allows for scenarios of single sign on across enterprises and organisations etc, from multiple sign on sources.

Service Bus
Exposing internal applications out onto the internet isn't easy. Network address translation and firewalls get in the way of efficiently and securely exposing your on-premises application to other users.

In Azure, the service bus provides a cloud-based intermediary between clients and internal applications. Organisation X may expose application A by connecting it to the service bus - it initiates the connection, over standard ports, and keeps the connection open, thereby ensuring NAT doesn't interfere. Meanwhile, Organisation Y opens their connection to the service bus and connects to these intermediary end-points that map back to the actual organisation's end points.

Of course all of this is controlled and secured with integration to the access control service.

Workflow
Where should workflow logic that co-ordinates cross organisation composite applications be run?

Azure helps to make this clear by having the workflow service run WF based workflows in the cloud. There are some limits on what activities can be used (eg: no code activities), but having the workflow run in the cloud overcomes the problem it is meant to address.

SQL Data Services
Formerly known as SSDS - this is now just SDS - is built on SQL server and provides a mechanism for working with a fixed hierarchy of data tied to a data sync service based on the sync framework. Whilst this sounds much like the storage service, the ultimate aim of SDS is to provide more database relevant facilities like reporting, analysis, ETL and more.

It's important to distinguish that SDS is built on SQL server, but it is not SQL Server. It's a hierarchy storage solution. Each data centre has authorities and each of these has data containers, which in turn consist of entities and entities have properties. Each property has a name, a type and a value.

This may seem a little limiting, but one key advantage is never having to worry about managing SQL servers or SDS itself. You just see data, not the database - all scalability and management etc is taken care of, on behalf of your application by the Azure platform.

SDS data is accessed via SOAP and REST (including ADO.NET Data services) and, just like with the storage service, it provides a query language based on the LINQ syntax with queries returning entities. Unlike storage services however, SDS supports database type functionality with order by and join operations.

Live services
Live services and the live framework offers something called a live operating environment (LOE) that allows for;

Accessing live services data, and personal data

Contacts
Hotmail
Calendar
Search
Maps

Creating a mesh of devices

My vista desktop
My MAC OSX desktop
My windows mobile device
All running the live operating environment, with data synchronised across all devices and into the cloud.

Creating mesh enabled web applications that can run through your browser, on your desktop or on any device within your live mesh.

Applications that are built to run within the mesh, on all of the LOE devices - create and consume both cloud and local data by using the live framework to access live services data via it's exposed REST interface (data is presented in the AtomPub format).

Applications are rich internet applications (RIAs) built using silverlight, javascript, flash etc and run from the desktop or from the cloud on the devices within the mesh. A user can add devices into their mesh and can then select to install mesh applications (from a catalog) to the LOE in the cloud that are then also presented via the LOE on the mesh devices.

Conclusion
Microsoft are investing heavily in Azure and there's no doubt that cloud computing and more specifically utility computing will be a significant factor in the future and the Azure platform overall offers some exciting opportunities to exploit and monetise ideas with much lower commitment and risk.

Day 4 - 13:30 : Building WCF services with WF in .NET 4.0 (SOA302)

2008-11-13T13:05:47Z

Jon Flanders from plural sight took this session looking at how you can expose WCF services from windows workflow on the .NET 4.0 stack, continuing from yesterdays first looks session.

A cool feature being introduced is the ability to generate xaml only workflows in the form of .XAMLX files. These, when hosted in IIS or another host, allow an entire WCF endpoint along with all of the WF logic to be defined in a single xaml file. This file can be hand cranked or you can utilise the new WPF enabled WF designer surface.

Guidance suggests benefits can be achieved using WF to define WCF services if the service;

Calls a database, calls another service, or uses the file system.
Coordinates parallel work
Enforces ordering between messages
Coordinates messages with application state
Is long running
Requires rich tracking information

Day 3 - 17:30 : Develop with the visual studio 2008 extensions for sharepoint

2008-11-12T17:27:00Z

I went to this presentation to learn about the new visual studio extensions for sharepoint, unfortunately the presentation was an exact repeat of a PDC video I had already watched.

The sharepoint extensions for visual studio 2008 make building sharepoint applications much easier than before and allow simple packaging of sharepoint solutions for deployment.

For more information, (and in fact to watch the exact same presentation as I've just seen again) see the following PDC video: http://channel9.msdn.com/pdc2008/BB13/

Day 3 - 13:30 : An in-depth look at the ADO.NET Entity framework (DAT307)

2008-11-12T13:37:53Z

This presentation, with Elisa Flasko, was covering an introduction to the entity framework and how it fits with common application patterns - client server, web applications and distributed N-Tier apps etc.

The ADO.NET Entity framework is the next layer up in the ADO.NET technology stack that allows us to describe data using a conceptual model mapped to the database using a declarative mapping and queries using LINQ to entities.

The demonstration started with replacing the data access layer of a client server application by importing an existing database structure. This pulled in the table structures and stored procedures of an existing database to an entity model, automatically resolving 1:n, 1:1 and n:n relationships to properties and collections etc.

The result of this was a graphical view of the entity model. This is where my first concern is with the entity framework. Visual tools simply do not scale in large scale applications - imagine having hundreds or thousands of entities - a graphical tool simply doesn't cut it. Once the number of entities increases to any significant number the visual model becomes cumbersome.

That aside, the demonstration then moved to consuming data. Rather than programming against the physical data model, you write code against the conceptual entity model. If you're at all familiar with OR/M solutions such as NHibernate or SubSonic, none of these concepts will be alien to you.

One nice facility was the seamless integration between EF and LINQ, allowing elegant, strongly typed and intellisense enabled queries to be defined. (This isn't unique to EF however, there is LINQ for NHibernate for example)

As you would hope, when queries execute, EF has a built in identity mapper pattern to ensure that only one instance of the same entity exists within the same context at any one time - this is an incredibly important feature to ensure you're always working with the correct and same unique object.

The presentation moved on to using EF in a web application and using object data sources within ASP.NET, with two way binding etc. As far as EF goes, the usage wasn't particularly different from using it in the client server environment.

Moving to N-Tier applications, as you might expect, the service layers utilise EF but then expose out from this data transfer objects (DTOs), although the speaker did mention that passing entities directly across the wire is possible. Personally I would always go for the DTO pattern as this represents best practice to send out only the data your clients need to consume.

Next, we looked at using ADO.NET data services (project Astoria) to expose an entity model directly over HTTP. This was reasonably cool, allowing the client to still query against the entity model using LINQ, but have this then executed remotely via your data service. Whilst this is a cool feature, it moves the responsibility for query to the wrong tier - the client should ask the service for data, the service should get it and return it appropriately - having the client issue any query it likes via the service breaks this separation, but is a cool feature non-the-less.

Whilst the EF is a very positive step forward in the OR/M space for Microsoft, the fact is that there are more mature, open and proven technologies already in existence (such as NHibernate), and that several other persons in the field have issued a vote of no-confidence for the framework which must all be considered before proceeding with an EF implementation.

Tech-Ed - Free TShirt of the week.

2008-11-12T12:06:11Z

Just got a free t-shirt from the guys that produce dotfuscator. On the front the slogan is;

"I can see you, I'm instrumenting"

and on the rear;

"You can't see me, I'm obfuscating"

Definite geek t-shirt, but I find this hilarious.

Day 3 - 10:45 : Windows Workflow Foundation 4.0: A first look (SOA207)

2008-11-12T10:09:55Z

Presented by Aaron Skonnard, co-founder Pluralsight, this session looked at the up-coming release of windows workflow foundation 4.0.

Firstly, my definition of workflow is slightly different to how MS define workflow. I think of workflow as the definition of a process - usually some form of state machine type process which involves activities consisting of system and human interaction. MS define workflow the same in most ways, but consider workflow to additionally be a new way to write software overall.

In this guise, WF helps to move traditional sequential processing (get input, store state, with control flow logic) into a loose coupled distributed world (SOA). However, the current implementation of WF has challenges for adoption including;

Limited support for XAML only workflows.
Versioning is problematic
Limited base activity library
Writing custom activities and managing data flow is not easy enough today
Limited WCF integration and activity support
No generic server host environment

WF 4.0 aims to address these issues in .NET 4.0 by introducing:

XAML only workflows are the new default, with a unified model between WF, WCF and WPF. (Set breakpoints in XAML, designer writes XAML etc)
Extended base activity library

Flow Control

Flowchart
ForEach
DoWhile
Break

SendMessage
ReceiveMessage
ClientOperation
ServiceOperation
CorrelationScope
InitializeCorrelation

Others

Assign
MethodInvoke
Persist
Interop
PowerShellCommand

+ MS are planning to ship additional activities via codeplex.

Simplified WF programming model
Support for arguments, variables, expressions
Major improvements to WCF integration
Runtime and designer improvements (designer is WPF based)
Hosting and management via "Dublin"