F. Plasil, D. Balek, and R. Janecek. Sofa/dcup: Architecture for component trading and dynamic updating. In Proceedings of the International Conference on Configurable Distributed Systems, page 43. IEEE Computer Society, 1998.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....relations is typically used [4] e.g. a summary use case) and how the Generic UC View models the include relation. Thus, there is no interpretation of the include relation in UML 2.0. 4. Pro cases as an instance of Generic UC View. In [16,17] we developed Pro cases, based on Behavior Protocols [20,1,18,22], as an instance of Generic UC View. Here, we very briefly describe how Pro cases interpret the Generic UC View. Basic concepts An agent is interpretation of entity; an agent S composed of agents A1. An forms the scope of these agents, connection of an agent interprets connection. A Pro case ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating, Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc., 1998

....finite sequences of atomic events, capturing the communication on the entity s connections (both internal and external) A regular 6 expression like notation is used to approximate the actual behavior of entities by regular languages. These concepts are applied to a hierarchical component model [18, 22]. As the behavior is formally defined and there are powerful operations upon the protocols and behavior (languages) decidable relations and operations exist ( compliant with, consent [1] which allow to decide on compatibility of two components (their specifications) We show, that (and how) the ....

....substitution, naturally acyclic) the subscenario preservation property is implied from the definition of pro cases. Whole picture behavior. Typically, only a single procase is used (as the representative of UM ) such a pro case is called the frame pro case (inspired by frame protocol in SOFA [20, 18]) The basic and parallel operators used in the behavior protocols notation can be advantageouslyemployed as the operations for use case expressions (the UEop set) thus assembling the behavior via use case expressions is natural here. Addressing consistency issues. Even though the variety of the ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating, Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc., 1998

....with the adaptation problem such as Dynamic Linking, Redundant Hardware and State Transfer. Other more recent approaches are presented in this section. 3.1. DCUP Many adaptation approaches associate to each component one or more managers to ensure the administration functionalities. In DCUP[2,3] (Dynamic Component UPdating) each component defines one component manager (CM) and one component builder (CB) that are responsible of managing the particular component. A component may have several implementation objects and or sub components that provide its functionality. A component is ....

F. Plasil , D. Balek, R. Janecek "SOFA/DCUP: Architecture for Component Trading and Dynamic Updating", Proceedings of ICCDS'98, Annapolis, Maryland, USA, IEEE CS Press, May 1998.

....and State Transfer. Other more recent approaches are presented in this section. These approaches are more specific to component based applications. 3.1. DCUP Many adaptation approaches associate to each component one or more managers to ensure the administration functionalities. In DCUP[2,3] (Dynamic Component UPdating) each component defines one component manager (CM) and one component builder (CB) that are responsible of managing the associated component. A component may have several implementation objects and or sub components that provide its functionality. A component is ....

F. Plasil , D. Balek, R. Janecek "SOFA/DCUP: Architecture for Component Trading and Dynamic Updating", Proceedings of ICCDS'98, Annapolis, Maryland, USA, IEEE CS Press, May 1998.

