Interoperability is a key issue for a wider adoption of mobile agent systems (MASs) in heterogeneous and open distributed environments where agents, in order to fulfill their tasks, must interact with non-homogeneous agents and traverse different agent platforms to access remote resources. To date, while several approaches have been proposed to deal with different aspects of MAS interoperability, they all lack the necessary flexibility to provide an adequate degree of interoperability among the currently available MASs. In this paper, we propose an application-level approach grounded in the software layering concept, which enables execution, migration and communication interoperability between Java-based mobile agent systems, thus overcoming major setbacks affecting the other approaches currently proposed for supporting MAS interoperability. In particular, we define a Java-based framework, named JIMAF, which relies on an event-driven, proxy-based mobile agent model and supports interoperable mobile agents which can be easily coded and adapted to existing MASs without any modifications of the MAS infrastructures. Results from the performance evaluation of MAS interoperability was carried by using JIMAF atop Aglets, Ajanta, Grasshopper, and Voyager, demonstrating that the high-level JIMAF approach offers high efficacy while maintaining overhead at acceptable levels for target computing environments.

Achieving Mobile Agent Systems interoperability through software layering

The report is the result of a course for PhD students on software architecture. An overview of the state of the art is presented. Discussed topics include describing, evaluating and designing architectures, product-line architectures, object-oriented frameworks and component-based software engineering.

Software Architecture : An Overview of the State-of-the-Art

What is the nature of the process of implementing a new technology? How should the dynamics of implementing a new technology be studied? What research methods are best-suited to the study of complex issues of social and organizational impacts arising from the implementation of a new technology? Clientserver computing represents a significant new technology that has not been a focus of research investigations. As companies pursue client-server technology as a replacement for legacy computing systems, there is a need to provide practitioners with grounded research that discover patterns of organizational and social dynamics that influence the successful outcome of a transition to this new technology. This article suggests that naturalistic research studies can formulate realistic business foundations for the successful implementation of client-server computing. This article is available in The Qualitative Report: http://nsuworks.nova.edu/tqr/vol4/iss1/2 Establishing the Research Foundations for Successful Client-Server Computing: What Naturalistic Studies Could Contribute by Patricia Y. Logan and Charles M. Lutz The Qualitative Report, Volume 4, Numbers 1 & 2, January, 2000

https://nsuworks.nova.edu/cgi/viewcontent.cgi?article=2084&context=tqr

Establishing the Research Foundations for Successful Client-Server Computing: What Naturalistic Studies Could Contribute

