Let's be honest; as developers, we have bought into a lie. Silicon Valley has told us that software is all fun and games. It's Emoji, open source and multi-billion dollar acquisitions. It's thermostats with artificial intelligence, virtual reality (again) headsets and drones delivering products to your door. It's flat, it's "in the cloud", it's big flashy keynotes with musical performances and it's all a lie.

This is not reality.

As much as the tech media might have you believe that this is the norm, in fact represents a fraction of a percent of the software development that goes on in this country. I think this tweet from Ed Bott sums it up quite well.

 

It is the "Gossip Girl" of the software world. Reality is not Bentley's and Versace. It's station wagons and The Gap. It's not all glitz and glamor; it's the hard work that supports the GDP of each respective country. Enterprise development is the backbone of industries that generate revenue that would make Silicon Valley and all it's sparkle look like Monopoly money. We while the next mobile text messaging app is feverishly being worked on and 60 Flappy Bird clones hit the app stores every day, enterprise developers are in the trenches solving actual problems.

A Trip Down Memory Lane

I remember working in retail on a project where we were building a hiring application for the different retail locations. Each of the thousand locations of this retailer had one or more kiosks that potential job applicants could sit down at and fill out an application. Once they were hired, they came back into the location and filled out their "New Hire Paperwork". This included Direct Deposit information, 401K elections and W4 withholdings amongst many other forms - all very sensitive data. The kiosk used an automated wizard to walk them through the process.

When we first started the project, I put together a POC for the initial job application page and went to the QA lab to test it out. I sat down at a kiosk that mimicked the location kiosk in every manner - from PC to monitor to network connection. I pointed the browser at my test server and waited. And waited. And waited. Eventually part of my page started to load. I turned to the QA Manager and said, "Is there something wrong with your network?" He looked at me oddly and said "No. You're on a kiosk. Kiosk's are on the WAN." "How fast is the WAN?" I asked. "About 12 - 14 kbps down" he replied.

OMG

Are you KIDDING ME? Our office was on a gigabit backbone and our locations were on a WAN with slower than dial-up speeds. As it was explained to me, the WAN provided a level of security that was paramount. We were processing credit card data over those connections and part of our PCI compliance dictated that we have a secure connection that was not accessible from the outside. The WAN was dog slow, but also rock solid. You had to physically be in a location at an authorized device to ever compromise the internal network.

This was the first of many grim discoveries that I made about that specific project. Some days I wanted to scream, "JUST LET ME DO MY JOB!". Everywhere I turned there was some sort of restriction. You can't use that software because it isn't approved. You can't develop with that version of the framework because it's not what we're standardized on. We don't have any money to buy that tool because it isn't in the budget. The parameters that I had to work in were so very tight. Enterprise restrictions can feel like a set of over-protective parents that won't let you have any fun. If you are a parent, then you know that these restrictions are necessary for the overall security and stability of the family unit, but that doesn't make them any less frustrating for an angst ridden teenager - and the mobile disruption has been an all out rebellion against authority.

Mobility And Leaving The Nest

Data is critical to an organization; that's not news to anybody. It's not just a by-product of doing business - it IS the business. Being able to access and digest that data is the competitive edge. For many years we set behind large CRT monitors and enterprise grade firewalls. The data stayed safe and sound in the data center. Laptops were the first to challenge the system. VPN connections arose to answer the outcry by providing a secure tunnel through which applications could be accessed and data kept safely at home.

Then mobile showed up and knocked on the door. Mobile devices with their silky smooth designs and futuristic form factors. Not only can you access your email on these new touch screen, but you can also throw birds around and make perfectly good pictures look terrible. For our data, this was the equivalent of some kid with Emo hair and skinny jeans asking if our daughter was home. NO. Go AWAY!

Only mobile is not going away. Mobile devices have different operating systems and use different languages, SDKs and frameworks. Our standardized tools buy us little to nothing when it comes to mobile devices! So the question becomes - how do I let my data leave the nest, but make sure that it stays safe and protected? Where are the SQL and Oracle drivers for mobile apps?

