International Journal of Advanced Computer Science, Vol. 3, No. 2, Pp. 80-89, Feb., 2013.

A Multi-Model Based Component Architecture for Virtual Organizations

Christian Kreiner
1

Manuscript
Received: 16,Nov., 2012 Revised: 11,Dec., 2012 Accepted: 20,Dec., 2012 Published: 15, Jan., 2013

Keywords
Virtual Organization, Runtime model execution, MultiModeling, Component based development,

Abstract Raising the level of abstraction is an important research topic in the context of software for mobile and embedded devices. Model Driven Software Development techniques have been recognized for their ability to provide this abstraction by separating domain specific aspects from their technical implementation. Traditionally, such approaches rely on static code generation, which does not fit well in an evolving, collaborating system managed by multiple participating organizations. In order to support such dynamically (re-)configuring Virtual Organizations with high, domain specific abstraction levels, the presented approach is based on loosely coupled, run-time executed Model Based Software Components (MBSC). An MBSC is defined and implemented by potentially multiple distinct models covering all necessary domain-specific aspects (e.g. behavior, data) of the component. MBSCs are deployed to a distributed runtime architecture, where they reside in model-based component containers. System evolution during operation is supported by these plugin-extensible containers, which support additional kinds of MBSC models. A scenario for a building access system that consists of MBSCs owned by independent, yet cooperating organizations (facility management, security, departments), is analyzed in this paper. Finally, several system evolution use cases are discussed.

1. Introduction
Liggesmeyer and Trapp [1] noted that raising the level of abstraction in the development of embedded software is a major challenge tackled by current approaches proposed in this area. On one hand this task is solved by the application of higher level programming languages, but on the other hand this requirement is also tackled by the usage of software models, that are specified at design time and traditionally applied at system development time as input to code generators and model testing tools. Besides the ease of programming such systems, configuration of software systems at runtime has also been

noted as a major area of research. Fischer et al. [2] describe different roles in the reconfiguration of software ranging from pure software users over people applying Domain Specific Languages (DSL) to macros for programming professionals. While specification of DSLs using metamodels is becoming state of the art, the usage of software development models at runtime has also been described to enable evolvable systems (Blair et al. [3]). To support different domain experts working on one software project, Hessellund has proposed the usage of different models for one application with each one defining a specific domain of the software [4]. Considering the raising importance of mobile and embedded devices as noted by Roy Want in the case of smartphones [5] as well as by Ebert and Jones with respect to embedded software [6], this paper gives an overview of different aspects related to the application of a runtime environment for Model-Based Software Components. This component type is made up of different models, containing the domain specific functionality in a platform independent way. The models are interpreted at runtime by metamodel configured component containers that are part of the proposed runtime environment. These component containers are also used to provide shared usage of resources. Together with the runtime they enable the formation of a so called virtual organization out of the different owners of the executed Model-Based Software Components. To demonstrate the ability of this approach, the results of a case study targeting the implementation of a building access control system with the proposed methods are discussed in this paper. This case study proved the applicability of this concept for the construction of collaboration systems consisting of several independent organizations, which are using mobile and embedded devices in their business use cases.

2. Related work
Approaches in Model Driven Software Development (MDSD) follow the four-level metamodel hierarchy proposed by the Object Management Group (OMG). In this layered approach each level (named M3 to M0) defines the valid model elements of the next lower layer. MDSD techniques are also used in Component Based Software Engineering (CBSE) approaches enabling the composition and independent deployment of units with contractually specified interfaces and explicit context dependencies only as noted by Szyperski [7]. In traditional CBSE approaches like SOFA, Fractal or

Christian Kreiner, Graz University of Technology, Institute for Technical Informatics, Austria (Christian.kreiner@tugr az. at)
a a

Christian Kreiner: A Multi-Model Based Component Architecture for Virtual Organizations.

81

