Paper Title (use style: paper title)

Smart SysTech, June 16-17. 2015 in Aachen, Germany

Resource: A connection between Internet of Things and Resource-Oriented Architecture Vladimir Vujović, Mirjana Maksimović, Dijana Kosmajac

Branko Perišić Faculty of Technical Sciences University of Novi Sad Novi Sad, Serbia [email protected]

Faculty of Electrical Engineering University of East Sarajevo East Sarajevo, Bosnia and Herzegovina [email protected], [email protected], [email protected]

“real/physical world” events and influence it by running processes that trigger actions and create services with or without direct human intervention [1] (Fig. 1). Three main system-level characteristics of IoT [2] are:

Abstract — The Internet of Things (IoT) appears like a new paradigm in the globalization process. The term "Things" refers to the interconnected smart elements of any kind and purpose that can be located anywhere and interact with each other according to the predefined protocol. Because of the unlimited variety of different structures and behavior, it is essential to find the way to uniformly represent and implement the IoT in the real world environment. Referring the good practice of distributed Internet systems, like service oriented architecture (SOA), an implementation of IoT as a resource, that appears like the “black box” from the users’ point of view, looks promising. The analysis of service oriented architecture and IoT, and subsequently, the selection between SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) implementation style are presented in this paper. Because the main building element of REST services is a resource, REST appears as a “natural” choice for IoT description. Thus, the usage of REST services for describing IoT, and adequate system and its implementation, based on this idea, are presented in this paper too.

• Anything communicates: smart things have the ability to wirelessly communicate among themselves, and form ad-hoc networks of interconnected objects; • Anything is identified: smart things are identified with a digital name; and • Anything interacts: smart things can interact with the local environment through sensing and actuation capabilities whenever present. Thus, to realize the IoT vision of bringing technology to people anytime, anywhere, with any device, service, or application, not only that users must be aware of their device capabilities, but the “things” must also be aware of users' activities, preferences, and context [3]. In other words, the realization of the “Internet of Things” requires dramatic changes in systems, architectures and communications which should be: flexible, adaptive, secure, and pervasive without being intrusive [4]. Thus, creating networks of smart devices/objects, found in the physical world on a large scale, has become the goal of a variety of recent research activities. Instead of exposing the real-world data and functionality through vertical system designs, smart things can be made as an integral part of the Web by their embedding into a standardized Web service architecture [5]. Such distributed architectures consist of components that clients as well as other components can access through the network via an interface and the interaction mechanisms defined by the architecture. A conceptual methodology and development tools for creating distributed architectures are provided by Service-Oriented Architectural (SOA) and Resource-Oriented Architectural (ROA) patterns and the corresponding distributed programming paradigms [6]. As a consequence, the Web-enablement of smart things offers more flexibility and customization possibilities from the endusers perspective. Thus, the term “Web of Things”, or WoT, can be considered as a part or a subset of IoT which incorporates similar characteristics and application models as IoT. The WoT is about the use of the web technology for

Keywords — Internet of Things, Resource Oriented Architecture, RESTful services, Sensor Web, Broker Architecture;

I. INTRODUCTION The internet has become the part of everyday environments representing the ether which globally connects all active users and also all of the other elements that collectively can be called “resources”. A detailed analysis of what can be considered a resource, as well as how the resource can be used, ensures the adequate support in the planning of the Internet infrastructure construction. With the introduction of new technologies and the development of the globalization interface the phenomenon that ordinary devices communicate with each other and/or with humans becomes the reality. This approach is a completely new paradigm of the Internet utilization, commonly known as “The Internet of Things (IoT)”. Thus, the IoT can be defined as a worldwide network of interconnected “smart things” enabled to interact and communicate to each other, as well as with the environment, by exchanging data and information “sensed” from the environment. Subsequently, these networks can react autonomously to the

© VDE VERLAG GMBH · Berlin · Offenbach, Germany

1

ISBN 978-3-8007-3996-7

Smart SysTech, June 16-17. 2015 in Aachen, Germany building communication capabilities for smart objects. In brief, IoT gives everyday device an IP address and makes them interconnected on the Internet (the physical world is becoming one big information system), while WoT enables them to speak the same language, so as to communicate and interoperate freely on the Web [7]. Based on the previously stated WoT and IoT definitions, the key questions that have to be answered by the future designers are: whether the IoT, or “smart things” can be considered as a “resource” and, if so, how and which operations should be allocated to

