An Infrastructure for Development of Dynamically Adaptable Distributed Components

Size: px
Start display at page:

Download "An Infrastructure for Development of Dynamically Adaptable Distributed Components"

Transcription

1 An Infrastructure for Development of Dynamically Adaptable Distributed Components Renato Maia, Renato Cerqueira, and Noemi Rodriguez Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, Rua Marquês de São Vincente, 225 RDC, Gávea, Rio de Janeiro, RJ, Brazil. Abstract. Dynamic adaptation has become an essential feature in distributed applications, mainly because current technology enables complex tasks to be performed by computers in application domains unsuited for service interruption. This paper presents an infrastructure that uses an interpreted language to provide simple but powerful features that enable coarse and fine-grained adaptations in component-based systems, using the CORBA Component Model (CCM) as a basis. To extend the static nature of CCM, we propose dynamic containers, which enable development of dynamically adaptable components that admit changes on component structure and implementation. The extended set of mechanisms for component manipulation can be used to create adaptation abstractions that simplify the programmer s task. In this paper, we present a tool that provides support for the protocols and roles abstractions, which allows programmers to adapt running applications, establishing new interactions among its components. 1 Introduction Much research work has focused on techniques that support software evolution, that is, techniques that allow changes to existing software to be introduced in faster and easier ways. However, most of the effort on this matter concentrates on providing flexibility statically, that is, on designing the source code used to generate the system with flexible architectures or structures [1, 2]. On the other hand, there are currently many software systems that should never be stopped, such as those for process control, e-business, life support or military applications. In these systems, interruption of service is highly undesirable, and the issue of software evolution becomes extremely expensive and troublesome. As a consequence, development of the first working version of the system becomes critical. Such projects are very risky, because of the high probability of underestimated time and cost constrains. In face of those problems, the software community has recognized the necessity of mechanisms to allow dynamic adaptation of computer systems [3], that is, the ability to change during execution. However, as in the static approach,

2 most of the proposed solutions are based on architectures or structures that are applied to specific portions of the system: those related to a given set of possible anticipated changes. This adds extra effort on system design, which now must predict possible points of modification; this effort can prove useless in the future if none of the predicted modifications are necessary. Besides, the use of those techniques generally increases the complexity of system design. The main reason for this is the lack of appropriate abstractions: mechanisms that provide flexibility are generally added to the system by merging new, adaptation-related components with those related to the application domain. We propose a framework for the development of components that uses computational reflection features as an abstraction to hide the details of dynamic adaptation mechanisms. This framework is built with the interpreted language Lua [4]. The use of a dynamically-typed interpreted language allows us to combine flexibility and simplicity. As a basic layer, our framework provides LuaCCM, an implementation of the CORBA Component Model (CCM). CCM extends the OMG object model with introspective interfaces and entities that allow developers to implement, configure, and manage component-based applications in a standardized way. One important advantage of using CCM as a basic layer is that the adaptation code produced with our framework can be mapped to other CCM implementations. However, CCM is a complex model and remains in the class of techniques that add complexity to the development process. The idea of our framework is to use LuaCCM as a basis for the construction of different adaptation abstractions. In this paper, we illustrate this layered approach with the discussion of a tool that supports the protocols and roles abstractions as proposed in [5]. This paper is organized as follows: Sect. 2 presents a brief overview of the main CCM concepts; Sect. 3 presents some details about the features provided by LuaCCM; In Sect. 4 we discuss how these features can be used to implement abstractions to perform dynamic adaptations, as well as the implementation of a tool based on the concept of protocols and roles and examples of its use to perform dynamic adaptation of a system; In Sect. 5 some related works are discussed and, finally, some final remarks are presented in Sect CORBA Component Model The last version of CORBA defines the new CCM specification [6], which is a component model defined on top of CORBA architecture and is primarily intended to solve some problems of CORBA related to extension mechanisms and standardization of common tasks involved in object handling, such as instantiation, activation, request dispatching, etc. [7]. A CCM component is defined as a set of ports and can additionally support interfaces and provide attributes like a usual CORBA object. The ports of a component are used to establish connections and are divided into four categories: facets, receptacles, event sources, and event sinks. Facets are ports that provide some interface and may be connected to receptacles, which are ports where an object implementing some interface

3 may be registered. Similarly, event sources are ports that send events and may be connected to event sinks to establish an event-based communication channel. Additionally, CCM also defines the concept of component homes that are some limited form of component used specifically to retrieve and manage instances of some component definition. Through a component home one can create new instances or recover persistent component instances. Fig. 1 shows a graphical representation of the main CCM concepts and Fig. 2 shows an example of a component definition described using the extended version of IDL defined by the new version of the CORBA specification. Fig. 1. Graphical representation of CCM concepts. 1 component MyComponent supports SupportedInterface 2 : SuperComponent 3 { 4 attribute string my_ atribute ; 5 provides FacetInterface my_ facet ; 6 uses ReceptacleInterface my_ receptacle ; 7 publishes PublishedEvent my_ event_ source ; 8 consumes ConsumedEvent my_ event_ sink ; 9 }; Fig. 2. Example of component definition in IDL 3.0. The central concept in CCM is that of container. The container provides an execution environment for component instances with many features like management of connections on ports or implementations of event channels. Besides that, the container also manages creation, activation and incarnation (in case of persistent components that are recovered by a new instance incarnating some previously saved state) of instances of component implementations, which are called executors. This management is defined by a set of different policies as specified in CCM specification. However, taking into consideration the nature

4 of the CORBA architecture, the implementation of a container requires some previous knowledge of component definition (e.g. for implementation of port handling), as well as of the component implementation (like policies that define how to activate instances). As a solution, CCM defines four different categories of components and a set of policies that may be used to define how to handle component instances of some component implementation. Additionally, specific tools are used to generate part of the container implementation related to some component definition (e.g. management of ports); this generated code is incorporated into the component implementation. This way, the same component can be deployed in different container implementations. 3 LuaCCM LuaCCM is an implementation of CCM using the Lua programming language. Lua is a general-purpose dynamically-typed interpreted language with usual control structures (while, if, etc.), function definitions with parameters, local variables, and data-description facilities. Initially, Lua was devised to be an extension language to customize industrial applications, but today it is being used in thousands of products and prototypes worldwide. Its success is partially related to one of its main characteristics: extensibility. Lua provides reflective facilities that enable the extension of its semantics, making it extremely flexible. Another important feature are the data-description facilities provided by Lua that are based on a single data structure called table. Lua tables are associative arrays that can hold values indexed by any valid value of the language. This feature can be used to represent objects by tables containing values that represent attributes, as well as functions that represent methods, since Lua functions are first-class values. Object-oriented facilities are partially supported by syntactic sugar that simplifies invocation and declaration. Additionally, using the extension facilities of Lua, it is also possible to define object behavior-sharing mechanisms though hierarchies of object classes or prototypes [8]. In spite of all its flexibility, Lua is also a very small and simple language. Our group investigates how the features of Lua can be used to improve the development of dynamically adaptable systems [9 13]. One of the products of this work is LuaOrb, which uses the extension mechanisms of Lua to define a dynamic binding of CORBA. With LuaOrb, it is possible to invoke CORBA object operations as common Lua object methods. Additionally, LuaOrb enables the development of CORBA objects using Lua. LuaOrb is implemented on top of a C++ ORB (any one compatible with CORBA 2.3 specification) and uses the CORBA Dynamic Invocation Interface to dynamically generate requests to CORBA objects according to the information provided by the CORBA Interface Repository. Similarly, it uses the Dynamic Skeleton Interface to receive and dispatch requests to the corresponding implementation of a particular servant. A LuaOrb servant implementation is a simple Lua object, i.e. a table containing values and functions. This way, we are able to dynamically change objects by replacing the functions that implement their operations.