It's time to revisit a rather old buzzword.

SOA (Again)

Remember when Service Oriented Architecture (SOA) was the next big thing and we all scrambled to create as many SOAP services as we could? Unfortunately, I think that period may have left a really bad impression on many organizations. When the dust settled, all we had was a gross amount of XML being slung all over the network.

Services are the key to unlocking enterprise data. We used to call them "Web Services", but now they are really referred to an an "API". If you're really hip, you put the word "REST" in front of "API" or call them "RESTful Services". There may be some library abstraction on top of them, but that's essentially what is happening in the background. Whenever you see "Java Twitter API", what they are saying is "A Java wrapper around Twitter's web services". You are not connecting directly to Twitter's database as that would be a bad idea for Twitter and for you. Services are a necessary abstraction on top of business logic. If your business logic is the foundation that your application sits on, your solution is immediately quite brittle.

This might sound familiar: You swap out database instances or move a database to another node. You then have to go update the connection string in EVERY application that is connecting to that database. If you were using a service to communicate with your database instead of connecting to it directly, you would only have to change the connection string for the service, and all your applications are none-the-wiser. Services are a not a fad; they are a necessary abstraction.

The problem with SOAP was that while it created an object proxy and mapped directly to a static type, it was ridiculously verbose and impossible for humans to work with. If you were passing SOAP from a .NET service to a .NET project you had no problems. If you wanted to consume it somewhere that didn't speak SOAP (which is a LOT of places), good luck. Anyone who has ever tried do this will tell you there is truth in the famous quote "XML is like violence: If it's not working, you aren't using enough of it". So if SOA is essential and SOAP is bad, where is the middle ground?

Doing SOA Better

The great thing about services is that they are actually very easy to create. You don't need these wild abstractions that map strings to objects. You are capable of doing this. It might require a little more boilerplate on your part up front, but in the long run you will have services that actually make sense when you look at them, thusly allowing you to actually use them anywhere. There have been some pretty radical abstractions (read SOAP) that people have created, but the concept is simple: make an HTTP request and respond to it with some data. For instance, you can create a simple service using just ASP.NET MVC.

public class HomeController : Controller
{
  public JsonResult TrueOrFalse(string value) {
    var bit = false;
    bool.TryParse(value, out bit);

    return this.Json(bit, JsonRequestBehavior.AllowGet);
  }
}

You can then call this simple service by pointing your browser at localhost:port/Home/TrueOrFalse. You can then pass in a parameter on the query string and the method will tell you if it's a true or false value.

It looks like the browser returned "true", but there's actually more going on here. You can use Fiddler or your browser's developer tools to see what the browser is hiding. I have highlighted the relevant portion of the response for you.

This request is of type "application/json". You can think of JSON as what XML should have been if it were done right. It stands for JavaScript Object Notation, but it is used virtually everywhere - even when JavaScript is not present. Since JSON is so simple to compose and digest, it’s easy to access a database normally and then expose the data as JSON. For instance, an array of strings is sent as just that.

[ "thing 1", "thing 2", "thing 3" ]

When this response is received on the other side, you simply need a JSON parser to map it to the appropriate type. Every platform from Ruby to .NET to Java to iOS has superb support for JSON serialization. In many frameworks like WebAPI and ASP.NET MVC, it comes already wired in for you. In other words, it is expected that you will use JSON as it is the key to freeing your data.

Database Access

Since JSON is so easy to compose and digest, it's easy to access a database as normal and then expose the data as JSON. For instance, you may have a table of products that you want to return. It's easy to pull those objects out and then return them as JSON.

public class ProductsController : Controller
{
  private Data.NorthwindEntities _context = new Data.NorthwindEntities();

  public JsonResult Index()
  {
    var products = _context.Products.Select(p => new Product {
      ProductId = p.Product_ID,
      ProductName = p.Product_Name,
      QuantityPerUnit = p.Quantity_Per_Unit
    });

    return this.Json(products, JsonRequestBehavior.AllowGet);
  }

}

