Distributed Component-Based Systems1 Introduction2 Background2.1 Component Based Frameworks2.2 COTS-Based Systems2.3 Testing and Validation of Mobile Agent Systems3 Exploration of Component Based Systems3.1 Developing Sophisticated Applications with Component Based Frameworks3.1.1 Reuse through framework3.1.2 The development of framework3.1.3 Framework and design patterns.3.1.4 Framework behind the aglet system.3.1.5 OO implementation strategy3.1.5.1 Composition3.1.5.2 Inheritance3.1.5.3 Polymorphism3.1.5.4 Generic3.2 COTS-Based Systems3.2.1 CHALLENGES3.2.2 Frozen functionality3.2.3 Incompatible upgrades3.2.4 Trojan horses3.2.5 Defective or unreliable COTS software3.2.6 Complex or Defective Middleware3.3 Testing and Validation of Mobile Agent Systems4 Conclusions and Future WorkDistributed Component-Based SystemsA. Paul Heely Jr.Kun LuTing ZhouApril 25, 19991 IntroductionAs software systems grow larger and more complex developers continue to look for new ways to build these systems. One method currently being used is building of systems out of software components. A component can be any piece of self contained code (agent, Java bean, widget) that provides a published interface and a certain set of behaviors. The hope is that developers can then use different components to build the needed systems by simply providing the glue that holds all the components together.In this paper we look a three different areas of current component based design. First we look at existing component based frameworks and how they are being used. We then look at other Commercial Off the Shelf Systems (COTS) and how these can be applied to the component based methodology. Finally we look the testing and validation issues involved in trying to use agents in a component based way.2 Background2.1 Component Based FrameworksComponent frameworks are an increasingly popular strategy to provide guidance for application-level semantics or structure - how to design and arrange specific components to solve specific problems. Framework is build up with general components,which represent commonality or knowledge in a domain. We build our various application softwares by customizing the framework. This in essential reuses the framework. The framework must be robust, generic, and stable. The OO methodology provides good support to build framework with those properties. We will analyze those characters of OO methodology and find out how they support framework. We also Page 2 of 34explain why the aglet system is a very good example of framework. Base on those discovers, we will understand what we can do in the future.2.2 COTS-Based SystemsA new trend in software commerce is emerging: generic software components, also called commercial-off-the-shelf (COTS) components, that contain fixed functionality. COTS components can be incorporated into other systems still under development so that the developing system and the generic components form a single functional entity. The role of COTS components is to help new software systems reach consumes more quickly and cheaply. With COTS components, the functionality you desire can be - Accessed immediately.- Obtained at a significantly lower price.- Developed by someone expert in that functionality.Although on the surface "the COTS solution" appears straightforward and compelling, projects that apply COTS find its use less than straightforward. Rather, they encounter significant new trade-offs and issues. Applying COTS products is not merely atechnical matter for system integrators. It has a profound impact on business, acquisition,and management practices, and organizational structures. Nowadays, common maintenance processes originated when most systems were comprised of subroutines and procedures formatted in source code. Typical maintenance on such systems would include impact analysis, which determines if and how different Page 3 of 34system parts interact, and regression testing, which uses test code inputs from earlier versions to ensure system integrity after maintenance. For such systems, impact analysis was another procedure and could thus be used to limit re-testing to relevant procedures. However, these traditional maintenance procedures, which rely on source code visibility, are insufficient to contend with the maintenance demands of component-based development. The growing use of COTS components is fueled by object-oriented design and will drastically change how we build and maintain systems. When these components are incorporated into a system, maintenance becomes much harder because source code is either partially of completely invisible. For example, most applications built for Windows NT application, you have effectively teamed with hundreds of Microsoft's developers. However, when the application needs maintenance, you become a one-person team.Clearly, component-based development forces us to rethink our maintenance technologies. This paper focuses on the issues and complications that arise when maintaining complex systems with COTS component. If we are COTS vendors, for example, we must think not just of maintaining a block of source code in a specific application, but of maintaining code that is reused in numerous customer applications. Because each application may have slightly different requirements, component modifications may not work for all applications. If we are component integrators, we must think in terms of technologies that will let us maintain the entire system. If the components are "black boxes", visibility is limited to documentation that describes the component's operation and functionality. Although maintaining unfamiliar code is a Page 4 of 34common maintenance dilemma, maintaining systems filled with black boxes adds a new level of difficulty.2.3 Testing and Validation of Mobile Agent SystemsA growing trend in large distributed software systems is the use of multi-agent systems. An agent is an entity that acts autonomously, under its own control, to solve a particular problem. An agent communicates with other agents and the rest of the world by sending and receiving messages. Agents can be humans interacting with a software system or an actual piece of software.Our ability to design and build multi-agent systems has out-paced our ability to test and validate them. Multi-agent systems pose additional difficulties in testing and validation when compared to more traditional stand-alone pieces of software. The
View Full Document
Unlocking...