Serve clients’ specific protocol requirements with Brazil, Part 1

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:

• Part 1: Learn how to build an application server that can deliver data to clients requiring different protocols
• Part 2: How to support XML applications with the Brazil project
• Part 3: Economically sustain PQA, UP.SDK, and J2ME with the Brazil project
• Part 4: Build multicast-aware apps with JRMS
• Part 5: Manage users and content with Brazil
• Part 6: Plug Jini, BeanShell, and JAXM into Brazil

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:

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.

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

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 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 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 class="legacyTable">
<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.

An applet can process data, graph data, analyze data, and poll a server to provide the user with a flickerless display of data. The PosterApplet provides support for JavaScript applications to post and read a response from a Web server. This approach is awkward, but sometimes application/developer constraints are such that you have no choice. For example, perhaps — due to limitations in time or skills — you cannot write an applet, or the completed applet is too large, or you have so much existing HTML that integration with JavaScript would be easier.

Java Message Service

The Java Message Service (JMS) provides a framework to build message-oriented models. Because the receipt or distribution of a message initiates an action, many programmers and developers find this type of framework to be quite natural. See the sidebar, Brazil support for JMS, for more information.

A TINI board is a low-cost development environment that utilizes Java technology. Weather stations have been interfaced with TINI boards by several diverse groups with slightly different goals. MindStream Software developed an early client interface to the Brazil software using a commercial JMS package. The company wrote a handler that would distribute weather data using JMS over a public network. Since then, an additional prototype has been developed, which utilizes a TINI board to supply weather data as a JMS server. This server has a different handler in Brazil, which takes JMS data and provides access via other APIs. To summarize, a prototype was completed in which the Brazil server supported two different handlers:

1. JMS server handler, which publishes data to JMS clients
2. JMS client, which provides published data from the MessageBoard to non-JMS clients

A third option under consideration is to directly place a Web-based server on the MessageBoard. (See the sidebar below, MessageBoard, for information on a JMS solution built for the TINI board.) Future articles will demonstrate how to run the various protocols discussed above on the TINI board, TINI technology permitting. For example, we can’t support Jini directly on the current version of TINI.

RMI

RMI provides an easy-to-use distributed computing environment that facilitates small-application development. Part of the development process for a Jini-enabled service often produces an RMI service as well. Requests to obtain weather data using RMI from a Java application or applet are by far the smallest and easiest programs to develop. Unlike other approaches, which require that a wire protocol be defined, RMI has a built-in wire protocol, making development that much faster. Since the wire protocol is defined, there is no need to convert objects from one format to another, as would be the case with JDBC and JMS. It should be noted that JMS could send serialized objects so that object conversions are minimized.

J2EE

In my next article, I will implement a J2EE-compliant component that will interact with a database of historical data. This will be a general-purpose bean; it will, given latitude, longitude, and an elevation, return relevant weather readings. The application of these components to process-control and point-of-sale industries and factories represents a potentially vast new marketplace for developers.

Web Clipping

Palm OS users can browse the Web by using Web Clipping, a technology developed by Palm to deal with the low bandwidth of the radio link from a Palm VII wireless device. A very simple example on the Website that accompanies this article combines BSL scripting and the FileHandler to deliver weather data to Palm devices. I will delve further into Web Clipping in future articles.

Jini

Several fledgling initiatives aim to offer Jini services that provide weather data based on your current GPS position. Combining a spatial position with relevant data sources transparently will benefit consumers and industries by presenting relevant interfaces based on location. The plan is to support Jini services as a handler, and early prototypes have been constructed. Future articles will discuss the Jini implementation.

Two Jini groups exploring these ideas are Jeather and JGPS. Given a GPS coordinate, JGPS plans to provide information specific to that location, ranging from weather and tides to local stores and special events. The goal of Jeather is to provide relevant weather information as a Jini service. Jeather could supply weather data to JGPS. If you want to write code and or specifications, please join the groups by using the URLs in Resources.

Java Reliable Multicast Service (JRMS)

Because multiple listeners viewing the same data require some degree of reliability, the JRMS protocol is a good fit for weather data. Once the JRMS API has been released for public use, the JRMS handler will be made available. I will feature a more in-depth discussion of JRMS in a future column.

Conclusion

Developers looking to deploy applications on the Web should familiarize themselves with these technologies. With this series I hope to provide a firm foundation for moving data around the Internet inexpensively and securely. Since the threats are minor and service is more predictable on an intranet, cheaply moving data around and securely meeting requirements there is much easier. As the Web begins to allow Java technology to be fully utilized, many of the current ad hoc approaches can be replaced with formal, secure, user-friendly APIs that are designed to operate in unison. By following with this series, you should be able to develop applications that utilize simple HTTP, HTTP with scripting, applets, JMS, JRMS, Jini, RMI, and Jini. The knowledge gained here can also be applied to developing J2EE components.

Source: www.infoworld.com