A Systematic Approach for Composing General Middleware Completions

A Systematic Approach for Composing General Middleware Completions to Performance Models Adnan Faisal, Dorina Petriu, Murray Woodside Dept. of Systems and Computer Engineering Carleton University, Ottawa, Canada

The Problem • Software Performance Models often represent only the application software to be evaluated and its hosting. • The performance of many distributed applications is governed by the middleware rather than the application itself! • A systematic approach for integrating middleware sub-models to the application performance model is required. EPEW 2014, Sept 11 -12, Florence, Italy 2

Performance Completions • Adding platform information to software models for performance analysis is known as Performance Completion • This paper a proposes a systematic approach for generating and composing middleware sub-models as performance completions • Valuable for comparing multiple middleware • All models were built using Layered Queuing Network (LQN) Performance tool final models multiple sub-models Performance Model of the Application Completion Middleware Completions EPEW 2014, Sept 11 -12, Florence, Italy Application Completion 3

LQN Model • Can represent software processes and their deployments • Can represent queuing services for both software and hardware Entry: represents task operation(s) Call: traffic flows from entry to entry using calls request [$think] 2 User {$N} User. H {N} internet [100 ms] Internet {inf} Internet. H {inf} Host : where tasks are deployed 1 web. Op [$web] Web. Server {inf} WSH {32} 4 lan [20 ms] Lan {inf} 1 db. Op [$db] Db. Server {inf} LANH {inf} DSH {32} EPEW 2014, Sept 11 -12, Florence, Italy Task: represents a SW process / logical aspect of HW 4

LQN Model: Parameters • All the entities have multiplicities • All the entities have some parameters service demand/ think time request [z=$think] 2 User {$N} User. H {N} internet [z=100 ms] Internet {inf} Internet. H {inf} 1 web. Op [$web] Web. Server {inf} WSH {32} 4 call multiplicity lan [z=20 ms] 1 db. Op [$db] Lan {{inf} Db. Server {inf} LANH {{inf} DSH {{32} EPEW 2014, Sept 11 -12, Florence, Italy host and task multiplicity latency represented as infinite no. of tasks deployed on infinite no. of hosts 5

Range of Applications Considered Any distributed service system EPEW 2014, Sept 11 -12, Florence, Italy 6

Overview of the Approach • A Primary Application Model without middleware is given • A base middleware sub-model (Base. SM) is created • Base. SM can be extended adopting Middleware Services represented as set of features • A set of features are chosen to produce Specialized Middleware Sub-models suitable for the primary application • The Final Model is produced by composing the Primary Application Model with these submodels. EPEW 2014, Sept 11 -12, Florence, Italy 7

Overview of the Approach Base. SM Primary model (without middleware) Final Model Add Features Compose Specialized Sub-Model EPEW 2014, Sept 11 -12, Florence, Italy 8

1. Base. SM Construction EPEW 2014, Sept 11 -12, Florence, Italy 9

Role-Based Definition of Base. SM • Roles of typical middleware identified • Roles are classified into: Mandatory Roles and Optional Roles. • • Mandatory roles are present in every middleware. Optional roles are introduced by adding features to the base middleware. • Our Base Middleware Sub-Model (Base. SM) is constructed based on the mandatory roles. EPEW 2014, Sept 11 -12, Florence, Italy 10

Roles in Middleware • Mandatory roles: • Client and Servant • Stub and Skeleton • Remote Reference Layer • Transport Layer • Network Layer • Optional roles: • Name Service -> Name. Server • Encryption Service -> Encryption. Agent • Web Application Server -> Service. Manager EPEW 2014, Sept 11 -12, Florence, Italy 11

Mandatory Roles in Base. SM (1) Client Role ||make. Call ||CH ||Client |from. Call $n. Call |c. Operations |c. Op [$c. Fix [$Ca++$msg. Size*$c. Var] $Cmsg. Size*$Cb] |c. Wrapper |from. Client. Op 1 |latency [$z. Latency] |Net. H {inf} |Network {inf} this parameter comes from the primary model (Stub + Remote Reference Layer+ Transport Layer) Roles 1 |s. Op [$s. Fix+$msg. Size*$s. Var] |s. Wrapper |from. Server. Op 1 ||do. Op ||Servant ||SH Network Layer Role (Skeleton + Remote Reference Layer+ Transport Layer) Roles Servant Role EPEW 2014, Sept 11 -12, Florence, Italy 12

Mandatory Roles in Base. SM (2) Variables in service demands ||make. Call ||CH ||Client |from. Call $n. Call |c. Operations |c. Op [$c. Fix [$Ca++$msg. Size*$c. Var] $Cmsg. Size*$Cb] |c. Wrapper |from. Client. Op 1 |latency [$z. Latency] |Net. H {inf} |Network {inf} 1 |s. Op [$s. Fix+$msg. Size*$s. Var] Double bar represents the “placeholder” roles |s. Wrapper Single bar represents the “to-be composed” roles |from. Server. Op 1 ||do. Op ||Servant ||SH Join Calls are used during compositions EPEW 2014, Sept 11 -12, Florence, Italy 13

2. Obtaining Specialized Middleware Sub-models EPEW 2014, Sept 11 -12, Florence, Italy 14

Optional Services as Features Middleware. Service Wrapper Trading Discovery Notification Life. Cycle Event Service. Manager Wrapper Service Manager Resource Management Security Persistence Transaction Concurrency Security Compression Certificates Encryption Concurrency Access Control EPEW 2014, Sept 11 -12, Florence, Italy 15

Feature Realization • Every feature has one/more Realization(s) • Each realization is identified by a unique name that is known system-wide • Two kinds of realization 1. Value-modifying realization: a) b) modifies existing service demand keeps the model compact a) b) adds calls, tasks and possibly hosts the added features may run as separate components possibly on dedicated hosts useful if collecting performance indices of the added feature is intended 2. Structure-modifying realization: c) EPEW 2014, Sept 11 -12, Florence, Italy 16

