Some of the most useful products arise out of solving very specific problems and realizing that the solution you came up with would be useful to other people with similar problems. That’s how the Sybase Relay Server came to be.

Background

In the fall of 2000 (almost 10 years ago as I write this) I was working on a now-defunct product called the iAnywhere Wireless Server, or iAWS for short. The mobile web application market was in its infancy and iAWS made it easier to build wireless web apps that integrated with databases and other enterprise-class backend systems. This was back in the day when WAP and WML were the hot things and the idea of running full-fledged applications on a mobile phone was a dream, not today’s reality.

Anyhow, one of the biggest problems with wireless development was that we couldn’t access our desktop computers from the phones we were testing with. The company firewall made it impossible. So what we did was arrange to get a couple of computers placed outside the firewall on a separate Internet connection arranged just for that purpose.

That worked, but it was very awkward to use. Essentially you had to use remote desktop to connect to the outside computer from your desktop, copy the files you wanted to test to the computer (or create/edit them in place), and then run your tests by having the mobile phone connect to the outside computer. It worked, but as I said, it was awkward. Also, we only had one computer outside that developers could use, the others were reserved for product management and the sales team (so they could demo stuff — they had the same access problems), and that led to contention.

The HTTP Relay

After suffering through this process, I decided there had to be a better way to do things. All I really needed was a way to access the local web server running on my desktop computer with HTTP requests from outside the firewall. Then I could make changes locally (with my text editor) and test those changes immediately on my mobile device. No copying files back and forth and no remote desktops to fiddle with. Even looking at log files would be simpler. What I needed was a simple HTTP “relay” that could cross the corporate firewall and let me do what I needed to do.

I wrote a simple Java program called HTTPRelay that could be run in two modes. In external mode it would open two server sockets, one listening for incoming HTTP connections from mobile devices (or any browser, really) and one listening for a connection from another copy of HTTPRelay. Any data received on one connection would be automatically relayed to the other. In internal mode it would open an outgoing socket connection to another copy of HTTPRelay and an outgoing connection to the local web server. Again, any data received on one connection would be relayed to the other.

HTTPRelay ran on the outside computer (the one outside our firewall) in external mode. You ran a second copy of HTTPRelay on your own desktop computer in internal mode. The two relays shared a socket connection, which the internal relay initiated in order to cross the corporate firewall.

You connected to the external relay from your mobile phone. The HTTP request was relayed to the internal relay, which in turn sent it to the local web server. The response was relayed back from the internal relay to the external relay and back to the phone. To the phone, the external relay was a proxy server for the web server running on your desktop computer. It was seamless.

I had the system set up so that up to 8 developers could simultaneously do mobile web development, each on their own computer, simply by assigning different port numbers to different developers. It wasn’t a very sophisticated system, but it worked, and it saved us a lot of hassle.

Today’s Relay Server

Fast forward a few years and things haven’t changed that much. Anyone doing mobile application development (browser-based or not) runs in to the same kind of firewall issues. While the Sybase Relay Server is a completely different product than the HTTPRelay I hacked together one day, the basic idea is the same: run an external relay and have the internal data servers connect to it using outgoing socket connections. Use HTTP as the transport protocol, make the relay server robust and scalable, and everyone’s happy. That’s why MobiLink, Afaria and Mobile Office all use the relay server — see the Sybase Relay Server whitepaper for details.

When you think of RFID, do you think of packages quickly whizzing through a set of conveyor belts and being automatically directed to the right loading dock? As each package moves past an RFID reader, an RFID tag attached to the package identifies the package to a computer system that controls where the package goes. That’s a pretty typical use of RFID — the “Wal-Mart scenario”.

But what if you reversed things? Instead of the tags moving past readers that were fixed in place, what if the tags were (mostly) fixed and the readers were the things that moved? That’s what we call “mobile RFID”.

The Case For Mobile RFID

There’s a real need for mobile RFID, actually. Let’s say you want to take an inventory of the assets in your warehouse. Does it make sense to take each unit out of storage, move it past an RFID reader, and then return it to its original location? Of course not! It’s simpler and faster to leave the units where they are and move the RFID reader to them.

