Component-based Models For Distributed Systems

Jianhua Yang College of Information and Electrical Engineering

China Agricultural University Beijing, 100083, China yang.haag@163.com

Stephan Kindermann Department of Computer Science 7

Friedrich-Alexander-University Erlangen-Nuremberg Erlangen, D-91058, Germany

Xiaowei Qi Tongzhou Power Supply Company Beijing Electric Power Company

Beijing, 100020, China

Abstract—Much larger flexibility of software adaptability is necessary to the destination platform and the user requirement in distributed systems. Component-based models are becoming increasingly ubiquitous as enabling technology for modern distributed system applications. Software modules and components have always played a key role in the systems. The fundamental contribution of component-based models lies in making the property of the distributed systems a core requirement. In this paper the component-based models, such as COM+, EJB, CORBA and OSGi, are evaluated, and how deployment modelling is described. To illustrate the component models, an application to POP3 Web service component is implemented in Visual Studio .NET.

Keywords-component; model; distributed system; COM+; EJB; CORBA; OSGi

I. INTRODUCTION Distributed systems form a rapidly changing field of

computer science. Development of the distributed systems is a complex and difficult task [1]. The complexity of the functionality realized by software in the systems is steadily increasing, too. The complexity leads to the wide adoption of component-based software development, which is an engineering methodology used to develop a software system by assembling components with well-defined boundaries, explicitly specified interfaces and context dependencies [2, 3]. This development requires less time to assemble components than to design, code, test and debug the entire system, which greatly reduces the software cost and the time to market, enhances quality and simplifies maintenance [2, 4, 5].

In order for independently developed components to be seamlessly integrated with each other, it is necessary that there are some component-based models that govern how components are developed, packaged, assembled and deployed. The current component models for the distributed systems have been designed, e.g. Enterprise JavaBeans (EJB) [6, 7], Common Object Request Broker Architecture (CORBA) [8, 9], Component Object Model (COM) [3, 10] and Open Service Gateway Initiative (OSGi) [7, 11]. In this paper, these component models are described and the relevant features of

components are discussed. Specifically, a possible way to build the component models is put in practice and an application to POP3 Web service component is designed and implemented in Visual Studio .NET with Visual C#.

II. MAIN CONCEPTS OF COMPONENT MODELS A software component is a reusable part of software, which

is independently developed and can be brought together with other components to build larger units. As technology advances, new components can replace the existing components that make up the application. The application is no longer a static entity, and entirely new application can be built quickly from existing components. A component-based model defines a set of specific standards and conventions used by the component developer. A component model implementation is the dedicated set of executable software elements required to support the execution of components within a component model.

Interactions can be carried out among components, traditional software entities and a component infrastructure via interfaces, as shown as Fig. 1. A software component infrastructure is the design of a set of interacting software components, which can ensure that a software system using components and interfaces would satisfy the performance requirements. An interface of a component can be defined as a specification of its access point.

Figure 1. Interactions among components, entities and a infrastructure

Two kinds of interfaces can be distinguished, the exported interface and the imported interface. Components can export/import the interfaces to/from environments which may

Traditional software entities

Components

Componentinfrastructure

150978-1-61284-459-6/11/$26.00 ©2011 IEEE

include other components. An exported interface, i.e. service offer, describes the services provided by a component to the environment; and an imported interface, i.e. service claim, specifies the services required by a component from the environment.

A distributed system consists of a collection of components, distributed over various computers, also called hosts, connected via a computer network. Normally a middleware [9, 12] is layered between distributed system components and network operating systems. Fig. 2 shows where the components are in a distributed system.

Figure 2. Position of components in a distributed system

III. SURVEY OF CURRENT COMPONENT MODELS FOR DISTRIBUTED SYSTEMS

A. EJB Component Model EJB is a key part in the Java 2 Enterprise Edition (J2EE)

and is a software component model for developing and deploying enterprise-wide business applications. Enterprise Beans are reusable, server-side components that clients can remotely access and execute. When composed and deployed in an EJB container, a bean is fully configurable and executable. Interoperability between local Beans is supported through the Java language model for method invocation. Interoperability between remote Beans is supported through the Java remote method invocation (RMI).

EJB offers two types of component, session beans and entity beans. Session beans are modeled to perform the various processes of a business, which can be update data in a database and participate in transactions. They may be either stateful or stateless. Entity beans operate as business objects and represent data in a database. Multiple users can share them concurrently.

Every Enterprise Bean consists of a home interface (EJBHome), a remote interface (EJBObject), an Enterprise Bean class, a primary key class and an XML Deployment Descriptor. The EJB specification clearly defines the responsibilities that component producers, component