such defined resources? Through the analysis of serviceoriented technologies, their implementation and application, this paper, going through a discourse, gives the answer to the posted questions, and also defines the guidelines for further development and exploration of stated domain. The rest of the paper is structured as follows. Section II presents a choice of the architectural style for IoT implementations. The idea to consider smart things as resources is presented in Section III. Section IV, based on two examples, shows how the IoT resources can be equalized with ROA’s resources. Finally, Section V concludes the paper.

Fig. 1. The Internet of Things

II.

system design. The choice of an architecture style has the direct implication on: scalability, re-usability and ease of interconnection with other systems. A Resource-Oriented Architecture (ROA) presents an abstraction of resources implemented via “RESTful” interfaces [9]. RESTful platforms, based on REST development technologies, enable the creation of ROA whose main concepts are [6]:

IMPLEMENTATION OF IOT THROUGH SERVICE ARCHITECTURE

In order to enable a widely distributed platform in which smart things provide services that can be easily composed to create new applications, two types of Service-Oriented Architectures stand out as potential candidates: • The Representational State Transfer (REST) compliant Web Services, in which resources are manipulated using a uniform set of “stateless” operations; and • WS-* Web services which expose an arbitrary set of operations and use, for example, SOAP (Simple Object Access Protocol) messages [8]. The decision on which approach to adopt should be made carefully because of the major influence it has for an IoT


• Resource - anything that’s important enough to be referenced as a thing itself; • Resource name - unique identification of the resource; • Resource representation - useful information about the current state of a resource; • Resource link - link to another representation of the same or other resource; and

2

ISBN 978-3-8007-3996-7

Smart SysTech, June 16-17. 2015 in Aachen, Germany [11]. In addition, applications supporting RESTful Web Services perform better with limited hardware and software resources of the devices. Also, REST servers are used to proxy such access for very limited and non-standard devices. The key abstraction of a RESTful web service is the resource. A resource is anything that’s important enough to be referenced as an encapsulated thing. Usually, it is something that can be stored on a computer and represented as a stream of bits: a document, a row in a database, or the result of running an algorithm. Thus, resources are any named pieces of information, being a target of hypertext links. A resource also may be a physical object or an abstract concept, but the representations of such resources are bound to be disappointing [12, 13]. In the latter case, the resource is treated as a “black box” from the point of view of its caller [12]. The URI is the name and address of a resource. It means that it is used to get the value of a resource from the server: either static (if the resource is a file, part of text, an image, etc.), or dynamic, being a result of an invocation of a piece of program code. Every URI designates exactly one resource. If it designated more than one, it wouldn’t be a Universal Resource Identifier [12]. A thing or an object in the IoT is usually described as any item from our daily life that is enhanced with some computing and/or communication capabilities. But the author of [14] things of IoT calls entities of interest while devices are defined as technical components, such as RFID readers, sensors and actuators, mobile phones or embedded computers, which offer information about things and may provide actuation capabilities as well. In other words, the author considers devices as a subset of all things in the IoT. The devices usually host resources and access to resources from the outside world happens through services. However, an absolute, clear-cut categorization between entity of interest and device is not always possible, it depends on the perspective from which one looks at a particular thing. Authors of [5, 8, 14] propose the use of standard Web technologies, or RESTful web services and HTTP protocol for WoT implementation. In this way real objects are presented as RESTful resources that can be accessed directly via the Web. Thus, the smart things of the IoT can be elegantly represented as resources and their service exposed through a RESTful web service. REST implementations are lightweight so HTTP clients and servers are now available even on the smallest, IP-enabled platforms [16]. In such way the REST architecture and the Internet of Things (and Services) are an excellent match. This perfect match provides equality between IoT resource and REST resource where end user doesn't know what is behind, and it's only known how to call and use defined resource. From this conclusion, it appears that all of the options that are supported in the domain of ROA service technology can also be supported in the domain of IoT and this will be illustrated by two examples in the rest of the paper: - The example of organization and accessing the Sensor Web nodes (small measurement units), and

