A Model Driven Component Framework for Mobile Computing

Transcription

1 Model Driven Framework for Mobile Computing Egon Teiniker, Stefan Mitterdorfer, Leif Morgan Johnson, Christian Kreiner, Zsolt Kovács Institute for Technical Informatics Graz University of Technology, ustria Salomon utomation GmbH Friesach bei Graz, ustria bstract 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. ccording to these mappings, and with the support of tools, concrete component logic for a certain platform can be generated from an abstract component description. Keywords: mobile computing, MD, CCM; I. INTRODUCTION 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 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 CORB 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. RELTED WORK. 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. The Object Management Group (OMG) specified the Common Object Request Broker rchitecture (CORB) [13] as a middleware standard in enterprise computing. CORB is designed to work especially in heterogeneous systems with different programming languages. With the last version there came extensions to the CORB standard that address the requirements in mobile environments where resources are limited: Minimum CORB [15] is a subset of CORB designed for systems with limited resources. It omits dynamic aspects of CORB but is fully interoperable with standard CORB. Real Time CORB [16] is an optional set of extensions to CORB 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. Wireless ccess and Terminal Mobility in CORB [11] specifies an architecture and interfaces to support wireless access and terminal mobility in CORB. Transparency of the mobility mechanism to non mobile ORBs has been the primary design constraint. stationary ORB does not have to implement this specification in order to interoperate with CORB objects and clients running on mobile terminals. With these specifications, along with its increasing industry use, CORB seems to be a suitable middleware standard for the next generation of mobile computing. B. 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 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