Realization Example: Compression Feature Value-Modifying Realization |c. Operations [$Ca + $Cmsg. Size * $Cb] |c. Wrapper Value-modifying realization of Compression c. Operations. demand += base. SM. $msg. Size * Compression. $c. Factor |c. Operations [$Ca + $Cmsg. Size * $Cb + $Cmsg. Size * $c. Factor] Structure-Modifying Realization |c. Op [$c. Fix + $msg. Size*$c. Var] |c. Wrapper |from. Client. Op |latency [$z. Latency] |Network {inf} Structure-modifying realization |c. Wrapper |compression [$msg. Size *$c. Factor] |c. Op [$c. Fix + $msg. Size*$c. Var] |from. Client. Op |compression [$msg. Size *$c. Factor] |latency [$z. Latency] EPEW 2014, Sept 11 -12, Florence, Italy |Compression |c. Wrapper |Compression |Network {inf} 17

Structure-Modifying Realization • A Structure-modifying realization is one of the two types: 1. In. Flow. Struct: adds task(s) by replacing one/more calls 2. Out. Of. Flow. Struct: adds task(s) without any call replacement Encryption realization (In. Flow. Struct) ||make. Call |encrypt E [$msg. Size *$encrypt] ||do. Op ||Reque ster. H ||Requester ||Replier |Encryption ||Replie r. H Name. Service realization (Out. Of. Flow. Struct) ||make. Call ||Requester $p 1 |Encrypt ion. H EPEW 2014, Sept 11 -12, Florence, Italy |Name. S |Reques erver. H ter. H |lookup [$look] |Name. Service 18

Additional Information of a Realization • Join. List: list of places where a realization is to be composed. • Can be either a list of join-calls or a list of join-entries. • Join-call: a call which is to be replaced by an in. Flow. Struct realization • Join-entry: an entry for which either: a) its service demand is to be modified by a valuemodifying realization b) new calls are going to be added to it by a Out. Of. Flow. Struct realization • Parameter. List: parameters required by the realization (e. g. , message size, no. of incoming calls etc. ) EPEW 2014, Sept 11 -12, Florence, Italy 19