In mobile RFID applications, the reader moves, not the tags. The reader may be mounted on a forklift. Or converted into a handheld device.

A computing device is often associated with the mobile reader — typically built on either Windows CE or embedded Linux — allowing RFID tags to be processed intelligently (and locally) by on-board applications. Or the data is transmitted, perhaps in a batch, to a backend system using a wireless connection.

Mobile RFID and RFID Anywhere

Mobile RFID support is built into RFID Anywhere, our RFID middleware software. You can use to build RFID-enabled mobile applications that run on devices like the Motorola MC9090.

Or you can simply use the pre-built mobile agent to collect RFID data on the device with no programming at all. The mobile agent transfers the data directly to RFID Anywhere for processing. It’s a simple solution for mobile RFID data capture that is useful in a number of situations.

You can get more details about RFID Anywhere’s mobile support in the whitepaper Getting The Most From Mobile RFID With Middleware.

I’ve been reading Inside the Tornado by Geoffrey A. Moore and I wanted to share with you his take on how engineers view marketers:

Marketing, in the engineering universe, is that place where the laws of utility are suspended. They are of two minds about this. On the one hand, if painting the product red sells more product, by all means paint it red. On the other hand, since there is no rational cause operating here, you cannot trust marketing, as anyone can see for themselves, since sometimes when they paint it red, it does not sell more. So marketing is essentially voodoo. It is for flakes. It is not a real discipline. It is a con job.

Ouch! Not the most flattering description, is it… but there’s a lot of truth to what he says — just read a few Dilbert comic strips and you’ll see!

What’s interesting is that he says there’s a way for engineers to understand marketing’s critical function:

… it helps engineering considerably if it can conceptualize marketing as a systems discipline. In this frame of reference, markets are economic systems, and the role of marketing is to facilitate the transfer of money from the market into the company by ensuring that the company is delivering value out to the market. It is a systems-level exchange that obeys the laws of equilibrium. If either side of the system lacks what the other needs, the exchange does not happen. But when the right pairings meet up, it does. Defining who our right customers might be, and what value they might want, and what … product … we can provide that delivers that value — all this is the new meaning of marketing.

Oddly enough, my wife is teaching a high-tech marketing course this summer to fourth-year business students. It’ll be interesting to see what the marketers think of all this.

In RFID For Beginners, I gave a quick overview of RFID, which is short for radio frequency identification. If you recall, I pointed out two of the issues that RFID developers encounter: too much data to process and too many devices to deal with. That’s where RFID middleware helps.

Why RFID Middleware?

Middleware refers to software that acts as intermediary between two or more other pieces of software. It’s typical, for example, to have middleware that sits between a web server and a database — such middleware is often called a web application server. We here at Sybase iAnywhere are no strangers to middleware — we have the market-leading mobile middleware platform, after all.

RFID is a perfect place for middleware, as it turns out. Those two problems I mentioned before — data volume and device management — are mostly solved using middleware for RFID:

1. Data volume — The middleware can take the continuous stream of data broadcast by a company’s RFID readers and transform the flow of data into something that is manageable and actionable. It does this by filtering out duplicate and erroneous data and transforming the remaining data into useful business data. Many RFID tags, for example, store little or no information about the “thing” that was tagged. That information has to be pulled from a separate database. RFID middleware can easily do this and transform the raw tag data into real business data.
2. Device management — By sitting between the business applications and the devices, RFID middleware separates the management and configuration of those devices from the application (which is good) while still providing a central point of management for IT personnel. Well-designed middleware also makes it possible to support multiple types and vendors of RFID hardware — an important advantage when dealing with such a fragmented marketplace.

All the reasons that make middleware so popular and valuable also apply to RFID installations. That’s why we designed RFID Anywhere to be the perfect middleware for RFID.

You can even write simple RFID applications with no or little programming, that’s how easy we make things… More on this in a later post.

One of the hats I wear is managing a small team of developers working on RFID Anywhere, our RFID middleware product. What, you didn’t know that Sybase iAnywhere had an RFID product? Not a problem, I’ll be happy to give you some details. First, though, let’s talk about RFID.

What Is RFID?

