Hlavní menu

Nástroje

PremekBrada / ResearchComponentSubstitutability

View (print) - Edit page | Recent changes - Page history

Updated 05 April 2006, 14:39 by PremekBrada

PremekBrada.ResearchComponentSubstitutability History

Hide minor edits - Show changes to markup

05 April 2006, 14:39 by PremekBrada -
Changed lines 3-39 from:

See also ResearchPlan (summary).

The aim of this project is to investigate the root causes of the open issues defined in my Thesis and to research possible solutions, especially related to subtyping as a basis for substitutability. Its results should lead to important enhancements of contextual substitutability that will improve its suitability in practical situations (service lookup, component upgrades). Type-theoretical foundations will be considered, and implementation for industrially relevant frameworks used as practicality benchmark.

Current State of Research

Software components have been the topic of research and industrial use for the last decade, which lead to the commonly used definition summarised by Szyperski [szyperski98component]. However, neither the research nor the industrial practice have converged to a common component model which would follow the best practices and key research findings. This results in the current state where many non-cooperating frameworks exist in parallel. Moreover, externally available specifications of components, a key prerequisite for platform-independent interoperability, are used only by a minority of the frameworks [omg02components].

The situation is somehow better in web services [wsa04], a recent focus of research [fontoura03tspaces] and industry. Here, the components are loosely coupled and co-operate via the Internet, using XML-based protocols. This lead to the need of external, universally available component specifications, and industrially adopted standards such as WSDL [wsdl2core04] and UDDI [oasis02uddi3] exists for these.

Nevertheless, none of the industrial, and few of the research frameworks deal with issues beyond the simple specification of component service points and the wiring of components together. Safe component upgrades are among the key advanced issues in this respect [brada03thesis]. In the mid- and long-term, these issues will become important as the component-based applications will need to be maintained in operational state.

Details on the Core Issues

The first issue is exemplified by the JavaBeans? and Enterprise JavaBeans? component frameworks. Their components are distributed as .jar (Java archive) files which contain only their implementation in bytecode format. The manifest and/or deployment descriptor files, which the framework standards mandate to be present with the distributed component [sun01ejb], contain only rudimentary specification information. In particular, it does not define the types of the interface elements through which clients interact with the beans; this information has to be obtained from the component implementation.

The lack of type information in component specification leads to several problems (cf. [kent99uml-semantics]). One is the impossibility to reason precisely about its properties, for example to compare the interface with that of other components or to assess the impact of interface changes on component's clients. Another problem is the representation for modelling purposes, for example when the designer needs a simple visual representation of the component (like in the UML [omg01uml]) during component application design.

The second issue relates to the problem of safe upgrades, since above we argued they should be based on checking type substitutability of components (that is, of their interfaces). With external specifications, there is the danger that the typing rules differ between the specification language and the language(s) used to implement the specification [brada03thesis], e.g. IDL’s unsigned short type is represented by different types in Java and C languages. If subtyping-based substitutability assessment ignores these mismatches, its results are not reliable for safe upgrades.

Additionally, when components interoperate via the Internet they may experience the dynamic availability problem [cervantes03automating]. For example, an unforeseen loss of network connection would break access to some of component's required services. In such situation it is important to evaluate the type compatibility of substitute services available in the given component's context.

Approach Used

We envisage the work towards these goals will use two basic approaches. The first will be research into key industrial and research component frameworks and the underlying component models, to obtain the knowledge of language mappings, typing rules, variations in specification implementation, and finally of the architectural and availability properties of loosely coupled service components. The second approach will be to follow current research in these areas, mainly in terms of interface specifications, behavioural subtyping, substitutability and component/service architectures.

The work builds on a body of knowledge accommodated during previous research of the principal investigator, especially on his experiences in interface modelling and substitutability fields. For the extracted interface specifications, the ENT meta-model [brada02ent] will be used as the underlying scheme which allows efficient type-based comparisons. The contextual substitutability [brada02metadata] provides an efficient framework for evaluating candidate substitute components in the dynamic availability scenarios.

Target Technologies

We will have a look at the following related technologies and research projects:

  • "Enterprise JavaBeans?":http://java.sun.com/products/ejb/index.jsp - start at 2.1, extend into 3.0 (which is a completely different beast...)
  • WSDL
  • "Solution Installation":http://www.w3.org/Submission/2004/04/
to:

Moved to my research pages.

03 April 2006, 10:22 by PremekBrada -
Changed lines 3-4 from:

See also ResearchPlan2005 (summary).

to:

See also ResearchPlan (summary).

18 May 2005, 10:13 by PremekBrada -
Changed lines 1-2 from:

Background and Detailed Explanations on Component Substitutability Research Plans

to:

Component Substitutability Research Plans -- Background and Detailed Explanations

Changed line 25 from:

Approach and Scientific Results

to:

Approach Used

Deleted lines 30-38:

The following scientific outcomes are envisaged:

  • 1-2 work-in-progress papers per year, published as technical reports and/or presented at key workshops or smaller conferences;
  • 1-2 full papers per year, presenting the research results in items 3, 4 and 5 above.
  • A journal article on contextual substitutability, summing up its definition and a case study for EJB or WS.

