Interoperability of Middleware for Context-Aware Services

HIDENORI YAMAMOTO,1 SHIGETOSHI SAMESHIMA,2 TAKAAKI SEKIGUCHI,1 HIROMITSU KATO,1 JUN’ICHI YURA,3 and KAZUNORI TAKASHIO4

1Hitachi, Ltd., Systems Development Laboratory, Japan2Hitachi, Ltd., Power Systems, Japan

3Keio University, Graduate School of Media and Governance, Japan4Keio University, Faculty of Environment and Information Studies, Japan

SUMMARY

In the ubiquitous computing environment, it is desir-able to provide context-aware services enabled by usingphysical environmental information acquired from massiveembedded sensors. One issue in providing these services isinteroperability of different middleware systems. Amongthese middleware systems service roaming occurs duringperformance of the service. This paper presents our ap-proach to the technology for interoperating different mid-dleware systems, composed of sharing the information ofresources by normalization of profiles, normalization ofservice descriptions, and adaptation of original specifica-tions which cannot be normalized. These techniques arebased on the model of Super Distributed Objects (SDO) thatis standardized in OMGW. In order to verify these tech-niques, we have experimented with the interoperation ofdifferent middleware systems. © 2011 Wiley Periodicals,Inc. Electron Comm Jpn, 94(2): 67–74, 2011; Publishedonline in Wiley Online Library (wileyonlinelibrary.com).DOI 10.1002/ecj.10260

Key words: interoperability of middleware; superdistributed objects; context-aware service; ubiquitous com-puting.

1. Introduction

The ubiquitous information society expected to ar-rive in the near future [1, 2] should provide an infrastructure

for the development of user-centered information environ-ments so that information can be accessed by anyone at anytime and place [3]. One can also expect that portableterminals, electric home appliances, embedded devices, andother everyday equipment will be provided with informa-tion processing functions and interconnected, so as to im-plement finely-tuned services according to ever changingenvironments and user conditions. Such services are calledcontext-aware services [4].

Examples of context-aware services in ubiquitousinformation systems are information delivery and naviga-tion via linked portable terminals, outdoor display units andother street devices, and local crime-prevention serviceswith cameras and sensors dynamically interconnected ac-cording to human locations, etc. The implementation ofsuch services requires that different devices and softwareprograms recognize each other and interoperate.

When providing such services, necessary devices andsoftware (below referred to collectively as resources) areusually searched for in the available range according toservice descriptions. The resources that are found are linkedby procedures stipulated in the service descriptions, andthen operated. Here the service description is a documentthat describes the types of resources and functions used fora service as well as their execution procedures and condi-tions, I/O relations between resources, etc. In the case ofcontext-aware services, the usable resources and their com-position change with the situation, and therefore links be-tween resources must be updated during serviceperformance. In some cases, services must be transferredamong different environments as the user migrates (e.g.,“follow-me” services [3]). The environments among whicha service is transferred are not necessarily permanentlyconnected. Thus, unified handling of diversified resourcesis not sufficient: the service operation state must be trans-ferred among mechanisms that interpret service descrip-

© 2011 Wiley Periodicals, Inc.

Electronics and Communications in Japan, Vol. 94, No. 2, 2011Translated from Denki Gakkai Ronbunshi, Vol. 128-C, No. 8, August 2008, pp. 1327–1332

Contract grant sponsor: Trans-Disciplinary Research on Ubiquitous Infor-mation Society project [17] conducted under the Promotion of LeadingResearch program subsidized by MEXT.

67

tions and control service execution in different environ-ments (below referred to as service execution engines).Service descriptions and service execution engines arebased on middleware specifications realized in every envi-ronment; there, interoperability is required between mid-dleware systems operating in different environments.However, some service descriptions may include resourcespecifications, and the middleware may be different indescription content and format. Furthermore, service exe-cution patterns may be different depending on the middle-ware.

Hence, two issues must be solved in order to providecontext-aware services in a ubiquitous information system:first, unified handling of resources, service descriptions,and service execution states, and second, interoperability ofdifferent middleware systems. Here we propose an ap-proach comprising three components. By normalization wemean uniform processing of the information defined anddescribed in different formats by extraction of commoncontent portions, and their replacement by a common rep-resentation.

(1) Resource profiles are normalized for unified han-dling. In addition, shared search and reference are imple-mented.

(2) Service descriptions are normalized so as to makepossible uniform interpretation among different middle-ware systems, and transfer of service execution states.

(3) When services are provided by interconnection ofresources among different middleware systems based onitems (1) and (2), nonnormalizable differences among mid-dleware systems or resources are cleared.

