2.5 Aspects to be modeled_移动系统中间件建模与仿真-QQ阅读男生轻小说网

上QQ阅读APP看书，第一时间看更新

2.5　Aspects to be modeled

In the preceding sections, we have summarized the characteristics of the middleware for mobile systems, especially by emphasizing the main difference between the middleware for distributed systems and the middleware for mobile systems. Based on the understanding, we will discuss now which aspects should be modeled for the middleware for mobile systems. We will consider the items listed in the general framework for capturing the middleware (Table 2.1). We separate the aspects into two parts: the very general aspects to deal with mobility, and the aspects to model the middleware.

2.5.1　Modeling mobility

We combine the discussion of space and wireless network connection together, since they cause the main difference between distributed systems and mobile systems.

Space and wireless network connection Recall the conclusion given in last section, space and wireless connection are the two most important aspects to deal with mobility. Space decides allowed roaming style of components, influences the interaction and communication models of components, and hence deciding the preferable design strategy. Different treatment and consideration of wireless connection leads to various communication paradigms. At the same time, the component interaction and configuration are associated dynamically to space and wireless connection. The change of space and wireless connection causes dynamic change of the interaction and configuration. Computation is also related to such dynamic change.

In fact, the main difference between distributed systems and mobile systems is caused by the possibility of roaming and wireless connection. Correspondingly, space and wireless connection are two very basic elements need to be considered in order to model mobility generally. Especially, they need to be treated as first class entities, i.e., they have a name and they are refinable. It is important for a model to be capable of dealing these elements throughout the software development life cycle, starting from the definition of the environment where mobility occurs, through designing and reasoning about a mobile system, and down to the tools provided to programmers. Making the location and network connection explicit into the software architecture at the specification level enables us to formally reason about it in the same manner as we reason about other components in a distributed system.

More specifically, modeling space includes two basic aspects:

the definition of space, and the relationship with other components and elements (structural).
the allowed movement of components inside such spaces, the dynamic change of component interaction, configuration and computation when components move (behavioral).

Modeling wireless connection also includes two basic aspects:

the definition of wireless connection, and the relationship with other components and elements (structural).
the connection and disconnection of the wireless connection, and the influence to component interaction, configuration and computation (behavioral).

Dynamic change The stability assumptions in distributed systems make the software architecture static. Dynamic changes are generally only important for safety- and mission-critical systems, such as air traffic control or telephone switching systems, where shutting down and restarting the system incurs unacceptable delays and failures. On the contrary, dynamic change is a main characteristic of mobile systems. The configurations and interactions change dynamically according to the movement of the components, the change of wireless connection, the change of context that may include resources, services, etc. Consequently, modeling dynamic change is also a very basic aspect to deal with mobility. The behavioral part of modeling space and wireless connection in previous section is covered here. The behavioral part of component interoperability and context-awareness in the following sections is also covered here.

2.5.2　Modeling other aspects

Besides the mentioned general aspects to deal with mobility, we consider now the other aspects listed in the framework.

Component interoperability　It is important to model the framework for component interoperability in the middleware in order to understand how the middleware makes the components a single interoperable coherent system, and how they handle a collection of independent components. In a mobile setting, the framework needs to manage the roaming application components, the unstable wireless connection, the dynamic context, etc. It also provides other specific functionalities to satisfy application requirements, for instance, continuous service or access to other components. Thus, the main components that construct the framework need to be modeled. How the components cooperate to perform a task needs to be modeled too. These described aspects can be separated into structural and behavioral part respectively. Actually, component interoperability is related to component interaction very much, which provides underlying support to realize the needed framework, and it is very difficult to separate them. In most cases, modeling component interaction covers already component interoperability. Therefore, we will put component interoperability under component interaction.

Component interaction Component interaction is a very important aspect of the middleware. The main goal of middleware is to facilitate component interaction of components. Component interaction covers component communication, collaboration, and coordination. These different aspects are not orthogonal and there is no clear boundary. For example, components need a method to communicate with each other through the network. The method can be message based, transactional based, event based, etc. The communication requires the coordination and synchronization between different actions and components, and the components collaborate with each other in order to perform a task.

How to discover who is around for interaction with other components in the dynamic environment is an important characteristic that differentiates among middleware that supports mobility. In a mobile setting, the components involved in an interaction change dynamically due to their migration or connectivity patterns. This results in dynamic reconfiguration among these components. While the static assumption of network structure, network connection and execution context in distributed systems makes the component interaction quite static. The components involved for interactions are generally fixed. Such fixed configurations will not change till a dynamic change happens. And the messages for communication are always supposed to be successfully transmitted by the network.

Modeling component interaction should include several aspects: the roles played by the components during interaction, the methods used for communication, the coordination mechanisms, the influence on the coordination and communication caused by the movement of components and change of connectivity, etc.

Context-awareness　The middleware for mobile systems presents great diversity with how to treat context-awareness. Some middleware still holds distribution transparency. Some middleware provides location related and context information to the applications. In addition, the definition of context and the level of context-awareness are various in different middleware. Hence, modeling context-awareness varies in different middleware platforms. There are two important aspects to model context awareness:

The structural part of the context. There exist different definitions of context (see Section 2.3). In spite of that, the common aspect of context is: the context [121] of a mobile unit is determined by its current location which, in turn, defines the environment where the computation associated with the unit is performed. The context may include resources, services, as well as other components of the system. Therefore, it is important to clarify what aspects belong to the context, and their relationship with location and wireless network connection, etc.
The behavioral part of the context. It includes: how the migration or connectivity patterns changes the context, what will happen when the context changes. Usually, context changes cause dynamic adaption of the middleware. This leads back to the previously explained dynamic change. We think dynamic change is the key to model context-awareness. The other aspects are not so important since the are rather implementation related, for example how to present the context information to applications, and which degree of context-awareness should be presented to users (i.e., how much mobility should the users perceive), and who will activate the adaption, i.e., the predefined behavior in the application or the input from the user, etc.

(1) Roaming means that devices can change its location.

(2) After issuing a request, a client component can continue to perform its operations and synchronize with the server component until the server component responds.