rickgaribay.net

IoT, Mobility, Hybrid Cloud, ESB Oh My! A Closer Look at the Neudesic Gartner AADI Demo

Earlier this week, my colleague @simonguest posted a great summary of the demo he and I built together for the Gartner AADI Summit in Las Vegas week before last.

As Simon illustrates, the demo combined two areas we are thinking a lot about these days at Neudesic- enterprise mobility and Internet of Things.

When we talk about enterprise mobility, we're not talking about mobile device management, governance or provisioning. Our focus is on unlocking the assets that live on premises, behind the firewall so that they are safely and securely exposed, composed and consumed by a variety of devices and composite business applications on the web.

In this post, I’ll talk a little bit more about these two areas and dive into the back-end of the demo from a messaging and services perspective to give you a glimpse into the internals of the demo app.  

Exposing On-Premise Assets

The key unlocking event for enterprise mobility is enabling the ability to expose assets that live within an organization’s traditional datacenter. These assets include things like other apps, LOB systems, ERPs and databases. In the most traditional sense, the way this problem has been solved is by determining what assets need to be made available, standing up hardware on a DMZ and specifying which inbound ports allow which kind of traffic. Unfortunately, there’s really nothing too innovative about this approach as it is the way we’ve been solving this problem for nearly 20 years.

Today, there are many enterprise mobility vendors out there offering an appliance based offering which extends this approach to address things like security, hardware compression, etc., but the agility of these solutions is questionable as they still required CapEx spend, time and resources to provision and manage.

Another kind of on-premise asset you will be hearing more and more about involves sensors and devices that communicate with software and other devices. This Machine to Machine (M2M) communication will be revolutionary in domains such as transportation, retail, logistics, oil and gas, manufacturing, etc. as they will enable the ability to yield new insights that will at first transform business and then become key to survival. One such device is known as iBeacon.

These devices, about the width and half the length of a stick of gum run on Bluetooth Low Energy (BLE) and thus require very little power. These beacons transmit a unique identifier along with signal strength which can then be used to calculate proximity.

You can easily imagine a scenario where a retailer provides a free app that interacts with you in the store as you approach these iBeacons. As you might imagine, the back end of the app would learn your behaviors and preferences and target you with interesting offers to influence your browsing and buying habits as well as crowd sourcing what ideal retail layouts look like based on the tons of data that could be collected and modeled. Another scenario might involve tracking shipping containers on trucks. Today, 5.9 RFID technology dominates this space but the amount of infrastructure required to read the tags compared to what can be accomplished with a handful of iBeacons and a handheld device is disruptive indeed. To illustrate this in our demo, our iBeacons communicated directly with iOS and Android handsets, with literally no set up or tear down, allowing us to enumerate, update and “check into” the beacons that were placed throughout the conference floor.

For the check in scenario, as you approached an iBeacon, the app would raise an event allowing you to check in to that location. The app then sent a message over the Gartner guest conference WIFI network to a server hosted in our datacenter in Irvine, CA running Neuron ESB. The server sits behind our firewall and no inbound ports are open because our IT policy rightfully prohibits it. Instead, a single outbound port is opened by Neuron over an Azure Service Bus Relay which allows for secure, bi-directional messaging for a number of APIs that we implemented which I’ll cover in more detail next.

Composing and Consuming

As you can see in the demo sample architecture, we exposed a REST head over Azure Service Bus which provided the external messaging fabric for communicating with the apps running on iOS and Android in the Gartner exhibition hall. Using Neuron’s messaging and processing capabilities, we implemented the following 4 APIs:

REGISTER BEACON PUT /beacons { id: "<<GUID>>", name: "Neudesic Booth, Expo Hall"}   LOOK UP BEACON GET /beacons [{ id: "<<GUID>>", name: "Beacon name"}, {id: "<<GUID>>", name: "Beacon name"}] (Array)   GET ALL BEACONS GET /beacons/:id { id: "<<GUID>>", name: "Beacon name"}   CHECK IN TO BEACON PUT /beacons/:id/checkin { userid: "<<facebookid>>" }

The Android version of the app the weekend before the conference. We used Xamarin to build a consistent UX for iOS as well. The iBeacons were re-registered with the actual locations of the booths on the conference floor within a few seconds.

To create a connection to Azure Service Bus, we simply created a Client Connector within a Service Endpoint in Neuron as shown below:

Neuron hosts an instance of the WCF NetMessagingBinding and creates a virtual service endpoint using the URI shown above.

In order to route the requests from the app to the right logic, we implemented a simple controller called “Beacon Router” using a Neuron Process. Using a Decision step, we added 4 branches for each API:

Each Decision Step has a condition which returns true or false. If the condition returns true, the steps within the branch are executed. If not, the Process evaluates each branch until a match is found our returns a 404, Resource not Found.

Here is a look at the the Check In Condition:

As you can see, we used a simple UriTemplate to define the template for the Check In API. The URI is stored in the ESB message context within the MessageHeader.To property. If the template matches the actual URI, we return true and the steps within the branch execute in sequence.

The next step that fires is the Publish step. We included this step for testing purposes to serve as Wire Tap on the messages that reach the branch. In this case, this was useful for inspecting the message off the wire by configuring a subscribing party and using our Neuron Test Client to inspect the message:

This little trick aside, the Publish step is very powerful in that it allows you to asynchronously publish a message on a topic for other subscribers to pick up. Think of Scatter Gather as a good example.

The next step you’ll notice is a Call Process step. This step simply allows you to call a nested Process which is helpful in factoring your Process (note that we could have chosen to asynchronously execute a nested process by wrapping it inside a Parallel step).

