Distributed Component Based Systems

1. Distributed Component Based Systems A. Paul Heely Jr. Kun Lu Ting Zhou

2. What are components? • Units of self-contained code (Java beans, widgets, agents) • Provide a published interface. • Public methods • Return types • Provide “guaranteed” behavior. • Component provides a certain service

3. Why are components becoming popular? • Reduce development time. • Developers buy pre-built components • Domain specific components built by domain experts. • No need to learn a new domain for a single component. • Application builders glue together individual components

4. Current Component Based Designs • Component Frameworks • Aglets • COTS Components • Development Issues • Pros and Cons • Testing & Validation of Mobile Agents • Ensuring agent based systems operate correctly

5. What is an Agent? • Entity acting autonomously • Operates under it’s own control • Usually designed to solve a particular problem • Interacts with rest of the world by sending and receiving messages

6. Testing & Validation Issues • Agents do not fit into existing testing & validation methods • Identification of undesired behavior between agents • Mobility • Agent must be validated on all target platforms, even if agent is written in Java • Messages sent between agents could be lost • Agents being transmitted across the network could be lost

7. Testing & Validation Methods • Static • Analyze the design specification or source code itself • Trace flow of control trough an agent • Trace flow of control between agents • Dynamic • Operates on a running piece of code • Pre-determined test cases • Run-time verification

8. Goals • Problem • The fact that an individual agent of component works correctly in it’s own isolated test environment leads to no guarantee that a group of entities interacting together is going to operate properly. • Solutions • Extend existing testing and validation methods to work with agents • Method/Message Path • Runtime Validation

9. Method/Message Path (MM-Path) • Path starts with a method call • Ends when a method is called that does issue any method calls of its own • Paths consist of linked method-message pairs inside an object or across a network of objects • Paths can interleave and branch off creating new paths

10. Example MM-Path A input event A output event meth1 1 meth2 meth2 meth3 B input event meth1 B output event 2 meth1 meth3 meth2 MM-Path Message

11. Usefulness of MM-Paths • Identify undesired behavior • Chain reactions where an input event generates the expected output event and generates and unexpected output event

12. MM-Path Identifying Undesired Behavior A input event A output event meth1 1 meth2 Undesired output event meth2 meth3 B input event meth1 B output event 2 meth1 meth3 meth2 MM-Path Message

13. Problems With MM-Paths • How to model agent systems so MM-Path analysis can be done? • MM-Paths and UML collaboration diagrams similar • OMG Agent Working Group currently looking at ways to model agent systems • Specifically interactions between agents

14. Runtime Validation • What does runtime validation do? • Checks behavior of entity at runtime • Catches implementation errors that static testing miss • Catches faults as a result of the failure of another component. • Why is this necessary? • Autonomous agents are responsible for their own behavior • Wide range of sources • No guarantee that other agents work correctly

15. Specifying Behavior • Specification language designed for non-programmers • Runtime behavior specified at design time • Valid state transitions • Timing between transitions • Example of this is TSpec

16. Stop Light State Diagram duration(2,6) yellow duration(15,60) red green duration(10,70)

17. Stop Light Specification statemachine StopLight (color) { states{red, yellow, green} transitions { red -> green; green -> yellow; yellow -> red; } limits { duration (red, 15, 60); duration (yellow, 2, 6); duration (green, 10, 70); } }

18. Stop Light Specification • TSpec compiled into target system code • Becomes an integral part of the runtime system • Specification can be easily changed without effecting rest of system • Currently being used by NASA Ames Research Center to validate autonomous flight control systems • Implemented in C++ using an observer pattern

19. Problems With Runtime Validation • Many agent systems written in Java • What are the performance implications of runtime validation • Will the validation system have access to all the agents data? • C++ hacks allow access to any part of an object • Embedded validation increases an agents size • Will increased size adversely affect transmission time?

20. Developing Sophisticated Applications with Component-Based Framework Kun Lu For presentation in CSE300 Instructor: Steve A. Demurjian lukun@engr.uconn.edu http://www.engr.uconn.edu/~lukun (860) 486 - 2717

