Home arrow Projects funded by public calls arrow subTask 2.2 Building a middleware infrastructure for the development of distributed applications ove  
 

Main Menu
Home
About us
Project Description
Quantitative Results
Research Lines
Research Results
Impact on Society
Press room
Contact us
News
Secure Login
Events Calendar
« < October 2017 > »
M T W T F S S
25 26 27 28 29 30 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
Login

subTask 2.2 Building a middleware infrastructure for the development of distributed applications ove
Leader: Diego Sevilla

1. Brief Description of the Goals

The development of the CORBA-LC component model was motivated by some deficiencies in existing tools for the development of distributed applications. First, it was noted that component-based development (CBD), identified as a very well established and convenient paradigm for the development of applications, did not have a distributed counterpart that also allowed the efficient and transparent usage of the network resources. Existing distributed component models, such as EJB or CCM, are oriented towards enterprise applications, and implement a server-oriented model, instead of a peer model that would allow the homogeneous integration of the set of network resources. At the same time, actual developments that offer those network integration capabilities (as Grid systems), in general, don't offer a rich programming model that allows modular, reusable application development, having complex installation and maintenance procedures. Also, they are thought to be run mostly in dedicated systems, not for the transparent integration of existing networks, as it is the aim of CORBA-LC.

2. Scientific and Technical Developed Activities

We have specified a component model based on CORBA (CORBA Lightweight Components, CORBA-LC) that eases the development of distributed applications. This is because of the key characteristics of CORBA-LC:

i. Software is divided in independent modules, with a well-defined interface. These modules are called components, and, by being independent, they can be developed, specified and tested in isolation, enhancing the software quality.

ii. Each component specifies CORBA interfaces. Those interfaces allow that component to be accessed remotely in a transparent way, regardless of the computer it is running on. Also, each components offer standardized information on how to install it, its requirements of CPU and memory usage, architecture and operating system, other required components (meta-information) that allows to manage it, send it remotely, install and reinstall it, etc.

iii. The running environment also supports a well-known standard set of services, such as load balancing, fault tolerance, distributed searches for components, etc. These services are offered to the component through the container. The container also manages activation and deactivation of components through standard interfaces.

iv. Components specify what services they demand from the container, and it provides them. This has the following advantages:

a) service code is shared among all the components
b) the component only implements its required functionality, and does not have to have into account other requirements such as load balancing, provided by the container.

v. Component-based development allows developing applications by connecting basic components. In this activity, such a tool to develop applications has been carried out.

Finally, the set of policies forming the dialog between the component and the container has been formally established. These results were published by Sevilla et al. in the NCA 2007 Conference.
 

Publications: [Sevilla07a], [Sevilla07b]

Projects funded by Public Calls: 

External collaborations Academia: --

External collaborations Industry: --

Company Agreements: --

PhD dissertations:  --

Patents: --