Wireless mobile communications in the near future will make it possible for one to communicate with any mobile device anywhere in the world. There is a bright future for mobile positioning as the key technology for enabling LBS applications, which themselves will become increasingly important as a key enabler of value added services.

Mobile positioning technology is also crucial for wireless emergency services.

Beans of Blue Vector say the new generation of products has “blurred the line” about what RFID middleware is. New software standards plus development efforts in the IT industry may blur the lines as to where middleware is needed. The next installment will examine these developments, and the final article presents views on RFID middleware’s future.

Middleware has emerged as an important architectural component in modern distributed systems. The role of middleware is to offer a high-level, platform-independent programming model to users (e.g. object-oriented or component-based) and to mask out problems of distribution. Examples of key middleware platforms include:

• Distributed Computing Environment (DCE)
• Common Object Request Broker Architecture (CORBA)
• Distributed Component Object Model (DCOM)
• Microsoft .NET
• Java RMI
• JINI
• Enterprise Java Beans (EJB)
• Web Services

Traditionally, such platforms have been deployed (with considerable success) in application domains such as banking and finance as a means of tackling problems of heterogeneity, and also supporting the integration of legacy systems.

More recently, middleware technologies have been applied in a wider range of areas including safety critical systems, embedded systems, and real-time systems. In addition, middleware is required to respond to emerging technical challenges as offered for example by:

• Multimedia
• Mobile computing
• Grid Computing
• Peer-to-Peer computing

It is now becoming apparent that established middleware technologies (such as the ones listed) are not able to respond to such diversity or to such technical challenges. The main reason for this is the black-box philosophy of existing platforms. In particular, existing middleware platforms offer a fixed service to their users, and it is not possible to view or alter the implementation of this service. Inevitably, the architecture of this platform then represents a compromise design featuring, for example, general-purpose protocols and associated management strategies. It is then not possible to form platforms to meet the needs of more specific target domains.

Middleware designers are aware of this problem and have responded with a number of initiatives. Focusing on CORBA for example, the OMG have introduced a series of platform specifications including real-time CORBA and Minimal CORBA. These are however specific solutions to specific domains and are not a general solution to this problem. Modern middleware platforms also typically offer more flexibility through mechanisms such as interceptors and configurable protocol stacks. These are important developments but, in our opinion, they do not offer a complete solution to the problem.

Rather, we believe that next generation middleware platforms should have the following properties:

• They should be configurable to meet the needs of a given application domain (e.g. to provide a minimal configuration for embedded systems)
• They should be dynamically reconfigurable to enable the platforms to respond to changes in their environment (e.g. to respond to dramatic fluctuations in network quality of service as experienced in mobile computing)

They should support the evolution of the design of the platform as requirements change over time (e.g. to respond to the need to support continuous media interactions).