adfa, p. 1, 2011.

© Springer-Verlag Berlin Heidelberg 2011

A Systematic Approach for Integrating Middleware

Completions to Performance Models

Adnan Faisal1, Dorina Petriu

2, Murray Woodside

3

Carleton University Dept. of Systems and Comp. Eng. Ottawa K1S 5B6, Canada

+1 613 400 70941, +1 613 520 56522, 1 613 520 57213

{faisal | petriu | cmw}@sce.carleton.ca

Abstract. A software design typically addresses only the new components to be

developed, but its execution depends on a wide range of software infrastructure.

A performance analysis of the design must take account of the effect of the in-

frastructure through what has been called its “performance completions”, which

are modeled separately and incorporated in the application performance model.

One goal of analysis may be to compare different middleware subsystems

for their performance impact, which can be considerable. This motivates a sys-

tematic approach to modeling a wide range of middleware. This paper considers

performance completions for middleware, and describes a performance model

template for a generic middleware, which can be adapted to a wide range of ex-

isting and future middleware, and to analysis at different levels of detail. A pro-

cess is described for mapping a particular, possibly new middleware into the

template, and for incorporating the completion into a layered performance mod-

el. The template is applied to several common request-reply middleware sys-

tems.

Keywords: Performance analysis, middleware, role-based modeling, layered

queuing network.

1 Introduction

An application design model captures the functional properties of the application

being developed. But, in distributed systems, application software is built on top of

underlying platform which consists of third-party software (e.g., middleware, hyper-

visor, operating systems) and networks, which is not modeled by the system designer.

For performance analysis of the application the underlying platform needs to be mod-

eled and integrated with the application software model. This issue was identified by

Woodside et al. in 1] and the authors called these performance modeling elements

performance completions (See Fig. 1).

One of the major completion elements for any distributed application is the mid-

dleware. As described in [18], Middleware is a piece of software that operates at the

application layer of the distributed systems to provide a higher-level programming

abstraction. Middleware masks the heterogeneity of the underlying networks, hard-

ware, operating systems and programming language.

Quite often there are multiple options for middleware. The choice of middleware

can significantly impact the performance as described in 2]. In [2], the authors

showed that the transferred message sizes not only change from one middleware to

another, but they also depend on which services are used (e.g., security). It has been

observed that the web services SOAP messages were on average ~4.3 times larger

than RMI JRMP messages. The impact of middleware on system response time in

case of remote invocation was also studied. It was found that Web services were ~9.6

times slower than RMI for simple types (e.g., boolean, integer etc.) and strings, and

~14% slower for instantiation. These examples underline the importance of modeling

the particular middleware used. If the performance analyst can estimate the perfor-

mance effect of various middleware products, the system designer can make platform

decisions that meet both functional and Quality of Service (QoS) requirements.

Fig. 1. Communication infrastructure completions

Several attempts have been made to automate the process of middleware comple-

tion to application software models. Among those, the most significant works are

done by Wu, Verdickt and the researchers at Karlsruhe Institute of Technology (KIT).

Wu et al. [5,6] described a component-based approach for LQN [16,17] modeling

where each software component is represented by a parameterized performance sub-

model stored in a library. Wu does not have a process to generate the sub-models but

the sub-models found in her library can be parameterized . She did not model any

middleware, rather her effort was on composing an arbitrary sub-model to a base

model.

Verdickt et al. [7,8] described a process of automatic inclusion of platform infor-

mation in high-level UML models. Verdickt’s transformation engine takes 3 inputs:

Middleware-independent Model, Middleware Model and Middleware Usage Descrip-

tion, and produces Middleware-dependant Model. Verdickt manually builds the mid-

dleware model and does not describe any process to build them depending on varia-

bility.

Substantial amount of work on infrastructure modeling for Component Based

Software Engineering (CBSE) has taken place at Karlsruhe Institute of Technology

(KIT). In [9,10] Happe et al. proposed a process for parametric performance comple-

tions that is independent of any specific platform. The authors used feature models24]

to represent variability and showed how parametric performance completions can be

applied to Message Oriented Middleware (MOM) in the context of Palladio Compo-

nent Model (PCM). The authors of [12] further extended this idea and developed a

pattern-based performance completion for MOM. This includes an annotation model

to configure the completion as well as a model-to-model transformation to generate

