Service Operations of a Service Provider are catered by underlying application components laid on top of system components. For every Service Operation, the activities of these components cumulatively create the composite impedance 'I' implicit to that operation, which eventually impacts the operation's Performance 'P'. The application components are often modified due to changes in business requirements while the underlying system remains the same. Extending on the fundamentals of previous work [1], this research explores one level of abstraction from system resources to application components and verifies a higher level pattern based projection of certain non-functional features of a Service Operation for modifications to the supporting application components. Pure functional models do not capture quantitative information about resource consumption behavior [1]. So, the Service Operation's application components are decomposed into atomic activities or Delay Points like in-memory Data Processing, File I/O, Database Interaction, XML processing etc., which interface with the system resources (both Queue and Delay) and contribute to the overall Service Operation Impedance 'I'. The paper tries to establish that the total delay (or Impedance) for each type of Delay Point across all the supporting application components influence 'I' and hence 'P' and 'V' in a distinct pattern i.e.
where I DLP1 is the Impedance by a particular Delay Point of Component1. Atomicity of Delay Points is very important as Delay Point types determine their nature of system resource usage, which then manifests as the Delay Point impact pattern. Delay Points should not overlap. 'I' acts as a connector between the Service Operation's internal application Delay Points and external non-functional features. This research focuses on variations to application components/Delay Points instead of inbound workload. Operation Potential (V) is the differential between the maximum request load the Service Operation can cater to maintaining QoS (aka Service Operation's "stress point") and the Service Operation's contractual request load. Operation Performance (P) is the measure of Service Operation's performance under a given load. The less the response time, the more is 'P'. So, 'P' is computed as the reciprocal of the Average Response Time (ART) of the Service Operation. Operation Impedance (I) is the runtime composite delay introduced by the different Delay Points across all the components supporting the Service Operation. Network latencies (inter-component and Provider-Consumer) contribute to 'I' as well.
Significant research has been performed towards measuring and predicting throughput, response time and congestion using queuing network principles. Ways to model, analyze and plan for web performance problems have been illustrated in details [1]. High performance website design techniques involving redundant hardware, load balancing, web server acceleration and efficient management of dynamic data [2] have been discussed. Methods are devised for dynamic selection of services based on user specified preferences and to predict performance of component based services depending on the underlying technology platforms [3,4]. In [5,6], different methods of generating performance models and prediction have been discussed. An assembler tool and a methodology to automatically generate performance models for component based systems have been explored. A performance prediction approach comprising of gathering empirical performance results on COTS middleware infrastructure, a reasoning framework for understanding architectural trade-offs and relationships to technology features and predictive mathematical models to describe application behavior on the middleware technology has been investigated. Different model-based software performance prediction approaches have been classified and evaluated in [7]. Queuing network based methodologies, Architectural Pattern based methodologies, software performance analysis through UML descriptions and other approaches have been discussed.
Further research [8,9,10] has explored various methods of component based performance evaluation with top-down approach focusing on inbound workload, profiling, software containers, UMLs and transactions. However, often application developers find it convenient to analyze application level outputs than system resource or service level diagnostics, for which other human resources are required. Hence, it will be helpful to explore generic, application level, bottom-up methods to assess during development the impact of application component modifications at Delay Point granularity on other non-functional features. The notion of 'I' to facilitate the above through visual patterns remains unexplored. A high level abstract runtime model for 'V', 'P', 'I' and Delay Points related to Service Operations remains to be discussed. Typically, we still have to recourse to performance/benchmark testing of the whole system for impact analysis of application component modifications.
This research aims to achieve the following objectives:
1) For Service Operations, empirically deduce a high level abstract runtime model for Service Operation Potential 'V', Service Operation Performance 'P' and overall Service Operation Impedance 'I'.
2) Decompose the application components supporting the Service Operation into atomic Delay Points.
Point impedances and other non-functional features. Use Least Square Fitting (LSF) and appropriate regression types to derive pattern lines to enable bottom-up and topdown projections of the non-functional features related to service load and performance.
To increase precision of the model and standardize request resource requirements, partitioning of the request load is achieved by constraining the model and method to Service Operation level. Different Service Operations from the same Provider may have different resource requirements.
A Service Framework comprising of Web Services, Servlets, RMI Server, Socket Server, a multi-threaded Web Service Client etc. was created to simulate a Service Contract with provision to vary the various component Delay Points. Tests were run by gradually increasing the request load to the Service Operation. Assuming a stress point for the Service Operation, we observed a typical finite queue system curve [1] for 'V' versus 'P'. Accepting approximation error, for simplifying the model, Piecewise Linear model is applied to divide 'V' values into 3 bands, each with a linear regression (affine form) as the best fit for 'P'. Direct proportionality between 'P' and 'V' considered for each 'V' band: P = IV + c where I is the constant of proportionality with I and c band specific At a given time T 1 , for requests to the same Service Operation, the request/process type, system configuration, resource requirements and contract load condition will be ideally the same. Today, services are run on multi-core, multi CPU servers. So, for simplicity, we assumed Multi-Processor Single Class Queuing Network (open or closed) model approximation [1]. With m resources and D service demand at each resource, the service demand at the single resource queue will be D/m and for the delay resource will be D(m-1)/m. Under light load, the Residence time (R i ') is D (proven) and under heavier load, it will be dominated by the single resource queue:
where V i is the average no. of visits, W i is the average waiting time and D i is the service demand for a request at queue i. As the requests are to the same Service Operation, applying all the above constraints, D i and V i will ideally be same for all requests. As we used the ART of responses in test runs, the variability of W i is averaged out. Considering all the above, R i ' is assumed consistent for all requests at queue i. The experiments had co-located components with local calls between them. Also, only formal Service Contracts are in scope with dedicated, controlled network traffic and not any random service access over public network. Hence, at runtime, no unpredictable fluctuation of network bandwidth or latency is assumed. Average resource usage effect of other Service Operations on requests of the tested Service Operation is assumed. With all the above constraints, we assumed consistency of overall impedance for processing requests to the same Service Operation at T 1 for a 'V' band and mapped the runtime Operation Impedance to the proportionality constant 'I'. Power regression types and Piecewise Linear models were verified. For 'I DP '(x i ) versus 'I O '(y i ), pattern line with Polynomial regression of 3 rd order was the best fit:
For 'I O '(x i ) versus 'P'(y i ) and 'I DP '(x i ) versus 'IF DP '(y i ) pattern line with Power regression was best fit:
For precision, Delay Point atomicity needs to be increased e.g. file type specific File I/O Delay Point. Model calibration needs to be verified. More Delay Points need to be tested e.g. database interaction/contention has not been verified yet. Delay Points were varied one type at a time but real world component modifications will be more complex with multiple Delay Point types modified simultaneously. For this, a method involving Matrix Transpose and Inverse technique can be adopted for both linear and polynomial relations. Different combinations of Delay Point variations and corresponding 'I O ' can be recorded in Matrices. Atomic Delay Points may be treated as independent variables. We can find out the best fit Delay Point Impedance coefficient vector X:
where A is the matrix containing rows of Delay Point Impedances I DP , I FIO etc. from different test runs and B is the single column matrix of 'I O ' for each row in A. X will facilitate 'I O ' projection for any arbitrary combination of Delay Point Impedances.
Minimizing components system resource sharing by spreading the service framework would be good. All of these should enhance overall method precision.
The model will facilitate simple, generic, pattern based means for bidirectional i.e. top-down and bottom-up projections (with some error factors) of 'P', 'V', 'I' and application Delay Point impedances. It will guide fine tuning of the application components at Delay Point levels to retrofit new 'V', 'P' or both requirements. Importantly, we believe this method will allow upfront impact analysis of application component changes during development by the developers themselves without the need of additional testing/system admin resources or much external tool overhead. This should help address the typical resourcing issues faced during service component enhancements and provide potential for time, resource and cost savings. Also, repetitive performance or benchmark (e.g. TPC-C, TPC-App) testing of the whole system will not be required. It will be required initially during pattern creation through application component's Delay Point variation simulation. Thereafter, during future modifications, the developers will need to record the total delay of the modified Delay Point types across the Service Operation components while system testing with some load and plot the data on the patterns for the applicable 'V' band. We wouldn't need software monitors and hence overcome their inherent overhead and OS dependency shortcomings [1].