RFID is short for radio frequency identification. The idea is simple: encode information into tiny radio transmitters (known as tags) and physically attach them to something you want to track or control. That something could be a crate of parts, an individual article of clothing, a truck, a bin, etc. etc. — the possibilities are endless. Place radio receivers at strategic locations throughout a building, or in vehicles, or even on handheld devices. When a tag comes within range of the receiver (known as readers) then you know when and where you saw the “something” the tag represents. Send that information across the network to a central server and process it.

There’s a lot more to RFID than what I just described, of course. The engineering aspects of RFID — how information gets encoded on the tags, how the tags respond to the readers, the protocols the readers use for external communication — are quite complex and beyond anything we’ll discuss here. But they’re used to solve real-world problems. Tracking assets is the most obvious use of RFID, but RFID can also used for authorization and authentication purposes — that security badge you’re wearing is a good example. RFID technology is finding its way into all kinds of interesting scenarios.

So Much Data!

At its simplest, then, RFID is a means of automated electronic data capture. It’s faster and more efficient than using bar codes or humans to capture the data. But it also can generate a lot of data. I think the Police (this dates me!) said it best: “Too much information, driving me insane.” As a crate travels past an RFID reader, for example, that reader will “see” the associated tag multiple times per second. Or if two readers are in close proximity to each other, they may both “see” the same crate simultaneously (known as a cross-read) because of the physics involved.

Managing all that data is one of the challenges of RFID programming. You have to be able to process data quickly while filtering out extraneous and/or irrelevant information.

So Many Devices!

One thing you’ll soon discover is that there are many, many vendors of RFID hardware out there. And we’re not just talking readers, either. Many readers are also writers, because some tags let you change the data that’s stored on them. Then there are RFID printers, too, for creating new tags.

You’ll also discover that there are many different standards and protocols to choose from. Everything from the frequency range that the tags and readers use to how the data makes it from the reader to back end data systems varies from system to system. The latter aspect is what really makes it hard to mix-and-match hardware from different vendors, although the LLRP protocol will help in the long term. Configuring different devices is also a pain.

RFID Anywhere To The Rescue

So much data, so many devices… this is why we created RFID Anywhere. More on that next time!

Monday’s announcement of Oracle’s acquisition of Sun Microsystems is surely causing some grief at IBM headquarters. Sun was IBM’s to lose, and looks like that’s what they did.

Still, IBM is a big company and they’ll weather this storm. The more relevant question is what will happen to all the MySQL users out there today? Probably more than a few of them are now wondering if there are credible alternatives to MySQL. (There are, especially the free web database version of SQL Anywhere.)

The demise of MySQL is far from certain. After all, every LAMP-based web hosting service (which means most of them) offers MySQL support — it’s the “M” in “LAMP”. You don’t need a commercial license to use it this way: MySQL is currently free for web app use as long as you’re not distributing the application itself. (Technically, you’re using the GPL-licensed version of MySQL when you’re building a web app.) I certainly don’t see this changing overnight: even if Oracle decided to stop offering or supporting the GPL-licensed version of MySQL, it will continue to propagate “out in the wild” no matter what. (I wonder how many forks of the source code happened since Monday?)

The name “MySQL” may take a different path, however. Oracle may decide to strictly control who can use the MySQL trademark and add “Oracle” to the front. Thus “Oracle MySQL” would be the official version of MySQL going forward. Everyone else would have to find a new name for the product.

Expect to see enterprise developers look for alternatives (like SQL Anywhere) going forward. The web developers won’t be in such a hurry, though. Interesting times, indeed!

… and the unmarried ones can do it more often, because they have more time.

Do what, you ask?

Post to their blogs, of course! What did you think I meant?

The biggest challenge that any blogger faces is creating content for their blogs. Getting the blog up and running is really quite trivial in comparison, especially these days when most hosting services offer single-click (almost) installation of WordPress. Sure, you’ll spend a few days finding and tweaking the right theme for your blog and installing useful plugins, but the hard work only begins after you’ve made the first post.

Corporate blogging is perhaps even more challenging in this respect, because the blogging isn’t usually a formal part of the blogger’s job description. When you’re blogging at home, it’s often because it’s a passion and you find ways to make the time to blog. Blogging at work, though, can seem much harder because you have to find time in your already busy workday to post something meaningful and interesting to your blog.

