The Olan Architecture Definition Language

Transcription

1 The Olan Architecture Definition Language Luc Bellissard, Noël De Palma, David Féliot, SIRAC project INRIA Rhône Alpes 655, Avenue de l Europe F MONTBONNOT SAINT-MARTIN, France [Luc.Bellissard]@inrialpes.fr Abstract This paper presents the Olan Architecture Definition Language used for describing a distributed software architecture. Architecture Definition Languages are today recognized as a successful solution for the design, the analysis, the implementation and the deployment of complex software architecture, goals that are within the scope of the C3DS project. The main contribution of the Olan ADL is to help the design and implementation of distributed software systems, and the result of an Olan described Architecture can be used to deploy a system on various kind of middleware. Within C3DS, the targeted middleware is the TCCS platform, a combination of the AAA agent-based message oriented middleware and CORBA Object Request Brokers. 1. Introduction Software Architecture is a promising field for the component-based development of large scale software. Issues related to such developments are the reuse of components and their substitutability. The software engineering community claims those issues must be fully integrated and planned at design time[shaw96][perr89]. Techniques for doing so in the small exist, such as separation of concerns and isolation of changes, but they proved to be insufficient as long as the reuse of existing complex components is concerned. Indeed large components encapsulate several abstract data types (ADT). Moreover they provide significant functionalities and also rely each on their particular execution models and runtime supports. Studies have been conducted in the past decades about the suitability of particular languages to support the definition and specification of architectures, thus providing the practitioner a concrete way of programming in the large. Architecture definition languages have all the same basic rational of providing the structural view of a software system. This view is often refined into a particular view dedicated to either the analysis, the expression of properties or also the implementation and configuration of a software. This paper depicts the process of designing and implementing a distributed software architecture through the Olan ADL. Like other languages, an Olan architecture definition is based on the commonly accepted concepts of an architecture: component, connector and configuration [Iss98]. We will also detail the mapping between software component described in Olan and their implementation depending on the type of middleware used for remote communication between software entities. 1

2 1 Olan overall presentation 1.1 Architecture definition languages Design, implementation and deployment are three activities that are carried out during the life time of a software system. The software architecture aims at describing the component-based program structure, the interconnections between the components, the design and evolution rules. The architecture design stage is critical because it links the specification to the implementation. The architecture is the abstract description of a system structure in terms of software components. It explains and models the relations and interconnections between those components.[luc95][medv97] ADL s are notations that express a software architecture. All ADLs are based on the modeling of a program out of multiple components. They partition a system into a set of computational components (called primitive components) that are implemented by a developer. Some ADLs attach to components a type according to the nature of the programming model of their implementation. Besides they describe some of the behavior of components either from a functional point of view (e.g. a finite state automaton in Darwin) or a non functional point of view (inner execution model in Olan[Bal98], quality of service or protection in Aster). Moreover most of the ADLs are based on a hierarchical composition approach[nie95a][nie95b]. Thus they allow to describe generic program structures that may be customized and instantiated in order to produce specific versions of a program [Kra89b][Bel96][Mag93][Mag94a]. The connector concept is also widely used [Sha95] [All94] to specify the binding rules between components and communication properties. These properties can be quite complex when dealing with distributed applications. Examples of such properties are: communication mechanism type, protocol, synchronization rules, scheduling, etc. A full study of ADLs can be found in [Iss98]. 1.2 Olan concepts OlanADL enables the description of software architectures intended to be deployed on a target system. A version of an architecture ready for the deployment is called a configuration. Configurations are made of a set of components, hierarchically composed with each other. Components may be either primitive components (units that describe the implementation code attached to this component) or composite components which are defined in terms of interconnected components and configured properties (such as location, component parameters, ). Interconnecting component requires the use of connectors, as the objects ruling and defining the communication happening when deployed components communicate with each other. Components are units of description: description of the implementation in case of primitive components, description of the functional services provided or required by the component, and properties (like name-value pairs, hosting node for the execution, non-functional properties of components) 2 Olan Syntax 2.1 Preliminaries The syntax of Olan is given in a variant of traditional BNF. Non terminal identifiers are shown without bracket where terminal identifier are shown in boldface. Syntactic comments starts with // and continue till the end of the line, or can be enclosed in /* */ expression as in Java. Olan ADL follows the Java conventions for identifiers and token. 2

