A MEDIATION SERVICE FOR WEB SERVICES PROVISION IN TACTICAL DISADVANTAGED ENVIRONMENT 1

Transcription

1 A MEDIATION SERVICE FOR WEB SERVICES PROVISION IN TACTICAL DISADVANTAGED ENVIRONMENT 1 Joanna Sliwa Marek Amanowicz Military Communication Institute Zegrze, Poland ABSTRACT The article describes Web Services realization in a disadvantaged environment of the Service Oriented Architecture (SOA) based C4I tactical system that supports provision of situational awareness at the tactical level. In our work we propose a mediation service that interacts both with the producer and consumer of information, checks the quality of service (QoS) level of the service that can be offered by the network and accepted by producer and consumer. It adapts Web Service realization to the client needs, and available network resources. The mediation service is also available in the service registry and can be discovered by the client requesting the adaptation. In the first part of the article we present the review of the methods of Web Service realization in disadvantaged grids and provide justification of our work. In the second part we provide description of the mediation service operation. In the last part we provide primary verification of the service operation in assumed SOA tactical disadvantaged environment. 1 The work has been supported by Polish R&D funds allocated for the years INTRODUCTION One of the most important enablers of achieving mission effectiveness is information sharing that allows creating situational awareness among mission participants. However new operational environment that the Network Enabled Capability (NEC) concept assumes, requires high mobility and rapid reactions to situation changes. This in turn provides the necessity to improve collaboration and dynamically create common relevant operational picture (CROP). Improvement of collaboration and information sharing in highly dynamic, unpredictable NEC environment is a great challenge. It assumes transfer of information with required quality of service and security independently of the underlying infrastructure as well as common access to relevant information by the authorized users. These requirements are to be satisfied by the use of Service Oriented Architecture (SOA), that succeeded in commercial world lately and is recommended by NATO as crucial NEC enabler [2]. SOA can make military information resources available in the form of services that can be discovered and used by all mission participants that do not need to be aware of these services in advance. SOA s greatest advantage is the ability of seamless information exchange based on different policies and loose coupling of its components. This can be realized however by the widespread use of open standards. One of the most intuitive realizations of SOA assumes application of Web Services (WS) the most mature implementation of this paradigm. WSs are described by a wide range of standards that deal with different aspects of WS realization, transport, orchestration, semantics etc. They provide means to build very flexible environment that is able to dynamically link different system components to each other. These standards are based on the extensible Markup Language (XML) and have been designed to operate in high bandwidth links. XML became very popular because it solves many interoperability problems, even though it adds significant overhead. Utilization of SOA-based implementation of Web Services in NEC environment has been shown in many international experiments (e.g. CWID Coalition Warrior Interoperability Demonstration [4]). They prove that WS technology improves collaboration, interoperation and information sharing in Federation of Systems (FoS). In order to achieve efficient information exchange between these users, the SOA solutions need to work with different types of information and communication systems. The biggest challenge is though to use this simple in concept and providing a big flexibility means of communications in low bandwidth tactical communications systems, that usually cope with high error rates and frequent disruptions. Such networks are usually called disadvantages. Some experiments have been carried out [6] which demonstrated that Web Services continue to function adequately even at 1 of /08/$ IEEE