Specifically, the profile normalization and sharingstipulated in (1) is based on the SDO (Super DistributionObjects) model proposed previously by the authors [5, 7].This model is a real-world object model aiming at abstrac-tion and unified handling of device standards in differentfields, as specified by the OMG (Object ManagementGroupTM). Using the SDO model, we propose a method ofimplementing service description normalization (2) andinteroperation (3).

Below we give a summary of prior art in Section 2.Then in Section 3, we explain the proposed method ofinterconnection among different middleware based on theprior art and points (1), (2), and (3) above. In Section 4, wepresent interoperation experiments using actual middle-ware and demonstrate the effectiveness of the proposedmethod.

2. Prior Art

As regards item (1) in the previous section, devicespecifications have been standardized for the unified han-

dling of resources in particular fields, such as home net-works and equipment control networks for buildings andindustrial facilities [6, 13]. In these, the interfaces andprotocols for device access as well as device search proce-dures and other elements are defined. In addition, stand-ardization covers the formats for profile description ofdevice attribute information as well as the types of functionsand the respective I/O data. However, standardization isoptimized for particular fields, and hence field-specificplatforms, network protocols, and programming languagesare employed, and the emphasis is placed on field-specificapplication areas.

In particular, in the field of information devices andnetwork control, interconnectivity and interoperabilityfunctions have been developed aiming at service enhance-ment for teleoperation and home network environments.For example, software vendors and others are examiningbridge functions of HAVi (Home Audio/Video interoper-ability) and Jini (Java Intelligent Network Infrastructure)[6]. The objective is interconnection between two middle-ware standards in very different subject fields, namely,HAVi, intended for building networks of audio and videodevices, and Jini, intended for building networks of soft-ware and electric home appliances, thus expanding therange of devices that can be used by applications. There arealso attempts to resolve differences between protocols anddata models by arranging virtual service gateways andproxies between two networks based on different standardssuch as Jini, HAVi, and so on [16].

However, the above approaches deal with particularpairs of different standards. But a larger number of stand-ards requires more bridges and gateways, which may ham-per system extensibility and flexibility. In addition, thepossibility of resource sharing among different middlewaresystems is not sufficient to assure context-aware services inthe real world, including emergency connection environ-ments: services organized by resource interconnection mustbe managed appropriately. That is, service descriptionsmust be normalized.

As regards the normalization of service descriptionsmentioned in item (2) in the previous section, such stand-ards in the field of business applications as BPEL (BusinessProcess Execution Language) [14] and DAML-S (DARPAAgent Markup Language) [15] are description languagesrepresenting process flow and other elements. These areused mainly to interlink Web services. In systems based onthese standards, agents on the server side interpret descrip-tions, call services as necessary using a Web service inter-face written in WSDL (Web Service DescriptionLanguage), and exchange data between services. Thus,normalization of resources and service descriptions isachieved in the software world.

On the other hand, when the use of real-world devicegroups is involved, the diversity of middleware systems

68

employed in each environment leads to differences in serv-ice component combinations, I/O relations, execution pro-cedures, etc. Furthermore, the service descriptions mayinclude device I/O data, while the description content andformat may be different for each middleware. Thus, it isdifficult to normalize service descriptions solely by meansof BPEL or DAML-S. In addition, common interpretationof service descriptions does not assure a proper response tochanges of the real environment. In addition, the issue oftransfer of service execution states among different middle-ware has not been much discussed in previous research.

In this context, we focus on sharing of resources,service descriptions, and service execution states to imple-ment context-aware services in real-world emergency con-nection environments.

3. Middleware Interconnection

The objective of this section is provision of context-aware services by linking different devices managed bydiverse interconnected middleware. To this end, we inter-connect middleware consistently, from resource sharing bynormalization of service descriptions, thus overcoming theproblems of prior art. Specifically, the following three stepsare taken. (1) Different resource profiles are describeduniformly by mapping to the SDO model proposed pre-viously by the authors. (2) Service descriptions are normal-ized for each middleware. (3) Differences betweenresources arising from proprietary specifications arecleared to provide interoperability in service execution.Each step is described in detail below.

3.1 Resource sharing

Unlike the prior art dealing only with two particulardevice standards, resource normalization and sharing in thisstudy aims at interconnection among an arbitrary numberof different device standards.

As shown in Fig. 1, device profiles used by middle-ware to interconnect devices include one or more of thefollowing information items: (a) function content, I/O in-terface type, data structure, and other information about

