Measuring Web Service Interfaces

Transcription

1 Measuring Web Service Interfaces Harry M. Sneed ANECON GmbH, Vienna Abstract The following short paper describes a tool supported method for measuring web service interfaces. The goal is to assess the complexity and quality of these interfaces as well as to determine their size for estimating evolution and testing effort. Besides the metrics for quantity, quality and complexity, rules are defined for ensuring maintainability. In the end a tool WSDAudit is described which the author has developed for the static analysis of web service definitions. The WSDL schemas are automatically audited and measured for quality assurance and cost estimation. Work is underway to verify them against the BPEL procedures from which they are invoked. Keywords web services, WSDL, metrics, rule checking, quality, complexity, sizing, static analysis, code inspection, interface rule checking 1. SIGNIFICANCE OF WEB INTERFACES The web service interface acts as a hinge between the business processes and the underlying software services. The business processes in the foreground, implemented with BPEL, Java or some other business process language require the web service interface to communicate with the services in the background. It serves not only as a communication media between the client and the service, but also as a specification of the service functionality. The quality and complexity of the service interface is a good indicator of the quality and complexity of the service itself. From the interface description assumptions can be made about the effort required to test the service. The interface description is also a good indicator of how the service may evolve. Any change to the interface will affect both the business process above it and the services below it. [1]. However, change is inevitable. As business processes change, the requirements on their services change and that means altering the interfaces. To accommodate change, interfaces need to be constructed in a modular, flexible and testable fashion. Thus, web service interfaces need to fulfill several quality requirements in addition to their functional requirements. It is the task of quality assurance to assess the degree to which these requirements are met. One means of achieving this by static analysis, the subject of this paper. 2. MEASURES FOR WEB INTERFACES Like programs and other software artifacts, interface specifications have a size, a complexity and a quality, all of which can be measured and assessed. These three dimensions determine the amount of effort required to test and to evolve the underlying services. At the bottom of the interface hierarchy are the elementary data types such as strings, integers, real numbers, booleans, etc. These are collected together into data groups or complex types which are either sequences, selections, or repetitions, i.e. repeating groups. Users may define their own complex data types with include other complex types. At the next level user messages are defined. Each user message has a message name and one or more parts. A part refers to a predefined user data type, which may be in the same schema or in some remote schema. Messages are assigned as inputs or outputs to operations, which correspond to methods. The inputs are the requests, the outputs the responses. Each operation also contains an exception condition which refers to a predefined user message. At the top of the hierarchy a service is declared that refers to one or more ports below it. Thus, a WSDL interface is implemented as a cascaded data structure, which can be parsed by tree walking from one level to the next in a recursive cycle [2]. Such a tree structure may become highly complex unless rules are enforced to limit it. 2.1 Service Interface Size Common size measurements are lines of code, number of statements, number of variables (data-points), number of operations (object points) and number of inputs and outputs (function points). All of these can be found in a web service interface schema. Being a source text, the schema has lines of code which can be easily counted, just as with any other source text. The statements can be recognized as an XML tag beginning with a < and ending with a >. If these are nested in each other then each nested tag is counted as a separate statement. The variables declared are of two types group variables and elementary variables. Group variables are defined in a WSDL schema as complex types. They can contain elementary variables as well as other complex data types. In counting data-points the group variables are weighted depending on the number of other group variables they contain. Thus a complex data type which has three nested complex data types would have a weight of 3. Elementary data types have a weight of 1. The number of variables declared in an interface definition, i.e. the data-points, determines the width of the interface, since /10/$ IEEE 111

