Using Coordination Middleware for Location-Aware Computing:A Lime Case Study Amy L.Murphy1,2and Gian Pietro Picco2
1Dipartimento di Elettronica e Informazione,Politecnico di Milano,Italy
E-mail:picco@elet.polimi.it
2Department of Computer Science,University of Rochester,NY,USA
E-mail:murphy@https://www.doczj.com/doc/e615874734.html,
Abstract.The decoupling between behavior and communication fos-
tered by coordination becomes of paramount importance in mobile com-
puting.In this scenario,however,coordination technology is typically
used to deal only with the application data necessary to orchestrate the
process activities.In this paper,we argue instead that the very same
coordination abstractions can be used e?ectively to deal also with in-
formation coming from the physical context—a fundamental aspect of
mobile computing applications.
We cast our considerations in Lime,a coordination model and middle-
ware designed for mobile computing.To support our arguments with
concrete examples,we report about the development of Tuling,a proof-
of-concept application enabling the tracking of mobile users.The lessons
learned during development enable us to assess the feasibility of the ap-
proach and identify new research opportunities.
1Introduction
Mobile computing de?nes a challenging environment for software development. Communication is enabled by wireless links,which are less reliable and intrinsi-cally dependent on the relative positions of the mobile parties in communication. Similarly,location a?ects the overall context perceived by a mobile unit,by con-straining not only the available communication parties,but also the data avail-able for computation,the set of accessible services,and in general the resources available to a component.
It has been observed[13]that software development in the mobile environ-ment can be tackled successfully by exploiting a coordination perspective.The decoupling between behavior and communication fostered by coordination en-ables one to separate the applicative behavior of components from the con-tinuously changing context in which they are immersed.Examples of systems that have applied this intuition to deal with physical mobility of hosts or log-ical mobility of agents include Klaim[10],xmiddle[7],Tucson[12],Mars[2], and Lime[8].In all of these systems,a shared data structure—typically a tu-ple space—is used to store the data available to mobile units and to represent naturally the context available to them.Nevertheless,all of these systems focus
2Amy L.Murphy and Gian Pietro Picco
on providing support for coordination through a context consisting essentially of
application data.Little or no support is provided for constraining the application
behavior based also on the physical context.
Clearly,this is a limitation.Dealing with a changing physical context is fun-
damental in many mobile applications.Physical context information can be very
diverse,and include local system information such as battery level or signal-noise
ratio,or environmental information such as light intensity,temperature,or am-
bient noise.Among all,location is possibly the most relevant context element,
in that it often quali?es the values of the others.For example,a temperature
reading becomes more meaningful when accompanied by the identity of the room
where it was sensed.The point,however,is that the actions of an application
component in a mobile environment may depend on one or more of these context
information values and modeling physical context becomes a necessity.
At the opposite extreme of coordination approaches,several middleware sys-
tems have been proposed that explicitly tackle the problem of managing a dy-
namically changing context.Relevant examples include the Context Toolkit[3],
Odyssey[11],Aura[5],Gaia[14],and Owl[4].The focus of these systems is on
allowing applications to retrieve information about context,either proactively
(by directly querying some context representation)or reactively(by subscribing
to changes in the context information).The middleware takes care of properly
disseminating the context information to the involved parties,and hence greatly
simpli?es the management of physical context used in mobile applications.On
the other hand,these systems provide little or no support for representing and
managing the data context,used for coordinating the behavior of the application
components.
In this paper,we argue that the gap between the two aforementioned perspec-
tives can be reduced,if not eliminated,by exploiting coordination abstractions
also for the management of the physical context.Once acquired by appropri-
ate sensors,context information is essentially like any other data,and hence
can be treated as such in a data-centric coordination approach.The very same
primitives used to manipulate,retrieve,or react to available data for the sake
of coordination can now be used for dealing with physical context information.
These two traditionally separate dimensions are uni?ed under a common set of
abstractions,simplifying considerably the design and implementation of mobile
applications.
Although our considerations are in principle applicable to any data-centric co-
ordination approach,in this paper they are cast in Lime[8],a coordination model
and middleware expressly designed for mobile computing.A concise overview of
Lime is provided in Section2.Section3illustrates the premise of our approach, and describes how a coordination middleware can be used to disseminate physical
context information.The implications of our design approach can be understood
and assessed only through the reality check provided by application development.
Hence,to support our arguments with concrete examples,in Section4we report
about the design and implementation of Tuling,a proof-of-concept application
providing location tracking of mobile users.The lessons learned from this ex-
Using Coordination Middleware for Location-Aware Computing3 perience enable us to assess,in Section5,the feasibility of the approach and identify new research opportunities.Finally,Section6ends the paper with brief concluding remarks.
2Lime:Linda in a Mobile Environment
The Lime model[8]de?nes a coordination layer for applications that exhibit log-ical and/or physical mobility,and has been embodied in a middleware available as open source at https://www.doczj.com/doc/e615874734.html,.Lime borrows and adapts the communication model made popular by Linda[6].
In Linda,processes communicate through a shared tuple space,a multiset of tuples accessed concurrently by several processes.Each tuple is a sequence of typed parameters,such as<"foo",9,27.5>,and contains the actual information being communicated.Tuples are added to a tuple space by performing an out(t) operation.Tuples are anonymous,thus their removal by in(p),or read by rd(p), takes place through pattern matching on the tuple content.The argument p is often called a template,and its?elds contain either actuals or formals.Actuals are values;the parameters of the previous tuple are all actuals,while the last two parameters of<"foo",?integer,?float>are formals.Formals act like“wild cards”and are matched against actuals when selecting a tuple from the tuple space.For instance,the template above matches the tuple de?ned earlier.If multiple tuples match a template,selection is non-deterministic.
Linda characteristics resonate with the mobile https://www.doczj.com/doc/e615874734.html,munication is implicit,and decoupled in time and space.This decoupling is of paramount importance in a mobile setting,where the parties involved in communication change dynamically due to migration,and hence the global context for operations is continuously rede?ned.Lime accomplishes the shift from a?xed context to a dynamically changing one by breaking up the Linda tuple space into many tuple spaces,each permanently associated to a mobile unit,and by introducing rules for transient sharing of the individual tuple spaces based on connectivity. Transiently Shared Tuple Spaces.In Lime,a mobile unit accesses the global data context only through a so-called interface tuple space(its),permanently and exclusively attached to the unit itself.The its,accessed using Linda primitives, contains tuples that are physically co-located with the unit and de?nes the only data available to a lone unit.Nevertheless,this tuple space is also transiently shared with the its s belonging to the mobile units currently accessible.Upon arrival of a new unit,the tuples in its its are merged with those already shared, belonging to the other mobile units,and the result is made accessible through the its of each of the units.This sequence of operations,called engagement,is performed as a single atomic operation.Similarly,the departure of a mobile unit results in the disengagement of the corresponding tuple space,whose tuples are no longer available through the its of the other units.
Transient sharing of the its is a very powerful abstraction,providing a mobile unit with the illusion of a local tuple space containing tuples coming from all the
4Amy L.Murphy and Gian Pietro Picco
units currently accessible,without any need to know them explicitly.Moreover, the content perceived through this tuple space changes dynamically according to changes in the system con?guration.
The Lime notion of a transiently shared tuple space is applicable to a mobile unit regardless of its nature,as long as a notion of connectivity ruling engagement and disengagement is properly de?ned.Figure1shows how transient sharing may take place among mobile agents co-located on a given host,and among hosts in communication range.Mobile agents are the only active components,and the ones carrying a“concrete”tuple space;mobile hosts are just roaming containers providing connectivity and execution support for agents.
Operations on the transiently shared tuple space of Lime include those al-ready mentioned for Linda,namely out,rd,and in,as well as the probing operations rdp and inp whose semantics is to return a matching tuple or return null if no matching tuple exists at the time the query is issued.For convenience Lime also provides the bulk operations rdg and ing that return a set of tuples that match the given pattern.If no matching tuples exist,the set is empty.
Restricting Operation Scope.The idea of a transiently shared tuple space re-duces the details of distribution and mobility to changes in what is perceived as a local tuple space.This view is powerful as it relieves the designer from speci?-cally addressing con?guration changes,but sometimes applications may need to address explicitly the distributed nature of data for performance or optimization reasons.For this reason,Lime extends Linda operations with scoping parame-ters,expressed in terms of agent or host identi?ers,that restrict operations to a given projection of the transiently shared tuple space.
The out[λ](t)operation extends out by allowing the programmer to specify that the tuple t must be placed within the tuple space of agentλ.This way,the default policy of keeping the tuple in the caller’s context until it is withdrawn can be overridden,and more elaborate schemes for transient communication can be developed.Location parameters are also used to annotate the other operations to allow access to a slice of the current context.For instance,rd[ω,λ](p)looks for tuples matching p that are currently located atωbut destined toλ.Lime allowsωto be either a host or an agent,enabling either an entire host-level
Fig.1.Transiently shared tuple spaces encompass physical and logical mobility.
Using Coordination Middleware for Location-Aware Computing5 tuple space to be queried or a subset of the host-level tuple space containing the tuples speci?c to the named agent.
Reacting to Changes.In the dynamic environment de?ned by mobility,reacting to changes constitutes a large fraction of application design.Therefore,Lime extends the basic Linda tuple space with a notion of reaction.A reaction R(s,p) is de?ned by a code fragment s specifying the actions to be performed when a tuple matching the pattern p is found in the tuple space.A notion of mode also is provided to control the extent to which a reaction is allowed to execute.A reaction registered with mode once is allowed to?re only one time,i.e.,after its execution it becomes automatically deregistered.Instead,a reaction registered with mode oncepertuple is allowed to?re an arbitrary number of times,but never twice for the same tuple.Details about the semantics of reactions can be found in[8]and a formal semantics is available in[9].Here,it is su?cient to note that two kinds of reactions are provided.Strong reactions couple in a single atomic step the detection of a tuple matching p and the execution of s.Instead, weak reactions decouple the two by allowing execution to take place eventually after detection.Strong reactions are useful to react locally to a host,while weak reactions are suitable for use across hosts,and hence on the entire transiently shared tuple space.
Exposing System Con?guration.With the perspective presented thus far,ap-plications are aware only of changes in the portion of context concerned with application data.Although this is enough for many mobile applications,in others knowing which hosts are connected also plays a key role.For instance,a typical problem is to react to departure of a mobile unit,or to determine the set of units currently belonging to a Lime community.Lime provides this form of awareness of the system con?guration by using the same abstractions already discussed: through a transiently shared tuple space conventionally named LimeSystem to which all agents are permanently bound.The tuples in this tuple space contain information about the mobile units present and their relationship,e.g.,which tuple spaces they are sharing or,for mobile agents,which host they reside on. Insertion and withdrawal of tuples in the LimeSystem is the prerogative of the run-time support.Nevertheless,applications can read tuples and register reactions to respond to changes in the con?guration of the system.
3Representing Physical Context in Lime
Applications written for the mobile environment must have access to their own data as well as the data of the other components within range.Providing this access while ignoring the details of communication is the primary goal of Lime and of other coordination systems targeting the mobile environment.In addition to application data,many mobile applications are characterized by their need to respond to the environment in which they?nd themselves,adapting application behavior as their location,bandwidth,or environmental parameters change.In other words,they must be able to react to changes in the physical context.
6Amy L.Murphy and Gian Pietro Picco
The LimeSystem tuple space described previously shows that the transiently
shared tuple space style of coordination promoted by Lime can be used success-
fully to provide mobile applications access to one form of context,namely the
identity of accessible hosts and agents.Our goal here is to show that Lime can
similarly be used to represent,share,and interact with other aspects of context
as well.We further show that by placing context information into a transiently
shared tuple space applications obtain easy access to what we refer to as the
distributed context,or the context of all components within range.
At its core,our idea is simple:insert context information into a transiently
shared tuple space thus allowing all connected components to access it through
the proactive and reactive constructs of Lime.In this section we describe the
representation of context information in the tuple space,the primary access
mechanisms,and the bene?ts provided to the application programmer. Making Context Accessible.Our work focuses on the sharing of and interaction
with context data through tuple spaces,intentionally leaving aside the issues
related to detecting context information as well as the format of that information.
Therefore,we do not focus on any speci?c sensing technologies nor even on any
speci?c type of context information.Instead,we provide a general infrastructure
to exploit and disseminate context,and that can be easily adapted to the needs
of any system.The key component of our infrastructure providing this isolation
is a context agent that interacts with the sensors and with Lime.
The context information to be made available is represented as tuples,iden-
tical in all respects to traditional application data tuples.Interestingly,this can
be exploited to represent single values as well as sequences of temporally related
values to maintain history or for aggregation of context information.In prin-
ciple,it is therefore possible to mix data and context tuples in a single tuple
space.This,however,leads to a cumbersome design that imposes restrictions on
applications(such as requiring that no application tuple use the same pattern as
any context tuple)and mixes the interaction with the two types of data.There-
fore,ideally the two kinds of data should be insulated from one another.Lime
supports this separation with a mechanism for creating multiple tuple spaces,
uniquely identi?ed by name,and whose contents are independent.By creating a
separate context tuple space(e.g.,named context),application tuple formats
remain unrestricted and interaction with context information is made explicit
by issuing operations on the context tuple space.
For applications residing on the same host as the context agent,the context
information is accessible locally by issuing the normal Lime operations on a
context tuple space.Such interaction enables an application to query for the current context,and attach this to generated data.For example,a video player
can adjust its bu?er size based on the currently available local memory.This
memory level information is retrieved from the local context tuple space.
Because Lime tuple spaces are transiently shared,the information in the con-
text tuple space is also available to all connected components,yielding what we
refer to as the distributed context.For example,?re?ghters can spread location-
enabled temperature sensors throughout a forest?re and annotate a map with
Using Coordination Middleware for Location-Aware Computing7 the temperature gradient from the information available in the distributed con-text.Even if only a limited number of sensors are within range,those connected provide the context for the area immediately surrounding the?re?ghter gener-ating the map.
Interacting with Context.Middleware,and in general systems targeted toward the mobile environment,have evidenced that access to context information should be both proactive and reactive,meaning that a program should be able to pull the information on demand or have it pushed whenever it changes.By representing the context information inside a Lime tuple space,both styles of operation are available.Proactive operations map to the query operations of Lime(e.g.,rdp)while reactive mechanisms are enabled by strong and weak Lime reactive statements.Furthermore,the Lime extensions to control scope enable operations over the entire distributed context or over a projection of the
context tuple space,tailoring operations to apply to all hosts in range or only a single host.
For applications such as the video player described previously,the query op-eration rdp,restricted in scope to the application’s own host-level tuple space, returns the needed current available memory.The same operation can be used to retrieve the context of a remote host simply by changing the scope parameters. Lime bulk operations,such as rdg,are especially useful to retrieve historical context.For example,an application validating the functioning of the air condi-tioning in a building can query for the history of temperatures in a given room.
In our previous Lime programming e?orts,we found that although the query operations are useful,the core application functionality often utilizes reactive constructs.With respect to context information,reactions are most useful for monitoring and immediately adapting to changes.For example,a reaction over the host’s own context tuple space can notify an application when its battery power is low.Changing the scope of the reaction to monitor a remote host’s bat-tery can trigger a modi?cation in the mode of interaction between the two hosts. Alternately,to keep the map of temperatures up to date,a reaction over the dis-tributed context can be registered to?re every time any sensor’s temperature value changes.
Finally,the distributed context can easily be searched,providing a dimension of accessibility not present in most context systems.For example,a query can be formed to?nd one or all components at a speci?c location in space.This powerful operation uses the same Lime primitives as before,rdp in this case,and does not require any kind of server support,a solution common with other context-aware systems.Such serverless operation makes our solution for managing context more amenable for mobile ad hoc networks,and other highly dynamic scenarios. Bene?ts to the Application.The ideas presented here unveil how a variety of context information can be represented in the context tuple space and accessed by connected components using the usual Lime primitives.This approach has two main bene?ts.First,the management of context is decoupled from the ap-plications that use it.This implies that the context maintenance mechanisms
8Amy L.Murphy and Gian Pietro Picco
can easily be substituted or extended to present more context information from additional sensors.For example,if an application is designed to use location information to build a map of connected users,the location context information can be changed from GPS to an indoor infrared tracking system without changes to the application as long as the tuple format does not change.
Second,placing context information into a tuple space uni?es the manage-ment of application data exploited for coordination,and of the physical context perceived by the application.This allows programmers to deal with both using the same interface with evident bene?ts in terms of ease of development and understanding of the resulting implementation.
4Tuling:Tracking Users in Lime with GPS
To further explore and validate our ideas about representing context in Lime,we chose to focus on a single aspect of context,namely location in physical space. This choice is motivated by the observation that location is critical to many mobile applications.Often,context information is dependent on the particular location where it is sensed.Moreover,location has a value per se,in that it provides a direct and intuitive way to express mobility of users.
In this section,we discuss the design and implementation of Tuling,an application for collaborative exploration of a space.Although we have already discussed the main idea for representing and interacting with context in Lime,it is only through the elaboration of these ideas in a real application that they can be fully appreciated and we can report about the ease of incorporating location context into an application.
Tuling is intended to be used by multiple individuals moving through a common environment,each equipped with a GPS-and wireless-enabled PDA. While the immediate goal of this application is to provide a proof-of-concept for our approach,we can envision the functionality provided as useful in several real-world scenarios,e.g.,coordination of a rescue team deployed in a in a disaster scenario.The major portion of the display of each user,as seen on the left of Figure2,is a representation of the user’s current location in space,where a sequence of dots indicates her past movement itinerary.When a new user comes within range,her name is displayed in the box on the top right of the display. To allow users to coordinate their actions as they move,each user can specify a monitoring mode for viewing the movement of the others by?rst selecting the user,then pressing one of the buttons to the top right.
By pressing the monitor button,a user’s movements are marked on the screen as long as she is connected.When the user disconnects,her name disappears from the list,but the dots remain on the screen.In monitor mode,the user’s displayed location is kept as up to date as possible,but only the itinerary during connection is tracked.To retrieve the history of movement that occurred before connection,a user must press the getItinerary button.Instead of being a continuous operation such as monitoring,this is a one-time operation that displays the entire history of movement(up to that moment)for the selected user.Another one-time operation
Using Coordination Middleware for Location-Aware Computing9 is to display the current location of a user by pressing the getCurrent button.
The?nal mode is simply to ignore a user.
In addition to these monitoring modes,Tuling provides two other that ap-ply globally to all users that come within range.These modes are available as menu options and are designed to always retrieve the history for every users,and to actively monitor the movement of every user within range.When both these modes are active,a user’s display shows the entire itinerary of every user she has encountered,i.e.,including movements that occurred before and during connec-tion.In a disaster recovery scenario,this mode can be useful for a supervisor to monitor the movements of all the members of a team around her.
Tuling also allows users to add annotations,such as a textual note or a digi-tal photograph,to their own current location.For instance,after an earthquake,
Fig.2.Screenshot of two Tuling users,Tom(the top image)and Ema,after discon-nection.Before the two users were disconnected,each was monitoring the location of the other,but only Ema had retrieved the history of Tom.After disconnection,the movements of the users are not visible to one another,but only to themselves.
10Amy L.Murphy and Gian Pietro Picco
annotations could take the form of photographs of damaged walls or descriptions of work to be completed at a location.These annotations are indicated on the display with a special icon:by clicking on the icon,the annotation can be viewed as long as the user is connected.1
As already noted,Tuling can be useful in disaster recovery scenarios for allowing workers to coordinate their actions.For example,workers monitoring the current movements of others in the area can either avoid one another in order to explore di?erent territory,or gather to discuss face to face their?nd-ings.Annotations created by survey workers can be evaluated by aid workers to direct supplies to speci?c areas.The bene?ts of using Tuling include the ability for users to interact without requiring line-of-sight,the enabling of impromptu sharing of information without the required support of a central server,and the variety of monitoring modes to adjust the communication overhead,and thus battery requirements,on a per-user basis.
As a proof-of-concept application,Tuling demonstrates how the operations available in Lime are both natural and su?cient to provide the range of inter-action necessary for exploiting context,as we illustrate in the remainder of this section.
Representing and Updating Location Context.The combined requirements to both monitor the current location of a user and to display the previous itinerary require that Tuling provide access to the current location and to the previous locations of a user.The current location is represented by a single tuple contain-ing the GPS coordinates and a timestamp.To update this tuple,we?rst insert the new location tuple,then remove the old.The motivation for this sequence of operations is to ensure that a location is always accessible to a probe operation. It is true that the old value may be returned instead of the new,but the two values are unlikely to be signi?cantly di?erent,and furthermore the timestamp can be examined for freshness.
Because a host has only a single current location,we needed a separate tuple representation for the location history,i.e.,the user itinerary.We explored the idea of having one tuple for each previous location,simply changing the pattern to include a new?eld with the label history.This solution turns out to be unreasonable because the overhead necessary to retrieve the entire history of a user is proportional to the number of tuples retrieved.Therefore,we opted for grouping multiple locations together into a single stride tuple that contains a sequence number and a list of locations.The number of locations in the stride list is tunable.We chose a value that balances the overhead of retrieving all the stride tuples to build a history with the overhead of updating the stride tuple with each new location.In other words,to keep the entire history in the tuple space,each time a new location is generated the most recent stride tuple, identi?ed by a sequence number,is removed,updated,and reinserted into the 1The choice of making annotations inaccessible while users are disconnected was moti-vated by the performance considerations discussed later.If needed by an application, this choice and be easily reversed,but with an accompanied increase in overhead.
Using Coordination Middleware for Location-Aware Computing11 tuple space.This solution also opens up opportunities for implementing“garbage
collection”of old stride tuples.
It is worth noting that both the updating of the current and stride tuples
are operations entirely local to the agent performing them.Therefore they are
executed with very low cost and generate low system overhead.
Accessing Location Context.Tuling uses a combination of reactions and probe
operations,both over the federated tuple space as well as speci?cally scoped,to
implement both the functionality of the buttons on the top right of the display
and the alternate modes to monitor and retrieve the histories of all users.
To our surprise,the LimeSystem continued to be an integral part of the oper-
ation of Tuling.For example,to display the name of each user within range,
Tuling employs a reaction on the LimeSystem tuple space.By exploiting the fact that Lime keeps this list up to date,users are able to select monitoring modes
on a per user basis,as well as see,at a glance,which users are connected.
As already mentioned,the monitor mode allows a user to be tracked while
they are connected.This essentially involves reacting to a change in the user
location and updating the display—an operation that naturally calls for a Lime
reaction.Therefore,the tracking functionality is implemented with the installa-
tion of a oncepertuple weak reaction restricted to the projection of the tuple
space of the selected user.The pattern of the reaction is that of current location
tuples.
The functionality of both the getItinerary and getCurrent buttons are im-
plemented with probe operations over the projection of the tuple space of the
selected user.The?rst exploits a rdg operation for stride tuples to retrieve all of
the tuples of the itinerary.The latter uses a similarly scoped rdp for retrieving
the current location tuple.
These explicitly selected modes o?er the ability to tailor monitoring on a per-
user basis,constructing her view of the environment and controlling the amount
of system resources dedicated to monitoring each user.If such tight controls
are not necessary,the two options for monitoring all users and automatically
downloading the histories of all users can be enabled.Monitoring all users in
Lime is accomplished with a single oncepertuple weak reaction registered on the transiently shared tuple space,with the pattern of the current location tuples.The reaction?res each time any user’s location changes,updating the display accordingly.
As in the case of a speci?c user’s itinerary,retrieving all itinerary information
also uses the bulk operation rdg to query a speci?c user’s projection of the tuple
space for all stride tuples.To accomplish this for all users,Tuling registers a
reaction on the LimeSystem tuple space to?re each time any host arrives.This,
in turn,causes the rdg to be invoked as part of the reaction code.
Exploiting Location.While the previously described functionality is designed
to show how context information can be shared and visualized,the annotation
feature of Tuling demonstrates how applications can attach location context
to application data.
12Amy L.Murphy and Gian Pietro Picco
Annotations can be either simple text,or a?le containing,for example,an image.After the annotation has been created,Tuling associates it with the user’s most recent location.To?nd it,Tuling queries the local context tuple space using a probing read,rdp.This returns a tuple containing the timestamp and the current location coordinate.These pieces of information,along with the annotation are combined into a single annotation tuple,which is inserted into a regular Lime tuple space,making it accessible to other users.
One of the requirements of Tuling is to display the existence of an anno-tation as an icon on top of the normal location icon.With the implementation of annotations just described,the only way to do this is to query for the ac-tual annotation tuples at the same time that the itinerary tuples are retrieved, or to react to annotations when a host is being monitored.If the annotations themselves are large,this creates an unreasonable amount of overhead,especially wasteful if the annotations are not viewed eventually by the user.Therefore,we modi?ed the representation of annotations in the tuple space,e?ectively creat-ing two tuples with the same information as the original tuple.The?rst tuple, contains only the location and an annotation identi?er.It is this tuple that is retrieved and monitored in the cases above,reducing the overhead because the identi?er is small in comparison to a typical annotation.The second tuple con-tains the annotation identi?er and the actual annotation.This tuple is retrieved on demand when a user opts to view the annotation.The result,however,is the restriction that annotations can only be viewed while users are connected,a reasonable compromise for e?ectively managing overhead.
5Discussion and Lessons Learned
Experience with Tuling provides evidence to support our argument for placing context information into the tuple space.In this section we discuss the relation-ship between our work and others and discuss extensions to Lime that would better support context.
Related Work.The uni?cation of access to both data and context is a factor that distinguishes our work from that of other systems for accessing context. For example,the Context Toolkit[3]wraps context providers with a standard interface that provides query and noti?cation access.In Lime,these two modes of interaction are naturally provided by the query and reaction operations,the same operations used for application data access.
Furthermore,the Context Toolkit provides a separate service discovery server that identi?es context providers to which the programmer can explicitly bind to receive context information.By using Lime,this type of centralized service dis-covery is not necessary.Instead,the currently available components are identi?ed from the fully distributed LimeSystem tuple space,which is also accessed by the same tuple space operations.Finally,in Lime,while it is possible to access spe-ci?c context providers by limiting the scope of the operations,it is also possible to access the entire distributed context with the Lime primitives,something
Using Coordination Middleware for Location-Aware Computing13 that while possible in some other systems,would require additional,non-trivial
programming e?ort.
Placing context information in a Lime tuple space also simpli?es access and
reaction to the context of remote components.This is fundamentally di?erent
from the context reaction mechanisms provided by Odyssey[11].In Odyssey,a
component can register to be noti?ed when the local context changes,allowing,
for example,a server to detect a bandwidth reduction.However,Odyssey is
not designed for servers to monitor context changes at the mobile client.In
Lime,instead,registering for remote changes is as straightforward as registering for local changes.Furthermore,the implementation of weak reactions ensures
reasonable performance.
The work presented here is also related to the many other coordination ap-
proaches designed to address the concerns of the mobile environment.We chose
Lime as our foundation both because we are most familiar with it,and because it is well suited to the needs of interacting with context.In principle,it should be possible to apply our idea of representing context as data in other coordi-nation systems,although we are not aware of any work from the coordination community in this direction.
Lime Extensions.While the current implementation of Tuling well serves as a proof-of-concept,the development process illuminated several directions for extending Lime to better support interaction with context information,and most likely with application data as well.These include the ability to atomically change the contents of a tuple,to sequentially order a set of tuples,to replicate data,and to search for tuples based on a range.These features were initially left out of Lime,in an e?ort to strive for a minimal and yet expressive application programming interface.In the light of their relevance for improving handling of the physical context,however,we are currently reconsidering this decision and planning to include these features in the next release of our middleware.
As explained in Section4,the updating of the current location?eld is ac-
complished by?rst outputting the new tuple,then removing the old tuple.The
result is that in the short interval between the two operations,the component
has two current locations,and a probe operation such as rdp is just as likely to
return the old tuple as it is the actual current tuple.Reversing the operations,
however,leaves an interval where a component has no location and rdp may
return null.Both of these conditions could be avoided if Lime provided either
an atomic“change”operation,performing in and out in the same atomic step,
or a generic transaction construct for grouping arbitrary Lime operations.
When Tuling retrieves itinerary tuples to display the history of movement
of a user,the Lime bulk operation rdg returns the set of all stride tuples.Al-
though this set does not have an inherent ordering according to Lime and Linda
semantics,in Tuling an order is implied by the stride sequence number.Cur-
rently,the application uses this value to sort the stride tuples before visualizing
them.It would be convenient if Lime bulk operations were extended to allow
the speci?cation of a?eld over which an ordering is automatically imposed,thus
releasing the programmer from the burden of coding ordering explicitly.
14Amy L.Murphy and Gian Pietro Picco
Another feature to consider adding to Lime is replication.In Tuling,the previous locations of the other components are e?ectively replicated at the ap-plication level,to enable its visualization.Location information,however,is not duplicated within the tuple space.Therefore,if A copies B’s history,and then later meets C,the information about B is outside the tuple space and therefore not accessible to C.Several e?orts in the mobile ad hoc community have looked at the issue of replication[1,7,15],but none of the solutions is immediately applicable to the tuple space environment.
Finally,a useful operation to add to Tuling is to support a query such as “?nd all components within a radius r from point(x,y).”Such a query requires a range search inside the tuple space,while Lime provides only value matching. Supporting this functionality requires a change in the tuple space implementa-tion underlying Lime,as well as a change in the interface to the tuple space. Nevertheless,this would provide a great improvement in the expressiveness of the system.In Tuling,the user could monitor an area around herself,or even request information in an area away from her current position.
6Conclusions and Future Work
Our evaluation thus far has focused on location context.While location is useful for many applications,other aspects of context also have direct use for mobile applications.For example,by providing available bandwidth,applications can adjust their use of the tuple space,querying for large tuples only when the bandwidth is plentiful.By exposing context such as available storage space, applications can control how much data is moved to a particular tuple space.It is our belief that most of the e?ort to provide this extra context information is in the collection of the data itself,not in the presentation of the data context in Lime.Our work with location provides a model for this transformation as well as solutions for issues such as large histories.
In this paper,we have presented the requirements for presenting and ac-cessing context information with coordination mechanisms and a description of Tuling,an application that demonstrates how location context can made avail-able in Lime.Throughout,our goal was to provide evidence to support the use of coordination middleware for enabling both local and remote components to share and interact with one another’s context information.This work?lls a gap between coordination systems that focus on providing access to application data and context-aware toolkits that concentrate only on enabling interactions with context.Furthermore,it e?ectively demonstrates that context information and application data can be treated in a uni?ed manner and accessed with the same coordination operations.The result is a signi?cant reduction in the programming e?ort to develop mobile applications that require access to physical context.
Acknowledgements.The work described in this paper was partially supported by the projects VICOM and IS-MANET,funded by the Italian government.The
Using Coordination Middleware for Location-Aware Computing15 authors wish to thank Emanuele Cordone and Thomas Pengo for their work on the implementation of Tuling.
References
1.M.Boulkenafed and V.Issarny.A middleware service for mobile ad hoc data
sharing,enhancing data availability.In Proceedings of the ACM/IFIP/USENIX International Middleware Conference,Rio de Janeiro(Brazil),June2003.
2.G.Cabri,L.Leonardi,and F.Zambonelli.Reactive Tuple Spaces for Mobile Agent
Coordination.In Proc.of the2nd Int.Workshop on Mobile Agents,LNCS1477.
Springer,1998.
3. A.K.Dey,D.Salber,and G.D.Abowd.A conceptual framework and a toolkit for
supporting the rapid prototyping of context-aware applications.Human-Computer Interaction(HCI)Journal,special issue on Context-Aware Computing,16(2-4):97–166,2001.
4.M.R.Ebling,G.D.H.Hunt,and H.Lei.Issues for context services for pervasive
computing.In Proceedings of the Workshop on Middleware for Mobile Computing.
IFIP/ACM,2001.
5. D.Garlan,D.Siewiorek,A.Smailagic,and P.Steenkiste.Project aura:Toward
distraction-free pervasive computing.IEEE Pervasive Computing,April-June2002.
6. D.Gelernter.Generative Communication in Linda.ACM Computing Surveys,
7(1):80–112,Jan.1985.
7. C.Mascolo,L.Capra,S.Zachariadis,and W.Emmerich.xmiddle:A data-sharing
middleware for mobile computing.Kluwer Personal and Wireless Communications Journal,21(1),April2002.
8. A.L.Murphy,G.P.Picco,and G.-C.Roman.Lime:A Middleware for Physical and
Logical Mobility.In F.Golshani,P.Dasgupta,and W.Zhao,editors,Proc.of the 21st Int.Conf.on Distributed Computing Systems(ICDCS-21),pages524–533, May2001.
9. A.L.Murphy,G.P.Picco,and G.-C.Romjan.Lime:A coordination middleware
supporting mobility of hosts and agents.Technical Report WUCSE-03-21,Wash-ington University,Department of Computer Science,St.Louis,MO(USA),2003.
10.R.De Nicola,G.Ferrari,and R.Pugliese.Klaim:A Kernel Language for Agents
Interaction and Mobility.IEEE Trans.on Software Engineering,24(5):315–330, 1998.
11. B.D.Noble and M.Satyanarayanan.Experience with adaptive mobile applications
in odyssey.Mobile Networks and Applications,4,1999.
12. A.Omicini and F.Zambonelli.Tuple Centres for the Coordination of Internet
Agents.In Proc.of the1999ACM Symp.on Applied Computing(SAC’00),Febru-ary1999.
13.G.-C.Roman,A.L.Murphy,and G.P.Picco.Coordination and Mobility.In
A.Omicini,F.Zambonelli,M.Klusch,and R.Tolksdorf,editors,Coordination of
Internet Agents:Models,Technologies,and Applications,pages254–273.Springer, 2000.
14.M.Romn,C.Hess,R.Cerqueira,A.Ranganathan,R.H.Campbell,and K.Nahrst-
edt.Gaia:a middleware platform for active spaces.ACM SIGMOBILE Mobile Computing and Communications Review,6(4):65–67,2002.
15. D.Terry,M.Theimer,K.Petersen,A.Demers,M.Spreitzer,and C.Hauser.Man-
aging Update Con?icts in Bayou,a Weakly Connected Replicated Storage System.
Operating Systems Review,29(5):172–183,1995.
无线传感网络关键技术及应用探析 1概述1.1无线传感网简介无线传感网络是集数据采集，信息传输，信息处理等多个技术为一体的综合智能信息系统。它融合了电子技术，计算机技术，无线通信技术，分布式信息处理等理论，能够实时监测并感知其覆盖区域中的环境以及各被监控对象的状态，而后将数据信息通过无线传输方式发送到到控制中心，供观察者进行处理。1.2无线传感网络的特点和传统网络通用的模式不同，WSN可以针对不同的应用，需要调整自身的配置，如节点密度，通信协议等，其主要特点如下。（1）节点能量受限。WSN 中的节点通常由电池供电，由于电池的容量一般不能维持节点正常工作时间过长，并且无线传感节点往往部署于野外环境中，无法及时充电或更换电池，当电池电量耗尽，节点也就随之失效。（2）节点处理能力受限。无线传感网络中的节点受体积和成本的影响，内存和处理器均不能和普通计算机相比，其处理程序和运算数据的能力也有限，这决定了无线传感网络的节点设计不能过于复杂。（3）WSN是一种自组织网络。传感器节点通过自组织分布形成WSN，网络大多数采用Adhoc方式进行配置，网络中的每个节点中同时充当主机和路由器的角色，具有路径寻址和维护功能。由于传感器节点自身的特点，网络拓扑结构经常发生变化，因此要求节点需要有维护动态路由的功能，以保证网络正常工作。（4）以数据为中心。在无线传感网络中，为了节省能量的消耗，要求在保证通信质量的前提下，尽可能的减少信息传输量，只需将用户关心的信息数据进行搜集传输，即WSN 是一种以数据为中心的网络。 2无线传感网络的关键技术2.1网络的自组织和自我管理WSN采用无线自组织方式进行组网，节点放入检测区域后，搜集被检测信息，并把这些信息发于邻接节点，并将其周围的链路连接信息发回给sink节点，sink节点把从所有信息进行汇总分析后，可得到网络的拓扑结构和传输路由等信息。 WSN的拓扑形式一般有三种：簇方式、平面结构、栈结构。三种结构各有利弊，需在具体的应用中灵活选取，当节点失效或加入新节点而导致网络拓扑变化较大时，需要能很快的适应这种变化，快速的使网络正常工作，即WSN需要良好的自适应性。
无线传感器网络技术试 题 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998
一、填空题 1. 传感器网络的三个基本要素：传感器、感知对象、用户(观察者) 2. 传感器网络的基本功能：协作式的感知、数据采集、数据处理、发布感知信息 3. 无线传感器节点的基本功能：采集数据、数据处理、控制、通信 4. 传感节点中处理部件用于协调节点各个部分的工作的部件。 5. 基站节点不属于传感器节点的组成部分 6. 定向扩散路由机制可以分为三个阶段：兴趣扩展阶段、梯度建立阶段、路径加强阶段 7. 无线传感器网络特点：大规模网络、自组织网络、可靠的网络、以数据为中心的网络、应用相关的网络 8. NTP时间同步协议不是传感器网络的的时间同步机制。 物理层。介质访问控制层 10. 从用户的角度看，汇聚节点被称为网关节点。 11. 数据融合的内容主要包括：多传感器的目标探测、数据关联、跟踪与识别、情况评估和预测 13. 传感器网络的电源节能方法：_休眠（技术）机制、__数据融合 14. 分布式系统协同工作的基础是时间同步机制 15. 无线网络可以被分为有基础设施的网络与没有基础设施的网络，在无线传感器网络，Internet网络，WLan网络，拨号网络中，无线传感器网络属于没有基础设施的网络。 16. 传感器网络中，MAC层与物理层采用的是IEEE制定的IEEE协议
17. 分级结构的传感器网络可以解决平面结构的拥塞问题 18. 以数据为中心特点是传感器网络的组网特点，但不是Ad-Hoc的组网特点 19. 为了确保目标节点在发送ACK过程中不与其它节点发生冲突，目标节点使用了SIFS帧间间隔 20. 典型的基于竞争的MAC协议为CSMA 二、选择题 1.无线传感器网络的组成模块分为：通信模块、（）、计算模块、存储模块和电源模块。A A．传感模块模块 C网络模块 D实验模块 2..在开阔空间无线信号的发散形状成（）。A A．球状 B网络 C直线 D射线 3.当前传感器网络应用最广的两种通信协议是（）D A. B. C. D. 4.ZigBee主要界定了网络、安全和应用框架层，通常它的网络层支持三种拓扑结构，下列哪种不是。D A．星型结构、B网状结构C簇树型结构D树形结构 5.下面不是传感器网络的支撑技术的技术。B A．定位技术B节能管理C时间同步D数据融合 6.下面不是无线传感器网络的路由协议具有的特点D A．能量优先 B.基于局部拓扑信息 C.以数据为中心 D预算相关 7.下面不是限制传感器网络有的条件C A电源能量有限 B通信能力受限 C环境受限 D计算和存储能力受限
无线传感器研究背景目的意义及现状与发展趋势 1 研究背景 随着无线技术的快速发展和日趋成熟，无线通信也发展到一定的阶段，其发展的技术越来越成熟，方向也越来越多，越来越重要，大量的应用方案开始采用无线技术进行数据采集和通信。 微机电系统和低功耗高集成数字设备的发展，使得低成本、低功耗、小体积的传感器节点得以实现。这样的节点配合各类型的传感器，可组成无线传感器网络（WSN）。无线传感网络是一种开创了新的应用领域的新兴概念和技术。广泛应用于战场监视、大规模环境监测和大区域内的目标追踪等领域。传感技术、传感网络已经被认定为最重要的研究之一。因为无线传感器网络节点一般采用电池供电，工作环境通常比较恶劣，而且数量大、更换非常困难，所以低功耗是无线传感器网络最重要的设计准则之一，因此，它迫切需要对传统的嵌入式应用开发进行更新和改进，需要精心设计的软硬件系统，以使其可靠而耐用。 2003年,美国《技术评论》杂志论述未来新兴十大技术时,WSN被列为第一;美国《今日防务》杂志更认为WSN的应用和发展将引起一场划时代的军事技术革命和未来战争的变革。可以预测,WSN是信息感知和采集的一场革命,是21世纪最重要的技术之一[2]。低功耗无线传感模块，便是组成无线传感网络的节点。此方面的研究由来已久，是计算机应用的扩展，采用了大规模集成电路和嵌入式技术，使用智能微处理器对采集到的信息进行处理和加工。现已广泛应用于社会建设的各个层面和人们的日常生活当中。但过去的研究有的只考虑低功耗而性能不高，有的性能高但是功耗太大。 因此，在无线传感技术应用如此广泛的今天，在保证无线传感模块性能的同时又能实现其低功耗具有一定的理论和现实意义。 2 研究目的及意义 2.1 研究目的 当前对于无线传感技术的研究仍然处在一个高速发展的阶段，低功耗就是其发展方向之一，而低功耗与高性能的结合实现还不完全。因此，为了更好的实现无线传感模块的功能，增加模块的可靠性和使用寿命，通过对无线传感节点的硬件功耗的分析，确定无线传感模块各单元的基本功率消耗，并进行相应比较，确定需重点降耗的单元，在此基础上结合当前对低功耗无线传感模块的研究，通过对比分析选择合适的芯片完成对低功耗无线传输模块的自主设计和制作。并辅助软件开发人员完成各子模块的驱动编写，实现低功耗无线传感模块的整体通信功能。
w e b l o g i c中间件介绍 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998
目录
一、Weblogic11g概述
编写目的 ■金税三期以后的综税的产品线中间件由原来Weblogic814，全面升级为Weblogic11g，JDK统一使用及以上版本。 ■为了满足三期后运维要，全面提高运维工程师运维能力。本文档全面介绍了Weblogic11g中间件的基础操作。 功能简介 ■支持最新的 Java 平台、企业版 (Java EE) 规范及Web 服务标准，从而可简化开发并 增强互操作性，以支持面向服务的体系结构 (SOA)。 ■领先的可靠性、可用性、可扩展性和业界领先的性能。 主要优势 ■J2EE应用服务器性能记录的保持者 ■应用程序和服务的可用性和运行时间 ■更好地监视和管理生产应用程序 ■更快、更高效的开发-部署-调试周期 ■卓越的最终用户客户端可用性 ■高效快速的服务器管理 ■简化新应用程序和服务的开发 适用范围
■J2EE应用服务器 ■BS三层架构的应用服务器 Weblogic11G新特性 自调优的企业级内核 ?静态的线程池参数可以不进行设置 ?系统自动维护线程池的大小 ?自动记录系统历史的吞吐量和性能统计 ?为了达到资源的最优分配，自动优化服务器 ?没有本地代码 过载保护 ?合理的处理过量的服务–过载保护 ?根据内存与队列容量的极限值的设定拒绝请求 ?通过降低非关键业务系统的使用资源，来保证关键业务系统的正常 ?过载的时候拒绝新的请求而不是降低整个服务器的服务质量 ?优雅的意外处理 ?可以选择当发生死锁、内存溢出等关键错误时，关闭或暂停服务器动态的配置变化 ?事务式的配置变化– all or nothing! ?大部分的变化不需要重启服务器
1 绪论 1.1 课题背景和研究意义 无线传感器网络综合了传感器技术、嵌入式计算技术、现代网络及无线通信技术等多种先进技术。其主体是集成化微型传感器，这些微型传感器具有无线通信、数据采集和处理、协同合作的功能。无线传感器网络就是由成千上万的传感器节点通过自组织方式构成的网络，它通过这些传感器协作地实时监测、感知和采集各种环境或监测对象的信息，通过嵌入式系统对信息进行处理，并通过随机自组织无线通信网络以多跳中继方式将所感知信息传送到用户终端，使用户完全掌握监测区域的情况并做出反应[1]。 无线传感器网络的自组织性和容错能力使其不会因为某些节点在恶意攻击中的损坏而导致整个系统的崩溃，所以传感器网络非常适合应用于恶劣的战场环境，包括监控我军兵力、装备和物资状态；监视冲突区域，侦察敌方地形和布防，定位攻击目标；评估损失，侦察和探测核、生物及化学攻击等。在战场上，铺设的传感器将采集相应的信息，并通过汇聚节点将数据送至数据处理中心，再转发到指挥部，最后融合来自各战场的数据，形成我军完备的战区态势图。也可以更隐蔽的方式近距离地观察敌方的布防，或直接将传感器节点撒向敌方阵地，在敌方还未来得及反应时迅速收集有利于作战的信息。在生物和化学战中，利用传感器网络，可及时、准确地探测爆炸中心，这会为我军提供宝贵的反应时间，从而最大可能地减小伤亡。 无线传感器网络是继因特网之后，将对21世纪人类生活方式产生重大影响的IT 热点技术。如果说因特网改变了人与人之间交流、沟通的方式，那么无线传感器网络则将逻辑上的信息世界与真实物理世界融合在一起，将改变人与自然交互的方式[2][3]。无线传感器网络是新兴的下一代传感器网络，最早的代表性论述出现在1999年，题为“传感器走向无线时代”。随后在美国的移动计算和网络国际会议上，提出了无线传感器网络是下一个世纪面临的发展机遇。2003年，美国《技术评论》杂志论述未来新兴十大技术时，无线传感器网络被列为第一项未来新兴技术。同年，美国《商业周刊》又在其“未来技术专版”中发表文章指出，传感器网络是全球未来四大高技术产业之一，将掀起新的的产业浪潮。美国《今日防务》杂志更认为无线传感器网络的应用和发展，将引起一场划时代的军事技术革命和未来战争的变
第一章：中间件技术介绍 1.1两层结构与三层结构 长期以来，我们一直使用着"客户端/服务器"的两层结构，这种两层的结构曾让无数人 为之兴奋和惊叹，即客户端提供用户界面、处理业务逻辑，数据库服务器接受客户端SQL 语句并对数据库进行查询，更新等操作，然后操作结果返回给客户端，如图所示。 在一个比较简单的计算机应用系统中，采用两层体系结构的确给人们带来了相当的灵活性。但随着计算机应用水平的飞速发展、企业信息化水平的不断深入、企业客户的不断增 加，以及新业务的不断出现，越来越多的用户对计算机应用系统提出了更高的要求： 1.要能够同时支持成千上万乃至更多用户的并发服务请求 2.由单一的局域网向跨多个网络协议的广域网扩展 3.不仅要支持一般的信息管理，而且还要支持关键业务的联机交易处理 4.从支持单一的系统平台和数据源转向支持异构的多系统平台和多数据源 面对用户的新需求，二层结构的应用模式由于采用客户机与服务器直接联接的方式形成了其固有的一些缺陷： 1.难以维护 clie nt/server 结构用户界面、业务逻辑和数据逻辑相互交错，通常在第一次部署的时候比较 容易，但难于升级或改进，而且经常基于某种专有的协议（通常是某种数据库协议）。它使得重 用业务逻辑和界面逻辑变得非常困难。 2 ?难以扩展 随着系统的升级，系统复杂程度大大增加，难以扩展，另外它是一个封闭的系统，很难与其他的应用系统实现互操作。 3.安全性差 客户端程序可以直接访问数据库，可通过编程语言或数据库提供的工具直接对数据库进行操作，不安全
4?性能不好 客户端直接与数据库建立连接，当有大量的并发用户存在时，会使数据库不堪重负，性能迅速下降，甚至当机。 三层结构 为解决传统二层模式与应用需求日益突出的矛盾，以交易中间件为基础框架的三层应用模式应运而生，三层结构以中间层管理大量的客户端并为其联接、集成多种异构的服务器平台，通过有效的组织和管理，在极为宽广的范围内将客户机与服务器进行高效组合。同时中间件开创的以负载平衡、动态伸缩等功能为代表的管理模式，已被广泛证实为建立关键业务应用系统的最佳环境，使在二层模式下不可能实现的应用成为可能，并为应用提供了充分的扩展余地。这种模式的成功应用已为许多国际大型企业在应用的开发和部署方面节省了大量的时间和金钱。由此促使越来越多的系统开发商和用户采用三层结构模式开发和实施其应用。 三层客户机/服务器模式的核心概念是利用中间件将应用的用户界面、业务逻辑和数据逻辑 分为三个不同的处理层，如图所示? 1.表示层（用户界面）：它的主要功能是实现用户交互和数据表示，为以后的处理收集数据， 向第二层的业务逻辑请求调用核心服务处理，并显示处理结果。这一层通常采用VB, PB DELPHI等语言编写，或采用浏览器实现 2.中间层（业务逻辑）：实现整个应用系统核心业务逻辑，通常把业务逻辑划分成一个个独立 的模块，用中间件提供的API结合数据库提供的编程接口实现。客户端通过调用这些模块 实现相应的业务操作。 3.数据层（数据逻辑）：数据库负责管理整个应用系统的数据资源，完成数据操作。中间层上应用程序 在处理客户端的请求时，通常要存取数据库。 随着市场竞争的日益加剧和企业电子信息化建设的不断深入，高度灵活、能快速部署新服务和新应用的三层结构应用系统将成为企业信息化的必由之路。采用以中间件为基础的三层结构来架构的应用系统不但具备了大型机系统稳定、安全和处理能力高等特性，同时拥有开放式系统成本低、可扩展性强、开发周期短等优点。可以很好解决两层结构所面临的问题。中间件作为构造三层结构应用系统的基础平台，在三层结构中起着关键的作用，下一节我们将对中间件技术做一个概括性的介绍。 1． 2 中间件技术简介
对于定位一般的理解就是确定位置。在无线传感网中,定位是指网络通过特 定的方法确定节点的位置信息。其可分为节点的自身定位和目标定位。节点自 身定位是确定网络中节点位置坐标的过程,它是网络自身属性的确定过程,是网络 的支撑,可以通过人工配置或各种节点自定位算法完成; 目标定位是指在网络覆 盖范围内确定一个事件或一个目标的位置坐标,这可以通过把位置已知的网络节 点作为参考节点来确定事件或目标在网络中所处的位置。无线传感网定位问题 就是寻求利用少量的锚节点来确定网络中未知节点的位置坐标的方法。 无线传感网中,传感器节点的可靠性差、能量有限、节点数量庞大且节点部 署具有不确定性等,这些限制因素对定位技术提出了更高的要求。通常无线传感 网定位技术具备以下特点: ① 自组织性 通常无线传感网中的节点是随机布设的,不能依靠全局的基础设施的协助确定每 个节点的位置所在。因此,自组织性就显得格外重要。 ② 容错性 传感器节点的硬件配置低、处理能力弱、可靠性差、能量少以及测距时会产生 误差等因素决定了传感器节点本身的脆弱性,因此定位算法必须具有良好的容错 性。 ③ 能量高效性 为了尽量延长网络的生存周期,要尽可能的减少节点间的通信开销,减少算法中计 算的复杂度,用尽量少的能量完成尽可能多的工作。 ④ 分布式计算 每个节点自己对自身的位置进行估算,不需要将所有信息传送到某个特定的节点 进行集中计算。 、管路敷设技术通过管线不仅可以解决吊顶层配置不规范高中资料试卷问题，而且可保障各类管路习题到位。在管路敷设过程中，要加强看护关于管路高中资料试卷连接管口处理高中资料试卷弯扁度固定盒位置保护层防腐跨接地线弯曲半径标等，要求技术交底。管线敷设技术中包含线槽、管架等多项方式，为解决高中语文电气课件中管壁薄、接口不严等问题，合理利用管线敷设技术。线缆敷设原则：在分线盒处，当不同电压回路交叉时，应采用金属隔板进行隔开处理；同一线槽内强电回路须同时切断习题电源，线缆敷设完毕，要进行检查和检测处理。、电气课件中调试对全部高中资料试卷电气设备，在安装过程中以及安装结束后进行 高中资料试卷调整试验；通电检查所有设备高中资料试卷相互作用与相互关系，根据生产工艺高中资料试卷要求，对电气设备进行空载与带负荷下高中资料试卷调控试验；对设备进行调整使其在正常工况下与过度工作下都可以正常工作；对于继电保护进行整核对定值，审核与校对图纸，编写复杂设备与装置高中资料试卷调试方案，编写重要设备高中资料试卷试验方案以及系统启动方案；对整套启动过程中高中资料试卷电气设备进行调试工作并且进行过关运行高中资料试卷技术指导。对于调试过程中高中资料试卷技术问题，作为调试人员，需要在事前掌握图纸资料、设备制造厂家出具高中资料试卷试验报告与相关技术资料，并且了解现场设备高中资料试卷布置情况与有关高中资料试卷电气系统接线等情况 ，然后根据规范与规程规定，制定设备调试高中资料试卷方案。 、电气设备调试高中资料试卷技术电力保护装置调试技术，电力保护高中资料试卷配置技术是指机组在进行继电保护高中资料试卷总体配置时，需要在最大限度内来确保机组高中资料试卷安全，并且尽可能地缩小故障高中资料试卷破坏范围，或者对某些异常高中资料试卷工况进行自动处理，尤其要避免错误高中资料试卷保护装置动作，并且拒绝动作，来避免不必要高中资料试卷突然停机。因此，电力高中资料试卷保护装置调试技术，要求电力保护装置做到准确灵活。对于差动保护装置高中资料试卷调试技术是指发电机一变压器组在发生内部故障时，需要进行外部电源高中资料试卷切除从而采用高中资料试卷主要保护装置。
无线传感器网络覆盖技术 谭慧婷15040024 1.覆盖技术理论基础 覆盖问题是无线传感器网络配置首先要面对的基本问题，它反映了一个无线传感器网络某区域被检测和跟踪的状况。现有的研究结果，很多都是致力于解决传感器网络的部署和检测以及覆盖与连接的关系等方面的问题。 覆盖问题可以表述成不同的理论模型，甚至在平面几何里就能找到相应的解决方案。即使简单地只从数学上来考虑，在部署传感器节点的时候，我们必须知道怎样用相同的节点数覆盖尽可能大的区域。 为了对网络的覆盖问题先有一个初步的认识，这里我们提出一个几何问题-艺术馆问题来理解。 假设艺术馆的主人想在场馆内放置监视器来防止盗窃。假定相机可以有360度的视角而且可以极大速度旋转，相机可以监视任何位置，视线不受影响。 关于实现这个想法存在两个问题需要回答：首先就是到底需要多少台相机；其次，这些相机应当放置在哪些地方才能保证馆内每个点至少被一台相机监视到。
一个简单的办法就是将多边形分成不重叠的三角形，每个三角形里面放置一个相机。通过这个方法，我们可以得到最佳分布应该如下图，放置两个相机相机足以覆盖整个艺术馆。 相机1 我们可以知道无线传感器网络的覆盖问题在本职上和上面的几何问题是一致的：需要知道是否某个区域被充分覆盖以及完全处于监视之下。 但我们也必须认识到，几何研究的结果为理解传感器覆盖问题提供了一个理论背景，但这样的求解办法是无法直接应用到无线传感器网络。 因为： 1. 监视器可以看到无穷远的地方只要没有障碍物阻挡，但是 传感器节点存在最大感应范围； 2. 无线传感器网路没有类似监视器之间固定的基础设施，其 拓扑结构可能随时变化。 2.覆盖的感知模型 在讨论节点如何布置之前，需要先知道传感器节点的感知模型。目前主要是两种。
重庆航天职业技术 学院 实训报告 教师： 课程：无线传感网技术及应用 学号： 姓名： 班级：物联网 日期：2016/6/16
评阅页 课程设计题目: 温度采集DS18B20 同组成员： 学生自评：设计方案由讨论组完成，大家一起做硬件DS18B20温度显示，再由大家分工把报告完成。 指导教师评语: 成绩：指导老师签名： 2016年06月24
前言 ZigBee简介ZigBee技术是一种近距离、低功耗、低速率、 低成本的无线通信技术，兼具经济、可靠、易于部署等优势，已成为无线传感器网络中最具潜力和研究价值的技术，在工业控制、环境监测、智能家居、医疗护理、安全预警、目标追踪等应用场合已展现出广阔的市场前景。 本设计利用TI公司CC2530单片机，采用DS18B20数字温度传感器，完成温度采集并通过液晶显示器显示测量温度值，测温电路简单，适合于-50~150摄氏度温度的测量。
目录 一、设计题目 (1) 二、硬件设计方案 (1) 2.1 CC2530芯片简介： (1) 2.2 芯片概述 (2) 三、CC2530模块说明 (2) 3.1 CPU 和内存 (2) 3.2 中断控制器 (2) 3.3外设 (3) 3.4 调试接口 (3) 3.5 无线设备 (3) 四、DS18B20 (4) 4.1 DS18B20工作原理 (4) 4.2 DS18B20的主要特性 (5) 五、软件设计方案 (5) 5.1 程序流程图 (5) 5.2 所需用到的部分C语言程序 (7) 5.3 实验过程及结果 (11) 六、总结 (13) 七、参考文献 (13)
一、设计题目 本次的设计题目要求是基于DS18B20的温度采集显示系统，该系统要求包含温度采集模块、温度显示模块等。其中温度采集模块所选用的是DS18B20数字温度传感器进行温度采集，温度显示模块用液晶显示屏显示。 二、硬件设计方案 2.1 CC2530芯片简介： CC2530 结合了领先的RF 收发器的优良性能，业界标准的增强型8051 CPU，系统内可编程闪存，8-KB RAM 和许多其它强大 的功能。CC2530 有四种不同的闪存版本：CC2530F32/64/128/256，分别具有32/64/128/256KB 的闪存。CC2530 具有不同的运行模式，使得它尤其适应超低功耗要求的系统。运行模式之间的转换时间短进一步确保了低能源消耗。其引脚如图1.1所示。 图2.1 CC2530芯片
什么是地图发布中间件及其功能应用介绍 一、海量影像地图数据发布首选——中间件 如果需要发布海量影像数据快速构建全国离线二维GIS地理信息系统或全球离线三维地球触摸GIS系统，则需要由硬件、软件、数据和GIS平台四部分组成。 1)硬件 硬件主要包括地图数据服务器和客户端PC机。 服务器：主要用于安装中间件、布署GIS应用平台和存储全国卫星影像数据。 客户端：用于加载GIS平台，并接收中间件发布的影像数据、地名路网数据和高程数据。 2)软件 软件主要包括《水经注地图发布服务中间件》（简称“中间件”）和《水经注万能地图下载器》（简称“下载器”）。 中间件：用于发布全国或全球海量卫星影像数据、地名路网和高程数据。 下载器：用于下载卫星影像数据、地名路网和高程数据。 3)数据 用户可以自行下载数据或直接购买下载好的数据。 自行下载：卫星影像数据、地名路网数据和高程数据可以用《水经注万能地图下载器》自行下载。 直接购买：购买之后，会通过邮寄硬盘（全国数据）或阵列柜（全球数据）
的方式为用户提供。 4)GIS平台 由于中间件只是一个基于URL请求返回瓦片数据的功能部件，因此只要可以支持瓦片式影像加载的GIS平台都可以进行调用。 这里推荐几个GIS开发平台供选择： 1)Google Map 离线API 2)Openlayers 二维开源平台 3)ArcGIS API for JavaScript 4)Cesium 开源三维地球平台 5)OsgEarth开源三维地球平台 二、什么是地图发布中间件 简单的讲，地图发布中间件就是为客户端提供影像瓦片的一个Windows系统服务。它只做一件事，也就是客户端通过URL请求的方式，可以快速返回影像瓦片、地名路网瓦片和高程瓦片数据。 获取影像URL示例 http://127.0.0.1:8080/getImage?z=6&y=62&x=35 获取地图路网URL示例 http://127.0.0.1:8080/getlabel?z=6&y=62&x=35 获取高程URL示例 http://127.0.0.1:8080/getDem?z=6&y=62&x=35
无线传感网络技术与发展趋势的分析 引言 无线网络传感技术给人们的生活创造了很多的乐趣，也为信息的有效、及时的传递起到一定的促进作用，人们越来越依赖无线传感网络技术为其生活带来的舒适和方便，无线网络传感技术越来越受到社会各界的广泛关注，下文主要讲述了无线传感网络技术的概念、无线传感网络技术的发展现状以及无线传感网络技术的应用和发展。 1无线传感网络技术的概念 1.1无线传感网络技术是最近一种新型的网络技术，而且它一出现，就受到了世界各个国家的广泛关注和赞誉，无线传感网络技术是集多项科学技术于一身，多种高难度的知识相互交叉产生的具有高科技的、比较热门的、前沿的技术。 1.2无线传感网络技术集中了嵌入式计算、无线通信技术、传感器、现代网络和分散式的信息处理等高科技，实现了人们无论在何时何地都能够接收到来自网络的比较真实可靠的大量的信息的愿望，无线传感网络技术真正体现了信息无处不在的理念。 1.3无线传感网络在产生之初就以一种势不可挡的气势横扫世界的各个领域，无线传感网络的发展前景备受世人的关注，其应用和发展必定给人们的工作和生活带来极大的影响，它的辉煌应用成就了它的无双的地位，无线传感网络技术应用于军事领域，成为军事领域比较关键的高科技技术，但是无线网络不仅应用在军事领域，它对世界各
个领域的影响也是不可小觑的。 2无线传感网络技术的发展现状 2.1无线传感网络技术很受大众的喜欢与它的高科技的发展是分不开的，而且许多国家也很重视它的发展，世界各国的工业界、高科技界和学术界对无线传感网络的发展展开了猛烈的攻势，希望可以通过靠科技技术的结合实现无线传感网络技术的进步，许多国家还将无线传感网络技术列入国家的重点研究技术，而且一些周刊和杂志对无线网络的评价也很高，认为无线传感网络技术是未来引领世界计算机进步的主要技术。 2.2无线传感网络技术在我国的发展还很缓慢，这主要是由于无线传感网络技术在我国出现的时间比较晚，无线传感网络技术在我国的研究方案中还处在初级阶段，与西方一些发达国家相比，存在严重的滞后性，我国在无线传感网络技术上的研究主要局限在仿真计算和网络协议等，在人们的生活和军事中的应用还很少，而且无线网络现在已经可以用来作环境监测，我国却没有将无线传感网络技术应用到实处。 2.3目前，中国的未来技术研究方向中有几项是专门针对无线传感网络技术进行直接论述的，而且在一些重大会议的决策里而，也将无线传感网络技术列为三大前沿信息技术，无线传感网络技术中的自发组织网络技术和智能感知技术都成为中国重点信息技术研究，无线传感网络技术在我国如此重视的情况下一定会有所成就，无线传感网络技术也成为社会信息技术发展的必然，在我国，信息技术领域广泛地
《无线传感器网络》教学大纲 课程名称：无线传感器网络 学时/学分：40/2.5 先修课程：模拟电路、计算机网络、通信原理、操作系统、微机原理及接口技术、C 程序设计语言 适用专业：物联网工程 是否含课内实验：■是□否（若选择“是”，则还需填写实验教学大纲） 一、课程性质与任务（要求学生完成的任务等） 本课程旨在全面系统地阐述当前各种主流的无线传感网络的基本原理，结合多种无线传感网络开发平台，深入浅出地讲解无线传感网络的基本技术。在讲授内容上，力求反映国内外该方向技术的最新进展，在讲述方法上，注重理论与实际、原理与应用相结合，无线传感网络是现代通信产业中发展最为活跃的行业之一。本课程介绍无线传感网络的系统构成、网络技术、协议、开发平台和应用，学生通过学习本课程应该达到以下目标： 1.熟练掌握有关无线传感网络的基本概念、基本理论以及基本的分析设计方法； 2.较好掌握有关各种无线传感网络的支撑技术，操作系统及开发平台； 3.了解无线传感器网络的组网、通信技术，掌握路由协议、网络协议的技术标准等； 4.掌握在ZigBee环境下的无线传感器组网的实际开发案例； 4.进一步了解无线传感网络的最新的发展应用，如海量存贮、异类传感器网络技术。 二、课程教学内容（要求学生掌握的内容，突出重难点等） 三、课程基本要求 （一）教学内容 第1章无线传感器网络概述 无线传感器网络的基本概念、无线传感器网络的特点、无线传感器网络的工作原理、无线传感器网络的应用 第2章微型传感器的基本知识 常见传感器介绍，传感器的特性和选型，微型传感器的应用 第3章无线传感器网络软/硬件设计
无线传感器网络节点硬件设计，传感节点（网关和汇聚节点设计、典型节点），无线传感器网络节点软件技术，（软件架构、中间件、操作系统），无线传感器网络实验技术平台 第4章无线传感器网络结构、覆盖 无线传感器网络结构，(平面结构，层次结构、混合结构)，无线传感器网络覆盖，覆盖基本概念，覆盖模型，覆盖指标，覆盖算法 第5章无线传感器网络的支撑技术 时间同步技术，（时间同步的基本概念、同步信息传输延时分析、同步算法、同步模型参数的估计），定位技术，（源定位算法、节点自定位、匹配定位、典型定位系统实例），数据融合（分类、主要方法、多数据融合网关的设计），能量管理（节能的方法、节点的能量管理），容错技术（故障模型、检测、修复） 第6章无线传感器网络通信与网络技术 物理层，数据链路层，(基于竞争的MAC协议、基于调度的MAC协议) 第7章无线传感器网络协议标准 技术标准的意义， IEEE1451系列标准， IEEE802.15.4标准， ZigBee协议标准，Bluetooth， UWB 第8章无线传感器网络的路由协议 路由协议的分类，平面路由协议(几个典型的平面路由协议、平面路由协议和分簇路由协议比较)，无线传感器网络分簇路由协议，(分簇路由协议的网络结构、分簇网络中节点能耗分析、分簇路由协议的性能评价、几个典型的分簇路由协议) 第9章ZigBee实践开发技术 ZigBee硬件平台(CC2430/CC2530概述、2CC2430/CC2530芯片主要特点、3CC2430/CC2431芯片功能结构、CC2430与8051的相联)， CC2430开发环境IAR（软件安装、使用、实例运行），开发实践——环境监测(系统总体方案、系统试验平台搭建、系统联调与实现)，基于ZigBee协议栈进行开发(协议栈架构简介、15.2ZigBee协议栈的开发接口API、ZigBee Device Profile API、外围部件的操作) 第10章无线传感器网络信息协同处理技术 协同感知方法(协同感知理论基础、同构协同感知、异构协同感知、协同感知算法案例、面向WSN的协同感知体系架构)，海量数据处理技术(基于海量数据的协同网络架构、海量数据的存储与管理、海量数据的知识获取)
中间件介绍 文档编制序号：[KKIDT-LLE0828-LLETD298-POI08]
中间件介绍 1、Ice： ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中间件，基于ICE可以实现电信级的解决方案。在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作，将基础对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层(java,php,,python)进行更丰富的表现与操作，从而实现比较好的架构。基于ICE的数据层可以在未来方便的进行扩展。ICE支持分布式的部署管理，消息中间件，以及网格计算等等。 Zeroc推出的一种分布式的面向对象中间件，解决分布式的异构计算。可以用 C++,Java,c#等进行分布式的交互计算。 主要设计目标是： ·成为适用于异种环境的平台。 ·具有一组完整的特性，支持广泛的领域中的实际的的开发。 ·去掉不必要的复杂性，使平台更易于学习和使用。 ·是一种在、内存使用和CPU开销方面都很高效的实现。 ·是一种具有内建安全性的实现，使它适用于不安全的公共网络。 2、JBoss： 是一个基于J2EE的的。 JBoss代码遵循LGPL许可，可以在任何商业应用中免费使用，而不用支付费用。JBoss是一个管理EJB的容器和服务器，支持EJB 、EJB 和EJB3的规范。但JBoss核心服务不包括支持servlet/JSP的WEB容器，一般与Tomcat或Jetty绑定使用。 在J2EE领域，JBoss是发展最为迅速的应用服务器。由于JBoss遵循商业友好的LGPL授权分发，并且由开源社区开发，这使得JBoss广为流行。 另外，JBoss应用服务器还具有许多优秀的特质。 JBoss运行后后台管理界面 其一，将具有革命性的JMX服务作为其； 其二，本身就是（Service-Oriented Architecture，）； 其三，具有统一的类装载器，从而能够实现应用的和热卸载能力。 因此，高度模块化的和松耦合。JBoss应用服务器是健壮的、高质量的，而且还具有良好的性能。 1、JBoss是免费的，J2EE的实现，通过许可证进行发布。但同时也有的，开源和闭源流入流出的不是同一途径。 2、JBoss需要的内存和硬盘空间比较小。 3、安装便捷：解压后，只需配置一些即可。 4、JBoss支持"热部署"，部署BEAN时，只拷贝BEAN的文件到部署路径下即可自动加载；如果有改动，也会自动更新。 5、JBoss与Web服务器在同一个中运行，Servlet调用EJB不经过网络，从而大大提高运行效率，提升安全性能。
TUXEDO中间件介绍及应用 一、前言 首先介绍一下什么是中间件？中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。 中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。 世界著名的咨询机构Standish Group在一份研究报告中归纳了中间件的十大优越性： ●缩短应用的开发周期 ●节约应用的开发成本 ●减少系统初期的建设成本●降低应用开发的失败率●保护已有的投资●简化应用集成 ●减少维护费用 ●提高应用的开发质量●保证技术进步的连续性●增强应用的生命力 Tuxedo是第一个严格意义上的中间件产品。Tuxedo是1984年在当时属于A T&T的贝尔实验室开发完成的，但Tuxedo在很长一段时期里只是实验室产品。直到BEA公司1995年收购Tuxedo后，使Tuxedo现已经发展成为交易中间件领域事实上的标准。 TUXEDO是在企业、Internet 这样的分布式运算环境中，开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。它具备分布式事务处理和应用通信功能，并提供完善的各种服务来建立、运行和管理关键任务应用系统。开发人员能够用它建立跨多个硬件平台、数据库和操作系统的可互操作的应用系统。 二、TUXEDO的组件软件模型 TUXEDO采用三层结构的组件软件模型。 图1 BEA TUXEDO 的组件软件模型概要
《无线传感网络技术》复习资料 一、选择题 1、I/O端口的输出电压为（ B ） A. 3V B. 3.3V C. 5V D. 12V 2、ZigBee网络中存在设备类型不包括（ B ）。 A. 协调器 B. 无线网卡 C. 终端设备 D. 路由器 3、实验板上LED1和LED2与CC2530的连接如下图所示，LED1和LED2的负极端分别通过一个限流电阻连接到地（低电平），它们的正极端分别连接到CC2530的( A )端口。 A. P1_0与P1_1 B. P1_1与1_2 C. P1_0与P1_2 D. P1_1与P1_3 4、 basicRfCfg_t数据结构中的PanId成员是（C）。 A. 发送模块地址 B. 接收模块地址 C. 网络ID D. 通信信道 5、引起中断的原因或是发出中断申请的来源叫做中断源。CC2530共有（ D ）个中断源。 A.5 B. 12 C. 16 D. 18 6、basicRfCfg_t数据结构中的channel成员是（D）。 A. 发送模块地址 B. 接收模块地址 C. 网络ID D. 通信信道 7、在basicRf 无线发送数据时，“basicRfConfig.myAddr=SWITCH_ADDR;”的作用是（A）。 A.配置本机地址 B. 配置发送地址 C. 配置发送数据 D. 配置接收数据 8、无线传感器网络的基本要素不包括（C ）。 A．传感器B．感知对象C．无线AP D．观察者 9、二进制数 110011011 对应的十六进制数可表示为 ( C ). A. 192H B. C90H C. 19BH D. CA0H 10、定时器1是一个（）定时器，可在时钟（）递增或者递减计数。 C A．8位，上升沿B．8位，上升沿或下降沿 C．16位，上升沿或下降沿 D．16位，下降沿 11、basicRfCfg_t数据结构中的panId成员是（C ）。 A．发送模块地址B．接收模块地址C．网络ID D．通信信道 12、十进制数 126 其对应的十六进制可表示为 ( D ). A. 8 F B. 8 E C. F E D. 7 E 13、basicRfCfg_t数据结构中的channel成员是（D ）。 A．发送模块地址B．接收模块地址C．网络ID D．通信信道 14、I/O端口的输出电压为（ B ） A. 3V B. 3.3V C. 5V D. 12V 15、下列说法中，正确的是（C） A. #define和printf都是C语句 B. #define是C语句，而printf不是
中间件技术介绍 中间件（middleware）是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。 在众多关于中间件的定义中，比较普遍被接受的是IDC 表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。 IDC对中间件的定义表明，中间件是一类软件，而非一种软件；中间件不仅仅实现互连，还要实现应用之间的互操作；中间件是基于分布式处理的软件，最突出的特点是其网络通信功能。 中科院软件所研究员仲萃豪形象地把中间件定义为：平台＋通信。这个定义限定了只有用于分布式系统中的此类软件才能被称为中间件，同时此定义还可以把中间件与支撑软件和实用软件区分开来。 目前，中间件发展很快，已经与操作系统、数据库并列为三大基础软件。中间件主要分为以下几类：
1.通信处理（消息）中间件 此类中间件能在不同平台之间通信，实现分布式系统中可靠的、高效的、实时的跨平台数据传输（如Tong LINK、BEAe Link、IBM的MQ Series等）。这是中间件中唯一不可缺少的，是销售额最大的中间件产品。 2.交易中间件 在分布式事务处理系统中要处理大量事务，常常在系统中要同时做上万笔事务。例如在北京市就要设置各种运载汽车，完成日常的运载，同时要随时监视汽车运行，出现故障时，要有排除措施，发生堵塞时要进行调度。在联机事务处理系统（OLTP）中，每笔事务常常要多台服务器上的程序顺序地协调完成，一旦中间发生某种故障时，不但要完成恢复工作，而且要自动切换系统，达到系统永不停机，实现高可靠性运行；同时要使大量事务在多台应用服务器能实时并发运行，并进行负载平衡地调度，实现昂贵的可靠性机和大型计算机系统同等的功能，为了实现这个目标，要求系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而著名，它成为增长率最高的厂商。一个事务处理平台，根据X/OPEN的参数模型规定，应由事务处理中间件、通信处理中间件以及数据存取管理中间件三部分组成。东方通科技公司的Tong LINK和TongEASY实现了这个参考模型规定。3.数据存取管理中间件
无线传感网络定位技术 研究与实现 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]
无线传感网络定位技术
无线传感网络定位技术 摘要 当代移动通信和无线网络技术的不断进步，使得我们在平时的生活中更加依赖于自动化或半自动化的设备。目前无线传感网络技术越来越受到人们的重视，并且已经应用在航天、生态、救灾和家居生活等众多领域。其中定位技术在无线网领域中有着非常关键的作用，大多数情况下没有坐标信息的无线传感器节点缺少实际使用价值。目前已有较为成熟的无线传感网定位技术可以被分为需要测距的定位技术和与测距无关的定位技术。本文首先分别介绍了基于测距的定位技术和无需测距定位算法的基本原理，并在此基础上研究了常用二维和三维无线传感网定位算法。 关键词：无线传感网络定位二维定位三维定位 Abstract With the development of mobile communications and wireless networking technology, people have increasingly high demand for automation equipment. Currently,wireless sensor network technology draws more and more people's attention,and it has been used in many fields,such as aerospace, military, medical,disaster rescue and medical area. Positioning technology plays a very important role in wireless sensor networks. In most cases, a wireless sensor node without location information is of no value useless. Currently,positioning technology is divided into the localization