Another powerful tool in the composition framework is the ContentFactory. This provides methods for registering and getting content based on a contentType string. When getting content, if the contentType is not found in the container, it will try to fallback using substrings of contentType by progressively removing sections after a .

As an example, we might have some serializers that inherit from ISerializer.

We can create a new SerializerFactory that inherits from ContentFactory.

Then we use a custom installer to register the factory as a singleton, and also to register our default content (i.e. the serializers).

We are now able to use the SerializerFactory.GetContentFor(string contentType) method to retrieve our serializers by the name we registered them with:

• SerializerFactory.GetContentFor("Foo") will return FooSerializer
• SerializerFactory.GetContentFor("Foo.Bar") will return FooBarSerializer
• SerializerFactory.GetContentFor("Foo.Bar.Baz") will fallback to contentType of “Foo.Bar” and return FooBarSerializer

In the next post I’ll show you how to get set up with endjin composition framework in an MVC4 / WebAPI application.

@MikeLarah

Firstly, we define an interface for some type

Then, we create a concrete type for our interface

Now we can use one the composition framework’s convention based installers. For instance we could use the namespace installer, to install all types in a given namespace into the container.

The namespace installer will register types against their Default interface – where the default interface is the interface that follows the naming convention I + [my specific name] + [service name] (e.g. the default interface for class FooBarService : IFooService, IFooBarService is IFooBarService)

Most of the convention-based installers will install the concrete type into the container as Transient by default, but we can explicit specify the lifestyle using [Singleton] and [Transient] attributes.

See the Installers page on the GitHub wiki for a complete list of all the installers included in the framework, and explanations of how they work.

Next step is to initialize the container within our application’s start-up code. This is done using the Bootstrapper appropriate for whichever framework we are using, which will locate the installers in our assemblies and install the types they find into the container.

WP8

WinRT

.NET 4.0/4.5

You can now use the static ApplicationServiceLocator.Container for resolving your root types.

In the next post, I’ll go over how to use the ContentFactory for registering content with custom names.

@MikeLarah

There are a few reasons we decided to take this step. Mainly, we were developing some early Windows Phone 8 and Windows 8 applications last year, like our cross-platform charting controls and Milliman’s Azure Compute Dashboard, and we couldn’t live without DI. At the time, none of the existing container frameworks supported all the main Microsoft platforms that we were working with, so we had to “roll our own”. I did attempt to build a Windows 8 Azure Dashboard app (see pic) without DI to begin with, but the barrier to maintainability meant when it got large enough I ended up pretty much going back to the start and reimplementing it using our new framework.

Other containers are also really expensive for a ‘miss’ scenario (i.e. trying to resolve a component that isn’t registered in the container), because they use exceptions to implement this. We wanted to be really efficient for failing to find a match so we could implement an inexpensive “fallback mechanism” (e.g. looking in the container for handlers for specific content types, falling back to more general versions, if they were not found).

The other reason was, as much as we love Castle Windsor, it does a lot (much like the Spring Framework in the Java ecosystem). It suffers from a problem that many OSS projects do – it’s based on contributions from the community but rarely do people rationalise and prune the feature set. So with our container, we’ve stripped it back and included only the features we require. This means that there’s lots it doesn’t do, but in this series of blog posts, we’re going to cover many of the main usage scenarios.

Whatever the framework, component composition works the same way: you have contracts and concrete implementations and you need to map one against the other. The Endjin Composition Framework helps you work smarter, not harder by making component composition simple.

You can install the packages via NuGet or the source code is available up on the endjin GitHub page. There are packages for use with .NET 4.0, .NET 4.5, WinRT and Windows Phone 8 frameworks. Additionally there is an Endjin.Core.Composition.Web package with extensions for use in ASP.NET MVC 4 / WebAPI applications.

There are samples in the GitHub repo for how to use component composition for each of the supported frameworks, and in the next post I’ll go over how to get set up.

@MikeLarah

Twilio is a cloud based voice and SMS service and this post will show you how easy it is to create your own inbound voice application using MVC 4 Web API.

The basic premise of how it works is Twilio parses a form of XML called ‘TwiML’, which contains various verbs telling Twilio what to do. For example, parsing the following TwiML would read out “Good morning. How do you do?” in a woman’s voice, pause for 5 seconds, then make a POST request to https://twiliowebapisample.endjin.com/api/Sample for the next section of TwiML :

The full set of verbs and parameters you can use are detailed in Twilio’s docs section.