2 the lowest levels of network capacity, although their performance is diminished. In order to fully take advantage of SOA and Web Services there must be provided a method of adapting WS realization to enable information distribution to users located in tactical networks, provided that the conditions posed by the client and producer are met. In our scenario we assume a few autonomous systems that are able to expose their services to each other (both core and Community Of Interest services). Service Level Agreements (SLA) at the network level define requirements for the end-to-end Quality of Service (QoS) provision. However due to limited network resources (in terms of delay and bandwidth) the client is not able to consume the service with provided quality. The main problem is to enable the client to use the service in a limited way (reduction of the traffic volume delivered to the unit in the field) and adapt the service provision mechanism to client s possibilities [13] (including QoS downgrade). Such a situation is visible e.g. when a military unit works in a low bandwidth radio network and cannot get a complete Common Operational Picture of its forces. This service should be adapted and made available with a smaller number of information that is crucial for the unit operation in the field. RELATED WORK This first normative document that described SOA as the C4I system recommended architecture was NATO NEC Feasibility Study [2]. It states that Web Services based SOA should be used to the largest extent, in all network elements where it is feasible from the technical point of view. Further NATO recommendations followed this idea[7][8] and adapted the method of producing NATO architecture including the service-oriented view. The use of SOA is however a challenging task that requires investigation in terms of applying the quality of service, security and bandwidth consumption by heavy XML based WS standards [10]. There have been undertaken a few initiatives that focused on information distribution over disadvantaged grids. In very low bandwidth environments the use of asynchronous replication based middleware provides static information distribution between partners that have agreed to use a specific database format [9]. This solution is however not very convenient to highly dynamic operational scenario. For this reason there have been carried out researches on WS-based SOA solutions that provide flexibility and interoperability and are well suited to work in Federation of Systems. The NATO C3 Agency (NC3A) report on using WS in tactical domain [6] concludes with a statement that Web Services remain promising even in low bandwidth links, as long as very fast response times are not required. Other interesting work on this subject have been carried out in Norwegian Defense Research Establishment (FFI) in Norway [3,4,5,11,12]. These projects focused on applying mechanisms that diminish XML-based disadvantages of WS and experiment on new transport protocols instead of SOAP/ HTTP (Hypertext Transfer Protocol) e.g. Data Distribution Service (DDS) or Message handling System (MHS). It must be noted that there are no commercial works on applying SOA and Web Services in disadvantaged grids. POSSIBLE SOLUTIONS Data-rate constraints in tactical networks impose great challenges that have to be faced in order to fully deploy SOA supporting NEC. There are several solutions that can be applied to adapt SOA Web Services mechanisms to fit the capacity of the systems at various C2 levels. In this article we briefly present five of them, which in our opinion bring the biggest advantage, i.e.: compression, filtering, caching and non-soap transport mechanisms. Compression Two main disadvantages of using XML are as follows: big overhead related to human-readable format of the documents and significant parsing and processing times of the XML-based messages. In [12] there has been shown that XML is very compression-friendly and in many cases, depending on the data set and the size of the message, more than 95% gain can be achieved. This very simple method should be set as requirement for use of WS in disadvantaged networks. It must be noted however that in order not to complicate interoperability, compression algorithms should be standardized and known by collaborating parties. Another very efficient method of limiting XML disadvantages is using its binary form. This generally reduces the verbosity of XML documents and cost of parsing. It can lead though to faster document processing and lower memory and CPU (Central Processing Unit) requirements, which is especially appealing on mobile devices. Filtering Filtering enables to limit the amount of information sent to the end user in order to relieve tactical network from sending heavy traffic. This method is often used for access control based on XML guards (XML filters) or for providing subscriptions based on the messages content. However utilization of this method for WS adaptation to disadvantaged grids is a very complicated matter since it is very difficult to propose very general filter rules that apply 2 of 7

