A Formal Contract Language for Plugin-based

A Formal Contract Language for Plugin-based Software Engineering Jens Dietrich John Hosking Jonathan Giles Abstract—Plugin-based application design has become increasingly popular in recent years, and has contributed to the success of a range of very different applications including Mozilla Firefox and the Eclipse development environment. Plugin-based design is based on the idea that plugins provide additional functionality extending the capabilities of a core product. While this is often understood as providing services by implementing abstract classes or interfaces defined in the core product, modern plugin-based systems like Eclipse use a much wider definition of service. We propose a formal language that capture these services and describes the contracts between products and plugins. This language is formal, with a well-defined syntax and semantics, and can be used to validate these contracts.

I. Introduction Openness has been considered as a major design goal in software engineering for a long time. Using plugins is one way to achieve this: applications have well defined ports that can be used to add additional functionality. This has merits for both the provider of the application and the provider of the plugin. The provider of the application can focus on the core functionality and can use the extensions to make the product more attractive. On the other hand, the provider of the plugin does not have to worry about the infrastructure for the plugin, as this is provided by the core product. There have been a number of highly successful plugin-based products in recent years, including some products of the Mozilla foundation[Moz] and the Eclipse[Ecla], [GB03] development environment. These products have created plugin ecosystems. Plugins are easy to obtain, and multiple plugins providing the same functionality compete with each other. Examples include look and feels and ad blockers for Mozilla, and code analysis tools for Eclipse. There is no established definition of the term “plugin” in the software engineering literature, but it seems to be obvious that plugins can be considered as close relatives of components. A newer, generally accepted definition of software components [Szy98] lists a number of conditions components must meet: 1. Multiple-use 2. Non-context-specific 3. Composable with other components 4. Encapsulated i.e., non-investigable through their interfaces Institute of Information Sciences and Technology. Te Kura Putaiao o Hangarau-a-Mohiotanga. Palmerston North, New Zealand. Email: [email protected] Department of Computer Science. University of Auckland. Auckland, New Zealand. Email: [email protected] Institute of Information Sciences and Technology. Te Kura Putaiao o Hangarau-a-Mohiotanga. Palmerston North, New Zealand. Email: [email protected]

5. A unit of independent deployment and versioning Plugins meet most of these conditions, the only exception is the requirement of being non-context-specific. Plugins do depend on ports or extension points provided by the host (core application or other plugin), and in this sense are context specific. On the other hand, if there is a component that provides this extension point, then the plugins can inherit the context independence of this component. Another aspect specific to plugins is their life cycle. Components are usually assembled at design or build time. Usually, this requires a compiler linking the components. On the other hand, plugins can be installed, removed and replaced at system runtime by the end users. Technologies that allow access to class lifecycle management such as Java classloaders provide the infrastructure for plugin loading at runtime. The lifecycle of plugins depends on the lifecycle of their host, but not vice versa. I.e., a plugin based architecture uses weak composite aggregations linking hosts and plugins. A major difference between first and second generation plugin models is the ability of plugins to offer extension points. This way, plugins are the providers as well as consumers of services. First generation plugin models, by contrast, are “flat”, i.e. extension points are solely provided by the core applications. Examples include Mozilla, MagicBeans[CEM04] and JEdit[JEd]. Eclipse and its relatives OSGI and JPF are examples of second generation plugin models. They use an architecture where entire applications consist only of plugins, with the exception of a microkernel that bootstraps the application. For instance, the Java Plugin Framework JPF[JPF] uses the JPF-Boot boot loader to bootstrap applications. First generation plugin models like Mozilla and MagicBeans support only very special types of plugins responsible for the provision of XML/XUL, script and CSS files, or Java classes implementing a certain interface, respectively. On the other hand, newer plugin models feature much more polymorphic plugins: plugins have to provide resources that meet certain constraints. Figure 1 visualises the characteristics of first and second generation plugin models. The rest of this paper is organised as follows. First, we take a closer look at plugin interaction in Eclipse. We then classify the resources provided by plugins using the resource description framework. For this purpose, an ontology is defined. Based on these resource types, we introduce a formal language that can be used to express contracts between plugins. We then elaborate the execution semantics of these contracts and describe how this can be used to validate plugin-based systems. We then discuss the expressiveness of the language, and propose a concrete syntax based on the semantic web rule language SWRL.