necessary details. The idea of Coupled Transformations was presented in [10,11]. In

model-driven performance engineering, both program codes (e.g., Java) and perfor-

mance models (e.g., LQN) can be generated from the software model (e.g., PCM,

UML etc.). There seems to be gap between the program code and performance mod-

els due to missing platform information (e.g., Middleware). Coupled transformations

are mark transformations that make the relationship between generated code and

completion model explicit. In [14], the communication infrastructure is seen as a con-

nector and the authors showed how an abstract connector model can be extended with

selected adaptations and enhancements (completions) to result in a more detailed

connector model. The authors used an abstraction filter to create suitable models of

connectors. These adapted connectors could be enhanced by choosing from a set of

feature models and finally inserted into PCM instances. In [13,15] the author pro-

posed the so-called ‘CHILIES’ approach that adds variability in the model transfor-

mation process (rather than on the model instances) in order to automatize the inclu-

sion of completions. The author enables variability of transformations using genera-

tors based on the presented Higher-Order Transformation (HOT) patterns.

Our approach is different than these works in many ways.

We propose a process to adapt the middleware sub-model based on the choices of

system designer. The solutions of Wu and Verdickt handle only variability of val-

ues but we also support variability of structure.

We take a completion-based approach rather than the component-based approach

taken at KIT. The notion of completion is more general than the notion of compo-

nent. Not everything in the underlying platform can be modeled as components

(e.g., File Server). But, completions can be used to represent anything in the under-

lying platform that influences performance [1].

The notion of component is complex comparing to the notion of completion. In a

world where system developers need to develop software in minimum amount of

time, our completion-based approach is quick to learn and apply.

Our middleware sub-models are built and composed in LQN, which is a perfor-

mance modeling language. Though such early decision on performance tool reduc-

es the flexibility of an approach, but it makes the whole process of performance

modeling fast, which is desirable in many cases, by reducing the additional step of

transforming context-specific models built in other languages (e.g., UML, PCM

etc.) to performance models.

The main contribution of this paper is to describe a process that can handle the per-

formance impact of the variability of the middleware in use. This is achieved by iden-

tifying and grouping the different roles that take part in various middleware products

into two categories: mandatory roles and optional roles (Section 4). A base middle-

ware sub-model is proposed that is capable to represent large number of middleware

products. A library of realization is presented based on the variability in middleware

services. (Section 5). Next, the paper describes how the base middleware sub-model

can be adapted to the various changes (both in value and in structure) required by the

system designer. This paper sees the middleware as a completion, which makes it

possible to include a large array of underlying platform information (including over-

heads due to distributed communication, network execution, operating system execu-

tion etc.) in the middleware sub-model.

2 Classification of Middleware

In [18], middleware products are classified as follows:

Remote invocation, referring to a set of request-reply protocols which improve on

Socket and MPI [19] communication. The two most widely used remote invocation

techniques in distributed systems are: Remote Procedure Call (RPC) and Remote

Method Invocation (RMI). Example: Sun RPC, Java RMI.

Indirect communication, in which the sender and receiver exchange information

via an intermediary. Therefore, no binding takes place between sender and receiver.

Publish-Subscribe and Message Queues are examples of indirect communication.

Example: CORBA Event Service, WebSphere MQ, Sun Open MQ. The authors with

to model this class of middleware in their future papers.

Distributed objects and components are the two most important programming

abstractions. In the distributed object model, objects (or better distributed objects) are

physically distributed into different processes or computers in a distributed system.

Distributed object models support Remote Object Reference, which is a unique identi-

fier that can be used throughout a distributed system to refer to a particular unique

remote object. Example: OMG CORBA and Microsoft DCOM.

The distributed object model has several limitations such as implicit dependencies,

lack of separation of distributed concerns etc. which motivate the distributed compo-

nent model. Example: Sun Enterprise JavaBeans (EJB), IBM WebSphere Application

Server, JBoss, GlassFish etc.

Web services provide a service interface enabled at the server that allows client

applications to interact with the server by means of requests and replies. Request and

replies are exchanged usually in XML format over an HTTP network, making them

more easily processable and accessible than CORBA services. Most web services use

either XML-formatted SOAP Error! Reference source not found. messages or

REST 25 messages. W3C’s 23 and ORACLE’s Error! Reference source not found.