2 these variables are equivalent to the number of parameters sent and received. If the interface is wide with a large number of parameters, then it can be assumed that the service invoked will have many arguments and results. If the parameters passed are large blobs of data, it will take a longer time to transmit them and more code to process them. If on the other hand the interface is narrow with only a few parameters, then many messages will have to be sent to achieve the same result. This will cause performance problems. The design goal should be to specify interfaces with an appropriate width, having neither too many nor too few data points [3]. The number of object points is computed from the number of elementary data types, the number of messages and the number of operations. Each elementary data type is equivalent to one object point. Each message input, output and fault is weighted with two object points. Each operation, i.e. method, is equivalent to 3 object- points. This object point counting corresponds to that for measuring the size of object models [4]. Function Points are counted on the basis of inputs and outputs and data stores. According to the IFPUG method inputs weigh from 3 to 6, outputs from 4 to 7 and data stores from 7 to 15 [5]. Imports and exports between systems weigh from 5 to 10. The service request in its entirety can be considered to be an import / export file. If it has a high complexity, i.e. above 0.6 it should weigh 10. If it has a low complexity, i.e. below 0.4 it should weigh 5. With a medium complexity from 0.4 to 0.6 it will weigh 7. In addition to that the input and output messages should be counted as follows: an input message = 3 if message contains less than 4 data types 4 if message contains 4 to 7 data types 6 if message contains more than 7 data types an output message = 4 if message contains less than 4 data types 5 if message contains 4 to 7 data types 7 if message contains more than 7 data types The total function point count is the sum of the interface weight and the weights of each input and output message. What is missing is the count of the data stores. Since a service request has no memory, it also has no data store. As such it is not possible to recognize, which databases the service will access. This could be overcome by including a URL to each database table to be accessed by the target service. This would also solve the problem of data state in using web services. The client or service requester should keep the data under his control and only pass references to the data on to the service. In this way the web services can remain stateless and are not burdened with the responsibility of maintaining the client data. 2.2 Service Interface Complexity The literature on metrics identifies three types of software complexity: lingual complexity structural complexity and algorithmic complexity [6]. The metrics of Shannon for measuring the complexity of communication messages and of Halstead for measuring the complexity of program texts are good examples of lingual complexity. Both count the number of different semantic element types used in a text and compare them to the total number of semantic element occurrences. Shannon was counting different code types whereas Halstead was counting operators and operands [7]. In a WSDL schema there are some 18 semantic element types [8]. The number of occurrences is sum of all WSDL statements, e.g. each data type definition, each message definition and each operation definition. Like with any other programming language, the lingual complexity of a service interface definition is 1 = {statement types / statement occurrence} As with Halstead small interface definitions are penalized. They will have a lower lingual complexity than large definitions with many statement occurrences. To offset this imbalance, the number of statement occurrences should be bounded. WSDL schema offer many opportunities for measuring structural complexity. In general structural complexity is defined as 1 - {Entities / Relationships} The entities of a service interface definition are the instances of the data types, messages, operations, parameters, bindings and ports defined in the schema definition and occurring in the target interface. They are identified by parsing the interface definition and storing them in internal tables. Every such entity is uniquely identified by type and name. Web service interfaces have relationships of two types: Horizontal and Veritical The vertical relationships are the compositions. Group data types are composed of elementary data types. The parts or parameters are composed of group data types. Messages are composed of parts and are assigned as inputs, outputs or exceptions to an operation. A port contains one or more operations and is assigned to a binding or SOAP message. These compositions are recognized by the parser based on the nesting of the elements. The possible horizontal relationships in a WSDL schema are the cross references from one schema to another and from one data type to another. They are implemented as URL or Href references. The href cross reference is the GOTO of web data structures and should be avoided in interface definitions. However, it is sometimes necessary to connect two interfaces with each other. 112

