Utilizing Semantic Web Services in Factory ...

Appeared in: In the Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation, 22nd – 26th September 2009, Palma De Mallorca, Spain, Published by The IEEE Press, Piscataway, NJ – USA, pp. 1 – 8. DOI: 10.1109/ETFA.2009.5347054.

Utilizing Semantic Web Services in Factory Automation towards Integrating Resource Constrained Devices into Enterprise Information Systems Ioakeim K. Samaras*, John V. Gialelis**(1), George D. Hassapis*, Vincent A. Akpan* *

Electrical and Computer Engineering Dept, Aristotle University of Thessaloniki, 54124 Thessaloniki, Greece ** Electrical and Computer Engineering Dept, University of Patras, 26500 Patras, Greece (1) Corresponding author email: [email protected] interact and exchange information. Several efforts have been made in achieving interoperability, like in [1] where a vertical integration using workflows, ontologies and Web services is considered or in [2] where the Service-Oriented Cross-Layer Infrastructure for Distributed Smart Embedded Devices (SOCRADES) project defines a Web services integration infrastructure for achieving interoperability from the field to enterprise layer. Despite the efforts in accomplishing interoperability, limited work has been done in applying interoperability throughout the enterprise system hierarchical model. The technology constraints and the cost of performing particular tasks at the field layer have been the main barriers for this reason. Wireless Sensor Networks (WSNs) seem to present the most difficult part to be integrated into an enterprise information system. However, integrating such devices from different manufacturers renders unprecedented capabilities to the efficient running of an enterprise. As Internet technologies become the basic carrier for interconnecting most of the other components of an enterprise information system, finding means of mapping WSN to Internet and providing these devices with the same interoperability that the other components of the enterprise information system possess, becomes a necessity. As the Service Oriented Architecture (SOA) paradigm is the latest hype in the architecture design of enterprise application software, an extension of it to the device level is considered to comprise the technology that will provide the mapping of the resource constrained networks to the Internet. Several device level SOA technologies have been proposed, most notably Jini [3], UPnP (Universal Plug and Play) [4] and Device Profile for Web Services (DPWS) [5]. From all these technologies, DPWS is fully compatible with Web services technology [6] and if implemented at the WSN level will make WSN quite compatible with a large base of other components of an enterprise information system which use Web services. However, the DPWS imposes high requirements on computing power and memory consumption so it is not

Abstract This paper proposes an advanced two-part middleware solution to the problem of integrating resource constrained devices located in the field of factory automation, such as Wireless Sensor Networks, into an enterprise information system. These networks seem to present the most difficult part to be integrated into such information systems. The first part of the proposed middleware is implemented at the client side and provides a Service Oriented Architecture connection to the Internet. The second part provides to the wireless sensors a Service Oriented Architecture connection to the Internet by enhancing the exchanged information with semantic expressivity. Both parts are based on the Device Profile for Web Services which is a Service Oriented Architecture technology at the device level. By utilizing the proposed two-part middleware, we explain how such a Wireless Sensor Network can interact with a client with no previous knowledge on each other’s services achieving in this way an automatic integration of the Wireless Sensor Network into the enterprise information system.

1. Introduction It is of significant importance to establish high level interoperability among the components of the different hierarchical levels of an enterprise information system without special effort from the user. An enterprise information system follows a hierarchical model of different layers of components, i.e., the field, the shop floor, the plant and the enterprise layer. The field and shop floor layers are the two lower layers of the model where applications and systems associated with factory automation belong. Therefore, at these layers several field devices are interconnected such as sensors, actuators and Programmable Logic Controllers (PLCs). Apparently, interoperability is achieved if internal or external collaborators being at different layers can

1

Appeared in: In the Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation, 22nd – 26th September 2009, Palma De Mallorca, Spain, Published by The IEEE Press, Piscataway, NJ – USA, pp. 1 – 8. DOI: 10.1109/ETFA.2009.5347054. Finally in Section 6 conclusions drawn from this work are given.

Performing operations with complete SOAP/XML messages WS-Discovery

WS-Eventing

2. The complete DPWS

WS-Security WS-Policy WS-MetadataExchange WS-Addressing