5 LuaCCM extends LuaOrb with the concepts defined in the CCM specification. However, CCM is tightly coupled with the idea of statically defined components. Unlike other language mappings, LuaCCM defines the idea of a dynamic component, i.e. a component that can be changed at runtime. To allow that, we define the concept of a dynamic container, which can self-adapt to implement the facilities required by some component deployed at runtime. Additionally, dynamic containers also provide reflective facilities to adapt deployed component instances by changing their implementation, as well as changing the facilities provided according to the new implementation. We next present the details of the LuaCCM dynamic container and the reflective facilities provided to perform fine-grained adaptations on LuaCCM components. 3.1 Dynamic Containers LuaCCM dynamic containers are entirely implemented in Lua, as sets of Lua objects and LuaOrb servants. LuaOrb servants implement the external container interfaces, i.e. interfaces provided to component clients. The container creates a LuaOrb servant for each component instance. This LuaOrb servant implements the component main interface, which provides the operations of the supported interfaces, as well as operations to manipulate its ports. When the request of a facet is received, the container also creates a LuaOrb servant that implements the facet interface and dispatches all requests to the implementation of the component instance. Similarly, the container creates a LuaOrb servant at the request of each event sink of a deployed component instance. This servant implements an event consumer that delivers all consumed events to the implementation of the component instance. The container also creates a context object, i.e. an object that provides the interfaces used to access the facilities provided by the container to the component implementation, such as retrieving the objects connected to its receptacles or sending events though its event sources. CCM component implementations can be separated in independently activated parts called segments that implement different ports. Fig. 3 depicts the infrastructure created by the LuaCCM container for a component instance. Basically, the facilities provided by the LuaCCM container to a component instance are implemented by two elements: a wrapper object and a context object. The wrapper object is responsible for creating LuaOrb servants that represent the component, receiving requests or events and dispatching them to the component executor. Additionally, the wrapper object also implements the operations of the main component interface related to port handling, like the operations used to get facets or connect objects to receptacles. The context object is responsible for holding the references of objects connected to component receptacles and delivering the events sent through component event sources. Each time an implementation of a new component definition is installed, the container creates a definition manager, which retrieves the component definition (e.g. from a package descriptor or a component interface repository) and dynamically generates the implementation of the facilities provided to the new component by defining a wrapper object class and a context object class. Every

6 Fig. 3. LuaCCM container structure. time a new instance of that component definition is created, those classes are instantiated to produce the wrapper object and the context object for that particular instance. This behavior enables the dynamic adaptation of the container. Suppose that some component definition is modified and the corresponding definition manager is notified. Then, the wrapper and context object classes are adapted to implement new facilities according to the new component definition. As a result, every instance of the wrapper and context classes reflects the adaptation and provides the new facilities to every instance of that component definition installed in the container. Alternatively, the adaptation can be performed on a single instance of a component by adapting only the wrapper and context objects of that instance: that can be done replacing the functions provided by the wrapper and context classes. On the other hand, the dynamic container must also provide facilities to adapt the component executors. For example, if a new facet is added to the component definition, then the component executor must provide the new facet implementation. This is done by the definition of a segment constructor, i.e. a function used to create an object that implements an added facet or event sink and is added to the component executor as a new segment. The segment constructor is added to the wrapper class definition as a new field and can be used by the wrapper object to retrieve a facet or event sink implementation when necessary. When the adaptation is done only in a single instance of a component, the segment constructor is added directly as a field of the wrapper object. It is worth noticing that all component interactions are done by means of the wrapper and context objects. This enables the introduction of interceptors to handle the interactions of the component. The use of interceptors is useful to change the current behavior of a component, e.g. the services provided by a facet. As segment constructors, interceptors are defined as fields in the wrapper object or class. When a wrapper object receives a request to a port, it checks

7 if there is a defined field that specifies an interceptor for that port; if so, the interceptor is invoked to treat the request properly. The next section describes how the features of the dynamic container are used to implement the reflective facilities provided by LuaCCM components that allow fine-grained adaptations by changes on component definition and implementation. 3.2 Reflective Components LuaCCM dynamic containers can be dynamically adapted to provide the required facilities for a new component definition. Similarly, the same feature can be used to adapt the container to some modification on component definition. We propose the use of reflective facilities to manipulate components. Basically, we define mechanisms for introspection and intercession [14] of components definition and implementation. The CCM specification defines interfaces for introspection of component definition that are supported by all components. Those interfaces are used to retrieve information about the ports of a component, like their names, interfaces provided or requited, events emitted or consumed, etc. Additionally, those interfaces provide generic operations to manipulate component ports, for example to connect an object to a component receptacle given the name of the receptacle. However, CCM does not provide mechanisms to define changes on component structure (i.e. definition) or implementation. As a new intercession mechanism, we provide an interface called ::LuaCCM::Adaptable that provides operations to add or remove component ports, as well as to attach interceptors to existing ports. Fig. 4 illustrates the interfaces defined by LuaCCM, suppressing exception statements for sake of simplicity. The operations on ::LuaCCM::Adaptable interface for addition of ports receive as arguments the name of the new port and, in the case of facets or receptacles, the interface provided or required, and, in case of event sources and sinks, the event emitted or consumed. Notice that add facet and add consumer operations receive an additional parameter containing a piece of Lua code that defines the implementation of the added facet or event sink segment. Similarly, the operation intercept, used to attach an interceptor to a component port, also receives a parameter containing a piece of Lua code that defines the implementation of the port interceptor. LuaCCM interceptors are common Lua objects that provide interception operations, namely a before operation and an after operation. Both operations receive the self parameter used to identify the interceptor object that is notified of the method called, plus the request parameter, which is a table containing information about the intercepted request, such as the port name, port segment, operation name and parameters, etc. As one may suppose, the before operation is invoked just before an interaction is started through the component port, such as the execution of an operation on a facet or on an object connected to a receptacle, or even before the processing of a received event, or the emission of a new event. Additionally, the interaction can be cancelled and never passed to the component executor. To do so, the before operation must define the return values of the intercepted operation in the table containing information about the

8 1 module LuaCCM { 2 typedef string LuaCode ; 3 4 interface Adaptable { 5 void add_ facet ( in string name, in string iface, 6 in LuaCode code ); 7 void add_ receptacle ( in string name, in string iface, 8 in boolean ismultiple ); 9 void add_ emitter ( in string name, in string event_ type ); 10 void add_ publisher ( in string name, in string event_ type ); 11 void add_ consumer ( in string name, in string event_ type, 12 in LuaCode code ); 13 void remove_ port ( in string name ); 14 void intercept ( in string point, in LuaCode code ); 15 void unintercept ( in string point ); 16 }; interface AdaptableContainer : :: Components :: Container { 19 Adaptable get_ component_ adaptor ( in string name ); 20 }; 21 }; Fig. 4. LuaCCM adaptation interface. intercepted request. In case of intercepted event ports, since the event handler method returns no value, the before operation must define an empty list of return values prior to canceling the processing of the event. Similarly, the after operation is invoked after an interaction is performed through the component port. Fig. 5 illustrates the definition of an interceptor. 1 interceptor = { 2 before = function ( self, request ) 3 <implementation> 4 end, 5 after = function ( self, request ) 6 <implementation> 7 end, 8 } Fig. 5. LuaCCM interceptor definition. The reflective features of LuaCCM components can be used to provide a seamless mechanism of dynamic adaptation without additional effort of the system developer. However, dynamic adaptation is generally a complex task, mainly

9 because it is a peculiar form of system development that is done while the system is running. Like usual system development, dynamic adaptation can be improved by the use of programming abstractions and tools based on those abstractions. In the next section, we discuss how the features provided by LuaCCM infrastructure can be used as a basis for implementation of programming abstractions for dynamic adaptation of computer systems. 4 Adaptation Abstractions LuaCCM provides reflective mechanisms to perform fine-grained adaptations on component systems through the use of interfaces that can be used by any CORBA application to introduce changes on the system. However, the direct use of these interfaces remains a complex task. Using Lua s facilities, we can use LuaCCM as a basis for providing the programmer with different abstractions that organize the adaptation in a structured and modularized way. This organization makes the adaptation easier to design and understand, since a set of changes related to some particular subject or purpose can be separated into groups defining some particular aspect or functionality of the system. As a validation of this approach, we implemented a tool based on abstractions called protocols and roles. 4.1 Protocols and Roles [5] proposes the abstractions of protocols and roles to describe dynamic adaptations of running applications developed using the middleware Comet. A role is an abstraction used to define a set of characteristics (defined as a set of changes) that a component must provide prior to producing new behavior (or performing a new role ). More specifically, those changes are defined as a set of new connectors (i.e. ports) and changes on original connectors by use of interceptors. On the other hand, a protocol is an abstraction used to describe how a set of roles are applied to different components, and how those modified components are connected to produce the new aspect or functionality of the system. The protocol is defined by a set of scripts, each one defining how roles are applied and components are combined to produce one different feature. The protocols can optionally define an internal state. With the data-description facilities of the Lua language, we can provide a simple way to describe roles for CCM components, i.e. describe a list of added and intercepted ports, including the interfaces or events used, as well as the port or interceptor implementation when necessary. The structure of a role description in Lua using our proposed tool is illustrated in Fig. 6, where the role defines a new facet called inspector, including its implementation code defined as a string (Lua uses the [[ ]] delimiters to declare multi-line spanning strings) that creates an object (table) with two operations. The added facet provides the operation get field, which returns a string representation of the value of a field on the object implementing some component segment. Additionally, we