• Resource interface - uniform interface for accessing the resource and manipulating its state. Thus, REST relies on: a single application protocol (HTTPHypertext Transfer Protocol), universal resource indicators (URI) and standardized data formats, through XML (Extensible Markup Language). In other words, Web services, following the architectural principles of REST, use HTTP as an application protocol, providing a very basic and simple communication platform for application development. It means that, by employing established HTTP methods, such as GET and POST, to direct applications, REST developers use URIs to create a common ground enabling the applications to use HTTP and XML for data sharing [10]. On the other side, WS-* services declare their functionality and interfaces in a Web Services Description Language (WSDL) file. Client requests and service response objects are encapsulated using the SOAP and transmitted over the network, usually using the HTTP protocol. Further, WS-* standards define concepts such as addressing, security, discovery or service composition [8]. In the literature reviews these approaches have been compared with respect to performance, features, developers' preferences and programming experiences. Results have shown that RESTful Web services are easier to learn, more intuitive and more suitable for programming IoT applications compared to WS-* [8]. The main advantages of REST are: • Simplicity - Since REST uses standard HTTP it is much simpler demanding minimal tooling/middleware (only HTTP support is required); • The variety of data formats - REST permits many different data formats while SOAP permits XML only. In such a way REST allows better support for browser clients due to JSON (JavaScript Object Notation) support, which usually a better fits data and parses much faster; and • Performance and scalability - REST has better performance and scalability characteristics. Thus, the advantages of the REST approach in IoT vision can be summarized as follows: gives every “thing” an ID, links things together, uses standard methods, resources with multiple representations and supports stateless communication. Thus, its’ intuitiveness, flexibility, better cache support, lightweight requests and responses, and easier response parsing, makes REST-based platforms useful for different application domains. The connectivity of the integrated IoT device environment together with REST-based system forms the foundation of smart environments in which sensing and computing are mashed-up in the variety of ways that were not possible before. III.

SMART THINGS AS RESOURCES

As it already stated in the previous chapter, in the context of the IoT, the RESTful Web Services have many advantages over arbitrary Web Services (less overhead, less parsing complexity, statelessness, and tighter integration with HTTP)


3

ISBN 978-3-8007-3996-7

Smart SysTech, June 16-17. 2015 in Aachen, Germany A.

Atomic IoT resource The creation of so called atomic elements in the IoT can be realized through the basic and most important building block the sensor node, which is more accurately called Sensor Web (SW) node. SW can be defined as a web of interconnected heterogeneous sensors that are interoperable, intelligent, dynamic, scalable and flexible. The second approach considers SW as a group of interoperable web services that comply with a certain set of behaviors and interfaces that match the sensor node [17] where the difference between ordinary sensor nodes and SW nodes to the end-user is transparent [18]. Both definitions provide sufficient and necessary conditions in order that: a) The SW could be regarded as a fully IoT resource; and b) The SW could be regarded as ROA resource.

- Creation of the system for orchestration Sensor Web nodes through the Service Broker. IV.

IOT RESOURCE AS A ROA RESOURCE

Performing the analysis of the most commonly used IoT cases, it can be observed that the two examples are mostly in the use. The first one is usually the accession to the IoT resource, usually to the element through which the user reads simple parameters such as the parameters of natural phenomena measurements (e.g. Temperature, humidity, CO 2 levels, etc.). The second case refers to the creation of a system for monitoring and handling such set of “atomic” elements, whereby certain clusters of data of interest are being created.

Fig. 2. Infrastructure diagram of simple Sensor Web node

The example of parameters’ reading from the SW network will illustrate the use of IoT basic building blocks as ROA resources. Fig. 2 presents the simplest SW node infrastructure containing two sensor units: thermistor models: B57045k10 [19] and 10kNTC [20]. In the observed case, the value reading from the SW element can be performed by referring one of the two URLs for each sensor:

For the analysis, in the case of ROA, a REST API Twitter service, which is a system for accessing and publishing short messages, can be used. Referring URL that is defined as part of the public API Twitter service [21]: https://api.twitter.com/1.1/lists/show.json?slug=team&owner_ screen_name=twitter

the obtained result is a JSON:

[server_address]/RPISensorWeb/sw/b57045k10 [server_address]/RPISensorWeb/sw/b57045k10/data