SOAP implementations of Web Services were very popular until development of the sim-

pler Representational State Transfer (REST) which is an architectural style built on

certain principles using the current web fundamentals.

Multimedia systems are real-time systems that must perform tasks and deliver re-

sults according to a schedule that is externally determined. Most operations (e.g, de-

compression, jitter removal) of multimedia streaming are processed by the client me-

dia players using specialized hardware (i.e., graphics card) and they do not compete

with application software for hardware resources. They require a different kind of

modeling and this paper does not address multimedia systems.

3 Layered Queuing Network (LQN) Performance Models

The performance models in this paper use the Layered Queuing Network (LQN)

16.17] technique. These models directly represent the software components and their

deployment, treat software entities as resources, capture inter-component communica-

tions, and can analyze resource interactions between layers of the application.

Fig. 2 shows a layered web service application as a simple example. Each concur-

rent entity (called a task) is represented by a set of rectangles. The rightmost part

defines the task itself (its name and its thread-pool multiplicity, if greater than 1, for

instance {200}); the other parts represent the task operations, which are called entries,

and are labeled with the host (CPU) demand for one invocation of the entry (e.g. [50

ms] or, for a pure latency, [Z = 100ms]).

Fig. 2. An LQN model of a generic two-tier web application

Each task has a host processor (drawn as an oval, possibly with a multiplicity). A call

from one entry to another is represented by an arrow labeled with the average number

of calls. Every task and host is a queuing server, so requests to an entry first go into

the queue for the task owning the entry, and are served when a task thread becomes

available. An infinite server provides a pure time delay (without any waiting for the

server). It is modeled as an infinite task running on an infinite host (using the multi-

plicity {inf}). Infinite servers are used in this work to represent network latencies.

4 Roles in Middleware

The remote invocations of the different middleware products are extensions of a sim-

ple request reply protocol. The middleware represent a pattern on top of message

passing and support the two-way exchange of messages as encountered in client-

server computing (Fig. 3). As a result, from a performance modeling perspective,

these different groups of middleware products can be modeled uniformly.

Fig. 3. A basic remote method invocation. Role names are preceded by bar (|) symbol.

The sequence of operations shown in Fig. 3 are carried out by middleware compo-

nents/processes that implement these roles 20]. The following subsection describes

these roles along with the components/processes of RMI [21], CORBA 22] and SOAP

[23] that realize them. Subsequent sections will show how various other middleware

products and services can be modeled extending the base middleware sub-model.

4.1 Message Transfer Roles

Message transfer roles refer to the roles that participate in a distributed request-reply

scenario where a client process located in a client computer invoking a servant (i.e.,

remote process or object) located in a server computer via some computer network

(See Fig. 3). Note that roles do not correspond directly to software modules or com-

ponents. It is possible that two or more of these roles are realized by a single software

component/process of a middleware. There are two groups of roles: Mandatory roles

and Optional roles.

Mandatory roles.

Mandatory roles are those that are present in every middleware. These roles are de-

scribed below.

Client and Servant Processes: The originator of the remote invocation is known

as the Client process and the responder is known as the Servant process. In an object-

oriented environment, a Servant class implements the remote interface at the server

side and its objects live within the server process. They are created when remote ob-

jects are instantiated and remain in use until they are no longer needed, finally being

garbage collected or deleted.

Stub: A client-side wrapper that represents the remote object at the client. In mid-

dleware terminology this wrapper is called a proxy or stub. A stub carries out many

tasks: it hides the details of the remote object reference from the client object, it mar-

shalls/unmarshalls arguments and it sends/receives messages to/from the client object.

Both RMI and CORBA define stubs. In SOAP the stub role is played by the SOAP

Client API.

Skeleton: The server-side wrapper is called the skeleton by most middleware in-

cluding RMI and CORBA. In SOAP this role is adopted by the SOAP Request Han-

dler that resides in a Servlet Container. A skeleton plays the same role for the servant

as the proxy plays for the client process. The skeleton unmarshalls the arguments in

the request message, invokes the corresponding method in the servant, waits for the

invocation to complete and then marshals the result in a reply message to the sending

proxy. A servant has one skeleton for each remote client.

The proxy and skeleton that we have described above are static (i.e., the remote in-

terfaces of the objects are known at compile time). Dynamic invocations are a further