10 can use the extension mechanisms of Lua to define special semantics for role definitions, in such a way that the changes described can be translated to a sequence of operation calls on the adaptable interface of a LuaCCM component. As an example, Fig. 7 shows the sequence of operation calls to apply the changes defined by the role on Fig. 6 using the LuaCCM adaptable interface. 1 Inspectable = loaf. Role { 2 provides = { 3 inspector = { 4 interface = " eventflow :: distdebug :: Inspectable ", 5 code = [[{ 6 get_ field = function ( self, port, field ) 7 local executor = self. context : get_ executor ( port ) 8 return executor [ field ] 9 end, 10 }]], 11 }, 12 }, 13 } Fig. 6. Example of role definition using LuaCCM that provides inspection facilities. 1 adaptor = component : provide_ facet (" adaptation ") 2 adaptor : add_facet ( 3 " inspector ", " eventflow :: distdebug :: Inspectable ", 4 [[{ 5 evaluate = function ( self, port, field ) 6 return self. context : get_ executor ( port, field ) 7 end, 8 }]]) Fig. 7. Example of role definition using LuaCCM that provides reflective facilities. The implementation of the protocol abstraction in Lua is even simpler. A protocol can be described as a set of functions implementing the scripts used to apply roles and connect components. Alternatively, those functions can be stored in a table or used to define an object. In the last case, the protocol can use the internal state provided by the Lua object in the execution of protocol scripts. Fig. 8 illustrates the definition of a protocol, defined as a Lua object, that uses the Inspectable role of Fig. 6 to inspect components. The next section presents a dynamic adaptation of a hypothetical event-based application using

11 our tool based on protocols and roles. All the examples illustrated in the current and next sections are based on examples described in [5]. 1 InspectionProtocol = { 2 inspect = function ( self, component, port, field ) 3 Inspectable : assign ( component ) 4 local inspector = component : provide_ facet (" inspector ") 5 local value = inspector : get_ field ( port, field ) 6 Inspectable : unassign ( component ) 7 return value 8 end, 9 } Fig. 8. Example of protocol definition as a Lua object. 4.2 Use Examples To illustrate the use of our tool, we implemented an event-based application using our prototype of LuaCCM, which implements all the featured presented in this paper. This example application consists of an event producer component and two other components that process the produced events. The component server produces events and sends them through an event source called produced. On the other side, the components client1 and client2 receive the produced events through an event sink called raw. The events are processed and sent back to the server, as requests for a new event, through the event source done, which is connected to the request event sink on the server. Fig. 10 shows the definition of the example application components, interfaces and events in IDL 3.0. As an example of a possible adaptation, we discuss the dynamic inclusion of a mechanism for event flow synchronization that avoids that some client component gets stuck with an overloaded amount of unprocessed events. To do so, we define two roles: the FlowWatcher role that defines the new functionality required by the synchronized processing component, and the FlowRegulator role that defines the new functionality required by the producer component. The interfaces used by the flow synchronization roles are listed in Fig. 11 The FlowWatcher adds the functionality needed to analyze the flow of events received by a processor component, in order to identify flow glitches, i.e. when the amount of received events is greater than the processing capacity of the component. The new functionality is provided by the interception of port raw and addition of two ports: the facet limit, used to define a processing time upper limit used to trigger the synchronization, and the receptacle regulator, that provides the interface used to regulate the event production rate at the server when a glitch is identified. Fig. 12 shows the definition of the FlowWatcher. The flow analysis is done by the interception of port raw, which captures the

12 Fig. 9. Example event based application architecture. 1 module eventflow { 2 interface Instrumented { 3 attribute string name ; 4 attribute float speed ; 5 }; 6 interface Controlable { 7 void start (); 8 void stop (); 9 void pause (); 10 void continue (); 11 }; 12 eventtype SerialEvent { 13 public long seq_no ; 14 }; 15 component Producer supports Instrumented { 16 provides Controlable controller ; 17 consumes SerialEvent request ; 18 publishes SerialEvent produced ; 19 }; 20 home ProducerHome manages Producer {}; component Processor supports Instrumented { 23 consumes SerialEvent raw ; 24 emits SerialEvent done ; 25 }; 26 home ProcessorHome manages Processor {}; 27 }; Fig. 10. Example event based application using LuaCCM.

13 1 module eventflow { 2 module flowsync { 3 interface Rateable { 4 void set_ rate ( in double rate ); 5 }; 6 interface Limited { 7 attribute double value ; 8 }; 9 }; 10 }; Fig. 11. Interface used by flow synchronization roles time immediately before the event is processed by the component, and later calculates the total processing time, when event processing is completed. If the event processing time is larger than the limit defined at the limit facet executor (LuaOrb maps attributes to Lua object fields), then the object connected to the regulator receptacle is used to define a proper event production rate. However, the original event producer component does not provide functionality to regulate event production rate. Therefore, we define the FlowRegulator role to add this functionality to the server component. This is done by adding a new facet and the interception of port produced, that is used to send produced events. The added facet is called rater and is used to define the rate of events produced by the component, that is stored as a field of the context object (the context object can be used as a state shared by all component segments). This way, every time a new event is produced and sent through the produced port, it is intercepted by the FlowRegulator role that calculates the time elapsed since the last event was produced. If this time is shorter than the current event production rate, then a delay is inserted prior to sending the event. Fig. 13 shows the definition of the FlowRegulator role. In spite of the functionality provided by the roles appliance, to produce the desired result we also need to establish new connections using the added ports. Therefore, to conclude our example we define a flow synchronization protocol as illustrated in Fig. 14. This protocol creates an object with the sync operation used to synchronize two components by applying the previously presented roles and establishing the required connections between the modified components. LuaCCM provides simplifications to handle component ports as object fields as shown on sync operation. Those simplifications hide part of CCM complexity related to connection of ports. 5 Related Work Several works address the problem of modifying computer systems at runtime [3]. However most of the mechanisms proposed in literature are aimed at coarsegrained adaptations through the use of reconfigurations using different approaches,

14 1 FlowWatcher = loaf. Role { 2 provides = { 3 limit = { 4 interface = " eventflow :: flowsync :: Limited ", 5 code = [[ { value = 0.05 } ]], 6 }, 7 }, 8 uses = { 9 regulator = { interface = " eventflow :: flowsync :: Rateable "}, 10 }, 11 before = { 12 raw = { 13 code = [[ 14 function ( self, request ) 15 request. start_ time = get_ time () 16 end 17 ]], 18 }, 19 }, 20 after = { 21 raw = { 22 code = [[ 23 function ( self, request ) 24 local now = get_ time () 25 local time_ spent = now - ( request. start_ time or now ) 26 local limit = request. context : get_ executor (" limit ") 27 if time_ spent > limit. value then 28 local regulator = request. context : get_ connection_ regulator () 29 if regulator then regulator : set_ rate ( time_ spent ) end 30 end 31 end 32 ]], 33 }, 34 }, 35 } Fig. 12. FlowWatcher role definition.

15 1 FlowRegulator = loaf. Role { 2 before = { 3 produced = { 4 code = [[ 5 function ( self, request ) 6 local now = get_ time () 7 local last = self. last or now 8 self. last = now 9 local time_ spent = now - last 10 if request. context. rate and 11 time_ spent < request. context. rate then 12 sleep ( request. context. rate - time_ spent ) 13 end 14 end 15 ]], 16 }, 17 }, 18 provides = { 19 rater = { 20 interface = " eventflow :: flowsync :: Rateable ", 21 code = [[{ 22 set_ rate = function ( self, rate ) 23 self. context. rate = rate 24 end, 25 }]], 26 }, 27 }, 28 } Fig. 13. FlowRegulator role definition. 1 FlowSyncProtocol = { 2 sync = function ( self, server, client ) 3 FlowRegulator : assign ( server ) 4 FlowWatcher : assign ( client ) 5 client. regulator = server. rater 6 end, 7 unsync = function ( self, server, client ) 8 client. regulator = nil 9 FlowRegulator : unassign ( server ) 10 FlowWatcher : unassign ( client ) 11 end, 12 } Fig. 14. Flow synchronization protocol definition.