OpenCOM software models are used for the definition of component interfaces and assemblies and are applied by generators to produce the component platform specific artifacts and the required tooling support at system development time [8]. Domain specific support in these frameworks is provided by the use of feature models used for generating specific parts of the component platform at system development time based on the selected application domain [9]. Additionally, customized component models are available for specific domains like behavioral modeling [10] or distributed computing [11]. In contrast, the usage of models at system runtime has been proposed by Blair et al. [3], stating that a model@run.time is a causally connected self-representation of the associated system that emphasizes the structure, behavior, or goals of the system from a problem space perspective. Because a model typically facilitates some form of abstraction for a specific domain, applying models at runtime demands the combination of multiple models providing different domain specific views on the executed application as depicted in Fig. 1. This figure is adapted from a proposal by Lochmann and Hessellund [12] to use several DSLs in the context of Domain-Specific Multimodeling [4]. While in the original proposal each domain is represented by one specific language, an approach for applying several models at runtime should respect the usage of several languages within a given domain. As an example, Fig. 1 depicts several languages in the domain of behavior modeling (e.g. petri nets, state charts and decision tables) as noted by Jorgensen [13]. Because the usage of models supports the creation of platform independent software artifacts it also enables the realization of distributed business processes. Such processes are typically executed within a Virtual Organization (VO), which is an organizational concept proposed in the context of Grid Computing to support a dynamic group of users with a common goal coming together for a specific and short-lived collaborative venture [14]. Late binding of the specified component is reflecting the demands required by emerging Grid approaches [15].

3. Architecture for multi-model based distributed VOs

Today real-world applications run on multiple platforms (hardware, OS, database, middleware, component technology, etc.), consist of loosely coupled components (as discussed in the context of Service Oriented Architectures) that are developed and maintained by different organizations i.e. even the development processes are loosely coupled. As noted by Fischer et al. [2] current software products are created for increased flexibility by customization through the user. This user can be a real end user as well as software professional and can apply techniques such as macro programming or domain specific modeling to customize or configure the software. All provisioning, development and functionality services are governed by contractual agreements (see Fig. 2). This seems to be analogous to the ever changing structure within the 3-layer RFID data lineage model in the case study reported in [16].

Fig. 2 Simplified layer model for VO scenarios

Fig. 3 Model-based Component Container (MCC) and its proxy

In order to enable dynamic evolution of VOs we identified the following principal technical requirements for a supporting architecture: 1) Technically liberate structural and evolutionary moves in each of the three layers: IT infrastructure/ technology, software/middleware, and application from the other layers; e.g. by providing platform abstractions and using run-time binding and migration. 2) Separate concerns and cycles of management, component, and service evolution of the parties involved. As a consequence, every party has a clearly defined
International Journal Publishers Group (IJPG)

Fig. 1 Views in Domain Specific Multimodeling (adapted from [12])

82

International Journal of Advanced Computer Science, Vol. 3, No. 2, Pp. 80-89, Feb., 2013.

responsibility role for each components evolution and can use run-time binding and re-binding. The main parts of architecture to support these requirements are discussed in the next sections. A. Model-based software components Model-based software components (MBSC) are applied to define domain specific functions within a clearly defined component. MBSCs conceptually can contain models of multiple kinds of modeling languages chosen to suit the needs of the application (problem) domain. Provided and required component interfaces are specified using such models as well (think of a kind of model subset), which is expressed in the concept of model-typed component interfaces. In this concept both roles with potentially different owners behind have their own interface perception, i.e. are the owner of their interface models. In this way, MBSC internal contents are self-contained in term of ownership and integrity. Because of the weaker type safety induced by the model compatibility rules for connecting model defined interfaces, asynchronous MBSC evolution in separated administrative domains is supported, at the cost of necessary checks at runtime. In practice the usage of models for interface definitions limits that multi-modeling diversity. The modeling set will typically contain general purpose model paradigms like class models, finite state machine models, user interface descriptions, etc. (see example scenario in Sect. 4). A very limited number of domain specific modeling approaches might complement them. B. Model-based component containers Model-Based Component Containers (MCC) are the runtime environment of an MBSC. The MCC architecture is an extension of the EntityContainer approach, which has been proposed for the interpretation of data models at runtime [17]. The stacked data stores of an MCC are depicted in Fig. 3 and 4, where each one manages one layer of the four-level metamodel hierarchy. The topmost model (M3) is constant, defined as part of the architecture, and is used for generic encoding of all kinds of models in this architecture. The model M2 is also static and defines the view to be used by the entities. Their correctness is ensured by M2 specific validators used in the MCC. Optionally, the MCC model content at M0 and M1 can be interpreted by a controller realizing the domain specific concepts defined by the governing M2 model. MCCs support transactional updates with a 2-phase commit cycle, thus avoiding (temporarily) inconsistent system states during updates in several possibly remote MCCs due to a state changing transaction. Remote MCCs are locally represented by MCC proxies (see Fig. 3). These provide local interfaces to MCCs executing in another virtual organization node (discussed in the next section) implementing an MBSCs receptacle. An MCC proxy gets connected to a target MCC by configuring it with the latters uniform resource name. Both make use of

