Context: Modeling tools are traditionally delivered as monolithic desktop applications, optionally extended by plug-ins or special purpose central servers. This delivery model suffers from several drawbacks, ranging from poor scalability to di cult maintenance and the proliferation of \shelfware". Objective: In this paper we investigate the conceptual and technical feasibility of a new software architecture for modeling tools, where certain advanced features are factored out of the client and moved towards the Cloud. With this approach we plan to address the above mentioned drawbacks of existing modeling tools. Method: We base our approach on RESTful Web services. Using features implemented in the existing Model Analysis and Checking (MACH) tool, we create a RESTful Web service API o ering model analysis facilities. We refer to it as the Hypersonic API. We provide a proof of concept implementation for the Hypersonic API using model clone detection as our example case. We also implement a sample Web application as a client for these Web services. Results: Our initial experiments with Hypersonic demonstrate the viability of our approach. By applying standards such as REST and JSON in combination with Prolog as an implementation language, we are able to transform MACH from a command line tool into the rst Web-based model clone detection service with remarkably little e ort.
Until very recently, the only practically viable architecture
for modeling tools was the traditional rich client architecture
for desktop applications, sometimes complemented by
specialized central servers, e. g., to provide model versioning
and group collaboration capabilities. Such modeling tools
are large, monolithical applications, even though some do
o er scripting facilities, application programming interfaces
(APIs), or a plug-in mechanism to allow for a certain
degree of extensibility. A typical example is NoMagic's
MagicDraw [
Copyright c 2014 for the individual papers by the papers'
authors. Copying permitted for private and academic
purposes. This volume is published and copyrighted by its
editors.
complemented by the Teamwork Server plug-in [
In many other areas of computing, however, other, more
exible architectures are commonplace today. In
particular, recent technological developments have brought about
the widespread adoption of Cloud-based software
architectures. Typically, such architectures involve the deployment
of computationally intensive tasks to a centralized and fully
transparent shared pool of con gurable computing resources
(i. e., \the Cloud") [
To realize this potential, we propose a solution where the features required in a fully- edged modeling environment are hosted remotely and accessed in a transparent way. Playing the role of basic building blocks for a modeling work ow, these features should be accessible independently of each other and across a variety of devices. Fig. 1 visualizes the contrast between the widely used rich client architecture and the solution we propose. The crucial part of this proposal is the identi cation of features of a modeling environment that should be executed locally, and of those that should be executed on remote servers.
Arguably one of the most suitable application areas for
Cloud-based approaches in modeling is model analysis. We
select the requirements of this area as a background for
constructing Hypersonic, a test vehicle for demonstrating our
proposed approach for the delivery of modeling services - in
this case, model analysis services. To implement Hypersonic,
we use the features o ered by our existing model analysis
tool, MACH [
Client Provider 1 . . . Provider k . . .
Provider x
Provider y Provider 1
Provider 1 d n e g e L
Component suitable for deployment to remote server
Component suitable for deployment to local client come RESTful Web services. They can be accessed remotely from a wide range of clients, without requiring installation or explicit user actions for installing updates. To demonstrate the usefulness of our Web service API we also create a sample client in the form of a responsive Web application.
In this paper we discuss the application scenarios and business cases for Cloud-based modeling services, derive requirements and constraints for the associated tools (Chapter 2), propose a distributed architecture to satisfy these requirements (Chapter 3), and report on a proof-of-concept implementation (Chapter 4). We also provide an overview of related work (Chapter 5) and summarize the conclusions of our study (Chapter 6).
Moving modeling tools to the Cloud is not primarily motivated by technological reasons, but by new application scenarios and business cases. In this section we analyze these application scenarios and business cases to highlight the advantages of our proposed architecture. We start by describing the status-quo, considering the stakeholders \tool provider", \modeler", \IT administrator", and \MBSD community", where MBSD stands for Model Based Software Development. Observe that all of these stakeholders exist in similar ways both in academic and commercial settings. We argue that the current state of the MBSD tool landscape is unsatisfactory for the stakeholders in several ways.
To a modeler, tools come as xed packages: it is usually not possible (or not practical) to use one aspect, the editor, say, of one tool, and another aspect of a second tool. For instance, if the modeler appreciates the editing facilities of tool A, but that tool does not provide (adequate) code generation facilities, code generation may be di cult. It may not be economically viable due to the cost of purchasing two tools, or it may actually be impossible to use the editor of tool A combined with the code generator of another tool, unless both tools strictly adhere to model interchange standards. Also, from a modeler's perspective, resource intensive tasks may take an unreasonably long time to complete when executed locally.
To an IT administrator, repeatedly deploying tools to a large number of computers implies additional e ort. Even if this e ort is not incurred by the actual deployment (that might be expected to be taken care of by the modelers themselves), it becomes inevitable when distributing updates and xes, help-desk services, and possibly ensuring that the tool's license usage is compliant with the agreement entered in with the tool vendor.
To the tool provider, delivering a modeling solution as a self-contained product with all the business logic on the client side makes it di cult to support the wide array of emerging computing devices. Migrating a large modeling tool to a tablet, smartphone, or Web interface would likely require extensive re-implementation, not to mention that the hardware requirements of many modeling tools are still prohibitive for mobile devices. Furthermore, separating the highly critical (and sometimes highly innovative) and noncritical functionalities of the application is cumbersome, yet still achievable through plug-ins. The distribution of counterfeit copies of the tool is also di cult to mitigate.
To the MBSD community, all of these factors are limiting, in much the same way as super cial di erences between preUML modeling languages created niche markets for many di erent tools that were more expensive and less powerful than the UML tools that emerged after the uni cation of mainstream modeling languages in the late 1990's.
In a nutshell, the existing situation is suboptimal. Thus, we propose a di erent architecture: compute-intensive features and features with a high degree of innovation should be deployed to and executed in the Cloud rather than on the client machine. The client and server in this architecture are coupled loosely, by Web services, so that providing a new feature amounts to providing a new Web service. Such features can include advanced model analysis tools, code and report generation, and model transformation. Conversely, features of smaller distinctive value and small change rates, as well as features that require a higher degree of interactivity, can continue to be implemented as part of the client application. This will likely be the case for pure editing features, which many commercial vendors already o er as free community editions of their tools.
We have hinted at a set of criteria for determining which features of a modeling tool should be executed locally, and which would bene t from being migrated to the Cloud. Table 1 summarizes these criteria and presents examples. 2.2
Several advantages can be achieved by breaking up today's monolithic modeling tools into one stable, remote part that provides little added value distinguishing products (e. g., the editor), and a second, centralized part that comprises more advanced features with a higher change rate and higher distinctive value.
First, there are the advantages associated with thin-client systems in general: maintaining one central server instead of many remote clients reduces the work e ort for IT administrators and ensures that modelers always have access to the latest version of the modeling tool. It also becomes easier to monitor license usage, which bene ts administrators and tool providers alike.
Second, there are advantages rooted in the speci c properties of Cloud-based solutions. This includes the availability high interactivity & incidence high degree of stability exchangeable features editing simple syntax checking automatic layout context speci c help di erence visualization querying and navigation Cloud-based Features high resource consumption high degree of innovation unique features reporting global consistency checking advanced model analysis check in/out, locking di erence computation code generation of considerable computational resources to each individual user at reduced overall cost, as well as high scalability of the available resources with an increasing number of users.
Third, a scenario in which some modeling facilities are
provided as services is conductive to model interchange
standards conformance. In such a scenario, service providers
and client tool providers must both conform to model
interchange standards such as the XML Metadata Interchange
(XMI, [
Fourth, there are advantages brought about by changes in the business model and enabling market mechanisms. Today, the modeling tool market is dominated by companies providing feature-complete bundles. A new competitor can only enter the market by providing a feature-complete solution, which all but excludes small companies and academic tool providers. Innovative analysis methods, specialized code generators, and similar tools can only be provided as plug-ins to one of the existing platforms, sometimes depending on the approval of the platform owner. In contrast, with a service-based architecture, tool providers can enter the market at lower cost, since they only have to provide their contribution per se, not a feature complete-tool. They can also address a larger part of the market, as they provide a generic Web service rather than a platform speci c plugin that applies to only one modeling tool. Modelers, on the other hand, can mix and match services as they like within the limits of standardized exchange formats.
It is likely that the described change in dynamics of the modeling tools market will inspire an increase in competitiveness between existing tool providers, while at the same time providing an incentive for new providers to enter the market. Both these developments will likely lead to a higher degree of innovation. This could translate into new concepts from academia dissipating to industrial modeling at a faster pace. Users will thus have both a nancial and a technical incentive to experiment with new features.
From a nancial perspective, tool providers will be able to bill features separately as subscription Web services. This could reduce unit prices for customers, who only buy the features they need, and may subscribe to services as they need them. Spending on expensive \shelfware" can be reduced or avoided altogether. For the supplier, this opens the perspective of a new business model in which a steady stream of revenue is generated through subscription services, while features of high distinctive value are much better protected against counterfeiting.
It must be mentioned, though, that adopting a servicebased approach to modeling entails some trade-o s. Most are caused by the distributed nature of the approach. For instance, the process of uploading large models to a Cloudbased service may constitute a performance bottleneck. Security and privacy are also new aspects that come into play, considering that a centralized warehouse will store models owned by di erent organizations. These organisations must be able to trust that not only will their models not be accessible to other users, but they will also be protected against unauthorised mining by the modeling service provider. And, perhaps most importantly, the usefulness of the solution is dependent on a working Internet connection. Nevertheless, these drawbacks are common to the majority of Software as a Service (SaaS) solutions, and have not undermined this architecture style's acceptance. 2.3
In Section 2.1 we have discussed which types of features lend themselves to deployment as Web services. We now select one feature, clone detection, as a test case for exploring the proposed architecture (i. e., the Hypersonic API). Our selection is motivated by the following considerations.
The feature is well researched, published, and
implemented (see [
It is a unique feature: no UML modeling tool currently o ers a clone detection feature. This includes research prototypes other than our own MACH tool. It is therefore safe to assert that this feature provides a high degree of innovation.
A rst step towards the realization of the ideas presented in Section 2 is the de nition of a common Web service interface accepted by all stakeholders. The details of such an interface must be the result of a wide reaching discussion, which is beyond the scope of this paper. Instead, we take an exploratory approach and design a RESTful Web service API for the purpose of Cloud-based model analysis. We refer to this API as the Hypersonic API. By doing so, we study the requirements and potential setbacks of processing models via RESTful Web services.
In keeping with the REST architectural style [
This architectural approach allows physically decoupling clients from the execution of the various analysis algorithms exposed by the Hypersonic API. This aspect is part of the motivation behind the creation of Hypersonic, since many of these algorithms are resource demanding on models of non-trivial size. By using such a Web service API, a large variety of clients can have access to model analysis facilities regardless of their hardware capabilities. Fig. 2 highlights this aspect, showing that di erent clients can access existing analysis algorithms provided by the MACH tool via the Hypersonic API wrapper. The only prerequisites for API clients are HTTP support, the ability to process documents returned by the API, and, optionally, a model viewer. Note that all of these prerequisites are entirely reasonable for modern mobile devices.
HTTP HTTP
Additional non-functional considerations must be taken
into account to ensure the practicality of the Web service
API. Since using the API implies uploading entire models
to a remote server, security becomes an important factor.
With this in mind, the OAuth [
From a le format standpoint, Hypersonic currently
supports models stored in the MDXML format, the XMI-based
native format of the MagicDraw modeling tool. That is to
say, some API requests (e. g., POST requests to the
models resource) are expected to have an MDXML document as
payload. Most API response messages carry a JSON [
The internal components involved in answering a call to
the Hypersonic API are presented in Fig. 3. The
RESTful API component handles HTTP communication with
remote API clients and delegates all actual model processing
to the MACH component. It also forwards all models sent
by clients to the XMI2PL component, which performs a
format translation from the MDXML format to the internal
Prolog-based le format described in [
The SWI-Prolog runtime should be deployed to either a public or private Cloud platform. Since all models are stored separately in a model warehouse, several instances of the SWI-Prolog runtime can be deployed, assuming that the model warehouse provides appropriate concurrent access policies. Persistent model storage can be provided by a separate Cloud storage service. Since models are stored as XML and Prolog les, the storage service should support a document-oriented database management system. 4.
To demonstrate the feasibility of the architecture described in Section 3, a subset of the proposed Web service API has been implemented and is publicly accessible1. Due to the reasons elaborated on in Section 2.3, we have focused on a Web service providing model clone detection as a minimum useful scenario. Though important for a nal release, we have considered features such as user accounts and authentication beyond the scope of our proof of concept. Both the prototype API and the model warehouse are currently hosted on a dedicated server. They do not bene t from the scalability of a true Cloud deployment, although for the current proof of concept this is hardly a limiting factor. 1The Hypersonic API is available at the following base URL: http://hypersonic.compute.dtu.dk Resource /models /models /model/<id> /model/<id> /model/<id> /model/<id>/clones /model/<id1>/di /<id2> /model/<id>/dump /model/<id>/dump/<me id> /model/<id>/ nd/<string> /model/<id>/frequency /model/<id1>/similarity/<id2> /model/<id>/size GET POST GET PUT DELETE GET GET GET GET GET GET GET GET
MDXML
| | | | | JSON
quency distribution in a model.
two models. Options are specied in the request payload.
Method Fig. 4 represents a message exchange between a client and the Hypersonic API. The purpose of this exchange is to perform clone detection on a model. First, the model is added to the Hypersonic model warehouse by a POST request to the models resource. Upon this request's successful handling, a new model resource representing the model is available to the client. The resource has a unique identi er returned in the JSON response document of the initial POST request. The client then parses this document and extracts the identi er. Thus, the client is subsequently able to use the identi er to construct the appropriate URL for a GET request to the clones operation of the identi ed model resource. The GET request returns a list of clone candidates, also in the form of a JSON document (see Listing 1).
The response document includes a model identi er, the
number of detected clones, and a list of discovered clone
candidates. Each clone candidate is described by two model
elements, where one is a possible clone of the other, a numeric
similarity metric computed for the two elements following
the approach presented in [
Listing 1: JSON clone detection report f "model ": "1 " , " c a n d i d a t e s ": 2 , " c l o n e s ": [ f " t y p e 1 ": "package " , " i d 1 ": 2 9 , "name 1 ": "R e s e r v e Medium " , " t y p e 2 ": "package " , " i d 2 ": 9 3 8 , "name 2 ": "R e s e r v e Medium " , g " t y p e 1 ": "package " , " i d 1 ": 1 8 9 , "name 1 ": "Lend Medium " , " t y p e 2 ": "package " , " i d 2 ": 1 1 9 4 , "name 2 ": "Lend Medium " , " s i m i l a r i t y ": 1 2 8 . 7 2 8 7 , "k i n d ": " n a t u r a l c l o n e " ,
By conforming to the architecture presented in Fig. 3, the e ort required to implement the clone detection proof of concept has been minimal. The RESTful API functioning as a wrapper around MACH's existing clone detection implementation consists of around 100 lines of Prolog code, largely thanks to the comprehensive support o ered by SWIProlog for the HTTP protocol. Work on implementing the remaining API calls described in Table 2 is ongoing, as is work on the API management application that must be in place in order to to enable user authentication in API calls.
As a preliminary validation of the API's tness for purpose, we have created a simple, mobile device friendly Web application as an API client2. The application supports selecting a local model le, uploading it to the Hypersonic model warehouse, and requesting a clone report which it subsequently displays in tabular form. The application is written in JavaScript and is executed entirely in the browser (i. e., it does not rely on a server-side script for calling API operations). Though it is so far basic in terms of functionality, this sample client exempli es our vision of Web service driven modeling tools: using Web 2.0 technologies (REST, JavaScript, JSON) to enable advanced model analysis outside the constraints of the desktop and of traditional modeling environments. 5.
Model analysis is an activity typically performed in local,
non-distributed environments. As an example, the model
clone detection operation considered here as a proof of
concept has scarcely been addressed in itself, but is closely
related to the intensely studied model matching and di
erencing operations. To name just a few proposals in this area,
SiDi [
With the increase in size of industrially relevant models
and the increase in complexity of the operations performed
on these models, the need for distributed, Cloud-enabled
modeling solutions has become apparent [
More advanced activities such as model querying and
transformation have also been addressed. IncQuery-D [
However, performance gains due to Cloud deployment are
only a part of the overall vision of Hypersonic. Rather than
focusing on the bene ts to the application itself (i. e., model
analysis), Hypersonic emphasises the bene ts brought by a
Cloud-based approach to the interface and availability of
this application. The idea of performing model analysis via
a RESTful Web service API has yet to receive signi cant
attention in the literature. The closest related proposal is
the EMF-REST project [
In this paper we have discussed the application conditions, bene ts, and general business case for Cloud-based modeling tools. In particular, we have presented a scenario in which modeling capabilities are delivered as Web services to a wide array of clients, ranging from desktop applications to Web and mobile applications. We have contrasted this scenario with the current status-quo of rich client desktop modeling tools, reaching the conclusion that, in many respects, the Cloud-based approach is superior.
To explore our proposal, we have introduced Hypersonic, a RESTful Web service API aimed at o ering high-throughput processing for Cloud-based model analysis. We have implemented this architecture and made it available online. Currently, the only service it o ers is the detection of model clones, a feature that was previously only available in the MACH command line tool. Today, MACH is a stand-alone desktop tool providing only a textual user interface. Through the Hypersonic API, the features of MACH can be made available over the Internet to any API client. As a proof of concept for the utility of the API, we have developed a Web application acting as a client to the Hypersonic API and providing Web-based model analysis capabilities. 6.2
The concepts presented in this paper o er us ample
opportunities for future work. As a rst step, we will continue the
development of the Hypersonic API with the aim of
reaching functional parity with the MACH model analysis tool.
Once this has been achieved, the API will be deployed to
a Cloud platform. In parallel, we will update the sample
Web-based API client to both validate and showcase the
model analysis features of Hypersonic. Second, in order to
become a practical tool, the API client must o er several
critical features such as user authentication and model
security mechanisms. Third, we will carry out a systematic
performance evaluation of MACH in order to substantiate
the claim that Cloud-based model analysis can bring
significant performance bene ts. Finally, we intend to develop a
second client for the Hypersonic API in the shape of a
plugin for MagicDraw. This will permit seamless integration of
our Web services approach with a commercial modeling tool
and complement our existing model querying MagicDraw
plug-in, MQ-2 [