16 as for instance the ones discussed in [15]. Our group have been investigating different dynamic adaptation techniques based on the features provided by interpreted languages. In that sense, using the features of the Lua language, we have proposed many platforms and architectures using different approaches to perform dynamic adaptations, such as LuaOrb [9] that provides a dynamic binding for CORBA that can be used to perform fine-grained adaptations on CORBA objects [16]; ALua [10], an event-based asynchronous platform for parallel applications that allows dynamic definition of code to be executed on different computing nodes; and LuaTS [12], a reactive event-driven tuple space. Similarly, other works use the features of the Lua language to perform reconfigurations, like LuaSpace [11], that provides features that add flexibility to perform reconfiguration of CORBA-based applications. The architecture for self-adaptive CORBA based applications proposed in [13] provides mechanisms to start reconfigurations based on monitoring facilities. Other groups have also proposed infrastructures to perform fine-grained adaptations, like the Lasagne model presented in [17] that uses additional information inserted on component requests to dynamically select different adaptations on system components by selection of wrappers that intercept component interactions. Every collaboration started by a new client request defines the set of wrappers that must be applied to the component prior to handling request properly. Differently from the LuaCCM model, Lasagne provides means to consistently apply adaptations over a distributed environment, as well as to maintain different client-specific views of the performed changes. Still on the subject of fine-grained adaptations, [5] points out the necessity of abstractions for such adaptations by the proposition of the protocol and roles abstractions to describe dynamic adaptation of applications developed using the Comet asynchronous event-based middleware. Our work uses the LuaCCM features to provide the same abstractions for CCM applications with a complexity compatible to the original approach on Comet middleware, validating the applicability of those abstractions on more complex component models. By adopting a layered approach, we hope to be able to provide a range of abstractions built on LuaCCM, instead of focusing only on one specific adaptation abstraction. 6 Final Remarks In the past we have explored the flexibility that the use of an interpreted, dynamically-typed language can bring to component-based programming. We believe that the work in this paper goes one step further in this direction. On one hand, we discussed how Lua (or an alternative language with similar features) allows simple adaptation abstractions to be built on top of a standard model for component management and configuration. On the other, we showed that component models themselves can be more flexible and admit more powerful adaptation mechanisms when designed with such a language. The basic LuaCCM features, inherited directly from CCM, allow for coarse-grained adaptation, providing mechanisms for application reconfiguration through the definition of new

17 connections. With dynamic containers and reflective components, we gain the possibility of fine-grained adaptation, through changes on component definition and implementation. Such adaptations are important to add more flexibility prior to better adapt the system in face of requirement changes not predicted on its original design. In this work we explored only the protocols and roles abstractions. However, we intend to implement other adaptation abstractions with similar purposes, such as the idea of dynamic contracts based on the coordination-oriented approach proposed in [18]. A contract defines the computation related to coordination of interactions between system components, which is merged into component implementation prior to result in a coordinated group of components. We intend to use the fine-grained adaptations mechanisms of LuaCCM to provide means to specify and change contract definition at runtime. Alternatively, we plan to investigate the use of aspect-oriented abstractions that can be implemented using the interception facilities of LuaCCM components and may be useful to define and adapt crosscutting concerns of component-based systems. We believe the mapping of these abstractions to LuaCCM will be easy, and will enable us to experiment with coordination, aspects and other abstractions in component-based applications. The use of a C++ ORB in the implementation of LuaOrb provides means of reducing performance problems due to the use of an interpreted language like Lua. Additionally, Lua presents good performance results if compared with other scripting languages [19]. However, we intend to provide performance comparisons of LuaCCM with other CCM implementations, like MICO and OpenCCM. We would specifically like to study adaptations that need some type of atomicity. One example is that of adaptations spanning different containers. Although it is possible to apply a sequence of modifications over different containers, there is no guarantee of atomicity: it is possible that client applications see inconsistent states where only some of the containers have been modified. Another example is that of a sequence of modifications over one same container that should be viewed as a single adaptation step. We intend to study the requirements of these adaptations and eventually include new mechanisms to support them in LuaCCM. Finally, we believe that the features provided by LuaCCM compose an appropriate environment for experimentation on dynamic adaptation, especially on evaluation of different approaches considering aspects like simplicity or applicability. References 1. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, Boston, USA (1994) 2. Gouveia, J., Koutsoukos, G., Andrade, L., Fiadeiro, J.: Tool support for coordination-based software evolution. In Pree, W., ed.: Proceedings of TOOLS Europe 2001, Zurich, Switzerland, IEEE Press (2001)

18 3. Liu, X., Yang, H., eds.: Proceedings of the International Symposium on Principles of Software Evolution 2000, Kanazawa, Japan, IEEE Press (2000) 4. Ierusalimschy, R., Figueiredo, L.H., Celes, W.: Lua an extensible extension language. Software: Practice and Experience 26 (1996) Peschanski, F., Briot, J.P., Yonezawa, A.: Fine-grained dynamic adaptation of distributed components. In Endler, M., Schmidt, D., eds.: Proceedings of Middleware Volume 2672 of Lecture Notes in Computer Science., Rio de Janeiro, Brazil, Springer-Verlag (2003) Object Management Group Needham, USA: CORBA Component Model - Version 3.0. (2002) document: formal/ Wang, N., Schmidt, D.C., O Ryan, C.: An overview of the CORBA component model. In Heineman, G., Councill, B., eds.: Component-Based Software Engineering. Addison-Wesley Professional, Boston, USA (2000) 8. Stein, L.A., Lieberman, H., Ungar, D.: A shared view of sharing: The Treaty of Orlando. In Kim, W., Lochovsky, F.H., eds.: Object-Oriented Concepts, Databases and Applications. ACM Press/Addison-Wesley, Boston, USA (1989) Cerqueira, R., Cassino, C., Ierusalimschy, R.: Dynamic component gluing across different componentware systems. In: Proceedings of DOA 99, Edinburgh, Scotland, IEEE Press (1999) Ururahy, C., Rodriguez, N., Ierusalimschy, R.: ALua: Flexibility for parallel programming. Computer Languages 28 (2002) Batista, T., Rodriguez, N.: Dynamic reconfiguration of component-based applications. In: Proceedings of PDSE 2000, Limerick, Ireland, IEEE Press (2000) Leal, M., Rodriguez, N., Ierusalimschy, R.: LuaTS - a reactive event-driven tuple space. Journal of Universal Computer Science 9 (2003) Moura, A.L., Ururahy, C., Cerqueira, R., Rodriguez, N.: Dynamic support for distributed auto-adaptive applications. In Wagner, R., ed.: Proceedings of ICDCS 2002, Vienna, Austria, IEEE Press (2002) Demers, F.N., Malenfant, J.: Reflection in logic, functional and object-oriented programming: a short comparative study. In: Proceedings of Workshop on Reflection and Metalevel Architectures and their Applications in AI (IJCAI 95), Montreal, Canada, IJCAII/AAAI/CSCSI, Morgan Kaufmann (1995) Tosic, V., Pagurek, B., Esfandiari, B., Patel, K.: On various approaches to dynamic adaptation of distributed component compositions. Technical Report OCIECE-02-02, Ottawa-Carleton Institute for Electrical and Computer Engineering (OCIECE), Ottawa, Canada (2002) 16. Martins, M.C., Rodriguez, N., Ierusalimschy, R.: Dynamic extension of CORBA servers. In Amestoy, P., Berger, P., Daydé, M., Duff, I., Frayssé, V., Giraud, L., Ruiz, D., eds.: Proceedings of Euro-Par 99. Volume 1685 of Lecture Notes in Computer Science., Toulouse, France, Springer-Verlag (1999) Truyen, E., Vanhaute, B., Jørgensen, B.N., Joosen, W., Verbaeton, P.: Dynamic and selective combination of extensions in component-based applications. In: Proceedings of ICSE 2001, Toronto, Canada (2001) Andrade, L.F., Fiadeiro, J.L.: Coordination: The evolutionary dimension. In Pree, W., ed.: Proceedings of TOOLS Europe 2001, Zurich, Switzerland, IEEE Press (2001) Calpini, A.: Computer language shootout. (2003)

A Management Tool for Component-Based Real-Time Supervision and Control Systems

A Management Tool for Component-Based Real-Time Supervision and Control Systems A Management Tool for Component-Based Real-Time Supervision and Control Systems Sandro Santos Andrade, Raimundo José de Araújo Macêdo Distributed Systems Laboratory (LaSiD) Post-Graduation Program on Mechatronics

More information

Dynamic Adaptability of Services in Enterprise JavaBeans Architecture

Dynamic Adaptability of Services in Enterprise JavaBeans Architecture 1. Introduction Dynamic Adaptability of Services in Enterprise JavaBeans Architecture Zahi Jarir *, Pierre-Charles David **, Thomas Ledoux ** zahijarir@ucam.ac.ma, {pcdavid, ledoux}@emn.fr (*) Faculté

More information