Here are some strategies you can use to make corporate blogging easier:

• Limit yourself. Don’t post too frequently. Restrict yourself to two or three posts per week. Your readers are likely busy themselves and probably won’t have time to read daily posts, anyhow. One post at the start of the week and one at the end seems to be a good compromise for everyone involved.
• Set aside time for writing. Blogging is writing, something that a lot of people gloss over. Good writing takes time. If your posts are going to be meaningful and interesting, you need to spend some time on the content. Try to dedicate an hour or two per week for content creation.
• Keeping a running list of topic ideas. Keep track of ideas so you’re never scratching your head for a next idea. Use whatever works for you… a word processing file, self-addressed emails, pen and paper. Just keep a list, and keep adding to it. You’ll want to keep the corporate angle in mind, of course, so keep an eye on company news, you’ll often find interesting nuggets in those on which to base a new post.
• Share the load. If running a blog by yourself is too daunting, find another author or two to share the posting duties with you. This can work well with product-oriented blogs like our mobile device management blog.
• Plan for busy times. If you know you’re going to very busy, or on vacation, write some content ahead of time and use your blog’s scheduling feature to post it at normal intervals.

Don’t kid yourself that blogging is easy. Frequent blogging is especially hard if blogging’s not your full-time job. I once tried posting new content to one of my blogs on a daily basis for a month, and it was very hard. You need to find the right balance. And posting on a regular basis, no matter how infrequent, is better than not posting at all.

I’m going to start with a post about mobility, specifically the disconnect between the terms “mobile” and “wireless”. They’re often used interchangeably, but they’re not the same, and that can lead to some confusion. Let’s see if we can distinguish them from each other.

Mobile != Wireless

Mobile refers to the concept of mobile computing — the ability to use computer applications from portable computing devices. Mobility is really an attribute (and a need) of the user, not of the device, even though you’ll see the devices referred to as “mobile devices”.

Wireless refers to network connectivity that is free of physical connections — there is no wire connecting the computing device to the broader network. Wireless is an attribute of the device, not the user.

When you distinguish the two terms this way, you can see that they are not the same and in fact they combine together in different ways:

• Mobile Wireless: What people generally consider to be “mobile” or “wireless” — a mobile user with wireless connectivity, think iPhone email on the go.
• Mobile Non-Wireless: A mobile user without wireless connectivity, like the meter readers collecting utility usage information.
• Non-Mobile Wireless: A non-mobile user with wireless connectivity, like a desktop computer in the family room connected to the Internet via a wireless router.
• Non-Mobile Non-Wireless: A non-mobile user with physical connectivity, like a desktop computer connected directly to the cable/DSL router.

The combinations of interest for this discussion are mobile wireless and mobile non-wireless. Both have their challenges.

The Early Days: Disconnectivity

When we released SQL Anywhere’s UltraLite mobile database technology in the late 1990s, mobile non-wireless devices like the original PalmPilot were dominant. These very limited portable computing devices only had network connectivity when they were tethered to a desktop computer, typically by “cradling” them into a special-purpose connector (the “cradle” — since replaced with USB cables) that also recharged the device’s batteries.

Because such devices were normally disconnected from the network (we called them occasionally connected devices), applications had to be written to work in a network vacuum. Tracking and safeguarding on-device data was paramount, because you wouldn’t want any data to be lost or corrupted while the device was disconnected. And when the device was reconnected to the network, you needed a way to get that data off the device and into the databases and other backend systems your company used. By creating a fully relational database system with transactions and integrity checking and supporting the robust MobiLink data synchronization model, UltraLite was perfectly suited for building data-intensive mobile applications for disconnected devices.

The Wireless Trap

Nowadays, most mobile devices include wireless connectivity, but the need for technologies like UltraLite and MobiLink hasn’t diminished. Just because you can stay connected to the network doesn’t mean you want to use that connection, for the following reasons:

• It costs you money — when your data plan charges by the kilobyte, you want to keep data transfers to a minimum.
• It uses the battery — the more often you use a wireless connection, the sooner you’ll have to recharge the device.
• The network is slow — even the latest 4G networks won’t perform as fast as you’d expect.

