Monthly Archives: August 2013

Mobility for companies and organizations

Recently, I visited a lecture, held by Mikael Håkansson at Enfo Zign. The lecture was a part of Microsoft’s Summer Camp series and was held at Microsoft’s offices in Stockholm.

Enterprise Mobility is mainly about processes – large ERP-systems, HR-systems and CR-systems, starts Mikael: It is my experience, that you purchase these systems for the processes they enable/facilitate and then you tweak your organization to fit theses systems.

Traditionally, large ERP systems do not have very intuitive user interfaces (they are largely thick windows clients), why there’s a lot room for improvement as far as clients – consuming or accessing these processes – are concerned.

To discuss the processes some of theses systems provide, let’s investigate the time reporting process: This process starts way before you actually report your hours. First off, someone creates your project and assigns time slots, before you can submit your time. Thereafter, there is usually some form of approval process by a manager.

What we are to discuss today, is Work Order Management.

In Enterprise Mobility, I have found that about 60% of your work load, is performed on the server side.

Some of the challenges you are facing when working with enterprise software, are:
- Format: Line of Business systems have their own formats. If we’re lucky, they are either some form of XML, or have the ability to export data as XML, but XML isn’t optimal either for mobile applications. Whenever possible, we prefer JSON, being a lighter weight protocol and sporting better native support on the various mobile platforms.

- Transport: REST is our preferred transport, since it’s both testable from a browser and easy to consume for our mobile clients.

- Availability: How are going to be able to let an application – running on an arbitrary 3G network – let us access corporate resources behind our firewalls, without compromising the corporate network itself?

- Security: How do we authenticate our users? How do we handle the situation where the employee quits his position, where she has used her own phone, or where an employee’s phone is lost, or get stolen?
A great benefit of using REST, is that it’s so very cacheable – a GET-call can be cashed by all intermediaries, including the client itself, reducing the number of calls to a system and rendering better scalability.

Let’s create a REST service, says Mikael, firing up Visual Studio and creating a new WCF Service Application and simply adding the WebGet attribute (from System.ServiceModel.Web):

(Quick note: The code examples I use in this post, are inspired by the ones Mikael showed, however, they are not the exact same ones. I’ve chosen to keep some of the naming you get with the project templates, for example, to make it easier for you to follow along.)

… and declaring our service in Web.Config, making sure we add a new behavior configuration:

Also, add system.serviceModel.behaviors.endpointBehavior.behavior.webHttp:

By now, your service is accessible from a web browser. The standard format is XML, and you can easily see this – and other formats – by using Fiddler:

Fiddler

By changing the accept header to application/json, your service application will automatically return your data as JSON (because we added the “automaticFormatSelectionEnabled” attribute to our endpoint behavior):

Fiddler

To post data to your service, change the method attribute from WebGet to WebInvoke:

Then, it’s as simple as adding the header “Content-Type: application/json” to post your data with Fiddler:

Fiddler

 

Availability

To solve the challenge of availability, we could put our service on a DMZ and let that service alone access our resources, i.e. effectively drill a hole through our firewall for our service. This easily gets expensive in the long run, as you add more and more services, drilling more and more holes. Another option, is to use a different type of binding – a relay binding – and let Azure tunnel the calls to your service:

Availability Challenge

Through the Windows Azure Service Bus SDK (which is available through NuGet), we get access to the *RelayBindings. After adding your bindings, we can create a public endpoint in the Azure Management portal.

… and then add an additional binding to utilize the service bus as follows:

Azure Service Bus Cost

 

Now, the Service bus doesn’t have a user database of its own. Instead, it is relying on the Access Control Service to manage identities. So to access our service via the Service Bus, we will have to first visit the ACS and ask it for a valid token for our realm (our service). The token that is returned, we then attach to our service call as an HTTP header:

Introducing the ACS

Federated security

If we have an existing Active Directory that we want to be responsible fo authenticate our users, we need to turn on ADFS, which lets the AD act as a Secure Token Server, issuing tokens in the SAML format (more about that here). Having enabled ADFS, we can now call our on premise AD (through, for example, a relaying service), or our AD in the cloud, ask for a token for our resource (our local service address) and then ask the ACS for a valid token for the service call itself:

With an AD

 

Quick note: The ACS will remove the authorization header when it calls your service, so if you are relying on claims that you retrieved from your AD (e.g. group memberships), you will need to add the authorization token a second time with another key value (for example “MyAuthorization”). However, this may cause your header to overflow, so be selective of what data you promote.

Clients

To let a variety of clients connect to the service backend, Mikael built a client library based on the – recently made portable – HttpClient. See the TokenHelper class in the example code for details.

Having a rigorous backend in place with proper authentication, adding clients is a breeze. Mikael demonstrated an ASP.NET application utilizing the backend, followed by a short demonstration of Xamarin Studio on his wife’s Mac, accessible via TeamViewer. Another option, is developing on a Mac directly (accessing Visual Studio, when needed, through VMWare or Parallels). Using MonoTouch.Dialog, Mikael easily created a declarative UI for the data his service returned. Since Mono (which the Xamarin products are based) is a binary-compatible implementation of the .NET Framework, sharing code between Windows and any Xamarin supported platform, is a breeze.

Summary

I enjoyed Mikael’s presentation and learnt a lot with regards to the Azure Service Bus and its relaying capabilities. I still need to dig some into the Active Directory Services and the federated security bit, but after the session, I’m inspired to do so.

Slide deck: SommarKollo – Enterprise Mobility
Code Samples: SommarKollo – Enterprise Mobility – DEMOS

 

 

 Scroll to top