{"created_at": "Wed Sep "team","name": "Team",...

and

01:18:01

+0000

2009","slug":

...

[server_address]/RPISensorWeb/sw/ntc10k [server_address]/RPISensorWeb/sw/ntc10k/data

..."id": 574,"uri": "/twitter/team"}

An analysis of previous cases leads to the conclusion that the aforementioned systems vary considerably in their internal implementation (where the first system reads data from a hardware device, performs their conversion into a suitable form and send through the network to the end user, while in the second case, data are obtained from the database and sent across the network to the end user). In both cases, the user only knows how to send a data request but doesn’t know how the request is executed.

The user, by calling the first address, gets JSON which contains only information about the measured value: {"temp":"23.55"}

while the second address provides a JSON with information of sensor type and sensor model, forwarded in addition to the measured value: {"type":"thermistor","model":"b57045k10","temp":"23.87"}


23

4

ISBN 978-3-8007-3996-7

Smart SysTech, June 16-17. 2015 in Aachen, Germany B.

Cluster of atomic IoT resources The second most commonly used case of IoT is the creation of the clusters or groups of related elements, which monitor a certain phenomena or monitor it at a particular geolocation. To satisfy this demand, it is necessary to provide users with easy creation and editing of clusters, as well as access to the same. Following the previously defined concepts of SW, it can be concluded that the created clusters may represent a distributed, decentralized service systems. In order to provide centralized managing of this system, it is necessary to fulfill two basic requirements: to define a unique interface for services access and to know the IP address of a certain service. As the REST implementation approach of SW nodes is elected, thus the first demand is fulfilled (the use of a universal interface for access). Referable to the fulfillment of IoT demands, the HTTP protocol is used, and for a description of the service the Web Application Description Language (WADL) [22] is applied. It can be stated that WADL represents de facto standard for describing REST services, although not officially confirmed as such [23]. The second demand is fulfilled by the concept of a SW that says that each sensor node must have a unique address and be accessible over the Internet. Only centralized managing of SW nodes can be implemented utilizing a system that operates on the precept of the dispatcher (operator or orchestrator), and usually it is a Service Broker. Fig. 3 shows the architecture of a Service Broker. The ideology of Service Broker is to have an awareness of all registered services and users, and that it takes the full responsibility for managing them. Unlike a broker, the client is aware only of the broker and the services

that the broker offers. Applying this principle to proposed case, the broker registered all SW nodes and all users, while the users are aware only of the broker and can only access to methods that broker owns. SW nodes have no conscience nor on the broker or customer which does not infringe the principle of the Sensor Web. Control of Resources with service broker architecture implements the following features [24]: • Location transparency - achieved through masking of remote service real location from clients and vice versa; • Changeability and extensibility - achieved with feature of registration of a theoretically limitless number of clients and services on control component; • Portability and interoperability - achieved through hiding of operating system details and network system on which broker relies, from clients as well as services with the support of Internet communication protocols; and • Reusability - achieved through the use of existing services during client application execution. Besides mentioned features, certain disadvantages are identified [24]: • The Limited efficiency, as the use of intermediary components in communication contributes to requestresponse process latency. In the project, there are certain optimizations inside of the system, but latency still exists in augmented form compared to simple client-server architecture; and • The Lower fault tolerance, as requests towards broker are realized to execute synchronous, i.e., wait for a remote service response. In this way, there is a possibility for faults in client applications.

Fig. 3. Architecture of Service Broker


5

ISBN 978-3-8007-3996-7

Smart SysTech, June 16-17. 2015 in Aachen, Germany REFERENCES [1]

In this case it is possible to conclude that: the Service Broker behaves as a ROA resource, meaning that it can be used as an IoT resource too. This can be illustrated on the example of calling a resource:

[2] [3]

[server_address]/ServiceBroker/sb/data

which provide the obtained result in a JSON:

[4]

{"sensor_number":5,"sensor nodes":[ {"IP":"192.168.1.55","type":"Sensor node","data":[...]}, ... {"IP":"192.168.1.60","type":"Sensor node","data":[...]} ]}

[5]

In the presented example, the whole cluster of data is presented as one resource, where the user does not see the difference between so called atomic resource and the resource obtained via cluster.

[6]

[7]