2 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. 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. C. Model driven architecture 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 rchitecture (MD) [10, 6, 1]. Using MD, an application is completely defined at the model level, expressed in UML. n MD application s base model specifies every detail of its business functionality and behavior in a technology neutral way - the Platform Independent Model (PIM). MD tools follow an OMG standard mapping to generate a Platform Specific Model (PSM). In the final development step, working from the PSM, MD 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 MD based applications on multiple target platforms. The MD supports applications over their full lifecycle starting with design and moving on to coding, testing, development, and maintenance. III. CORB COMPONENT MODEL The CORB component model (CCM) [19] defines a component architecture and a container framework in which the component life cycle takes place. CCM Equivalent Facets Receptacles ttributes Figure 1: CCM component Event Sinks Event Sources (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; Event sources are named connection points that emit events of specified type to one or more interested consumers or to an event channel; Event sinks are named connection points into which events of a specified type may be pushed; and finally ttributes are named values exposed through accessor and mutator operations. Container ORB Callback Internal PO CORB External Figure 2: CCM component container s run in a CCM Container (Fig. 2) that provides the runtime environment for CORB components. Containers are built on the Object Request Broker (ORB), the Portable Object dapter (PO) and CORB services. Connecting components by their ports leads to component ssemblies that are described by assembly descriptors. IV. MODEL DRIVEN COMPONENT DEVELOPMENT. logic vs. business logic The CCM specification hides most of the CORB programming details from the application developer, but it still forces the developer to deal with CORB 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 CORB details [21]. We separate the application code from the implementation of the CORB component logic (Fig. 3). For every IDL definition of a CORB interface or component, we define a corresponding interface in the implementation language.

3 Equivalent Facets ttributes CCM Receptacles Figure 3: Local component adapter concept dapters (labeled with in Fig. 3) provide CORB 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. model vs. component realization The CCM component model,, is defined by two meta-models, namely the BaseIDL and the IDL. The BaseIDL meta-model defines the classic CORB interface repository while the IDL 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. IDL3 File UML Model g1 p1 p2 Metamodel Library CCM Model M CCM Figure 4: Mapping to and from the CCM model g2 g3 g4 g5 remote C++ remote Java C++ definition: component is defined by its interfaces, which are written in IDL [13]. There is a mapping from the IDL syntax to a component model in respect to the component meta-model. The component model can also be mapped to an IDL syntax! "!#. Beyond the IDL description there can be other mappings, e.g. a UML model. UML model would describe a component only if there is a valid mapping to the component model %$&!(')&*+,. Java implementation: To implement component logic means to define a mapping from the component model to a particular realization using programming languages and middleware technologies:.-!/ ;:;9 4=<><>< Note that the component model is mapped directly to a realization in a programming language. This generated code is the inside view of the component logic for the component developers. The component developer writes the business logic in respect to the implementation of in a particular programming language without having to worry about or remote invocation. The generated component logic includes all of the adapters need for transparently substituting middleware technologies and component collocation. Thus, there must be a set of code generating tools that realize the mappings between and different device and communication platforms. Especially in mobile computing, where communication mechanisms are heterogeneous, the model driven component development concept leads to a more general programming model, and the written business logic is portable between different platforms because of the additional component model abstraction layer. C. Remote components The CCM specification describes a mapping from the component model to remote components in different programming languages, where all ports are accessible from CORB clients. Each remote component is accessible from any point in the network, but communication between components in the same address space is very expensive because method calls still have to go through the CORB ORB. There are some techniques for transparently optimizing communication overhead (e.g. CORB collocation [20, 22, 23]). To separate the business logic from the CORB component logic we define adapter classes as explained above. Then deploying a component remotely or ly is just a matter of using the appropriate adaptors. D. Local components One of the important issues in Based Software Engineering (CBSE) [5] is the granularity of components. Fat components increase runtime performance, but their reuse is limited. On the other hand, thin components lead to significant communication overhead but are easy to reuse. To implement thin components in the same address space we need a specific component model that defines components and their interconnections. In Java there already exists such a thin component model (JavaBeans [3]),

4 but in other languages like C++ and Python there are no such specifications. There is a need for a language independent component model with mappings to many different programming languages. Instead of inventing another new component model, we use the CORB Model in a manner. We defined a mapping from the component model / to realizations in C++ and Java without using middleware. We can also leave some ports while some other ports are made remotely accessible by using a remote adapter. Note that the decision between using the or remote adapters does not affect the implementation of the business logic; in other words we can scale the remote accessibility of a component port by port. E. ssemblies of and remote components Local components increase runtime performance, but they are not accessible from other devices in a network. To overcome this problem, we build assemblies of and remote components using the Session Facade pattern [7]. Fig. 5 shows an example of two assemblies running on different devices. IDL parser The IDL parser reads the IDL source code, checks the syntax and creates the component model in memory. Model driven code generator The different mappings between the component model and the implementations of component logic / are realized by a model driven code generator tool that uses template sets to be flexible and extensible. The generator considers the as a graph in memory and follows a general design paradigm known as the visitor pattern [4]. There are three parts of a generator: The graph traverser is responsible for traversing a given graph in memory; the node handler receives traversal events from the traverser and performs the code generation; and a template set is essentially a collection of plain text files. These files are written in the target code language. This model driven component development framework offers us the ability to generate software component logic for different mobile devices using different communication structures. We can also implement business logic in various programming languages. VI. CONCLUSION ND FUTURE WORK Device Device B Figure 5: assembly n assembly can be described as a directed graph where the nodes are component instances and the edges are receptacle to facet connections. From the client s point of view, the session facade component looks like a fat remote component. In fact, this fat component is an assembly instance graph consisting of thin remote and components that ensure easy reuse of business code. V. COMPONENT DEVELOPMENT FRMEWORK To use the model driven component development concept, we support tools that result in a component development framework. CCM meta-model library We have implemented a meta-model library of the CCM Repository (IR) that supports navigation between the different parts of the model as well as access methods to their attributes. We have presented a component model based on the CORB Model (CCM) that is usable for location and middleware independent development of software components. It serves as a common abstraction for heterogeneous OS platforms, programming languages, and communication infrastructure from middleware to collocation. Thus it is equally applicable to information system servers, clients, and mobile clients. In this way it serves not only as a common basis for component based development, but also gives additional freedom when choosing deployment nodes for components. Generators produce component logic from the component interface definition for a certain language, middleware and OS combination. t the time of writing, generators for C++ components, remote (CCM) C++ components and complementary IDL are available. The latter is used for regression testing logic at the component level. Currently, development takes place primarily on Linux with the focus on stabilizing the component model and generators. Future work will concentrate on additional generator variants for Java and Python, and both and remote and migration to wirelessly coupled PD devices with limited resources. The presented approach is part of a comprehensive framework for multi-tier information and control systems in the area of logistics. Other topics covered in this framework are (G)UI technology and database access. REFERENCES [1] Jean Bézivin. From Object Composition to Model Transformation with the MD. Proceedings of TOOLS, 2001.

5 [2] Ivica Crnkovic and Magnus Larsson. Building Reliable -based Software Systems. rtech House Publishers, [3] Robert Englander. Developing Java Beans. The Java Series. O REILLY, [4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. ddison-wesley, Reading, M, [5] George T. Heineman and William T. Councill. -Based Software Engineering - Putting the Pieces Together. ddison Wesley, [6] Jon Siegel. Using OMG s Model Driven rchitecture (MD) to Integrate Web Services. Technical report, Object Management Group, [7] Floyd Marinescu. EJB Design Patterns: dvanced Patterns, Processes and Idioms. Wiley Computer Publishing, [20] Douglas C. Schmidt, Nanbor Wang, and Steve Vinoski. Object Interconnections: Collocation Optimization for CORB. SIGS C++ Report, [21] Egon Teiniker, Stefan Mitterdorfer, Christian Kreiner, Zsolt Kovács, and Reinhold Weiss. Local s and Reuse of Legacy Code in the CORB Model. In Ivica Crnkovic and Gerhard Fohler, editors, EUROMICRO 2002, -Based Software Engineering Track, Dortmund, Germany, Sept. 4-6, 2002, pages 4 9, Los lamitos, C, IEEE Computer Society. [22] N. Wang, D. Schmidt, and D. Levine. Optimizing the CORB Model for High-performance and Real-time pplications, [23] Nanbor Wang, Michael Kircher, and Douglas C. Schmidt. pplying Reflective Middleware Techniques to Optimize a QoS-enabled CORB Model Implementation [8] OMG. C++ Language Mapping Specification. Technical Report , Object Management Group, [9] OMG. IDL to Java Language Mapping Specification. Technical Report , Object Management Group, [10] OMG. Model Driven rchitecture (MD). Technical Report , Object Management Group, [11] OMG. Telecom Wireless CORB. Technical Report , Object Management Group, [12] OMG. Unified Modeling Language (UML), Version 1.4. Technical Report , Object Management Group, [13] OMG. Common Object Request Broker rchitecture (CORB/IIOP), Version 3.0. Technical Report , Object Management Group, [14] OMG. Meta-Object Facility (MOF), Version 1.4. Technical Report , Object Management Group, [15] OMG. Minimum CORB, Version 1.0. Technical Report , Object Management Group, [16] OMG. Real-Time CORB, Version 1.1. Technical Report , Object Management Group, [17] OMG. UML Infrastructure, Version 2.0. Technical Report , Object Management Group, [18] OMG. UML Superstructure, Version 2.0. Technical Report , Object Management Group, [19] OMG. CORB s. Technical Report , Object Management Group, June, 2002.