When someone dials into your service, Twilio will make a request to an action on one of your Web API controllers. Your controller may call on some back-end infrastructure and will then generate some TwiML to return to Twilio’s parser. This TwiML will need to contain instructions on where to make the next request, and so this will continue until the call is over.

Setup

To get started, firstly create a new ASP.NET MVC 4 app in Visual Studio and select Web API. Then pull in the Nuget package for Twilio.Mvc which contains libaries for MVC helpers and REST API wrappers.

You will also have to sign up for a Twilio account (there is a free trial for developers). You will be given a phone number on signing up that you can use for the service.

Controllers

Let’s start by making a controller for our Twilio service to call when someone rings in. Create a new ApiController with a Post method like so:

By default, all request Twilio makes are POST but you can change these to GET if you wish. When Twilio makes a request it also passes a set of parameters, the same as the ones contained in the VoiceRequest class in the client library.

Use the TwilioResponse MVC helper to build up the TwiML for the response. It contains methods for generating the correct TwiML and stores it in the Element property. When you have built up your TwiML, simply return the Element property as an HTTP response and format as XML.

If you use the gather verb in your TwiML, after the user has pressed a specified number of digits, Twilio sends a request to the URL you specify in the action parameter (you can specify relative or fully-qualified URLs). It also passes a Digits string as one of the request parameters, which contains the numbers that the user pressed on their telephone. Now you can use these digits in your controller method, for example if you wanted a user to enter in an ID number to login into a service.

Now if you wanted to pass other parameters to your controllers (the ID number the user previously entered, for example) you can just format your action and redirect URLs to include query parameters

Then add a extra parameter to the action of the relevant controller

You can create a complex service with many functions in this way.

Security

If your controllers expose any sensitive data you may want to validate that your requests are coming from Twilio. Fortunately, if you are using SSL and configure Twilio to use HTTPS URLs then you can do just that.

Twilio will take the full request URL and any POST parameters, concatenate them into a string, sign the string using HMAC-SHA1 with your AuthToken as the key (you are given an AuthToken when you create an account), and send this signature as a header on the request called ‘X-Twilio-Signature’. Full details are given in Twilio’s Security section.

So to authenticate the request we need construct the signature in the same manner on our side and check the two signatures match. In the Twilio.Mvc client library there is an attribute that can be applied to controllers and actions called ValidateRequestAttribute that does this for you if you are using MVC. For Web API though we will need to change this method slightly.

Create your own attribute as follows:

You will want to store your AuthToken somewhere in your configuration. In my example I have stored it in the Web.config file and used the ConfigurationManager to retrieve it in the default constructor. You’ll also notice there is a constructor that takes a urlOverride – you may need this when testing (we’ll get to that soon).

You can see the IsValidRequest method mirrors Twilio’s process for constructing the signature and then does the comparison. The attribute throws an exception and returns a Forbidden code if the signatures do not match.

To use the validation, all you need to do is decorate your actions (or controllers) with the attribute.

Debugging

To check if your controllers are returning the correct TwiML you could use a web debugging tool such as Fiddler to make requests to your controllers and look at the responses. But if you want to test your application actually running in Twilio then you will need to create an app in the Twilio dashboard. To do this, sign in to your Twilio account and go to DEV TOOLS –> TWIML APPS –> CREATE APP.

Give it a friendly name and then you will see you have to supply the request URL as an endpoint for Twilio to make requests. Now unless your machine is publicly exposed to the internet, you will need to set up some tunnelling in order to debug your application whilst in development.

For tunnelling I used a service called Forward (it was the only service I could find to work on Windows). This takes a little bit of setup. Firstly you will have to install Ruby and RubyGems (Ruby Installer for Windows is an easy option for this). Then sign up for an account at Forward – they offer a free 30 day trial.  With Ruby installed, open up Command Prompt With Ruby and install Forward using

gem install forward

Finally, in your Web API project’s properties pane in VS, in the Web section under servers, change the setting to ‘Use Visual Studio Development Server’ and set a specific port of your choice.

