Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Serve clients' specific protocol requirements with Brazil, Part 3

Economically sustain PQA, UP.SDK, and J2ME with the Brazil project

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
In Part 1 of this Brazil technology series, I introduced the concept of a developer-friendly experimental Web server technology called Brazil. The Brazil technology supports additional functionality via handlers, the simple Brazil Scripting Language (BSL), and a global dictionary of system and user properties (for more information on BSL, properties, and handlers, see Part 1

In Part 2, I discussed how to produce and synthesize XML content. In Part 3, I will demonstrate how to deploy a simple application to three different mobile targets using commonly available technology. You can't control the software and hardware environment of wireless devices but, by using well-constructed server technologies, you can economically adapt to them. Deployment, maintenance, and development costs drop if we only use one language. Of course, I would prefer Java to be that universal language for wireless devices, and that day may come to pass. In the meantime, however, you can utilize the methodology described in this article to support the various languages.

The 1-wire weather station provides a data source for many of the examples in Part 3. It is interfaced to the Brazil technology via a handler and can be found at http://www.brazilhandlers.com:9090/Applications/WeatherStation. Note that the concepts in this article apply to any data source and are not specific to the 1-wire weather station.

Read the whole series on Brazil technology:



One of the benefits of Brazil technology is that it removes the distinction between where the data is coming from and how it is delivered. For example, a client connected to a server utilizing the Brazil technology does little to facilitate communication with the device.

In this article's examples, you will look at the weather station data as content. In Part 2, I discussed how to convert the data to XML. As ubiquitous as XML may be, many XML extensions and unrelated approaches often require support on the server. It would be nice to only support XML, which is a perfectly valid approach, and ignore XML extensions. If you did, you can bet that everyone would come to your standard. Or you could architect your code to support multiple standards, which is a goal I hope to help you meet.

In this article, I provide all of the required URLS, examples, and some of the problems that I stumbled upon so that you can avoid the mistakes I made. All of the examples provide end-to-end solutions; a Brazil handler delivers data from a remote weather station to a remote wireless client using one of the following environments:

  • Palm query application (PQA)
  • Openwave UP.SDK
  • Java 2 Micro Edition's (J2ME) Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP)


This article will focus on basic architecture and will describe how to deliver content from point A to B with respect to the particular client. I will not go into detail about the best way to design a user interface using J2ME or, in the case of WAP-enabled phones, how to organize cards in a WAP application using WML.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources
Technology business overviews PQA resources UP.SDK resources J2ME resources Some WAP wireless J2ME books