middleware modeling
Post on 04-Dec-2015
24 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related