While the hosts we attach to networks are well catered for by the various protocol families, most netework devices are poorly serviced if at all by the mainstream network protocols. This is in spite of the fact that anecdotally at least, the desire to network attach a wider variety of machines dates back to the very earliest days of the net.
As a result, until recently, such network attached devices were limited to routers and bridges, printers and the occasional piece of more exotic hardware. For the network building hardware, like routers, a special protocol, namely SNMP, was defined to enable remote reporting and configuration of the device. For many other devices, SNMP has been adopted as a lowest common (control) denominator. In most cases it offers a control paradigm which only poorly matches the needs of the device in question. Even the devices for which it was designed, fall back to telnet as their primary configuration method (i.e. the administrator uses the ubiquious telnet program to establish somthing which behaves like a host terminal session with the device being controlled).
Moreover, for those organisations offering services across a network, the interfaces available were all almost completely proprietary. The arrival of the Web has at least ameliorated the situation for those who can make do with a simple forms based interface, but were a richer interface paradigm to be available, a competitive, commercial organisation would be almost certain to adopt it. Enter Java.
enno@metva [15] finger coke@coke.ucc.gu.uwa.edu.au.
[moray.ucc.gu.uwa.edu.au]
The UCC Coke machine.
Slot 0 has sold 2 drinks of type fanta.
Slot 1 has sold 17 drinks of type club lemon.
Slot 2 has sold 33 drinks of type mountain dew.
Slot 3 has sold 32 drinks of type kole beer.
Slot 4 has sold 32 drinks of type gest lemonade.
Slot 5 has sold 32 drinks of type dead and is now empty.
Slot 6 has sold 32 drinks of type coke.
May your pink fish bing into the distance.
enno@metva [16]
Finger(1) is a reasonably clean interface as it is both simple and widely available. Newer variations on this theme are FTP, gopher and of course Web interfaces. The chief drawback is generally that (with the exception of FTP) read-only interfaces are most easily catered for.
The next step was the development of a long line of incompatible, proprietary interfaces by various different commercial (usually hardware) vendors. The designers of these interfaces have chafed against the chief difficulty which arises from making use of an existing protocol. This is of course that, the model of the protocol will impose natural limits on the services which can be offered. This is to say, if we use FTP, everything must look like a file transfer, if we use finger, everything must look like an enquiry about a users life decisions, and so on. By building a completely proprietary interface, these limits are circumvented. The interface can now offer whatever it is wished it should be able to. The cost is that a matching proprietary User Interface program must be offered. The wide variety of hardware and operating system combinations then works to ensure that the vendor has a significant task attempting to cover their market (The alternative of only offering a few selected platforms is also vigorously pursued, especially by those who believe that the modern computing world finishes where PC's do.)
It is worth noting that proprietary may or may not also mean secret. Examples of both are common. For instance, Sun's Network Manager product makes use of a proprietary, but published, interface built on top of their ONC RPC mechanism. This is in contrast to the many secret control interfaces which exist in the world. Of these some are secret for commercial adavntage and some are secret merely because there is no real need nor interest in having them published.
The natural solution to the headache of everyone having their own protocol is to define one for everyone to use. SNMP is the most recent of a number of such protocols. SNMP - the Simple (misnomer) Network Management Protocol - is a general, extensible means for interoperable equipment and management software to exchange data and instructions. So, in theory, SNMP by having some degree of support from all parties, should have addressed everything that irritated us about generic and proprietary interfaces.
As you might expect, not quite. As with most standards, SNMP suffers from a number of shortcomings. The first is one which all such standards must deal with. In the attempt to be all things to all users, SNMP has to a greater or lesser degree inconvenienced all the members of this same community. SNMP's difficulties are chiefly:
In the Northern Spring of 1990 a small group of disaffected engineers inside Sun were given the go ahead to work on developing a next generation of user interfaces for everyday appliances aimed at being useful to non-computer professionals. By 1991, the group had physically moved from the main Sun corporate campus to their own site. This was possibly principally pyschological move intended to distance the group from the mainstream of Sun corporate management and as they saw it interference.
By late 1991, the group now called 'Green', had identified the need for a strong 'industrial-strength' OO based language to push their ideas further. This language, named Oak internally, was developed by James Gosling for the group. A Graphical environment is designed which will become the core project of the Green team. The group now believes it should build 'an interface to cyberspace' or 'a visual gateway into the virtual world'. By late 1992, a working prototype (the *7) of the new concept is demonstrated to senior Sun managers and is well received by them. The UI is a breakthrough for the time and Sun spins out a separate company, FirstPerson Inc., to make the attempt to find buyers for this technology.
In 1993 FirstPerson deals with Mitsubishi and French Telecom as well as unsuccessfully bidding an Oak interface to Time-Warner for set top boxes (i.e. cable TV/Video on demand decoders & controllers) and to 3DO. By early 1994, FirstPerson is scrapped and Oak is to be redeveloped for the Internet. In particular, mosaic has by now been released and has started the exponential growth of the Web.
By early 1995, Oak has been renamed Java, HotJava the Web browser has been written in it and the Web has become a major piece of the computing landscape. Almost single handedly, the Web is now attracting millions of non-computer geek users and the demand for interfaces which are more than the static documents, which were all that the original academic progenitors of the Web had forseen, was strengthening. Enter a programming language which has been tailored to run in a Web browser, Java.
All of this by itself would have made Java just another programming language. The key ingredient now was that Java was tailored to run in the Web browsers of the users. To do this it must of necessity have a few interesting features.
Java, is at its heart an interpreted language. To regain some efficiency, Java is precompiled into a machine neutral form called `bytecodes' in the jargon of Java and these bytecodes are then interpreted by a Java Virtual Machine (JVM). Those of you who can remember far enough back to the heady days of UCSD Pascal may remember a similar scheme of compiling to P-codes and having an interpreter which executed the P-codes. In fact, the JVM was modelled on the earlier P-code architectures in some places. The JVM in fact implements a fairly simple stack based architecture for which the Java code is compiled. [It is interesting to note that at least one implementation of hardware, The Western Digital MicroEngine, was made in the old days which could directly execute the UCSD P-codes. It is a matter of current speculation as to whether similar hardware can be built for Java. Given the historical precedent, it would seem that the answer should be yes.] It should be noted of course that there is nothing preventing the intermediate bytecodes from being further processed to produce real machine code for a target environment. Indeed, tools to do this are distributed. It should also be noted that there is nothing to prevent other languages from being compiled into bytecodes for the JVM to execute. The JVM has in fact taken the place of the target hardware. The only real difference is that the single definition of JVM runs on the many real target architectures.
The key here is that the JVM allows programs to be distributed which are not tied to a single make of computer, model of CPU, or flavour of operation system software. For an environment like the Web this could be crucial. For the rest of us, it will certainly be nice to have.
The JVM model of the language also allows significant amounts of checking to be built in the interpreter loop. Some of these checks are simple runtime tests for common programming errors and some are checks for violation of security policies. Java in fact attempts to enforce strict measures of the codes (applets) which it runs to prevent the possibility of rogue programs causing damage or distress. The degree to which this will succeed remains an open question, but it certainly appears the the will to correct any flaws as they are found is at least in place (which we know because a flaw was recently found).
Java is, as are most of the latest crop of languages, an Object Oriented one. It is loosely modelled on C++ although in some areas conscious decisions have been made to jettison C++ features which were felt undesirable. For example, unlike C++ Java only supports single inheritance and does not allow overloading of operators. It does however allow overloading of methods inside classes. The balance which was struck obviously represents one which the designers felt was best at the time. In the long term it remains to be seen how successful this is. Other C++ features which were retained are the exception mechanism for trapping and handling or passing off error conditions.
Other features which are new to Java are more interesting. Java pointers are more like those of Pascal then those of traditional C. In addition to this, Java pointers are never freed. Instead a garbage collector is used to reap objects which are no longer in use by anyone The intention here is to prevent the `memory leaks' which plague many modern projects. The garbage collection mechanism is also said to have benefitted from the research which has occurred since the last mainstream languages which made use of it were proposed in the 60's and 70's.
Like many other languages Java offers access to the thread mechanism which many host operating systems can now offer. Unlike most, it also attempts to offer native synchronization and mutual exclusion of threads from critical areas of code without the need for much programmer effort. This as you may realize is an attempt to make the use of threads less prone to the sorts of errors which can occasionally plague program using these facilities.
Rather than belabour the similarities or differences, let's just have a quick look at some Java code. This piece is from some of the example code which comes with the Java Developers Kit.
1: int addVert(float x, float y, float z) {
2: int i = nvert;
3:
4: if (i >= maxvert)
5: if (vert == null) {
6: maxvert = 100;
7: vert = new float[maxvert * 3];
8: } else {
9: maxvert *= 2;
10: float nv[] = new float[maxvert * 3];
11: System.arraycopy(vert, 0, nv, 0, vert.length);
12: vert = nv;
13: }
14:
15: i *= 3;
16: vert[i] = x;
17: vert[i + 1] = y;
18: vert[i + 2] = z;
19:
20: return nvert++;
21: }
To those of you with a working knowledge of C or C++ most of this will not look at all unusual. In this respect, Java has few surprises for the working C/C++ programmer. There are a few things which bear explaining. On line 10 you can see that Java allows variable declarations to appear anywhere. On line 11 a method in another class is being called. Lines 9 and 15 through 18 show expressions which most C compilers would be happy with. On Line 7 a new instance of a class (an object) is created.
More interesting perhaps is an example of how we can layout objects on a page for the user to interact with.
1: public class demo extends java.applet.Applet {
2: int counter;
3: TextArea txt = new TextArea("", 10, 60);
4:
5: public void init() {
6: add(txt);
7: add(new Button("Count"));
8: add(new Button("Reset"));
9: }
10:
11: public boolean action(Event evt, Object arg) {
12: if (evt.target instanceof Button)
13: handle_button((String)arg);
14: return true;
15: }
16:
17: public void handle_button(String name) {
18: if (name.equals("Count"))
19: counter++;
20: else if (name.equals("Reset"))
21: counter = 0;
22:
23: txt.setText(counter + " ");
24: }
25: }
This example shows how we can get some GUI objects to render on the screen and in fact also wires them up to do something semi useful. The size of this example compares favorably with many of the newer PC based programming environments and the reader can perhaps see how this could even be generalized into an 5-10 line hello world program. The real message here is that Java programs do not have to suffer from the daunting complexity which characterizes some languages and environments. In spite of this, the base classes offer sufficient flexibility to allow a number of complex tasks to be undertaken easily.
A quick survey of these class libraries is:
So the question now becomes what is necessary to embed a Java interface into a device, or a service. The answer depends on where the Java is intended to run. This highlights a point not yet made. The Java runtime environment can exist outside the browser. In this mode, Java is just another language in which to implement programmatic solutions to problems. While implementing a server in Java is indeed feasable, we are not really interested in this mode of operation as things currently stand. The single, unique feature of Java is that it is able to run in a Web browser. This means we fundamentally are interested in Java as a browser based client and not any of the other possible modes of operation.
Sizing the components we have identified can let us determine what sort of systems are feasible and what sort need to wait awhile. The components we can readily identify are:
Clearly also, we will need something like 64kb to 192kb of memory space plus support for the files we will need to serve and room for the application we are actually attempting to interface to. Having seen what our target environment must support, lets have a quick look at what we might accomplish with such hardware and software.
1: //
2: // A quick network demo -- connects to the quote server and after collecting
3: // the output displays it in a text area.
4: //
5: import java.awt.*;
6: import java.io.DataInputStream;
7: import java.io.BufferedInputStream;
8: import java.io.IOException;
9: import java.net.Socket;
10:
11: //_____________________________________________________________________________
12: // The 'quote' class will connect to the service of the same name under 'inetd'
13: //
14: public class quote extends java.applet.Applet {
15:
16: String str = "Making Network Connection... please wait.";
17: TextArea txt = new TextArea(str, 5, 70);
18: Button bttn = new Button("Again");
19:
20: //_____________________________________________________________________________
21: // Build the bits we want to display.
22: public void init() {
23: add(txt); // add text panel to display.
24: add(bttn); // now our one and only control.
25:
26: fill_text_area(); // get a initial quote.
27: }
28:
29: //_____________________________________________________________________________
30: // now we process the button events.
31: public boolean action(Event evt, Object arg) {
32: if (evt.target instanceof Button)
33: fill_text_area();
34:
35: return true;
36: }
37:
38: //_____________________________________________________________________________
39: // This is where all the interesting stuff happens.
40: public void fill_text_area() {
41: String line;
42: StringBuffer buf = new StringBuffer();
43:
44: try {
45: Socket sock = new Socket("metva.metva.com.au", 17);
46: DataInputStream strm = new DataInputStream(
47: new BufferedInputStream(
48: sock.getInputStream()));
49: while ((line = strm.readLine()) != null) {
50: buf.append(line + "\n");
51: }
52: sock.close();
53: str = buf.toString();
54: }
55: catch (IOException e) {
56: System.out.println("I/O Error:" + e.getMessage());
57: }
58:
59: txt.setText(str);
60: }
61: }
62:
Most of the early parts of this code deal with things we have looked at before. As such, we will not dwell on them again. The things of interest to us happen in the function fill_text_area() in lines 40 to 61. Even here, things should be reasonably familiar to users of sockets in C. Briefly, in line 45 a socket is opened. In line 46 we make it into a buffered I/O object and then collect the data from it in lines 49-51. The socket in closed in line 52 and the text is formatted and pumped into the text box in line 59.
An example of what this looks like is shown below.
1: //
2: // Another network demo -- connects to the AVL data server and display each
3: // position fix as it arrives.
4: //
5: import java.awt.*;
6: import java.lang.Math;
7: import java.io.DataInputStream;
8: import java.io.BufferedInputStream;
9: import java.io.IOException;
10: import java.net.Socket;
11:
12: //_____________________________________________________________________________
13: // The 'avldata' class will connect to the AVL data routing program and
14: // display the values in the POSITION fix messages.
15: //
16: public class avldata extends java.applet.Applet implements Runnable {
17:
18: Thread thd = null;
19: Socket sock;
20: DataInputStream strm;
21:
22: TextField id = new TextField("--", 10);
23: TextField poslat = new TextField(" ", 30);
24: TextField poslong = new TextField(" ", 30);
25:
26: //_____________________________________________________________________________
27: // Service functions which help out with layout.
28: //
29: protected void mk_lbl(
30: String name,
31: GridBagLayout gridbag,
32: GridBagConstraints cnstrn
33: ) {
34: Label lbl = new Label(name);
35: gridbag.setConstraints(lbl, cnstrn);
36: add(lbl);
37: }
38:
39: protected void mk_tfld(
40: TextField tfld,
41: GridBagLayout gridbag,
42: GridBagConstraints cnstrn
43: ) {
44: gridbag.setConstraints(tfld, cnstrn);
45: add(tfld);
46: }
47:
48: //_____________________________________________________________________________
49: // Build the bits we want to display.
50: //
51: public void init() {
52: GridBagLayout gb = new GridBagLayout();
53: GridBagConstraints gbc = new GridBagConstraints();
54:
55: setLayout(gb);
56:
57: gbc.fill = GridBagConstraints.BOTH;
58: gbc.anchor = GridBagConstraints.CENTER;
59: gbc.gridwidth = GridBagConstraints.REMAINDER;
60: gbc.weightx = 1.0;
61: mk_lbl("AVL data display", gb, gbc);
62:
63: gbc.weightx = 1.0;
64: gbc.gridwidth=GridBagConstraints.RELATIVE;
65: mk_lbl("Vehicle", gb, gbc);
66: gbc.weightx = 2.0;
67: gbc.gridwidth=GridBagConstraints.REMAINDER;
68: mk_tfld(id, gb, gbc);
69:
70: gbc.weightx = 1.0;
71: gbc.gridwidth=GridBagConstraints.RELATIVE;
72: mk_lbl("Latitude", gb, gbc);
73: gbc.weightx = 2.0;
74: gbc.gridwidth=GridBagConstraints.REMAINDER;
75: mk_tfld(poslat, gb, gbc);
76:
77: gbc.weightx = 1.0;
78: gbc.gridwidth=GridBagConstraints.RELATIVE;
79: mk_lbl("Longitude", gb, gbc);
80: gbc.weightx = 2.0;
81: gbc.gridwidth=GridBagConstraints.REMAINDER;
82: mk_tfld(poslong, gb, gbc);
83: }
84:
85: //_____________________________________________________________________________
86: // Kick off a thread of our very own to run in.
87: //
88: public void start() {
89: if (thd == null) {
90: thd = new Thread(this);
91: thd.start();
92: }
93: }
94:
95: //_____________________________________________________________________________
96: // This is where we kill the thread when we told to. We also incidentally
97: // disconnect from the data service as we don't want the data to back
98: // up and eat all the system buffers.
99: //
100: public void stop() {
101: if (thd != null) {
102: thd.stop();
103: thd = null;
104: }
105:
106: try {
107: sock.close();
108: }
109: catch (IOException e) {
110: System.out.println("I/O Error:" + e.getMessage());
111: }
112: }
113:
114: //_____________________________________________________________________________
115: // We are being told to start running (possibly again). Start by opening
116: // our data connection and then drop into the data display loop.
117: //
118: public void run() {
119: try {
120: sock = new Socket("metva.metva.com.au", 4201);
121: strm = new DataInputStream(new BufferedInputStream(
122: sock.getInputStream()));
123: }
124: catch (IOException e) {
125: System.out.println("I/O Error:" + e.getMessage());
126: }
127:
128: while (true) {
129: fill_data_area();
130: repaint();
131: }
132: }
133:
134: //_____________________________________________________________________________
135: // This is where all the interesting stuff happens.
136: //
137: public void fill_data_area() {
138: int length;
139: int fleet, vehicle;
140: double latr, lonr;
141:
142: if (strm == null)
143: return;
144:
145: try {
146: if (strm.readUnsignedShort() == 6) {
147: length = strm.readUnsignedShort();
148: strm.skipBytes(2);
149:
150: fleet = strm.readUnsignedShort();
151: vehicle = strm.readUnsignedShort();
152: strm.skipBytes(4);
153: latr = strm.readDouble();
154: lonr = strm.readDouble();
155: strm.skipBytes(17);
156:
157: id.setText(fleet + ":" + vehicle);
158: // poslat.setText(latr + " ");
159: // poslong.setText(lonr + " ");
160:
161: show_rads(poslat,
162: latr < 0 ? "S" : "N",
163: Math.abs(latr) );
164: show_rads(poslong,
165: lonr < 0 ? "W" : "E",
166: Math.abs(lonr) );
167: } else {
168: length = strm.readUnsignedShort();
169: strm.skipBytes(2 + length);
170: }
171: }
172: catch (IOException e) {
173: System.out.println("I/O Error:" + e.getMessage());
174: }
175: }
176:
177: //_____________________________________________________________________________
178: // convert a lat or long coordinate into a text string for display.
179: //
180: public void show_rads(
181: TextField txt,
182: String sign,
183: double rad
184: ) {
185: double deg;
186: int hr, min;
187: double sec;
188:
189: deg = (rad / 3.14159265358979323846) * 180.0;
190: hr = (int)deg;
191: deg = 60.0 * (deg - hr);
192: min = (int)deg;
193: sec = 60.0 * (deg - min);
194:
195: txt.setText(hr + "deg " + min + "min " + sec + "sec " + sign);
196: }
197: }
198:
Lines 26-85 represent the setup of the display for this example. As we need to deal with mostly automatic layout of the display in the presence of resizable windows, we do not have the luxury of specifying fixed positions for the GUI elements we wish to use. Instead we specify relationships and rules. Users of Tk/tcl will see some similarity with the layout mechanisms deployed there.
Lines 88-112 form the first significant difference in this scheme from any of the other more conventional means of giving Web pages dynamic content (such as using the cgi interface). In these lines we are arranging to spin out Applet out into a separate thread of execution. In effect, we are decoupling the applet from the browser UI in which it is embedded.
Lines 118- 132 form the core of the running applet. This code does little except (re)establish the data connection to the AVL server and then enter a loop to deal with the data as it arrives.
Lines 137-175 forms the core of the service loop. It arranges to read a packet of data from the connection and if the type is 6 (an AVL position fix) it will read the balance of the data, decoding the fields in which it has an interest. If the packet type was one of the other types in which we have no interest (here) then it is skipped.
Lines 157-166 are where the text fields are updated. (Complete with commented code which simply dumps the radian lattitude and longitude values directly). The code mostly uses the final utility function at Lines 180-197 to format the radian value in a slightly more human readable form.
Once again, the output of this applet is shown below.
As to the future of the Java language itself, Sun has signalled an intention to retain fairly tight control over the language specification. By way of example, Sun will supply JDK source code free of charge to anyone who wishes provided that they agree to a number of conditions, one of which is that any changes which they wish to promulgate must not alter the core language. If nothing else, this policy will guarantee backwards compatibility. [I should stress here that this is only one of the conditions and not the only condition. Unsurprisingly, the full agreement has some extra clauses you also need to live up to.]
The issues of implementation I touched upon before are also being actively discussed. The nature of the JVM and how close to hardware it may be implemented are of interest here as are the questions of whether we may see other languages implemented as front-ends to the JVM. Ultimately, the JVM is just another machine code. It has some features which allow it to be implemented efficiently in other machines and it has features to enhance the security of the language itself.
Whether James Gosling's future of Java powered light switches and toasters comes true or not is more likely to be a question of ubiquitous computing than whether Java itself succeeds. Java the porgramming language is not without merit. Java the programming language which we can attach to documents on the Web is clearly a new idea. Suns vision of dynamic content and a new generation of video games is only the beginning. The ability to distribute function to the place it is requested and to continue to interact once it is there may signal the beginning of a whole new User Interface paradigm. Servers can now be feature rich, change at will and continue to operate so long as they can supply a downloadable UI (client) for their current functions.
Java may in fact cause a resurgence of the proprietary inteface. Now that a machine independant means of servicing such interfaces is available in the form of Java driven extensions to otherwise conventional Web browsers, the cost of mnaintaining such interfaces becomes negligible. In fact, the Java powered interface is now likely to be both cheaper, more ubiquitous and in time more flexible and more useful to the user community. Given the high costs associated with mainstream Network Management packages, Java powered interfaces are likely to be seen as offering superior value to smaller communities of users.
How such Java powered interfaces will fare in the wider world of control, where peripherals are being controlled which have to this point not even had network interfaces, is unsure. Whether Java and its supporting infrastructure can be squeezed to the point where say X-10 and Cebus home control peripherals are targetted remains to be seen. It will almost certainly allow other midrange devices, such as office block climate control systems for instance, to make an appearance on the network to offer better access to the control functions. It would certainly seem to have a place where the resources to support it are available.
Prev Paper |
Conference Programme |
Next Paper |
 Author's papers |
||