SOA-based Integration of the Internet of Things in Enterprise Services

Info: 2009 IEEE International Conference on Web Service

Abstract:

      In this paper, the author proposes an architecture for an effective integration of the Internet of Things in enterprise services. Then the author show the details of architecture design and  some prototypes are implemented as proof of the idea. 

Concepts:

• WS-Notification: It defines  consumer  and  producer  roles and the interfaces both have to provide.  This allows for a point to point event subscription and delivery.
• WS-Brokered Notification: It provides the subscription interface on behalf of the producer and the notification interface on behalf of the consumer. 
• WS-Topics: It defines hierarchical topic trees that can be specified and used to declare event types when producing and event filters when subscribing to events.

Motivation:

      In Internet of Things Vision, heterogeneous devices are interconnected, providing and consuming information available on the network and cooperate. And the service-oriented approach seems to be a promising solution(i.e. each device should offer its functionality as standard services, while in parallel it is possible to discover and invoke new functionality from other services on-demand) to make these heterogeneous devices inter-operate.

SOCRADES Integration Architecture(SIA):

      This architecture(depicted in Figure 2) exposes real-world devices with embedded software to standard IT systems by making them accessible in a service-oriented way and enables enterprise-level applications to interact with and consume data from a wide range of networked devices using a high-level, abstract interface that features web services standards.

     The architecture has following layers:

• Application Interface:  The architecture should be a messaging system, because it should allow the application be able to consume any events and it also allows the application to interact with devices that only intermittently connected,receiving notifications when a certain device becomes available again or have the system cache the message and deliver it when the device is ready to receive it.
• Service Management: On this layer, 1)the notion of devices is abstracted from and the only visible assets are services.(All functionality offered by networked devices is abstracted by services.  Either devices offer services directly or their functionality is wrapped into a service representation.) 2) It also provides a runtime for the execution of composed services.(Service compositions can be modeled as business processes , this flexibility is needed since the set of services offered at the device level is dynamic; as (potentially mobile) devices connect and disconnect or are re-configured, the available service set changes frequently.)
• Device Management: On this layer, all devices are dynamically dis-covered, monitored and their status is available to the en-terprise services. 
• Security:This layer implements the correct handling of security towards the devices and the enterprise-level applications.
• Platform Abstraction: This layer wraps devices ' functionality into a service representation, which don't offer a service directly.
• Devices:This layer connect heterogeneous devices to the architecture, such as industrial devices, home devices, or IT systems.      

Architecture Design(show design details of component in each layers):

• Eventing component:  It is  an  implementation  of  the  WS-Brokered Notification standard, implementing publish and subscribe  functionality,  to  distribute  information  about events of interest.
• 
• Invocation Handler component: (depicted in Figure 4) It  implements functionality to act as an intermediary for service invocations. It is capable of buffering an invocation in case an endpoint is notavailable.  Furthermore, it  provides interfaces for the invoker to query for an invocation request status and canceling a pending invocation.
• 
• Application Service Catalogue component: Both atomic services hosted by the devices and higher-level composed services are listed here. And it allows user and applications can query services. It composed of three subcomponents:1) QueryEngine;2)BestEffortComponent: select the best possible device running the selected service; 3)OnDemandDiscoveryAndDeployment: initializ the dynamic search for services. When a service type corresponding to the query is found but the BestEffortcomponent does not find a running instance, it will try: (i) to force a discovery for such a service,using the Discovery component, and (ii) to inject the service on a device, using the Service Mapper and the DeviceService Injector.
• 
  
• Composed Services Runtime component: It  provides two interfaces for web service consumers: 1)the interface for deploying/undeploying composed services and 2)the interface for using composed services. And  logs the response time of each individual sub-service invocation and size of the SOAP request/response. 
• 
• Service Monitor component : It stores fast-changing, live and up-to-date data about the currently usable service instances.
• 
• Monitoring and Inventory component: It is composed of four sub-component:1)Device Repository:stores static information about the devices available in the system. 2)Device Monitor: monitors  devices  and  detects events like failures. 3)Middleware Historian:acts as an event archive for the architecture. 4)Discovery:find devices presenton a network, and retrieve information about them and their hosted services to be used by other components from the architecture.
• 
• Service Life-cycle Manager component: Two sub-component: 1)Service Mapper: performs deployment planning and deployment execution within the SOCRADES middleware.2)Service Implementation Repository: saves all services which are available for composition of new services,  orchestration  of  business  process  or  deployment within  the  SOCRADES  middleware. 
• 
• Device Service Proxy component: eases the integration of several categories of heterogeneous devices such as DPWS, OPC-UA, RFID or legacy protocols.
• Device Service Injector component:It is responsible for the execution of deployment levels and steps during the processing of a deployment list by the Service Mapper. 
• 
• Enterprise Services Proxy Factory component: provides interfaces for the creation of virtual devices that act as intermediaries between the device level and enterprise services.
• 

Conclusion:The approach is event-based and its interaction with external entities as well as internal communication is based on web services. And the extension of the architecture should be done to support additional devices using OPC-UA and REST plugin.