application kernel

time). In most cases, the only way to test the contracts between plugins is trial and error. The approach proposed here aims at providing validation as a central service.

application

III. Plugin Resources plugin1 plugin1

plugin3

plugin2 plugin2

Fig. 1. 1st vs 2nd generation plugin models

Finally, we discuss open questions and related approaches. II. Plugin Interaction in Eclipse In Eclipse, plugins interact through extension points and extensions. This interaction is governed by a contract between the respective plugins. These contracts are extremely polymorphic, ranging from implementing certain interfaces to providing XML or property files satisfying certain constraints. For instance, extensions to the org.eclipse.help.toc extension point have to provide a zip file in the plugin folder that contains the help system resources, and a table of content XML file that instantiates a certain DTD. Extensions of org.eclipse.ui.actionSets have to provide (amongst other items) labels and icons for actions and classes implementing the action semantics, i.e. implementing the given interface org.eclipse.ui.IWorkbenchWindowActionDelegate. This particular contract is rather sophisticated as it even contains a disjunction. The class attribute has to meet the following condition: the attribute value of class must be “a fully qualified name of a class which implements org.eclipse.ui.IWorkbenchWindowActionDelegate or org.eclipse.ui.IWorkbenchWindowPulldownDelegate. The latter should be implemented in cases where the style attribute has the value pulldown”[Eclb]. This contract is validated at runtime when the plugin providing the extension is used. For instance, consider the code snippet in figure 2. The class attribute value is interpreted as class name, and the respective class is loaded and instantiated. If the contract is breached, an exception occurs. The plugin loading mechanism Eclipse uses makes it rather difficult to deal with these exceptions. The loading of plugins is delayed as much as possible for performance reasons (lazy initialization). This makes it difficult for end users to associate exceptions with plugin lifecycle events. Sometimes, the exception can occur in modules that consume data provided by plugins. Some of these problems may not necessarily result in checked exceptions, but might manifest themselves in runtime exceptions as well. There is no standard mechanism to validate this contract. While using unit testing is an option, this relies on the provider of the plugins to actually supply the test suite. Even then, these test cases are usually not available when the plugins are actually integrated into the system (at run-

Contracts between plugins describe the relationships between resources and data that are supplied by the two plugins interacting. Both resources and data are typed, and there are relationships between resources based on these types. For instance, implements is a relationship between two resources of the type “Java class” and “java interface”, respectively. The semantics of this relationship is that the java class represented by the first resource must implement the interface represented by the second resource. This can be checked by a Java compiler or similar tools like source code analysers. I.e., the semantics of this relationship is defined in the Java language specification[GJS96], and tools based on this specification can be used. There is an obvious relationship between these two types - both can be seen as subtypes of another (abstract) resource type “Java type”. The resource description framework (RDF)[KC04] is a W3C standard for describing resources. Typing resources is not part of the RDF core but is added through the use of ontologies. In particular, the web ontology language OWL[MvH04] can be used for this purpose. RDF is based on the idea of identifying resources by uniform resource unifiers (URIs). These can be either locators (URLs) or names (URNs). Resource types are represented as OWL classes, and are considered as resources as well. In our case we will only consider URLs. I.e. all resources can actually be physically accessed. URLs may be relative with respect to the location of the plugin that provides the respective resources. For the purpose of describing contracts between plugins, a rich vocabulary is needed as there is a wide range of resource types that can be used in contracts, in particular different file formats. This seems to indicate that it is impossible to capture the entire vocabulary needed. For this reason, we focus on a relatively small vocabulary that captures Java artefacts, XML resources and some common file formats often used in software engineering. A. Top Level Structure Figure 3 depicts the upper level of the resource type hierarchy using a UML class diagram. The directed links represent object properties. In RDF, these links are also regarded as resources. The packages represent name spaces, and the subclass relationships denote assertions that use the rdf s : subClassOf predicate. The source of a link is the domain of the associated object property, the target is its range. Properties are data type properties (owl : DatatypeP roperty), the data type of all properties used is the string data type defined in XMLSchema[BM04]. P luginResource is the superclass of the resources provided by both the extension and the extension point. The link between Extension and ExtensionP oint is a derived association (see also [UML05]). I.e., the semantics of this

P l u g i n j d t C o r e P l u g i n = JavaCore . g e t P l u g i n ( ) ; IExtensionPoint extensionPoint = j d t C o r e P l u g i n . g e t D e s c r i p t o r ( ) . g e t E x t e n s i o n P o i n t ( anId ) ; IExtension [ ] extensions = extensionPoint . getExtensions ( ) ; for ( I E x t e n s i o n e x t e n s i o n : e x t e n s i o n s ) { IConfigurationElement [ ] elements = extension . getConfigurationElements ( ) ; for ( I C o n f i g u r a t i o n E l e m e n t element : e l e m e n t s ) { O bject o b j e c t = element . c r e a t e E x e c u t a b l e E x t e n s i o n ( ” c l a s s ” ) ; } } Fig. 2. Eclipse code snippet: integration of plugins

association is not provided through explicit assertions but by other means. We propose to use derivation rules for this purpose. In some plugin models, in particular Eclipse, there is an explicit link between the extension and the extension point. Extensions explicitly reference extension points using their id. But even then it does make sense to have a parallel extends relationship based on rules. Checking that both links associate the same pairs of extension points/extensions is validating the contract. B. Java Resource Types In Java based plugin models such as MagicBeans, Eclipse, JEdit and JPF contracts between Java resources are the most common types of contract. Often the client plugin provides an interface or abstract class and the extension has to provide an implementation of this class. This enables the client to reference a service without establishing dependencies to the actual implementation. The second type of contract adds a flavour of semantics. Component semantics is often described by relations between preand postconditions [ZW97] of method invocations. In agile software engineering, test cases are often used for this purpose, with JUnit[JUn] being a de facto standard to write these test cases in Java. The advantage of test cases is that they can be written using the programming language itself, i.e. without using a particular constraint language. The drawback is that they are not generic, i.e. they only check constraints for the specimen objects and values used in test cases. There is a trend towards providing test suites as part of specifications. Implementations of these specifications have to provide implementation classes of the abstract classes and interfaces, and these implementation classes must pass the tests in the test suite. This requires that test suites and test cases can be written so that only the abstract types are referenced, and have a public API that can be used to instantiate the respective instance variables with instances of the implementation classes. Frameworks like JUnit do not directly support this. However, it is very simple to add this feature to JUnit. Figure 4 shows the source code of such an extension. T is the abstract type; the protected instance variable object can be refer-

package nz . ac . massey . c s . j u n i t x ; public c l a s s TestCase extends j u n i t . framework . TestCase { protected T o b j e c t = nul l ; public TestCase ( S t r i n g name , T o b j e c t ) { super ( name ) ; this . object = object ; } } Fig. 4. Extended JUnit TestCase class

enced in the actual test methods. The constructor can be used to assign an instance of a class implementing or subclassing T to this variable. If the test cases reference multiple objects, arrays or maps can be used. Other JUnit classes like T estSuite can be extended in a similar manner. The tests property associates test suites with the abstract types they reference. The third type of contract uses java annotations. The contract stipulates that an extension has to use annotations provided by the extension point. This kind of contract is useful if the plugin is to take advantage of services provided by the main application. For instances, an application could ask a plugin to provide persistent objects by requiring the plugin to annotate the implementation class with EJB 3 ORM annotations1 . All java resource types have a string type data property javaV ersion that can be used to restrict the the JDK version of the respective resource. Figure 5 depicts the Java branch of the resource type hierarchy using a UML class diagram. The Java resource types are listed in table I, table II shows the object properties of Java resource types. C. XML Resource Types Using XML resources in components is rather common. In particular, XML is used to customise pre-defined generic services. Usually a plugin has to supply an XML document that satisfies certain additional constraints. These 1

these annotations are defined in the package javax.persistence

http://www.w3.org/2002/07/owl# owl name space Thing

http://www.massey.ac.nz/se/plugincontracts

PluginResource

Extension

ExtensionPoint +/extends

Fig. 3. top level resource type hierarchy

property usesAnnotation

rule(s)

semantics classes use the annotations defined

implements extends isVerifiedBy tests

transitive

classes implement the interface or extend the abstract class classes extend other classes a class is verified by a test suite a test suite provides tests for an abstract type

verification source code analyser, reflection (depending on the retention policy) Java Virtual Machine Java Virtual Machine JUnit test runner reflection

TABLE II Properties of Java Resource Types

PluginResource

http://www.massey.ac.nz/se/plugincontracts/java

JavaResource -javaVersion

JavaAnnotationType

+uses

JavaConcreteType

JavaAbstractType +implements

+extends +tests JavaInstantiableClass

TestSuite +isVerifiedBy

Fig. 5. Java branch of the resource type hierarchy

resource type JavaType

intended meaning represents java types, root of the Java resource type hierarchy a Java 1.5+ annotation type a non abstract java class non abstract java class with a public constructor without parameters an abstract java class or interface either a JUnit test suite, or a test suite factory.

JavaAnnotationType JavaConcreteType JavaInstantiableClass

JavaAbstractType TestSuite

TABLE I Java Resource Types

constraints can be easily defined using a schema or constraint language. Document type definition (DTD) and XMLSchema are commonly used for this purpose. Another use case is that a plugin has to supply an XSL transformation for a given schema or DTD. This is useful for plugins that supply services such as skinning, report rendering, or exporting data into specific formats. Since there are several schema languages, the range of some properties consists of the union of several resource classes (DTD and XMLSchema). Figure 6 shows the XML branch of the resource type hierarchy. The XML resource types and properties are listed in table III and table IV, respectively. There are some string type data properties that can be used to restrict the versions of the respective standards to be used. The importance of these attributes will increase in the future as the W3C is currently (2006) working on the second generation of some of the relevant standards (XMLSchema 1.1, XSLT 2.0). resource type XMLResource XMLInstance DTD XMLSchema XSLTransformation

intended meaning represents xml resources a XML document a document type definition an XML Schema a XSL transformation

TABLE III XML Resource Types

D. Other Resource Types In many cases, plugins have to provide other kinds of resources. This may include html pages, property files, images (icons) or multimedia resources. The class GenericResource can be used to represent these resources. This class has only one property representing the media type (as string) of the resource. Restrictions can refer to this media type as well as to the location (URL) of the resource. For instance, a contract can require a plugin to provide an image file (media type image/jpeg) that matches the

property instantiates

transforms

semantics the document is an instance of a schema or DTD the stylesheet can be applied to instances of a schema or DTD

verification validating parser

XSLT processor

TABLE IV Properties of XML Resource Types

naming pattern “icon\ .jp(e)?g”2. In some cases, using the GenericResource type is not expressive enough. A good example are properties file. While there is no official media type for properties files, the format has developed into a de factor standard used to serialise simple key-value associations. There are even “vocabularies” - sets of terms that are permissible keys. In this case, separate resource classes (and packages) should be defined. Figure 7 depicts the generic resource type. IV. Contracts as Rules With resource types and resource properties defined, derivation rules can be defined representing the contracts between the extension and the extension point providing the resources. These rules describe the validity of contracts. Using rules for this purpose has the following advantages: • Derivation rules have a well-defined semantics that is based on the model theory of first order predicate logic (PL1). • The use of a declarative language makes it easy for end users to configure and understand rules. • There are execution environments for rules (“inference engines”) that not only support the execution of rules, i.e. check the validity of a contract, but can also provide the reasons for a contract not being valid by making the derivation trace accessible. • Rules can easily be serialised and exchanged, and there are emerging standards for this purpose. Rules have to reference resources that are part of either the extension or the extension point. Using a general purpose contains predicate is not expressive enough for this purpose: sometimes, the same resource must be referenced twice in a different context. I.e., plugins use role names to reference resources. We formally define roles as functional, navigatable properties. This includes both object and datatype properties. I.e., given a resource r1 and a role p, a variable ?x in p(r1, ?x) can be resolved by the execution environment that processes the rule. At this point we are not interested in the precise mechanism how this is done, but an obvious example is that the semantics of p is defined by XML file, and resolving ?x is done by navigating through the hierarchical structure of this document (i.e., 2 We assume that there is a built-in predicate for regular expression matching. SWRL has such a predicate, swrlb:matches [HPSB+ 04].

PluginResource

http://www.massey.ac.nz/se/plugincontracts/xml

+instantiates

DTD

XMLInstance -xmlVersion

+instantiates +transforms XMLSchema

+transforms

-xmlSchemaVersion

XMLTransformation -xsltVersion

Fig. 6. XML branch of the resource type hierarchy

PluginResource

http://www.massey.ac.nz/se/plugincontracts/generic

GenericResource -mimeType

Fig. 7. Generic resources

navigating to a child element named

), or by querying the document with an appropriate XPath query. A concrete syntax for this kind of configuration file are the plugin.xml files used by Eclipse and the JPF. The rules representing contracts have the following structure: 1. Rules reference a fixed extension point. I.e., they contain a constant term of the type ExtensionP oint. 2. An extension is represented as a variable of the type Extension. Each rule contains exactly one such variable. 3. The heads of the rules use the predicate extends that associates the extension point (constant) with the extension (variable). The semantics of extends is solely defined by these rules. 4. The bodies of the rules contain prerequisites that use the following predicates:

(a) Predicates defined in the ontology, either in one of the packages defined here or in additional packages. These predicates are either object properties or data type properties of (subclasses of) P luginResource. The rule execution environment knows the semantcis of these predicates. I.e., given a predicate p and two constant terms t1 and t2 there is a decidable algorithm to decide whether p(t1 , t2 ) is true. (b) Built-in predicates for data type values from standard libraries with well known semantics. In particular, this should include the predicates that are defined in SWRL and XPath/XQuery. (c) Roles. 5. Extra variables can be used as long as there is a path of roles connecting them to either the extension (the variable), or the extension point (constant term). I.e. we define a variable ?x to be connected iff there is

a role p and the rule contains a prerequisite p(t, ?x) such that the term t is either the term representing the extension, the term representing the extension point or another connected variable. Rules that meet these conditions are called contract rules. The recursive definition of connected variables supports deep references to resources in contracts. For instance, an extension point can use two roles dbconf iguration and dbaccess to reference an XML resource describing the access to a database through another (folder like) resource that groups together several database related settings. The following example shows a contract that uses one role, parser. Terms are denoted using the following syntax: a term name is followed by the (local) resource type name separated by a colon. For space reasons, the type name is only used when the term is used for the first time. Variable terms start with the prefix ?. The extension point provides the parser interface i : JavaAbstractT ype, and the extensions have to provide a class implementing this interface. Furthermore, this class must be instantiable through reflection. In the first prerequisite, the variable ?c : JavaInstantiableClass is introduced. parser(?x : Extension, ?c : JavaInstantiableClass)∧ implements(?c :, i : JavaAbstractT ype) ⇒ extends(?x :, xp1 : ExtensionP oint)

V. Execution Semantics The main purpose of introducing rules is to be able to validate contracts. For this purpose, an execution environment is employed. This environment can check ground facts by invoking algorithms that can decide whether a predicate associates two resources or data values. Validation is performed for a given extension point and a given extension. The extension point supplies the contract rule, and the rule is then recursively transformed into a ground rule as follows: 1. All occurrences of the extension variable in the rule are replaced by the extension (i.e., the constant term representing the extension). 2. For all prerequisites using roles, having a constant term in the first slot and a variable term in the second slot, a constant term for the second slot is computed by the execution environment, and all occurrences of the variable in the rule are replaced by this constant term. Then this prerequisite is removed. This is repeated until all variables in the rule are replaced. Step 2 relies on roles being functional and navigable. At the end of this process, the rule is ground. I.e., all variables in the rule have been replaced by constant terms. Validation is essentially a matter of computing whether the ground prerequisites do or don’t hold. This computation is done by the execution environment. While this sounds vague, it emphasises the openness of this approach. For particular predicates the algorithms that can be used

T o b j = (T) c . n e w I n s t a n c e ( ) ; TestCase t c = new MyTestCase(” t e s t ” , o b j ) ; .. TestResult r e s u l t = . . ; t c . run ( r e s u l t ) ; .. Fig. 8. Executing a test case

are provided by additional modules an execution environment has to interact with. For instance, if the predicate is implements then an execution environment would typically employ a Java virtual machine to load the class and the interface and to verify that the class really implements the interface. In other cases, source code analysers, regular expression engines or validating xml parsers could be used to provide the semantics for predicates. The also rather vaguely defined standard predicates are usually interpreted by standard inference engines. Although we try to avoid references to a concrete rule syntax at this stage, the use of standard predicates is clearly motivated by the predicates built-into web languages such as XPath[BCS+ 06] and SWRL[HPSB+ 04]. For instance, the execution environment would employ the services of a regular expression matcher for the respective string matching predicates. Most of the work is done by the execution environment that knows the meaning of certain predicates. Usually, the processing of the predicates is orthogonal in a sense that the execution environment can verify whether a ground fact p(t1 , t2 ) holds without any further background knowledge. In some cases, such additional knowledge would be useful. For instance, consider the following contract: parser(?x : Extension, ?c : JavaInstantiableClass)∧ implements(?c :, i : JavaAbstractT ype)∧ tests(?s : T estSuite, i :)∧ isV erif iedBy(?c :, s :) ⇒ extends(?x :, xp1 : ExtensionP oint) The plugin has to supply an implementation class of an interface that must pass a test suite. In order to run the tests, the test runner must instantiate the implementation class, and bind the variable in the test cases within the test suite to this instance. Then the test cases are executed. The respective code snippet is shown in figure 8. T represents the abstract class, c is a java.lang.Class instance representing the implementation class provided by the extension. If implements(?c :, i : JavaAbstractT ype) fails, tests(?s : T estSuite, i :) will also fail (with a class cast exception). I.e., there is a dependency relationship between prerequisites in the contract rule. This dependency can be expressed by a derivation rule as follows: isV erif iedBy(?c : JavaInstantiableClass, s : T estSuite) ⇒ implements(?c :, i : JavaAbstractT ype)

If the isV erif iedBy fact is checked first, then the tests will fail, but the reason is actually that the class does not implement the interface. That is, the reason that validation has failed could be more precise if the execution environment had evaluated the prerequisite with the implements predicate first. Adding these kinds of rules to contracts does not change their meaning, but can be used to either maximise performance (skip the evaluation of dependent facts), or to improve preciseness (evaluate dependent facts first). VI. Adding Expressiveness - Negation and Disjunction The contract rules defined so far have a rather simple syntax. In particular, negation and disjunction are not yet supported. Adding (strong) negation is relatively simple if negation is seen as a construct that creates a new predicates with the “opposite” meaning. I.e., for constants t1 , t2 and predicates p p(t1 , t2 ) holds iff ¬p(t1 , t2 ) does not hold. Adding this negation only adds new predicate symbols, and therefore does not require a different execution semantics. Disjunction is already used in existing plugin systems. Section II contains such an example for the org.eclipse.ui.actionSets extension point in Eclipse: depending on the value of one attribute, a different interface has to be implemented by the extension. This contract can be expressed as follows (package names omitted). The two predicates class and style represent roles. class(?x : Extension, ?c : JavaInstantiableClass)∧ style(?x :, ?value : string)∧ (= (?value :, pulldown : string)∧ implements(?c :, IW orkbenchW indowAction− Delegate : JavaAbstractT ype)) ∨ (6= (?value :, pulldown :)∧ implements(?c :, IW orkbenchW indowP ulldown− Delegate :)) ⇒ extends(?x :, xp1 : ExtensionP oint) As far as the execution semantics of the rules is concerned disjunction is easy to handle, a (variable free) prerequisite containing a disjunction is true iff any of its parts is true. VII. Concrete Syntax SWRL is an obvious choice to represent contracts. The main problem is that SWRL does not support disjunction. If the contract does contain disjunctions, they can still be represented by a set of SWRL rules if they are transformed as follows: 1. The body of the rule is transformed into disjunctive normal form. 2. The rule A1 ∨..∨An ⇒ extends(?x, xp) is transformed into a set of rules {Ai ⇒ extends(?x, xp)} The set of rules resulting from this transformation can then be serialised using SWRL. The code snippet in figure 9 shows a contract represented in SWRL. The names space

prefixes swrl: and ruleml: are defined as in [HPSB+ 04]. The entities &core; and &java; represent the name spaces of the top level and java resource type package, &sample; refers to the name space in which the roles for this contract are defined. VIII. Conclusion, Related and Future Work In this paper, we have presented a contract language that can be used to specify the interaction between plugins. We have used various W3C standards for this purpose, and have elaborated an ontology that defines the resource types commonly used in Java based plugin systems. However, our approach is completely open and other resources type can easily be plugged in. We did not use a particular specification language to specify the interface or the behaviour of plugins. Instead, we consider these specifications as a special kind of resource provided by plugins. We have provided an execution semantics that defines how contracts can be validated, and a concrete syntax for contracts based on SWRL/XML. There are similarities between our approach and Architecture Description Languages (ADLs) like Darwin[MDEK95] and Wright[All97]. In particular, in [CEK+ 04] Darwin is used to specify the interaction between plugins in the MagicBeans framework[CEM04]. In general, ADLs provide notations for decomposing systems into components and connectors. ADLs are built around the concept of service. Services are provided and required by components. In contrast, our approach is based on typed resources that are provided and consumed by components. Service specifications are seen as resources, and the implementation of a service is modelled by object properties pointing to these resources. The resource centric approach facilitates the integration of different service description formats, and the decomposition of service descriptions. For instance, the combination of Java interfaces and test suites can be used to describe the syntax and the semantics of a Java service. If a higher level of abstraction and platform independence was required, other resource types such as IDL, WSDL and/or OCL[OCL03] could be used instead to describe services. The Babylone project [BFR] aims at capturing framework dependencies in Eclipse. It is based on the 3-layer active hotspot model (ASHM). These three layers can be related to our approach as follows: AHSM1 contains resources. ASHM2 adds relationships between resources including roles, AHSM3 adds constraints. ISL [DBFAM01] and OCL[OCL03] are used as constraint languages. This differs from our work as follows. In our approach, contracts are solely defined by derivation rules. This supports expressing disjunctions. If other types of constraints are needed that can be only expressed in OCL (or other constraint languages), then this can be integrated into the contract as OCL resources published by the extension point. This results in an architecture that supports pluggable constraint languages. Representing contracts by rules has been used in other areas as well, in particular in attempts to formalise ser-

< !−− t h e e x t e n s i o n −−> < !−− t h e c l a s s −−> < !−− t h e e x t e n s i o n t y p e −−> < s w r l : c l a s s P r e d i c a t e r d f : r e s o u r c e =”&c o r e ; E x t e n s i o n ” /> < !−− p a r s e r r o l e −−> < !−− c i s an i n s t a n t i a b l e c l a s s −−> < s w r l : c l a s s P r e d i c a t e r d f : r e s o u r c e =”&j a v a ; J a v a I n s t a n t i a b l e C l a s s ” /> < !−− c implemen t s an i n t e r f a c e s u p p l i e d by t h e e x t e n s i o n p o i n t −−> Fig. 9. Contract rule using the SWRL syntax

vice level agreements (SLA contracts) [GLC99], [PDK05]. SweetDeal[GP03] is a rule-based approach to representation of business contracts. It uses a similar stack of technologies, in particular DAML+OIL as ontology language and RuleML as rule markup language. In [GALH01] an XML based contract language has been proposed that connects service providers and service consumers in crossorganizational workflow management systems. The elaboration of suitable resource types and their relationships remains subject to further research. As the plugin-based approach gains momentum and is used in new areas such as development environments for programming languages other than Java and distributed plugin models [VT05], new ontologies are needed to define the vocabularies to be used in the respective contracts. Developing such a vocabulary is always a balance between simplicity and

expressiveness. Deciding whether a vocabulary is suitable will in many cases have to include empirical studies that analyse the plugins and their interaction in a particular application domain. We are also contemplating developing a visual rule language to design and maintain the contracts.

References [All97] [BCS+ 06]

[BFR]

Robert John Allen. A formal approach to software architecture. PhD thesis, Carnegie Mellon University, 1997. Chair-David Garlan. Scott Boag, Don Chamberlin, J´ erˆ ome Sim´ eon, Mary F. Fern´ andez, Jonathan Robie, Anders Berglund, and Michael Kay. XML Path Language (XPath) 2.0. Candidate recommendation, W3C, June 2006. http://www.w3.org/TR/2006/CR-xpath20-20060608/. Mireille Blay-Fornarino and Estelle Ringenbach. Babylone, enabling Eclipse with framework assistance tool-

ing. http://www.essi.fr/∼blay/RECHERCHE/babylone Website. [BM04] Paul V. Biron and Ashok Malhotra. XML Schema Part 2: Datatypes Second Edition. W3C recommendation, W3C, October 2004. http://www.w3.org/TR/xmlschema-2/. [CEK+ 04] Robert Chatley, Susan Eisenbach, Jeff Kramer, Jeff Magee, and Sebastian Uchitel. Predictable dynamic plugin systems. In Fundamental Approaches to Software Engineering (FASE) at the European Joint Conferences on Theory and Practice of Software (ETAPS), 2004. [CEM04] Robert Chatley, Susan Eisenbach, and Jeff Magee. MagicBeans: a platform for deploying plugin components. In Proceedings of 2nd international working conference on component deployment, e-Science Institute, Edinburgh, Scotland, 2004, 2004. [DBFAM01] Anne-Marie Dery, Mireille Blay-Fornarino, Borice Arcier, and Leonard Mule. Distributed access knowledge-based system: Reified interaction service for trace and control. In DOA ’01: Proceedings of the Third International Symposium on Distributed Objects and Applications, page 76, Washington, DC, USA, 2001. IEEE Computer Society. [Ecla] The Eclipse project. http://www.eclipse.org/. [Eclb] Eclipse platform extension points reference. http://help.eclipse.org/help31/index.jsp. [GALH01] Paul W. P. J. Grefen, Karl Aberer, Heiko Ludwig, and Yigal Hoffner. Crossflow: Cross-organizational workflow management for service outsourcing in dynamic virtual enterprises. IEEE Data Engineering Bulletin, 24(1):52–57, 2001. [GB03] Erich Gamma and Kent Beck. Contributing to Eclipse: Principles, Patterns, and Plugins. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 2003. [GJS96] James Gosling, Bill Joy, and Guy L. Steele. The Java Language Specification. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1996. [GLC99] Benjamin N. Grosof, Yannis Labrou, and Hoi Y. Chan. A declarative approach to business rules in contracts: courteous logic programs in xml. In EC ’99: Proceedings of the 1st ACM conference on Electronic commerce, pages 68–77, New York, NY, USA, 1999. ACM Press. [GP03] Benjamin N. Grosof and Terrence C. Poon. Sweetdeal: representing agent contracts with exceptions using xml rules, ontologies, and process descriptions. In WWW ’03: Proceedings of the 12th international conference on World Wide Web, pages 340–349, New York, NY, USA, 2003. ACM Press. [HPSB+ 04] Ian Horrocks, Peter F. Patel-Schneider, Harold Boley, Said Tabet, Benjamin Grosof, and Mike Dean. SWRL: A semantic web rule language combining owl and ruleml. W3C member submission, W3C, May 2004. http://www.w3.org/Submission/SWRL/. [JEd] The JEdit project. http://www.jedit.org/. [JPF] The Java plug-in framework (JPF) project. http://jpf.sourceforge.net/. [JUn] The JUnit testing framework. http://www.junit.org/. [KC04] Graham Klyne and Jeremy J. Carroll. Resource description framework (RDF): Concepts and abstract syntax. W3C recommendation, W3C, February 2004. http://www.w3.org/TR/2004/REC-rdfconcepts-20040210/. [MDEK95] J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Specifying Distributed Software Architectures. In W. Schafer and P. Botella, editors, Proc. 5th European Software Engineering Conf. (ESEC 95), volume 989, pages 137– 153, Sitges, Spain, 1995. Springer-Verlag, Berlin. [Moz] The Mozilla project. http://www.mozilla.org/. [MvH04] Deborah L. McGuinness and Frank van Harmelen. OWL web ontology language overview.

[OCL03] [PDK05] [Szy98] [UML05] [VT05]

[ZW97]

W3C recommendation, W3C, February 2004. http://www.w3.org/TR/2004/REC-owl-features20040210/. UML2.0 OCL Specification, October 2003. http://www.omg.org/docs/ptc/03-10-14.pdf. Adrian Paschke, Jens Dietrich, and Karsten Kuhla. A logic based SLA management framework. In Proc. of the Semantic Web and Policy Workshop, 2005. Clemens Szyperski. Component Software: Beyond Object-Oriented Programming. ACM Press and Addison-Wesley, New York, NY, 1998. UML Superstructure Specification, v2.0, July 2005. http://www.omg.org/cgi-bin/doc?formal/05-07-04. Minh Vu and Craig Thompson. E2 agent plugin architecture. In Proceedings of the IEEE Integration of Knowledge Intensive Multi-Agent Systems (KIMAS05), pages 26–31, Washington, DC, USA, 2005. IEEE Press. Amy Moormann Zaremski and Jeannette M. Wing. Specification matching of software components. ACM Transactions on Software Engineering and Methodology, 6(4):333–369, 1997.