3 to most Web Services and can provide the end user with the right set of information that he really needs at that moment. Some of the filtering functionalities are present it HTTP like e.g. requiring only a part of the HTTP page from the server. In Force Tracking systems filtering may mean sending information about objects that are away from the end user (service requester) by x km [3] creating some kinds of circles of service accuracy. For provision of still images it can mean sending the image with the resolution adapted to the end user terminal. For video it may mean decreasing the frequency of frames per second. Non-SOAP transport mechanisms application HTTP is one of the most popular binding protocols primarily designed to transport SOAP messages. HTTP holds its connection after the SOAP request is sent until the SOAP response is returned in the HTTP acknowledgment. If the connection times out (e.g. because of delays), the SOAP response will not be delivered to the service consumer. Therefore, using HTTP over disadvantaged grids or a combination of heterogeneous networks may not work very well [6]. According to [6] sending new service requests is much more expensive (in a performance sense) than extending existing ones. For instance, during the HTTP handshaking that takes place before each request, a lot of extra traffic is generated each time. Therefore, two byte requests will take far longer than one 2000-byte request. For the same reason, the performance of HTTP communications, which are made up of sets of data packets, are much more adversely affected by including more packets than more data. In other words, a 20-packet conversation equal to 1000 bytes will be slower than a 15-packet conversation equal to 2000 bytes. It is a good practice to use proxy element with a store-andforward functionality that could cope with the unpredictability of QoS parameters of tactical communications networks, especially in terms of frequent network disconnections. Such an element can provide different transport mechanisms, like Data Distribution Service [13] and Military Message Handling System [11] that have been designed to work in disadvantaged environments. Caching Caching is one of the functions of the proxy element that enables i.g. storing information that crossed the proxy to be available for subsequent requests. If a user requests the same object, proxy can send it without the need to ask the server again. However proxy must be able to handle stored information appropriately. This will not work well with short-lived information, that change frequently and information, the expiration of which cannot be assessed. Caching functionality should be placed at the edge of the low-bandwidth network quite near the end user. It can decrease the network load on the server-proxy path and shorten the time to send client response. Therefore the good practice is to keep frequently used (or infrequently changing) data at or near the client so that its retrieval does not impact the network considerably. MEDIATION In this paper we propose the mediation service that makes realization of Web Service efficient in the disadvantaged environment. The solution proposed by our team bases on some propositions that were described in the literature, however is more focused on implementation of serviceoriented approach. We can distinguish two parts of our adaptation solution: QoS negotiation and Web Service mediation. Mediation service operation The objective of mediation service operation is to enable Web Service realization in disadvantaged network in case when QoS broker sends information that the service cannot be realized with required QoS or will be degraded. This service is considered as the core service in terms of the SOA. Its WSDL (Web Services Description Language) description is registered with the service registry, therefore it can be discovered and used as any other SOA service. It is up to the client if he decides to use mediation service or not. Fig. 1 Mediation service operation Mediation service (MS) proposed by our team has the following functions (see Fig.1): - compression messages sent between the mediation service and service consumer will be compressed. For this purpose GZIP compression algorithm was chosen. According to [12] this compression mechanism gives good results even comparing to binary XML representation (e.g. Efficient XML and Fast Infoset). - resolution change images requested by the client will be adapted to fit the resolution of the end user terminal. 3 of 7