the constant M3 model for generic validation and encoding purposes. In contrast to Hessellund, who proposes separated metamodels for each domain and a reference mechanism based on string identifiers, the MBSC runtime environment is made up of a dynamically assembled metamodel consisting of the domain specific metamodels used by the executed component reflected by the loaded plugins. A domain specific language, the Entity Container Query Language (ECQL, [18]) is used to communicate between several MCCs. ECQL is further described in Sect. 4.

Fig. 4 Entity Container Architecture [17] used inside MCC

C. Model-based VO runtime environment The proposed runtime environment is used for the realization of VOs. Based on the assumption, that each part of the architecture (i.e. application components, runtime containers, resource nodes and resources) has a clearly defined owner that does not change at runtime, model-based applications are defined as an assembly of several MBSCs. These MBSCs can belong to different owners, who have the rights to manage the life cycle, development and evolution of their MBSCs thus also changing the access rights of the application and the corresponding business model. As a consequence the deployment of the MBSC defined application manifests a VO made up by 1 owners bound by a virtual organization (collaboration) contract. The runtime architecture is depicted in Fig. 5 and is made up of the following parts:

Fig. 5 Anatomy of the VO runtime architecture

International Journal Publishers Group (IJPG)

Christian Kreiner: A Multi-Model Based Component Architecture for Virtual Organizations.

83

1) Local resources are directly connected I/O resources, which are not part of this architecture like user interface hardware, sensors, auto-id devices (RFID readers), and local computing resources. Each resource is represented by one or more resource allocation rights (e.g. create/destroy actions), that can be granted to a certain MBSC and its owner in turn. 2) Resource Nodes (RN) are executed on a local machine, containing a device node controller. This controller features an MCC, which is configured with a metamodel as depicted in Fig. 6 for managing the resource access and the 3) VO runtime nodes (VON) executed inside an RN. Each VON can host MCCs to accommodate and execute MBSCs of one tenant owner only. Note that the owner of the VON itself who has created it can be different from the content owner. The isolation of the tenants realm of control from other owners in the system is ensured by this fact. Also a VON features a controller, managing its configuration via a specific MCC, to create MCCs and MCC proxies required by the residing MBSCs. Node identification is accomplished through a uniform resource name (URN), which is used for identification of resources. In this way a distinct MCC can be addressed by the assignment of a VO identifier, the RN name, the VON name and the name of the MCC within the MBSC (e.g. urn:vo:customer1:runtimeNode2:dataContainer1). These URNs are used in the corresponding ECQL statements to formulate the queries, which are executed by the MCCs running inside the corresponding VONs and RNs, which altogether form a distributed system.

The next use case enabled by the runtime architecture is the migration of VONs. This might become necessary during adaptations of the distributed system at runtime. A new VON gets created for the same tenant on another RN, and the contents of all MCCs are transferred. The new MCCs are registered for name resolution (in the RN!) within the tenants name space. Having finished, all facets in the migrated VON interfaces will resolve to the new RN location, as well as all component receptacles using an MBSC within migrated VON. As the VO made up by the corresponding model-based application is consisting of different owners, another use case is defined by the steps required to shut down a VON. These use case can also be applied by the owner of a rented VON, if the tenant does not satisfy the terms of conditions anymore. In case of a required RN shutdown, each VON is informed to start the migration to another RN belonging to the corresponding VO.

Fig. 7 Example contents of an MCC named DataContainer

4. Entity-Container Query Language (ECQL)

The Entity Container Query Language (ECQL) has been proposed [18] for the communication between several MCCs. It allows specifying queries and manipulation statements on the content of an MCC. ECQL facilitates basic operations on standard data types (strings, numbers, etc.), provides abilities to access and modify data in MCCs and enables the representation of relationships between several data entities like navigating over association connections in a class diagram. A. ECQL Language Elements Several data types are supported by ECQL. Beside the types Bool, Number, String and void a Set type is an important feature of ECQL for enabling various use cases (like applying operations on a number of entities in an MCC simultaneously (i.e. in one ECQL statement). Retrieving a set of entities is done with the help of filters or by applying the SETREF statement. Note that all exemplary statements are applied to an MCC containing models and data as depicted in Fig. 7. In the following, ECQL features will be characterized. 1) Filter functions. While a VALUE_FILTER simply returns a set of entities containing values that fulfil the filter criteria, the ASSOCIATION_FILTER statement facilitates relationships between several entities, providing the ability to navigate
International Journal Publishers Group (IJPG)