possibility which is not considered in detail here, but form a straightforward extension

of this work.

Communication modules: The communication modules of the client and server

are responsible for carrying out the request-reply protocol by exchanging request and

reply messages over the network. They are typically implemented over TCP or UDP

sockets that give access to Internet standard protocols. Communication modules are

responsible for various protocol execution costs including data copying (between

protocol layers, buffers etc.) and packet initialization.

The role of communication module is played by different objects in different mid-

dleware products. In Java RMI it is the stub and skeleton; in CORBA it is the ORB

Core, and in SOAP it is the SOAP Transport module.

Dispatcher: The dispatcher is located at the server side and its role is to select the

right method in the appropriate skeleton. In SOAP the dispatcher lives in the servlet

container and extracts the name of the operation from Action header in the HTTP

request and invokes the corresponding method in the appropriate skeleton. The role of

dispatcher is played by Portable Object Adapter (POA) in CORBA. In Java RMI the

skeleton is overloaded with this role.

Optional roles.

There are many elective services, such as name service, security, transaction, per-

sistence services, that introduce additional, optional roles. Adopting these optional

roles changes the sequence diagram shown in Fig. 3. Three optional roles are de-

scribed below.

Name Service: Use of a naming service requires adding a Naming Service role to

the model. Use of a Name Service role adds several steps before the first doOperation

call shown in Fig. 3. The added steps are shown in Fig. 4.

Fig. 4. Typical Name Service interactions in a middleware

Service Manager: In some distributed component-based middleware (such as EJB)

the service manager takes over many responsibilities of the skeleton and facilitates

component-based modeling. The service manager offers a variety of services such as

management of transactions, security, concurrency, networking, resources, persis-

tence, messaging, deploy-time customization etc. A middleware product that employs

a service manager requires every request going from the skeleton to the servant to go

through the service manager (in EJB the bean acts as servant). The use of a service

manager adds a new role and lifeline ‘Service Manager’ between Skeleton and Serv-

ant of a typical remote method invocation. This modification is trivial and therefore is

not shown in a separate sequence diagram.

Security Service: Both the client and the server may optionally run security

mechanisms to protect the interacting processes, their communication channels and

the objects they encapsulate. To combat potential threats, the server and client may

adopt techniques such as encryption-decryption, certificates, access control, firewall

etc. In many cases, these operations are carried out by the stub and skeleton of the

middleware.

5 The base sub-model

The base middleware sub-model or simply the base sub-model is derived from the

mandatory roles described in the previous section. In the performance model each role

does not necessarily correspond to a separate LQN task. Rather, roles that closely

work together can be lumped together in a single task. This approach is also followed

in software development where more than one roles are occasionally implemented by

a single software component. The challenge is to find a level of granularity for the

tasks in the template so the model captures potential bottlenecks without creating too

many tasks.

A second motivation for using fewer tasks than roles is the ease of measurement

for calibrating the template demand parameters. In performance models we need ser-

vice demands of tasks and it is hard to get service demands for each of the processing

unit. Using few tasks facilitates the job of building performance models by requiring

less number of measurements. This approach is fine in terms of performance model-

ing as long as the grouping of computational modules do not drop out any bottleneck

unit.

Fig. 5. Base LQN template for middleware completion. Roles are preceded by bar (|) symbol.

The proposed base sub-model is shown in Fig. 5. It is derived from the sequence

diagram shown in Fig. 3. The tasks in the base sub-model introduce new aggregated

roles and we call them role-tasks. The role-tasks run on hosts we call role-hosts. We

also precede every role name in the base sub-model by single (|) or double (||) bars. A

role that is preceded by single bar means that this middleware role is yet to be bound

with some entity of the application model. This binding can take place either by add-

ing this role to the application model or its role could be merged with an existing

entity (e.g., host) in the application model. A double bar before a role name denotes

that binding is default. In other words, it is known who is going to take its role, the

modeler does not provide binding specification for it.

In Fig. 5, the role-task ||Client represents the client process, and it calls its local

stub. The roles ‘Stub’ and ‘Client Communication Module’ are lumped together to

form an LQN task named |ClientWrapper. The demand at the |ClientWrapper is com-

puted based on parameters for the message size ($msgSizeC), marshalling-