4 - filtering of responses filtering of geospatial data based on the client location. - subscription to filtered data providing subscriptions to filtered data. Due to SOAP/HTTP overhead and other disadvantages it is proposed to use other transport protocol (set of protocols) between the mediation service and the client (e.g. Data Distribution Service DDS, Military Message Handling System MMHS). As mentioned before, mediation service will be discoverable in the service registry (e.g. UDDI Universal Description Discovery and Integration). All other services available in this environment will be also registered in service registry (e.g. BFT Blue Force Tracking service) and though visible to all the authorized users. Mediation service will mediate between the consumer and producer adapting the way Web Service is realized in case when negative response about service realization is received by the client from the QoS broker (no resources to realize the service or service degraded). QoS negotiation process Each Web Service has an appropriate WSDL description, stored in the service registry (UDDI). This description, apart from the standard elements: - service name, - service description, - types of service interfaces for particular operations, - input and output messages sent in the Web service call, - fault cases, - binding. In order to support mediation and differentiation of the quality of service it should also contain the following additional elements: - QoS data: - response time time between the client sends the request until he gets the response during normal network operation. - response time (degraded) - time between the client sends the request until he gets the response in a disadvantaged network situation. - service latency time needed for Web Service to generate response for the request (service response time). - information timeliness maximum time after which information is no longer valid. - data size size of data sent with particular message. - traffic type elastic or streaming. - RTbdwth - minimum bandwidth for real-time services. - security data: - protected route does the service require that the message is sent only through protected domains (depending on requirements route with Traffic Flow Confidentiality, Owned route, Public route, etc.). In our mechanism we assume existence of the management system element that possesses knowledge about the network state and actual possibilities of particular service realization (QoS broker). This functionality will provide decision about possibilities of service realization based on the network state and the set of service description elements related to QoS and security (see Fig. 2). Fig. 2 QoS broker decision process based on the service parameters (yellow boxes). Adaptation The primary function of the mediation service is to adapt the way Web Service requested by the client is realized in order to distribute information in disadvantaged grids. In our solution we consider 3 types of data that can be requested from the service provider: 1. data 2. still images 3. real time video stream. In the first case client asks QoS broker about the possibility to receive data from particular Web Service. If network is overloaded, it gets in response two kinds of information: that the service can be degraded and how long will he have to wait for this data. Obviously if there are no network resources available, the client will get the information that realization of the service is currently impossible. Decision about the possibility to realize requested service is based on the WSDL service description. QoS broker takes into consideration values of responsetime, responsetimedegraded, datasize, traffictype and secureroute (see Fig. 3), decides which class of service this request should be mapped to and then responds if the service can be realized with required QoS level (response 4 of 7

5 OK) or in a lower class of service (response degraded) together with information how long will the transfer take (latency). In case of sending video stream the first communication needed between the client and producer is to negotiate the codec used to encode and decode the video. This is done during so called control connection' between the client and producer. After they agreed to use one, this information should be passed to the QoS broker together with the request to establish the video stream connection. The QoS broker responses with the actual throughput of the video stream (frames per second) (see Fig. 5). Fig. 3 Simple diagram showing exchange of messages between the client, the Web Service, QoS broker and the mediation service during the data request. If the network is overloaded and the service will be degraded, the client, in order to receive the most important information, will call the mediation service to adapt its target Web Service operation to the network state. The client requesting still image should ask the QoS broker about the possibility to download the image providing him also with information about the max resolution of his terminal (resolution range in pixels) (see Fig.4). Fig. 4 Simple diagram showing exchange of messages between the client, the Web Service, QoS broker and the mediation service during the image request. After receiving the image client may want to see particular sector in higher resolution (fitted to his terminal screen size). He can ask the mediation service to send him this sector after defining image ID and area of the sector that should be zoomed in. The image can be taken from the mediation service cache (if it is still stored there). Response from the QoS broker is created in a similar way like in the data request case. If the client receives information that the target service will be degraded, he can call the mediation service in order to change resolution of the image sent in response from the target service. Fig. 5 Simple diagram showing exchange of messages between the client, the Web Service, QoS broker and the mediation service during the video stream request. Decision about the possibility to realize this request is taken by the QoS broker similarly to the data and image cases however the response includes not the latency of information transfer but the throughput of the video stream. The client can then call the mediation service that will adapt the throughput of the video stream to the requested number of frames per second (within the agreed codec). Mediation service WSDL description Hereunder we present WSDL description of the mediation service proposition. <?xml version="1.0" encoding="utf-8"?> <description xmlns=" targetnamespace= " xmlns:tns= " xmlns:ghns = " xmlns:wsoap= " xmlns:soap=" xmlns:wsdlx= " <documentation> This document describes the mediation service used to adapt Web service realization in disadvantaged grids environment. </documentation> <types> <xs:schema xmlns:xs=" targetnamespace=" xmlns=" <xs:element name="filter" type="tfilter"/> <xs:complextype name="tfilter"> <xs:element name="servname" type="xs:string"/> <xs:element name="servlocation" type="xs:uri"/> <xs:element name="servoperation" type="xs:string"/> <xs:element name="filtertype" type="xs:string"/> </xs:complextype> <xs:element name="filterresponse" type="ttrack"/> <xs:complextype name="ttrack"> <xs:element name="track" type="ghns:track"/> 5 of 7