ion is simply the ignoring of the irrelevant pieces and focusing on the pieces that are important. In software, a representation of some thing is created. It is not the real thing and it is much less complex by focusing only on the attributes and behaviors that are important to the application. In object-orientation, the term “class” or “type” is commonly used to describe a unique category of things, while the term “object” is used to denote an instance of a particular class. An example of this is the class “car”. This category would be defined by the attributes (color, number of passengers, number of wheels, engine size) and the behaviors (go, stop, breakdown) that are thought to be important. Attributes and behaviors are allocated to the abstraction in terms of the level they exit at. Most attributes are instance attributes because they can change from one instance to another. Color is a good example of an instance attribute because you see cars in many different colors. If it were assumed that all cars have only 4 wheels, then Has The Object Oriented Paradigm Kept Its Promise? Page: 16/106 this may be deemed a class attribute. All car instances contain the same value for this attribute. If the value changes, it changes for all instances. This same allocation between class level and instance level can be made to class behaviors also. If an instance method is performed, that behavior only occurs to the single object, whereas if a class method is executed, the behavior is performed for all object instances. Let’s be glad that breakdown isn’t a class behavior, it already takes forever to get your car fixed and back from the mechanic. C. Encapsulation Encapsulation is also commonly referred to as “Information Hiding”. In the previous section we talked about how the attributes and behaviors of a class distinguish it from all other classes. Encapsulation deals with permitting or restricting a client class’ ability to modify the attributes or invoke the methods of the class or object of concern. If a class allows another to modify its attributes or invoke its methods, the attributes and methods are said to be part of the class’ public interface. If a class doesn’t allow another to modify its attributes or invoke its methods, those are part of the class’ private implementation. A “Queue” provides a good example of this characteristic. A queue is an abstract concept that represents an ordered list of things. The implementation of a queue may by an array or it may be by a linked-list. If the implementation were known, a developer writing a client of the queue class may use this knowledge and directly access the internal storage mechanism. If the implementation changed, the client would then have to be modified also. This type of tight coupling between classes would cause a very brittle system and would increase maintenance costs as parts of the system were modified. Therefore, the levels of encapsulation that a language supports and how those mechanisms are used directly impacts the level of coupling between classes and it can significantly affect the cost of maintenance in an application. D. Hierarchy In the pursuit of defining abstractions, it is realized that some types have many of the same attributes and/or behaviors as other classes. Classification in most scientific exploits commonly deals with one type being a specialization or generalization of Has The Object Oriented Paradigm Kept Its Promise? Page: 17/106 another. A dog is an animal; a cat is an animal. There are different types of dogs and cats. If the process of classification normally exhibits a hierarchy, shouldn’t the abstractions used in software development also exhibit and benefit from this feature. Hierarchy is another mechanism for reducing the complexity of software by being able to treat and express sub-types in a generic way. This hierarchy is implemented in software via a mechanism called “Inheritance”. Just as a child inherits genes from its parent, a class can inherit attributes and behaviors from its parent. The parent class is common referred to as the super-class and the child class as the sub-class. Another implementation feature of the hierarchy characteristic is referred to as “Generics or Generic Units”. An example best serves to illustrate this concept. Using the idea of a “Queue” class as described above. It wasn’t mentioned the type of objects that the queue held. If the current project needed a queue of integers, the queue would be implemented with that type. What would happen if the next application were a simulation of a line of customers for a bank teller? The queue class would have to be re-written, this time with the Customer type instead of an integer. Obviously having to re-write this abstraction with all of the different permutations of contained items is not in the best interest. E. Modularity Modularity is probably is the most common term of everyday language used in defining the characteristics of object-orientation. Webster’s dictionary defines modular as “designating or of units of standardized size, design, etc. that can be arranged or fitted together in a variety of ways.” Even Booch defines modularity as “the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” Modularity simply means the physical partitioning of the application where as abstraction is the logical partitioning. A module can be considered a class, a file, a package, or almost anything. The issue with these definitions is that while they explain what modularity is, they don’t explain how to achieve the qualities of “cohesive” or “loosely coupled”. The quality of a module is completely dependent upon the ability of the person constructing it. Bertrand Meyer has probably addressed the term modularity and the development of modules to the most extent of anyone. He defines five criteria of Has The Object Oriented Paradigm Kept Its Promise? Page: 18/106 modularity as Decomposability, Compos-ability, Understandability, Continuity, and Protection. Therefore, a key to how well modularity can be achieved is how restrictive or permissive the definition of a module is, in a language implementation. A module is the primary mechanism for reuse. F. Typing Typing commonly refers to how stringent a compiler is when determining whether or not a type has a specific attribute or operation when called by the source code. For example, our “Car” class has the operation “go” but does not have an operation “speed”. If a software developer attempted calling “speed” on a car instance, the style of typing determines where this error would be caught. Strong typing means that the error would be caught at compilation time while weak typing means that the error would be caught at runtime. Typing is also associated with characteristic of hierarchy. If a super-class defines a public method, a sub-class has the ability to redefine that method in terms of the behavior desired in the sub-class. An example of this is a class “Animal” with a method called “speak” in its public interface. There are two sub-classes of “Animal”, “Dog” and “Cat”. Class “Dog” may override the “speak” method to produce a barking sound while class “Cat” will override the method to produce a meow sound. Polymorphism is the ability of two classes to react differently to the same message. G. Software Development Software development is similar to most other types of construction processes. A complex problem is encountered; a solution is deduced; then construction of the solution occurs. When performing these steps in software development, we commonly refer to them as analysis, design, and implementation. “Object-orientation” in a software development process then means we focus on types, characteristics, and behavior as we perform each of the steps, object-oriented analysis (OOA), object-oriented design (OOD), and object-oriented programming (OOP). The fact that we tie each of these steps together in an object-oriented fashion, that the solution domain is expressed in the same Has The Object Oriented Paradigm Kept Its Promise? Page: 19/106 types as the problem domain, is referred to as seamless-ness. The existence of the objectoriented characteristics in a software development language has a significant impact on the design process, as the design is “the disciplined approach we use to invent a solution for some problem.” If the implementation language lacked a specific characteristic, specifying or making use of that characteristic in design would make very little sense. As detailed in the introduction to this document, proponents expressed numerous promises to the adopters of the object-oriented paradigm. The incidence matrix below shows the relationship between the promises made and the characteristics of objectorientation. An “X” mark indicates a correlation between the existence of a characteristic and the ability to realize a promise. This chart will also help show how the selection of an object-oriented programming language may impact which promises may be realized as each language supports to a varying degree a sub-set of the characteristics of objectorientation. C om pxity N atualness R euse Exsibility Esier Tsting Less M ainnance M re ow eful M oeling Abstraction X X X X X Typing X X X Encapsulation X X X Hierarchy X X X X X Modularity X X Xion X X X X X Typing X X X Encapsulation X X X Hierarchy X X X X X Modularity X X X Has The Object Oriented Paradigm Kept Its Promise? Page: 20/106 H. Language Comparisons The following language comparisons have been adapted from the comparisons that Booch (1994) created in his book. They have been modified to incorporate the characteristics identified above and updated to reflect the current state of popular object oriented languages. Ada95 Abstraction Instance variables Instance methods Class variables Class methods Yes Yes No No Encapsulation Of variables Of methods Public, Private Public, Private Modularity Kinds of mo

