During Build 2014, Microsoft renewed its commitment to the long ignored .NET Micro Framework. This is the lightest weight version of .NET that is used for very small embedded devices. A popular way to get started with .NET Micro is through Netduino, an open source electronics platform.
Because it is designed to run on hardware with only 60 KB of RAM, the .NET Micro is rather limited when it comes to built-in libraries; even basic functionality such as accessing REST based resources over HTTP require help from people like Daniel Stegmaier of the mfRCF project.
InfoQ: To start with, can you explain what mfRcf is?
The mfRcf is a tiny framework, which reduces the effort and potential complexity of implementing an REST-based interface on a netmf-plattform. It also contains frequently used functions, like URL-Parameter-Parsing.
The implementing major-requirements was:
- dynamic Hosting, possibility to implement different Hosting SetUp's
- e.g.: on different Network-API's or even on the big .net framework (netFx) or mono
- this should also ensures the independent testability
- case-invariant path declaration @design-time
- dynamic executable return-types
- (customizable-)basic-http-authentication
- no ssl (or x509-)support
Supported http-action-codes are:
GET
POST usually used 4 insert
PUT usually used 4 update
DELETE
But the mfRcf itself, is only the half the rent, in the most rest-interfaces stream-content, e.g.: POST or PUT, have to be parsed and interpreted, that’s why I implemented the mfXmlSerializer, based on the XmlReader under System.Xml.Legacy and the XmlWriter under System.Ext.Xml, which can be used to like the XmlSerializer-class in the .NET Framework 2.0.
The (netmf-)Dependencies are here visualized with a component diagram:
Figure 1 mfRCF componentdiagram
The published code on codeplex contains a sample-project mfRCF.NetduinoPlus2.TestApp and implement a simple sample-rest-interface:
http://netduino/led?state=true
http://netduino/led?state=false
root on :80
/rss
HTTP-GET
in: void
out: text/xml
<rss/>
specification@: http://cyber.law.harvard.edu/rss/rss.html
/state
HTTP-GET
in: void
out: text/xml
<State/>, deserialized with mfXmlSerializer
/Date
HTTP-GET
in:
GET-Parameter: void
out: text/plain current DateTime in
Format 'yyyy-MM-ddTHH:mm:ss
HTTP-CODE
HTTP-POST
in:
GET-Parameter: date :DateTime as string
/led toggles the onboard-led based on the GET-parameter on the netduino
HTTP-GET
in:
GET-Parameter: state : bool out:
HTTP-CODE
The platform independent use of the mfRCF is guaranteed by an interface-structure:
Figure 2 mfRCF plaform independent interface-structure
The configuration and initialization of the mfRCF application is done with a few lines-of-code:
Figure 3 mfRCF command configuration and initialization
The mfRCF ensures, that the combination of http-path and –method is unique.
The provided REST functionality is implemented based on the command-pattern:
Figure 4 mfRCF Http-Action-Code base commands
Custom REST-Commands can be implemented by inheritance from mfRcfCommand-class, for example in case of the http://netduino/state path:
Figure 5 http://netduino/state rest-command implementation
Through the command-based implementation @this point the developer can concentrate on the details of the concrete functionality, without the concern of the http-path and -method context. In the most embedded systems the size of the code is critical, the command-based implementation reduces code-copies and increases the grade of reusability.
The needed space for the mfRCF is:
- 86KB mfXmlSerializer (with references: System.Xml.Legacy, System.IO and System.Ext.xml ['MFDqwsExtensions.dll'] included)
- + 36KB HttpReferences (Microsoft.SPOT.Net, System.Http)
- + 10KB mfRCF.Core && mfRCF.netmf itself
- = ~135KB
InfoQ: Why did you feel the need to create mfRcf?
In another netmf-project I was forced to implement the http-path- & -method-parsing with switch-case, which ends up in a heap of unmaintainable code and a high code-complexity.
As a global alternative the MFDPWS was too heavy and not platform-independent enough for my project.
I am a fan of REST, because almost each platform today can handle http-requests and -responses and compared to WebServices its efficient respective to memory and runtime, which recommends REST to the use on embedded systems. Unfortunately I didn’t found an elegant way inside the netmf or as an external library/framework, which is why I tried it ;-)…
InfoQ: Over the long term do you see the .NET Micro Framework as being a viable platform? Or do you see it being replaced by more comprehensive versions of .NET?
I think the netmf in connection with visual studio is a powerful combination to increase software-quality, reduce development efforts and increase the (component-) reuseableility for specialized (not real-time) embedded systems lower than the .Net Compact Framework, this is the place where is see the authorization to be there of the netmf.