6 </xs:complextype> <xs:element name="resolution" type="tresolution"/> <xs:complextype name="tresolution"> <xs:element name="vertresol" type="xs:decimal"/> <xs:element name="horizresol" type="xs:decimal"/> </xs:complextype> <xs:element name="reschange" type="treschange"/> <xs:complextype name="treschange"> <xs:element name="servname" type="xs:string"/> <xs:element name="servlocation" type="xs:uri"/> <xs:element name="servoperation" type="xs:string"/> <xs:element name="resolution" type="ghns:tresolution"/> </xs:complextype> <xs:element name="reschangeresp" type="ghns:image"/> <xs:element name="invaliddataerror" type="xs:string"/> </xs:schema> </types> <interface name = "mediationinterface"> <fault name = "invaliddatafault" element = "ghns:invaliddataerror"/> <operation name="op_filter" pattern=" style=" wsdlx:safe = "true"> <input messagelabel="in" element="ghns:filter" /> <output messagelabel="out" element="ghns:filterresponse" /> <outfault ref="tns:invaliddatafault" messagelabel="out"/> </operation> <operation name="op_reschange" pattern=" style=" wsdlx:safe = "true"> <input messagelabel="in" element="ghns:reschange" /> <output messagelabel="out" element="ghns:reschangeresp" /> <outfault ref="tns:invaliddatafault" messagelabel="out"/> </operation> </interface> <binding name="mediationsoapbinding" interface="tns:mediationinterface" type=" wsoap:protocol=" <fault ref="tns:invaliddatafault" wsoap:code="soap:sender"/> <operation ref="tns:op_filter" wsoap:mep=" <operation ref="tns:op_reschange" wsoap:mep=" </binding> <service name="mediationservice" interface="tns:mediationinterface"> <endpoint name="mediationendpoint" binding="tns:mediationsoapbinding" address =" </service> </description> PROPOSED SOLUTION VERIFICATION Verification of mediation service operation was divided into two phases: engineering analysis and practical experiments. In this section we provide description of engineering analysis. As the target Web Service for verification we selected Blue Force Tracking service based on the STANAG 5527 data definitions. Blue Force Tracking (BFT) is the capability to monitor the precise location and identification of friendly forces in NATO-led operations in near-real time [1]. It normally refers to the automated, cooperative reporting of landoriented positional data of friendly units through systems. The tracked objects are typically vehicles or dismounted soldiers. However, tracking of aircraft (e.g. Army Aviation) also occurs. We assume that the BFT service offers also images and video from UAVs (Unmanned Air Vehicles) and other sensors. Engineering analysis was to prove gain in the message overhead when XML documents are filtered and compressed. We assumed that the BFT service can send tracks of objects on the geographical area or based on object ID. Track contains 3 types of information about the object: - positional data obligatory: track source, data/time, coordinates; optional: bearing, speed, reliability, inclination; - identification data (optional) unit symbol, unit short name; - operational status data (optional) footprint, strength, status code, alert, remarks. We compared the size of messages with full track information (long tracks) and only obligatory positional data (short tracks) for various number of tracks (100, 10, 5 and 1). Our results show that we can significantly decrease the amount of information sent by filtering tacks and sending only obligatory positional data information (see Fig. 6). The filter can be configured to send full tracks information associated with objects that are close to the client (belong to the same unit or are located in the same area of defined radius) and only obligatory positional data associated with other objects in the theatre. Additional information about these objects can be sent on particular request. Idea of filtering derives from operational experience that the end user is not interested in gathering information about all the objects but only the ones that have an alarm status or the ones that have impact on his mission. file size [bytes] Filtering gain tracks 10 tracks 5 tracks 1 track Number of tracks in XML files long track short track Fig. 6 Sizes of XML documents with various number (100, 10, 5 and 1) of short (red blocks) and long (blue blocks) tracks. After filtering, mediation service compresses NFFI messages. We verified compression gain using open source GZip compression algorithm (see Fig. 7). Verification proves very high gain in compressing XML messages. The highest gain (more than 90 %) is associated with bigger messages the size of which is above 5Kbit. In very small messages (below 1Kbit) compression gain is smaller than 50%. Compression is though more efficient 6 of 7

