The term middleware stems from the distributed computing area and refers to a set of standardized APIs, protocols, as well as infrastructure services for supporting the rapid and convenient development of distributed services and applications based on the client/server paradigm.When the first distributed applications became important in the early 1990s, application developers were increasingly faced with a multitude of heterogeneous programming languages, hardware platforms, operating systems, and communication protocols, which complicated both the programming and deployment of distributed applications. The term middleware refers to a layer that is arranged on top of operating systems and communications stacks and thus hides heterogeneity from the applications through a set of common, well-defined interfaces. In this way, the distributed client and server components an application is made up of can be programmed in the same manner as if they were executed on the same host. The application programmer does not have to care for aspects resulting from distribution, but can concentrate on the actual functions of the application.

The basis for nearly all middleware approaches was founded by the International Organization for Standardization (ISO), which fixed the common principles and structures of middleware in a framework known as Reference Model for Open Distributed Processing (RM-ODP). The main objective of ODP is to achieve distribution, interworking, and portability in an environment of heterogeneous IT resources and multiple organizational domains of different actors. ODP groups the functions of middleware into different transparency mechanisms, such as location, failure, persistence, and transaction transparency. Each of them provides a number of APIs and services to the developer for masking the complexity associated with the respective functions. For example, location transparency refers to the mechanisms for locating the server components of a distributed application in terms of a network location (i.e., it does not refer to a geographic location). It can be realized by naming or trading services, which map the name or the desired type of a server component onto its network address in order to make it accessible for other client components. Failure transparency, on the other hand, refers to recovery procedures that are automatically triggered in a transparent way during execution if one or several components fail. For a detailed description of ODP and its associated transparency mechanisms, see (ISO/IEC 1996–1998).

The common principles of ODP have been adopted by many middleware approaches, such as the different implementations of the Common Object Request Broker Architecture (CORBA), Java’s Remote Method Invocation (RMI), or several approaches for web services. All of them provide several infrastructure services and support different communication patterns, for example, synchronous and asynchronous interactions. However, all of them focus on demands resulting from distribution and communications, while there is a lack of functions for meeting the special demands of LBSs. This chapter identifies these demands and presents a conceptual, but not yet realized LBS middleware. Subsequently, the chapter introduces the Location API for J2ME and the OpenGIS Location Services, which have first adopted the idea of an LBS middleware and turned it into concrete specifications.

Contents

• Conceptual View of an LBS Middleware
• Location API for J2ME
  • Overview of J2ME
  • Location API
• OpenGIS Location Services
  • Information Model
  • Core Services
• Conclusion