Due to the fact that the Web services are considered the preferred implementation vehicle for service-oriented architectures [6], their protocol sequence has been adopted for devices interoperability, and with a few updates the DPWS has been created. Its protocol stack [7], shown in Figure 1 utilizes Internet and Web technologies including IP, TCP,UDP, HTTP, SOAP, XML as well as WSDL 1.1. In this paper we call the DPWS depicted in Figure 1, traditional DPWS. As it is documented in [7], the core Web services standards are the following: Web Services Description Language (WSDL), XML Schema, Simple Object Access Protocol (SOAP), WS-Addressing, WS-Policy, WSMetadataExchange and WS-Security. Apart from the standard core Web services, traditional DPWS adds WSDiscovery for Web services’ discovery and WSEventing for subscription mechanisms. A detailed description of DPWS and its protocols’ specifications can be found in [7].

SOAP 1.2 WSDL 1.1, XML Schema HTTP 1.1 UDP

TCP IPv4/IPv6

Figure 1. Devices profile for Web services protocol stack. designed to fit into resource constrained devices, such as wireless sensors. Moreover, when using Web services a user (human) must always be on the one end of the line due to the fact that Web services technologies assume a lot of human interaction for integrating two applications. However, the so much desired interoperability requires that every transaction interactions to be executed automatically by the machines themselves and not involving human intervention. Therefore it must exist an understanding of data and functions of the involved applications by machines. For the above reasons a special two-part middleware based on the DPWS is proposed. The first part is implemented at the client side which is considered a non resource constrained device. The second part is designed for usage at the server side which is considered to be a resource constrained device, such as the wireless sensor. This last part is an implementation of a stripped down version of the DPWS protocol stack which can fit into such device. Furthermore, we add semantics on the Web services standards that are used by the proposed two-part middleware. This provides an ontology-based agreement on the meaning and intended use of terms and presents the requirements and capabilities of Web services. In addition, a technique is proposed that allows the compression and reduction of the data volume of eXtensible Markup Language (XML) documents in such a way that they can be exchanged over the Internet Protocol (IP) in the environment of the limited resources of WSN. By this way we allow the communication between the wireless sensors and the other components to be done in the complete SOA information exchange protocol at the application level by using semantic Web services. In Section 2 of the paper the complete DPWS protocol stack is outlined. In Section 3 state of the art as well as similar work is demonstrated. Then, in Section 4 the general architecture of the system in which every component conforms to the proposed two-part middleware is delineated. In Section 5, the proposed two-part middleware is presented as well as its differences from the complete DPWS are outlined.

3. State of the art and similar work According to our knowledge, two are the main efforts that were made with the scope to use semantic information in industrial communication systems. Firstly, in [8] semantic Web services are proposed as a possible way for enabling a single device to incorporate knowledge about new types of processes and components with no previous knowledge on how to collaborate with them. Secondly, in [9] an attempt is described for integrating field bus systems into the Internet. It uses XML for encoding field bus messages and for giving syntax, semantics and pragmatics representation to the information. Our proposal differs from the above because we propose a two-part middleware based on the traditional DPWS enhanced with semantic representation of information aimed to enable machine-machine interaction between a client and a resource constrained device (such as a wireless sensor). Special efforts are made for reducing the data volume of XML messages so as savings in battery life and memory consumptions in the resource constrained device are achieved. With respect to the state of the art as well as similar efforts that were made in implementing a middleware with the purpose to enable the mapping from networks with resource constrained devices to IT systems, which may be the Internet, several attempts have been made. In [10] a framework is presented for using SOAP implemented in every sensor as a protocol for data aggregation in WSNs. No further functions in the

2