CORBAservices. Naming. Part of the CORBA Naming Service Interface in IDL. CORBA Naming Service

CORBAservices. Naming. Part of the CORBA Naming Service Interface in IDL. CORBA Naming Service CORBAservices CORBAservices are general purpose and application independent services. They resemble and enhance services commonly provided by an operating system: Service Collection Query Concurrency Transaction

More information

Limitations of Object-Based Middleware. Components in CORBA. The CORBA Component Model. CORBA Component

Limitations of Object-Based Middleware. Components in CORBA. The CORBA Component Model. CORBA Component Limitations of Object-Based Middleware Object-Oriented programming is a standardised technique, but Lack of defined interfaces between objects It is hard to specify dependencies between objects Internal

More information

Patterns in. Lecture 2 GoF Design Patterns Creational. Sharif University of Technology. Department of Computer Engineering

Patterns in. Lecture 2 GoF Design Patterns Creational. Sharif University of Technology. Department of Computer Engineering Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 2 GoF Design Patterns Creational 1 GoF Design Patterns Principles Emphasis on flexibility and reuse through decoupling of classes. The underlying

More information

SOFT 437. Software Performance Analysis. Ch 5:Web Applications and Other Distributed Systems

SOFT 437. Software Performance Analysis. Ch 5:Web Applications and Other Distributed Systems SOFT 437 Software Performance Analysis Ch 5:Web Applications and Other Distributed Systems Outline Overview of Web applications, distributed object technologies, and the important considerations for SPE

More information

A Reusability Concept for Process Automation Software

A Reusability Concept for Process Automation Software A Reusability Concept for Process Automation Software Wolfgang Narzt, Josef Pichler, Klaus Pirklbauer, Martin Zwinz Business Information Systems C. Doppler Laboratory for Software Engineering University

More information

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g Systems Integration: Component-based software engineering Objectives To explain that CBSE is concerned with developing standardised components and composing these into applications To describe components

More information

Generating Aspect Code from UML Models

Generating Aspect Code from UML Models Generating Aspect Code from UML Models Iris Groher Siemens AG, CT SE 2 Otto-Hahn-Ring 6 81739 Munich, Germany Iris.Groher@fh-hagenberg.at Stefan Schulze Siemens AG, CT SE 2 Otto-Hahn-Ring 6 81739 Munich,

More information

The Advantages of Using NCL 2.3

The Advantages of Using NCL 2.3 MAESTRO: The Declarative Middleware Proposal for the SBTVD TeleMidia Laboratory PUC-Rio R. Marquês de São Vicente, 225 Rio de Janeiro 22453-900 Brazil lfgs@inf.puc-rio.br ACM, (2006). This is the author's

More information

CoSMIC: An MDA Tool Suite for Application Deployment and Configuration

CoSMIC: An MDA Tool Suite for Application Deployment and Configuration CoSMIC: An MDA Tool Suite for Application Deployment and Configuration Tao Lu, Emre Turkay, Aniruddha Gokhale*, Douglas Schmidt Institute for Software Integrated Systems Vanderbilt University, Nashville

More information

An Overview of CORBA-Based Load Balancing

An Overview of CORBA-Based Load Balancing An Overview of CORBA-Based Load Balancing Jian Shu, Linlan Liu, Shaowen Song, Member, IEEE Department of Computer Science Nanchang Institute of Aero-Technology,Nanchang, Jiangxi, P.R.China 330034 dylan_cn@yahoo.com

More information

Model Driven Development of Inventory Tracking System*

Model Driven Development of Inventory Tracking System* Model Driven Development of Inventory Tracking System* Gan Deng, Tao Lu, Emre Turkay Andrey Nechypurenko Aniruddha Gokhale, Douglas Schmidt ISIS, Vanderbilt University Siemens Nashville, TN 37221 Germany

More information

Run-time Variability Issues in Software Product Lines

Run-time Variability Issues in Software Product Lines Run-time Variability Issues in Software Product Lines Alexandre Bragança 1 and Ricardo J. Machado 2 1 Dep. I&D, I2S Informática Sistemas e Serviços SA, Porto, Portugal, alexandre.braganca@i2s.pt 2 Dep.

More information

Overview of the CORBA Component Model. Wang, Schmidt, O Ryan

Overview of the CORBA Component Model. Wang, Schmidt, O Ryan Overview of the CORBA Model Wang, Schmidt, O Ryan Section VI Other Author(s) Nanbor Wang, Douglas C. Schmidt, and Carlos O Ryan Chapter 38 E-mail Address nanbor@cs.wustl.edu, schmidt@uci.edu, coryan@cs.wustl.edu

More information

Service Oriented Architecture (SOA) An Introduction

Service Oriented Architecture (SOA) An Introduction Oriented Architecture (SOA) An Introduction Application Evolution Time Oriented Applications Monolithic Applications Mainframe Client / Server Distributed Applications DCE/RPC CORBA DCOM EJB s Messages

More information

An Object Model for Business Applications

An Object Model for Business Applications An Object Model for Business Applications By Fred A. Cummins Electronic Data Systems Troy, Michigan cummins@ae.eds.com ## ## This presentation will focus on defining a model for objects--a generalized

More information

Monitoring Infrastructure (MIS) Software Architecture Document. Version 1.1

Monitoring Infrastructure (MIS) Software Architecture Document. Version 1.1 Monitoring Infrastructure (MIS) Software Architecture Document Version 1.1 Revision History Date Version Description Author 28-9-2004 1.0 Created Peter Fennema 8-10-2004 1.1 Processed review comments Peter

More information

DESIGN AND IMPLEMENTATION

DESIGN AND IMPLEMENTATION Building a Persistent Object Store using the Java Reflection API Arthur H. Lee and Ho-Yun Shin Programming Systems Laboratory Department of Computer Science Korea University Seoul, Korea +82-2-3290-3196

More information

A CORBA Component. Component runtime support. A CORBA Component Home Home interface. Component Home. Väliohjelmistot 2003 15/04/2004

A CORBA Component. Component runtime support. A CORBA Component Home Home interface. Component Home. Väliohjelmistot 2003 15/04/2004 -komponenttimalli CCM Komponenttiväliohjelmistot Model (CCM) jatkoa korjatulla esitysjärjestyksellä abstrakti komponenttimalli komponenttien suoritusaikainen ympäristö container programming model komponenttien

More information

New Methods for Performance Monitoring of J2EE Application Servers

New Methods for Performance Monitoring of J2EE Application Servers New Methods for Performance Monitoring of J2EE Application Servers Adrian Mos (Researcher) & John Murphy (Lecturer) Performance Engineering Laboratory, School of Electronic Engineering, Dublin City University,

More information

How To Guarantee A Service In A Distributed Real Time System

How To Guarantee A Service In A Distributed Real Time System Dynamic Guarantee in Component-Based Distributed Real-Time Systems Cssia Yuri Tatibana Romulo Silva de Oliveira* Carlos Montez Departamento de Automao e Sistemas Universidade Federal de Santa Catarina

More information

COORDINATION CONTRACTS AS CONNECTORS IN COMPONENT-BASED DEVELOPMENT

COORDINATION CONTRACTS AS CONNECTORS IN COMPONENT-BASED DEVELOPMENT Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 2002 Society for Design and Process Science COORDINATION CONTRACTS AS CONNECTORS IN COMPONENT-BASED

More information

ARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS

ARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS ARCHITECTURAL DESIGN OF MODERN WEB APPLICATIONS Lech MADEYSKI *, Michał STOCHMIAŁEK Abstract. Architectural design is about decisions which influence characteristics of arising system e.g. maintainability

More information

Infrastructure that supports (distributed) componentbased application development

Infrastructure that supports (distributed) componentbased application development Middleware Technologies 1 What is Middleware? Infrastructure that supports (distributed) componentbased application development a.k.a. distributed component platforms mechanisms to enable component communication

More information

Verifying Semantic of System Composition for an Aspect-Oriented Approach

Verifying Semantic of System Composition for an Aspect-Oriented Approach 2012 International Conference on System Engineering and Modeling (ICSEM 2012) IPCSIT vol. 34 (2012) (2012) IACSIT Press, Singapore Verifying Semantic of System Composition for an Aspect-Oriented Approach

More information

The Advantages of CorBA For Network Based Training Systems

The Advantages of CorBA For Network Based Training Systems Support of multimedia services for distributed network training applications in CORBA-3 Fausto Rabitti CNUCE-CNR, Via S. Maria, 36, Pisa, Italy Abstract In this paper, fundamental technological issues

More information

Composing Concerns with a Framework Approach