Fig. 6 Metamodel used by device controller MCC

D. Identified VO use cases Several use cases with respect to the adaptation of the distributed system at runtime were identified and are supported by the architecture. The basic use cases are the creation of new/initial VONs and the execution of the MBSC application by the different MCCs running inside these VONs. Another important aspect of the proposed approach is the value-added reseller (VAR) use-case. A customer can act as a VAR, if he possesses a VON (created by the operator) and has the rights to create additional VONs in the same resource node. Given these rights, he can create new VONs for his customers in turn within one of his application MBSCs running in his own VON.

84

International Journal of Advanced Computer Science, Vol. 3, No. 2, Pp. 80-89, Feb., 2013.

across associations in a class diagram. As visible from the class representing this statement in the metamodel (Fig. 8), two sets of entities are required as parameters as well as a string identifying one associations name in the entities of the first set. SETREF(Entity(DataContainer,M0, Datastructure, * ) ) , SETREF(Entity(DataContainer,M0, DataStructureElement, Item )) , structure);
Listing 1. Using the Association Filter

INSERT ( Entity ( DataContainer , M0, DataStructureElement , Item ) , Attribute ( valueEntry, length) , 2 ) ;

Listing 3. Data Manipulation with ECQL

Again, the entity resides in the layer M0 of the MCC named DataContainer.

Listing 1 expresses the query every DataStructure which contains a mapping for a DataStructureElement with the ID Item. The starting set is a list of all entities, which are an instance of the type DataStructure and are contained in an MCC named DataContainer (Fig. 7). This set is filtered by looking up each associated entity for the association structure. Only if the associated entity is of the type DataStructureElement and named Item, the currently observed entity is part of the first set in the result. Considering the possibility of filtering sets of entities before applying the ASSOCIATION_FILTER function, the support of complex, composed queries becomes apparent. Since all filters evaluate to a set of entities, filter nesting is also possible.
2) Reference functions. Reference functions are required to express data access during runtime interpretation. To achieve a non-ambiguous naming convention, every data is referred by its fully qualified name in the VO resource node. While Listing 1 demonstrated the retrieval of an entity set, Listing 2 instructs the runtime environment to access a number value named valueEntry.baseOffset in entity A which is of type DataStructure. The entity is looked up at the data layer (M0) of MCC DataContainer. NUMBERREF( Entity(DataContainer ,M0, DataStructure ,A) , Attribute (valueEntry , baseOffset ) ) ;

Fig. 8 ECQL metamodel (simplified)

B. Statement signatures Each ECQL statement has a well-defined signature which facilitates type safety checks for any ECQL statement inserted into an MCC. Bool SMALLER THAN(Number first, Number second) Bool BOOLREF (Entity entity, Attribute attribute) Set INTERSECTION( Set first , Set second )
Listing 4. ECQL Signatures

Listing 4 gives an example of some signatures derived from the metamodel depicted in Fig. 8. Metamodel elements in the first stage of the inheritance tree are defining the return type while inherited elements specify the name of the statement as well as the number of parameters. C. Platform extension with ECQL Fig. 9 gives an overview about the relevant models and the operations applied on the MCC in the concept of ECQL. At creation of an MCC the corresponding M2 model is loaded and is treated as static during runtime (c.f. Fig. 3). For effective use of ECQL statements inside an MCC (e.g. as state chart actions, for data binding purposes) the M2 model of the MCC has to be extended with the ECQL metamodel.

Listing 2. Reference Functions in ECQL

Type safety checks for references can only be executed at runtime (interpretation time) since data referred to is not necessarily available at insertion time of the ECQL statement. 3) MCC manipulation. Quite a similar syntax is used to express MCC data manipulation operations (for various layers) in ECQL. The statement shown in Listing 3 instructs the runtime environment to insert a new number value entry equivalent to attributes in the UML named length into entity Item of type DataStructureElement.

