The seventh major release of BizTalk Server has now been released to manufacturing and will be available for purchase starting October 1st.

I’m particularly interested in checking out how BizTalk integrates with the new Windows Server AppFabric (code name Dublin) and WorkFlow 4.0 to build Agile Composite Applications.

Netduino

Technical Specs

• Atmel 32-bit microcontroller
• Speed: 48 Mhz, ARM7
• Code Storage: 128 KB
• RAM: 60 KB
• 20 Digital and Analog GPIO pins

The rest of the specs for the Netduino can be found on their website here.

The Netduino is an Arduino compatible open source board, which means that the schematics are available for download and you are free to build your own board if you so desire. It also means that you can extend the functionality of the Netduino by attaching various Arduino compatible modules called “Shields” since all Arduino compatible boards must be designed with a standard socket configuration allow for the shields to be easily added on top of the Arduino boards.

Arduino with an Ethernet Shield attached.

Motor Controller Shield for controlling DC motors and Servos.

Prototyping Shield.

There are also shields for GPS, GSM cellular, Zigbee, and touch screens. As you can see you can really extend the functionality of the Netduino well beyond the basic controller. (One note of caution, some shields come with drivers that need to be installed on the Micro Framework board. Some shields such as GSM cellular’s drivers may be too large to install in the available memory on the board.)

Microsoft .Net Micro Framework

The .Net Micro Framework is a subset of the .Net Framework that is even smaller than the .Net Compact Framework. Unlike the .Net Framework or the Compact framework, the Micro Framework does not require a host OS in order for it to run. The Micro Framework has a hardware abstraction layer which allows for it to run on the bare metal. You can also install and run the Micro Framework on a host OS if your requirements are such. Also unlike the Compact Framework, the Micro Framework is now open source under the Apache 2.0 license agreement making it a very cheap option for embedded devices when compared to the cost of the embedded OS such as CE that is need to run the Compact Framework. You can download the Micro Framework and find additional information on Microsoft’s MF website located here.

Getting Started

To get started developing in the Micro Frame work you must first either install Microsoft Visual Studio 2010 or install the Microsoft Visual C# Express 2010. Once Visual Studio is installed download and install the .NET Micro Framework SDK v4.1. Last download and install the Netduino SDK v4.1.0 (either the 32-bit or 64-bit version depending on your OS) from the Netduino website here.

Once Visual Studio and the software SDKs have been installed you can attached the Netduino to your computer via USB with the USB cable supplied with Netduino board.

The first project I created was a simple “Hello World” app (Netduino style) which made the onboard user LED blink on and off. (whoooo I know, how exciting. It gets better trust me) I select “Console Application” from the Micro Framework template in VS 2010.

Next I had to go into the project properties and tell Visual Studio to deploy via USB and select the Netduino device from my device list. If you don’t it defaults to using the emulator.

Next I added references to the Netduino libraries.

The code required to turn on and off the user LED is very simple. Basically you set the OutputPort to the use the user LED and then you toggle it back and forth between 1 and 0 with the .Write() method on the OutputPort object. This is the object you will instantiate when you want to interface with any of the GPIO pins.

        public static void Main()
        {
            OutputPort led = new OutputPort(Pins.ONBOARD_LED, false);
            while (true)
            {
                led.Write(true); // turn on the LED
                Thread.Sleep(250); // sleep for 250ms
                led.Write(false); // turn off the LED
                Thread.Sleep(250); // sleep for 250ms
            }
        }

Press F5 to compile and run in debug. Visual Studio will take care of deploying the source code over to the Netduino and starts running it on the device. While running in debug and connected to the Netduino you can set breakpoints and step through your code all while running on the device.

Conclusion

As you can see there really isn’t much to getting the .Net Micro Framework installed and getting your first app up and running on the Netduino. The entire process of installing both SDK’s and write/deploying that first HelloWorld app too me less than 10 minutes. It’s really nice to be able to use the tools and languages that I’m familiar with and use everyday in my normal job.

Now I know this was a pretty simple example with not a lot of code to show but I just wanted to give a quick introduction to the .Net Micro Framework and the Netduino board before I move onto some more in-depth examples. I’ve already started working on a project that will use the Netduino to interface with a DS1621 Temperature sensor that communicates over the I2C (pronounced ‘I’ Squared ‘C’) 2-wire communications bus. I’m hoping have that project and blog post ready to publish by the end of this weekend. Stay tuned!

Big Ball of Mud

Let’s start with my original example business, Acme Enterprise.  Acme wishes to build an ecommerce system to sell its products to its customers.  The developers at Acme start out by building a web application that customers can come to for placing orders, employees in the pricing department can update product prices, and employees in the inventory management department can maintain product SKUs and product levels.  As time goes on the pricing department wants to add new functionality to the system to maintain promotional pricing on products, discount pricing on products, etc.  The inventory department wants to add new functionality to the system to provide auto-replenishment on products, warehouse location of products, etc.  As the application grows into one monolithic system it can quickly become unmanageable in its current form, or as some call it, BBOM – Big Ball of Mud.  More importantly, the different departments within Acme define the term “Product” differently.  The sales department defines a “Product” as an item ordered by a customer and added to a shopping cart with a price and quantity ordered information attached to it.  The pricing department defines the “product” in terms of not only unit price, but promotional pricing, and marketing campaign pricing that is valid for a particular time period. Meanwhile the folks in inventory management define a “Product” in terms of Quantity on Hand, Warehouse Location, and Reorder Threshold Trigger.  As the system grows, so does the complexity and the size of our BBOM.

