Serve clients' specific protocol requirements with Brazil, Part 1

Learn how to build an application server that can deliver data to clients requiring different protocols

Reusing code to concurrently support different interface options is not an easy task for a developer. The purpose of this series is to facilitate this process by showing you how to build a simple application server that supports clients using any of the J2EE APIs. I will demonstrate how to deliver data from a device or other source to clients requiring a specific protocol or a delivery guarantee that must support multiple protocols.

Read the whole series on Brazil technology:

The Brazil Web server, which I introduced in my previous column, will be implemented as an experimental application server. (See the sidebar below, Brazil: An extensible Java Web server, for more information about the Brazil project.) In that article, I discussed how you can support X10 devices by means of a Brazil handler. This time around, the handlers, which realize specific interfaces for different connection protocols, will extend the Brazil Web server so that users can employ varying network protocols and technologies to connect to it.

Consider delivering data from a weather station to a mixture of users on the Internet, as shown in Figure 1:

Figure 1. Delivering data to diverse clients

The figure demonstrates that you may have users on limited-bandwidth connections -- like radio links to handheld devices, pagers, phones, and PDAs -- and high client bandwidth multicast services -- like satellites telemetry applications requiring constant updates, and cable modem, DSL, and traditional modem users. In future columns, we will examine prototypes that use a delegation model to utilize the technologies in the figure, while at the same time maximizing code reuse with simultaneous support for Jini, JRMS, RMI, JDBC, JMS, HTTP, applets, and JavaScript.

This article introduces an architecture that utilizes a Web server as a resource contention manager, a basic service provider (for file services), and a general supplier of an application service (for weather data). The Brazil Web server differs from current Web servers in that it is smaller and easier to comprehend, and provides users with an old abstraction -- property objects. Use of property objects with the Brazil Scripting Language (BSL) provides an integrated Web content delivery system with no out-of-band scripts, which allows easy access to data on the server. Thus, placing server data that is not a file on a Webpage becomes trivial.

The advantage of this approach is that the Web server also doubles as the foundation for delivering services to users with different requirements, yet utilizes the same code base and provides a unified interface to the varying protocol drivers. Often these services require some additional interfaces and/or management abilities. By using a variety of mechanisms, the Brazil Web server can provide authenticated, secure access to these services.

The server is a research prototype, and the concepts developed here are usable with commercial application servers as business needs merit. This series will provide the code needed to develop a simple test environment for working with different components of the J2EE architecture. See the Resources section below for links to code for this article.

In addition, I will discuss how you can create your own application server for small devices like the TINI board, which can interface devices to different protocols. Also see the sidebar below, Brazil support for JMS, for a discussion on implementing a JMS interface to the Brazil weather station.

Requirements for the API/interface

Users often have varying requirements concerning data delivery, and developers must keep these in mind when distributing information to them. Often developers encounter environments that, due to a lack of security knowledge, are hostile to Java. Such a case doesn't mean that you can't use Java in a deployment solution. The Brazil approach utilizes Java on the server with full support for Java on the client and with minimal impact on the work you have completed. For example, suppose a client stipulates that the browser cannot implement Java applets. You can utilize BSL and JavaScript to accomplish similar functionality. And if the situation changes, you can inexpensively provide the same functionality with the added benefits of applet-based user interfaces and security. Over time, this strategy may allow you to point out to users the merits of using Java technology on the client, an effort recently given new impetus by Sun with Java Web Start (see Resources).

Consider the following simplified user infrastructure requirements in the table below. In addition to these requirements, the table also lists the technology selected to receive and deliver the data. These solutions are based specifically on each user's constraints.

User interface requirements
ConstraintsProposed client technologyProposed server technology
Java or JavaScript through firewallBSLTemplate, file
JavaScript but no appletsBSL or JavaScriptTemplate, file
Unsigned appletsBSL or JavaScriptTemplate, file
Allows signed applets, but not to other ports (blocked at firewall)Applet using Brazil dictionariesTemplate, file
Minimize network trafficJRMS clientJRMS handler
100 percent reliable messagingJMS clientJMS handler or interface to UPI
Users need to create dynamic networks when they are in the vicinity of machineryJINI clientJINI

The service -- a weather station

We will use data from a realtime weather station with an interface available on the Web (see Resources for the URL). It provides weather services with multiple API interfaces. Generally, you will be able to use these APIs from your desktop. Please note that in some cases your site's security policy may prevent you from implementing a selection of the more advanced APIs. Usually, sites have a difficult time comprehending sophisticated APIs and thus often perceive them as a security threat or as a potential consumer of corporate resources.

Access the weather station site from an entry point like a proxy, which lacks layers between you and the Internet. The Website in Resources will provide all the code you will need as I publish future articles in this series. As time goes on, we will migrate this functionally to a J2EE architecture, so that other business or scientific logic can act on the data stream.