public class Product {
  public int ProductId { get; set; }
  public string ProductName { get; set; }
  public string QuantityPerUnit { get; set; }
}

Yikes! That's a mess. Fiddler will format this nicely for us.

It's an array of objects. Each object is a product. You may have noticed from the code above that the process of returning this data involves creating a simple object and putting the data into it. The reason is that the Entity Framework Context used to get the data is very complex and even if you could serialize it to JSON, it would contain a ton of information that you don't care about in terms of the application. This is we create "view models", which are simple and stripped down versions of their ORM counterparts. Usually you put these in a folder called "Models".

Now that we have exposed these products as a service, anything - and I mean ANYTHING can consume it. This is how we liberate data to be used in mobile applications. It doesn't matter if the application is native, hybrid, web or otherwise. JSON is the universal language.

Call it with jQuery...

$.get('/products', function(data) {
  $.each(data, function() {
    $("<p>" + this + "</p>").appendTo(document.body);
  });
});

Working with iOS? Use the NSJsonSerialization class. Java offers several libraries, my favorite of which is Gson.

Pushing data from devices back into systems is done in mostly the same way. In the case of ASP.NET MVC, a controller method will actually parse out any parameters that are sent along in the body of the request into the matching object.

[HttpPost]
public HttpStatusCodeResult Create(Product product) {

  var newProduct = _context.Products.Add(new Data.Product {
    Product_ID = product.ProductId,
    Product_Name = product.ProductName,
    Quantity_Per_Unit = product.QuantityPerUnit
  });

  _context.SaveChanges();

  // return a 200 ok
  return new HttpStatusCodeResult(200);
}
$.ajax({
  type: 'POST',
  url: 'http://localhost:57796/Products/Create',
  data: { ProductId: 99999, ProductName: 'New Product', QuantityPerUnit: '4 per package' },
  success: function () {
    // called for a 200 OK response
  },
  error: function () {
    // called for anything other than a 200
  }
});

Consuming SQL Data With The Telerik Platform

Using simple HTTP requests, you can expose an entire API for your mobile applications. This is how most mobile development frameworks like the Telerik Platform expect that you will be delivering your data. Since you cannot hook a hybrid mobile application directly to your database, you instead wire it up to consume your services. The Telerik Platform provides Kendo UI Mobile, which makes working with remote JSON or XML with mobile widgets trivial. For instance, a mobile application which displays a list of products using the above simple API looks like this:

<!DOCTYPE html>
<html>
<head>
  <title></title>
  <meta charset="utf-8" />
  <link href="kendo/styles/kendo.mobile.all.min.css" rel="stylesheet" />
  <link href="styles/main.css" rel="stylesheet" />

  <script src="cordova.js"></script>
  <script src="kendo/js/jquery.min.js"></script>
  <script src="kendo/js/kendo.mobile.min.js"></script>

</head>
<body>

  <div data-role="view" data-model="APP.model">
    <div data-role="header">
      <div data-role="navbar">
        <span data-role="view-title">Products</span>
      </div>
    </div>
    <ul data-role="listview" data-style="inset" data-template="productsTemplate" data-bind="source: products"></ul>
  </div>

  <script type="text/x-kendo-template" id="productsTemplate">
    #: ProductName #
  </script>

  <script>

    (function () {

      // global APP variable available off window
      var APP = window.APP = {};
      var api = 'http://localhost:57796'

      // model for the view
      APP.model = {
        products: new kendo.data.DataSource({
          transport: {
            read: api + '/Products'
          }
        })
      }

      // create the mobile application
      new kendo.mobile.Application(document.body);

    }());

  </script>

</body>
</html>