....The sequence diagram is depicted on Figure 16. 24 Figure 17 Structure of SGenerator 5 Case study (implementation in SOFA) 5. 1 Generator implementation As a proof of the concept, we made a Java implementation of the previously specified generation framework for the SOFA component system [26, 30]. For this generator we created two modules, which one implements the generation of connector builders and the other implements primitive element adaptions. These two modules allow to build the three pre defined SOFA connectors (CSProcCall, EventPassing and DataStream) 5.1.1 Connector generator ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating. In Proceedings of ICCDS `98, Annapolis, IEEE CS, 1998

....related to software components (Section 2.4) We conclude the chapter in Section 2.6 by summarizing the main issues identified throughout the chapter and we state the goals of the thesis to address these issues. 2. 1 Illustrating general concepts SOFA DCUP environment The SOFA project [44, 58] (Software Appliances) aims to create a distributed development and run time environment for component based software systems. It includes a component model with component specification language, a versioning model, and an environment for the deployment and running of software components. In the ....

....the CSProcCall connector frame in Figure 2 provides multiple cRole roles and requires a single sRole role. The architecture of the connector type contains a graph of primitive connector elements such as cInterceptor, stub, and skeleton. 2.1. 3 DCUP architecture DCUP (Dynamic Component UPdate [44]) implements dynamic updating of the SOFA components, i.e. replacing components at run time based on the clear separation of the levels of revealing architectural details by the frame and architecture pairs. A 2 Composition F Sub1 F Sub2 A Sub1 A Sub2 A Sub3 Implementation A 2 F Sub1 F ....

[Article contains additional citation context not shown here]

F. Plasil, D. Balek, R. Janecek, "SOFA/DCUP Architecture for Component Trading and Dynamic Updating," Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc. Press, 1998, pp. 43--52.

....finite sequences of atomic events, capturing the communication on the entity s connections (both internal and external) A regular expression like notation is used to approximate the actual behavior of entities by regular languages. These concepts are applied to a hierarchical 12 component model [17, 21]. As the behavior is formally defined and there are powerful operations upon the protocols and behavior (languages) decidable relations and operations exist ( compliant with, consent [1] which allow to decide on compatibility of two components (their specifications) We show, that (and how) the ....

....relation is defined as an inclusion of behavior protocol specifications (similar to macro substitution, naturally acyclic) Whole picture behavior. Typically, only a single pro case is used (as the representative ) such a pro case is called the frame pro case (inspired byframe protocol in SOFA [19, 17]) The basic and parallel operators used in the behavior protocols notation can be advantageously employed as the operations for use case expressions (the UEop set) thus assembling the behavior via use case expressions is natural here. Addressing consistency issues. Even though the varietyof the ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating, Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc. Press, 1998, pp. 43--52.

....uses analysis of di#erences in their specifications structured into traits of related declarations. 1 Introduction In the area of software components [17] a lot of e#ort has been put into the research of component specifications and their consistent composition [4] including the dynamic case [14, 10]. This lead to the adoption of industry architectures like the CORBA Component Model (CCM [11] JavaBeans [8] as well as to research systems like SOFA [14] However, the problem of determining compatibility of components has in our opinion received insu#cient attention. Imagine you would like ....

.... a lot of e#ort has been put into the research of component specifications and their consistent composition [4] including the dynamic case [14, 10] This lead to the adoption of industry architectures like the CORBA Component Model (CCM [11] JavaBeans [8] as well as to research systems like SOFA [14]. However, the problem of determining compatibility of components has in our opinion received insu#cient attention. Imagine you would like to use a better version of a component instead of the one you currently have. It would be best to just plug it in without writing any adaptation code, ....

[Article contains additional citation context not shown here]

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating. Proceedings of ICCDS 98, Annapolis, Maryland, USA. IEEE CS Press 1998.

....of software component technology [45] became a rapidly growing field. Several commercial systems are available or emerging, namely the JavaBeans technology by JavaSoft, Microsoft s Component Object Model, and the proposed CORBA Component model; research in the area is even more abundant ([30, 1, 39, 35]) While the important architectural issues such as component description languages [1, 39] connectors and even composition of component based applications [35, 8] are extensively researched, software configuration management (SCM) issues related to component technology especially versioning, ....

.... systems are available or emerging, namely the JavaBeans technology by JavaSoft, Microsoft s Component Object Model, and the proposed CORBA Component model; research in the area is even more abundant ( 30, 1, 39, 35] While the important architectural issues such as component description languages [1, 39], connectors and even composition of component based applications [35, 8] are extensively researched, software configuration management (SCM) issues related to component technology especially versioning, compatibility and ensuring consistency of the composed applications have received less ....

[Article contains additional citation context not shown here]

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating. Proceedings of ICCDS 98, Annapolis, Maryland, USA. IEEE CS Press 1998.

....with a component provider. In DCUP, these problems are addressed by a small set of abstractions with a clear separation of their functionality. The bases of the SOFA DCUP project were stated in #998 by publication of our paper SOFA DCUP: Architecture for Component Trading and Dynamic Updating [48] at the ICCDS 98 conference. Since that time, more than twenty papers, Ph.D. and master theses have been published within this project extending the basic framework with a support for specifying component behavior, connectors, a versioning schema, and transaction management. Work on the SOFA DCUP ....

....runtime environment for component instances and their respective homes. Several containers can be hosted by a single container server. Containers hide the complexity of the underlying system services such as the POA, transactions, persistence, security, etc. 2. 3 SOFA DCUP component model In SOFA [48], an application is viewed as a hierarchy of software components. Analogous with the classical concept of an object as an instance of a class, a software component is an instance of a component template. A component template is defined bya pair component frame, component architecture . A ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating. In Proceedings of ICCDS '98, Annapolis, IEEE CS, #998, pp. 43--52.

.... The scheme will be feasible to implement for a component model satisfying certain basic requirements (ADL based component descriptions, component composition, possibly behavior specifications) component models to be considered are CCM [7] Darwin [14] Wright [13] or the SOFA component model [1]. As a proof of the concept, a prototype implementation of key tools will be developed for SOFA [1, 4, 5] 3 Current Status Future Work Preliminary results have been obtained in analyzing update scenarios with respect to the component life cycle; these are presented in the Autonomous Points ....

.... (ADL based component descriptions, component composition, possibly behavior specifications) component models to be considered are CCM [7] Darwin [14] Wright [13] or the SOFA component model [1] As a proof of the concept, a prototype implementation of key tools will be developed for SOFA [1, 4, 5]. 3 Current Status Future Work Preliminary results have been obtained in analyzing update scenarios with respect to the component life cycle; these are presented in the Autonomous Points in Component Composition poster. Previous research was focused on enriching an ADL with support for ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS'98, May 4-6,

....of nested components) mentioned in the Section 3.1 is also related to the architecture model of the EJB. In this respect, an additional problem is the impossibility to declare a reference to a component instance in the deployment descriptor (it is similar to required interface concept used in SOFA [13]) it is implied by the original assumption of not allowing for component nesting (e.g. in the bank example, the tellers cannot share the same datastore) Another weakness is the number of interfaces EJB componentprovides componentoneinterface only. Thus, it is not possible to make the ....

....services has to be described. Modi cations are described in following sections. 4.1. 1 New component modes: There are a number of ways how to describe the behavior of a system fully independent on the implementation (e.g. plain english, CSP [10] behavioral protocols [11] nite state machines [13]) parametrization of the implementation of a system and source code. In this section we discuss possible ways of componenttype description. Semantic description of componentmode: As it is said, the best description is the source code. Butnoonegives the source code of a commercial software for ....

[Article contains additional citation context not shown here]

Plasil, F., Balek, D., Janecek, R., \SOFA/DCUP Architecture for ComponentTrading and DynamicUpdating.", In Proceedings of ICCDS `98, Annapolis, IEEE CS, 1998, pp. 43-52.