21. Motivation • Force Reusing - build application-specific software product by customizing framework • Forced to consider reuse • Framework is a good carrier of design pattern • Help to build robust software • Separate the development of software into two relative independent cycles and reduce the maintain effort • Possible to be developed by two group of software engineer

22. Components • Three classes of components • Domain-independent • Libraries, utilities, etc. • Most likely to be reused • Domain-specific • Dedicated components • Reused in software of the same domain • Application-Specific • Uniqueness in some final product • Unlikely to Be Reused

23. Reuse through Framework • Software products in a specific domain must have commonness • Build commonness into a platform - framework • The final software product is built by customizing the framework • Framework consists of domain-independent and domain-specific components

24. Requirement of Framework • Generic • Adopted in various situation • Flexible • Easy to customize

25. Design Patterns • An especially clever and insightful way of solving a particular class of problems • Design patterns can be incorporated into the framework • Reuse pattern through framework

26. Framework Development and Maintenance • Two way to start building framework: • Find commonness among various software products and ‘frame’ those commonness - a passive way • The commonness could be general class or design pattern • Anticipate reuse in advance and build framework from beginning - an active way • Some cost at beginning, but save in the long term

27. Framework Development and Maintenance(Cont.) • Two independent development and maintenance cycles • Framework development and maintenance • Application development and maintenance • Two independent corresponding groups of software engineers • Framework software engineers • Only concern about the general component and patterns • Application software engineers • Deal with the customizing, and adopt changes of requirement of the user • Those two groups many be of the same

28. Framework Development and Maintenance(Cont.) • What does the independence mean? • Framework software engineers provide application software engineers with only the compiled components as well as interface and necessary document. No source code. • Application software engineers can not modify the framework source code directly(encapsulation) • If framework is robust and there is bug in the final product, it must be in the customizing work(isolation) • Framework can be sold as an independent commercial software without publishing its source code.(commercializable) • Application software engineers only write their own code to customize framework into final product

29. Framework Development and Maintenance(Cont.) • What is the benefit? • Isolate concerns • The application software engineers only has to concern about the changes of requirement by the user. • Isolate changes • The changes usually be adopted within the customizing work, no need to modify framework. • break the job • Framework software engineers and application software engineers may be of different companies. Since customizing work cost less effort, user company may hire a small group of application software engineer. Easy to react to the change.

30. Framework Development and Maintenance(Cont.) • Signs of deficiency in frameowork • Application software engineers feel awkward to customize • Unnecessary dependence between some components • Too specific interface • Application software engineers have to repeat something over and over • Something general should be augmented into the framework

31. Framework Behind the Aglet System • Aglet system is a framework for mobile agent • Include general class like aglet, message, context, etc • Generate our own mobile by customizing the default aglet,etc • Aglet system encapsulate the complex of mobile agent • Serialize and deserialize when dispatch • Multithread • Message sending • Much easier to customizing than building from scratch

32. Aglet - a Design Pattern • It is possible to write distributed computation from scratch with JAVA, but it is too complex, and easy to go mad • Aglet provides a rigorous basic element to implement distributed computation software • How comes the aglet? • Try different way to implement distributed computation software • Find a rigorous pattern or component. • Introduce new concept - aglet and implement it with JAVA in aglet framework

33. Problem with aglet • It is still a quite basic element or pattern • It is still easy to get out of control if used in a non-regulated way • Violate the security rule • Lost in the net • We have to find higher level of pattern to control the aglet and implement it in the higher level of framework • The aglet book mentions some design pattern to control the aglet • Higher level of pattern is quite domain-oriented

34. OO implementation Strategy • OO provide us with enough ability to build generic and flexible frame work • Customizing is a kind of change and we must make it easy to adopt change • Two rules: • Separate the things that change from the thing that stay the same • Put the same things together to avoid duplication • Purpose • easy to find where to change • change will not propagate to far or repeat

35. Compository • Most encountered reuse • Create object of existing A class into a new class B • A Could be data member or in the method of B • We can build a compository hierarchy • Higher level of class reuse the lower level class • Example • IRA is a data member of UA

36. Inheritance • Cornerstones of OO method • Superclass is reused in all its subclass • Superclass is the common part of its subclass • Do not have to be repeated in each subclass • Example • Build our own aglet by subclass the default class