Composing Concerns with a Framework Approach Composing Concerns with a Framework Approach Constantinos A. Constantinides 1,2 and Tzilla Elrad 2 1 Mathematical and Computer Sciences Department Loyola University Chicago cac@cs.luc.edu 2 Concurrent

More information

BPMN by example. Bizagi Suite. Copyright 2014 Bizagi

BPMN by example. Bizagi Suite. Copyright 2014 Bizagi BPMN by example Bizagi Suite Recruitment and Selection 1 Table of Contents Scope... 2 BPMN 2.0 Business Process Modeling Notation... 2 Why Is It Important To Model With Bpmn?... 2 Introduction to BPMN...

More information

Useful Patterns for BPEL Developers

Useful Patterns for BPEL Developers Central Page 457 of 493 Useful Patterns for BPEL Developers Darko Andročec, Dragutin Kermek Faculty of Organization and Informatics University of Zagreb Pavlinska 2, 42000 {darko.androcec, dragutin.kermek}@foi.hr

More information

OpenCCM : une infrastructure à composants pour le déploiement d'applications à base de composants CORBA

OpenCCM : une infrastructure à composants pour le déploiement d'applications à base de composants CORBA 1 OpenCCM : une infrastructure à composants pour le déploiement d'applications à base de composants CORBA Frédéric BRICLET Christophe CONTRERAS Philippe MERLE openccm@objectweb.org Project INRIA Jacquard

More information

Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS

Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS In order to ease the burden of application lifecycle management,

More information

A Framework for Automatic Performance Monitoring, Analysis and Optimisation of Component Based Software Systems

A Framework for Automatic Performance Monitoring, Analysis and Optimisation of Component Based Software Systems A Framework for Automatic Performance Monitoring, Analysis and Optimisation of Component Based Software Systems Ada Diaconescu *, John Murphy ** Performance Engineering Laboratory Dublin City University,

More information

Design Patterns. Design patterns are known solutions for common problems. Design patterns give us a system of names and ideas for common problems.

Design Patterns. Design patterns are known solutions for common problems. Design patterns give us a system of names and ideas for common problems. Design Patterns Design patterns are known solutions for common problems. Design patterns give us a system of names and ideas for common problems. What are the major description parts? Design Patterns Descriptions

More information

GenericServ, a Generic Server for Web Application Development

GenericServ, a Generic Server for Web Application Development EurAsia-ICT 2002, Shiraz-Iran, 29-31 Oct. GenericServ, a Generic Server for Web Application Development Samar TAWBI PHD student tawbi@irit.fr Bilal CHEBARO Assistant professor bchebaro@ul.edu.lb Abstract

More information

PERFORMANCE MONITORING OF JAVA COMPONENT-ORIENTED DISTRIBUTED APPLICATIONS

PERFORMANCE MONITORING OF JAVA COMPONENT-ORIENTED DISTRIBUTED APPLICATIONS PERFORMANCE MONITORING OF JAVA COMPONENT-ORIENTED DISTRIBUTED APPLICATIONS Adrian Mos, John Murphy Performance Engineering Lab, Dublin City University Glasnevin, Dublin 9, Ireland Tel: +353 1 700-8762,

More information

Framework Development for Large Systems

Framework Development for Large Systems Framework Development for Large Systems Dirk Bäumer 1, Guido Gryczan 2, Rolf Knoll 3, Carola Lilienthal 2, Dirk Riehle 4, and Heinz Züllighoven 2 Abstract Frameworks are a key asset in large-scale object-oriented

More information

Model Transformations and Code Generation

Model Transformations and Code Generation Model Transformations and Code Generation Ecole IN2P3 Temps Réel Ansgar.Radermacher@cea.fr 2 École d été, 26.11 08h30 10h00: Cours S1 Component models CCM and FCM (connectors) CCM CORBA component model

More information

Towards automated software component configuration and deployment

Towards automated software component configuration and deployment Towards automated software component configuration and deployment Vincent Lestideau, Noureddine Belkhatir, Pierre-Yves Cunin Adele Team Bat C LSR-IMAG, 220 rue de la chimie Domaine Universitaire, BP 53

More information

Excerpts from Chapter 4, Architectural Modeling -- UML for Mere Mortals by Eric J. Naiburg and Robert A. Maksimchuk

Excerpts from Chapter 4, Architectural Modeling -- UML for Mere Mortals by Eric J. Naiburg and Robert A. Maksimchuk Excerpts from Chapter 4, Architectural Modeling -- UML for Mere Mortals by Eric J. Naiburg and Robert A. Maksimchuk Physical Architecture As stated earlier, architecture can be defined at both a logical

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2007 Vol. 6, No. 1, January-February 2007 CM Configuration Change Management John D.

More information

The Service Revolution software engineering without programming languages

The Service Revolution software engineering without programming languages The Service Revolution software engineering without programming languages Gustavo Alonso Institute for Pervasive Computing Department of Computer Science Swiss Federal Institute of Technology (ETH Zurich)

More information

Java Application Developer Certificate Program Competencies

Java Application Developer Certificate Program Competencies Java Application Developer Certificate Program Competencies After completing the following units, you will be able to: Basic Programming Logic Explain the steps involved in the program development cycle

More information

A Web-Based Real-Time Traffic Monitoring Scheme Using CORBA

A Web-Based Real-Time Traffic Monitoring Scheme Using CORBA A Web-Based Real-Time Traffic Monitoring Scheme Using CORBA Yuming Jiang, Chen-Khong Tham, Chi-Chung Ko Department of Electrical Engineering, National University of Singapore, 10 Kent Ridge Crescent, Singapore

More information

CORBA Component Model(CCM)

CORBA Component Model(CCM) CORBA Model 1 of 19 CORBA Model(CCM) Technology for building enterprise-level applications Contents 2 of 19 Overview of CORBA Model CCM Deployment Model K2 Server Copyright 2000-02 Internet Management

More information

International Journal of Web & Semantic Technology (IJWesT) Vol.3, No.3, July 2012. Vishnuvardhan Mannava 1 and T. Ramesh 2

International Journal of Web & Semantic Technology (IJWesT) Vol.3, No.3, July 2012. Vishnuvardhan Mannava 1 and T. Ramesh 2 COMPOSITE DESIGN PATTERN FOR FEATURE- ORIENTED SERVICE INJECTION AND COMPOSITION OF WEB SERVICES FOR DISTRIBUTED COMPUTING SYSTEMS WITH SERVICE ORIENTED ARCHITECTURE Vishnuvardhan Mannava 1 and T. Ramesh

More information

System types. Distributed systems

System types. Distributed systems System types 1 Personal systems that are designed to run on a personal computer or workstation Distributed systems where the system software runs on a loosely integrated group of cooperating processors

More information

Overview of CORBA 11.1 I NTRODUCTION TO CORBA. 11.4 Object services 11.5 New features in CORBA 3.0 11.6 Summary

Overview of CORBA 11.1 I NTRODUCTION TO CORBA. 11.4 Object services 11.5 New features in CORBA 3.0 11.6 Summary C H A P T E R 1 1 Overview of CORBA 11.1 Introduction to CORBA 11.2 CORBA architecture 11.3 Client and object implementations 11.4 Object services 11.5 New features in CORBA 3.0 11.6 Summary In previous

More information

Distributed Objects and Components

Distributed Objects and Components Distributed Objects and Components Introduction This essay will identify the differences between objects and components and what it means for a component to be distributed. It will also examine the Java

More information

Distributed Network Management Using SNMP, Java, WWW and CORBA

Distributed Network Management Using SNMP, Java, WWW and CORBA Distributed Network Management Using SNMP, Java, WWW and CORBA André Marcheto Augusto Hack Augusto Pacheco Augusto Verzbickas ADMINISTRATION AND MANAGEMENT OF COMPUTER NETWORKS - INE5619 Federal University

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

Service-Oriented Architectures

Service-Oriented Architectures Architectures Computing & 2009-11-06 Architectures Computing & SERVICE-ORIENTED COMPUTING (SOC) A new computing paradigm revolving around the concept of software as a service Assumes that entire systems

More information

Coordinated Visualization of Aspect-Oriented Programs

Coordinated Visualization of Aspect-Oriented Programs Coordinated Visualization of Aspect-Oriented Programs Álvaro F. d Arce 1, Rogério E. Garcia 1, Ronaldo C. M. Correia 1 1 Faculdade de Ciências e Tecnologia Universidade Estadual Paulista Júlio de Mesquita

More information

Software Architecture & Composition. Guillaume Waignier, Anne-Françoise Le Meur, Laurence Duchien Project-Team U. Lille 1/CNRS-INRIA