3 The structural complexity of an interface definition can be summed up in the correlation 1 - {entity types / entity relationships} The more relationships there are relative to the number of entity types, the higher will be the structural complexity. In this respect the complexity of a service interface corresponds to the complexity of any software architecture. Interface definitions being purely declarative, have no computational complexity. Therefore, the complexity of a web service interface can be seen as the median value of lingual complexity and structural complexity. 2.3 Service Interface Quality The quality of a service interface definition can be interpreted in different ways. There is no one all encompassing view of quality. Quality is in the eyes of the beholder. If he is a tester, then testability is for him the essence of quality. If he is a maintenance programmer then maintainability is the key issue. If he is a system integrator then reusability and modularity are the most important features. Finally, if he is a business process developer he is looking for usability and above all reliability. For him reusability and testability are secondary issues. Thus, a piece of software should have many qualities with varying degrees of importance depending on the situation. The first task of quality assurance is to establish the quality goals as defined above. The second task is to ask how these quality goals can be fulfilled. The third task is to define a metric to measure the degree to which a goal is fulfilled. Finally, a tool is required which will implement the measurement. This is the essence of the Goal-Question- method [9]. There are some qualities such as reliability and efficiency which can only be measured dynamically thru testing. However many qualities, especially those of an interface definition, can be measured statically by means of static analysis. These are: Reusability Testability Modulanty and Maintainability Usability is with regards to a service interface the degree to which the interface definition can be easily adapted to the requirements of the user. Usability is equivalent here to flexibility. Flexibility implies a maximum of user influence and a maximum granularity of the data structure. The smaller the data units, i.e. the more data sets there are relative to the number of data elements, the easier it is to adapt them to new requirements. The metric for usability combines these two features Usability = {user data types / all data types} x {group data types / elementary data types} Reusability is a question of independence from a particular environment. It is the ease with which a piece of software can be taken out of its original environment and reused in another. The less dependent the software is on the other software around it, i.e. the fewer its external relationships, the higher is its reusability. Dependencies in a web service definition schema are references to other schemas or data types outside of this schema. Href s and URL s are samples of this. The metric for reusability is Reusability = 1 - {external referenced data types / all data types} Testability implies a minimum of test effort. Test effort is determined by the number of operations to be tested and the number of parameters they have [10]. The least operations there are to test and the less the number of their parameters, the less will be the required test effort. The metric for testability is Testability = 1 - {operations + message parts /data - types} Modularity is interpreted in the literature on design quality as achieving maximum cohesion and minimum coupling [11]. High cohesion of a service interface can be measured in terms of the number of data types relative to the number of operations. The less the number of data types per operation, the higher is the cohesion. The metric for cohesion is Cohesion = {operations / data - types} Coupling can be seen as the number of operations invoked per port. That corresponds to the fan out of a service request. The metric for measuring coupling in a service interface definition is Coupling = 1 - {ports / operations} Modularity as a whole is the arithmetic mean of cohesion and coupling Modularity = { (cohesion + coupling ) /2 } Maintainability is interpreted here as conforming to the rules for developing maintainable web service interfaces. These rules will be discussed in the following section on rule checking. What is important here is that these rules should be adhered to. Maintainability is the degree to which they are adhered. Of course, the rules vary in their significance. There are rules with high significance, rules for minor significance and rules with a medium significance. Violations of rules with a high significance, i.e. major rule violations, are weighted by 2. Violations of rules with a medium significance are weighted by 1 and violations of rules with a minor significance are weighted with 0.5. The metric for maintainability, i.e. rule conformity, is: Conformity = {weighted rule violations / WSDL statements} The final quality rating of a service interface can be computed as the weighted average of these individual quality metrics. (see Figure 1) 113

4 Class Quantity Size Complexity Quality Type Count Count Ratio Ratio all elements types of a WSDL schema number of statements number of function points number of object points number of test points structural complexity referential complexity hierarchical complexity relational complexity attributal complexity Flexibility Reusability Testability Modularity Conformity Computation Occurrences Weighted inputs & outputs Weighted data types Test case count entities relationships soll ist Goal Readability Flexibility Reusability Testability Performance Modularity Complexity All names should be according to a naming convention Messages may not refer to standard data types Data groups should be small Operations and their parameters should be limited There should not be so many small requests There should be no more than one interface per source file The number of Interdependencies between interfaces should be minimized Check Names are checked against name templates before defined by the user Data types referenced by message are checked that they are not standard Data groups are checked that they do not contain more than 10 elements Interface is checked that it contains no more than 7 operations, 14 messages and 50 data types Message are checked that it contains at least 3 complex and 10 simple types Source files are checked that they contain one interface definition Schema is checked that it does not refer to more than 7 other schemas Figure 2: s for Checking Web Service Interfaces Figure 1: s for Measuring Web Service Interfaces 3. RULES FOR WEB SERVICE INTERFACES Having established how a web service is structured according to the WSDL 1.1 standard, the next step is to define rules for constraining that structure. The purpose of the rules is to promote readability, to increase flexibility, testability and reusability, and to reduce transmission time as well as to reduce complexity. The question is how to construct an interface so as to best serve these goals. For this, the author has established a set of 12 WSDL coding rules to be enforced [12]: Adherence to the current standard Use of prescribed name spaces Use of in source documentation Avoidance of any data type Adherence to the naming convention Hiding of elementary data types Restricting the size of data groups Limiting interface width Enforcing the first normal form Minimizing the number of requests Not exceeding a give size limit Limiting the use of links All of these rules can be checked by a static analyzer tool when parsing the web service definition. Each rule violation needs to be recorded, weighted and reported as a deficiency. Then, the interface can be graded in terms of its conformity to the rules. (see Figure 2). 4. WSDAUDIT A TOOL FOR AUDITING WEB SERVICE INTERFACE DEFINITIONS The tool for checking the rules and measuring the web service interface sources is WSDAudit. The tool is given a list of WSDL sources to process plus a set of rules to check and a list of measurements to take. It is also given a list of naming templates. It then parses the WSDL sources by tree walking up the XML hierarchy. For each statement it checks the name against the naming templates, checks the references, and counts the statement and attribute types. The counts are accumulated in a metric table. The rule violations are written out in a deficiency report, referring to the source and the line where they occur. After all sources have been processed, the deficiency report is closed out and the metrics are presented in a metric report grouped by source counts, data counts, relation counts, size metrics, complexity metrics and quality metrics. With the size and complexity metrics an estimator is better able to estimate how much it will cost to maintain and evolve the service interfaces while the tester is better able to project the test costs. In addition, the tester is better able to assess the quality of a web service interface and to make constructive proposals as how to improve it before testing even begins. (see figure 3). 114