7 with larger file sizes. Therefore it is recommended to send bigger amounts of data with one message, than a few small messages. gain [%] Compression gain tracks 10 tracks 5 tracks 1 track gain for long tracks number of tracks in XML file gain for short tracks Fig. 7 Gain of using Gzip compression (in percents) of XML files with various number (100, 10, 5 and 1) of long and short tracks. The next phase of the Proof of Concept will be implementation of this service in a SOA Demonstrator, which is being developed in Poland by the Network Centric Operations Consortium (called KOS). In this environment MS functionality will be evaluated and tested together with security services and most desirably using also other than SOAP/HTTP transmission protocols (DDS and MMHS). SUMMARY The objective of proposed mediation service operation is to limit the size of files sent to the target service consumer due to the scarce network resources. It minimizes overhead imposed by the XML by using filtering and compression mechanisms. It also decreases image sizes by changing their resolution. The engineering analysis proved that only using compression can decrease sizes of the XML files with tracks even by 99%. Files with 100 tracks filtered and then compressed can have the size equal to only 0,45% of the original file. Mediation service operation will now be checked experimentally. The team is currently during the implementation phase and is hoping to prove the mediation service operation in real environment. In case of using Web Services it is also very interesting to check how the proposed mechanisms influence the time of service realisation and does the location of the mediation service has impact on effectiveness of the target service operation when the traffic flows trough operational, strategic and tactical communications systems. The idea of mediation service will be further investigated together with aspects of security mechanisms overhead during the course of the project funded by polish Ministry of Science and Education. While more research must still be done, the results of our primary researches and experiments performed by other R&D institutions [3,4,5,6,11,12] show that Web Services should be a viable technology for the future. Utilization of this technology in tactical networks will always face the problem of limited resources since the information needs grow in the same pace as the available bandwidth. BIBLIOGRAPHY [1] STANAG NATO Friendly Force Information (NFFI) standard for interoperability of force tracking systems (FTS) [2] NATO Network Enabled Feasibility Study Volume II: Detailed Report Covering a Strategy and Roadmap for Realizing an NNEC Networking and Information Infrastructure, version 2.0 [3] Experiment report: SOA Cross Domain and Disadvantaged Grids NATO CWID 2007 [4] Experiences from implementing dynamic and secure Web Services, 11th ICCRTS September 26-28, 2006 Cambridge, UK [5] Adapting Web Services for Limited Bandwidth Tactical Networks, 12th ICCRTS [6] An investigation into deploying Web services, J.Busch, TN 1229, NC3A December 2007 [7] NATO Architecture Framework (NAF) version 3.0, June 2007 [8] NATO Interoperability Standards and Profiles (ADatP- 34) Volume 2, Near Term, Version 1.1, 20 August 2007 [9] RTO IST-030/RTG-012 Final Report Information Management over Disadvantaged Grids [10] How much pain is the XML s gain, Michael Champion, Software AG, Reston, Virginia, PainGain.html [11] Utilizing Military Message Handling Systems as a Transport Mechanism for SOA in Military Tactical Networks, F. T. Johnsen, A. Eggen, T.Hafsøe, K.Lund, IST 083 Symposium, Prague 2008 [12] Using Web Services to Realize Service Oriented Architecture In Military Communication Networks, K. Lund, A. Eggen, D. Hadzic, T. Hafsøe, F. T. Johnsen, IEEE Communications Magazine, October 2007 [13] Success factors of SOA implementation in military environment, Joanna Sliwa, Marek Amanowicz, Services in NEC Integrated Environment conference, Prague of 7