37. Polymorphism • Based on inheritance • Help to isolate change • Subclass can be treated as its superclass(Upcast) • A subclass object hold by a superclass reference can be downcast to its real class • Dynamic binding • Subclass override superclass’s method • At runtime, it is the method of the object’s real class call

38. Dynamic Binding A Compile CourseDB CourDB Person person person.getType( ) Person getType( )

39. Dynamic Binding(Cont.) A Compile CourseDB CourDB Person person person.getType( ) Person getType( ) Runtime Student getType( ) Faculty getType( ) Not CourseDB need not be recompile

40. Dynamic Binding(Cont.) • What does that mean? • We can build framework with general classes and have them compiled • We customize the framework by subclass those general class and overriding method • By polymorphism, at runtime, it is the overriding method of the subclass that are run • We do not have to recompile those general class in the framework and we do not need the source code! • Framework software engineer can use something like final to avoid override method which they do not expect application software engineers to override

41. Dynamic Binding(Cont.) • In aglet, polymorphism is heavily exploited • Why you must use the prescribed interface? • Why at run time it is the your subclass with those override methods are run even though you never explicitly call them? • The Aglet system build can not direct call your customized methods because they do not know them

42. Generic • Note that application software engineers must use the prescribed interface.(Like a socket) • The interface must be general enough to satisfy various polymorphism • The key for generic interface is its argument type, argument number and return type • A ‘stone face’ • real methodname(int)

43. Generic(Cont.) • The most general interface in JAVA • Object methodName(Object). • Example: • Object handleMessage(Message) • void onCreation(Object) • In Java, everything is subclass of Object class. However, it is not true for C++. What could C++ do? • Though C++ has template, it does not mean the generic ability of C++ is stronger than JAVA • In fact, there is no need to have template in Java • Template for C++ is only are remedy for generic

44. Maintaining COTS-Based Systems Ting Zhou† Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 zting@engr.uconn.edu http://www.engr.uconn.edu/~zting (860) 486 - 0130

45. COTS Components • COTS Components • Commercial-Off-The-Shelf Components • Contain Fixed Functionality • New Trend in Software Commerce • Role of COTS Components • Make Development of New Software Systems More Quickly and Cheaply • With COTS Components, the Desired Functionality Can be • Accessed Immediately • Obtained at a Significantly Lower Price • Developed by Someone Expert in That Functionality

46. Fundamental Changes • Fundamental Changes Occur in COTS-Based System • Source Code of COTS Components is Either Partially or Completely Invisible • System is Composed of Building Blocks that May or May not Work Cooperatively Directly

47. Fundamental Changes (Cont.) • This Shift from development to Composition Causes • Numerous Technical and Business Changes • Profound Impact on All Lifecycle Activities • Specified Requirements Must be Sufficiently Flexible • What Level of Testing are Possible or Needed Must be Determined • Maintenance Changes in Fundamental Ways(in details later)

48. Traditional Maintenance • Common Maintenance Processes • Originated When Most Systems were Comprised of Subroutines and Procedures • Rely on Source Code Visibility • Typical Maintenance Includes • Impact Analysis • Determines If and How Different System Parts Interact • Regression Testing • Uses Test Code Inputs from Earlier Versions to Ensure System Integrity after Maintenance

49. New Issues in Maintaining COTS-Based Systems • Development of COTS-Based System Forces Us to Rethink Maintenance Technologies • Issues and Complications Arise in Maintenance COTS-Based Systems • COTS Vendors Need to • Not Only Just Maintain a Block of Source Code in a Specific Application • But Also Maintain Code That is Reused in Numerous Customer Applications • COTS Integrators Need to Maintain Systems Filled with Black Boxes

50. Why So Hard to Maintain COTS-Based Systems • Frozen Functionality • Occurs When a Vendor Either Goes Out of Business or Stops Supporting the Component • Can Make Application Which Needs Periodic Updates Unmaintainable • Example: System with a Parser Component that Requires Modifications Each Time the Language Changes • Incompatible Upgrades • Occur when Software Vendors Upgrade and Maintain Components That Do not Align with Your Demand • Can Make a Component One Day Become Incompatible with Rest of the System