Now we’re ready to go. Back in your Twilio dashboard, set the the request URL for app as the domain you specified when signing up for Forward (e.g. https://example.fwd.wf). Start up your Web API app in debug mode, then in Command Prompt With Ruby type

forward {port}

where {port} is the port you assigned in the app properties. The first time you do this you be asked for your Forward credentials.

With that done, you should now hopefully be able to call your service. If you navigate to your TwiML app in the Twilio dashboard, just press the Call button.

And now you can run through your service using the onscreen keypad and debug on your development machine. The Twilio debugger in the dashboard also provides useful information for when errors occur.

NOTE – if you are using the authentication attribute from above to do validation, you will need to specify a urlOverride parameter when testing, otherwise you will find that Twilio will use your Forward URL when constructing a signature, but your app will use a “https://localhost:{port}” URL and they won’t match.

Conclusion

There is of course plenty more functionality to be found with Twilio and this just scratches the surface. I would recommend you check out their website for all the features. But following this guide you can get quickly and simply set up with building an inbound voice application using Web API.

For the full sample application, download it from the endjin samples GitHub repo.

Finally, thanks to @sydlawrence and @devinrader for help getting me starting with my Twilio project.

@MikeLarah

The way to do it is to mock an HttpServer and HttpClient class, but first you have to change some of the config to get them working correctly.

In the WebApiConfig in App_Start, create two overloaded methods for mapping HTTP routes – one that takes a RouteCollection as a parameter (for when running in debug/production), and one that takes an HttpRouteCollection (for when running integration tests).

You will also have to define your own class for a Route - with Name, Template and Defaults properties.

Then call the AddHttpRoutes method during application startup (I placed it in the RegisterRoutes method of RouteConfig) to configure the routing on the Web API controllers.

So now we are ready to set up some integration tests – in my sample I am using NUnit.

In your test setup you will need to instantiate an HttpClient and pass a configured HttpServer as a parameter (using the overloaded AppHttpRoutes method to configure it).

Now you can create an HttpRequest and use the HttpClient to send the request and hit your Web API controllers, then run your assertions on the HttpResponse that is returned.

And that’s it. Now you can run integration tests against your Web API controllers – useful for checking if your routes are correctly configured.

Check out the full sample on the endjin samples GitHub repo.

@MikeLarah

There were some great talks throughout the day and I’ll highlight a couple of the ones I attended.

DDD, CQRS and Event Sourcing – Neil Barnwell

First talk of the day from a first time Developer Developer Developer speaker (although you would never have known). Neil used a series of examples based around his current line of work (warehouse management systems) to put forward his arguments. He went through the advantages of using Domain-Driven Design for any applications that require more logic than CRUD (Create, Read, Update, Delete). I’ve been informed that this book by Eric Evans is good place to start for DDD and has been added to my reading list.

He went on to talk about how DDD lends itself to two other ideas: CQRS (Command Query Responsibility Separation) and Event Sourcing.  CQRS as I understand it is essentially a separation of commands (which mutate state) and queries (which do not). This leads onto the idea of Event Sourcing, where every command triggers an event and these event objects are stored in sequence. Then you can do interesting things like replaying the events to rebuild the application state, or looking at at the state at any given time in the past. Neil pointed out that this could be really useful when debugging as you can see the precise sequence of events that led to a bug.

I found this link and this link useful for better understanding the ideas.

Developing real-time asynchronous web applications – Mira Javora

Mira showed a really interesting example of using SignalR to create real-time web applications. His example was a basic “Formula 1” web app that showed updates to race position, news etc.

He explained that instead of the client constantly querying the server to see if there is any new data, by implementing SignalR, the server establishes whether the client is capable of accepting real-time information and creates a persistent connection using WebSockets if possible (and if not it uses another real-time technique such as Long Polling).

From what Mira demonstrated, I feel there is a lot of potential in these type of applications and am looking forward to trying it out for myself.

Designing for Mobile – George Adamson

A lively talk from George that made me a think. He spoke about how the instinct is to design “desktop” apps primarily, then make a “mobile” app to fit around that by some means, whether that be by linking to the desktop site for full features or just omitting features altogether.

But, to quote George himself, “Mobile traffic has/might-jolly-soon overtake desktop traffic”. We expect to be able to do the same things now whether we’re on our smartphones, tablets or laptops and all these devices can be classed as “mobile”. So almost every web application should be designed with this in mind and the solution he suggested is to place content as first priority and use responsive web design.

George then went on to explain various ways of implementing this and talked about good practices to bear in mind when designing for mobile.

Overall I would say DDD10 was great success and I will definitely be attended more of their events in the future. The Doctor Who cupcakes helped too (not a fan of the show BTW, but they were delicious)

@MikeLarah

(Here is a link to some useful videos on dependency injection and Castle Windsor that helped me to understand why they are used).

Part of the framework uses a class called WindsorContainerBootstrapper which calls a GetInstallers method which looks through all referenced assemblies and finds and returns a list of the Windsor Installers that are contained within them.

This was designed for console applications though. To make this work, I made a change so that it uses the HttpRuntime.BinDirectory method to correctly locate the bin folder where the assemblies are stored in a web application.

This extra class could not be added to Endjin.Core.Composition though as HttpRuntime is dependent on System.Web, and Endjin.Core.Composition uses the .NET 4 Client Profile which does not support this.

So I added a new WindsorContainerWebBootstrapper class to the project and called it in the dependency injection configuration to initialise a new Windsor Container.

This means I can now resolve my types dynamically.

(As a side note, we now have a GitHub Gist plugin installed for the blog so all the pasted code looks pretty)

@MikeLarah

The day kicked off with Mike Taulty going over all the features of Windows 8 and explaining how to use the new touch based controls and also how to do everything with whilst using traditional keyboard and mouse. I must say, even after having used Windows 8 for 3 weeks now, I found it becomes much easier to use as a desktop OS once you learn all the keyboard shortcuts ( Windows + q for search, Windows + . to “snap” an app, Windows + c for the charms menu, etc.) and the split desktop/tablet experience isn’t as jarring as I first found it.

Then a great talk from Andrew Spooner about the UX/UI considerations when developing Metro apps. It appears Microsoft have taken a big step towards making the user’s experience seamless between apps, by encouraging developers to do things like only using fonts of 3 specified sizes (depending on heading/subtitle/text) from a select group of typefaces and considering how the app’s views for semantic zoom.

Back to Mike Taulty again for a more in-depth talk about the new Windows APIs specifically for Metro apps like sharing, searching, notifications and app lifecycle management.

In afternoon we got to see these APIs in action as we put together a Metro app through a series of tutorials, building the ‘Contoso Cookbook’ app (and getting my first, slightly daunting, experience with using XAML).

I could talk about any and all of the new features in detail but I think one of my favourite parts was how easy it is to set up an app to share content and also how easy it is to set up another app to consume that content.

When hitting the share charm whilst on a page in the app, a DataRequested event is triggered. All that needs to be done in the app is write a handler on that page to respond to the event. So for example, for the single item page (in this case a recipe) like this,

the method needed to share the image and text is:

Then when hitting the share charm, Windows filters through your apps to determine which ones are capable of handling the file types you have shared.

Using the Share Target sample from the Windows 8 SDK we can see that the image and text content were both shared.

So, all in all an interesting day at Microsoft and I think it’s going to be quite fun doing some Windows 8 development.

@MikeLarah

The other part of my week has been spent preparing to write a web application to assist in logging my (and future apprentices’) progress. The idea is to create a system where it is easy to log activities that have been completed and represent the logged data in useful ways. Other features will be to provide a way to give feedback for continuous assessment throughout the apprenticeship, and a library for sharing useful articles/tutorials/tools. To get prepared for this, I have been studying Pluralsight courses on ASP.NET MVC and Web API.

To begin designing the structure of the site, I have been creating a mindmap (using XMind) and using a great, simple tool called Balsamiq Mockups to create wireframes like the one below.

These are both great ways to start thinking about the features for the site and the architecture that will be required to build it.

Finally, I have also this week attended the Microsoft TechDays Windows Azure Developer Camp (taken by cloud evangelist Steve Plank), where I was shown an introduction to cloud computing and how to do things like deploy an application to Azure, and create and utilise cloud storage and databases.

@MikeLarah

So one down! Next up was to try TeamCity and straight to C# and VS 2012 for this one as the REST API looked similar to YouTrack. For this we used the TeamCitySharp NuGet package (by Paul Stack).

Although similar, it was not exactly the same and I found that it required a XML object passed, not just a string. We ended up using Fiddler to determine the structure of the required request body to create a new user and tested by using POST request in Fiddler itself (below). This turned out to be successful, except there was an issue (again) with the password.

After contacting the TeamCity team, it seems like there is a issue in the XML deserialization which ignores the password and they suggested a workaround by using a separate PUT request for the password. Using this fix, I got the CreateUser method fully working in TeamCitySharp and so have now successfully got two of the five accounts for new employees to automate new users. Next step will be to wrap them up in PowerShell script.

So to sum up this first week at endjin: I’ve had a play around with PowerShell and C#, learnt to use various debugging tools like Fiddler and IDE debuggers, learnt how to use BDD and testing frameworks, used Git to save and share projects, learnt how to configure virtual machines, toyed around with various tools to increase productivity and attended a client meeting about developing a communication plan. Been kept busy but that’s not a bad thing!

Next week I’ll be off at a client to run some testing, spending a day at Microsoft to attend a course on Azure, and starting to develop a web and mobile app to log apprentice activities and development.

@MikeLarah