A Model Driven Component Framework for Mobile Computing Egon Teiniker
, Stefan Mitterdorfer , Leif Morgan Johnson , Christian Kreiner , Zsolt Kov´acs
Institute for Technical Informatics Graz University of Technology, Austria
[email protected]
Abstract – Shorter product cycles and increasing system and software complexity, especially with respect to mobile computing, require changes in software construction and the utilization of leading-edge technologies. We present an abstract, platform-independent component model as a basis for component-oriented development, leading to better software reuse and reduction of architectural complexity. For this component model we have defined mappings to various combinations of programming language, middleware and operating system. According to these mappings, and with the support of tools, concrete component logic for a certain platform can be generated from an abstract component description.
The Object Management Group (OMG) specified the Common Object Request Broker Architecture (CORBA) [13] as a middleware standard in enterprise computing. CORBA is designed to work especially in heterogeneous systems with different programming languages. With the last version there came extensions to the CORBA standard that address the requirements in mobile environments where resources are limited:
Minimum CORBA [15] is a subset of CORBA designed for systems with limited resources. It omits dynamic aspects of CORBA but is fully interoperable with standard CORBA. Real–Time CORBA [16] is an optional set of extensions to CORBA that provides standard policies and mechanisms to support quality–of–service requirements. Thus, the Object Request Broker (ORB) can to be used as a component in Real–Time systems.
Keywords: mobile computing, MDA, CCM; I. I NTRODUCTION Mobile devices are increasingly common in multi-tier information systems, which opens up another dimension of complexity in terms of development for heterogeneous platforms and communication links. In addition, marketplaces are exerting pressure to increase software development efficiency. In order to succeed, software reuse has to be boosted, and complexity has to be tamed in some manner. In both respects Component Based Development (CBD), and the software product line approach in particular, seem to be promising [2]. We propose a component framework which offers a defined common component model based on the CORBA Component Model (CCM), serving as an abstract basis for CBD. This allows us to build a CBD process upon the framework, with clearly defined roles of component designers, developers, and application assemblers. The component model can be mapped to various programming languages. Tools generate the component logic from the component definition for a variety of language, OS and communication platform combinations. II. R ELATED WORK A. Middleware in heterogeneous environments The improved performance in mobile computing allows the use of middleware technologies coming primarily from enterprise computing. Meanwhile, the specifications of middleware are more and more adapted to the requirements of mobile and real–time environments.
Salomon Automation GmbH Friesach bei Graz, Austria
Wireless Access and Terminal Mobility in CORBA [11] specifies an architecture and interfaces to support wireless access and terminal mobility in CORBA. Transparency of the mobility mechanism to non–mobile ORBs has been the primary design constraint. A stationary ORB does not have to implement this specification in order to interoperate with CORBA objects and clients running on mobile terminals.
With these specifications, along with its increasing industry use, CORBA seems to be a suitable middleware standard for the next generation of mobile computing. B. Component based development The main challenge for software developers is to handle complexity and to adapt quickly to change. These problems are addressed by a rapidly emerging approach called Component–Based Development (CBD) [2]. In its simplest form, a software component contains some code and an interface that provides access to the component. From outside components should be looked at as black boxes; their interface alone provides all of the information needed by users. In CBD we distinguish development of components from development of systems using components. While the component development process is focused on building reusable units, the system development process concentrates on the
reuse of components and their evaluation and integration. These tasks can be performed independently of each other. The system architecture in CBD will be the result of the choice of a component model that defines the overall structure and communication mechanisms of software components. Component–based real–time systems must take care of timing constraints, reliability and robustness. Unfortunately general–purpose component models often do not provide real–time support.
(Fig. 1) provides a variety of surface features that support ways to connect components together to form assemblies:
Facets are named interfaces that provide access to specific component methods;
Receptacles are named connection points that describe the ability to use a facet;
C. Model driven architecture
Event sources are named connection points that emit events of specified type to one or more interested consumers or to an event channel;
The OMG has proposed a modeling language called the Unified Modeling Language (UML) [12] for describing all kinds of object–oriented software artifacts. In the upcoming UML 2.0 standard [17, 18] there are some extensions for real–time modeling (Timing Diagrams) and formal methods (executable models). The OMG also defines a notation to express meta-models called Meta Object Facility (MOF) [14]. For example, MOF has been used to define the UML meta-model. To simplify modeling, design and implementation, the OMG defined the Model Driven Architecture (MDA) [10, 6, 1]. Using MDA, an application is completely defined at the model level, expressed in UML. An MDA application’s base model specifies every detail of its business functionality and behavior in a technology neutral way - the Platform– Independent Model (PIM). MDA tools follow an OMG standard mapping to generate a Platform–Specific Model (PSM). In the final development step, working from the PSM, MDA tools generate interface definitions, application code, makefiles, and configuration files for the PSM’s middleware platform. Because the PIM is middleware neutral and conversion to PSM and then to the implementation is mostly automatic, it is practical to produce equivalent implementations of MDA based applications on multiple target platforms. The MDA supports applications over their full lifecycle starting with design and moving on to coding, testing, development, and maintenance. III. CORBA
COMPONENT MODEL
The CORBA component model (CCM) [19] defines a component architecture and a container framework in which the component life cycle takes place. A CCM Component Home Interface
Home
Equivalent Interface
Component
Event Sinks
Facets
Receptacles
Event Sources
Attributes
Figure 1: CCM component
Event sinks are named connection points into which events of a specified type may be pushed; and finally Attributes are named values exposed through accessor and mutator operations.
Home External Interface
Component Callback Interface
Internal Interface
Container ORB
POA CORBA Interface
Figure 2: CCM component container
Components run in a CCM Container (Fig. 2) that provides the runtime environment for CORBA components. Containers are built on the Object Request Broker (ORB), the Portable Object Adapter (POA) and CORBA services. Connecting components by their ports leads to component Assemblies that are described by assembly descriptors. IV. M ODEL – DRIVEN
COMPONENT DEVELOPMENT
A. Component logic vs. business logic The CCM specification hides most of the CORBA programming details from the application developer, but it still forces the developer to deal with CORBA references, data types and memory management. While the OMG Java mapping [9] is acceptable in this regard, the C++ mapping [8] does not use the advantages of standard C++ like strings, vectors and lists. To improve the usability of CCM, we have proposed a new approach that provides an easy way to implement business logic without having to pay attention to CORBA details [21]. We separate the application code from the implementation of the CORBA component logic (Fig. 3). For every IDL definition of a CORBA interface or component, we define a corresponding interface in the implementation language.
Home Interface
A
Home
CCM Component Equivalent Interface
A
Receptacles
local Component
A
A
Facets
Component implementation: To implement component logic means to define a mapping from the component model to a particular realization using programming languages and middleware technologies: .-
A
Attributes
Figure 3: Local component adapter concept
Adapters (labeled with in Fig. 3) provide CORBA mappings, and link the implementation of business logic to the CCM component. It is important to keep in mind that these adapters do not change the client view of a component, so our approach still conforms to the CCM standard. B. Component model vs. component realization The CCM component model, , is defined by two meta-models, namely the BaseIDL and the ComponentIDL. The BaseIDL meta-model defines the classic CORBA interface repository while the ComponentIDL meta-model expresses the component model extensions. Dividing component models from component realizations leads to more flexibility in component development as shown in Fig. 4.
! / 0
1 6 6 2 354 487.9;:;9 4=