3 The existing keywords are : Keyword = component provided required interface implementation connector configuration in out builtin attribute service file notification readonly agent object composite collection dyn new But also any primitive type used in IDL such as int, long,... Identifiers are used for defining services, component, properties, constants, instances, Identifiers must be unique in the scope in which they are defined. The scope of identifiers extends from their defining point to the end of the immediately enclosing declaration block (i.e. enclosing { ). 2.2 Services Services define the operation or set of operations that can be accessed or used by components. In architecture definition languages, services are of two kinds: provided services or required services. Thus a component definition is made of either kind, in order to completely describe a component services and requirements. The exact semantic of a service depends on the mapping of the service on its real implementation. Thus a service might correspond to an interface, a module header file or simply one single function, procedure or method. services = service <service identifier> : <service type> { <service mapping> The service mapping is defined according to the service type Service Type Types of services characterize the way operations are defined and accessed at runtime. Each type is associated to a middleware. The following table details the existing type of services today in OlanADL. Middleware Service Type Operations Description Syntax AAA A3Service Java serializable type system Corba IDL IDLService OMG IDL type system Java RMI JremoteService Java serializable type system Java rari ARIRemoteService Java serializable type system Service type mapping According to the type of the service, there must be a correspondence to the way services are described and used in the implementation. Such a correspondence is called a mapping, and the following mapping are defined in OlanADL. AAA Services service mapping = <a3 mapping > <java service > <CORBA service > service mapping = <a3 mapping> a3 mapping = notifications = <java class name>; file = <file name>; 3

4 java class name = <package name>. <class name> file name = <string> package name = <string> <package name>. <string> class name = <string> A service provided or required by AAA agents corresponds to a set of notifications to be handled by the agent or sent to other agents. The set of notification defining the service must be implemented by a NotificationSet class. service FilterService : A3Service { notification = aaa.ar.logfilternotificationset; file = ${SRC_DIR/aaa/ar/LogFilterNotificationSet.Java; Each method of this class creates a notification that can be used by the agents. package aaa.ar; public class LogFilterNotificationSet extends aaa.agent.notificationset { public static SyncNot SyncNot(long stamp, long date) { return new SyncNot(stamp, date); public static SyncNot SyncNot(long stamp, long date, int nbsyncrecord){ return new SyncNot(stamp, date, nbsyncrecord); public static FlushNot FlushNot(long stamp, long date, long flushdate) { public static FlushNot FlushNot(long stamp, long date, long flushdate, String name, int nbsyncrecord); { public Static RecordNot RecordNot(Record record){ public static RecordNot RecordNot(Record[] records){ public static EOFNot EOFNot(long stamp, long date, long enddate){ public static EOFNot EOFNot(long stamp, long date, long enddate, int nbsyncrecord) { In this example, the agent interface allows the reaction to four types of notifications: SyncNot, FlushNot, EOFNot and RecordNot. CORBA Services CORBA Service = interface = <IDL interface name> ; file = <file name> ; IDL interface name = <module name> :: <interface name> module name = <string> interface name = <string> 4

5 service Billing : IDLService { interface = C3DSDemo::BillingService; file = ${SRC_DIR/c3ds/Workflow/C3DSDemo.idl; The corresponding IDL definition is: module C3DSDemo ; struct Bill { string department; long inputcost; long outputcost; AccountingSeq records; float amount; ; interface BillingService { void transfer(in Bill bill); void claim(in Bill bill, in string claim); Java RMI service mapping = <java service > java Service = interface = <java interface name>; file = <file name>; java interface name = <package name>. <interface name> The java interface must be of type java.rmi.remote. service DNS : JRemoteService { interface = DNS.DNSInterface; file = ${SRC_DIR/DNS/DNSInterface.Java; The Corresponding agent interface is the following: package DNS; public interface DNSInterface extends java.rmi.remote { public DNSResult lookup(dnsaddress addr); rari Services service mapping = <java service > The java interface must be of type aaa.ari.remote. Such an interface is defined as an RMI interface, with all methods having no return value (oneway methods). 5

6 2.3 Properties Properties define parameters that can be configured when the application is deployed. Properties enable the configuration of either attributes value of component (properties are then name value pairs used by the component operations) or non-functional properties of component (properties related to the execution behavior of a component, like the hosting node, transactional behavior, persistence properties, ). In OlanADL, the definition of functional properties are attached to the component interface, whereas the non-functional properties are attached to the definition of the component itself. Properties are syntactically defined as follows: properties = [+0 [ readonly ] attribute <property type> <property identifier> [ = <expression> ] ; ] The property type is usually expressed with the IDL type system. The type corresponds to the type of the value to be assigned to the property. However, when expressing non-functional properties, type can be of special kind, as detailed in the sub-section Non functional properties below. The initial value can be set within the interface definition (the initial value is defined), or externally when components are assembled or deployed. The expression syntax is the same as IDL constant assignment. However, expression can also be environment variables, i.e. references to a value that will be set up later, when the application is deployed. expression = <IDL expression> <environment variable> environment variable = $ <variable identifier> readonly modifier indicates that the property cannot be configured externally from the component. It can only vary over time because the component implementation manages its modifications Functional Properties Still using the same example of a Filter agent, here are some property definitions: attribute string SRC_IP_ADDR ; attribute string DEST_IP_ADDR; They corresponds to string attributes. AAA mapping A property can be assigned to any agents. Since interface or services are defined in a special way, the attribute correspondence must be found within the component implementation itself (in the AAA agent case, the implementation is a particular java class as detailed in section about components). The mapping is : For any attribute of identifier ATTRID, there must be a method defined in the agent class which prototype is attrtype getattrid( ) and a method of prototype void setattrid(attr_type value) if the attribute has no readonly modifier. Java types used for attr_type corresponds to the OMG IDL to Java mapping. public class LogFilterAgent extends Agent { // definition of internal attribute protected String SRC_IP_ADDR; 6

7 string getsrc_ip_addr() { return SRC_IP_ADDR; void setsrc_ip_addr(string value) { SRC_IP_ADDR = value; CORBA mapping In CORBA IDL, attributes can be defined in the same way as defined in OlanADL. The mapping is defined as follow: For any property named ATTRID, there must be in one of the IDL interface used to define the encapsulated CORBA object, an attribute of identifier ATTRID with the same definition as the one described in OlanADL. RMI mapping The RMI mapping of attribute is the same as the one found in Agent. For each attribute, there must be a getattrid method and a setattrid method if the property is not readonly. This method must be implemented by the RMI server and defined in an interface inheriting from java.rmi.remote. ARI mapping The mapping is exactly the same as in RMI except that attribute-related methods must be defined in an interface inheriting from aaa.ari.remote Non functional properties Non functional properties are expressed using attributes. Today, those properties are related to the execution node of a primitive component. Other properties will be added later, according to the primitive component type handled by OlanADL. Each of these properties are highly dependent on the component type. AAA Middleware Non functional properties Location A3Server Property type Description Agent server where the agent is deployed initially True if the agent is persistent. Persistent boolean Corba IDL Location CORBAFactoryName Name of the factory in charge of creating any application related CORBA object. Name is the one registered in CORBA name service. Java RMI Location RMIFactoryURL Name (as URL) of the factory in charge of creating any RMI object of the application. Name are registered in the Registry of RMI. Java rari Location A3Server Same properties as AAA agents Persistent boolean 2.4 Primitive components Primitive components are the units of description of the encapsulated software. Their definition must include every possible information related to what kind of program code they contain, how this code and the component interface can be mapped together, and where this code can be found in order to 7

8 install the component in a later stage. Some other information can also be described, those related to the required configuration in order to have the component deploy and install on a computer node. The Component type is the first step to the definition of a primitive. Types characterize the nature of the encapsulated implementation. As a matter of fact, the type usually reflects the middleware used to access remotely the component. Second step is the definition of the interface. The interface is made of a list of services, either required or provided, and properties. The component definition is complete when the implementation is defined. The implementation is a list of information about the code of the component : files, type of source code, Implementation are thus completely dependent from the component type. So are the services included in an interface, their type must be compatible with the component type. component = component <component Identifier> : <component Type> { ( <properties> )*; interface = <interface identifier>; implementation = <implementation identifier>; Properties can be defined within the component or within an interface as shown below. Properties attached to components are properties allowed for the corresponding component type, as shown in the next table. Such properties are usually non functional properties, like the hosting machine name. Properties attached to an interface are usually functional properties, attached to a set of operations Component type A type characterizes the nature of the implementation. According to the type of the component, interface, properties and implementation must be carefully chosen. The following table shows available type and the associated service type, property types and implementation Component Type Description Associated Services Type Associated Requirement Provision Properties A3Agent Agent A3Service A3Service A3Server location Boolean persistent CORBAObject CORBA distributed object IDLService IDLService CORBAFactoryNa me location RMIObject Java RMI server object JRemoteService JRemoteService RMIFactoryURL ARIObject Asynchronous remote invocation java object CorbaAgentProxy Programmable gateway between Corba object and A3 agent location ARIRemoteService ARIRemoteService A3Server location Boolean persistent A3Service IDLService A3Service IDLService A3Server location Interface Interfaces describe the externally available services and properties. By available, we mean the properties that can be configured from outside the implementation code of a component, as well as the services that can be accessed from other components. Required components are particular in the sense that they explicit the functional dependencies of the component with other component. Such dependencies are defined by the architecture, within composite component that will be described later in this paper. component interface = 8

9 interface <interface identifier> [ : <interface identifier> ] { ( <properties> )*; ( provided <service identifier> <provision identifier> required <service identifier> <requirement identifier> )*; As shown in the grammar like notation, an interface can be defined by inheriting from a previous definition. There is thus interface inheritance in OlanADL Implementation Implementation of a primitive component is a description of all information required to retrieve the real implementation of the component. This implementation description depends on the type of the component. For each type, a mapping is defined with the real implementation, thus allowing various components or object models to be encapsulated and described within the OlanADL. component implementation = implementation <implementation identifier> { <implementation_mapping> The implementation mapping is the description of the encapsulated software within the primitive component. Several kinds of mapping are defined in OlanADL according to the type of the component. For each mapping, there is some convention about the programming of software that we detail below. implementation mapping = <a3 mapping> <CORBA mapping> <RMI mapping > <ARI mapping> AAA Agent mapping An AAA primitive component corresponds to an agent class. This agent must support the properties of the component, as well as the required and provided services. The description of the agent class is defined as: A3 mapping = agent = <java class name>; file = <file name>; Supporting the properties means the availability of getxxx and setxxx method in the class. Supporting the provided services means implementing the associated interface, as defined in AAA service mapping. Each accepted notification in provided services must be handled within the implementation of the agent. Supporting the required services means that the agent contains as many Role as the number of defined required services. Each of these Roles must accept any of the notification contained in the definition of the required service. The following example shows the complete LogFilterAgent, example partially used in the services and properties mapping sections. component LogFilterAgent : A3Agent { A3Server location; interface LogFilterItf { string SRC_IP_ADDR; 9

10 string DEST_IP_ADDR; provided LogFilterService record; required LogFilterService accept; required LogFilterService reject; ; implementation LogFilterAgentImpl { agent = aaa.ar.logfilteragent; file = ${SRC_DIR/aaa/ar/LogFilterAgent.java; The implementation of the agent may be the following: package aaa.ar; import aaa.agent.*; public class LogFilterAgent extends Agent { /* definition of required service */ public Role accept; public Role reject; void LogFilterAgent( short to, String name) { Super(to,name); // rest of constructor implementation // main method: definition of the possible reactions to // an incoming notification // dispatch to doreact method according to Notification types. public void react(agentid from, Notification not) { // implementation of the accepted notification as defined in the // provided services if (not instanceof SyncNot) { doreact(from, (SyncNot) not); else if (not instanceof FlushNot) { super.react(from,not); // implementation of the reaction to notification SyncNot // within the method, something is sent to a Role, i.e. a required service protected void doreact(agentid from, SyncNot not) {. // send a notification to one of the role sendto(accept, new SyncNot());. // other doreact method. Notification accepted are // defined in LogFilterNotificationSet class. protected void doreact(agentid from, FlushNot not) 10

11 CORBA Object mapping A CORBA primitive component correspond to a CORBA object, whatsoever its implementation language is. However, we assume that CORBA objects are implemented here in Java, thus being defined by a Java class. This restriction may easily be overcome, with languages like C++ where the implementation principles are somehow similar to other object-oriented language. This object must support the properties of the component, as well as the required and provided services. The description of the CORBA object is then defined as: CORBA mapping = object = <java class name>; file = <file name>; Supporting the properties means the availability of public attributes in a particular IDL interface definition of the object (the ObjectAdmin interface). Supporting the provided services means implementing the associated IDL interface, as defined in CORBA service mapping. Supporting the required services means that the object contains as many references as the number of defined required services. Each of this reference is typed according to the associated interface, as defined in CORBA service mapping. In addition, there must be also an Admin IDL interface implemented by the object which role is to define the attributes as well as method for the setting of references for each required service. The following example shows the complete Billing Corba object, example partially used in the services and properties mapping sections. service Department : IDLService { interface = C3DSDemo::Department; file = ${SRCDIR/c3ds/Workflow/C3DSDemo.idl; service BillingWF : IDLService { interface = C3DSDemo::BillingWF; file = ${SRCDIR/c3ds/Workflow/C3DSDemo.idl; component Billing : CORBAObject { CORBAFactoryName location; interface BillingItf { attribute long inputcost; attribute long outputcost; provided BillingWF start; required Department ressources; required BillingService billingperformer; implementation BillingImpl { object = c3dsdemo.billingwfimpl ; file = ${SRCDIR/c3dsdemo/BillingWFImpl.java ; The IDL interface for the management of the CORBA object, as well as those of required or provided services are : interface BillingWFAdmin { attribute long inputcost; attribute long outputcost; 11

12 ; void setdepartment(in Department dept); void setbillingservice(in BillingService billingservice); interface BillingWF { void onaccountinglog(in string accountingfilename); ; interface Department : Workflow::Resource { string getname(); void pay(in Bill bill) raises (ClaimException); ; The implementation in java of the Billing component is the following: public class BillingWFImpl implements BillingWF, BillingWFAdmin { private Vector departments = new Vector(); // multiple departments might be connected private BillingService billingservice; private int inputcost; private int outputcost; public int inputcost() { return inputcost; public void inputcost(int intputcost) { this.inputcost = inputcost; public int outputcost() {return outputcost; public void outputcost(int outputcost) { this.outputcost = outputcost; public setdepartment(department dept) { departments.addelement(dept); public void setbillingservice( BillingService billingperformer) { this.billingservice = billingperformer; // implementation of the provided interface, i.e BillingWF public void onaccountinglog(string accountingfilename) { name = departments[0].getname(); 2.5 Composite components Composite components are a particular kind of components, because their implementation is not in charge of encapsulating a piece of software. It contains a configuration, i.e. the instructions related to the instantiation of components and their interrelationships expressed as interconnections. Operations described in composite components are thus: Instantiation of components The instantiation of components may happen at the deployment of the application (e.g. thefirstfilter) or later during execution using Darwin s notions of dynamic instantiation and lazy instantiation[mag96]. Components may also be instantiated dynamically by the application itself when contained in a collection[bel96]. Configuration of components attributes and execution properties, like the execution nodes or other non-functional properties. Interconnections of components. Interconnections describe how components are bound. Interconnections uses a connector, and thus the connectors rules and semantics must be checked. Composite are defined as follows with the same syntax rule as primitive components: 12

13 component = composite <component Identifier> { interface = <interface identifier>; configuration = <configuration identifier>; Composite are, from an external point of view, rather similar to any other component. The interface definition is similar to primitive components, however there are no implementation but a configuration which contains the instantiation of inner components, their interconnection and their customization. configuration <configuration identifier> { <configuration block>; configuration block = [+0 <constant declaration> <variable declaration> <assignment declaration> <instantiation declaration> <link declaration> <binding declaration> ] The content of a configuration declaration may be: constant declaration, variable declaration used mainly to store or set property values, assignment declaration to store values in variables, instantiation of components, binding of component and linking of a composite interface description to inner components interfaces Constants and Variables and Assignment Assignments can be used for: Defining a constant like using IDL notations Assigning values to a variable, like component variable or other kind of variables defined within a composite. Assigning values to properties within composite. The syntax for constant declaration is: constant declaration = #define <constant identifier> <expression> The syntax for variable declaration is: variable declaration = <type> <variable identifier>; type = <primitive type> <component identifier> The syntax for assignments is: assignment declaration = <variable identifier> = <expression> <property identifiers> = <expression> <collection declaration> property identifiers = <property identifier> <service identifier>. <property identifier> <components variable>. <property identifiers> components variable = <component variable> <collection element> 13

14 collection element = <collection variable> [ <collection index> ] <collection variable> [ * ] For property assignment, various property identifiers can be used whether the property belongs to the composite, the interface of a composite or to inner components already declared in the composite configuration block. An alternative syntax can be used for declaring variables and assigning a value immediatly: variable declaration = <type> <variable identifier> = <expression>; Instantiating inner components Instantiating a component means creating the component when the application is deployed. Such a creation loads the implementation of the component in case of primitive or the deployment of the configuration in case of a composite. However, there are some possibilities to create the component later after the deployment, for example when one of its service is first called or when the application itself decides to create dynamically a component. This two possibilities can be partially expressed in an ADL [Mag96] with the lazy instantiation or the dynamic instantiation instructions. In addition, OlanADL provides the notion of collection, a set of identical components that can be extended dynamically, where components can be addressed individually or globally. Collections are defined with the component that can be instantiated and the cardinality of the collection. collection declaration = <component identifier> <collection variable> = collection<cardinality>; Collection variables are compliant to a component definition, they can be thus used as any component. ( this is one explanation to the rule components variable above in the previous subsection). The cardinality is an expression defined as follow: cardinality = [ <range expression> ] range expression = <integer>.. ( <integer> * ) LogFilterAgent logfiltercollection = collection[0..*]; // collection that can be empty or contains at most an infinite number of component LogFilterAgent. The declaration of a component instantiation is defined by the following set of rules: instantiation declaration = <components variable> = new <component identifier> [ ( <parameters assignment> ) ] ; <components variable> = dyn new <component identifier> [ ( <parameters assignment> ) ] ; parameters assignment = <param assignment> [0+, <param assignment> ] param assignment = <property identifier> = <expression> <service identifier>. <property identifier> = <expression> 14

15 The new constructor corresponds to classical instantiation (i.e. at deployment time) where dyn new constructor stands for the lazy instantiation (i.e. creation when first used). // definition of two filter agent, the second one being created dynamically when first used LogFilterAgent myfirstfilter, mysecondfilter ; myfirstfilter = new LogFilterAgent( LogFilterItf.SRC_IP_ADDR = *.*, LogFilterItf.DEST_IP_ADDR = * ); mysecondfilter = dyn new LogFilterAgent(LogFilterItf.SRC_IP_ADDR = *, LogFilterItf.DEST_IP_ADDR = * ); The first rule corresponds to a well defined element of a collection, ranging from 0 to the collection maximum size. The second rule corresponds to the next free possible element of the collection LogFilterAgent filtercollection = collection [0..*]; filtercollection[2] = new LogFilterAgent(LogFilterItf.SRC_IP_ADDR = *.* ); filtercollection[*] = dyn new LogFilterAgent( LogFilterItf.SRC_IP_ADDR = *.*, LogFilterItf.DEST_IP_ADDR = * ); Connectors Connectors are the object ruling an interconnection. It is the one that contains the semantic of an interaction, thus defining the possible interconnections between components. Connectors cannot be defined explicitly in the ADL, they can only be used for interconnection purposes. Why? Connectors first describe the possible services that can be interconnected (through either service type conformity or service conformity). But connector identifies also the communication medium used at runtime by the component to communicate either locally or remotely. This medium is set up at deployment, whenever a binding between components is required. For example, the binding of two CORBA objects simply consists of setting the reference of a required object in the calling object implementation. In accordance to the way connector are defined in UniCon, each connector has a set of Players, which are the possible set of services that can be interconnected with the connector. Each player can be bound to a provision or a requirement, depending on the connector rules. In addition, each player define the type of the service that can be bound. The definition of players cannot be done since new connectors cannot yet be defined in OlanADL. However, the set of existing connector have been defined with players. Connector Definition connector definition = connector <connector identifier> [ : <connector identifier>] { <players> [1+, <players>] <connector implementation> Players characterize the services that can be interconnected to the component. Each player has the following definition. players = [default] (in out) <service type> [<service def>] <player identifier> ; service def = ( <abstract service identifier> <service identifier>) abstract service identifier= < identifier > 15

16 The in keyword identifies services that can be bound as input services to the connector, i.e required services. The out keyword stands for an output i.e. it can be bound to a provided services only. Default keyword indicates that the player can be used in a particular way as far as the binding of component is concerned. This will be detailed in the next sub-section. The : inheritance operator can be used to define a connector from another connector. Inheritance applies only to players: existing player in super connector are reused, while new players can be added. The implementation of a connector defines the operations that are executed whenever the binding of components is done at run-time. The implementation thus refers to the way binding of components should be realized. Implementation cannot be defined yet, only built-in connector implementation can be used. connector implementation = implementation { builtin Available Connectors Message passing between AAA Agents This first connector enable two components of type A3Service to be bound, whatsoever the service definition is. connector A3bus { default in A3Service input; default out A3Service output; implementation { builtin This second connector enable a typed communication between two components with services of type A3Service. The services connected on both side (in and out) must be identical, here identified abstractly by <A>. connector A3TypedBus { default in A3Service <A> input; default out A3Service <A> output; implementation { builtin CORBA invocation The available connector enables two component with services of type CORBAServices to be bound, with the condition of conformant services according to IDL definition of conformity. connector CORBAbus { default in CORBAService <A> input; default out CORBAService <A> output; implementation { builtin Interconnection Binding declaration = <default binding> <complete binding> Default binding = <components variable>.<requirement identifier> 16

17 => <components variable>. <provision identifier> using <connector identifier>; This first kind of binding can be used if the connector defines two default players, an in and an out players. The OlanADL definition of such a binding is illustrated below: myfirstfilter.accept => mysecondfilter.record using A3TypedBus; This second kind of binding can be alternatively used or defined if more complex connectors exists (i.e. connectors with multiple players) complete binding = <connector identifier> ( <players assignment> ) ; players assignment = <player assignment> [0+, <player assignment> ] player assignment = <player identifier> = <components variable>. <port identifier> port identifier = <provision identifier> <requirement identifier> The example below illustrates such a syntax. A3TypedBus(in = myfirstfilter.accept, out = mysecondfilter.record); In case collections are referenced instead of component variables, the syntax collection[*] indicates that all elements of the collection are connected. More refinement in addressing collection elements will be taken into account in the near future, such as using ranges of element index, (e.g. collection[1..6]) Linking Linking defines the mapping of what is defined at the interface level of a composite, and the components, properties and services defined inside the composite (in the configuration). It is how a composite component acts as the encapsulator of an inside configuration. <link declaration> = <provision identifier> => <components variable>. <provision identifier>; <components variable>. <requirement identifier> => <requirement identifier>; The first case corresponds to the linking of a provided service of the composite to a provided service of an inner component. The second corresponds to the linking of required components. record => myfirstfilter.record; mysecondfilter.reject => reject; Only One to one link are available today, but future work might introduce the notion of linker between one composite service to many services of inner components Example Composite Component Here is an example of a SubSystem component, which defines the configuration of a set of LogFilterAgent (as well as other agents). This composite component is taken from the C3DS demonstration configurations. interface LogMonitorItf { 17

18 A3Location location; provide LogStatusService logready; require LogStatusService logfinished; require LogFilterService sendrecords; provide LogReportService getreport; composite SubSystem { interface LogMonitorItf; configuration SubSystemImpl { #define TRANSIENT_NODE s0_trans #define PERSISTENT_NODE s0 #define OTHER_NODE1 s1_trans LogFilterAgent filter1, filter2; CounterAgent countercollection; LogMonitorAgent monitor; LogReporterAgent reporter; filter1 = new LogFilterAgent( location = TRANSIENT_NODE, logfilteritf.src_ip_addr= 129.*.*.*, logfilteritf.dest_ip_addr= *.* ); filter2 = dyn new LogFilterAgent (Location = OTHER_NODE1, logfilteritf.src_ip_addr= 130.*.*.*, logfilteritf.dest_ip_addr= *.* ); ); countercollection = collection[1..3]; countercollection[0]= new CounterAgent(location = TRANSIENT_NODE); countercollection[1]= countercollection[2]= ; // other instantiation monitor = new LogMonitorAgent(location = PERSISTENT_NODE, logmonitoritf.syncperiod = 30, logmonitoritf.logfiledirectory = ${DEMO_DIR/nwlogs/ // some interconnections logready => monitor.logready; monitor.logfinished => logfinished; monitor.sendrecord => filter1.report using A3TypedBus; filter1.accept => countercollection[0].report using A3TypedBus; filter1.reject => filter2.report using A3TypedBus; filter2.accept => countercollection[1].report using A3TypedBus; filter2.reject => countercollection[2].report using A3TypedBus; countercollection[*].filteredrecords => Reporter.filteredRecords using A3TypedBus; reporter.reportready => monitor.getreport using A3TypedBus; 2.6 Architecture An architecture is a composite component that will instantiated and configured at deployment time. There is no particular concept or syntax in OlanADL to define an architecture. 18

19 3 Graphical Notation The OlanADL has not been implemented first as a textual language, but rather through a set of graphical tools enabling the complete process of : Defining components and the encapsulation of their source code Defining a distributed software architecture Deploying the architecture on a set of nodes Monitoring the architecture once deployed and executing. Such tools relies on a graphical user interface, and the language constructs and declaration are done graphically by the distributed application architect. For this reason, a graphical notation has been introduced in order to enable this architect to easily define and manipulate an architecture. The graphical notation is explained in this section 3.1 Services IDL Service JRemoteService A3Service ARIRemoteService 3.2 Components Interfaces The graphic distinction between provided and required services is done by adding an in or out arrow within the shape of the service. The LogFilterAgent is then displayed as follow: provided LogFilterService record required LogFilterService reject required LogFilterService accept 19

20 provided A3Service required A3Service provided CORBAService required CORBAService Properties Properties are displayed in a separate frame as a list of typed name-value pairs. 3.3 Composite Component Configurations The representation of a composite is a box with services on its border, but instance of component are drawn within the box. Representation of identifiers scope It is defined by all the available components that can be instantiated within a component. Instantiation of inner components and collections Identifiers scope Instantiation Set the properties values 20

21 Binding of inner components A3bus binding loglistener logproducer Linking between the composite and the inner components Composite: local stats analysis Inner component: Netwall monitor 21

22 2. References [All94] Allen R., Garlan D., "Formal Connectors", CMU Tech. Report CMU-CS , School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213, USA, March [Bal98] Balter R., Bellissard L., Boyer F., Riveill M.and Vion-Dury J.-Y., Architecturing and Configuring Distributed Applications with Olan, Proc. IFIP Int. Conf. on Distributed Systems Platforms and Open Distributed Processing (Middleware 98), The Lake District, September 1998 [Bel96] Bellissard L., Ben Atallah S., Boyer F., Riveill M., "Distributed Application Configuration", in Proc. of the 16 th IEEE Intn l Conference on Distributed Computing Systems (ICDCS 96), Hong Kong, April 1996 [DeR76] DeRemer F., Kron H.H., "Programming-in-the-large vs. Programming-in-the-small", IEEE Trans. Software Engineering, vol.se-2(n.2), June 1976, pp [Gar95] Garlan D., "First International Workshop on Architectures for Software Systems: Workshop Summary", ACM SIGSOFT Software Engineering Notes, SEN [Iss96] Issarny V., Bidan C., "Aster: a Framework for Sound Customization of Distributed runtime Systems", Proc. Of the 16th IEEE Intn l Conference on Distributed Computing Systems (ICDCS 96), Hong Kong, April [Iss98] Issarny V., Saridakis T., Zarras A., «A Survey of Architecture Description Languages», C3DS Deliverable A3.1, ESPRIT LTR Project N 24962, pp.8-28 [Kra89a] Kramer J., Magee J., Sloman M., "Constructing Distributed Systems in CONIC", IEEE Trans. Software Engineering, vol.se-15(n.6), June 1989, pp [Kra89b] Kramer J., Magee J., Ng K., "Graphical Configuration Programming", IEEE Computer, vol.22(n.10), Oct. 1989, pp [Luc95] Luckham D. C., Vera J., "An Event-Based Architecture Definition Language", IEEE Trans. Software Engineering, vol.se-21(n.9), September 1995, pp [Mag93] Magee J., Dulay N., Kramer J., "Structuring Parallel and Distributed Programs", IEE Software Engineering Journal, vol.8(n.2), March 1993, pp [Mag94a] Magee J., Dulay N., Kramer J., "A Constructive Development Environment for Parallel and Distributed Programs", in Proc. of the IEEE Intn'l Workshop on Configurable Distributed Systems (IWCCS'94), Pittsburgh PA, USA, March [Mag94b] Magee J., Dulay N., Kramer J., "Regis: A Constructive Development Environment for Distributed Programs", IEE Distributed Systems Engineering Journal, vol.1(n.5), Dec. 1994, pp [Mag96] Magee J, Kramer J, «Dynamiuc Structure in Software Architectures», Proc. of ACM SIGSOFT 96 Symposium on Fundations of Software Engineering,

23 [Mag97] Magee J., Tseng A., Kramer J., "Composing Distributed Objects in CORBA", in Proc. of Intn l Symposium of Autonomous Distributed Systems (ISADS 97), Berlin, April 97. [Medv97] Medvidovic N., Oreizy P?, Taylor R., «Reuse of off-the-shelf components in C2-style architectures», Proc. of the 1997 Symposium on Software Reusability [Ng95] Ng K., Kramer J., Magee J., Duay N., «The Software Architect s Assistant A Visual Environnement for Distributed Programming», in Proc. of HICCS-28, Hawaii, January [Nie95a] Nierstrasz O., Dami L., "Component-Oriented Software Technology", in Object-Oriented Software Composition, Eds. Nierstrasz O. and Tsichritzis D., Prentice Hall, Englewood Cliffs NJ USA, 1995, pp.3-28 [Nie95b] Nierstrasz O., Meijler T. D., "Research Directions in Software Composition", ACM Computing Surveys, vol.27(n.2), June 1995, pp [Perr89] Perry D., Wolf A., «Foundations for the study of software architecture», ACM SIGSOFT Software Engineering Notes 17(4), 1992 [Pur94] Purtilo J. M., "The POLYLITH Software Bus", ACM TOPLAS, vol.16(n.1), Jan. 1994, pp [Rog97] Rogerson D., "Inside Com", Microsoft Press, One Microsoft Way, Redmond WA USA, 1997, ISBN [Sha95] Shaw M., DeLine R., Klein D. V., Ross T. L., Toung D. M., Zelesnik G., "Abstractions for Software Architecture and Tools to Support Them", IEEE Trans. Software Engineering, vol.se- 21(N.4), April 1995, pp [Shaw96] Shaw M., Garlan D., «Software Architecture: Perspectives on an emerging discipline», Prentice Hall [Soinne97] F. Soinne, "Netwall Version 3.2", Bull Whitepaper, available at 23

24 24