consumer, vendors, and end-users fulfill. As shown as Table I, there are six roles defined for EJB component model.

TABLE I. ROLES IN THE EJB MODEL

Role Description Enterprise Bean Provider Produce the enterprise bean component

Application Assembler Write an application using enterprise beans

Bean Deployer Deploy the beans and application into an EJB container and server

EJB Container Provider Provide an EJB container and deployment tools

EJB Server Provider Provide a server that distributes the enterprise beans in a container to clients

System Administrator Configure and tune the server and container for optimum performance

The EJB specification allows for any kind of client, which means that a server can support multiple protocols like RMI, Internet Inter-ORB Protocol (IIOP) of CORBA, and Distibuted COM (DCOM). JavaBeans can work with CORBA and DCOM to support RMI.

B. CORBA Component Model CORBA is an Object Management Group (OMG) standard

which is an open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

OMG's best support for server-side scalability comes from the CORBA Component Model (CCM). The two important new ideas in the CCM are the component model and the container programming model. The component model uses ports to describe a component’s interconnectivity. Containers are the runtime environment for a component on the server side.

CCM components are the basic building blocks in a CCM system. A component definition is a specialization and extension of an interface definition. There are two levels of components: basic and extended. Both are managed by component homes, but they differ in the capabilities they can offer. The components support a variety of surface features through which clients and other elements of an application environment may interact with a component. These surface features are called ports. The component model supports four basic kinds of ports, i.e. Facets, Receptacles, Event sources or sinks, and Attributes, as shown as Fig. 3. The basic components only offer attributes. The extended components may offer any type of ports.

CORBA provides a bridge technology to allow CCM components to work with an EJB. An EJB component can be used by CORBA clients, including CORBA components. A CORBA component can also be used by a Java client, including an EJB component.

151

Figure 3. Ports of CCM components

C. COM, DCOM and COM+ COM is a component software architecture which allows

applications and systems to be built from components supplied by different software vendors. Object Linking and Embedding (OLE) and ActiveX are brand names for technologies that are developed using COM. COM defines a binary standard for component interoperability, which makes it programming language-independent. COM supports interaction between local components (in-process and cross-process) and between remote components (on different machines) via DCOM. DCOM is an extension of COM, which makes it possible to create networked applications built from components. COM+ is the latest incarnation of COM.

A COM interface is seen as a C++ virtual class and takes the form of a list of data and function declarations without associated code. Every component of COM must support an interface called IUknown, which provides a method for discovering the interfaces that are supported by this component. All interfaces are descendants of the IUnknown interface.

By enhancing and extending existing services, COM+ further increases the value that these services provide. COM+ works with both classic COM and the new Common Language Runtime (CLR). COM+ is based on two basic concepts, contexts and causalities. A context is essentially a set of run-time properties maintained for a collection of one or more objects, and represents the smallest execution context for a component. Every COM object is associated with precisely one context as it runs. Every context resides within precisely one COM apartment. Multiple objects can run within the same context. Multiple contexts can reside within the same apartment. A causality is a distributed chain of COM+ method calls that spans any number of contexts in any number of processes, possibly involving multiple machines. Each causality represents a single logical thread of action within the distributed system as COM+ method calls are invoked across contexts. COM+ can be built in Visual Studio .NET.

D. OSGi OSGi is an independent, non-profit corporation working to

define and promote open specifications for the delivery of

managed broadband services to networks in homes, cars and other environments. Fifteen companies, such as IBM, Motorola, Oracle, Philips Electronics, Sun Microsystems, Sybase, and Toshiba, were the original founders. Now there are more companies who have committed to support the full incorporation and charter of the organization.

OSGi is focused on the application layer and open to almost any protocol, transport or device layers. The central component of OSGi specification effort is the services gateway (SG) that functions as the platform for many communications-based services. The SG is intended to manage the interconnection with "zero administration".

The three key aspects of the OSGi mission are multiple services, wide area networks, and local networks and devices. OSGi links two key market trends: a) broadband connectivity and Internet access in homes, offices, vehicles and mobile/portable devices; b) new applications and services in networks and networked devices, such as new Jini "smart appliances", Bluetooth wireless device groups, TV-set top boxes, and DSL (digital subscriber loop) modems.

The OSGi technical specification creates an open standard for programmable user-premises equipment that includes: downloading of software, application lifecycle management, gateway security, attached device access, resource management, and functions necessary for remote administration of the gateway. Fig. 4 displays an application of OSGi in home with Internet of Things (IOT).

