An introduction to the URL programming interface

Create ubiquitous controlled access to devices using UPI

1 2 3 Page 2
Page 2 of 3
  • Get the current temperature in the house: Allows you to decide whether to turn on the air conditioner so that the house is cool by the time you get home. While some of the current applications for the home are not that interesting, homes will become increasingly more automated and automation products will be available via Web sites in the not too distant future.
  • Turn on the camera and the light: Lets you see if the weather station that you mounted on the side of your house is operating correctly. If the station is collecting values for wind speed and wind direction that seem to be incorrect, you can debug this problem remotely by asking for wind speed samples and seeing what the relative movements on the weather station sensors are. Of course, this needs a cheap cellular modem chip that you can just throw onto a board such as the new TINI board from Dallas Semiconductor. I would consider 00 a good price for such a device.

    Let's look at what exactly is on this device:

    • TINI board
    • Cellular modem interface and antenna
    • Java iButton chip for authentication access
    • Web server and software for appearing as node on the Internet when called
    • RS232 parallel interfaces for connecting to various devices
    • Power line interface
    • Battery
  • Give me file MEMO.HTML: Sends you the file you forgot to grab from home this morning. Consider the freedom from worry if your home network is always online.

Up to now we have been discussing the applications and the requirements. Now it's time to consider the technology that will help us realize these applications. The UPI architecture is very easy to understand and deploy, and it doesn't rely on any new protocols in the short term; it easily supports new concepts like Jini as market acceptance continues.

The UPI architecture at its core consists of a series of handlers that are similar to servlets but have fewer features. These handlers are mapped to incoming URL requests. This allows the UPI to be put on very small devices like the TINI board. The UPI supplies a number of handlers, for things like file service, CGI scripts, and so on. Application developers can develop handlers for devices by simply coding a few required methods like init and respond, along with code that understands the device grammar you require.

In the following three sections we examine UPI access to the three devices we mentioned earlier: a Java Card-compliant smart card, a weather station, and a power line interface via X10.

UPI interface to Java Card-compliant smart cards

The request:

http://www.digiorgio.com/SecureTokenServices/VerifyPersonalCode?pin=123456
78?challenge=76458924659264

asks that a handler called SecureTokenServices process the command VerifyPersonalCode with the arguments supplied. The arguments are a PIN and a challenge. The challenge is a random collection of bits generated for purposes of implementing a challenge-response protocol. The handler takes the arguments and, in this case, generates a cryptographic signature, which it returns as a URL-encoded name value pair. The cryptographic signature was generated by sending the string to a Java Card using an Open Card service (see Resources for more information on Open Card). The cryptographic signature can then be sent to the server, which can determine the validity of the signature.

Using smart cards on various systems is still subject to errors and is expensive to deploy due to version issues and competing browser security models. Sun Labs has solved this problem by creating an architecture that utilizes the latest versions of Java and Java Card and that is independent of Microsoft and Netscape. The architecture also supports non-Java smart cards. An excellent write-up of an interface to a non-Java card can be found in Resources below. This architecture is built on the concept of UPIs that create small Web servers, which in turn get wrapped around physical or logical devices and the reverse proxy technology developed at Sun Labs and used in Sun.net.

As we mentioned earlier, the vast number of current smart card solutions on the market combines with the plethora of methods for accessing the Internet to pose a challenge for MIS and IT departments. The problem is even more acute in the consumer world. The UPI architecture solves this problem by making the client browser independent; an additional piece of technology for the server, to be discussed in later articles, has the potential to make Web servers appear to be equal in terms of authenticated access and services.

The current concept of the browser owning both the card and the API interface to the card decreases the utility of a card that only works with browser from company A or B. As much as I would like to see a browser-only world, there are still many applications that need to have access to smart cards independent of the browser. It would be better to have the resource -- a smart card, in this case -- appear as a shared resource that is available to all applications on the network, both local and remote. The core concept of UPI involves speaking to a smart card and reader combined as a HTTP stack; in other words, the reader and card look like a bunch of URLs that provide responses to queries. Normally, Web pages are disk files or data generated from programs. In this case, the data returned to you comes via proxies from a smart card reader that contains a card. The client software is called PersonalCard Services, and the server side products are called PersonalCard Service providers. Service providers provide server implementations of code that complete client requests and/or transactions that require server services.

Four large groupings of these services follow. The PersonalCard Server has working prototypes of the Web application support abilities described below.

  • Authenticated Web access: Each URL can be assigned an access control list. This control list can specify the valid authentication algorithms and process.
  • Personal Profiling: Without forms many Web applications would not be possible. Forms are an essential user interface component, yet very little has been done to make the process of filling one out automatic and secure. By using smart cards and the techniques described in this article, you can gain control of your personal data instead of trusting various machines and companies to keep it up to date for you. We sometimes refer to this personal data as personal profile data.
  • Transaction systems for micro- or macropayments: Some transaction architectures are too heavyweight for the Web when the monetary amounts are small. The smart card UPI allows everyone to transfer money from one user on the Internet to another. This could be as popular a service as instant wire transfer.
  • Virtual ATM: Why go to an ATM when you can download money directly to your smart card?