One of the difficult things about services is that they present architectural challenges that are not easily answered until you implement them and some time down the road realize that you didn't plan appropriately. We refer to this as "technical debt". For instance, what fields should be exposed? What happens when a new field is added to a table? What are the constraints? While the services layer is a necessary abstraction, it's also an added level of complexity and maintenance. Before ORMs, we put all of the business logic in the database. Since databases are not web servers, we are forced to create services and most of the time the business logic actually bleeds across the services and back into the database.

What if the database could expose it's own data without your manual intervention?

A Peek At The Future

At Telerik, we've been pondering this very problem.

When we created Telerik Backend Services, the whole point was to provide a backing data store where you never had to write the services layer. When you create a content type in your Backend Services instance, it is exposed for full CRUD operations via the Backend Services API. Remember that API is just a fancy way of saying "wrapper around a set of web services services". Not only that, but Backend Services also secures the data and provides authentication via Active Directory integration or social authentication. You literally don't have to write any facade code to expose data from Backend Services. It just works. There is Cloud Code where you can go in and add logic to the service methods for more control. We wanted to bring this same concept to enterprise users who have existing data which is NOT in Telerik Backend Services. Why should you be punished because you already have data that you want to use.

One option would be for companies to import their data into Telerik Backend Services. While some enterprises might be fine with that for certain projects, most are going to laugh at that notion. What the enterprise really needs is a way to expose their data without having to put it in someone else's database. That is why I want to give you a sneak peak at Telerik Data Link. This is super secret, so don't tell anyone and make sure nobody is looking over your shoulder when you read this. As Gandalf once said, "Is is secret!? Is it safe!?!?" It is, but we're going to look at it anyway.

When Data Link launches, you will see a new option when you login to Telerik Backend Services and navigate to Types.

The "Add New Data Link" button will start the process of setting up a new or existing Data Link. If you select "Setup new Data Link Server", you will be able to download the Data Link server.

The Data Link server is installed into IIS using Microsoft Web Deploy. You just create a site and then use the "Import Application" option in IIS.

The install instructions will help you setup an SSL connection between your server and Telerik Backend Services. You are NOT pushing data into the Backend Services, but rather giving Backend Services permission to lay it's API on top of your existing data.  Your tables show up in Telerik Backend Services as if they were actually there.



This means you get a secure connection complete with user authentication and a complete set of REST services for your data, along with all of the other nice features that Backend Services has to offer. You can literally setup Data Link and start building applications against your relational data as if you have already written a complete service layer and authentication scheme.

Does it sound to good to be true?

You can now query your SQL Database using the Backend Services SDK as if your data was in the Backend Services - but it’s not! It's still in your data center where it belongs. Telerik Data Link is smart enough to map your data to simple NoSQL data types. It also respects all of your database constraints, including updateable views. Triggers and internal database operations just keep right on working. What's even nicer is that Data Link is built on top of Telerik Data Access, so it works with SQL Server, Oracle AND MySQL. This way you can keep all of your business logic on your database, and use Data Link to create a dynamic API.

The Future Is Now

We believe that the future of productivity for many enterprises is not in creating more services and acquiring more technical debt. It is in using a solution like Data Link that can securely expose enterprise data thereby allowing developers to concentrate on building world class applications, set free of the restrictions and control that come with building and deploying enterprise code. Data Link is only one of many steps we are taking to create a complete development platform solution.

Data Link is currently in private beta.  Make sure you request your invitation today so you can start focusing more on your applications and not have to worry about how you are going to access your data from those applications.

The future is now. Are you ready?

* Emo Guy Picture from Victor Gregory Photography: https://www.flickr.com/photos/casanovapacifista/

About the Author
is a web developer living in Nashville, TN. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke works for Telerik as a Developer Advocate focusing on Kendo UI. Burke is @burkeholland on Twitter.


Burke Holland is the Director of Developer Relations at Telerik
About the Author

Burke Holland

Burke Holland is a web developer living in Nashville, TN and the Director of Developer Relations at Telerik. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke works for Telerik as a Developer Advocate focusing on Kendo UI.

Related Posts

Comments

Comments are disabled in preview mode.