unmarshalling operation ($muC) and other operations ($otherOpC) (e.g., communica-

tion module related executions). The tasks ||Client and |ClientWrapper run on the host

||ClientH.

On arrival at the server’s communication module, a dispatcher selects the appropri-

ate skeleton which in turn calls the servant. The three roles related to message han-

dling (‘Server Communication Module’, ‘Dispatche’ and ‘Skeleto’) are grouped to-

gether in single role-task (|ServerWrapper) and the ||Servant is modeled as a separate

role-task. |ServerWrapper uses similar variables as |ClientWrapper to compute its

service demand. Both |ServerWrapper and ||Servant role-tasks are deployed to the

server host (||ServerH).

The base sub-model is made based on the mandatory roles described in 4. These man-

datory roles construct the essential parts of most middleware including RMI, CORBA

and SOAP. Therefore, the base sub-model models the basic version (i.e., the version

without any optional services) of these middleware products.

Architecture Modeling: Though the base sub-model has been described in terms of

different middleware roles, it can be used to model architectural styles without mid-

dleware, such as REST [25], which is currently a popular distributed communication

style. REST does not require marashalling/unmarshalling, instead it uses simple re-

quest-reply protocol over HTTP. Still, the transport layer protocol (e.g., TCP / UDP)

overheads of REST are modeled using the two wrappers at the two communicating

ends. In this way, the base sub-model is suitable to model REST.

6 Variability in the Base Sub-model

When an optional service is used, additional optional roles (described in Section 4)

are included in the middleware. To model them, new tasks need to be added to the

base sub-model or parameters of existing tasks need to be modified. This section de-

scribes feature models [26] to model these different choices.

6.1 Feature Models to Represent Variability

Optional services may be introduced either at the base sub-model itself (i.e., mid-

dleware-level services), or at any role of the sub-model (i.e., role-level services). It is

also possible that one service may contain more other services (i.e., nested services).

Figure 6(a) show a limited feature model for the base middleware sub-model. The

base middleware sub-model can be extended by adopting various services such as

NameService, LifeCycle Management, Service Manager etc. One of these services

may contain nested services. Nested services for Service Manager is shown in Figure

6(b). Figure 6(c) shows a feature model which shows the optional services that may

extend the |Wrapper (client or server) role-task of the base sub-model.

(a) Middleware Services (b) Service Manager Service (c) Wrapper Services

Fig. 6. Feature diagrams to represent variability of services

6.2 Library of Feature Realizations

Feature diagrams are abstract descriptions. In order to compose them to the base mid-

dleware template, the feature models need to be realized. Since our base middleware

template is modeled in LQN format, the realizations is also represented as an LQN.

When these realizations are composed to a base model, then some of them may only

require to modify the service demand of the role and other may require to add one or

more tasks (and corresponding hosts and calls) to the base model. The services that

require the first kind of realizations will be called demand-modifying services and the

latter kind of services will be called structure-modifying services. The remainder of

this subsection deals with structure-modifying services, as demand-modifying ser-

vices are comparatively easy to model.

Figure 12 and Figure 13 show the realizations of the features Naming Service and

Service Manager – both of which are structure-modifying services. The functionalities

of Naming Service and Service Manager were described in Section 4.1.2. The other

service (Security Service) described in that section is a demand-modifying service

which could be modeled using a mathematical formula.

Fig. 7. Feature realization template for Name Service

Fig. 8. Feature realization template for Service Manager

6.3 Obtaining Specialized Middleware Template

The new algorithm is presented below. Needs explanation.

READ required features in array featureList

FOR every feature feature in array featureList

IF feature is not a mathematical_formula

GET associated joint-calls array jointCallsList of

feature

FOR every joint-call jointCall in jointCallsList

REPLACE or ADD the call pointed by jointCall

with feature

BIND hosts of jointCall

UPDATE jointCall with newly associated en-

tries

ENDFOR

ELSE /* feature is a mathematical_formula */

UPDATE service demands of stub and/or skeleton

ENDIF

ENDFOR

6.4 Examples of Base Template Adaptation

This section discusses two cases of obtaining a context-specific middleware template

from the base middleware template. The first case composes a Naming Service to the

base template. The second case composes a Service Manager to the base template.

Composing Name Service: The Naming Service is an integral part of many mid-

dleware products. In Java RMI and CORBA the Naming Service is implemented us-