Appeared in: In the Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation, 22nd – 26th September 2009, Palma De Mallorca, Spain, Published by The IEEE Press, Piscataway, NJ – USA, pp. 1 – 8. DOI: 10.1109/ETFA.2009.5347054. middleware are implemented. The MMLite architecture [11] aims to provide a middleware implemented in resource constrained devices with the purpose to realize Web services on them. Furthermore, in [12] Sliver is presented which is a middleware engine that supports Business Process Execution Language (BPEL) implemented on mobile devices. In [13] a proposal is exhibited aimed to overcome the physical and logistical constraints that prevent the manufacturing processes from being integrated with IT systems. Finally, MORE project as it is documented in [14] aims to provide a middleware for embedded systems that enables Web services to be hosted by devices. Despite the implemented middleware in the above efforts, the devices that host the middleware cannot provide all the functions of the traditional DPWS. For the purpose of deploying traditional DPWS at the device level, the work presented in [15] demonstrates the advantages of adopting traditional DPWS at the level of communications between limited resource embedded devices. But no attention is devoted in applying traditional DPWS on mobile resource constrained devices. Lastly, in [16] a special middleware is proposed implemented on wireless sensors and enables them to perform as if they were hosting the traditional DPWS. The drawback is that this special middleware prohibits the usage of annotated data with semantics. As it is explained above, despite the efforts being made, the implementation of the traditional DPWS in mobile resource constrained devices for mapping from their resource constrained networks to IT systems remains extremely challenging. The proposed two-part middleware overcomes the above barrier and utilizes semantic representation of data it is analyzed in the next Sections.

two parts. The Ontology Fragment A is utilized to aid the service discovery and the Ontology Fragment B is used for annotating the operations of the Tiny DPWS-S wireless sensor. Moreover, a compressed SOA message is every message that is produced according to the Application Specific Format Technique (ASFT) which constitutes the proposed technique for reducing the XML message size without prohibiting the usage of SOAP and other Web services standards and is explained in [20]. According to this technique, a client and a wireless sensor take advantage of the a priori knowledge that they can acquire during the discovery phase about the application that they will be part of. After the discovery phase, the client knows that every message that it will receive from the Tiny DPWS-S wireless sensor represents a specific type according to its current application and needs in a specific format. This format is defined by the ASFT and predefined by the manufacturer of the sensor. Taking advantage of the ASFT, not only the size of a message can be reduced but also a new model of device-level SOA interaction patterns can be defined. In this way every device which wishes to communicate with a Tiny DPWS-S device must conform to this requirement. The device-level SOA interaction patterns are described in [6]. In the new defined model of interactions we skip the control and presentation interactions. Furthermore, we call every message understood by the traditional DPWS as complete SOAP/XML message. The wireless channel implies communication limitations, such as channel bandwidth constraints, timevarying fading, low QoS, etc. Therefore, it is very important to alleviate the traffic load with which wireless sensors load the wireless channel. Furthermore, due to the fact that we need low-rate and low-cost wireless personal area network in order to make savings in battery consumption of wireless sensors, the IEEE 802.15.4 standard [21] was considered to be the communication standard between the wireless sensors. The 6LoWPAN [22] architecture meets all the above requirements and also enables IPv6 packets to be exchanged between the wireless sensors. This induced us to implement on top of 6LowPAN the Tiny DPWS-S middleware. The drawback of 6LowPAN is that it is not able to sent packets directly to Internet. In order to do that, a more end user-oriented approach, such as Wi-Fi must be used. The Wi-Fi is based on the IEEE 802.11 Wireless set of standards [23] and allows multiple nonoverlapping frequency channels to be used simultaneously to increase the aggregate bandwidth available to end-users. These standards do not fit in a low cost and low rate personal application network as they need a lot of device resources and a nonconstrained wireless channel. Bearing in mind that the IEEE 802.15.4 architecture enables the transmission of IPv6 packets, there is no need to use complex gateways

4. Architecture of the proposed system The overall architecture of the proposed system based on the proposed two-part middleware that converts a WSN to a semantic Web services SOA Network connected to the Internet is depicted in Figure 2. The part of the proposed middleware for the client side is called Extended DPWS Semantics (Extended DPWS-S) while the part of the middleware for the server side is called Tiny DPWS Semantics (Tiny DPWS-S). The HTTP ontology server is a server that stores the Web Ontology Language (OWL) [17] domain ontologies and their corresponding databases. By utilizing the knowledge captured in domain ontologies, devices can reason about the environment, understand the context, and take decisions autonomously. The used domain ontology in our proposed system was written in OWL using the Protégé Ontology Editor and Knowledge Acquisition System [18] version 3.3.1 and sketches the Tiny DPWS-S wireless sensor. It is described in [19] and is depicted in Figure 4. We have fragmented the domain ontology into

3

