Web-based and HTTP Solutions

I constantly hear software requirements dictating a web-based application for enterprise public sector applications.  However, I seldom know whether they are demanding the application run in a browser, which is the standard interpretation of web-based application, or whether they are referring to the data transfer protocol that typically binds business applications indirectly to their databases.  I think it is worth exploring the technologies available with HTTP applications since the traditional definition of web-based applications dealing with HTML, CSS, Javascript, etc., are become somewhat blurred with XML markup technologies, such as XBAP and technologies that offer many of the traditional web-based benefits, such as APP-V and RemoteApp.

I worked on the development of all types of applications, including browser-based, desktop, and mobile applications.  Lately, the backbone of all these are typically web services layers, ReST and SOAP, and for the most part run over HTTP with TLS.  SOAP is essentially an XML-RPC, and as such, is not constrained to HTTP.  My usual response to “I need a Web App” is “Okay, why exactly?”  I typically get roughly the same five responses, and usually just the first three:

  1. accessible anywhere
  2. single point of maintenance
  3. no installations
  4. flexible hosting options
  5. platform agnostic (hardware and software)

While these are logical and intelligent requirements, they are in no way confined to a browser, except maybe the last and even that is changing.  In addressing requirement (1), one can build a desktop, mobile, or hybrid application (like XBAP) that runs over HTTP (which is synonymous with accessible anywhere because firewalls don’t tend to block port 80).  Click-once and other attendant-free installations take care of (2) and (3), not to mention server-based deployments, such as Microsoft’s APP-V or RemoteApp.  I would even argue that enterprise business web applications which are publicly exposed require more maintenance, if only from a security standpoint.  The fact that requirement (1) is met practically implies (4) is met also.  And that leaves (5).  While IT systems professional are certainly excited about iOS and Android technology, how many are exited about having to support and maintain them in the scope of their network and systems security operations?  I’ve talked with many and most are apprehensive and guarded, at best.  With Windows 8 (and soon to be 10) providing a nice mobile OS on top of some excellent hardware choices, mobile options for Windows-based systems administrators wanting integrated domain-based security while in the office is getting easier.  Not to mention there are nice free RDP solutions in both the Android and Apple app stores.

Other considerations that I deem important for governments, but which do not receive much attention are:

  1. secure data
  2. ownership and physical possession of data
  3. natural disasters, loss of internet, and disaster recovery

Now the third point cuts both ways.  Obviously, if a disaster strikes your data center you have problems, but that is true of any data center.  Offsite backup is always a good idea and you can bet hosting providers do it.  My main point is that our local area networks are more reliable than our bandwidth and connection from our ISP (for most us IT folks).  A couple other items I think are worth considering is application performance, speed, and integration with other resources on your network, such as Active Directory, file shares, and other 3rd party systems local governments inevitably need to integrate.  But to be fair, most system integrations today leverage web services.

It is not that i do not see a need for web-based applications, but that i see more applications pivoting toward web services.  Whether or not it loads in a browser is more of a platform agnostic requirement than an accessibility requirement.  If you want more information on our product line, including our web-based products, please visit our website.

What are your reasons for a web-based application requirement?

Developing with Office 365 in Mind

There has been some significant press around Microsoft’s cloud-based Office 365 subscriptions and I have talked with local government’s IT staff who are planning to make the move in the near future.  Office 365 has obvious costs, deployment, and support benefits, but what does it offer from an integration stand-point?  Office 365 provides a few subtle advantages, from cross-domain document sharing to providing a secure offsite environment for hosting business applications.  Though on the surface neither of these are a unique advantage of Office 365 (other than being the brand name solution).

While there might be some ground-up considerations when developing with Office 365 in mind, the core technologies provided and APIs used with Office 365 remain constant from your Servers on the LAN to ones in the cloud.  Namely, the big three Office 365 Servers, SharePoint, Exchange, and Lync provide the same Web Service APIs and SDKs, so not much code should have to change from the technology integration side.  Arguably, the single most important benefit in leveraging Office 365 is the ability to secure access to these server technologies for a minimal cost.

One of the main restrictions of the Office 365 environment is that the solution is sandboxed.  As a developer working within a sandboxed SharePoint solution, a few things to keep in mind are :

  • access to the hard drive is restricted
  • assemblies need to be at least at partial trust
  • web service calls outside the site collection is restricted
  • be careful of over consuming server resources

Silverlight allows some flexibility with external web service calls, and LINQ and the client-side objects for SharePoint are still great tools for the developer.  And yes, Exchange Web Services (EWS) still provides access to user calendars and inboxes.  The Lync API allows integration with instant messaging, desktop sharing, and file transfers.  For the developer, there are some good resources for recipes and ideas, one of which is the Microsoft Office Developer Center.  For more information on our solution offerings, please visit our website or email us.

What advantages do you see in Microsoft Office 365?

Benjamin Davenport, MCSD, MCAD, MCP
Software Division Chief