**7. Conclusion**

We have introduced a security testing methodology dedicated for stateful Web Services. This one takes STS specifications and a Nomad test pattern set, which are translated into test purposes to check the test relation *secureTP*. The specification is completed to take into account the SOAP environment while testing. Test cases are generated by means of a synchronous product between test purposes and the completed specification.

The first concluding remark, raised by our experimentation, is that SOAP Web Services are not a "security nightmare". Several companies have taken into consideration the Web Service security standards. For instance, the Amazon Service is based upon some features proposed by the WS-Security specification (timestamps, etc.). Nevertheless, our experiment results have revealed that 11 percent of the tested Web Services are vulnerable. And, we believe that this number should increase with a larger test pattern set. This leads to the first perspective. Our work is based upon the recommendations for Web Services, provided by the OWASP organization. These ones do not propose formal security rules. However, it sounds interesting to dispose, in an open-source community, of a large formal rule set, independently of the language used for modelling them. Such a rule set would be interesting to derive easily test patterns and to define the vulnerability coverage of our testing method.

Our testing tool is a prototype which requires further improvements. To the best of our knowledge, there is no Nomad parser or analyzer to translate Nomad expressions into an automata-oriented model. So, abstract test purposes are currently constructed by hands. An automatic generation would be more pleasant. The value sets, used for the test case generation can be manually modified but stay static during the test case generation. Furthermore, to avoid a test case explosion, the cardinality of these sets is reduced independently of the Web Service under test. It could be more interesting to propose a dynamic analysis of the parameter types to build a list of the most adapted values. It could be also interesting to analyze the values leading to more errors while testing and to set a weighting at each of them.

The experimentation part has also revealed that other external factors, e.g., high traffic load, may lead to a fail verdict. Such external factors show the limitations of our testing method, which cannot take them into account. A possible solution would be to complete it with a monitoring method which could detect security issues over a long period of time.

### **8. References**

Amazon (2009). Amazon e-commerce service (ecs).


26 Will-be-set-by-IN-TECH

We have introduced a security testing methodology dedicated for stateful Web Services. This one takes STS specifications and a Nomad test pattern set, which are translated into test purposes to check the test relation *secureTP*. The specification is completed to take into account the SOAP environment while testing. Test cases are generated by means of a synchronous

The first concluding remark, raised by our experimentation, is that SOAP Web Services are not a "security nightmare". Several companies have taken into consideration the Web Service security standards. For instance, the Amazon Service is based upon some features proposed by the WS-Security specification (timestamps, etc.). Nevertheless, our experiment results have revealed that 11 percent of the tested Web Services are vulnerable. And, we believe that this number should increase with a larger test pattern set. This leads to the first perspective. Our work is based upon the recommendations for Web Services, provided by the OWASP organization. These ones do not propose formal security rules. However, it sounds interesting to dispose, in an open-source community, of a large formal rule set, independently of the language used for modelling them. Such a rule set would be interesting to derive easily test

Our testing tool is a prototype which requires further improvements. To the best of our knowledge, there is no Nomad parser or analyzer to translate Nomad expressions into an automata-oriented model. So, abstract test purposes are currently constructed by hands. An automatic generation would be more pleasant. The value sets, used for the test case generation can be manually modified but stay static during the test case generation. Furthermore, to avoid a test case explosion, the cardinality of these sets is reduced independently of the Web Service under test. It could be more interesting to propose a dynamic analysis of the parameter types to build a list of the most adapted values. It could be also interesting to analyze the

The experimentation part has also revealed that other external factors, e.g., high traffic load, may lead to a fail verdict. Such external factors show the limitations of our testing method, which cannot take them into account. A possible solution would be to complete it with a

Castanet, R., Kone, O. & Laurencot, P. (1998). On the fly test generation for real time protocols, *International Conference on Computer Communications and Networks,* p. 378. Cohen, M. B., Gibbons, P. B. & Mugridge, W. B. (2003). Constructing test suites for interaction

Cuppens, F., Cuppens-Boulahia, N. & Sans, T. (2005). Nomad : A security model with non

Darmaillacq, V., Fernandez, J., Groz, R., Mounier, L. & Richier, J.-L. (2006). Test generation for

Een, N. & Sörensson, N. (2003). An extensible SAT-solver, *Proc. 6th International Conference on*

atomic actions and deadlines, *Computer Security Foundations. CSFW-18 2005. 18th*

network security rules, *Testing of Communicating Systems (TestCom)*, Vol. 3964, LNCS,

*Theory and Applications of Satisfiability Testing*, Vol. 2919, LNCS, Springer, pp. 502–518.

values leading to more errors while testing and to set a weighting at each of them.

monitoring method which could detect security issues over a long period of time.

testing, *Proc. Intl. Conf. on Software Engineering (ICSE)*, pp. 38–48.

Amazon (2009). Amazon e-commerce service (ecs).

*IEEE Workshop*, pp. 186–196.

Springer, pp. 341–356.

product between test purposes and the completed specification.

patterns and to define the vulnerability coverage of our testing method.

**7. Conclusion**

**8. References**

Eviware (2011). Soapui. http://www.soapui.org/.


URL: *http://doc.utwente.nl/41390/*


**12** 

 *Japan*

**Autonomous Decentralized** 

*<sup>2</sup>DTS, Inc 3-39-5 Higashi Ueno Taitou-ku Tokyo,* 

 **Multi-Layer Cache System to Low** 

 **Latency User Push Web Services** 

Hironao Takahashi1,2, Khalid Mahmood Malik2 and Kinji Mori1 *1Department of Computer Science, Tokyo Institute of Technology Tokyo,* 

Emerging rich interactive Web services require timeliness and high availability. These applications are usually characterized as high I/O intensive service model such as ecommerce services, medical sciences including healthcare and digital imaging. [1,3]. These applications require continuous operation, non-stop service system and timeliness to achieve high assurance to meet Service Level Agreement (SLA). SLA is the explicit requirement of the Quality of Service (QoS), such as reliability and timeliness. SLA requirement in the emerging applications on the Internet needs Autonomous Decentralized

The usage of Web services on the Internet is increasing exponentially and giving rise to very large online community. Web service community behavior shows power functions (from 2.1 to 4) that is called "small world". Therefore, some web sites are much more popular and hence highly I/O intensive. In these websites, there is considerable response time delay due to increasing demand of user push type I/O request and its data coherence. Faded Information Field (FIF) technology supports pull type of read event access enhancement while Autonomous Decentralized System by different class of nodes by its service level. But Web services require interoperable communication for user push type also. Traditional system does not meet the dynamic demand and it doesn't have Multi layer-cache concept. To enhance the user push type I/O performance, there are two approaches. One is the cache node approach and the other is selecting a high performance device. Each of them has pros & cons. High speed device such as NAND Flash SSD has less capacity and very limited write life cycle time. Proxy cache node effects for read event but it doesn't achieve write event on each node dynamically. Thus the interoperable I/O performance is not enhanced by existing approaches. How to solve these issues by the system architecture is proposed by this paper. First is to achieve timeliness user pushing type I/O performance by using write back cache processing node (P-Node). Second is to maintain online property by trio nodes by dual data field configuration. The third is data availability which is achieved by dividing processing node and content node in two data fields and duplicating data storage partitions. This system architecture has two data fields with trio nodes Autonomous Decentralized

**1. Introduction** 

System (ADS) [8] characteristics [2,4].