That last reason brings up an important point: what happens to your application when there’s no network coverage available? Don’t scoff, it’s not an unusual situation: if a worker is moving in and out of buildings or driving out into rural areas, data connectivity may be very erratic.

Always Working

This is why we still find there’s value in taking disconnected application operation into account when designing applications for mobile devices. AJAX-style local user interface logic isn’t enough.

Unless your application is truly an online-only application (and those certainly exist), it’s best to plan for disconnected operation right from the start. Use wireless connectivity when it’s available, and when it makes sense. But ask yourself this question: will the application still work when there’s no network?

That’s the real disconnect between “mobile” and “wireless”: people think they need a mobile wireless solution when in fact they need a mobile non-wireless solution with optional wireless connectivity. They need an application that always works, with or without the network. It’s harder to write applications that work without network access, but I can assure you that retrofitting a wireless-only solution to work in a disconnected manner is even harder.

Is there a disconnect in your mobile application strategy? We’ll revisit this topic in the future when we look at mobile application architectures.

So I thought I’d join the twenty-first century and give this “blogging” thing a try… Seriously, I’ve been blogging on my own since 2005, but I never had the urge to do it in my capacity as a longtime Sybase employee. Now I do. Go figure.

One of the things I liked best about being a software developer in my early years at Watcom/Powersoft/Sybase was the close interaction I had with customers. In those years I was working on rapid application development tools, first in REXX (for OS/2), then C++ and Java (both for Windows). Customers were other software developers, who were using our tools to make their jobs — typically application development in an IT setting — simpler and faster. What was great was the interaction we (the tool developers) had with these customers. They’d post problems and ask questions in our newsgroups (or mail us directly, if we had already established a relationship with them), we’d turn around and give them new software that solved their issues. It was very interactive, and messed with the product release plan. But it was very satisfying to know you were fixing someone’s problems.

I’m not saying we should go back to those “cowboy” days, not when we sell truly mission-critical software that entire companies depend on day after day to get the job done. Because that’s what we do at Sybase — we help you get the job done. Whether you need an embedded database in your applications, to manage your iPhone email and integrate it with corporate systems, or mine terabytes of data, we’ve got the software you need.

Does that sound like marketing to you? Well, as the blog’s title announces to the world, I’m not in marketing. I’m a software developer through-and-through. You won’t see me walk over to the Dark Side anytime soon. (That’s assuming they’d want me, anyhow!)

But it’s not like marketing has the exclusive right to promote our products. It’s easy to overlook the fact that most software developers at Sybase are proud of the products they work on. So why shouldn’t we tell the world how great our software really is? We’re the ones who know it for a fact…

That’s why the Sybase blogs excite me. It’s another way for us to reach and interact with our customers without layers of insulation. Without having to be a trained PR flack.

Look at the cast of characters that’s been assembled: we have a query processing expert who can answer all your obscure (and yet important) questions about why database come up with the results you see; a mobile banking evangelist who understands mCommerce; and a data synchronization guru who’ll explain to you why getting data from your big backend database system down to your BlackBerry and back isn’t as easy as you might think (unless you use our BlackBerry database, of course). These are just a few of the smart people we have blogging about the things that are important to Sybase and its customers.

Now, there’s always the chance that any one of us will say something on our blogs that will get us fired. Remote, but it’s a possiblity. No one from marketing is prescreening the content. That’s just part of the excitement, I think, that comes with dealing directly with the outside world.

Unlike the other Sybase blogs, though, I won’t be focusing on a single product. You’ll see me exploring the pantheon of Sybase products. Many of those discussions will revolve around mobility, an expertise of mine and many others in the company, but they’ll also range further afield into essays on programming, recruitment, social marketing, and other fun stuff.

A parting note… John Donne said that “no man is an island” (excuse the non-inclusive language) but many bloggers live on islands of their own making. But it doesn’t have to be that way. The best blog is one that not only gets read by more than the blogger’s family, but that fosters real discussion between the blogger and his or her readers. Please leave comments on this blog, I’d love to hear what you have to say on any of the topics I discuss.

Now to come up with some exciting posts to start things off right… Don’t let anyone fool you into thinking this “blogging” thing is easy, by the way…