Fig. 9 Extension of ECQL at runtime

Such an extended metamodel enables a full validation of loaded M1 models with embedded ECQL statements also. Extension of the metamodel is done with a Transient Model Extension (TME) [19], allowing the insertion of new model
International Journal Publishers Group (IJPG)

Christian Kreiner: A Multi-Model Based Component Architecture for Virtual Organizations.

85

elements and the connection of existing model elements based on the rules provided in the next upper layer (in this case the M3 layer). A second extension in the M2 layer is performed during the instantiation of a MCC, allowing to support assigned resources to a VON (e.g. reading RFID tags, using hardwares integrated speaker) with additional ECQL statements. Using this approach enables model based checking of resource constraints at runtime by the MCC, leading to an abortion of the loading procedure in case the MCC respectively the VON have not been assigned the required resources. INSERT ( Entity ( DataContainer , M0, RawData , getTimestamp ( ) ) , Attribute ( valueEntry , data ) , getRfidCode ( ) ) ;
Listing 5. Using Platform Defined ECQL Statements

authentication strategies, and a security service company. A. Hardware nodes In this scenario, two devices are deployed, holding MBSCs from four organizations. An overview can be seen in Fig. 10 which also includes the arrangement of the organizations components on the actual hardware nodes. The main part of the hardware is an RFID reader mounted at the buildings door (named resource node zero (RN0) in the whole scenario). Its locally connected resources allow RFID tags to be read, and also control the doors electrical locking mechanism which enables the RFID reader to trigger the events open, close and lock. Furthermore it may feature a built-in buzzer and a number of visual indicators for the state of the door (open, closed or locked). All this hardware can be controlled by the hosted MBSCs. The second device shall be a mobile PDA owned by the security service that allows the guard to remotely trigger door events and to be notified whenever a person enters the building which can also be used for logging facilities. This PDA is referred to as RN1. B. Organizations In this scenario, four organizations are involved: Facility Management owns the actual hardware and is responsible for the buildings. It also provides the infrastructure necessary to create virtual organizations. Security service: hired for security reasons, which is common in companies nowadays. Departments are two organizations whose offices are located inside the building. Due to data privacy reasons they are the only participants having access to the employees personal data as well as the information whether a person is allowed to enter the building or not. Each of the organizations has well-defined interests and responsibilities. This directly leads to the definition of a data model and a state machine implementing the organizations tasks. They are depicted in reasonable detail for every organization in the following sections.

Listing 5 demonstrates this feature by presenting a statement to add a new entity of type RawData to the MCC DataContainer. This MCC is contained in a VON running on an RFID reader acting as the RN. The owner of this RN has granted the right of using the data of the currently read tag to the MBSC being executed in the VON. This right is represented by the ECQL statement getRfidCode(), which is added to the ECQL metamodel of the VON and thus to the M2 layer of all MCCs in this VON. In the same way an ECQL statement for requesting a timestamp from the RN is added to the container, and is used for determining the name of the new entity instance in the exemplary ECQL statement. If the resource of reading RFID tags is not made available to the VON, the corresponding ECQL statement is missing in the MCC DataContainer and thus the validation of the ECQL statement in Listing 5 would fail.

5. Evaluation scenario
The presented architecture was evaluated in a building access scenario involving personnel RFID auto-identification. The realizing system has to cope with the interests of different owners, namely the facility management of the building, two departments accommodated in this building providing independent

Fig. 10 Evaluation Scenario: overall hardware configuration and MBSC deployment International Journal Publishers Group (IJPG)

86

International Journal of Advanced Computer Science, Vol. 3, No. 2, Pp. 80-89, Feb., 2013.

Fig. 11 Facility Managements MBSCs

1) Facility management. In terms of functionality, one of its responsibilities is to handle RFID read events triggered from the physical interface when reading personnels RFID tags. According to that the data model consists of classes containing information about the tags actual partitioning necessary to retrieve the tags type from the raw data present on the physical interface along with well-defined classes to provide the information to the departments. This MBSC_ID is shown in Fig. 11a. It waits for read events, processes the read tags to gather their tag type and provides the tags raw data to the department concerned by saving them into the corresponding data container. The facility managements second responsibility is to relay the door commands to the security service component which controls the actual hardware. In order to obtain a flexible design this functionality was encapsulated in the separate component MBSC_Lock (Fig. 11b). Facility management owns RN0, an RFID reader capable to accommodate and run MBSCs within VONs. Initially one VON is available, but the owner can and does create a number of additional VONs for himself and its tenants. Facility managements own MBSCs reside in RN0 (VONs zid:inffeldgasse16Door1_1 and zid:inffeldgasse16Door1_2, see Fig. 10). 2) Security Service organization. Security service owns three components in our scenario.