5 WSDL Sources User Interface WSDL Audit Control Module Name Templates List Weights interfaces by means of static analysis. The prerequisites to applying this method are a set of rules, a set of metrics and a tool for parsing the interface definitions. Here all of the basic prerequisites have been fulfilled. A set of 11 coding rules has been established. 25 quantity, 4 size, 5 complexity and 5 quality metrics have been defined. Finally a tool has been developed to check the rules and to calculate the metrics. Still it remains to empirically validate the assumptions upon which the rules and metrics are based. Checker Deficiency Report WSDL Parser Calculator Report Figure 3: WSDAudit A tool for auditing web service interfaces 5. FUTURE WORK It is clear that there is still much to do to ensure the quality of web service interfaces. For one thing the standard should be extended to include semantic information. It should be possible to verify the interface definition against the service requirements. For instance, the parameter types should be compared with the data types of the from and to variables in the corresponding BPEL procedure [13]. Also legal statements contained in the service level agreement should be parsed and compared with operations in the interface definition to make sure that they are being handled [14]. Furthermore, there should be more and better rules to check against. The rules have to be extended to cover WSDL-2. Above all the metrics need to be tuned and validated. More empirical evidence is necessary to prove the correlation between static and dynamic quality characteristics and between sizing metrics and actual effort. Finally, the tool itself should be tuned to become more accurate and easier to use. 6. SUMMARY This short paper has presented a method for measuring and assessing the size, complexity and quality of web service 7. REFERENCES [1] Tonella, P. / Ricca, F.: Dynamic Model Extraction and Statistical Analysis of Web Applications, Proc. of 10 th WSE-2008, IEEE Computer Society Press, Beijing, Oct. 2008, p. 3 [2] Lucca, G. /Penta, M./ Antoniol, G./ Casazza, G.: An Approach for Reverse Engineering of web-based Applications, Proc. of 8 th WCRE Workshop, IEEE Computer Society Press, Stuttgart, Oct. 2008, p. 51 [3] Sneed, H./Göschl, S.: Testing Software for Internet Applications, Software Focus, Vol. 1, No. 1, Sept. 2000, p. 15 [4] Sneed, H.: Estimating the development costs of object-oriented software, Proc. of 7 th European Software Control and s Conference, Wilmslow, G.B., 1996, p. 135 [5] IFPUG: Function-Point Counting Practices Manual Release 4.1, International Function-Point Users Group, Westerville, Ohio, 1999 [6] Laird, L. /Brennan, C.: Software Measurement and Estimation, John Wiley & Sons Pub., New York, 2006, p. P. 54 [7] Hughes,R.: Practical Software Measurement, McGraw-Hill, London, 2000, p. 53 [8] Web Service Description Language (WSDL), Vers 1.1, [9] Basili, V. /Caldiera, C./Rombach, H.-D.: Goal Question Paradigm Encyclopedia of Software Engineering, Vol. 1, John Wiley & Sons, New York, 1994, p. 469 [10] Collard, R: Test Estimation with Test-Points, Proc. of StarEast Conference, Washington, D.C., June, 1999, S. 112 [11] Stevens, W. /Myers, G./ Constantine, L.: Structured Design Complexity, IBM Systems Journal, Vol. 13, Nr. 2, 1974, p. 115 [12] Tayi, G. /Ballou, D.: Examining Data Quality, Comm. Of ACM, Vol. 41, No. 2, Feb. 1998, s. 54 [13] Juric, M.B.: Business Process Execution Language for Web Services, Packt Publishing, Birmingham, U.K., 2004, p. 47 [14] Kienle, H. /Vasiliu, C.: Evolution of Legal Statements on the Web, Proc. of 10 th WSE2008, IEEE Computer Society Press, Bejing, Oct. 2008, p