functions of individual devices (Function), (b) content andvalue of hardware attributes, and other information aboutdevice attributes (Property), (c) links and dependenciesamong devices, and other information about configuringdevices into a real-world system (Combination). The de-scription format differs from middleware to middleware.

The SDO (Super Distributed Objects) model pro-posed previously by the authors [5, 7] is a logical repre-sentation of hardware devices and software components(objects) providing uniform definitions for data models andexternal access interfaces. The SDO model is illustrated inFig. 2. SDO profiles include information about mappeddevice attributes, information about available services andfunctions, etc. In addition, there is Organization, repre-senting dependencies and hierarchical relations amongSDOs.

Among the three information items of device profilesin Fig. 1, (a) Function contents are often similar even fordifferent middleware systems. For example, functions canbe expressed via data I/O, or via methods with argumentsand return values. In this study, contents related to devicefunctions (data I/O, arguments and return values, etc.) areextracted (from middleware systems 1 and 2 as shown inFig. 3), and mapped on profiles in the SDO model; thus, thedevice profiles are normalized. The other profile informa-tion (b), (c) is treated individually.

Using the SDO makes possible search, reference,operation, and management of devices by applications viashared data models and interfaces. As a result, applicationsneed not be changed even though the device standards arechanged.

Messages are exchanged among different middle-ware systems in order to normalize the profile informationmanaged by each middleware system as explained above,thus providing mutual reference. Notification messages areissued at device startup/shutdown, at certain intervals, or atstate change. In addition to normalized device profiles,messages contain device status information such as thepresence state. This information is used to search necessarydevices when services are provided via interconnection ofdevices with different middleware systems. When serviceexecution is in progress, the information is used to monitorthe presence state of the devices involved.

Fig. 1. Profile description content. Fig. 2. SDO model.

69

3.2 Normalization and extension of servicedescriptions

Service descriptions are normalized to obtain a com-mon representation for different middleware systems, thusassuring service transfer and execution management amongmiddleware systems. Such normalization is started from theclassification of existing service descriptions.

In terms of connections between service componentsand execution schedule, services can be subdivided intothree patterns as shown in Fig. 4, namely, those with directconnections via an interface (Interface Connection), thosewith indirect connections via work flow (Work Flow), andthose with sequence control enabled by application-de-pendent rules (Rule/Logic). In the Interface Connectiontype, I/O relations between components are expressed, andservices are executed using multiple components with dataI/O relations. In the Work Flow type, one component callsone or more other components according to the executionflow. In the Rule/Logic type, components are selected andexecuted by conditional tests.

The type of service to be used depends on the appli-cations employed by the middleware. The Interface Con-nection type is used for such services as video streamingdelivery and sequence control. The Work Flow type is usedmainly for flow-controlled business applications. TheRule/Logic type is used for adaptive applications that re-quire a dynamic response to environment changes.

The differences between the three patterns of servicedescription shown in Fig. 4 are related to the configuring ofcomponents into a service, I/O relations, and executionconditions. Thus, we introduce a common description for-mat to subsume these differences. The service componentsare replaced by SDOs, and services are expressed as proc-esses executed by linking multiple SDOs. This SDO-baseddescription format is illustrated in Fig. 5.

The SDO-based service description format containsexecution patterns [Fig. 5(b)] and conditions [Fig. 5(c)] ofSDOs, definitions of data storage variables [Fig. 5(d)] usedfor data exchange among SDOs during service execution,definitions of one or more SDOs [Fig. 5(e)] involved in theservice, and the service state of progress [Fig. 5(f)]. SDOdefinitions [Fig. 5(e)] are descriptions based on the SDOmodel, and are independent of actual device specifications.Multiple patterns are provided for SDO execution [Fig.5(b)]. The three patterns of service description in Fig. 4 arerepresented in the proposed format as shown in Fig. 6. TheInterface Connection type is represented by a combinationof Parallel and Cyclic execution patterns, and variables areused to store the I/O data. The Work Flow type is repre-sented by Sequence and other execution patterns. TheRule/Logic type is represented by conditional branching(If-Then-Else) and other execution patterns.

When this format is employed for context-awareservices [8, 9], SDOs having appropriate functions (map-ping to different devices, etc.) are sought with reference tothe service description, and cooperative relations are estab-lished among the found SDOs. Based on these cooperativerelations, the SDO interface is employed to execute devicefunctions, to exchange data among devices, etc.

Fig. 4. Patterns of service descriptions. Fig. 5. Service description based on SDO.

Fig. 3. Normalization of profiles (Function).

70