MBSC_Lockstrategy (Fig. 12a) holds an overall building lock state and controls feedback indicators next to the door and the electric door opener mechanism. Honoring the lock state, it opens the door when receiving an open event. MBSC_Lockstrategy is located on the RFID reader, VON guardDuty:inffeldgasse16_Door1. As an MBSC, MBSC_Lockstrategy can be updated at any time by the sole discretion of its owner, the security organization to reflect a new security strategy. Two more MBSCs are located at RN1, the guards PDA. MBSC_Sec (Fig. 12b) enables the guard to set the building lock state described before, while a second logging MBSC visualizes received RFID entry events. This MBSC is not described further here. 3) Departments. A simple departments MBSC consisting of a state machine and data model is shown in Fig. 13. It gets notified every time a new tag data is read. The component reads the pre-processed tag data from the facility managements container, and tries to look up the ID in its private personnel list to decide whether this person is authorized to enter the building. In this case it sends an open event to the facility managements MBSC Lock component. Keep in mind, that each department has such a component. C. Realized VO use cases For demonstration of a typical task performed in this scenario a sequence diagram for a valid entry request is shown in Fig. 14. Starting with a person holding an RFID

Fig. 12 Securitys MBSCs

International Journal Publishers Group (IJPG)

Christian Kreiner: A Multi-Model Based Component Architecture for Virtual Organizations.

87

tag near the RFID-reader executing RN0, the MBSCs of all participating organizations interact upon their bilateral agreements and decouple RFID tag reading, ID approval, security strategy, and physically attached hardware resources.

contractual as well as the technical interaction between the department and its hired accounting service remains local between these two partners. D. Discussion The presented scenario has been implemented using the .NET Microframework for the realization of the runtime architecture components (i.e. MCC, VON and RN). The models presented in the previous section were encoded with JSON, enabling a more compact representation compared to XML.

Fig. 13 Departments ID data processing MBSC

For a discussion of the VON migration use case discussed in Sect. 3.3, the initial deployment of both department MBSCs in the RF-ID reader RN0 has to be considered. As a reason for a VON migration, a department might decide during operation to run its MBSC on another resource node for some reason (e.g. on its own server for privacy reasons). At the beginning of the migration use case the target resource node has to be instantiated and a new target VON has to be executed. The department communicates with the VON hosting the MBSC to be migrated by sending commands to the VON controller. These commands cause the current state of all MCCs to be saved. These saved MCC contents is then serialized to the freshly created MCCs of the new target VON. After the MBSC is migrated preserving its URN and internal state to its new resource node, its network name resolution gets updated. With the help of the transactional MCC access feature, all necessary steps happen as an atomic operation. Another independent decision within one department could be to automate work timekeeping from these available building entry/exit data. To accomplish this, an extended department MBSC like in Fig. 15 is deployed. It still takes the responsibility to check building access rights (required by the VO contract of this department), but also collects working time per employee and day to make it available to an accounting service. Note that the additional

Fig. 15

Extended ID processing MBSC

Table 1 gives an overview of the summarized file size of different artefacts created for this scenario. While the runtime environment consisting of VON and RN implementations has to ported for every architecture once, the MCC artifact has to be realized for every supported modeling language. For this scenario two modeling languages (state machine and class diagram) were realized in this artefact category. Device specific functionality consists of custom functions for ECQL statements, which also needs to be provided for each supporting platform combination. Finally the model artefact category summarizes the file size of the 7 data models and 7 state machine models containing the domain specific functionality of the scenario in the various MBSCs presented in the previous section. Note that the runtime environment as well as the MCCs can be developed with well-established component models (e.g. SOFA, Fractal), as the interfaces of these components are independent from the model-based application and are

Fig. 14 Sequence diagram for an approved building entry activity International Journal Publishers Group (IJPG)

88

International Journal of Advanced Computer Science, Vol. 3, No. 2, Pp. 80-89, Feb., 2013.