Appeared in: In the Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation, 22nd – 26th September 2009, Palma De Mallorca, Spain, Published by The IEEE Press, Piscataway, NJ – USA, pp. 1 – 8. DOI: 10.1109/ETFA.2009.5347054. that in the past were necessary to translate between proprietary protocols and standard Internet Protocols. So in order for a wireless sensor to send a packet to the Internet only a simple bridge is needed. The bridge is a widely available technology and only translates an 802.15.4 packet to an 802.11 packet. This mapping from WSNs to IT systems introduces a single point of failure (bridge), but it can easily be fixed by the manageable substitution of bridges. Next the proposed two-part middleware and its exchanged messages’ sequence diagram are explained in detail.

HTTP Ontology Server

Performing operations with complete SOAP/XML messages

Performing operations with complete SOAP/XML messages

HTTP messages

Compressed SOA & HTTP messages


INTERNET Wired Extended DPWS-S PLCCLIENT


Wireless Extended DPWS-S CLIENT

802.11

BRIDGE

5. The proposed two-part middleware

802.15.4


In this Section we analyze the two-part middleware which we propose for enhancing the efforts towards the integration of the enterprise information system from the enterprise layer to the lowest layer which is considered to be a WSN.

Wireless Tiny DPWS-S sensor Compressed SOA & HTTP messages Compressed SOA & HTTP messages

5.1. The Extended DPWS-S The Extended DPWS-S has the same protocol stack with the traditional DPWS but also it encompasses a mechanism that transforms compressed SOA messages to complete SOAP/XML and vice versa. Moreover instead of implementing the WS-Discovery and WSDL 1.1, it implements the WS-Discovery Semantics (WSDiscovery-S) and the WSDL Semantics 1.1 (WSDL-S 1.1) respectively. These of course load the client with extra burden. Nevertheless this is feasible because the client is considered to have significant computing power and memory. The compression/decompression mechanism is responsible for producing the compressed SOA messages and the complete SOAP/XML messages. The compressed SOA messages are sent to the wireless sensor while the complete SOAP/XML messages are manipulated by the client. The protocol stack of the Extended DPWS-S that client conforms to, has not the ability to perform operations on the compressed SOA messages. The messages that it can recognize are the same messages understood by the traditional DPWS. The opposite applies to the server side, which is the wireless sensor. Bearing all the above statements in mind, we load the client with this mechanism. As far as the WS-Discovery-S is concerned, it is a discovery protocol that enables the Web services to be discovered semantically. As the set of available Web services increases, it becomes a necessity to have automated tools to help identify services that match a requester's requirements. The WS-Discovery-S operates as follows: first the client queries the database of the domain ontologies uploaded on a server in the Internet for the name of a sensor that hosts a Web service capable of supplying the client with the required variable (for example the reactor’s temperature). As it is described in

Wireless Tiny DPWS-S sensor

Wireless Tiny DPWS-S sensor Compressed SOA & HTTP messages

Wireless Channel





Figure 2. Architecture of the proposed system. the next sub-section, every Tiny DPWS-S wireless sensor initially registers itself as an instance in the database of the domain ontology that sketches it. So in the database of the corresponding domain ontology it is stored the name of the Tiny DPWS-S wireless sensor. The client receives an answer from the Ontology Fragment A of the Tiny DPWS-S wireless sensor’s Web Ontology Language (OWL) domain ontology. The answer contains the name of the domain ontology’s instance (name of the sensor) that has the ability to transmit the required temperature (for example a reactor’s temperature). It must be mentioned here that every developer is responsible for creating a domain ontology that well enough describes the corresponding domain. In our example, the Tiny DPWS-S wireless sensor OWL domain ontology shown in Figure 4 is used to describe the Tiny DPWS-S wireless sensors, as it was mentioned before. It is assumed that only one reactor exists and therefore the name returned by the domain ontology is correct. If for example the reactors were many, this domain ontology would have problem in answering the client’s query correctly because it may have returned a name of a Tiny DPWS-S wireless sensor that does not senses the temperature of the specific reactor needed by the client. So the Reactor Temperature class of the domain ontology described in [19] should have had subclasses in order to be more detailed described. Having acquired the name of a sensor (so far the client is not able to understand that this sensor is a Tiny DPWS-S wireless sensor), the client

4