....components in the application component hierarchy should be allowed to postpone the selection of concrete component to a later stage in the component life cycle, we denote them as autonomous points. A proof of the concept realization of these principles exists for the SOFA component model [1]. 6. ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS'98, May 4-6, 1998, Annapolis, Maryland, USA, IEEE CS Press 1998

....is heading to software components used to build large software architectures (component architectures) A big problemis how to describe the software component and component architecture. There are projects that deal with that problem in different ways (Wright [4] C2 [5] Rapide [6] SOFA DCUP [7]) All approaches define a software component as reusable code and resources that provides its functionality to the runtime environment and require a functionality from the environment. The functionality is described by interfaces (set of methods or set of accepted and emitted events) and behavior ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating. In Proceedings of ICCDS '98, Annapolis, IEEE CS, 1998, pp. 43--52.

....this section. In Section 4, a discussion of and a comparison to other approaches are provided. Section 5 is devoted to a brief discussion of future inventions. Section 6 concludes the paper by summarizing the key achievements. 2 Component behavior specification 2. 1 Component model In SOFA ( 2] [3]) an application is built as a hierarchy of software components. Analogously with the concept of an object as an instance of a class, we introduce software component as an instance of component template. The template frame defines a set of individual interfaces that are provided or required by a ....

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating. In Proceedings of ICCDS '98, Annapolis, IEEE CS, 1998, pp. 43--52.

No context found.

F. Plasil, D. Balek, and R. Janecek. Sofa/dcup: Architecture for component trading and dynamic updating. Proceedings of ICCDS'98, Annapolis, Maryland, USA, IEEE CS Press, May 1998.

No context found.

F. Plasil, D. Balek, and R. Janecek. SOFA/DCUP: Architecture for component trading and dynamic updating. In Proceedings of International Conference on Configurable Distributed Systems, pages 35--42. IEEE CS Press, March 1998.

No context found.

Plasil, F., and D. Balek, R. Janecek. SOFA/DCUP Architecture for Component Trading and Dynamic Updating, In Proceedings of ICCDS '98, Annapolis, IEEE Computer Soc. (1998)