ing RMIRegistry and Interface Repository respectively. After applying Algorithm 1,

the context-specific middleware template shown in Error! Reference source not

found. is obtained.

Fig. 9. Name Service and Service Manager are separately composed to the base template

Composing Service Manager: Service Manager is a service that is found in compo-

nent based middleware such as EJB and was described in Section 4.1.2. In EJB, the

operations executed by |ServerWrapper is handled by EJBObject. Once a message

sent by the client arrives at the EJB server’s EJBObject, the role of ServiceManager is

invoked. The ServiceManager feature realization is described in Figure 13. When this

realization is composed to the base middleware template using Algorithm 1, we ob-

tain the context-specific middleware template shown in Figure 14.

7 Using the Proposed Modeling Approach

This section describes an example showing how the proposed approach can be used in

an application software model. The first software model that does not have any mid-

dleware in it, we call it the primary model. The model that we get as result of compo-

sition is called the ‘final’ model. Several alternative final models will be compared in

their capacity, response time and achieved throughput.

7.1 Primary Model

The primary model represents a 2-tier web application as shown in Figure 15. It has

three tasks allocated to three hosts. The initial request goes from User to WebServer

(3 requests within one response) and then from WebServer to DbServer (10 times for

each WebServer request). Each task is assigned to its own dedicated host. There are

$N clients and client hosts. The infinitely threaded tasks WebServer, and DbServer

(representing unlimited on-demand thread creation) are deployed respectively to hosts

WebServerH and DbServerH.

Fig. 10. Primary web application model

There are 5 instances of the WebServerH host and 10 instances of the DbServerH

host. For WebServer, the average message size ($msgSize1) is assumed to be 120

KB, the message processing host demand of webOp is 0.1 ms/KB, making the host

demand of webOp to be 12ms. For dbOp the average size of a message ($msgSize2)

is 80 KB, and the message processing time is again 0.1 ms/KB, giving a host demand

of 8 ms. User think time ($Zthinkt) is set to 3000 ms.

8 Composing specialized middleware with the primary model

The process for composing the context-specific middleware template with the primary

model is shown in Algorithm 2. This algorithm has a method named

ComposeMWTemplate. Apart from the obvious input of primary model, this method

takes two other maps as parameters. First, a map (mcs) that tells which context-

specific template to be composed to a call. Second, a map (mps) that maps context-

specific roles to primary model’s roles. These input parameters are used during the

binding process.

Algorithm 2 follows the same steps as compose method described in Algorithm 1.

At first the specific template’s hosts are bound to primary model’s host, then the cor-

responding requesters/repliers are bound, and finally the remaining nodes (i.e.,

submodel) of the specific template are bound to the primary model. Algorithm 2 has

fewer conditions than Algorithm 1 as there is always a replier for a call in the primary

model. It is to be noted that the actual names of the role instances are not used as in-

put parameters, rather the composing algorithm determines them. This implicit nam-

ing convention is chosen so that the algorithm requires fewer parameters from the

user.

Model ComposeMWTemplate(Model p,

Map<Call,ContextSpecificTemplate> mcs,

Map <Role,Role> mps){

for each call c in mcs

s := specified template of c

if s is not null then

for each host hs in s

Let pRole be mapping of hs.role in mps

if pRole is found in mps then

bind hs.role to pRole

else

create pRole for hs.role

bind hs.role to pRole

update mps

end if

end for

bind sRequester to pRequester

bind sReplier to pReplier

for each call c’ in sRequester’s outgoing calls

c’.nRequest := c’.nRequest * c.nRequest

end for

subs := s \ {sRequester,sReplier}

replace c with tasks and calls of subs

allocate each task of subs to its host in p

//use mps for this

end if

end for

return p

}

The algorithm above needs to be updated and described.

Fig. 11. The Primary web application model is composed with an EJB instance that uses Nam-

ing Service and Service Manager at two different layers

9 Experimental Results

To illustrate the capability of our middleware modeling approach, the primary model

of the 2-tier web application in Figure 15 is composed with various middleware

products to generate different ‘final’ models which are solved to show their effect on

performance.

First the primary model was solved without any middleware product. This ideal-

ized case ignores both the middleware overheads and the network latency. The second

final model (“Primary + Netw”) has no middleware overhead but only fixed network

latency. Then, four different middleware products (RMI, REST, EJB and SOAP) are