Appeared in: In the Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation, 22nd – 26th September 2009, Palma De Mallorca, Spain, Published by The IEEE Press, Piscataway, NJ – USA, pp. 1 – 8. DOI: 10.1109/ETFA.2009.5347054. interaction model (as discussed in [20] the Tiny DPWS-S wireless sensor uses a new model of interactions) is acquired by the compressed annotated WSDL file (see Figure 4) which is called Tiny DPWS-S wireless sensor’s WSDL file and it is received by the Tiny DPWS-S wireless sensor during the description interaction as explained in the Section 5.3. This file is annotated because it contains two extensibility elements that further describe the capabilities and requirements of the Web services hosted by the Tiny DPWS-S wireless sensor and is explained in [26]. So the specific wireless sensor hosts semantic Web services. Furthermore it is compressed because all the exchanged documents are formatted according to the ASFT. By using these extensibility elements every client that processes this compressed annotated WSDL file knows that the short integers transmitted by the sensor represent a reactor’s temperature and that it must use the eventing level interaction in order to receive them. Therefore, the knowledge that the sensed and transmitted variable is the required by the client variable can be acquired from the compressed annotated WSDL file too. Following the concept described in [27], the client generates an XML schema in order to describe the format of these new extensibility elements. Moreover, the client uses the eXtensible Stylesheet Language Transformations (XSLT) [28] for transforming this compressed annotated WSDL file using pattern-matching, template-based transformation rules. By utilizing this technique, the client transforms the compressed annotated WSDL file that contains extensibility elements to a new XML document that describes the semantic Web services using the annotations derived from the Tiny DPWS-S wireless sensor’s domain ontology. All the above actions comprise the WSDL-S 1.1. Now the client and the server which were previously unknown to each other can gain understanding about their respective skill sets, goals and interaction models, and can therefore interact and collaborate.

understands from the knowledge acquired by the Ontology Fragment B that this specific sensor is a Tiny DPWS-S wireless sensor and in order to communicate with it, the ASFT must be used. Now the WS-Discovery of the traditional DPWS is utilized. As it is documented in [24] the WS-Discovery protocol is able to locate a target service by name. A client sends a resolution request message to a multicast group and the target service that matches sends a response directly to the client. So the discovery is done in a peer-to-peer mode. Every sensor that registers itself to the database of the Tiny DPWS-S wireless sensor’s OWL domain ontology, names its hosted Web service with its name. For example, the name of the sensor can be ‘Reactor Temperature Tiny DPWS-S Wireless Sensor’. The name of the Web service that it can provide would be the same. By this way, the name that the client receives from the Ontology Fragment A can be used for locating the required Web service by using the WS-Discovery protocol of the traditional DPWS. Therefore the discovery is based not only on syntactical information, but also on semantically reasoning information. As soon as the client receives the corresponding name of the required sensor, it knows from the knowledge acquired by the domain ontology that this sensor can transmit a temperature which is also a reactor’s temperature sensed by a Tiny DPWS-S wireless sensor. Now the client and the server rely on the same point of view. Lastly, WSDL-S 1.1 is based on the WSDL 1.1 [25] and is used to associate semantic annotations with Web services that are described using WSDL 1.1. The current WSDL standard operates at the syntactic level and it has not the ability to semantically express the requirements and capabilities of Web services. This poses an impediment to support automatic process and application integration. As the client and the Tiny DPWS-S wireless sensor are two devices with no previous knowledge on each other’s type, skills and interaction patterns, they cannot interact autonomously. Additional knowledge is needed in order to enable them to communicate with each other. In our application environment which is an client that conforms to the Extended DPWS-S (Extended DPWS-S client) that wishes to interact with a Tiny DPWS-S wireless sensor, three elucidations are required by the client so as to understand and communicate with the Tiny DPWS-S wireless sensor: the knowledge that the sensed and transmitted variable is the required by the client variable, the format of the exchanged messages (ASFT) and the model of interactions. The first and the second annotations are processed during the WSDiscovery-S protocol as the client queries the database of the domain ontologies for a sensor that can transmit for example the reactor’s temperature. Moreover, the knowledge acquired from the Ontology Fragment B indicates that in order for the client to communicate with the sensor, it must send and receive messages formatted according to the ASFT. The necessary knowledge for the

