The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Infuziasm
Matt Nicholson talks to on board info about how it is using Microsoft technologies to access digital diaries.
Author: Matt Nicholson
Last updated: Apr 2002
Business models Design decisions Choosing the language Programming the client The architecture behind Infuzer
Using XML Working with .NET My Services
The idea came to Ray Eitel-Porter, now chief executive officer of
on board info limited, in 1995 while on holiday with his new Psion Organiser: "The diary didn't have Christmas Day or Easter in it. I had to borrow a paper diary to find out when Easter was and then type it into my electronic diary, and it struck me as a bit of a waste of time. There had to be a better electronic way of getting such information into the diary."
A year and a half later Ray had persuaded The Economist to release a CD-based product called The Economist Diary Companion. This allowed users to have business events, sports fixtures and so forth entered automatically into their electronic diaries. However, it soon became apparent that the means of delivery was more important than the information itself: "Ultimately the information is relatively easy to commoditise, and that's not where the value is. The value is in how you deliver it."
This became particularly apparent during talks with partners towards the end of 1999, when it became clear there was a market for a service that partners could offer free of charge from their web sites, having licensed the technology from
on board info. Jeremy Ruston, chief technology officer of the company, joined at the beginning of 2000: "Jeremy immediately saw this was about more than just putting dates and events into calendars. There's an opportunity here to make it into an open conduit for taking anything from an Internet site and putting it into a local application."
Jeremy takes up the story: "The key thing is that we're providing an infrastructure for sharing, creating, organising and distributing discrete items of information into the application context that makes the most sense. We didn't want to make an application that was a destination. You never have to go to our application to do anything aside from configuration. We ride on the back of applications that people are already using."
The result is Infuzer. Go to a partner site, such as Manchester City Football Club, and you will see the Infuzer icon displayed against match fixtures. Click on the icon and, if you haven't already done so, you will be invited to download the Infuzer client appropriate to your PC or mobile device. Once that's done the details of the selected match will appear at the appropriate date and time in your device's calendar, whether it be Microsoft Outlook, Lotus Notes or a range of other supported applications. Furthermore, if the date or time of the fixture is changed, you will be informed automatically.
An important point is that all interaction is
initiated by the user. The company conducted quite a bit of research into the
psychology surrounding the use of calendars. Ray told us, "People made it clear
that the calendar is a very private thing. Their email inboxes had been
junked by all the spam, and they're not going to let that happen to their
calendar. On the other hand, once you do overcome that barrier, because
someone actually does want to get something in their calendar, you've
established a very personal relationship because you've found a way into
that trusted environment."
Also important is that Infuzer puts
information into its relevant context, rather than requiring the user to
open a web browser and browse to the relevant site. Ray explains, "For
example, you've decided that you really need to understand what the weather
is going to do tomorrow. You can go and open your web browser and go off to
a web site and find out, and that's great. However the context in
which you want to know about the weather is usually when you're working in your diary, so it makes more sense to actually have the weather displayed in
your diary, without forcing you to switch the application." This
becomes particularly important with smaller devices, such as PDAs, where
it's not so easy to have more than one window open at the same time.
Under the current business model the information itself is supplied to end
users free of charge, and the necessary client software is a free download
from the Infuzer web site. However partners are now looking for ways to
charge their users for Infuzer content. As Ray told us,
"Everyone we talk to is looking for ways to charge the user for content
delivery on the Internet, but it's very hard to charge someone tomorrow for
something you give to them free today. The beauty of Infuzer is that you can
charge someone for the delivery mechanism. It becomes an added service,
offered by the partner, rather than something the end user has already had
for free. We can give our partners a new revenue stream."
Initially on board info offered a free
weather feed, downloading five-day rolling forecasts every four hours into
the end user's calendar, which gave people a reason to install the Infuzer
client. However the company has now started charging for this service. Jeremy explains:
"Like everyone else we're wrestling with the lack of a workable
micro-payment mechanism. We're doing three things: you can pay on the web
site by typing in your credit card details; you can call a national-rate
phone number and give your credit card details by phone; or you can call a
premium rate telephone number which costs £1.50. We get a chunk of that, as
does our referring partner. It's an incredibly convenient way of paying, and
you can apply it to other content right down to 25p. It also doesn't have
the security worries - after all, it's just a premium rate phone call."
(See www.weather.com for further
details.)
Like most companies, on board info took a pragmatic rather than an evangelical approach when it came to platforms and technologies. Data is handled by SQL Server 2000 running on Windows 2000. Middle tier logic is implemented
as Java Servlets and served up with JSP (Java Server Pages). However this is achieved using the Resin servlet engine running on Microsoft Internet Information Server under Windows
2000. Jeremy:
"Initially we wrote to a very conservative subset of SQL Server so we
could migrate to Oracle at a later date should we wish. We were running Apache on Windows
NT4, again on the basis that it would permit us to migrate to Unix later.
However now we use IIS, partly because it makes it easier for us to integrate with
Passport, and IIS is very flexible."
The SQL Server database contains tables of
events, users and partners which are combined through the profiles of the
users. As Jeremy told us, "It's maybe 70 tables and 150 stored
procedures, all rigorously managed. All application access is through stored
procedures - we don't do any table-level access."
Jeremy continues: "We don't maintain any session data on the application servers ? everything is persisted to the database. It's one of the best decisions we made. There are a lot of third-party solutions to session management, and we even thought about building our own. ASP.NET now does it quite well, but in my opinion middle-tier session management is a sop to inexperienced programmers because it supports a conventional way of writing programs. If you have a clean sheet of paper, and you have enough self discipline to persist everything to the database, it makes the app infinitely scalable."
Currently Infuzer only uses a single box for SQL Server but, as Jeremy points out, it would be fairly straightforward to add further boxes as the need arises while maintaining its appearance, from a programmer's perspective, as a single database. Middle-tier boxes can also be replicated: "The only consequence of having 80 application servers instead of 2 would be more database connections, so you scale the database."
They chose Java for the middle tier because they wanted to use a modern
programming language which would allow them to express their application
with a suitable level of abstraction and elegance. Previous experience had
led them to believe it would be impossible to write the whole application in
ASP, which in January 2000 brought the choice down to Visual Basic, C++ or
Java. Jeremy explains:
"Visual Basic is a lovely language, but
we were anticipating Infuzer to be of a scale where it would have been
ridiculously inefficient. The limitations to its expressiveness are obvious:
VB6 was not, as far as I am concerned, an object oriented language -
although of course it is now in VB.NET, which Microsoft has implemented very
nicely.
"C++ is a nice language, but it's very
unforgiving and has a clumsy object-oriented model - a hodge-podge of ideas
from different sources which lacks a kind of elegance that we thought was
important. A lot of C++ programmers were trained a long time ago, and are
frankly not as good software engineers as the Java guys. It's a matter of
age I think. The C++ culture is a classic structured programming mentality,
not withstanding the object-oriented features they've added with C++. Java
clearly delivered on all of those things, so it was a very easy
choice."
However Jeremy continues, "If we were making the choice now it would be much more difficult. We regard C# and the CLR as being more modern than Java. There are features in C# that we really like.
"The classic example is attribute handling, combined with reflection. In our application the core data item is something we call the
Fuzicle. This is a generic super class, so there's an Events Fuzicle that's a derivation of the
Fuzicle. We wanted to write as much of the system as possible to cope with as yet unanticipated
Fuzicles, so the obvious solution was to put the common Fuzicle properties in the base class and the time-specific ones, such as start and end times, in the sub class. However it then becomes very hard to write polymorphic code.
"Our solution was to work at a higher level of abstraction, so our Fuzicle object maintains a key-value dictionary of all the properties which allows us to enumerate through them and write extremely polymorphic code. But it's dead clumsy! In C# we could have implemented all that much more directly, because we could have decorated each property with enough metadata to tell the system how to deal with it, even if it's never encountered the property before. In C# you can express that very clearly and purely. Although the reflection code can get less pretty than you might like, it's still way more direct than the equivalent in
Java.
"So now we would probably choose C# for
the very dull pragmatic reason that we would be able to interoperate with
VB.NET, which means we could hire VB programmers, and there are some
extremely good VB programmers out there. There's a whole load of technical
factors, but when you're actually running a business rather than a research
organisation it's the pragmatic commercial things that end up dominating the
decision."
"The truth is that language skills are
transferable. Developers are primarily designers, although clearly a huge
part of their talents lie in the tools they're comfortable using. I'm
completely confident that if we turned around tomorrow and said, 'In 6
months we won't be doing any Java development', nobody would leave. Instead
they'd see it as an exciting opportunity to get into another field. For
some, moving to C# is going to be a philosophical problem, but that's not
the attitude we have here."
By design, it is obviously not possible to write directly into the data stores of applications such as Microsoft Outlook or Lotus Notes using JavaScript from a web page. This can only be achieved through purpose built client-side software. "You need something to bridge from the web into the application environment." Jeremy continues, "Right from the beginning the goals of the client were that it should be small and reliable, because we were concerned about download speed. We immediately realised that C++ was the only way to go."
Initially on board info concentrated on the desktop PC, relying on the updates being transferred to a wide variety of mobile devices through synchronisation mechanisms such as ActiveSync. Jeremy: "We all know that from a design and a testing point of view it?s the number of entities that you deal with that's really important. It's not necessarily harder to test 1,000 lines of code than 100 lines of code, but if that 100 lines of code interacts with 15 web services, you've got a testing nightmare. So we were very happy to avoid having to write clients for individual
PDAs."
However the increasing popularity of wireless technologies has opened up opportunities to update mobile devices directly, which led the company to explore the various mobile platforms available. "In doing that, you discover that the Pocket PC is a fantastic programming environment. It's familiar, it's like Windows, it's like a real operating system. A nice environment, and Windows CE is really cool as an operating system. Symbian is a nice operating system, but without as many bells and whistles. Palm is not so straightforward ? there's very little encapsulation and you're very aware you're programming for a 16-bit device."
The company started programming Windows CE with eMbedded Visual C++ 3.0. However Jeremy's team has also been investigating the .NET Compact Framework. "The attraction is that you can share code. For instance we can have exactly the same Fuzicle class running on the desktop PC, the PDA client and the server which gives us a potential advantage in testing. We can test a class once to exhaustion, and be reasonably confident it's going to run properly on the other platforms as well.
"We've found the integration with Visual Studio .NET is fantastic. It's an incredibly productive environment. The implementation of the CLR seems to be utterly solid. When you install the Smart Device Extensions for Visual Studio .NET it installs a whole bunch of extra wizards, so that when you open 'New Project' you can select 'New Pocket PC Application' or 'New Handheld PC Application'. As ever with Microsoft, developer productivity is absolutely tip top."
However new technologies bring new issues: "Inevitably the .NET Framework is a subset on the Pocket PC, and a big issue for us has been deciding whether it's worth bifurcating to take advantage of the increased capabilities on the desktop, and doing a specialist version for the Pocket PC, or taking a lowest common denominator and writing within the limitations of the PDA device."
On the server side, although the company is looking at J#, there is no obvious business case for moving the system to .NET in the near future. However, they have added a .NET box in parallel to the existing Java servers that talks to the same database and shares the same session information. "Careful management has enabled us to seamlessly merge ASPX pages and JSP pages. That means right now, if there's something that's best done in .NET, we can. It gives us a great deal of flexibility."
Although the initial intention was for partners to deliver event data as XML, Jeremy's team quickly realised this was not the best approach, "Not because they're half witted, but because they're locked in to a development cycle that means a far reaching architectural change is not something they can frequently contemplate." Instead, partners can choose from a variety of options, ranging from a full-blown web service to comma-delimited text files.
Alternatively, the partner can simply use GET style parameters to transfer the event details.
When the user clicks on the Infuzer icon, the Infuzer server checks for a
cookie to find out whether the client software has already been installed.
If it has, the server extracts the event detail from the URL and returns
them as an XML file with a custom filename extension. This filename
extension causes the browser to invoke the Infuzer client and pass it the
XML data for processing. If the cookie doesn't exist then the user is
directed to an HTML page prompting them to download the client.
Using this technique, if the partner has an event listing that's generated from a database using ASP, the site can be Infuzer enabled in a couple of hours. Jeremy explains, "It doesn't take more than one sheet of A4 to explain to a software engineer what they've got to do."
So for on board info, the emphasis is
on XML as an internal data transfer mechanism, rather than as a way to facilitate interoperability with partner systems.
"Partners can deliver us updates as XML, but they often choose to give
us comma delimited files because that's what their infrastructure is set up
to handle. As developers we're very focused on technologies that have come
out in the last three or four years, but when you're dealing with other
companies you can't assume they've got to grips with XML - that they've
mastered the character encoding issues with XML, for instance. That was a
pivotal insight on our part, vindicated by the number of sites that we've
Infuzer-enabled in a ridiculously short time."
One stumbling block to the adoption of Infuzer is the need for the client
download. Some people are nervous about software downloaded from the Web,
while many corporates prohibit end users from installing software at all.
Web-based calendars provide an obvious answer, although so far they have not
taken off, and the company has seen little reason to support Yahoo or MSN
Calendar. However Jeremy is excited by .NET My Services.
"Commercially it was obvious that we
needed to check this out so we joined the Early Adopter programme, and it
was a thrilling transcendental moment when we finally got to see the
implementation. It's cool and it's all written in C and C++. The development
team is led by one of the original Windows NT designers and he's a 'code it
tight, code it small' merchant.
"Better than that is the programmer
model. They capture everything in one big XML document, and then give you a
kind of RPC-DOM to manipulate it, and it's very well thought out. The
techniques you use to remotely manipulate what's actually a very large and
unwieldy object model are standardised so they work across all the different
services. It's a beautiful approach. What's nice is that it's declarative:
you don't send up bits of code that procedurally manipulate the services
on your behalf; instead you interact directly with the object model using
XML. It's completely the right way of doing it, and they're using custom
lean-and-mean XML parsers which make it efficient, to boot.
"Initially we assumed we'd be adding a
.NET module to the system that would talk to .NET My Services, but by far
the easiest way for us to get up and running turned out to be having
our Java code talk to .NET My Services. Once we realised that it took us
about three days to get it up and running to the point where it was doing
something, and about two weeks to get it to the point where it was doing
pretty much everything we needed. The way it works is that when you click
for the first time on an Infuzer link and are prompted to register and
download, you are also given the option to identify your .NET My Calendar
and infuze into that.
"It's frustrating that .NET My Services
won't now see the light of day in the form Microsoft originally intended.
It'll be very interesting to see how they rejig them."
Click here for Jeremy's views on team and project management
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
Project management
