Many closed internal information systems (IS) must not concern much about its security. But, nowadays, mostly due to globalization and dynamic world, business demands integration of several legacy ISs into new one. The new IS must improve its security compared to legacy ISs, because they work in the heterogeneous environment, and need to be opened. Adding security will decrease the new IS performance, but business wants to retain or even improve it. In this paper, we simulate this issue and we create a baseline of performance data that can be used to predict IS response time, for various numbers of requests, request size and implementing security as a necessary issue for new distributed IS.
Nowadays, there are many cases where companies’ ISs, often developed using
different technologies and on different platforms, need to communicate each other.
Even more, many companies buy or merge with others, which lead in merging two
independently developed ISs, probably with totally different structure. As a solution
concept, [
In most of cases, legacies ISs are often isolated and closed to outside environment, and do not concern much about security. However, the new IS must improve better security compared to legacy ISs, because legacy ISs are often on a different locations and new IS will work in the heterogeneous environment, wide-opened to hackers.
In order to secure the new ISs, has to be achieved message confidentiality, data
integrity, authentication, authorization, non-repudiation, service availability, and web
service identification. For web services, XML Encryption [
In this paper, we analyze the response time overhead of the signed and encrypted messages through experimental approach, as well as the response time overhead of increasing message size for the same message type. In Section 2, we show the results of the experiments and analyze the dependency of the new IS response time for a various number of requests. Next, in Section 3, we analyze the results of the experiments in order to gain the response time ratio implementing signature and encryption compared to legacy IS messages, and implementing encryption compared to signed only messages.
We find many articles discussing about agent-based web services. [
In [
One of the most near article is [
Only in [
None of the related work analyzed the performance impact of the agent-based web services, nor implementing different security-level mechanisms, using different message size and concurrent requests.
This paper describes a series of experiments focused on understanding the performance impact of message overhead, as well as increased number of requests, in simulated wrapped legacy IS. We create a baseline of performance data that can be used to predict new IS response time. That is, the number of concurrent requests can be predicted, as well as the message sizes, because the new IS system information has equally size to the legacy and the number of requesters can be predicted as a sum of all users in the legacy systems.
We create three test environments, (1) using unsecured messages, (2) signed messages and (3) both signed and encrypted messages, on Windows platform. We simulate a situation where two parameters (let’s say Street and City) in legacy IS are only one parameter (let’s say Address) in the new IS. Thus, the wrapper receives and returns equally sized messages. In each test case, we change the message size and the number of concurrent requests, but in the range of normal workload.
This section describes the results of the performed tests to measure the response time dependency of the message size and a given number of requests, for the same message type. On Fig. 2 is shown the response time in milliseconds (Y axis), for a given number of requests in second and message type, for a different message size in kilobytes (X axis).
First, we perform a performance baseline, that is, we analyze the response time without security for different payload of 1, 10 and 100 messages per second for different message size. As shown on Fig. 2, the results are very strange. Namely, for small sized messages, the system has better performance when loaded with 10 or 100 messages per second, and for bigger messages (over 30K), the system performance is as expected, that is, higher response time for a huge payload and bigger messages.
Next, when we implemented signature into messages, we analyze the response time for different payload of 1, 10 and 100 messages per second. As shown on Fig. 2, the results are a little strange. Namely, for small sized messages (smaller than 35K), the system has better performance when loaded with 10, instead of loaded with 1. For a 100 messages per second, the system performance is as expected, that is, higher response time for a huge payload and bigger messages.
Next, we implemented the encryption, besides signature, and payload the system with 1, 10 and 100 messages per second. As shown on Fig. 2, the results are similar as signed only messages. Namely, for small sized messages (smaller than 25K), the system has better performance when loaded with 10, instead of loaded with 1. For a 100 messages per second, the system performance is as expected.
This section describes the results of the performed tests to measure the response time overhead of the security implementation, for a given number of requests and various message size. On Fig. 3 is shown the response time ratio (Y axis) of implementing signature and both signature and encryption to the unsigned messages, for a given number of requests, and different message size in kilobytes (X axis).
Fig. 3. Response time overhead (ratio) for implementing security for a given number of requests, depending of message size
We analyze the response time overhead implementing signature to the different sized messages, compared to the same unsigned message for different payload of 1, 10 and 100 messages per second. As shown on Fig. 3, adding signature increases the response time ratio constantly, near linear, growing slowly when increasing message size, but only for a small number of requests, because for a huge number (100), the baseline payload (without security) has huge response time (shown on Fig. 2).
Implementing both signature and encryption creates similar overhead to the no security messages.
At the end, we analyze the response time overhead adding encryption to the signature for different sized messages, compared to the same signed only message for different payload of 1, 10 and 100 messages per second. On Y axis on Fig. 4 is shown the response time ratio, and X axis is original message size.
We can conclude that adding encryption to the signature increases the response time ratio constantly, near linear, but only for a message size above 10K, growing slowly when increasing message size. The reason that the ratio decreases at the range of a huge messages and especially huge number of requests is because in that range, the baseline, that is the signed messages only response time, is huge. With other words, the IS has a low performance for that payload.
In this paper we have done security based performance analysis and comparison simulating a small part of new IS, which operates as a wrapper to the legacy IS. We analyze the performance parameter “response time”, as well as its overhead increasing “message size”, “number of messages”, and implementing different security-level mechanisms.
We believe that these result can be considered as a baseline and with these analysis, IT quality managers can predict response time for a new IS, knowing number and size of concurrent messages, in order to retain the new system secured, as the legacy.
In this paper we analyzed the decreasing the performance to the new IS, implementing security, increasing “message size”, “number of messages”, and implementing different security-level mechanisms. But, for the business managers, the most important issue is customer satisfaction, which is the most connected to the performance issue, or response time.
Therefore, our future work will be oriented on necessary hardware improvements to the new IS, to retain the same performance, such as the legacy system, for the same payload, but with implemented signature and encryption. Also, the operating system platform must be analyzed.