Software Architecture & Composition. Guillaume Waignier, Anne-Françoise Le Meur, Laurence Duchien Project-Team U. Lille 1/CNRS-INRIA 1 Software Architecture & Composition Guillaume Waignier, Anne-Françoise Le Meur, Laurence Duchien Project-Team U. Lille 1/CNRS-INRIA http://adam.lille.inria.fr April 2009 2 Scientific context Future applications

More information

OpenCCM: The Open CORBA Components Platform

OpenCCM: The Open CORBA Components Platform OpenCCM: The Open CORBA Components Platform 3rd ObjectWeb Conference 20th November 2003, INRIA Rocquencourt, France Philippe Merle INRIA Futurs Lille Jacquard Project OpenCCM Project Leader www.objectweb.org

More information

Using Coordination Contracts for Evolving Business Rules

Using Coordination Contracts for Evolving Business Rules Using Coordination Contracts for Evolving Business Rules Michel Wermelinger Dep. de Informática Univ. Nova de Lisboa 2829-516 Caparica, Portugal mw@di.fct.unl.pt José Luiz Fiadeiro Dep. of Computer Science

More information

U III 5. networks & operating system o Several competing DOC standards OMG s CORBA, OpenDoc & Microsoft s ActiveX / DCOM. Object request broker (ORB)

U III 5. networks & operating system o Several competing DOC standards OMG s CORBA, OpenDoc & Microsoft s ActiveX / DCOM. Object request broker (ORB) U III 1 Design Processes Design Axioms Class Design Object Storage Object Interoperability Design Processes: - o During the design phase the classes identified in OOA must be revisited with a shift in

More information

Framework Development for Large Systems

Framework Development for Large Systems Framework Development for Large Systems Dirk Bäumer RWG Stuttgart Guido Gryczan University of Hamburg Vogt-Kölln-Str. 30 22527 Hamburg Germany Phone: +49-40-54 94-2302 Fax: +49-40-54 94-2303 Email:gryczan@informatik.uni-hamburg.de

More information

Module 17. Client-Server Software Development. Version 2 CSE IIT, Kharagpur

Module 17. Client-Server Software Development. Version 2 CSE IIT, Kharagpur Module 17 Client-Server Software Development Lesson 42 CORBA and COM/DCOM Specific Instructional Objectives At the end of this lesson the student would be able to: Explain what Common Object Request Broker

More information

Enabling Technologies for Web-Based Legacy System Integration

Enabling Technologies for Web-Based Legacy System Integration Enabling Technologies for Web-Based Legacy System Integration Ying Zou Kostas Kontogiannis University of Waterloo Dept. of Electrical & Computer Engineering Waterloo, ON, N2L 3G1 Canada Abstract With the

More information

A MODEL-BASED MONITORING ARCHITECTURE FOR HETEROGENEOUS ENTERPRISE SERVICES AND INFORMATION SYSTEMS

A MODEL-BASED MONITORING ARCHITECTURE FOR HETEROGENEOUS ENTERPRISE SERVICES AND INFORMATION SYSTEMS ISBN: 978-972-8939-47-2 2011 IADIS A MODEL-BASED MONITORING ARCHITECTURE FOR HETEROGENEOUS ENTERPRISE SERVICES AND INFORMATION SYSTEMS Félix Cuadrado, Rodrigo García-Carmona, Juan C. Dueñas and Álvaro

More information

Variable Base Interface

Variable Base Interface Chapter 6 Variable Base Interface 6.1 Introduction Finite element codes has been changed a lot during the evolution of the Finite Element Method, In its early times, finite element applications were developed

More information

Migrating Legacy Software Systems to CORBA based Distributed Environments through an Automatic Wrapper Generation Technique

Migrating Legacy Software Systems to CORBA based Distributed Environments through an Automatic Wrapper Generation Technique Migrating Legacy Software Systems to CORBA based Distributed Environments through an Automatic Wrapper Generation Technique Hyeon Soo Kim School of Comp. Eng. and Software Eng., Kum Oh National University

More information

Encapsulating Crosscutting Concerns in System Software

Encapsulating Crosscutting Concerns in System Software Encapsulating Crosscutting Concerns in System Software Christa Schwanninger, Egon Wuchner, Michael Kircher Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany {christa.schwanninger,egon.wuchner,michael.kircher}@siemens.com

More information

Patterns for Business Object Model Integration in Process-Driven and Service-Oriented Architectures

Patterns for Business Object Model Integration in Process-Driven and Service-Oriented Architectures Patterns for Business Object Model Integration in Process-Driven and Service-Oriented Architectures Carsten Hentrich IBM Business Consulting Services, SerCon GmbH c/o IBM Deutschland GmbH Hechtsheimer

More information

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT Cléver Ricardo Guareis de Farias, Marten van Sinderen and Luís Ferreira Pires Centre for Telematics and Information Technology (CTIT) PO Box

More information

Business-Driven Software Engineering Lecture 3 Foundations of Processes

Business-Driven Software Engineering Lecture 3 Foundations of Processes Business-Driven Software Engineering Lecture 3 Foundations of Processes Jochen Küster jku@zurich.ibm.com Agenda Introduction and Background Process Modeling Foundations Activities and Process Models Summary

More information

How To Write A Composition Engine In A Microsoft Ip System

How To Write A Composition Engine In A Microsoft Ip System Service composition in IMS using Java EE SIP servlet containers Torsten Dinsing, Göran AP Eriksson, Ioannis Fikouras, Kristoffer Gronowski, Roman Levenshteyn, Per Pettersson and Patrik Wiss The IP Multimedia

More information

Some Software Technologies for Resilient Computing

Some Software Technologies for Resilient Computing Some Software Technologies for Resilient Computing Jean-Charles FABRE OSD Conference, Tokyo, Japan, March 7, 2012 Resilient computing Resilience is defined as the persistence of dependability when facing

More information

On Dynamic Service Composition and Its Applicability to E-Business Software Systems

On Dynamic Service Composition and Its Applicability to E-Business Software Systems On Dynamic Service Composition and Its Applicability to E-Business Software Systems Vladimir Tosic 1, David Mennie 2, Bernard Pagurek 1 1 Department of Systems and Computer Engineering, Carleton University

More information

Service-Oriented Architecture and Software Engineering

Service-Oriented Architecture and Software Engineering -Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based

More information

A Methodological Approach to Domain Engineering for Software Variability Enhancement

A Methodological Approach to Domain Engineering for Software Variability Enhancement A Methodological Approach to Domain Engineering for Software Variability Enhancement Alexandre Bragança 1,2 and Ricardo J. Machado 3 1 Dep. I&D, I2S Informática Sistemas e Serviços SA, Porto, Portugal,

More information

KITES TECHNOLOGY COURSE MODULE (C, C++, DS)

KITES TECHNOLOGY COURSE MODULE (C, C++, DS) KITES TECHNOLOGY 360 Degree Solution www.kitestechnology.com/academy.php info@kitestechnology.com technologykites@gmail.com Contact: - 8961334776 9433759247 9830639522.NET JAVA WEB DESIGN PHP SQL, PL/SQL

More information

In: Proceedings of RECPAD 2002-12th Portuguese Conference on Pattern Recognition June 27th- 28th, 2002 Aveiro, Portugal

In: Proceedings of RECPAD 2002-12th Portuguese Conference on Pattern Recognition June 27th- 28th, 2002 Aveiro, Portugal Paper Title: Generic Framework for Video Analysis Authors: Luís Filipe Tavares INESC Porto lft@inescporto.pt Luís Teixeira INESC Porto, Universidade Católica Portuguesa lmt@inescporto.pt Luís Corte-Real

More information

A View Integration Approach to Dynamic Composition of Web Services

A View Integration Approach to Dynamic Composition of Web Services A View Integration Approach to Dynamic Composition of Web Services Snehal Thakkar, Craig A. Knoblock, and José Luis Ambite University of Southern California/ Information Sciences Institute 4676 Admiralty

More information

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme. Middleware. Chapter 8: Middleware

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme. Middleware. Chapter 8: Middleware Middleware 1 Middleware Lehrstuhl für Informatik 4 Middleware: Realisation of distributed accesses by suitable software infrastructure Hiding the complexity of the distributed system from the programmer

More information

Monitoring Extensions for Component-Based Distributed Software

Monitoring Extensions for Component-Based Distributed Software Monitoring Extensions for Component-Based Distributed Software Nikolay K. Diakov, Marten van Sinderen, Dick Quartel Centre for Telematics and Information Technology, University of Twente, The Netherlands

More information

irods and Metadata survey Version 0.1 Date March Abhijeet Kodgire akodgire@indiana.edu 25th