Execution states (“execution standby,” “execution inprogress,” “execution completed”) are monitored on theSDO level, thus tracking service progress. When serviceexecution states are transferred among different middle-ware systems, the execution state of every SDO in thesource middleware is written to the service state of progressfield of the proposed format [Fig. 5(f)]. In the target mid-dleware, this record is used to resume processing from theSDOs marked as “execution standby,” thus continuing serv-ice execution.

3.3 Interconnection for service execution

When context-aware services are provided by inter-linking resources managed by different middleware, theremay exist middleware-specific resource attributes and proc-essing procedures that cannot be handled even using nor-malized recourse descriptions and SDO-based servicedescription format as explained above. To solve this prob-lem, we provide each middleware system with extensionadapters. These adapters clear the mentioned differencesamong middleware systems by means of (a) data typereplacement and data supplementing/refining, (b) data I/Oalignment and data buffering, and (c) function start/stop andexecution sequence control.

An example of connecting middleware systems usingservice descriptions of the Interface Connection and WorkFlow types is shown in Fig. 7. Here the extension adapter

of the Work Flow middleware assures continuous data I/Oamong resources. On the other hand, the extension adapterof the Interface Connection middleware assures sequencecontrol for resource execution and data I/O.

4. Middleware Interoperability Tests

Tests of middleware interoperability by the proposedmethod were carried out using Galaxy [10] (a servicedescription of the Interface Connection type) and AYA [11](a service description based on SDO [Fig. 5]).

4.1 Test system configuration

In the tests, context-aware service was implementedas use cases of continuous remote monitoring of a room (anursing patient, a pet, etc.) performed by devices availableat the user’s location (office, public space, etc.). The con-figuration of the test system is shown in Fig. 8. Galaxy wasprovided in the room, and AYA at the remote location. Eachenvironment contained a PC with middleware, and multipledevices (cameras, displays, sensors, etc.) controlled by therespective middleware systems. The environments wereinterconnected via a network.

As regards the method introduced in Section 3, Gal-axy devices were mapped onto SDO to normalize theresource profiles, and the messages containing the profileswere exchanged via the gateway as shown in Fig. 9. Galaxyservices were normalized using the SDO-based descriptionformat shown in Fig. 5, and service execution was control-

Fig. 6. Examples of SDO-based service descriptions.

Fig. 7. Middleware interoperation using adapters.

Fig. 8. Test system configuration.

71

led via middleware interoperation. As regards I/O betweendevices, object references were used in AYA, while com-munications ports were used in Galaxy. Because of thesedifferences not reflected in the profiles, adapters were in-troduced so that I/O data could be exchanged directlyamong devices, without involving middleware, during serv-ice execution.

4.2 Test results

According to the service descriptions, when the userwas at home (as indicated by the position detector output),the Galaxy service execution engine searched for displaysand cameras in the home environment, and interconnectedthem to execute the service. When the user was in the office,the AYA service execution engine, using profiles transmit-ted via the gateway, searched for a display in the office(controlled by AYA) and cameras at home (controlled byGalaxy), and interconnected them to resume the service.

Thus, devices controlled by the respective middle-ware were interoperated via mutual reference to deviceprofiles information. In this test, only two middlewaresystems were interconnected; however, more middlewaresystems can be easily interoperated by setting gateways,and using SDO-based profile normalization and sharing asshown in Fig. 9.

5. Conclusions

Aiming at provision of context-aware services viadevice interconnection in a ubiquitous information system,we proposed an interoperability method consisting of threecomponents: profile sharing, service description normali-zation, and interconnection of different middleware sys-tems; in addition, we verified the proposed methodexperimentally. Interoperation of different middleware sys-tems by the proposed method makes possible not only theprovision of services, but their transfer among middleware

systems. Topics for future research include robustness andinformation security in a real interoperation environment.

Acknowledgment

This study is a part of the Trans-Disciplinary Re-search on Ubiquitous Information Society project [17] con-ducted under the Promotion of Leading Research programsubsidized by MEXT.

REFERENCES

1. Weiser M. The computer for twenty-first century.Scientific America, p 94–100, 1991.

2. Abowd GD, Mynatt ED. Charting past, present andfuture research in ubiquitous computing. ACMTransactions on Computer Human Interaction, Vol.7, Issue 1, p 29–58, 2000.

3. Aoyama N et al. Revolution of networking technolo-gies to support the ubiquitous computing environ-ment. IPSJ Magazine 2002;43:611–652. (inJapanese)