....belong to the classics , while CCM[13] and Fractal[4] are among the recent ones. Except for CCM, the higher level models support component nesting. To illustrate the basic idea common to all of these higher level models, we will use the SOFA component model elaborated in our research team [14,19,8]; intending to keep its description here as simple as possible, we refer the reader to [14] for details on the SOFA architecture description language CDL, connection names, etc. Typically, a component is similar to an object but features more interfaces to access the services it provides (provides ....

....for CCM, the higher level models support component nesting. To illustrate the basic idea common to all of these higher level models, we will use the SOFA component model elaborated in our research team [14,19,8] intending to keep its description here as simple as possible, we refer the reader to [14] for details on the SOFA architecture description language CDL, connection names, etc. Typically, a component is similar to an object but features more interfaces to access the services it provides (provides interfaces) and, moreover, it features Many component models do not distinguish among ....

[Article contains additional citation context not shown here]

F. Plasil, D. Balek, R. Janecek, "SOFA/DCUP Architecture for Component Trading and Dynamic Updating," Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc. Press, 1998, pp. 43--52.

....belong to the classics , while CCM[14] and Fraetall4] are among the recent ones. Except for CCM, the higher level models support component nesting. To illustrate the basic idea common to all of these higher level models, we will use the SOFA component model elaborated in our research team [ 15,20,9]; intending to keep its description here as simple as possible, we refer the reader to [ 15] for details on the SOFA architecture description language CDL, connection names, etc. Typically, a component is similar to an object but features more interfaces to access the services it provides ....

....CCM, the higher level models support component nesting. To illustrate the basic idea common to all of these higher level models, we will use the SOFA component model elaborated in our research team [ 15,20,9] intending to keep its description here as simple as possible, we refer the reader to [ 15] for details on the SOFA architecture description language CDL, connection names, etc. Typically, a component is similar to an object but features more interfaces to access the services it provides (provides interfaces) and, moreover, it features requires interfaces as abstractions to capture ....

[Article contains additional citation context not shown here]

F. Plasil, D. Balek, R. Janecek, "SOFA/DCUP Architecture for Component Trading and Dynamic Updating," Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc. Press, 1998, pp. 43-52.

....the cited benefits of ADL component systems and the lack of their practical employment leads us to believe that there are unresolved issues that prevent this employment. In order to investigate these issues, we have designed and implemented a runtime environment for the SOFA ADL component system [21] (SOFA environment) 2 Our chief goal in the design and implementation of the SOFA environment is to support development of transparently distributed applications. The development centers around a hierarchical description of the application architecture. This description is gradually refined ....

....nodes. The components that share a node are interconnected through linking and run in one address space. The components that run on di#erent nodes are interconnected through connectors. The SOFA environment describes the application architecture using the SOFA component definition language [10, 21] (SOFA CDL) SOFA CDL is mapped into C , which is used to implement the components. The connectors are built using CORBA [18] The SOFA environment also allows interfacing the application with GNOME [26] to provide user interface support. The choice of GNOME as a representative of a component ....

[Article contains additional citation context not shown here]

Plasil F., Balek D., Janecek R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS 1998, USA, 1998

No context found.

F. Plasil, D. Balek, and R. Janecek. Sofa/dcup: Architecture for component trading and dynamic updating. In Proceedings of the International Conference on Configurable Distributed Systems, page 43. IEEE Computer Society, 1998.

No context found.

F. Plasil, D. Balek, and R. Janecek, "Sofa/dcup: Architecture for component trading and dynamic updating," in Proceedings of the International Conference on Configurable Distributed Systems. IEEE Computer Society, 1998, p. 43.

No context found.

Plasil F, Balek D, Janecek R. SOFA/DCUP Architecture for Component Trading and Dynamic Updating. Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc. Press, 1998, pp. 43 52.

No context found.

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating, In Proceedings of ICCDS '98, Annapolis, IEEE CS, 1998

No context found.

Plasil, F., Balek, D., Janecek, R., SOFA/DCUP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS'98, Annapolis, Maryland, USA, IEEE CS Press, May 1998

No context found.

Plasil F, Balek D, Janecek R. SOFA/DCUP Architecture for Component Trading and Dynamic Updating. Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc. Press, 1998, pp. 43 52.

No context found.

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating, In Proceedings of ICCDS '98, Annapolis, IEEE Computer Soc. (1998)

No context found.

Plasil F, Balek D, Janecek R. SOFA/DCUP Architecture for Component Trading and Dynamic Updating. Proc. of the ICCDS '98, Annapolis, IEEE Comp. Soc. Press, 1998.

No context found.

Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating, Proceedings of the ICCDS '98, Annapolis, IEEE Computer Soc., 1998

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC