A Component-based Environment For Distributed Configurable Applications

1. A Component-based Environment For Distributed Configurable Applications Ahmed Saleh, George R. R. Justo and Stephen C. Winter Centre for Parallel Computing University of Westminster, London, UK. http://www.cpc.wmin.ac.uk

2. Overview • 1- Problems of developing distributed configurable applications based on their non-functional requirements. • 2- An environment for supporting the development of distributed configurable applications. • 3- The NCSL (Non-functional requirements components specification language) and NADL (Non-functional requirements architecture description language). • 4- Conclusions. • 5- Current state and Future work. ECBS2002 11 April 2002

3. 1- Problems of Developing Distributed Configurable Applications • . Design & Management. • . Extension & Reusability. • . Non-functional requirements. 2- An Environment for Developing Distributed Configurable Applications with Non-functional Requirements. • The explicit construction of the system architecture. • The separation of concerns of the system. • The introduction of management components and dynamic reconfiguration. • The definition of a clear IDL and ADL can help in understanding and reusing the system. • An explicit representation of the application’s non-functional requirements at the early stages of the design. ECBS2002 11 April 2002

4. An Overview Of The Environment NCSL Repository NCSL Compiler Global Manager Interface n Interface n Interface n Interface 1 Event System Component n Component n Component n Component 1 Local Manager n Local Manager 1 Connector n Connector 1 Configuration Manager Framework Structure NADL Repository XML Configuration NADL Compiler ECBS2002 11 April 2002

5. 3(a) - NCSL: A Non-functional Requirements Component Specification Language interface GoldBranch { //-----------------------------------------------// // Services provided by the component with their // // associated non-functional requirements // //-----------------------------------------------// provide float checkBalance ( int customerID, int customerPIN ); support{performance && availability}; provide void withdrawCash (int customerID, int customerPIN, float value ) ; support { availability && performance }; //-----------------------------------------------// // Services required by the component with their // // expected non-functional requirements // //-----------------------------------------------// require float getBalance ( int customerID, string customername ); with {performance >= 500 Kb/sec && availability >= 500 mesc } ; require void updateBalance ( int customerID, float value) ; with { reliability > 750 mesc && availability = 500 mesc } ; } • A language for creating independent • Components interfaces • Services required/provided by each component. • The non-functional requirements associated with each service. • - Performance • - Reliability • - Availability • NcslToJava compiler ECBS2002 11 April 2002

6. 3(b) - NADL: A Non-functional Requirements Architecture Description Language Application : Bank { select { component: Comp1 { interface: MainBank ; location: remote (osiris.cpc.wmin.ac.uk) ; properties: { (getBalance.performance>= 500 kb/sec || checkBalance.availability >= 5000 msec }; }; // End Comp1 // connector: Conn1 { interface: GoldConnector ; properties: { dataStream.availability>= 800 msec && dataStream.reliability> 750 msec }; } ; // End Conn1 // } ; // End select // constraints: { Comp1.Performance >= 4000 Kb/sec ; propertiesCheckupRate>= 4000 mesc ; }; implementation: {Bank.Platform = java; //App platform Bank.OS= Unix;};//OS for running the app // configuration: { conf1: when (select) ; do (connectComp1.getBalance ToConn1.dataStream; connect Comp3.withdrawCash ToConn2.dataStream); conf2: when (Comp3.checkBalance.availability < 600 ms); do ( wait (3000); reselect;) } ; // Repeat ‘select’ process reconfiguration: { when ( Comp1.getBalance.performance< 5000 Kb/sec || Comp1.getBalance.availability< 5000 msec); do ( start ; suspend ; stop Comp3.checkBalance ; stop Comp3.withdrawCash ; resume ; end) ; }; } // End reconfiguration // End Application // • A language for defining the • structure of the application. • The components/connectors of the application • The non-functional requirements of the application • The Application’s constraints and implementation rules • Different configurations of the application • Expected reconfigurations of the application ECBS2002 11 April 2002

7. 4 - Conclusion 5 - Current State and Future Work • The combination of software architecture concepts with object-oriented frameworks and language mechanisms can lead to the development of a new generation of configurable applications. • The separation of concerns and modularity of distributed applications play an important role in the reusability of such applications. • We are currently in the process of incorporating dynamic reconfiguration into environment. • Investigate the use of intelligent mobile agents to allow the automatic reconfiguration and customisation of the framework components. • Further evaluation of the framework by developing complex multimedia applications. ECBS2002 11 April 2002