expected to be more stable.

TABLE 1 CODE SIZE OF ARTEFACTS FOR THE PRESENTED SCENARIO

6. MBSC development support

Code Size (kByte) 135 86.5 47.4 22.4 % of total 46% 30% 16% 8%

Artifact Runtime Environment MCC Device specific Application models

TABLE 2 TRANSFER OF MODELS TO A VON

CPU speed [MHz] 200 600 1400

.NET platform Micro Compact Full

Transfer Time [s] 46% 16% 8%

In order to support the development of MBSCs, a modular graphical development environment has been created (Fig. 16). Model editors for all Domain Specific Languages used for MBSCs are at the core of this environment. The backend are code generators for the JSON model representation, the model exchange format in our framework. The generated JSON representation of an MBSC can then be directly loaded into and MCC for execution. In our implementation, this multi-modeling development environment is based on Eclipse EMF/GMF technology. Currently, DSL editors for class-diagram like data models, statechart models, and user interface design models have been implemented and obey the same M2 metamodels used also in the MCC and executors. ECQL (Sect. 4) is used as glue language between the different DSL models used in MBSCs.

Table 2 summarizes the time needed for transferring and loading the updated models in the MCCs, which is the major task required for reconfiguration of a VON. As code developed for the .NET Microframework is specified in C#, it can be easily used in the other .NET platforms. Therefore tests were executed on three device architectures, consisting of a PC with a 1400 MHz processor, an industrial PDA with a 600MHz ARM processor and GHI Chipworks Development System for the .NET Microframework containing a 200 MHz ARM processor, 64 MB RAM and 8 MB flash memory. The great runtime difference is resulting of the different CPU speeds and the lack of a just-in-time compiler in the .NET Microframework.

7. Conclusion
In this paper an application of a combined multimodeling, loosely-coupled, component-based architecture for decentralized virtual organizations scenarios has been presented. Every artifact in the system has a clear owner responsible for its life cycle. The architecture tries to decouple evolution in functionality, runtime-platform/ middleware, and hardware resources. This aims at locally limiting ripples coming from life cycle dependencies. Functionality is partitioned in model-based software components (MBSC) containing multiple models (in the presented scenario mostly data class models and statecharts). These models can be referenced and thus

Fig. 16

Modular graphical development tool for Domain Specific Languages used MBSCs (shown here: MBSC data model) International Journal Publishers Group (IJPG)

Christian Kreiner: A Multi-Model Based Component Architecture for Virtual Organizations.

89

woven together by the Entiy-Container Query Language (ECQL). The models reside in MBSC Containers (MCC) and are executed directly at run-time. MCCs are plugin-exensible to support additional kinds of models. Extensible modeling tools have been implemented for multi-modeling used in MBSCs. The generic runtime and deployment architecture presented supports the dynamics of virtual organizations (VO) by the separation of concerns in resource nodes (RN) and virtual organization runtime nodes (VON). Local resources are controlled by RNs, and made available to their VONs. VONs are used as execution platforms for MBSCs. They are identified by an URN and can be migrated to other RNs. A prototypical implementation of MCC, VON, and RN has been realized based on the .NET Microframework and utilizes JSON for data encoding. This prototype has been evaluated in a building access scenario, where different autonomous organizations (facility management, security service, and several departments) cooperate on the basis of bilateral agreements. Within their responsibility, they organize life cycles of owned components by their own discretion asynchronously of each other. Future work shall include the support of additional runtime platforms, new MBSC model types and the corresponding MCC plugins, as well as steps to improve the security of the runtime platform.

[4]

[11]

[12]

[13] [14]

[15]

[16]

[17]

