MARTE performance annotations into a Layered Queueing Network (LQN) performance model. An aspect- oriented modeling approach is used to represent ...
Proceedings of the International Conference on Electrical and Computer Systems Ottawa, Ontario, Canada, 22-24 August 2012 Paper No. 132 (The number assigned by the OpenConf System)
Aspect-oriented Modeling of Platforms in Software and Performance Models Mohammad Alhaj, Dorina Petriu Department of Systems and Computer Engineering, Carleton University 1125 Colonel By Drive, Ottawa ON Canada, K1S 5B6 {malhaj|petriu}@sce.carleton.ca Abstract – This paper discusses a model transformation approach for generating queueing-based performance models from the UML design model of service-oriented applications, with the goal of evaluating the performance of the system to be built early in the software development lifecycle. Using a performance model for verifying whether a software design will meet its performance requirements is promoted by the Software Performance Engineering methodology. The paper focuses on the model transformation chain PUMA4SOA, which transforms automatically a UML model of a service-oriented architecture (SOA) system extended with MARTE performance annotations into a Layered Queueing Network (LQN) performance model. An aspectoriented modeling approach is used to represent different services of the intended SOA platform (needed for performance evaluation). The focus of the paper is on comparing different alternatives for composing the platform models with the platform independent model (PIM) of the application throughout the model transformation process from the SOA design model to the performance model. Keywords: SOA, Software Performance Engineering, Aspect-oriented modeling, Model transformation
1. Introduction Service-Oriented Architecture (SOA) is a software architectural approach that seeks to develop and deploy business applications as a set of reusable services (Earl, 2005). The developers of SOA applications would benefit from the ability to estimate the performance of the proposed design (in terms of response time, throughput and utilizations) in the early development phases, as promoted by the Software Performance Engineering methodology (Smith, 1990). This would require deriving (by hand or automatically) a performance model from the software design model and deployment information. In the case of UML designs, performance annotations can be added with the MARTE profile (Modeling and Analysis of Real-Time and Embedded Systems) standardized by OMG MARTE (OMG, 2009b). An example of a model transformation chain which takes as input a UML software design model with performance annotations and generates automatically various types of performance models (such as queueing networks, Petri nets, simulation, etc.) is called PUMA - Performance for Unified Modelling Analysis (Woodside et al., 2005). The authors of this paper, who were also contributors to PUMA, have proposed an extension called PUMA4SAO (Alhaj and Petriu, 2010), which adds new capabilities for evaluating the performance of SOA systems. The main differences between PUMA and PUMA4SOA stem from the kind of design models taken as input and the separation between the Platform Independent Model (PIM) of the SOA application and the Platform Specific Model (PSM) which incorporates platform details needed for performance evaluation. This allows for the rapid composition of one PIM with multiple platform models, so its performance can be easily evaluated for different platforms. This paper focuses on one feature of PUMA4SOA: the representation of the platform details needed for performance analysis as aspect-oriented models and different alternative ways for composing them with the application model throughout the model transformation chain, as shown in Figure 1. The UML design models with MARTE annotations, the starting point of PUMA4SOA, include three parts: 1) application PIM, 2) deployment diagram, and 3) platform aspect models. The application PIM represents the software design using three views: a) workflow model describing the business process, b) service architecture model representing the hierarchy of the underlying services, and c) service behaviour models 132-1
a) Aspect composition at UML level
b) Aspect composition at CSM level
c) Aspect composition at LQN level
Fig. 1. PUMA4SOA alternative approaches
representing the execution steps of the invoked services. The deployment diagram describes the allocation of software artifacts to processors, needed for the performance model derivation. The platform aspect models represent the structure and behaviour of different service platform (such as service invocation and service discovery) in a generic format. A new OMG standard profile SOA Modelling Language (SoaML) (OMG, 2009a) is also used to express the service architecture model. SoaML extends UML with the ability to define the service structure, behaviour, dependencies, and capabilities. Aspect oriented modelling (AOM) is used to generate the platform specific model (PSM) by weaving a platform aspect model into different locations in PIM. AOM uses two types of models: the primary model, which is the core design model, and a set of aspect models describing concerns that crosscut the primary model. Aspect composition (a.k.a. weaving) in AOM is performed in a number of steps: 1) defining the point cut rules (a set of conditions applied to the primary model to identify the join points) , 2) identifying the join points (the locations in the primary model where the compositions occur), 3) instantiating a context-specific aspect model, by binding the parametric values of the generic aspect to concrete values related to the context of the join point in the primary model, and 4) performing the aspect composition at the join points (France et al., 2004). After obtaining the PSM, a model transformation is performed to generate the Core Scenario Model (CSM). CSM is an intermediate language which aims to bridge the semantic gap between the software and performance domain during model transformations. CSM reduces the complexity of mapping different views from design model to the performance model, and helps checking the consistency of the generated models. The CSM is then transformed to different performance models, such as Layered Queuing Network (LQN) (Petriu and Woodside, 2007) which is solved to produce the performance results of the system. PUMA4SOA provides the ability to transform PIM to PSM based on the AOM approach at three modeling levels: UML level, CSM level and LQN level. Although platform aspect models are originally defined in UML, they can be transformed separately and composed into the primary model at different levels, i.e. UML, CSM, and LQN. In this paper, we will present the composition of platform aspect model at these levels, will also compare the three alternatives for aspect composition and discuss the characteristics of each composition. The paper is organized as follows: Section 2 describes the UML input models with the help of a purchase order system example; Section 3 presents the aspect composition at the UML level; Section 4 presents the aspect composition at the CSM level; Section 5 presents the aspect composition at the LQN level; Section 6 compares the three alternatives; Section 7 discusses briefly the related work; and Section 8 presents the conclusion and directions of future work.
132-2
2. PUMA4SOA input models: Purchase Order System PUMA4SOA begins with developing the Platform independent model (PIM). The top level model is the UML activity diagram in Fig.2a describing the workflow of a simple purchase order system. The workflow starts when the sales server receives the purchase order (PO), followed by a parallel process of
a) PIM: Workflow model
b) PIM: Service Architecture model
d) Deployment diagram
c) PIM: Service Behavior model
Fig. 2. UML input design model
a) Generic deployment diagram for Service invocation
b) Generic sequence diagram for Service invocation Fig. 3. Platform aspect model for “Service invocation” 132-3
invoicing and scheduling activities. The Ship Product activity is then processed by the shipping server. Fig 2b illustrates the service architecture model expressed using SoaML, which defines the participants, their binding rules and their capabilities. Components are stereotyped as «Participant» to indicate parties that provide or consume services. Ports are stereotyped with «Request» to indicate the consumption of a service, or «Service» to indicate the offered service. The details of each activity in the workflow model are described in a service behaviour model. However due to the space limitations, only Ship Product activity in Fig. 2c is presented. The deployment diagram is in Fig. 2d, showing the allocation of software to the hardware. A platform aspect model describes the structure and behaviour of a platform service (such as “service invocation” in Fig.3) in a generic format. In this paper, the SOA platform is in fact the middleware used for service invocation, discovery, publishing, etc. Each middleware service is represented by a different aspect model. Fig.3a illustrates the generic deployment diagram and Fig. 3b the sequence diagram of the service invocation aspect model. As a naming convention the vertical bar ‘|’ indicate a generic role name (France et al., 2004). The |client host acts as the service consumer, while the |provider host acts as a service provider. The middleware on both sides defines two generic roles: the |xmlParser which helps marshal/unmarshals data into an acceptable format, and |SOAP stub for sending/receiving messages.
3. Aspect composition at the UML level Our proposed PUMA4SOA in Fig. 1a shows the aspect composition taking place in the UML design model. The models described in Fig. 2a to Fig 2d represent the purchase order system in UML extended with MARTE stereotypes (such as «GaExecHost», «SchedulableResource», «PaStep»). The primary model is the platform independent model (PIM) in Fig. 2a, 2b and 2c, while the platform aspect model is the generic structure and behaviour of the service invocation in Figs. 3a and 3b. The first step in the AOM approach is defining the point cut rules. Since our proposed aspect (service invocation) applies only to services, the point cut rules must be defined to locate the service calls in the primary model. Fig. 4 defines the point cut rules for Service Invocation. Any UML Message element existing in the service behaviour models of PIM, such that: 1. Message element is expressed in the service architecture model as a service Connection element. 2. Sender’s Life line of the Message element is expressed in the service architecture model as a Participant role stereotyped with «Request» 3. Receiver’s Life line of the Message element is expressed in the service architecture model as a Participant role stereotyped with «Service» Fig. 4. Defining the Point cut rules for Service Invocation at UML level
The result of applying the point cut rules on UML elements of PIM can be either true (if the UML element is of type Message and if the Message is defined in the service architecture model as service Connection), or false (otherwise). The next step identifies the join points by applying the point cut rules to PIM. Based on the point cut rules, the join points are UML elements of type Message. Applying the point cut rules to the Purchase Order system locates four join points defined in table 1. The highlighted message (SetSchedulingDate) of the Ship Product in Fig. 2c is one of the join points. Table 1. Identifying the Join points at UML level Join point InitialInvoiceRequest GetShippingCost ScheduleManufacturingPeriod SetSchedulingDate
UML Element type Message Message Message Message
Sender’s lifeline sales invoicing sales sales
132-4
Receiver’s lifeline Invoicing shipping scheduling shipping
Name of Service Behaviour model Process Invoice Process Invoice Process Schedule Ship Product
Once the join points are identified, a context specific aspect model is generated by instantiating the generic aspect model for each join point. The instantiating requires binding the generic roles to concrete ones, and then assigning context specific performance values to «PaStep» attributes (processing demands, probabilities, etc.) Table 2 illustrates the binding of generic roles: some to existing PIM roles and some to newly created roles. The context specific aspect model is not shown due to the space limitations; however it will appear within the composed model in Fig.5. Table 2. Binding Generic to Concrete roles Generic Aspect |Client |xmlParserC |soapClientC |provider |xmlParserP | soapClientP
Context Specific Aspect sales XMLParserInv (new) SOAPInv (New) shipping XMLParserShip (new) SOAPShip (new)
The final step in AOM is to weave (i.e., compose) the context specific aspect model within PIM, which inserts the context specific aspect model in the PIM at the join point location. Fig. 5 shows the composed model, where the SetSchedulingDate (join point) has been replaced with the context specific aspect model (the gray area).
Fig. 5. Result of composition for Ship Product
4. Aspect composition at the CSM level PUMA4SOA provides the flexibility to perform the aspect composition at the CSM level (AlHaj, 2008). The platform independent model and the platform aspect model are first transformed into CSM models separately, as in Fig 1b and then AOM is used to perform the aspect composition in CSM, following the same steps as at the UML level. In this paper, we skip the description of aspect composition in CSM for two reasons: first because of the space limitations and second because it is similar to the aspect composition at LQN level, presented in the next section.
5. Aspect composition at the LQN level PUMA4SOA allows the AOM aspect composition to be performed at the LQN level (Fig 1c). The CSM of PIM and the generic CSM of platform aspect model are first transformed into LQN models separately. Fig 6a, describes the LQN model of platform independent model of PO system. The workflow 132-5
layer, which represents the CSM top scenario model, is transformed into a top level LQN activity graph associated with a task called Workflow allocated on POproc. The service layer, corresponding to CSM sub-scenario models that describe the services, is transformed into a set of tasks with their owned entries. Fig 6b describes a simplified LQN of the generic platform aspect model, where the middleware model has been integrated. The |Client and |Provider tasks own a client and service entries, respectively. The middleware on the |Client side (|MW1) owns send entry which sends the service request, and the |Provider side (|MW2) owns receive entry which receives the service request. The network delay is modeled by the delay entry of the |net task.
b) The LQN generic Platform aspect model for Service Invocation
a) The LQN model of PIM for Purchase Order system
c) The LQN composed model of Purchase Order system
Fig. 6. The Performance models of Purchase Order system at LQN level
The steps of AOM aspect composition in LQN are similar to the ones for UML and CSM levels. However, with an LQN metamodel, the point cut rules and join points are defined with different model elements. To define the point cut rules, the LQN for the PIM of the PO system (Fig 6a) in conjunction with the UML service architecture model (Fig. 2b) are used. Note that the drawback of CSM regarding the loss of service details has been propagated to the LQN level. The LQN point cut rules for Service Invocation are defined as in Fig. 7. Any LQN entry element that exits in the LQN part representing the PIM, such that: 1. The entry element corresponds to a connection element in the service architecture model 2. The task element corresponding to a Participant owning a role stereotyped as «Request» in the service architecture model is the service client. 3. The task element corresponding to a Participant owning a role stereotyped as «Service» in the service architecture model is the service provider. Fig. 7. Defining the Point cut rules for Service Invocation at LQN level
The point cut rules in Fig. 7 check for a 3-tuple: {entry, task, task} = {service, client, provider}. So any three elements satisfying the rules identify a join point for which the composition is performed. Table 3lists the joint point for Service Invocation for the LQN model of Purchase Order system. Instantiating the context-specific aspect model is the next step. This steps is similar to the one did at the UML level, where the generic roles defined in the LQN model in Fig. 6b are bound with concrete ones. The final step is performing the aspect compositions at the join points. In our Purchase Order example, we composed the context specific aspect model the service invocation of SetSchedulingDate by adding new tasks with entries to the LQM model which express the middleware of the sales (client), shipping (provider), and net (network delay). Fig. 6c shows the result of aspect composition in LQN.
132-6
Table 3. Identifying the Join points at LQN level Joint point Workflow activity {InitialInvoiceRequest, sales, Invoicing} ProcessInvoice {GetShippingCost, invoicing, shipping} ProcessInvoice {ScheduleManufacturingPeriod, sales, scheduling} ProcessSchedule {SetSchedulingDate, sales, shipping} ShipProduct
6. Comparisons between Aspect composition at UML, CSM and LQN levels PUMA4SOA provides the flexibility of transforming platform independent model to platform specific model based on AOM aspect composition at three levels (UML, CSM and LQN). This allows the modelers to select between different modeling languages to perform the AOM aspect composition based on their knowledge and experience. The main advantage of performing aspect composition in UML stems from the language features. UML is an OMG standard modeling language. It is popular and supported by several model-driven tools. We also noticed that we were able to define easily the point cut rules in UML, which is more complicated in CSM and LQN (we have to go back to the service architecture model). Another advantage of performing aspect composition in UML is the ability to modify models with changing requirements, which we cannot do in CSM or LQN. On the other side, CSM and LQN both have a lightweight metamodel, compared with UML, whose metamodel is considerably more complex. This advantage makes the implementation of the aspect composition easier in CSM and LQN; it is significantly easier to insure the composition consistency and to reduce the execution time required for the model transformation in PUMA4SOA. Table 4 summarizes the points of comparison between the three levels. Table 4. Comparison between aspect composition at UML, CSM and LQN levels Points of Comparison Language features (standard, popularity) Modeling langauge abstraction lavel Ability to modifying model with changing requirements Ability to define the point cut rules Metamodel complexity How easy to insure composition consistency Implementation complexity of aspect composition Execution time of model transformations in PUMA4SOA
UML level
CSM level
LQN level
7. Related work This section presents a brief overview of related works. An approach to model platform operations, called performance completions is presented in (Happe et al., 2010). Such completions abstract from platform-specific details and can be instantiated for different target environments using measurements of a test-driver designed especially for a parametric performance completions. Performance completions close the gap between available high-level models and required low-level ones. The paper (Xu et al., 2007) presents a modeling approach for aspect oriented web service composition using UML. The approach was motivated by the fact that the current composite specification, such as BPEL, suffers from several weakness. In (Abu-Eid, 2007) it is presented an aspect oriented approach which aims to make the process of applying features to web services more flexible and less resource consuming. The approach introduced an aspect oriented extension module which modularizes the logic of applied features. In (Feng et al., 2009), a requirement-driven aspect oriented approach for web service composition (WSC) is proposed. In this approach, the level of abstraction of evolution modeling for web services composition has been elevated from business process level to strategic goal level. However, none of the AOM approaches targets platform modeling like in our case. 132-7
8. Conclusion and directions of future work The paper focuses on the ability of PUMA4SOA to transform the Platform Independent Model (PIM) of SOA systems into Platform-Specific Model (PSM) by using AOM. PUMA4SOA is a model transformation framework which aims to generate performance models from different design models for SOA. It provides the flexibility to perform aspect composition at three levels: UML, CSM and LQN. Although the aspect composition follows similar steps regardless of the level, the degree of composition complexity differs between the three levels, especially between the UML and the other two. The complexity depends on the size of the language metamodel. A comparison has been done to present the pros and cons of performing aspect composition at the three levels. The main point of comparisons are related to language features (standard, popular), complexity of metamodel language, implementation complexity of aspect composition, etc. We have implemented aspect composition in CSM (Alhaj, 2008) but not in UML or LQN. We are integrating CSM composition in the PUMA4SOA. We are planning to define other aspects for SOA platform services (such as discovery, publishing, subscription, and message security) and to study their influence on the performance of SOA systems. Acknowledgements This research was partially supported by the Natural Sciences and Engineering Research Council (NSERC) and industrial and government partners, through the hSITE Strategic Research Network.
References Abu-Eid V. (2007), “An Aspect Oriented Approach for Applying Features to Web Services”, IEEE International Conference on Web Services (ICWS07). AlHaj M. (2008), "Aspect Composition in Core Scenario Models", Master Thesis, Department of Systems and Computer Engineering Carleton University. Alhaj M., Petriu D. C. (2010), “Approach for generating performance models from UML models of SOA systems”, Proceedings of CASCON 2010, Toronto, ON, Canada. Earl T. (2005), Service-Oriented Architecture: Concepts, Technology, and Design, Pearson Education. Feng Z., He K., Ma Y., Peng R., Gong P. (2009), “A Requirements-Driven and Aspect-Oriented Approach for Evolution of Web Services Composition”, Proceedings of WMWA '09 the Second Pacific-Asia Conference on Web Mining and Web-based Application. France R., Ray I., Georg G., Ghosh S. (2004), “An Aspect-Oriented Approach to Early Design Modeling,” IEE Proceedings - Software, Special Issue on Early Aspects: 151(4):173-185. Happe J., Becker a, S., Rathfelder C., Friedrich H., Reussner R. H. (2010), "Parametric Performance Completions for Model-Driven Performance Prediction”, Elsevier, Volume 67, Pages 694-716. OMG (2009a), Service oriented architecture Modeling Language (SoaML), ptc/2009-04-01. OMG (2009b), UML Profile for MARTE (Modeling and Analysis of Real-Time and Embedded systems), Version 1.0, formal/2009-11-02. Smith, C.U. (1990), Performance Engineering of Software Systems, Addison Wesley. Petriu D. B., Woodside C. M. (2007), “An Intermediate metamodel with scenarios and resources for generating performance models from UML designs”, Software and Systems Modeling, Vol.6, Nb. 2, pp. 163-184. Woodside C.M., Petriu D.C., Petriu D.B., Shen H., Israr T., Merseguer J. (2005), “ Performance by Unified Model Analysis (PUMA)” Proc. 5th Int. Workshop on Software and Performance WOSP'05, pp. 1-12. Xu Y., Tang S., Tang Z. (2007), „Towards Aspect Oriented Web Service Composition with UML”, 6th IEEE/ACIS International Conference on Computer and Information Science (ICIS07).
132-8