Obtaining a Specialized Middleware Sub-Model • Features are composed into the Base. SM as directed by a Feature Composition Descriptor • A Feature Composition Descriptor is a text file that contains: • Keyword Compose. Feature followed by Input and output middleware sub-models names • Keyword feature followed by the name of the realizations to be composed • (Optional) Keyword bind followed by binding information, to override the default bindings EPEW 2014, Sept 11 -12, Florence, Italy 20

Feature Composition Descriptor Example 1: Compose. Features (Base. SM -> MWSub. Model) feature Encryption end |c. Op [$c. Fix + $msg. Size * $c. Var] |from. Client. Op |c. Encrypt 1 [$msg. Size * $c. Encrypt] |latency |c. Wrapper ||CH |Enc. H |c. Encryption |Network {inf} |Net. H {inf} Example 2 (with binding overriding): Compose. Features (base. SM -> MWSub. Model) feature Encryption (bind |Encryption. H ||Caller. H) end |c. Op [$c. Fix + $msg. Size * $c. Var] |c. Wrapper |from. Client. Op |c. Encrypt 1 [$msg. Size * $c. Encrypt] |latency EPEW 2014, Sept 11 -12, Florence, Italy ||CH |c. Encryption |Network {inf} |Net. H {inf} 21

Base. SM + (Encryption + Service Manager) ||make. Call ||CH ||Client |c. Op [$c. Fix +$msg. Size * $c. Var] |c. Wrapper |Network {inf} |s. Op [$s. Fix+$msg. Size*$s. Var] |c. Encrypt [$msg. Size * $c. Encrypt] 1 |Net. H {inf} |latency |c. Encryption |Network{inf} |s. Op [$s. Fix + $msg. Size * $s. Var] |s. Wrapper |Net. H {inf} |s. Wrapper |from. Server. Op ||do. Op |c. Wrapper |from. Client. Op |latency [$z. Latency] ||CH |from. Call |c. Op [$c. Fix + $msg. Size*$c. Var] ||Client ||Servant ||SH |Serv Man. H |service 1 [$msg. Size *$service] |s. Encrypt [$msg. Size * $s. Encrypt] 1 EPEW 2014, Sept 11 -12, Florence, Italy |Service Manager ||SH |s. Encryption EPEW 2014, Sept 11 -12, Florence, Italy ||Servant ||do. Op 22

3. Obtaining the Final Model EPEW 2014, Sept 11 -12, Florence, Italy 23

Obtaining the Final Model • The desired final performance model is obtained by composing the specialized middleware sub-model into the primary model as directed by a Middleware Composition Descriptor • Middleware Composition Descriptor is a text file that contains: • a pair of call-sources and their middleware • Call-sources can be either entries, tasks or entries • Following keywords are used to represent a group of callsources: – All. Entries: all entries in the application model – Entries. H(host): all entries of a given host – Entries. T(task): all entries of a given task EPEW 2014, Sept 11 -12, Florence, Italy 24

Middleware Composition Descriptor Use middleware 1 • Example 1: in all the calls of the model Middleware. Spec (All. Entries, All. Entries) middleware 1 Use middleware 2 in all (Entries. H(h 1), Entries. H(h 2)) middleware 2 calls between host 1 and host 2 (Entries. T(t 1), Entries. T(t 2)) middlware 3 (entry 1, entry 2) middleware 4 end later specifications override earlier specifications • Example 2: Middleware. Spec (All. Entries, All. Entries) RMI (Entries. T(User), Entries. T(Web. Server)) RMIPlus. Enc (bind |Encryption. CH Caller. H) default host bindings can (bind |Encryption. SH Callee. H) be overriden end EPEW 2014, Sept 11 -12, Florence, Italy 25