References
[1] P. Liggesmeyer and M. Trapp, Trends in embedded software engineering, Software, IEEE, vol. 26, no. 3, pp. 1925, April 2009. [Online]. Available: http://dx.doi.org/10.1109/MS.2009.80. G. Fischer, K. Nakakoji, and Y. Ye, Metadesign: Guidelines for supporting domain experts in software development, Software, IEEE, vol. 26, no. 5, pp. 3744, August 2009. [Online]. Available: http://dx.doi.org/10.1109/MS.2009.134. G. Blair, N. Bencomo, and R. B. France, Models@ run.time, Computer, vol. 42, no. 10, pp. 2227, October 2009. [Online]. Available: http://dx.doi.org/10.1109/MC.2009.326 A. Hessellund, Domain-specific multimodeling, Ph.D. dissertation, IT University of Copenhagen, February 2009. R. Want, When cell phones become computers, Pervasive Computing, IEEE, vol. 8, no. 2, pp. 25, 2009. [Online]. Available: http://dx.doi.org/10.1109/MPRV.2009.40 C. Ebert and C. Jones, Embedded software: Facts, figures, and future, Computer, vol. 42, no. 4, pp. 4252, June 2009. [Online]. Available: http://dx.doi.org/10.1109/MC.2009.118. C. Szyperski, Component Software: Beyond Object-Oriented Programming (2nd Edition), 2nd ed. Addison-Wesley Professional, November 2002. T. Bures, T., P. Hnetynka; F. Plasil, J. Klesnil, O. Kmoch, T. Kohan, P. Kotrc, Runtime Support for Advanced Component Concepts, September 2007. [Online]. Available: http://dx.doi.org/10.1109/SERA.2007.115. T. Bures, P. Hnetynka, and M. Malohlava, Using a product line for creating component systems, in SAC 09: Proceedings of the 2009 ACM symposium on Applied Computing. ACM, 2009, pp. 501508.

[18]

[19]

[2]

T. Barros, R. Ameur-Boulifa, A. Cansado, L. Henrio, and E. Madelaine, Behavioural models for distributed fractal components, Annals of Telecommunications, vol. 64, no. 1, pp. 2543, February 2009. [Online]. Available: http://dx.doi.org/10.1007/s12243-008-0069-7 F. Baude, D. Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio, and C. Perez, GCM: a grid extension to Fractal for autonomous distributed components, Annals of Telecommunications, vol. 64, no. 1, pp. 524, February 2009. [Online]. Available: http://dx.doi.org/10.1007/s12243-008-0068-8 H. Lochmann and A. Hessellund, Integrated view on modeling with multiple domain-specific languages, in Software Engineering. IASTED, February 2009. P. C. Jorgensen, Modeling Software Behavior: A Craftsmans Approach, 1st ed. AUERBACH, July 2009. I. Bird, B. Jones, and K. F. Kee, The organization and management of grid infrastructures, Computer, vol. 42, no. 1, pp. 3646, 2009. [Online]. Available: http://dx.doi.org/10.1109/MC.2009.28 H. Kurdi, M. Li, and H. A. Raweshidy, A classification of emerging and traditional grid systems, IEEE Distributed Systems Online, vol. 9, no. 3, p. 1, 2008. [Online]. Available: http://dx.doi.org/10.1109/MDSO.2008.8 J. Mo, Q. Sheng, X. Li, and S. Zeadally, RFID infrastructure design: A case study of two Australian RFID projects, Internet Computing, IEEE, vol. 13, no. 1, pp. 14 21, jan.-feb. 2009 G. Schmoelzer, S. Mitterdorfer, C. Kreiner, J. Faschingbauer, Z. Kovacs, E. Teiniker, and R. Weiss, The Entity Container - An Object-Oriented and Model-Driven Persistency Cache, in HICSS. IEEE Computer Society, 2005. U. Krenn, M. Thonhauser, and C. Kreiner, ECQL: A Query and Action Language for Model-Based Applications, in Engineering of Computer Based Systems, 17th Annual IEEE International Conference and Workshop, 2010, pp. 286 290. M. Thonhauser, G. Schmoelzer, and C. Kreiner, Modelbased Data Processing with Transient Model Extensions, in Proceedings of the 14th Conference and Workshop on the Engineering of Computer Based Systems (ECBS). Tucson, AZ, USA: IEEE, March 2007, pp. 299 306.

[3]

[4] [5]

[6]

[7]

[8]

[9]

Christian Kreiner graduated and received a PhD degree in Electrical Engineering from Graz University of Technology in 1991 and 1999 respectively. 1999-2007 he served as head of the R&D department at Salomon Automation, Austria, focusing on software architecture, technologies, and processes for logistics software systems. He was in charge to establish a company-wide software product line development process and headed the product development team. During that time, he led and coordinated a long-term research program together with the Institute for Technical Informatics at Graz University of Technology. There, he leads the Industrial Informatics and Model-based Architectures group. His research interests include systems and software engineering, software technology, and process improvement.

International Journal Publishers Group (IJPG)