composed to the primary model to get four different final models. All these final

models were solved using the LQN solver, giving the results shown in Figures 17 and

18. The results are as expected.

From Figure 17 we can see that the primary model has the lowest system response

time. Adding network latency adds a fixed delay to the system response time until the

system is saturated at nearly 180 users (See Figure 18). RMI has a higher system re-

sponse time than “Primary + Netw” model due to marshalling/ unmarshalling over-

head and various other wrapper operations. REST response times are higher than

those of RMI due to REST’s larger message sizes. EJB system response time exceeds

those of REST and RMI, possibly because of the overheads caused due to the service

manager. Finally, SOAP has the highest response time as expected, due to its very

large XML messages.

Fig. 12. System Response Time [ms] for various middleware compositions

Fig. 13. System Throughput [jobs/sec] for various middleware compositions

If the required response time for the system is less than 3 seconds, then both the pri-

mary (which is the best case) and the “Primary + Netw” models can handle as many

as 250 users. RMI, REST and EJB can support 220,180 and 160 users respectively.

SOAP gives the worst performance comparing to the other middleware products, i.e.,

the system saturates only at 130 users, which is almost half the number of users sup-

ported by the primary model. These results are in accordance with the expected per-

formance behavior, i.e., higher the middleware overhead, the less number of users the

system can support to meet the required response time.

For all the final models, the bottleneck device was database server host. It has been

observed that for N > 180, all of the 10 instances of database server hosts are saturat-

ed for all the six final models. This behavior is anticipated due to the fact that every

request coming to the web server calls the database server for 10 times and thus over-

loading it with many requests. On the other hand, the web server hosts are under-

utilized. For N = 180 users, at most 2 of the 5 instances of web server hosts are used

for any middleware product.

10 Conclusion

This paper presents a systematic generative approach to model any old or new mid-

dleware product. The proposed approach starts from a base middleware template that

captures the mandatory roles that participate in all the middleware products. To de-

scribe and group the various service options of middleware products a feature dia-

gram is used. The features are realized by LQN templates that can be composed to the

base template to generate context-specific middleware templates. Finally, an algo-

rithm is proposed that composes the context-specific middleware templates to primary

application software model.

This paper has several contributions. First, it identifies the different mandatory and

optional roles available in various middleware products and groups them in feature

diagrams. Second, it describes a process to extend the power of Layered Queuing

Network so that underlying middleware platform can be systematically added to per-

formance models. Third, the proposed approach asks meaningful and high level in-

formation about the choices of middleware to the user related to the abstraction intro-

duced by the middleware templates.

We are currently implementing the proposed algorithm on the Eclipse platform to

automate the process of model composition. We are also in the process of integrating

a library of middleware templates with the Layered Queuing Network (LQN) frame-

work. This research can be extended in various other ways. Different kinds of services

can be realized and patterns can be found in those realizations so that two or more

services can be realized using same/similar model. Feature diagrams for a large num-

ber of optional services can also be developed to support large array of functionalities.

A study can be made on proper ordering of compositions of feature realization tem-

plates, as it has been done for reusable aspect models in [25].

Acknowledgement.

This research was funded by the NSERC Strategic Network SAVI (Smart Applica-

tions on Virtual Infrastructure), and by the NSERC Discovery Grant program.

11 References

1. M. Woodside, D.B. Petriu, K. H. Siddiqui, Performance-related Completions for Software

Specifications, In Proceedings of 24th Int. Conf. on Software Engineering (ICSE 2002),

Orlando. May 2002.

2. Juric, M. B., Rozman, I., Brumen, B., Colnaric, M. & Hericko, M. (2006). Comparison of

performance of Web services, WS-Security, RMI, and RMI-SSL.. Journal of Systems and

Software, 79, 689-700.

3. Juric, M. B., Rozman, I. & Hericko, M. (2000). Performance comparison of CORBA and

RMI..Information & Software Technology, 42, 915-933.

4. Gómez-Martínez, E. & Merseguer, J. (2006). Impact of SOAP Implementations in the Per-

formance of a Web Service-Based Application.. In G. Min, B. D. Martino, L. T. Yang, M.

Guo & G. Rünger (eds.),ISPA Workshops (p./pp. 884-896), : Springer. ISBN: 3-540-

49860-5