Primary to Final Model request [$think] User {$N} Internet {inf} User{$N} c. Op. U [$c. Fix. U +$msg. Size 0 * $c. Var. U] 2 c. Encrypt. U [$msg. Size 0 1 * $c. Encrypt. U] User. H {N} 2 internet [100 ms] request[$think] Internet. H {inf} internet [100 ms] c. Wrapper. U c. Encryption. U web. Op [$web] Web. Server {inf} WSH {32} 4 lan [20 ms] Lan {inf} 1 db. Op [$db] Db. Server {inf} LANH {inf} DSH {32} Internet. H {inf} Internet {inf} s. Op. WS [$s. Fix. WS + $msg. Size 0 * $s. Var. WS)] 1 s. Encrypt. WS [$msg. Size 0 * $s. Encrypt. WS] 1 User. H {$N} s. Wrapper. WS s. Encryption. WS WSH {32} web. Op[$web] Web. Server 4 c. Op. WS c. Wrapper. WS [$c. Fix. WS +$msg. Size 1 * $c. Var. WS] lan[10 ms] Lan {inf} s. Op. DS [$s. Fix. DS + $msg. Size 1 * $s. Var. DS)] db. Op [$db] EPEW 2014, Sept 11 -12, Florence, Italy Db. Server {inf} Lan. H {inf} s. Wrapper. DS DSH {32}

Demonstration of the Proposed Approach (1) • The web application shown in the previous slide was used • System requirement : Response time < 2 sec • What is the maximum number of users under various middleware products? • 6 different middleware sub-models were composed: RMI, RMI + E, Rest, EJB + E, SOAP • Model Parameters: User think time: 3000 ms web. Op CPU demand: 20 ms Message Size (request, web. Op): 200 KB db. Op CPU demand: 14 ms Message Size (web. Op, db. Op): 300 KB Internet latency: 60 ms Host (WSH and DSH) multiplicity: 32 LAN latency: 10 ms EPEW 2014, Sept 11 -12, Florence, Italy 27

Demonstration of the Proposed Approach (2) Middleware name Model and Feature used RMI Base. SM RMI + Enc Base. SM + Encryption REST Base. SM EJB Base. SM + Service Manager EJB + Encryption Base. SM + Service Manager + Encryption SOAP Base. SM • Values of message sizes, fixed parts of service demands and variable parts of service demands are different for different middleware (Please refer to the paper for their values). EPEW 2014, Sept 11 -12, Florence, Italy 28

Demonstration of the Proposed Approach (3) • No. of User varied from 50 to 900. • SOAP saturates first due to its large XML messages. • REST and RMI+E have similar performance. • Different middleware saturate at different workload varying from 600 to 900 user • Max. no. of users at Response time < 2 sec are SOAP: 600, EJB+E: 650, EJB: 750, REST: 850, RMI+E: 900 EPEW 2014, Sept 11 -12, Florence, Italy 29

Related Works (1) • Verdickt et. al [Ph. D thesis 2007] built CORBA middleware submodels in UML and composed it to UML software models. • Limitations: – Does not consider middleware in general – No automation for building the middleware sub-model – Performance models must come from UML Several works have been done using a Component Based Software Engineering (CBSE) framework called Palladio Component Model (PCM): • Happe et al. [WOSP’ 08] used model-to-model transformation to integrate the low-level details of a Message Oriented Middleware (MOM) into the high-level software architecture model. EPEW 2014, Sept 11 -12, Florence, Italy 30

Related Works (2) • Becker et. al [WOSP’ 08] used “coupled transformation” to compose completions both in generated code and in models. • Strittmatter et. al [ICPE’ 12] developed an abstract connector model for a particular connector (i. e. , Procedure Call Connector) using completions and feature models. • Kapova [Ph. D thesis 2011], incorporated variability in the model transformation process (rather than just in the model instances), using generators based on higher-order transformation patterns. • Limitations: • CBSE is not targeted for performance models and thus components are both system structural objects and model objects. • Component-modeling requires detail knowledge of the software which is often not required in performance modeling. EPEW 2014, Sept 11 -12, Florence, Italy 31

How our work is different • Completions are done at the performance level (using Layered Queuing Network) not in software specification / components + General + Simpler + Smaller + Software detail may be confidential/unavailable • Completions are realized through parameter changes or structure changes EPEW 2014, Sept 11 -12, Florence, Italy 32

Summary • A systematic approach for generating and composing middleware sub-models (i. e. , completions) • A large group of middleware and architectural styles are supported • Performance models can come from any model-creation process. • Middleware sub-models can be customized depending on the features used • Sub-models are generated programmatically • The approach is being extended to work with Group Communication • The proposed approach is being implemented in Java. EPEW 2014, Sept 11 -12, Florence, Italy 33