irods and Metadata survey Version 0.1 Date March Abhijeet Kodgire akodgire@indiana.edu 25th irods and Metadata survey Version 0.1 Date 25th March Purpose Survey of Status Complete Author Abhijeet Kodgire akodgire@indiana.edu Table of Contents 1 Abstract... 3 2 Categories and Subject Descriptors...

More information

PERFORMANCE COMPARISON OF COMMON OBJECT REQUEST BROKER ARCHITECTURE(CORBA) VS JAVA MESSAGING SERVICE(JMS) BY TEAM SCALABLE

PERFORMANCE COMPARISON OF COMMON OBJECT REQUEST BROKER ARCHITECTURE(CORBA) VS JAVA MESSAGING SERVICE(JMS) BY TEAM SCALABLE PERFORMANCE COMPARISON OF COMMON OBJECT REQUEST BROKER ARCHITECTURE(CORBA) VS JAVA MESSAGING SERVICE(JMS) BY TEAM SCALABLE TIGRAN HAKOBYAN SUJAL PATEL VANDANA MURALI INTRODUCTION Common Object Request

More information

Motivation Definitions EAI Architectures Elements Integration Technologies. Part I. EAI: Foundations, Concepts, and Architectures

Motivation Definitions EAI Architectures Elements Integration Technologies. Part I. EAI: Foundations, Concepts, and Architectures Part I EAI: Foundations, Concepts, and Architectures 5 Example: Mail-order Company Mail order Company IS Invoicing Windows, standard software IS Order Processing Linux, C++, Oracle IS Accounts Receivable

More information

Evaluating OO-CASE tools: OO research meets practice

Evaluating OO-CASE tools: OO research meets practice Evaluating OO-CASE tools: OO research meets practice Danny Greefhorst, Matthijs Maat, Rob Maijers {greefhorst, maat, maijers}@serc.nl Software Engineering Research Centre - SERC PO Box 424 3500 AK Utrecht

More information

SERENITY Pattern-based Software Development Life-Cycle

SERENITY Pattern-based Software Development Life-Cycle SERENITY Pattern-based Software Development Life-Cycle Francisco Sanchez-Cid, Antonio Maña Computer Science Department University of Malaga. Spain {cid, amg}@lcc.uma.es Abstract Most of current methodologies

More information

Introduction CORBA Distributed COM. Sections 9.1 & 9.2. Corba & DCOM. John P. Daigle. Department of Computer Science Georgia State University

Introduction CORBA Distributed COM. Sections 9.1 & 9.2. Corba & DCOM. John P. Daigle. Department of Computer Science Georgia State University Sections 9.1 & 9.2 Corba & DCOM John P. Daigle Department of Computer Science Georgia State University 05.16.06 Outline 1 Introduction 2 CORBA Overview Communication Processes Naming Other Design Concerns

More information

A Model for Component Based E-governance Software Systems

A Model for Component Based E-governance Software Systems A Model for Component Based E-governance Software Systems A.SHRABAN KUMAR 1, G.JAYARAO 2,B.SHANKAR NAYAK 3, KBKS. DURGA 4 A.ESWARA RAO 5 1,2,3,4 Associate Professor CSE, St.MARTIN S ENGINEERING COLLEGE,

More information

SOA Planning Guide. 2015 The Value Enablement Group, LLC. All rights reserved.

SOA Planning Guide. 2015 The Value Enablement Group, LLC. All rights reserved. SOA Planning Guide 1 Agenda q SOA Introduction q SOA Benefits q SOA Principles q SOA Framework q Governance q Measurement q Tools q Strategic (long term) View 2 Introduction to SOA q Service-oriented architecture

More information

A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus

A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus Karim M. Mahmoud 1,2 1 IBM, Egypt Branch Pyramids Heights Office Park, Giza, Egypt kmahmoud@eg.ibm.com 2 Computer

More information

What Is the Java TM 2 Platform, Enterprise Edition?

What Is the Java TM 2 Platform, Enterprise Edition? Page 1 de 9 What Is the Java TM 2 Platform, Enterprise Edition? This document provides an introduction to the features and benefits of the Java 2 platform, Enterprise Edition. Overview Enterprises today

More information

SCALABILITY AND AVAILABILITY

SCALABILITY AND AVAILABILITY SCALABILITY AND AVAILABILITY Real Systems must be Scalable fast enough to handle the expected load and grow easily when the load grows Available available enough of the time Scalable Scale-up increase

More information

Ontological Representations of Software Patterns

Ontological Representations of Software Patterns Ontological Representations of Software Patterns Jean-Marc Rosengard and Marian F. Ursu University of London http://w2.syronex.com/jmr/ Abstract. This paper 1 is based on and advocates the trend in software

More information

SODDA A SERVICE-ORIENTED DISTRIBUTED DATABASE ARCHITECTURE

SODDA A SERVICE-ORIENTED DISTRIBUTED DATABASE ARCHITECTURE SODDA A SERVICE-ORIENTED DISTRIBUTED DATABASE ARCHITECTURE Breno Mansur Rabelo Centro EData Universidade do Estado de Minas Gerais, Belo Horizonte, MG, Brazil breno.mansur@uemg.br Clodoveu Augusto Davis

More information

Component Based Software Engineering: A Broad Based Model is Needed

Component Based Software Engineering: A Broad Based Model is Needed Component Based Software Engineering: A Broad Based Model is Needed Allen Parrish (parrish@cs.ua.edu) Brandon Dixon (dixon@cs.ua.edu) David Hale (dhale@alston.cba.ua.edu) Department of Computer Science

More information

Dynamic Scheduling of Object Invocations in Distributed Object Oriented Real-Time Systems Jørgensen, Bo Nørregaard; Joosen, Wouter

Dynamic Scheduling of Object Invocations in Distributed Object Oriented Real-Time Systems Jørgensen, Bo Nørregaard; Joosen, Wouter Syddansk Universitet Dynamic Scheduling of Object Invocations in Distributed Object Oriented Real-Time Systems Jørgensen, Bo Nørregaard; Joosen, Wouter Published in: Lecture Notes in Computer Science Publication

More information

zen Platform technical white paper

zen Platform technical white paper zen Platform technical white paper The zen Platform as Strategic Business Platform The increasing use of application servers as standard paradigm for the development of business critical applications meant

More information

Software Visualization Tools for Component Reuse

Software Visualization Tools for Component Reuse Software Visualization Tools for Component Reuse Craig Anslow Stuart Marshall James Noble Robert Biddle 1 School of Mathematics, Statistics and Computer Science, Victoria University of Wellington, New

More information

Middleware support for the Internet of Things

Middleware support for the Internet of Things Middleware support for the Internet of Things Karl Aberer, Manfred Hauswirth, Ali Salehi School of Computer and Communication Sciences Ecole Polytechnique Fédérale de Lausanne (EPFL) CH-1015 Lausanne,

More information

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces Software Engineering, Lecture 4 Decomposition into suitable parts Cross cutting concerns Design patterns I will also give an example scenario that you are supposed to analyse and make synthesis from The

More information

A Framework of Model-Driven Web Application Testing

A Framework of Model-Driven Web Application Testing A Framework of Model-Driven Web Application Testing Nuo Li, Qin-qin Ma, Ji Wu, Mao-zhong Jin, Chao Liu Software Engineering Institute, School of Computer Science and Engineering, Beihang University, China

More information

Aspect-Oriented Programming

Aspect-Oriented Programming Aspect-Oriented Programming An Introduction to Aspect-Oriented Programming and AspectJ Niklas Påhlsson Department of Technology University of Kalmar S 391 82 Kalmar SWEDEN Topic Report for Software Engineering

More information

Integration of Application Business Logic and Business Rules with DSL and AOP

Integration of Application Business Logic and Business Rules with DSL and AOP Integration of Application Business Logic and Business Rules with DSL and AOP Bogumiła Hnatkowska and Krzysztof Kasprzyk Wroclaw University of Technology, Wyb. Wyspianskiego 27 50-370 Wroclaw, Poland Bogumila.Hnatkowska@pwr.wroc.pl

More information

VARIABILITY MODELING FOR CUSTOMIZABLE SAAS APPLICATIONS

VARIABILITY MODELING FOR CUSTOMIZABLE SAAS APPLICATIONS VARIABILITY MODELING FOR CUSTOMIZABLE SAAS APPLICATIONS Ashraf A. Shahin 1, 2 1 College of Computer and Information Sciences, Al Imam Mohammad Ibn Saud Islamic University (IMSIU) Riyadh, Kingdom of Saudi

More information