For the workshop and conference papers, at least the following forums will be considered: WCOP, ECOOP, CBSE, ICSE, ESEC.

For the journal article, the following periodicals will be considered: CAI, Informatica, Kluwer Automated software engineering, Wiley Journal of Software Maintenance and Evolution or Software – Practice and Experience.

18 May 2005, 09:49 by PremekBrada -
Changed lines 1-49 from:
to:

Background and Detailed Explanations on Component Substitutability Research Plans

See also ResearchPlan2005 (summary).

The aim of this project is to investigate the root causes of the open issues defined in my Thesis and to research possible solutions, especially related to subtyping as a basis for substitutability. Its results should lead to important enhancements of contextual substitutability that will improve its suitability in practical situations (service lookup, component upgrades). Type-theoretical foundations will be considered, and implementation for industrially relevant frameworks used as practicality benchmark.

Current State of Research

Software components have been the topic of research and industrial use for the last decade, which lead to the commonly used definition summarised by Szyperski [szyperski98component]. However, neither the research nor the industrial practice have converged to a common component model which would follow the best practices and key research findings. This results in the current state where many non-cooperating frameworks exist in parallel. Moreover, externally available specifications of components, a key prerequisite for platform-independent interoperability, are used only by a minority of the frameworks [omg02components].

The situation is somehow better in web services [wsa04], a recent focus of research [fontoura03tspaces] and industry. Here, the components are loosely coupled and co-operate via the Internet, using XML-based protocols. This lead to the need of external, universally available component specifications, and industrially adopted standards such as WSDL [wsdl2core04] and UDDI [oasis02uddi3] exists for these.

Nevertheless, none of the industrial, and few of the research frameworks deal with issues beyond the simple specification of component service points and the wiring of components together. Safe component upgrades are among the key advanced issues in this respect [brada03thesis]. In the mid- and long-term, these issues will become important as the component-based applications will need to be maintained in operational state.

Details on the Core Issues

The first issue is exemplified by the JavaBeans? and Enterprise JavaBeans? component frameworks. Their components are distributed as .jar (Java archive) files which contain only their implementation in bytecode format. The manifest and/or deployment descriptor files, which the framework standards mandate to be present with the distributed component [sun01ejb], contain only rudimentary specification information. In particular, it does not define the types of the interface elements through which clients interact with the beans; this information has to be obtained from the component implementation.

The lack of type information in component specification leads to several problems (cf. [kent99uml-semantics]). One is the impossibility to reason precisely about its properties, for example to compare the interface with that of other components or to assess the impact of interface changes on component's clients. Another problem is the representation for modelling purposes, for example when the designer needs a simple visual representation of the component (like in the UML [omg01uml]) during component application design.

The second issue relates to the problem of safe upgrades, since above we argued they should be based on checking type substitutability of components (that is, of their interfaces). With external specifications, there is the danger that the typing rules differ between the specification language and the language(s) used to implement the specification [brada03thesis], e.g. IDL’s unsigned short type is represented by different types in Java and C languages. If subtyping-based substitutability assessment ignores these mismatches, its results are not reliable for safe upgrades.

Additionally, when components interoperate via the Internet they may experience the dynamic availability problem [cervantes03automating]. For example, an unforeseen loss of network connection would break access to some of component's required services. In such situation it is important to evaluate the type compatibility of substitute services available in the given component's context.

Approach and Scientific Results

We envisage the work towards these goals will use two basic approaches. The first will be research into key industrial and research component frameworks and the underlying component models, to obtain the knowledge of language mappings, typing rules, variations in specification implementation, and finally of the architectural and availability properties of loosely coupled service components. The second approach will be to follow current research in these areas, mainly in terms of interface specifications, behavioural subtyping, substitutability and component/service architectures.

The work builds on a body of knowledge accommodated during previous research of the principal investigator, especially on his experiences in interface modelling and substitutability fields. For the extracted interface specifications, the ENT meta-model [brada02ent] will be used as the underlying scheme which allows efficient type-based comparisons. The contextual substitutability [brada02metadata] provides an efficient framework for evaluating candidate substitute components in the dynamic availability scenarios.

The following scientific outcomes are envisaged:

  • 1-2 work-in-progress papers per year, published as technical reports and/or presented at key workshops or smaller conferences;
  • 1-2 full papers per year, presenting the research results in items 3, 4 and 5 above.
  • A journal article on contextual substitutability, summing up its definition and a case study for EJB or WS.

For the workshop and conference papers, at least the following forums will be considered: WCOP, ECOOP, CBSE, ICSE, ESEC.

For the journal article, the following periodicals will be considered: CAI, Informatica, Kluwer Automated software engineering, Wiley Journal of Software Maintenance and Evolution or Software – Practice and Experience.

Target Technologies

We will have a look at the following related technologies and research projects:

  • "Enterprise JavaBeans?":http://java.sun.com/products/ejb/index.jsp - start at 2.1, extend into 3.0 (which is a completely different beast...)
  • WSDL
  • "Solution Installation":http://www.w3.org/Submission/2004/04/