The Check In process starts with a Push step. This step stores the current message for later use.

This was required because we needed to first determine if the iBeacon location was valid before allowing a check in. The way Neuron Processes work is that the message is modified by each step allowing for very powerful enrichment and transformation of the message. However, since there can only be one message in context at any time, the current message is overwritten by the message we crafted up for the ODBC step which follows.

In this case, we used the ODBC step to query SQL Server for the iBeacon guid. The ODBC step expects a message that conforms to it’s interface, a simple XML syntax for defining the query:

   1:  string sql = String.Empty; 

   2:   

   3:  sql += "<Statement type=\"Text\" sql=\"SELECT * FROM [dbo].[Beacon] WHERE BeaconGuid =?\">"; 

   4:  sql += "<Parameters>"; 

   5:  sql += "<Parameter type=\"varchar\" name=\"@BeaconGuid\" value=\"" + beaconId + "\"/>"; 

   6:  sql += "</Parameters>"; 

   7:  sql += "</Statement>"; 

   8:   

   9:  context.Data.FromXml(sql);

Note line 9 above replaces the message in the context with this new message. The ODBC step executes the query based on the latest context and returns the result:

<QueryResults> 
    <QueryResult> 
        <Id>2</Id> 
        <BeaconGuid>1.1</BeaconGuid> 
        <BeaconName>Neudesic Booth</BeaconName> 
    <QueryResults> 
<QueryResult>

Next, we used a Decision step to check to see if the ODBC step yielded the iBeacon we looked up:

   1:  var xml = context.Data.ToXmlDocument(); 

   2:  var node = xml.GetElementsByTagName("QueryResult"); 

   3:  return node.Count > 0;

If the node count is not zero, we know we have a match. Otherwise, we issue a 404 since the resource could not be found.

Recall that at the beginning of the process execution, the first thing we did was push the message into temporary storage so that we could retrieve it later. Once we determined that the iBeacon exists, we pop the message back into context so that we can grab the iBeacon id from the URI and the user id of the user (in this case, a facebook email address) from the original HTTP message body.

To perform the chec kin, we simply did an INSERT into a SQL Server table called CheckIn. The Code step includes the following code, which as before, the ODBC step will consume and perform the unit of work.

Since the iBeacon ID is part of the URI, we use UriTemplate again to determine a match and then extract the {id} parameter from the URI:

   1:  System.UriTemplate template = new System.UriTemplate("/beacons/{id}/checkin");

   2:  Uri uri = new Uri(context.Data.GetProperty("MessageHeader","To"));

   3:  Uri baseUri = new Uri("https://" + uri.Host);

   4:  var match = template.Match(baseUri, uri);

   5:   

   6:  var beaconId = match.RelativePathSegments[1];

From there, we do some formatting and grab the user id from the JSON message payload that was provided in the HTTP body:

   1:  System.Web.Script.Serialization.JavaScriptSerializer serializer = new System.Web.Script.Serialization.JavaScriptSerializer();

   2:   

   3:  Neudesic.TPG.GartnerAADI.Model.CheckIn checkIn = new 

   4:  System.Web.Script.Serialization.JavaScriptSerializer().Deserialize<Neudesic.TPG.GartnerAADI.Model.CheckIn>(jsonString);

Finally, we build the INSERT statement and load the new message context:

   1:  string sql = String.Empty;

   2:   

   3:  sql += "<Statement type=\"Text\" sql=\"INSERT INTO [dbo].[CheckIn]([UserId],[BeaconGuid],[Date]) VALUES(?,?,?)\">";

   4:  sql += "<Parameters>";

   5:  sql += "<Parameter type=\"varchar\" name=\"@UserId\" value=\"" + checkIn.UserId + "\"/>";

   6:  sql += "<Parameter type=\"varchar\" name=\"@BeaconGuid\" value=\"" + beaconId + "\"/>";

   7:  sql += "<Parameter type=\"varchar\" name=\"@Date\" value=\"" + DateTime.Now.ToString() + "\"/>";

   8:  sql += "</Parameters>";

   9:  sql += "</Statement>";

  10:   

  11:  context.Data.FromXml(sql);

If all goes well, we issue an HTTP 200 back to the client:

   1:  context.Data.Http = new HttpMessage();

   2:  context.Data.Http.StatusCode = System.Net.HttpStatusCode.OK;

   3:  context.Data.FromString("");

Otherwise we own up to the problem being on our end and return a 500 (with some internal logging of course).

The Register API is implemented in much the same way. We check to see if the iBeacon exists and if so, do an update, otherwise insert a new record. Thus, this API supports initial standing up of the beacons as well as managing the names as the beacons moved from development to the expo floor.

For the GET APIs, we again used ODBC steps to query for a single or all beacons and returned a single or an array of beacons respectively as you can see in the BeaconRouter screenshot at the beginning of this walkthrough.

Summary

As you can probably guess, Simon and I had a lot of fun building this demo and the folks at the conference seemed to find it interesting too :-)

There are unlimited possibilities once you unlock the ability to safely and securely transcend network, security and business boundaries behind the firewall. And if agility isn’t enough to compel you to think differently about how you expose and compose your enterprise assets for external consumption by mobile devices today, the proliferation of devices- and I’m not talking about tablets or phones- expected to reach in the excess of 250 billion by 2025, will challenge every industry to think differently about their enterprise messaging and mobility strategy.

Print | posted on Saturday, December 21, 2013 8:49 AM | Filed Under [ Neuron ESB Windows Azure Azure Service Bus IoT Mobility ]