5.2. The Tiny DPWS-S The Tiny DPWS-S protocol stack, shown in Figure 3, is proposed as a possible way of implementing SOA by the use of semantic Web services at the level of WSN. It has approximately the same protocol stack as the Tiny DPWS [16] which is our proposed middleware for implementing the traditional DPWS in mobile resource constrained devices based on the ASFT. A meticulous description of the Tiny DPWS can be found in [16]. Even though it restricts the protocol stack of the traditional DPWS, it enables the wireless sensors that conform to it to perform as if they were hosting the traditional DPWS. It is able to understand only compressed SOA messages. The difference between the Tiny DPWS and Tiny DPWSS is that the second uses the modified WSDL-S 1.1 instead of the modified WSDL. The modified WSDL is described in [16] while the modified WSDL-S 1.1 is

5

Appeared in: In the Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation, 22nd – 26th September 2009, Palma De Mallorca, Spain, Published by The IEEE Press, Piscataway, NJ – USA, pp. 1 – 8. DOI: 10.1109/ETFA.2009.5347054. Application-Specific protocols WS-Discovery

Tiny DPWS-S wireless sensor’s OWL domain ontology Ontology Fragment A

WS-Eventing

Tiny WS-MetadataExchange Tiny WS-Addressing

Field Device

isA

Ontology Fragment B hasNot

Tiny DPWS-S Wireless Sensor

Power Supply

Compression Technique isA

hasAbilityToTransmit

MODIFIED WSDL-S 1.1

hasSkill


PROPOSED HTTP & SOAP UDP

hasSkill Temperature

IPv6

Pressure

hasAttribute

Figure 3. The Tiny DPWS-S protocol stack.

hasAttribute

isA

Speed

hasProduced

isA

isA

Room Temperature

Boiler Temperature

Reactor Temperature

isSentUsingTheInteraction

Addressing Level

Boundary of the two ontology fragments

hasSkil

hasSkill

isA

hasSkill

isA

isA

hasSkill

Description Level

Discovery Level

Eventing Level

isA

Specific Model Of Interactions

Sensed Variable

hasAttribute

analyzed below. By utilizing the modified WSDL-S 1.1, the wireless sensors not only can provide the measured results as Web services, but also they are able to semantically describe their requirements and capabilities. The modified WSDL-S 1.1 is used for semantically describing the Tiny DPWS-S wireless sensor’s Web services and how to access them, as it is shown in Figure 3. Building on the descriptive capability of WSDL 1.1, we utilize extensibility elements to annotate the capabilities and requirements of Web services hosted by the Tiny DPWS-S wireless sensor with semantic concepts accrued from a semantic model written in an OWL domain ontology. Therefore, the Tiny DPWS-S wireless sensor hosts semantic Web services. The compressed annotated WSDL used to semantically describe the Web services hosted by this wireless sensor is completely explained in [26]. It was written based on the WSDL 1.1 and the ASFT. As the ASFT transforms complete SOAP/XML messages to compressed SOA messages, it transforms a complete annotated WSDL file to a compressed annotated WSDL file too using the same format. This results in reduction of the complete annotated WSDL file’s data volume by 75%. The complete annotated WSDL file has approximately 2.58 Kilobytes size and our compressed annotated WSDL file has 661 bytes size and therefore its storage and transmission is affordable by the resource constrained environment of WSNs. The compressed annotated WSDL file, the OWL domain ontology as well as the associations between them are shown in Figure 4. Apparently, two extensibility elements are utilized to annotate with semantics, one output and one operation of the Web services hosted by the Tiny DPWS-S wireless sensors. Now the client knows that the short integers that it is going to receive represent the reactor’s temperature and in order to invoke that semantic Web service it must use the eventing level interaction. Moreover, the predefined knowledge acquired by the ASFT, at it is documented in [16] is utilized here too. The only information that the client and the Tiny DPWS-S wireless sensor need to exchange via the formatted, according to the ASFT, WSDL file is the data types used by the semantic Web services that are hosted by the sensor, as it can sent various types of data (for example temperature, pressure, speed etc.) depending on the requested by the

Models Of Interaction

Application Specific Format Technique


isA

DeviceLevel SOA Interaction Pattern

Tiny DPWS-S wireless sensor’s WSDL file