Task Parallel Library – Internet of Things

We want to implement a energy monitoring system with the help of C# library which has interface with an Embedded System and relevant controllers attached to it. Its essential that we communicate with these devices and understand the data trends they provide. This would help to build the intelligence through some machine learning algorithms and there by improving the intelligence of these devices.Smart Home

The challenge in doing this is to have a master controller or a service which can talk to these devices are different intervals sequentially or parallel so that it can be more realistic and efficient. While I was looking at developing this kind of app I was looking at c# to implement a multitasking to communicate with these devices at different intervals in parallel. Thanks to TPL the Task Parallel Library of .NET Framework. Before I started writing these post I read about the TPL on  Introduction to TPL , Parallel Tasks in .NET 4.0 – Dotnetcurry and Understanding Task Parallelism Framework (TPL) using C#. These are really good articles to hit the ground pretty fast.

The rationale behind looking at this option is to evaluate how we can make best use of concurrency to collect data from devices and pass it on to the Message queues like Mqtt/RabbitMQ. This scenario would be very much helpful when you have the following scenarios with respect to M2M or IoT:

  1. Devices cannot be reprogrammed with the client to develop and deploy client app to the device.
  2. You have the exposure of data through connectivity means
  3. You can poll the devices for specific parameters through Usermanual
  4. You have connected your smart devices through LAN via Wi-Fi or Ethernet
  5. Communication can be done to the devices via standard protocols

Why TPL?

  • Need to interact with the devices concurrently
  • The topics needs to be monitored and can invoke parallel tasks based on the nature of message
  • The parallel tasks could be like sending Alerts, Notifications, Writing logs, etc.,
  • Tasks should all be done in an async manner

In the another post, I will try and see how we can accomplish this with the help of TPL.


Introduction to Microservices

“Microservices” is basically an architectural style to develop a single application having small services which can communicate using Lightweight mechanism such as HTTP resource API. This would be most suitable when you have multiple interfaces which you would like to consume in the end-user scenario. Probably this post would be a summary of the Keynote from Martin Fowler.

Also microservices are nothing but a meaningful subset of SOA. so it can never by considered as an alternative or to replace SOA.


Why Microservice?

  • Monolithic puts all functionality under one application process where in Microservice puts features/services into a separate servics.
  • During the deployment to a distributed environment monolithic service has similar replica of its services where in Microservices  can be deployed based on the need basis.

Common characteristics outlined in his talk are:

  1. Componentization via services
  2. Organized around business capabilities
  3. Products not projects
  4. Smart end points and dumb pipes
  5. Decentralized Governance
  6. Decentralized Data management
  7. Infrastructure Automation
  8. Design for failure
  9. Evolutionary design

Few important takeaways according to me:

  1. Componentization via Services: The componentization during development should be in such a way that it is independently replaceable and upgradable. Microservices uses the library and services can be built as components.
  2. Organized around business capabilities: Whenever the applications are built generally the teams are divided as UI, Middleware and DBAs. Instead the team should be organized around the communication channel in the business according to Conway’s law. These microservices dev teams are cross functional teams which has an broad spectrum resources with UX, Persistent Storage and project management knowledge. This helps align quicker to understand the business context in faster ways

We will discuss more on the other takeaways in the upcoming post.

SOA: Understanding the terminology

You might have came across this term many times. This post attempts to provide different perspectives available in different sources for this term “SOA”. Don’t miss this wonderful SO thread on the subject.


Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.

Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service:

  • Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
  • Is self-contained
  • May be composed of other services
  • Is a “black box” to consumers of the service

Source: http://www.opengroup.org/soa/source-book/soa/soa.htm

Also look at this page of Martin Fowler which outlines various ambiguity around the topic. Key ambiguity issues outlined there are as follows:

  1. SOA is considered to be exposing software through web services
  2. Asynchronous messaging exchange
  3. Systems communicate over standard messaging infrastructure such as SOAP/WSDL