5. Xiuping Wu, "An Approach to Predicting Performance for Component-based Systems",

MASc thesis, July 2003.

6. Wu, X., Woodside, M., "Performance Modeling from Software Components," in Proc. 4th

Int. Workshop on Software and Performance (WOSP 04), Redwood Shores, Calif., Jan

2004, pp. 290-301.

7. Tom Verdickt, Performance Analysis of Distributed Systems Based on Architectural Sys-

tem Models, PhD Dissertation, Dept. of Information Technology, Universiteit Gent, Bel-

gium, 2007.

8. Verdickt, T., Dhoedt, B., Gielen, F. & Demeester, P. (2003). Modelling the performance of

CORBA using Layered Queueing Networks.. EUROMICRO (p./pp. 117-123), : IEEE

Computer Society. ISBN: 0-7695-1996-2

9. S. Becker, H. Koziolek, and R. Reussner. Model-based Performance Prediction with the

Palladio Component Model. In Proceedings of the 6th International Workshop on Soft-

ware and Performance (WOSP2007), pages 56–67. SIGSOFT Software Engineering

Notes, ACM, New York, NY, USA, Feb 2007.

10. Happe, J., Becker, S., Rathfelder, C., Friedrich, H. & Reussner, R. H. (2009). Parametric

Performance Completions for Model-Driven Performance Prediction. Performance Evalu-

ation,.

11. Becker, S. (2008). Coupled model transformations.. In A. Avritzer, E. J. Weyuker & C. M.

Woodside (eds.),WOSP (p./pp. 103-114), : ACM. ISBN: 978-1-59593-873-2.

12. Happe, J., Friedrich, H., Becker, S. & Reussner, R. H. (2008). A pattern-based perfor-

mance completion for Message-oriented Middleware.. In A. Avritzer, E. J. Weyuker & C.

M. Woodside (eds.), WOSP (p./pp. 165-176), : ACM. ISBN: 978-1-59593-873-2

13. Lucia Kapova. Configurable Software Performance Completions through Higher-Order

Model Transformations, PhD Thesis, Karlsruhe Institute of Technology (KIT), 2011.

14. Misha Strittmatter and Lucia Kapova Happe. Compositional performance abstractions of

software connectors. In Proceedings of the 3rd ACM/SPEC International Conference on

Performance Engineering (ICPE '12). ACM, New York, NY, USA, 275-278.

15. The Chilies project for automated model completions.

http://sdqweb.ipd.kit.edu/wiki/Chilies

16. Layered queuing network homepage http://www.sce.carleton.ca/rads/lqns/ last accessed:

1st May 2014

17. G.Franks, T. Al-Omari, C. M. Woodside, O. Das, S. Derisavi, Enhanced Modeling and So-

lution of Layered Queueing Networks, IEEE Trans. on Software Eng. Vol. 35, No. 2,

March/April, 2009

18. George Coulouris, Jean Dollimore, Tim Kindberg and Gordon Blair, Distributed Systems

Concepts and Design, Fifth Edition, Pearson Education Inc., 2012.

19. Message Passing Interface (MPI) standards documents and forum

http://www.mpi-forum.org/

20. Kim, D.-K., France, R. B., Ghosh, S. & Song, E. (2002). Using Role-Based Modeling

Language (RBML) to Characterize Model Families..ICECCS(p./pp. 107-116), : IEEE

Computer Society. ISBN: 0-7695-1757-9.

21. Java RMI Specification

http://docs.oracle.com/javase/7/docs/platform/rmi/spec/rmiTOC.html

22. OMG CORBA specification http://www.omg.org/spec/CORBA/

23. W3C SOAP specification http://www.w3.org/TR/soap/

24. Batory, D. Feature models, grammars, and propositional formulas. Proceedings of the 9th

international conference on Software Product Lines (p./pp. 7–20), Berlin and Heidelberg:

Springer-Verlag. (2005).

25. Fielding, Roy Thomas, Architectural Styles and the Design of Network-based Software Ar-

chitectures, Doctoral dissertation, University of California, Irvine, 2000.

26. Kienzle, J., Abed, W. A., Fleurey, F., Jézéquel, J.-M. & Klein, J. (2010). Aspect-Oriented

Design with Reusable Aspect Models. T. Aspect-Oriented Software Development, 7, 272-

320.