The PersonalCard Server is a minimal HTTP 1.1 server that understands URLs of the form:

http://somehost:someport/SecureTokenServices/GetId

This type of programming is an example of UPI URL that queries a handler for the operation of the GetID method. The last element in this path is not treated as a file or as a CGI script, but rather as an identifier that allows the handler SecoreTokenServices to dispatch appropriate processing. In this case, the UPI has been applied to a specific problem and can be called something like SmartCardUPI. The GetID path component returns the ID of the smart card in the reader. This approach lets non-Java programmers easily develop smart card applications using JavaScript. We have also applied this approach to other devices to control X10 power line networks, weather stations, and the implementations are called X10UPI and WeatherStationUPI, on which more below. The Sun Labs approach minimizes IT deployment costs because it allows readers and cards to be treated as addressable Web servers. These servers can be maintained over the Web using simple HTML and JavaScript macros, or using Java programs and applications.

UPI interface to weather stations

The current version of the weather station interfaces to a computer that has a Java application; this computer in turn manages the communication. We discussed this in prior articles in great detail (see Resources). The UPI allows us to build on this previous work and make low-cost, easy-to-deploy interfaces for these sorts of devices. A typical URL to get a sample would be something like this:

http://www.digiorgio.com/Weather/GetSample

The link above is real; go ahead and try it. How does it work? The weather handler is queried for a current reading. It then decodes the request and communicates with the Dallas 1-Wire weather station to get an XML sample. (See Resources for more information on this product.) It should be obvious that this process can be generalized to any device with which you can communicate from a local computer.

UPI interface to X10 power line controllers

X10 is a widely distributed protocol for controlling devices in the home. Each device is assigned a unique ID and understands a small vocabulary -- a light switch would only need to understand On, Off, and Dim commands, for instance. These units can be controlled over the power line by using an interface that typically connects to the serial port on your controller. In 1998 Sun Labs and Dallas Semiconductor developed Java-based controllers that are small enough to fit into a light switch. One of Java's strengths is its ability to take dated legacy architectures and support quick upgrading of the system to a Web-based interface that can be easier to use and deploy. The X10 UPI interface provides a URL-based interface to X10 so you can issue a command, from your browser.

For example:

http://yourhome:1000/X10/HC=10&UC=11&FC=ON

asks for a device with a house code of 10 and a unit code of 11 to be turned on. (For more information on the X10 protocol look in the Resources.) An appealing JavaScript, Java, or HTML interface can easily be put on top of the core functionally to create Web-enabled interfaces. Most of the products from the X10 companies are Windows-based and are pretty useless from an Internet perspective because you have to log into machines all day to get information. The X10Handler.java code in Resources implements the handler required to process X10 commands with the TW523 module and the two-way controller.

Let's move on to another application, this one targeting the devices in your home. How would you specify control of the temperature? You would need a thermostat that interfaces with your furnace and is accessible to your control device; typically, this device is your computer. The URL might look like this:

http://www.digiorgio.com/X10/SetTemperature?Zone=Upstairs?Temp=62

The home automation handler is being asked to change the heating, ventilation, and air conditioning settings. Dampers in your home can be controlled remotely so that heating is directed to rooms where it is needed.

The HTTP stack finds the correct handler and supplies the parameters from the requester. The handler communicates with the home automation controller du jour and provides information back to the user. You can see that, in order to get to the home automation system or the weather station, you need to first get through the authentication process. One of the key concepts is that gaining access to files or devices is no different from gaining access to a URL. Incidentally, Sun Labs has written more than 10 different handlers for serving files out of EPROM, for form-filling using XML and Java Card, and for many other useful purposes. For more information, see the e-mail link in Resources.

UPI and Jini

One may question the utility of the UPI given the arrival of Jini. As Jini technology develops, the use of HTTP stacks for solutions to problems like these will decrease, as it should. The weather station UPI has been enhanced to support a Jini interface as well as a UPI interface. Similarly, the other handlers can be augmented to support Jini interfaces so that Jini clients can perform actions on devices. The UPI architecture complements Jini technology by allowing the deployment of intranet applications that use Jini exclusively, yet allows the same code base to present a URL interface for Internet users. This code will be posted to the Jini Web site in next few weeks. (See Resources for the URL.)

X10Handler for a TW523 maps requests to actions on the power line

The following two files demonstrate how to write a simple handler for the UPI that allows users to send X10 commands to power line devices. The first file is an abstract class that provides some of the common implementations and defers implementation of device specific methods to other classes, in this case the TwoWayHandler.java. The TwoWayhandler communicates with a device that connects to the RS232 port and connects on this port to signal levels appropriate for a TW523. For more information on the X10 devices, look at the URLs in the comment sections within the code.

1 2 3 Page 2
Page 2 of 3