ISBN: 0-471-41405 -0
Download (direct link):
Portal engine. This general user interface manager determines how the services that are offered by the service network will look to the user. This portal engine also includes the service management that PSEM provides. Typically, the portal is the first thing that a mobile Internet user sees when starting the WAP browser. The services that appear on the portal can then be customized either by the WAP interface or on a PC. Typically, a user wants to use the larger screen and richer input mechanisms of a desktop PC in order to perform the initial customization and then to perform minor alterations on the mobile device (adding/removing bookmarks).
When you create an application, it is interesting to know the platform for which you should create the application. Generally, the application should be made as platform independent as possible. Discussing in concrete words how to deploy an application without focusing on a single platform would be impossible, and this book should be more generic than that. Every vendor of application servers provides (or should provide) an SDK that describes the exact procedure. While application servers theoretically could be made from any PC, there are some additional requirements that operators (and others who host applications) must consider.
The application server is the middle-tier part of the three -tier architecture in Figure 9.6 and can be defined as follows:
An application server is the place where the application/service logic for end-user applications resides and executes.
Consequently, the application server is the node where most of the actual computing burden is placed. Features usually include the following:
Linear scalability up to a certain load. In other words, you can buy the server with one processor board to serve 100,000 users and then add another board to double the capacity. At first glance, this situation might sound like a natural feature, but it is never achieved by a platform that is not optimized from the beginning. There have been examples of service providers that did not anticipate the rapid growth of mobile Internet services and failed to build a scalable platform for the application. In the end, you might add twice the equipment and only achieve a 20 percent increase in capacity. This scalability is further supported by the architecture of the service network, where load sharing between different servers makes it possible to scale the application server functionality even more.
Robustness and redundancy. One processing board can go down without affecting the performance of the other. The server can still be running while the faulty board is removed and replaced by a new one. This feature is obviously crucial when you consider that the service provider might now be a telecommunications operator who is used to having services and equipment that have a system down time of fewer than 10 minutes per year. The operator will not tolerate that the service that his or her customer experiences on the mobile is disrupted every once in a while because of server maintenance. The server must also be capable of handling a large number of hits without crashing, which is difficult to achieve but possible.
Zero down time software upgrades. If the server is serving a couple of millions of users, it cannot be rebooted if the applications on it are
upgraded or installed. This situation requires a new way of thinking, because every second of service down time (when users cannot access the service) means a loss of revenue and customer dissatisfaction.
Multilanguage and platform support. While an operator or content provider obviously has to choose what application server to use, the application server must be capable of talking to service network components from other vendors as well. In other words, CORBA should be supported in order to enable the use of the standardized APIs (Parlay, 3GPP, and so on). For the convenience of the developer, the most common programming languages, such as C, C++, and Java, should be supported.
Manufacturers of application servers include IBM, Ericsson, and Sun Microsystems, to name a few. You can find more information about specific products on the developerís Web sites of those respective companies. Figure 9.13 shows an example of the exterior of an application server.
Application servers not only contain a run-time environment for applications, but also have certain middleware components that make development easier. These components can include object request brokers, transaction processing support, and message-oriented middleware.
Usually, the developer does not have to own an application server but can buy a hosting service from the service network provider (commonly the same as the network operator). We will see the advent of many new players in this field in upcoming years.
As the complexity of the services adds up and more and more subscribers start using them, a good service management functionality is necessary. This functionality enables the owner of the service network to look at statistics and logs and to add and modify the userís portfolio. The more complex the solution becomes, the larger the need for an organized way to install new applications and update the service offering to individual users. In addition, it is valuable to be able to track the usage of individual applications and their geographical distribution. The live monitoring and changes to the configurations are usually done via Web interfaces in order to minimize the complexity for maintenance personnel.