4. Chen G, Kotz D. A survey of context-aware mobilecomputing research. Technical Report TR2000-381,Department of Computer Science, Dartmouth Col-lege, 2000.

5. Sameshima S et al. Super distributed objects modeland autonomous plug and play for context-awareservices. IEEJ Transactions on Electronics2004;124:64–72.

6. Japan Patent Office. Survey Report on TechnologicalTrends in Information Devices and Home AppliancesNetwork Control. http://www.jpo.go.jp/shiryou/pdf/gidou-houkoku/kaden.pdf (2001)

7. Object Management Group. Platform IndependentModel (PIM) and Platform Specific Model (PSM) forSuper Distributed Objects (SDO) Specification. for-mat/04-11-01, 2004.

8. Yamamoto H et al. Service reconfiguration usingsuper distributed objects (SDO) in context-awareservice systems. Proceedings of IEEE Second IEEEWorkshop on Software Technologies for Future Em-bedded and Ubiquitous Systems (WSTFEUS 2004),p 163–165.

9. Yamamoto H, Sameshima S. Platform-independentdomain management using super distributed objects(SDO) in context-aware services systems. Proceed-ings of the 2005 International Symposium on Appli-cations and the Internet (SAINT2005) Workshops, p196–199.

10. Nakamura J et al. Galaxy: A service shaping ap-proach for addressing the hidden service problem.Proceeding of IEEE Second IEEE Workshop on Soft-

Fig. 9. Interoperation of middleware.

72

ware Technologies for Future Embedded and Ubiq-uitous Systems (WSTFEUS 2004), p 35–39.

11. Funabashi M et al. Middleware technology for ubiq-uitous computing: AYA (context-Aware and Yet An-other service) that permits autonomous collaborationon super distributed objects. Proceedings of 2002IEEE International Conference on Systems, Man andCybernetics (SMC2002), Vol. 2, p 623–628.

12. Yamamoto H et al. A study on ubiquitous informationplatform for middleware interoperation. MultimediaDistributed, Cooperative and Mobile Symposium(DICOMO2005), 2005.

13. Shin S. Feature story: Standardization of measure-ment and control networks. SICE JCMSI2005;44:353–413.

14. IBM et al. Business Process Execution Language forWeb Services Version 1.1 2003. http://www.ibm.com/developerworks/library/specifications/ws-bpel

15. The DAML Services Coalition. DAML-S: SemanticMarkup for Web Services. http://www.daml.org/services/daml-s/0.7/daml-s.html

16. Tokunaga E et al. Middleware for next-generationhome computing. 2001 IPA Exploratory SoftwareProject.

17. Yaoyorozu Project Homepage, http://www.8mg.jp/en/index.html.

AUTHORS (from left to right)

Hidenori Yamamoto (nonmember) completed the M.E. program at the University of Tokyo (School of Engineering) in2001 and joined Hitachi, Ltd. (Systems Development Laboratory). His research interests are middleware for information controlsystems and ubiquitous information systems. He is a member of SICE.

Shigetoshi Sameshima (member) completed the M.E. program at the University of Tokyo (School of Engineering) in1993 and joined Hitachi, Ltd. He is engaged in the development of system architectures and middleware for information controlsystems in the industrial and power fields at the Systems Development Laboratory. He holds a Dr.Inf.Sc.Tech. degree, and is amember of IEEJ and SICE.

Takaaki Sekiguchi (member) completed the M.E. program at Kyoto University (School of Information Science) in 2001and joined Hitachi, Ltd. (Systems Development Laboratory). His research interests are car navigation and other onboardinformation systems.

Hiromitsu Kato (nonmember) completed the M.E. program at the University of Tokyo (School of Engineering) in 1995and joined Hitachi, Ltd. His research interests are supervision and risk management of information control systems. He receivedthe IPSJ Yamashita Memorial Research Award in 1999, SICE Technology Award in 2000, and other awards. He is a member ofIEEE, IPSJ, and SICE.

Jun’ichi Yura (nonmember) completed the M.E. program at Keio University (School of Governance and Media) in 2002,and completed the doctoral program in 2008. He is now a researcher there. His research interests are ubiquitous computing,mobile sensor nodes, and sensor networks. He is a member of IPSJ.

73

AUTHORS (continued)

Kazunori Takashio (nonmember) completed the doctoral program at Keio University (School of Science and Engineering)in 1995 and became a research associate at the University of Electro-Communications. He is now an associate professor at KeioUniversity. His research interests are distributed real-time systems, mobile applications for miniature devices, and ubiquitouscomputing. He is a member of IPSJ, JSSST, ACM, and IEEE.

74