ISBN: 0-471-41405 -0
Download (direct link):
Development studios. Most software developers are used to working with a development studio product that not only includes an advanced editor and debugger but that also contains other features that make programming easier. Some entire development studios are made specifically for wireless, and some existing ones have wireless features already included. As a result, the developer can write his or her C and Java programs as before, but he or she must use library calls for the wireless communications functions. The middleware then optimizes those requests and calls as much as possible and abstracts the details away from the developer. This feature gives lots of flexibility and control, but the developer has to do almost as much programming as he or she would have to do without the middleware. Another potential drawback is that both the client and the server usually need to have the middleware installed.
Of course, the question arises of who should use middleware. First, you need to determine whether it is possible to use middleware at all. If the desired middleware needs client-side software, the device of course needs to support that (open platform). Middleware can generally shorten the development time and cost at the expense of flexibility and differentiation. Today, with our shortage of skilled Information Technology (IT) personnel, it might be valuable not to have to hire skilled programmers but rather to just focus on the content and use middleware for the presentation. This situation especially applies to those companies that just want another channel for their content and/or to have legacy applications from the fixed Internet/LANs. For content developers who want to start from scratch and deliver content to mobile devices, however, WAP is likely the best solution.
One segment where middleware has proven successful is in vertical enterprise applications. This success is mostly due to the specialized devices that might include bar-code scanners and other add -ons. For those devices, it is a huge time saver to have a middleware solution that enables developers to quickly create advanced applications without having to worry how a bar-code scanner works. As the mobile Internet becomes pervasive, we are likely to see an increased market for such specialized devices and applications.
Overall, the price for using middleware is flexibility. Differentiating applications from the competition becomes more difficult, and there is a high dependence on the device properties. The choice is in the hands of the developer.
We can attack the problems in wireless environments in two ways: improving real performance and improving perceived performance. Real performance
involves handling interruptions, latencies, and avoiding overhead. The developer should avoid going into too much detail; rather, he or she should concentrate on making the application robust and efficient. These remedies make the application more fit to handle the unexpected and to perform better overall. The perceived performance produces improvements that are hard to measure but that help the user have a better experience. This concept includes keeping the user in control and informed and keeping the userís needs in mind at all times. You can use middleware to enable a third -party product to overcome some of these difficulties. The application type as well as the device and operating system used are parameters to consider when you are deciding whether or not to use middleware.
This page intentionally left blank.
Applications and Their Environments
This page intentionally left blank.
hen we described wireless networks in Part One, we examined most of the aspects that are relevant to the applications developer (except for where you can implement applications and how). One reason is because this area is so important, and we want to give it plenty of space. Another reason, however, is that we are migrating to a new way of implementing applications on wireless networks. Here, we use the term application architectures to denote the way in which applications connect to the mobile network and to other components.
Traditionally, technicians have implemented applications such as voice mail, Short Message Service (SMS), and so on as tightly connected to the nodes and switches of the wireless network, and these applications are specific to a certain mobile system (GSM, TDMA, and so on). This situation creates a very rigid architecture, where third-party applications developers have little or no chance of adding applications. In this chapter, we will examine how we can implement applications in second-generation (2G) and 2.5G systems and how we can accomplish this task on third-generation (3G) networks. In addition, we will take a closer look at the Application Programming Interfaces (APIs) that developers can use to access the features of mobile networks.
Architectures Now and in the Future