We can support the weather station over a serial line that connects directly to a platform capable of running Java. Almost every desktop computer meets this requirement. The weather station communicates using the TMEX protocol, details of which are available in Resources.

We modified the original source code from Dallas so that the WeatherStation would provide return types better suited to the Brazil server, operate 24 hours a day, 7 days a week, and add automatic calibration features for the anemometer. The code is also available in Resources.

We can also connect the weather station directly to the TINI board and communicate with the board over an Ethernet interface, using HTTP, for example, where the TINI board runs a Web server.

We have two main classes for communicating with the WeatherStation: one that collects data from the WeatherStation, and another that delivers it to requestors.

The WeatherStationHandler communicates with the weather station using the WeatherStation object. The handler checks for basic errors and understands the URLs, one of which is http://SOMEHOST:SOMEPORT/weather/GetStaus.html.

The SOMEHOST specifies the name of the machine -- in our case, use 24.228.0.167 for the host. The SOMEPORT port number is 8090. When the Brazil server starts, it reads the config file, where there is an entry for various handlers. One of the handlers, the WeatherStationHandler, processes the application-specific URLs. The Brazil server also serves files, applets, and the template-processing language.

The protocols and technologies that Brazil can support

The Website at http://www.digiorgio.com/weather runs a Brazil Web server that supports the following access protocols/technologies in various stages of development: simple HTTP request, BSL, applet and JavaScript clients, JMS, RMI, JRMS, Web Clipping, and Jini. I have provided an overview of each below, and I will delve further into some of the protocols not detailed here in future articles.

Simple HTTP request

Sending an HTTP request to http://24.228.0.167:8090/weather/GetSample.html returns a name=value pair, which you can access with other programs. At one time, we supported returning HTML pages, but because HTML code is almost impossible to maintain and requires recompilation, we found this to be undesirable.

Use BSL to present results and create dynamic Webpages

BSL is a simple language and, from my point of view, one of Brazil's most powerful features. The language allows Web developers to extract values from the Web server and easily place them on a Webpage. For example, to obtain the value of the root of the Web server, you need only specify <property name=root> on a Webpage, and it will substitute the value for root. Brazil's abilities can also protect your intellectual property since users can't steal scripts and applets that don't exist. A brief description of BSL follows.

The BSLTemplate takes an HTML document with embedded BSL markup tags in it and evaluates those special tags to produce a standard HTML document. BSL can substitute data from the request properties into the resulting document. However, rather than simple property substitution, as provided by the PropsTemplate, this class provides the ability to iterate over and choose among the values substituted with a set of simple flow-control constructs.

BSL uses the following special tags as its language constructs:

     <foreach> 
     <if>

Brazil supports large data dictionaries in two ways. Applications can place properties in the global property table, which is available to all HTTP requests, or alternatively return the data as a name=value pair in a request only. This limits visibility by using per-request scoping. Each time a request arrives at the server, the returned properties apply only to that request, directly contrasting with server properties, which all requests can utilize. The Brazil server utilizes the defaults field of properties to implement chainable properties lists. Other developers are looking at dictionaries in the server that have 200,000 entries. The power of this method is discussed in the sidebar, Brazil: An extensible Java Web server. This approach can be secured because Brazil supports the notion of a per-URL access control list, which can be protected with passwords and/or other external devices such as smart cards.

Use of BSL is, by far, the easiest and most elegant of the methods described in this article. The following segment displays all the values in the server starting with the prefix weather.

<table>
<foreach name=a  match="(weather.sample.*)" >
    <tr>
        <td><property a.name.1></td>
        <td><property a.value></td>
    </tr>
</foreach>
</table>

However, this approach does not solve the dreaded flicker problem, which is caused when a Webpage continually requests to refresh itself. A certain type of dynamic page requires new data from the server. When an entire page is refreshed using a meta tag, the result is often unappealing; the larger the page, the worse it gets. Ideally we would use Java applets in this case. However, you can utilize BSL with a refresh specification:

 <META HTTP-EQUIV="Refresh" CONTENT="5">

Applet and JavaScript clients

JavaScript clients can access the Brazil server by performing a post to the server and parsing the response. The JavaScript security model does not support directing posts to a URL with a subsequent read of the returned data. In order to prove this ability to JavaScript applications, JavaScript calls an applet method. Applets can post to the server from which they came without security restrictions. Since JavaScript can call Java applets, the Java applets support JavaScript.

Should you use JavaScript or applets?

You could probably obtain the same results using either technology. JavaScript is quicker for prototyping, while applying security to an applet is much easier than applying it to JavaScript. JavaScript user interfaces don't perform adequately; in my opinion, their use often involves a round trip to the server, which causes flicker. Some developers argue that they can clone applets more easily than they can clone JavaScript. However, an unscrupulous developer could easily steal a JavaScript program and change it, although some claim that they can just as easily decompile a Java applet and modify it for their own benefit.

1 2 Page 1
Page 1 of 2