Performance analysis in traditional distributed computing systems has always been inherently complex given the combination and interplay of behaviours associated with various operational components such as application routines, operating systems, communication protocols, the network infrastructure, and CPU and storage hardware nodes. In Service Oriented Architecture- (SOA)-based distributed systems, where functional capabilities are abstracted and presented as service packages, accurately determining performance patterns is even more challenging. The increased complexity arises from additional characteristics of the middleware-based service framework. In this paper we propose a conceptual approach for modelling SOA performance, which is based on understanding (a) the behaviours manifested in the SOAbased infrastructure and (b) the properties associated with the underlying physical resource landscape. The parameters used in developing the SOA performance models are derived from the service taxonomy that we also present. Finally, an initial conceptual method for service performance modelling is developed.
A dominant trend in distributed computing is the current migration of Information Technology (IT) systems towards the Service Oriented Architecture (SOA) design. The principal idea behind the adoption of the SOA paradigm is to define and present the functional capabilities of IT infrastructures to user environments as addressable and reusable services. As shown in Figure 1, the SOA-based IT implementation approach can be summarised into a layered organisation. Such a functional structure permits simple, incremental and safe enhancements on the IT infrastructure. Furthermore the layered organisation of the functional elements bridges the semantic gap between corporate business goals and technical IT functions. As a result, the flexibility inherent in the standards-based SOA implementations enables the automation of enterprise processes and measurable performance of business tasks.
The basic makeup of the SOA system implementation consists of the following functional layers shown in Figure 1: (a) Business Process Layer in which service compositions are defined (b) Enterprise Services Layer that provides specific service offerings for the needs of the enterprise domain as well as the virtualised Utility Services environment, in which the operations executed by physical resources are presented as accessible service capabilities and (c) the Physical Resource Fabric made up of distributed hardware and system platforms that perform the actual physical operations for service delivery.
Included in Figure 1 are the performance components associated with each of the layers of the SOA stack. Operational Performance is obtained from the runtime implementation of application routines as they execute in the hardware environment. Service Performance is derived from the lowest level of service provision, where the functionality of a single service is accessed through interfacing mechanisms. Process Performance is based on executions of integrated service packages that are brought together to achieve a concrete business result.
The success of SOA implementations requires going beyond the technical
breakthroughs (such as provision of standardised and flexible technologies) that have
already been achieved in bringing together reusable functional components for service
oriented IT systems. In order to plan for and review SOA implementations
systematically, there is also a need for information-rich and structured formats that
describe service attributes. Such descriptions should (a) permit the methodical
analysis of the SOA landscape’s makeup and (b) enable systematic integrations of
service components in the development of SOA solutions. According to the
discussion presented in [
While the taxonomies aimed at satisfying the above-mentioned requirements serve a useful purpose in planning for and evaluating SOA implementations, such classifications do not sufficiently address the complexities associated with performance analysis in distributed SOA systems. The functionality of the dispersed SOA frameworks is characterised by the interplay of multiple behaviours. These characteristics emanate from the physical resource fabric (made up of processing, communication, storage, application and system software components) and the behaviours associated with the individual service elements in the middleware-based service framework. Our proposals for a taxonomy set out to address the following aspects: (a) provision of service classifications for capturing key characteristics having a bearing on performance trends associated with both the service and physical resource landscapes and (b) presentation of performance-related characteristics so that the related functions of SLA/QoS guarantees, optimisations and fulfillment of performance goals are supported in SOA environments. Our approach of developing and using the service taxonomy in a performance-oriented way is in contrast to previous contributions, which have provided fairly general classifications that largely pay attention to service characteristics relating to functional capability. 2
Perhaps as the starting point in proposing our service taxonomy, it is worth
considering other related research contributions on the subject. The discussion in [
Another guiding objective which is becoming increasingly important to take into account when developing SOA-based IT systems is the need to design infrastructure deployments that meet specific performance targets. Therefore, the consideration of how service categories can present information for supporting evaluation and planning of performance delivery over the SOA-based deployments is a further aspect to address in the choices of service classifications we adopt. 2.1
As the preceding discussion notes, considerable public discussion has been directed at
the subject of service taxonomies, with most of the related work presenting different
flavours of service classifications featuring functional capabilities [
To present service characteristics in a performance-relevant way, we propose the adoption of the following as the main categories: (a) Service Functionality, (b) Relationships, (c) Interfacing and Runtime Properties, (d) Deployment and (e) Execution Strategies. It is worth pointing out that a substantial part of service classifications built into our taxonomy borrows from already existing classifications. To assist the readers appreciate the performance implications of the service categories that we present, full discussion on the subject is provided in the next section. The five major categories comprising our taxonomy are briefly considered from 2.2 to 2.5. 2.2
Classifications of service functionality provide clear boundaries on the capability that individual services can and cannot offer. Such classification enables solution architects to determine the appropriate combinations of services required in a complementary fashion to meet the specific needs of SOA-enabled applications.
The discussion by Cohen in [
The approaches taken in deploying and executing services provide further categories that we consider important to include in the taxonomy. As Figure 5 shows, Service Deployment determines in which part of the resource infrastructure service objects are installed to run (i.e. whether the intra- or extra-organizational arrangements can be made for accessing required services). The Service Execution choices determine the approaches taken in the invocation of individual services that make up compound applications. The choice of marshalling strategy depends on the quantity of and dependencies between constituent services objects that are assembled into a SOA solution. Choreography-based techniques direct the execution of service routines through the operational logic residing inside the service components themselves. Orchestration approaches use external logic to fix the order and coordination of constituent service operations.
As stated in 2.1 and also shown in Figure 5, we consider the interactions of services an important dimension that the service taxonomy must capture. The description of the interactions through service relationships summarises the respective roles that constituent services play in accomplishing SOA solutions, particularly in scenarios where composite services are used.
Based on the set of relationships described in the OGSA document [
Each service element has attributes according to which its principal behaviours are
characterised. The taxonomy according to [
The Interfacing definitions provide protocol-based descriptions for exposing functions in a service. The State Management definitions determine how a service responds to messages having a bearing on the status of a running application. Provided by the Transaction Handling characteristic is a service’s capability to receive, process, generate and transmit data in collaboration with other service objects that it has dependencies with. The Error Handling functions specify the corrective ability in a service to deal with operational inconsistencies of SOA-enabled applications. Security Enforcement determines the protection offered during service interactions.
As brought out in Section 1, this paper’s focuses on developing a methodology for modelling and evaluating the performance of SOA implementations by considering how the service dimensions captured in the service taxonomy have an impact on performance. In the set of service classifications presented in the taxonomy, five broad categories are proposed as Figure 5 shows. From 3.1 to 3.3, we briefly consider the performance implications of the Functionality, Relationships, Deployment, Runtime Properties and Execution Strategies of service.
The service taxonomy summarises the interactions of services through the service
relationship category. The service relationships describe the respective roles that
constituent services play in accomplishing SOA solutions, especially in scenarios
involving use of multiple services. From the descriptions presented in 2.4, it can be
appreciated that the nature of service relationships employed by SOA architects
determines how services are joined up in accomplishing end-to-end process solutions.
In turn, the integration of services as well as conditions governing their invocation
can lengthen the overall response time of assembled business processes. In order to
formally describe the phenomenon of service relationship in SOA performance
models, Rud et al. in [
Interfacing descriptions are a key component of Service Properties as presented in the
taxonomy [
Besides the delays occurring prior to service execution, properties of state management, transaction handling, security enforcement and error correction contribute to additional overheads during runtime as Figure 4 shows.
We have highlighted that physical deployments of individual services determine how readily they are accessed from user environments. For local deployments of services, performance evaluation would consider host system settings such as CPU speed, Caching Techniques, Page Fault levels and Disk access mechanisms. In most end-toend process integrations, significant increase in overall process response times is experienced when component services are scattered over a wide geographic area. For distributed SOA systems, additional overheads due to network latencies such as bandwidth, congestion and propagation delays need to be considered.
In Figure 5, an all-encompassing description of the service taxonomy that summarises both the key dimensions of service characteristics and their impact on performance as discussed in Section 3 is shown. Using the set of service classifications shown in Figure 5, four important steps, which will provide a taxonomy-driven template for SOA performance modelling are derived. The taxonomy-based modelling approach is outlined as follows:
Stage 1: Based on the needs of the received service request, determine the required service groupings, S1 – SN, and their interactions based on existing functional capability and the choices of service relationships. In the real-world treatment of this modelled stage, the considerations made would ensure that sufficient serviceprovision capacity is in place to fulfil the requirements of the accepted request.
Stage 2: From the choices of individual services brought together to provide a solution, we determine the overheads associated with protocol-based service accesses, TProtocol, and operational overheads, TSecr, TTransac and TError, during service execution.
Stage 3: Based on the physical deployment(s) of the individual services in use, we determine the hardware-based costs associated with host machines and the network infrastructure. For a local host system, service time, TCPU, is a function of such settings as CPU speed, Caching and Virtual Memory techniques, and Storage Access mechanisms. For distributed SOA implementations, the network delays of bandwidth, propagation and congestion times (TBW, TProp and TCong) also needs to be considered.
Stage 4: From the option that is chosen for the coordination of service executions, we establish the costs, TIntraprocess and TInterprocess, associated with message exchanges both within and between constituent process and service elements.
The initial model presented here is a simplified version of the design template we have proposed. Although Figure 6 shows parameters associated with a distributed implementation for completeness, we use a simplified construct based on standalone deployment i.e. generated requests access target services on the same machine. The collection of service elements, S1 – SN, in Figure 6, is derived from the application needs and dependencies between constituent services. The service execution time is a function the local machine’s system settings. Because sequential operation of services is assumed, execution strategies for messaging and coordination of service functions are treated as embedded features inside each constituent service.
We now present the analytical description of the simplified model, where there are s services. Each service has exponential duration with rate μ and, with probability pi, an application requires i services, for i=1,…,k. So the total execution time of an application which requires i services, denoted by Xi, is the convolution of i independently and identically distributed (i.i.d.) exponential random variables (r.v.s), each with rate μ. The distribution of of Xi is then special Erlang with probability density function (p.d.f.) given by:
i=1 with corresponding mean
(i − 1)! s p i m= ∑ i .
i=1 μ fi (x) = μ i xi−1e −μx (i − 1)!
x>0, with corresponding mean i/ μ and variance i/ μ2.
For any application, the p.d.f. of completion time is therefore: f (x) = ∑s piμ i xi−1 , The survival function F(x) = Prob(X>x) is given by:
s r−1 pr (μx)i e −μx F (x) = ∑ ∑ ,
i! r=1 i=1 where this function tells us how likely it is that a given application request exceeds a QoS threshold.
For the invocation of composite services, we model the instances of the internal services, CServices, as a variable parameter that ranges between 1 and 10 component services, S1 – S6, according to the uniform distribution characteristic. We characterise the CPU execution time, TCPU, according to the exponential distribution with mean of 0.5 seconds. In Table 1 we present the list of parameters that were defined for the preliminary model.
Probability of exceeding a specified duration
threshold x
Example1: We consider the case when s=10, μ=1 and pi =1/10 for i=1,…,10. In this case, m =5.5. In Figure 7 we illustrate the probability of exceeding a specified threshold x as a function of x. Thus, we can see that, for these data, if we have a QoS contract to execute 95% of requests in less that 10 time units, the current system will not be able to comply since the probability of exceeding 10 time units is 0.125, i.e. only 87.5% jobs will meet the QoS specification.
The discussion started by highlighting the complexity involved in analysing performance of distributed IT infrastructures, which results from the occurrence and interplay of multiple behaviours associated with the functional components of dispersed SOA frameworks.
We then proposed a modelling approach based on the classifications of important characteristics of the service and physical resource landscapes so that SOA performance is accurately characterised. Based on this taxonomy-driven approach, we presented a simple example model, which described service performance on a single machine. We use our taxonomy to inform the modelling of service performance by capturing those aspects of the service and physical resource domains that have direct bearing on SOA performance delivery. We believe that the modelling approach we have presented can provide accurate characterisation of performance patterns over SOA frameworks since it is based on a comprehensive set of service classifications that are relevant to performance.
In order to enhance the modelled features presented, further work will consider
using the taxonomy for more complex scenarios on SOA performances modelling by
giving detailed attention to hardware characteristics. We will also investigate the use
of our approach to support the SLA-based modelling of (a) Brokering and
Optimisation through orchestration strategies that will explore parallel strategies in
conjunction with service relationships and execution strategies, and (b) Autonomic
capabilities or real-time intelligence in responding to unexpected operational changes.
We also plan to carry out validations of our example models with benchmarked
results from SOA implementations on physical test bed infrastructures and analyse the
effects of loading on the distributed infrastructure in terms of likelihood, duration, and
levels of congestion. To determine the effectiveness of our approach of
taxonomybased treatment of SOA performance, we intend to compare our results with other
outputs from related work on SOA modelling and simulation frameworks [
Acknowledgments. We would like to express appreciation for contributions by researchers at SAP Belfast Laboratory with whom we had insightful discussions on the various topics presented in this paper. This research was jointly supported by INVEST Northern Ireland and SAP.