Posted by dtait
on November 14, 2003 at 1:15 PM PST
Sun's Visionary statement of "the Network is the Computer" will eventually happen, but the question is when. Putting political and business issues aside, what are the technical barriers to true Network Computing? Why is programming for Networks so hard? There are many answers, but identifying and prioritizing the barriers, and then overcoming the important barriers with integrated solutions, moves us in the direction of the Network becoming the Computer(...or was that the Computer becoming Network?)
My first experience writing SS7/Voice signaling-to-IP gateways should have been simple right? Wrong!
The task of receiving an SS7 message, converting to IP and sending to another system seems easy, but when you start writing the code, the networks start to tangle you up in events, alerts, collisions, performance, scaling, failure, recovery, and all sorts of heartburn that spiral you into a programmers nightmares. Waking from this nightmare of Voice and Data internetworking, and having the luxury of stepping back and analyzing the problems and flaws in network development, the following two barriers and solutions jump right out -
Problem #1) Synchronous vs. Asynchronous Synchronous is the chronological arrangement of historical events. Computer programming in intrinsically synchronous. This is the nature of the science a program does one thing, one step at a time. As computers evolved, they became better at doing a lot of programs where each program still does one step processing. This is also reflected in the computer languages.
Asynchronous is the absence or lack of concurrence in time a processes or event could happen at any time. Asynchronous processing has been added to computer programming to handle device drivers, interrupts, events, exceptions, etc. This may seem acceptable until you contrast a computer with a telephone switch. A switch sets up and processes many simple connections asynchronously. A switch is not designed for complex processing on any single connection, but can do many simple small processes on many connections all at the same time - concurrent asynchronicity.
Another way to look synchronous vs asynchronous processing is by examining how a person interacts with the the Internet. A typical high school student asynchronously bounces from one or more browsers, to one or more Instant Messengers, to email, purely on a whim an 'absence of concurrence in time'. Each of these processes on the internet are synchronous they take an input, process it, and return an output, in 'chronological arrangement of events'. The person at the keyboard asynchronously jumps to another synchronous process, not waiting for any one process to complete. The asynchronous human endpoint interfacing to a synchronous Internet.
The voice network is quite different. A synchronous human endpoint interfaces with a network that is handling many asynchronous calls. A person making a phone call is usually interacting with the phone synchronously while the network is asynchronously checking to see if there is another end point, handling the endpoint for busy, ringing, or a pickup. The switch is doing this simple processing for many endpoints, all at the same time. Add a simple level of sophistication conference calls, and the processing becomes quite complex, but manageable, and still very asynchronous.
The Bad News -
The effect of Moore's law on both technologies is dramatic. As computing becomes faster and denser, processing capabilities are enveloping switching and signaling technologies making the Network become the Computer. So what is the effect on Java? As Java moves into more difficult asynchronous processes, the synchronous nature of the Java environments presents roadblocks for the developer.
For example, the EJB was designed to handle many big synchronous data events such as database manipulation, http processing, and web processing. These operations are synchronous. When attempting to use an EJB for asynchronous call processing, the low throughput unfairly brands Java as 'not ready prime time'. While the number of asynchronous calls the EJB synchronously processes is low, we must be fair - the EJB was not designed for this type of processing.
The Good News, - events and asynchronous processing are embraced within Java by such technologies as JavaBeans, Servlets, and JAIN SLEE:
- JavaBeans introduces the notion of events in J2SE. The programmer can now fire and process events with call-backs. These are great constructs for event processing and introduce normal synchronous Java programs to the world of asynchronous processing.
- Servlets - Events and asynchronous processing are taken to the next level with Servlet technology where the call-back is an integrated in the framework. A developer simply provides the event processing when the messaging arrives at servlet.
- SLEE - with the advent of JSR 22 going final release, the next level of sophisticated asynchronous event processing embraces many networks through the use of resource adaptation. Also JSR 22 defines several utilities such as timers, tracers, loggers, etc. to unburden the developer. Designed using many of the patterns from EJBs, JSR 22 JAIN SLEE puts asynchronous event processing at its core, and network adaptation as part of the framework.
Beans for SE, Servlets for IP, and SLEE for all networks.
Problem #2) Standard Interfaces for Communications -
The communications industry lives and dies by standards. If one network carrier has to interface to another network carrier, they communicate by a predefined standard endorsed by a standards body. Also if they have to purchase equipment from vendor, they makes sure the vendor has closely adhered to the standard. This is well and good for interoperability between vendors and carriers, but...
The Bad News - No standards consideration is given to the developer. The poor coder who has to write services for the networks must use proprietary interfaces. The real crime here are the protocols and messages are very well defined for interoperability purposes, but completely forsaken in the processing environment. What is worse, the proprietary interface must convert all the data to a standard format for messaging. Consequently, the Java developer has many useful standard libraries for 2d/3d graphics, database access, and web processing, but no standards to make a simple call, send an Instant message, or play voice.
The Good News - thanks in part to the Java Community Process and the JAIN Community, standard Java APIs are very slowly evolving for communications:
- JTAPI was a good first jab at defining a standard for endpoints, but JTAPI was able to sneak through the JCP with no Reference Implementation or Technology Compatibility Kit, and this weakened the API such that JTAPI implementations can deviate from the standard and there is no checks and balances to make sure vendors behave.
- JAIN SS7 standards produced several good Java standards for telephony protocols, however, SS7 networks never opened up to public networks, consequently, only those who program in the SS7 space benefitted.
- JAIN IP standards are finally enabling a new class of developers who are becoming savvy at IP integration with Voice, Messaging, and Media. JAIN SIP, JSR 32 , has defined a popular standard interface for Session Initiation Protocol, commonly used for Voice over IP. For Reference Implementations and Technology Compatibility Kits, check outhttps://jain-sip.dev.java.net/ . Also take a look at all the SIP projects under https://communications.dev.java.net/
JAIN SIP is just the beginning. Several other communications standards are paving the way to take the nightmare away from the developer and give him a placid Java Dreamland. APIs such as
Write once, run anywhere should also apply to networks, not just computers. Java applications that utilize voice, location, presence, messaging, conferencing, or any number of communications functionality should run on any system, any network, any vendor, any time. This should not be a technical issue, but one driven by the market place, and certainly should not be a nightmare.