Figure 4. An application example of OSGi

152

In OSGi, components are called bundles, which are also the specifications for delivery of downloadable services. A bundle uses three kinds of ports to express its interactions with traditional technology, other components, and the run-time environment. Bundles may listen to events published by the framework such as the insertion of a new component in a system. There are two types of binding of components: static and runtime. In the component models like JavaBeans, components are simple reusable blocks of code, and the application is assembled by a builder tool before instantiation. The Components in the models cannot be substituted later. In component models of OSGi, component representatives are resolved at runtime when the application is loaded to the system, whose process is shown in Fig. 5. The components in the models can be substituted later because the application is assembled dynamically.

Figure 5. An example of runtime binding of components

IV. APPLICATION OF COMPONENT-BASED DEVELOPMENT WITH C#

Visual Studio .NET is a complete set of development tools for building Active Server Page (ASP) Web applications, XML Web services, desktop applications, mobile applications and components [10]. Its powerful component-based development tools and other technologies may directly be used to simplify team-based design, development, and deployment of Enterprise solutions.

The component can be created in Class Library of Visual Studio .NET. As an application, a class, TcpClient, can be used to develop a POP3 component which sets the host connection establishment based on TCP / IP network protocol connection and communication. To complete the component, it is necessary to design properties, methods and events of the component. In the POP3 component, some properties should be added, such as the host name, port number, the user name, password, number of messages and message size. The methods, ReceiveMessage and ReceiveMessageAsync, are used to complete connection and communication to the server, and end the session. An event, OnMailReceived, is triggered after the mail has been checked. By using the component, a messenger, like an e-mail program, can be easily developed, as shown as Fig. 6.

V. CONCLUSION The component models for the distributed systems are

discussed. An application to receive e-mails is implemented

with a POP3 component. EJB is available on many platforms and can exploit long-standing, proven technology to implement its futures. COM+ has a single, consistent implementation from a single vendor. And this implementation can be easily done in Visual Studio .NET. CORBA components are being proven in the market. OSGi creates a platform-independent delivery vehicle for value-added network services and a means for integrating the various networks. Therefore, OSGi may play a leading role in mobile environment and IOT.

Figure 6. An application to receive e-mails with a component

REFERENCES [1] A. S. Tanenbaum and M. Van Steen, Distributed systems: principles and

paradigms, Pearson Education. Inc, USA, 2007. [2] G. T. Heinememan and W. T. Councill, Component-Based Software

Engineering: Putting the Pieces Together, Addison-Wesley Longman, Boston, 2001.

[3] K. Lau and Z. Wang, “Software Component Models”, IEEE Trans. on Soft. Eng., vol. 10, pp. 709-724, October 2007.

[4] J. Carlson, J. Feljan, J. M. Turja and M. Sjodin, “Deployment Modelling and Synthesis in a Component Model for Distributed Embedded Systems”, 36th EUROMICRO Conf. on Soft. Eng. and Advanced Applications, 2010, pp. 74-82.

[5] C. Raj, J. Park, J. Park and S. Hong, “CREAM: A Generic Build-time Component Framework for Distributed Embedded Systems”, The 14th IEEE Inter. Conf. on Embedded and Real-Time Computing Systems and Applications, 2008, pp.318-323.

[6] K. A. Gabrick and D. B. Weiss, J2EE and XML Development, Manning Publications Co., Greenwich, 2002.

[7] H. Cervantes and J.-M. Favre, “Comparing JavaBeans and OSGi Towards an Integration of Two Complementary Component Models”, Proc. of the 28 th Euromicro Conf., 2002, pp.1-7.

[8] OMG, Common Object Request Broker Architecture (CORBA) Specification, Version 3.1 - Part 3: CORBA Component Model, OMG’s Issue Report, 2001.

[9] A. Puder, K. Roemer, and F. Pilhofer, Distributed Systems Architecture: A Middleware Approach, Elsevier Inc., San Francisco, 2006.

[10] D. Beyer, C# COM+ Programming, M & T Books, New York, 2001. [11] B. Lee, Ka-Kyung Oh, and D. Shin, “STUDY: OSGi-based intelligent

Ride-share vehicle middleware”, International Conf. on Electronics and Information Eng. (Volume 1), 2010, pp. 473-475.

[12] S. Vinoski, “Where is Middleware?” IEEE Internet Computing, vol. 2, pp. 83-85, March 2002.

A component requirement specification

Best fitting

component

Instantiate the components and form the application

trading service

153