/pdf/has-the-object-oriented-paradigm-kept-its-promise-5ggh378ull.pdf

Has the Object-Oriented Paradigm Kept Its Promise?

This report gives an overview of the eighth ECOOP Workshop on Formal Techniques for Java-like Programs. It summarizes the workshop preparation, contributions, debates and conclusions.

Formal Techniques for Java-Like Programs

Previous workshops on reflection both in ECOOP and in OOPSLA have pointed out the growing interest and importance of Reflection and Metalevel Architectures in the fields of programming languages and systems (ECOOP’98, OOPSLA’98), software engineering (OOPSLA’99) and middleware (Middleware 2000). Following these workshops but also the conference Reflection’99 held in SaintMalo (France), this workshop has provided an opportunity for researchers with a broad range of interests in meta-level architectures and reflective techniques to discuss recent developments in this field. It has also provided a good test-bed for preparing them to submit their works to Reflection’01. The workshop main goal is to encourage people to present works in progress. These works could cover all the spectrum from theory to practice. To ensure creativity, originality, and audience interests, participants have been selected by the workshop organizers on the basis of 5-page position paper. We hope that the workshop will help them to mature their idea and improve the quality of their future publications based on the presented work.

Object-Oriented Technology

Workshop Reports.- Reflection and Meta-level Architectures: State of the Art and Future Trends.- Exception Handling in Object Oriented Systems.- Object-Orientation and Operating Systems.- Formal Techniques for Java Programs.- Component-Oriented Programming.- Tools and Environments for Understanding Object-Oriented Concepts.- PhDOOS 2000: The 10th Ph.D. Workshop on Object-Oriented Systems.- Quantitative Approaches in Object-Oriented Software Engineering.- Metadata and Adaptive Object-Models.- Defining Precise Semantics for UML.- Objects and Classification.- Object-Oriented Architectural Evolution.- Specification, Implementation, and Validation of Object-Oriented Embedded Systems.- Quality of Service in Distributed Object Systems.- XML and Object Technology.- Workshop on Aspects and Dimensions of Concern: Requirements on, and Challenge Problems for, Advanced Separation of Concerns.- Mobile Object Systems.- New Issues in Object Interoperability.- Panel Report.- Panel Session: Mobile Code, Internet Security, and E-Commerce.- Posters.- Poster Session.

Object-Oriented Technology: ECOOP 2000 Workshop Reader: ECOOP 2000 Workshops, Panels, and Posters Sophia Antipolis and Cannes, France, June 12-16, 2000 Proceedings

Jacques Malenfant

Papers

Object-Oriented Technology

Object-Oriented Technology: ECOOP 2000 Workshop Reader: ECOOP 2000 Workshops, Panels, and Posters Sophia Antipolis and Cannes, France, June 12-16, 2000 Proceedings