Bounded Contexts

This is where Domain Driven Design (DDD) can help with the design of our ecommerce system.  When we start to define the term “Product” with the people responsible for products in each of the departments within the company, we realize that they all care about this thing called a “Product” but they each talk about it in a different context.  This is where DDD introduces the idea of a Bounded Context.  Our system can be split into separate contexts each with its own explicit boundary.  So what we end up with in our system is a bunch of Bounded Contexts for each of the different contexts within the system: an inventory context, a pricing context, sales context, etc.  Each Bounded Context has its own model and ubiquitous language that defines the domain and entities like “Product” uniquely to its own definition.  The key phrase to our bounded context here is “explicit boundary”.  Each context provides a contract to the outside world to interact with and can be viewed as its own application within an application.  This can provide modularity to our overall system design.  One Bounded Context shares data with another Bounded Context via a Context Map.  A Context Map exposes a well defined contract interface that can be consumed.

Bounded Context as a Service

Now let’s take our DDD ecommerce system and apply SOA principles to it. Remember when I stated that a Bounded Context provides an explicit boundary?  One of the core tenets of SOA states that “Boundaries are explicit”.  I also stated that a Bounded Context can provide modularity within our system and that a context can be viewed as an application within an application.  Well another core tenet of SOA states that “Services are autonomous.” Hmm, so what else do bounded contexts and SOAs share in common?  A Bounded Context within our system communicates with another Bounded Context within our system via a context map that provides a contract interface to the outside world.  SOA; “Services share Schema and Contract, not Class”.  So when we compare the Bounded Context of our DDD and the Services of our SOA, there really isn’t a whole lot of difference between the two.  Maybe in an SOA we should call them “Bounded Services”?  SOA is about the separation of Bounded Contexts in our application into their own services so looser coupling can be achieved while providing a certain degree of service reuse within our enterprise.  Our context map or interface to the SOA service can be done via a web service, restful service, or WCF.  For example, in our DDD ecommerce application, if we wanted to replace the inventory context with a third party inventory management or ERP system like SAP, there may be a bit more work involved to decouple it from the old system and integrate the new SAP system.  With SOA, we have a lesser degree of coupling to deal with so integrating to the new inventory system will be easier.  Notice, I said “easier” not seamless.

EDA with NServiceBus

This brings me to Event-Driven Architecture (EDA), more specifically, EDA with NServiceBus.  As we’ve taken our initial BBOM ecommerce application and we introduced DDD principles to it and refactored our system, we began to decouple the system into different functional modules, or Bounded Context, within one application running on our web server.  Each department (inventory, pricing, sales), would access the same system to update their various domains of information.  As we moved to SOA, we took this one step farther by making these contexts autonomous services that can be distributed on different servers running within our enterprise, providing user access to a particular service to only the people in the department that need to update data within that service.  The problem with traditional SOA is it still gives us a certain level of coupling with our enterprise applications between services.  If the inventory service needs to inform the pricing service that a new SKU has been entered into the system, the inventory service must know that the pricing service exists within our enterprise.  Meaning, the inventory service must be programmed to make a service call to a service interface (web service, WCF, socket call, etc.) on the pricing service.  If we decide to use a different system in the future to do pricing, we need to update the inventory service to call the new service interfaces on the new pricing system.  This is where event messages and NServiceBus can help.  If we define a series of business events that describe important transactions within our enterprise, we can publish their event messages to a message bus.  Now instead of our services interacting directly and having to be aware of one another in the enterprise, each service only needs to know to publish event messages to the message bus, and only subscribe to event messages on the message bus that it cares about.  So in the case of our inventory service, and our pricing service, the inventory service can publish“New SKU” events and the pricing service and subscribe to “New SKU” events.  At no point does the inventory service need to know about the pricing service and conversely, the pricing service doesn’t need to know about the inventory service; now what “links” the two systems together are the “New SKU” events, and more importantly the data contained within.  In essence, the event messages and the service bus, in this case NServiceBus (but we could use others) become the “Context Map” defined back in our DDD application.  The event messages are our contracts and NServiceBus becomes our service transport layer to communicate between Bounded Contexts/Services with a higher level of decoupling between our services than we had with our traditional SOA.

In conclusion

            NServiceBus provides an easy to use API to the framework to work with so we can create an event message driven architecture.  Publishing event messages via NServiceBus will allow for a much more loose coupling design between the different Bounded Contexts or Services running in our enterprise.  While applications or services will always have a higher degree of coupling between their application layers, (UI, Business Layer, DAL, etc.), Event-Driven Architecture with NServiceBus can provide for a much lesser degree of coupling between the explicit boundaries of the services.