CONCLUSION V. Globalization, new technologies and novel architectures directly influence the way service-oriented technology is used as an approach to problem solving. The proliferation of globalization is followed by the emergence of ideologies which heavily rely on the global connection of physical resources. The IoT concept defines access to these resources, but also the requirements necessary for their implementation. By choosing the adequate implementation of IoT, and using ROA, a key element, i.e. a “resource”, can be equalized, while the well-known methodologies, used in service-oriented systems, can be inherited and applied in IoT concept. In the illustrated examples, the use of simple, “atomic” Sensor Web elements is demonstrated, promoting the smallest building element of the real world - the sensor. A comparative analysis of calling and obtaining data from the SW element and from a public twitter service through REST API, shows that necessary and sufficient conditions for the equalization of resources are fulfilled. In both cases, the client calls the resource by URI and receives a corresponding result, with no awareness of their implementation. Another example represents the analysis of resource as a data cluster, which is accessed in the same way as an atomic resource by using service-oriented technology. All of these indicate that methodologies and technologies defined in ROA architecture can be efficiently applied to the IoT. The general conclusion can be summarized as follows: - By using the proper implementation of IoT, any resource can be treated as ROA resource; and - Methods and technologies used for access and orchestration of ROA resources can be equally applied for the orchestration of IoT resources.

[8]

[9] [10] [11]

[12] [13] [14] [15] [16]

[17]

[18] [19] [20]

The direction of future work will be to analyze and specify security mechanisms (authorization and authentication) of Service-Oriented Architecture and its appliance in IoT without violation of IoT concept.


[21] [22] [23]

6

Internet of Things, European Research Cluster on the Internet of Things, Available: http://www.internet-of-things-research.eu/about_iot.htm D. Miorandi et al., “Internet of Things: Vision, applications and research challenges,” Ad Hoc Networks 10 (2012) 1497–1516 A. Zaslavski, “Internet of Things and Ubiquitous Sensing,” 2013, Available: http://www.computer.org/portal/web/computingnow/archive/september2 013 L. Yan, Y. Zhang, L.T. Yang, H. Ning, THE INTERNET OF THINGS, From RFID to the Next-Generation Pervasive Networked Systems, Auerbach Publications, Taylor & Francis Group, 2008 D. Guinard, V. Trifa, F. Mattern, E. Wilde, “From the Internet of Things to the Web of Things: Resource Oriented Architecture and Best Practices,” in Architecting the Internet of Things 2011, pp 97-129 R. Lucchi, M. Millot, C. Elfers, “Resource Oriented Architecture and REST,” Luxembourg: Office for Official Publications of the European Communities © European Communities, 2008 D. Zeng, S. Guo, and Z. Cheng, “The Web of Things: A Survey,” Journal of Communications, Vol. 6, No. 6, 2011, pp. 424- 438 D. Guinard, I. Ion, S. Mayer, “In Search of an Internet of Things Service Architecture: REST or WS-*? A Developers' Perspective,” Mobile and Ubiquitous Systems: Computing, Networking, and Services Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering Volume 104, 2012, pp 326-337 Resource-oriented architecture, Available: http://en.wikipedia.org/wiki/Resource-oriented_architecture R. McMillan, “A RESTful approach to web services,” 2013, Available: http://www.networkworld.com/article/2339954/software/a-restfulapproach-to-web-services.html M. Laine, “RESTful Web Services for the Internet of Things,” Available: http://media.tkk.fi/webservices/personnel/markku_laine/restful_web_ser vices_for_the_internet_of_things.pdf L. Richardson, S. Ruby, RESTful Web Services, 2007, O’Reilly Media, Inc. United States of America. D. Wilusz, J. Rykowski, “Comparison of architectures for service management,” Proceedings of the 2014 Federated Conference on Computer Science and Information Systems pp. 1207–1214 S. Haller, “The Things in the Internet of Things”, Available: http://iota.eu/public/news/resources/TheThingsintheInternetofThings_SH.pdf I. Corredor Pérez and A. M. Bernardos Barbolla, “Exploring Major Architectural Aspects of the Web of Things”, Internet of Things, Smart Sensors, Measurement and Instrumentation 9, Springer, 2014 G. Gruetter, “The Internet of Things for the REST of us,” 2012, Available: http://blog.bosch-si.com/categories/technology/2012/09/the-internet-ofthings-for-the-rest-of-us/ L. Di, “Geospatial Sensor Web and Self-adaptive Earth Predictive Systems (SEPS),” Proceedings of the Earth Science Technology Office (ESTO)/Advanced Information System Technology (AIST) Sensor Web Principal Investigator (PI) Meeting, San Diego, USA, 2007 K. A. Delin, “Sensor Webs in the Wild,” in Wireless Sensor Networks: A Systems Perspective, Artech House, 2005 NTC thermistors for temperature measurement, Type B57164, March 2006, Available: http://eecs.oregonstate.edu/education/docs/datasheets/10kThermistor.pdf Resistance table for 10kNTC Thermistor, Available: http://coldtears.lin3.siteonlinetest.com/files/10kNTC.pdf REST API’s, Available: https://dev.twitter.com/rest/reference/get/statuses/show/%3Aid Web Application Description Language (WADL), Available: https://wadl.java.net/ Team Comment on the "Web Application Description Language" Submission, Available: http://www.w3.org/Submission/2009/03/Comment

ISBN 978-3-8007-3996-7

Smart SysTech, June 16-17. 2015 in Aachen, Germany Dijana Kosmajac was born in Sarajevo in 1988. She received the BSc from Faculty of Electrical Engineering, University of East Sarajevo, Bosnia and Herzegovina in 2011. Her MSc degree she received from University of Novi Sad, Faculty of Technical Sciences, Novi Sad, Serbia in 2013. Currently she is enrolled in Ph.D. program at Dalhousie University, Faculty of Computer Science, Halifax, NS, Canada. She joined Faculty of Electrical Engineering, East Sarajevo, B&H, in 2011 as a Teaching Assistant and worked there for 3 years. From 2014 she is on the positions of Research and Teaching Assistant at Faculty of Computer Science, Dalhousie University, Halifax, NS, Canada. Her main areas of research interest are Natural Language Processing, Machine Learning, Information Systems, Web Services, and Distributed Information Systems. Dijana Kosmajac is a member of the Computer Science Graduate Society (CSGS) at Dalhousie University.

[24] D. Kosmajac, V. Vujović, M. Maksimović, N. Davidović, B. Perišić, “MasterBroker: REST oriented Service Broker,” 18th International Conference on Intelligent Engineering Systems – INES 2014, Tihany, Hungary, pp. 227-232, ISBN 978-1-4799-4616-7, 2014

Vladimir Vujović has a master's degree in Electrical Engineering from University of East Sarajevo, Bosnia and Herzegovina. He works as senior teaching assistant in the Department of Computer science and informatics at Faculty of Electrical Engineering in East Sarajevo. As a Ph.D student at the Department of Computing and control engineering at the Faculty of Technical Sciences in Novi Sad, Serbia, he is pursuing research in the field of Software engineering, Information systems and Artificial intelligence. Since 2010 he actively participates in the organization and reviewing process of the International Scientific Professional Symposium INFOTEH - Jahorina. An active member of the Technical Committee for Information Technology at the Institute for standardization in Bosnia and Herzegovina became in 2013.

Branko Perišić is an associated professor at the Faculty of Technical Sciences, University of Novi Sad, Serbia. He has received his engineer diploma from University of Sarajevo, Faculty of Electrical engineering, M.Sc. and Ph.D diplomas from the University of Novi Sad, Faculty of Technical Sciences. As a teaching professor, he has developed and taught a variety of Computer Engineering, Software Engineering and Information System Design courses. His major research interests are related to: Model Driven Software Development, Software Design, Business Information Systems Design, E-Learning Systems Development, Standardization and Software Quality, and Secure Software Development.

Mirjana Maksimović received the Ph.D degree in Electrical Engineering from University of East Sarajevo, Bosnia and Herzegovina in 2014. She works as assistant professor in the Departments of Automatics and Electronics, Electroenergetics and Computer science and informatics at Faculty of Electrical Engineering in East Sarajevo. Her current research and teaching interests extend to a range of topics in Telecommunications, Automation and Electronics. Since 2006 she actively participates in the organization and reviewing process of the International Scientific - Professional Symposium INFOTEH Jahorina. She became an active member of Technical Committee for Automation at Institute for standardization in Bosnia and Herzegovina in 2009. Since 2011 she has been an active member of the Technical Committee for Telecommunications at the same institute.


7

ISBN 978-3-8007-3996-7