A P R A C T I C A L A P P R O A C H T O W A R D A R C H I T E C T U R E S
F O R O P E N
C O M P U T A T I O N A L S Y S T E M S
J I M M Y C A R L S S O N
puter Science at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Bachelor of Science in Computer Science.
The thesis is equivalent to 10 weeks of full time studies.
Contact information Author(s): Jimmy Carlsson
Address: Department of Software Engineering and Computer Science Blekinge Institute of Technology
Box 520
S-372 25 Ronneby Sweden
E-Mail: jimmy.carlsson@bth.se
Advisor(s): Martin Fredriksson
Address: Department of Software Engineering and Computer Science Blekinge Institute of Technology
Box 520
S-372 25 Ronneby Sweden
E-Mail: martin.fredriksson@bth.se Phone: +46.457.385825
Department of Internet:www.bth.se/ipd
Software Engineering and Computer Science Phone:+46.457.385000 Blekinge Institute of Technology Fax:+46.457.27125 Box 520
S-372 25 Ronneby Sweden
iii
C O N T E N T S
Preface v
1 Introduction 1
Problem description and thesis. . . 2
Methodological approach . . . 3
Outline . . . 4
2 Backgound analysis 7 General systems theory . . . 8
Modelling open computational systems . . . 12
3 Implementing open computational systems 17 Comparison of modelling approaches . . . 17
Scalability versus construction . . . 20
Observation versus construction . . . 20
Architectures for open computational systems . . . 21
Physical scalability . . . 22
Conceptual decoupling . . . 22
4 Concluding remarks 25
Summary . . . .25
Implications. . . .26
Results . . . .27
Future work. . . .28
Bibliography 29
v
P R E F A C E
y means of a systemic approach toward analysis and design of com- plex systems, we introduce the issue of implementing open compu- tational systems on service-oriented architectures. We start by studying general systems theory, as it accounts for analysis and modeling of com- plex systems, and then compare three different implementation strategies toward system implementation. As such, the comparison is grounded in the notion of supporting architectures and, more specifically, in the prac- tical case of a service-oriented layered architecture for communicating entities (SOLACE).
The author particulary wishes to thank his advisor Martin Fredriksson (Societies of Computation) for stimulating discussions and useful com- ments on earlier drafts of the thesis. The author also acknowledges the valuable contribution from colleagues in the Societies of Computation Laboratory (SOCLAB), especially Jonas Rosquist and Johan Lindblom for interesting discussions during late night work.
B
1
C h a p t e r 1
I N T R O D U C T I O N
uring the last century, science has developed drastically and so has the methodologies following evolving scientific paradigms. An example of this state of affairs is the systems paradigm. As a mechanistic approach toward systems analysis exhibits certain limitations, general sys- tems theory manifests itself as a much sought for alternative.
Another example of development in science is its relationship with engineering. As science evolves, so does engineering and innovations that follow. An example of such innovation is the computer and, more recently, global communication networks such as the Embedded Internet (Estrin et al., 2000). In essence, those particular innovations present themselves as the primitives of a new class of systems, i.e., open computa- tional systems (Fredriksson and Gustavsson, 2002).
Computer networks are becoming more and more complex and, con- sequently, so do the software systems running on top of them. Our ability to explain and predict behaviour becomes limited or even impossible. An example of this is the service-oriented modelling and development para- digm (Bieber and Carpenter, 2001). As such, the service-oriented para-
D
digm explicitly addresses the exploitation of dynamic computer networks, e.g., peer-to-peer networking, home appliances and mobile devices, hav- ing a profound impact on the complexity of system behaviour. The ser- vice-oriented paradigm explicitly addresses the need to quickly create powerful applications in distributed complex computer networks. How- ever, the paradigm also advocates the development of service-oriented systems under the somewhat vague pretence that underlying architectures support the important aspects of complexity in open computational sys- tems.
S e c t i o n 1
P R O B L E M D E S C R I P T I O N A N D T H E S I S
As the problem of complexity in contemporary networked systems of services grows, the need for sufficient methodologies for construction and observation of the systems is becoming increasingly evident. In search for an appropriate methodology, we have turned to general sys- tems theory and holistic thinking, and found the concept of open systems to be of the essence, i.e., open computational systems.
Consequently, the material presented herein is concerned with valida- tion and verification of open computational systems with respect to mod- elling of complex systems (see Figure 1.1). By identification of appropriate architectures for open computational systems, e.g., service- oriented architectures, we should be able to observe and construct the
Introduction 3
complex behaviour in this particular class of systems. Consequently, the initial questions we ask in this thesis are:
• What is an open computational system?
• What is a service-oriented architecture?
Based on answers to these questions in relation to the notion of complex behaviour in open computational systems, we will test the following hypothesis:
Implementing open computational systems can be done by means of service-ori- ented architectures.
S e c t i o n 2
M E T H O D O L O G I C A L A P P R O A C H
In essence, the methodological approach chosen for this thesis is based on the CommonKADS methodology (Schreiber et al., 1999). The build-
science engineering
construction open computational observation
complex systems
systems
Figure 1.1 - Relations between practical approaches and subjects of study:
science observes complex systems, by means of systems analysis, and engineering constructs open computational systems, by means of supporting architectures.
The thesis under study consider wether or not open computational systems can be mapped onto complex systems, by means of support from the underlying
ing blocks of that particular methodology are framework, theory, models, tools and system. From the perspective of the hypothesis under study, the relationship between scientific analysis of behaviour in complex systems and engineering of service-oriented systems is what comprises the frame- work. Consequently, the theories put to use involve general systems the- ory and open computational systems. In particular, the methodological approach, which in order to verify the thesis under study, aims at a more in-depth understanding of complexity in service-oriented systems.
Consequently, we make use of a service-oriented architecture for com- municating entities (SOLACE) as a practical case of supporting analysis and engineering of open computational systems. The particular architec- ture developed makes use of three different layers of behavioural perspec- tives: fabric, system and domain. Considering the delimitation of the hypothesis presented herein, the following aspects of SOLACE will not be taken into consideration:
• Modelling of open computational systems and their behaviour, i.e.,
domain layer.
• Architecture of systems with less complexity than that of open com- putational systems, i.e., systems layer.
• Physical and hardware entities for other than explanatory reasons, i.e.,
fabric layer.
Introduction 5
S e c t i o n 3 O U T L I N E
The remaining parts of the material presented herein are structures as fol- lows. In Chapter 2, we take a closer look at the problem at hand. In essence, we explicitly address material on general systems theory, com- plexity, and open computational systems. In Chapter 3, we continue our study by looking at implementation of open computational systems. This particular study focuses on a comparison of modelling approaches and architectures for open computational systems. Finally, in Chapter 4 we conclude the hypothesis by means of certain implications and give point- ers towards future work.
7
C h a p t e r 2
B A C K G O U N D A N A L Y S I S
n this chapter we introduce a background analysis of the problem addressed by the hypothesis. We start by studying general systems theory, as it accounts for modelling of complex systems and therefore introduce us to a systemic (holistic) perspective of system behaviour. This introduction is then followed by a study of open systems and a complex- ity classification of such. With the framework and concept of open systems in focus, we move on to open computational systems, by means of a comparison between analysis and synthesis. This particular compari- son is then related to the practical issue of implementing open computa- tional systems. However, before we continue to describe the characteristics of general and open systems, we shortly make a reflection on what systems thinking is all about.
I
S e c t i o n 1
G E N E R A L S Y S T E M S T H E O R Y
The paradigm of general systems theory was established during the mid 20th century when certain limitations of reductionism were realized (Skyttner, 2000). The concept of systems thinking can be traced back to as early as 300 B.C.: “the whole is greater than the sum of its parts” (Aris- totle). This statement, mapped onto the notion of system, is a fundamen- tal aspect in the general systems theory. In particular, as the activity of analysis approach complex systems by means of reducing them into abstract structures, synthesis expands the subject under study into open structures in continuous interaction. Now that we have a basic under- standing of what systems thinking is all about, we can continue by defining the concept of system, followed by a general description of open systems.
A S Y S T E M I C P E R S P E C T I V E
System as a concept is as broad and generic as “A system is anything that is not chaos.” (Boulding, 1985) to “A group of interacting mechanical or electrical com- ponents“. However, the important issue here is to specify what aspect and understanding of systems that we aim at in this material. We start by stressing the difference between two uses of the term.
In computer science, the term system usually refers to a systematic notion of a physical structure, i.e., a collection of computer software and networks in interaction. However, systems thinking involves another per- spective of system, i.e., a model of real-world situations having properties as a whole not found by looking at parts of the whole.
This state of affairs introduce us to important issue emphasized by Checkland: systems do not exist in the real world, but are rather ways of viewing the
Backgound analysis 9
world (Checkland, 1981). In essence, Checkland describes systems in terms of epistemologies rather than ontologies. This means that a system is only a model of the real world made by some particular observer, e.g., seeing the Embedded Internet as a massive amount of hardware intercon- nected but also as an information system. Consequently, from this per- spective it is important to explain the concept of system boundaries.
A system’s boundary is the perimeter that holds together the compo- nents in the system and protects them from the outside environment, i.e., stopping unwanted matter, energy and information to enter the system (Miller, 1990). Checkland on the other hand defines the boundary of a system as “... a distinction made by an observer which marks the differ- ence between an entity he takes to be a system and its environment.” Finally, in our attempt to define the term system, the following definition is worth mentioning (Ackoff, 1981):
• The behaviour of each element has an effect on the behaviour of the whole.
• The behaviour of the elements and their effects on the whole are interdependent.
• However subgroups of the elements are formed, all have an effect on the behaviour of the whole, but none has an independent effect on it.
C O M P L E X I T Y H I E R A R C H Y
An important aspect of the hypothesis relates to the issue of systems complexity. The nature of complexity is primarily due to quantity and flux of system constituents and their continuous interaction. That is, as dis- tributed computer networks increase in size, the amount of computa-
tional entities and their interactions accounts for a dramatic increase in the behavioural complexity of the network as a whole. We therefore introduce a hierarchy of systems complexity (Building, 1956):
1. Cybernetic systems. Systems capable of self-regulation in terms of some externally prescribed target or criterion, such as a thermostat.
2. Open systems. Systems capable of self-maintenance based on a throughput of resources from its environment, such as a living cell.
3. Blueprinted-growth systems. Systems that reproduce not by duplication but by the production of seeds or eggs containing pre-programmed (genotype) instructions for development, such as the acorn-oak sys- tem or the egg-chicken system.
We find that open systems are more complex than cybernetic systems but less complex than blueprinted-growth (sometimes called genetic-societal) systems. When comparing level two (open systems) and level three (blue- printed-growth systems) we find that open systems lack reproduction capabilities in terms of a more advanced reproduction than simple dupli- cation. We also find that open systems lack the differentiation between genotype and phenotype found in cybernetic systems, where phenotype is the observable physical or biochemical characteristics of an organism, e.g., human body, and genotype is the internally represented genetic char- acteristics, e.g., human DNA. Comparing level one and two we find that open systems adds the ability of self-maintenance; based on importing and transforming energy, matter, and information from the surrounding environment during a finite period of time. This notion of self-mainte-
Backgound analysis 11
nance and organization is closely related to the concept of entropy. Finally, we find that there exists a clear-cut separation between open and closed systems. A closed system is open for input only in terms of an environ- ment with a physically fixed set of constituents. Open systems on the other hand are dependant on their ability to exchange matter, energy and information with a physical environment in continuous flux.
H O M E O S T A T I C B E H A V I O U R
From a systematic perspective on open systems, as described in previous section, an open computational system can be characterized in terms of networked computer systems that apply open standards, e.g., ISO OSI (Tanenbaum, 1996). In this study, we do not consider the systematic per- spective. Instead, we address the notion of open computational systems from a systemic perspective. Having the complexity classification of open systems, we now look at characteristics not found in less complex sys- tems.
As previously mentioned, closed systems lack mechanisms to counter- act entropy, i.e., amount of disorder or randomness in a system. Open systems on the other hand have the ability to counteract entropy; this is also called negentropy. To support negentropy, open systems can input,
transform and output matter, energy and information from the surrounding environment. Input is transformed into new forms, patterns and products, e.g., a school may create new knowledge, teaching material, and other products from its source. As entropy can be described as the amount of energy that after transformation dissipates, the ability to import and export matter, energy and information is vital, e.g., educating personnel. Another vital mechanism open systems is differentiation. Differ- entiation is the mechanism that tends to develop highly specialized sub- systems, performing system functions For example, in a school system
differentiation may be observed in the development of elaborated roles with specialized functions as psychologist, reading teacher, etc. All the previously mentioned mechanisms play an important role in open systems’ homeostatic behaviour. Homeostasis is the ability to maintain a steady state in a system without losing activity, i.e., a constant preparation for change to preserve balance. Now that we have an understanding of what characterize open systems we move on to describe open computa- tional systems.
S e c t i o n 2
M O D E L L I N G O P E N C O M P U T A - T I O N A L S Y S T E M S
Looking at a definition of the term computational, we find “The act or pro- cess of computing.”. Looking at a scientific area dealing with computation we find computational theory, i.e., what is the goal of computation, why it is appropriate, and what is the logic of the strategy by which it can be car- ried out (Marr, 1982). Following the above definitions, a computational system can, in part, be any device of standard computation theory, e.g., Turing machines, register machines and finite state automata. What we find is that open computational systems have the same fundamental char- acteristics as open systems but in a computational setting.
As we now have established characteristics of open computational sys- tems, we continue to look at related models. First, we compare issues when constructing systems by means of analysis and synthesis. Then we will study implementation strategies by looking at relevant programming approaches. In the final section of this chapter, we will look at a service- oriented approach.
Backgound analysis 13
A N A L Y S I S V S . S Y N T H E S I S
As of today, current methodologies for developing computational sys- tems are based on analysis. This has the effect that systems are modelled once and then implemented. This is not a problem concerning closed computational systems, as they do not require homeostatic behaviour, i.e., they do not change behaviour stochastically by means of negentropy.
However, when it comes to open computational systems, contemporary methodologies based on analysis are inadequate due to homeostatic behaviour, i.e., homeostasis characterizes open computational systems.
Creating a model and perspective of behaviour at one time does not guar- antee that it is valid at a different time and perspective in open systems.
To that end, synthesis is more adequate than analysis in coping with homestatic behaviour, since it explicitly account for deduction of multiple perspectives of a single set of computational entities. To investigate this issue further, we will now take a closer look at certain implementation strategies that (in part) address the notion of synthesis.
I M P L E M E N T A T I O N S T R A T E G I E S
The well-defined and established object-oriented approach is still the most used software development methodology and probably will be for quite some time (Rumbaugh et al., 1991). Objects have the ability to describe themselves through interfaces, i.e., the methods included in an interface makes a particular object self-descriptive of its capabilities and properties. Object-oriented development is based on analysis, which is sufficient in closed systems where a model and behaviour of the system is established only once.
Another approach is the agent-oriented approach (Huhns and Singh, 1998). It is increasingly considered to be very suitable in complex com-
puter network environments. The key idea of agent-oriented program- ming is a mentalistic approach, e.g., an agent having belief, desire and intention. The agent-oriented paradigm is based on a societal view of computation. Agents perceive their environment through sensors and communicate by means of message interaction. Here are some examples of areas considered where an agent-oriented approach is especially well suited:
• Customized services where services have to be created quickly in a rapidly changing environment. They also have to be set-up and man- aged in distributed environments.
• Automated maintenance: As complexity increase in distributed sys- tems, a need for sophisticated automated monitoring and maintenance is becoming increasingly important.
S E R V I C E - O R I E N T E D A P P R O A C H
Service-oriented programming (SOP) is a new programming paradigm that currently is gaining momentum in the software industry (Bieber and Carpenter, 2001). The expansion of large communication networks, such as the Embedded Internet, has created a need for more powerful capabil- ities quickly. Now we will define what a service is in a service-oriented context, followed by basic characteristics of service-oriented architec- tures.
According to Bieber and Carpenter, a service can be defined as “A service is a contractually defined behaviour that can be implemented and provided by any component for use by any component, based solely on the contract.” By analyzing several service-oriented technologies on the market today, we find the following set of elements that is part of service-
Backgound analysis 15
oriented architecture:
• Contract. An interface that contractually defines the syntax and semantics of a single behaviour.
• Component. A third-party deployable computing element that is reusable due to independence from platform, protocols and deploy- ment environments.
• Connector. An encapsulation of transport-specific details for a specified contract. It is an individually deployable element.
• Container. An environment for executing components that manages availability and code security.
• Context. An environment for deploying plug and play components, that prescribes the detail of installation, security, discovery, and lookup.
We also find several architectural aspects that characterize service-ori- ented computing:
• Conjunctive. This refers to the ability to use or combine services in ways not conceived by their originators. This implies that components have published interfaces for the services they provide.
• Deployable. This refers to the ability to deploy or reuse a component in any environment. This requires transport independence, platform independence and environment independence.
• Mobile. This refers to the ability to move code around the network.
This is used to move proxies, user interfaces and even mobile agents.
This is the key enabler for interoperability.
• Available. One of the premises of service-oriented programming is that redundant networked resources can provide high availability. It is the goal of SOP to handle the failures that plague distributed computing.
• Interoperable. Interoperability is the ability of components from differ- ent sources to use each other’s services. SOP supports this through two key features: code mobility and contracts. Interoperability is achieved by sending code across the network that complies with the contract. This code could be a proxy or even an entire application.
17
C h a p t e r 3
I M P L E M E N T I N G O P E N C O M P U T A T I O N A L
S Y S T E M S
n our approach toward open computational systems, we will first make a comparison of relevant modelling approaches. Furthermore, from the perspective of service-oriented architectures, we summarize issues related to implementing open computational systems. Based on the issues found, we propose a particular solution, i.e., architectures for open computational systems, in terms of a service-oriented layered architecture for communication entities (SOLACE).
S e c t i o n 1
C O M P A R I S O N O F M O D E L L I N G A P P R O A C H E S
Although service-oriented programming is based upon object-oriented programming, it addresses a different level of complexity in distributed
I
complex systems, such as the Embedded Internet (Estrin et al., 2000).
The object-oriented approach typically focuses on modelling of complex systems by means of encapsulation and abstraction barriers. The service- oriented approach on the other hand, focuses on deployment and avail- ability of simple components’ behaviour, by means of support for service publishing and discovery.
Finally, since the agent-oriented approach need to either publish agents’ capabilities or let other agents query for their capabilities, a service-oriented approach can be considered to complements the agent- oriented approach through its fundamental mechanisms for publishing and discovery of behavioural properties.
To that end, reflecting on the characteristics found in open computa- tional systems, we find that service-oriented architectures support differen-
tiation, i.e., use of services in dynamic ways not conceived by their originators, and maps directly onto open computational systems’ ability/
requirement to create subsystems.
We have therefore chosen the service-oriented approach for imple- mentation of open computational systems; we need support from a service-oriented architecture. From this perspective, an architecture that sufficiently meets our needs is that of OSGi (Open Services Gateway ini- tiative) specification, which is an open specification of service-oriented architectures. In our first approach, we look at the possibility to use GDSP (Gatespace’s Distributed Service Platform) as an open computa-
Implementing open computational systems 19
tional systems’ architecture, since it is an implementation the OSGi speci- fication.
From the aspect of open computational systems, two particular perspec- tives represent the architecture, namely fabric and system (see Figure 3.1).
Fabric is the physical infrastructure for subsystem interaction, coupling and entity mobility. System layer is where the system entities proliferate and interact with each other. In essence, we consider GDSP present at the fabric layer.
In terms of a service-oriented architecture, the GDSP looks as if it would be sufficient for implementation of open computational systems.
However, this turned out to be false because of two reasons:
• Lack of support for multiple perspectives to support observation and construction of open computational systems.
• Lack of support for scalability, i.e., the ability to automatically resize due to inclusion or exclusion of matter in terms of computational entities.
system/model
fabric
Figure 3.1 - An illustration of contemporary perspectives on behaviour in com- plex systems, i.e., open computational systems.
S e c t i o n 2
S C A L A B I L I T Y V E R S U S C O N - S T R U C T I O N
As closed computational systems have fixed system boundaries, i.e., quan- titative size never changes, i.e., there is no need to support the notion of scalability. Open computational systems on the other hand, require support for scalability. This is due to construction of homeostatic systems behaviour. More specifically, input, transformation and output of matter, energy and information as a precondition for negentropy requires an ability of a system’s infrastructure to change in size. Current approaches toward service-oriented architectures lack sufficient support for scalability in terms of coupling and decoupling of networked computational entities situated at the fabric layer, e.g., in a computer network setting, computers added to the physical network is not automatically coupled with the fabric layer and thereby entities on the system layer are not accessible.
S e c t i o n 3
O B S E R V A T I O N V E R S U S C O N - S T R U C T I O N
Observation of system behaviour is a necessary support mechanism for open computational systems architectures, due to the activity of verifying homeostatic behaviour. We know through general systems theory that pain analysis cannot solve holistic problems. What we need is a synthetic approach. As a direct result of a synthetic approach, we need support for multiple perspectives of the same system, one for each deducted perspec- tive. Let us look at an example where the systems entities are agents in an open computational system.
Implementing open computational systems 21
Agents must be able to perceive their environment. In a multi-agent system, each agent’s perception of a set of computational entities (agents) is the agent’s own cognitive model of the system (c.f. Checkland’s defini- tion of a system). This in turn calls for multiple perspectives of a single system. However, in current implementations of service-oriented archi- tecture such mechanisms are not supported because all computational entities contain prebuilt and static models of their particular behaviour (in a typical object-oriented manner). In the previous example, the agents would have had a predefined model of the structure and behaviour of their environment.
S e c t i o n 4
A R C H I T E C T U R E S F O R O P E N C O M P U T A T I O N A L S Y S T E M S
In this section, we will suggest an alternative approach toward imple- menting open computational systems, based on previous architectural findings, i.e., observation, construction, and scalability.
As we described in the previous section, using service-oriented archi- tectures alone are inadequate for methodological activities such as obser- vation and construction. In order to address this profound issue, a Service-
system fabric domain
Figure 3.1 - Illustration of suggested solution for perspectives of behaviour in complex systems, i.e., open computational systems
oriented layered architecture for communicating entities (SOLACE) was devel- oped. The main problems to address are in essence,
• Physical scalability. Current implementations of service-oriented archi- tectures lack sufficient scalability in open computational systems.
• Conceptual decoupling. Current implementations of service-oriented architectures lack support for multiple perspectives, by means of a system versus model separation.
S e c t i o n 5
P H Y S I C A L S C A L A B I L I T Y
To support the notion of scalability as needed in open computational systems, SOLACE provides for automatic coupling and decoupling of physical nodes (local set of computational entities) at the fabric layer. This is done by means of multiple broadcast protocols in order to signal a par- ticular node’s presence to the surrounding environment at regular inter- vals. Listening nodes receive the broadcast message and thereby acknowledge the presence of the signalling node. As soon as both nodes have found each other, by means of the broadcasting mechanism, interac- tion between system entities is provided for irrespective of node locality.
S e c t i o n 6
C O N C E P T U A L D E C O U P L I N G
Contemporary methodologies can be perceived to consider two layers of perspective on behaviour, namely a fabric and a system layer (see Figure
Implementing open computational systems 23
3.1). The fabric layer contains the physical infrastructural behaviour that supports the system layer. The system layer includes the behaviour of system entities in interaction. However, since contemporary methodolo- gies for constructing systems are based on analysis, models are an inte- grated part of the system layer; thereby rendering multiple perspectives of systems impossible. To that end, SOLACE utilizes the service-oriented approach by means of a service-oriented architecture (GDSP) in the form of a service. Being part of a layered architecture, SOLACE supports multiple perspectives of a single set of computational entities. By dividing the system layer to a system and a domain layer (see Figure 3.1), the model(s) of the system are separated from the system itself and thereby making it possible to freely model the system and manage multiple models, i.e., multiple perspectives. Fabric layer is the physical communica- tion infrastructure and physical entities. System layer contains system entities with support for interaction and mobility. The domain layer supports abstractions, i.e., models, of the system layer. Observation and construction of open computational systems can thereby be done through multiple perspectives, i.e., models, of the same system.
25
C h a p t e r 4
C O N C L U D I N G R E M A R K S
ow that we have reached the last chapter of this thesis, we will conclude the work. Firstly, a short summary of the material presented so far will be outlined. Secondly, we will delve further into the implications of results presented. Finally, the chapter is concluded with pointers to future work.
S e c t i o n 1 S U M M A R Y
As a starting point for the thesis presented herein we have addressed the notion of open computational systems. In Chapter 2, we sought to find unique characteristics of open computational systems, by means of studying general systems theory in relation with reductionism. We found that the methodological activity of analysis address complex systems by means of reducing them into abstract structures whereas synthesis on the other hand expands the subject under study into open structures in con-
N
tinuous interaction. We thereby found that general systems theory is an approach that addresses system complexity from a holistic perspective.
We continued by comparing the concept of system from a systematic versus a systemic perspective and found that the systemic perspective most effectively address relevant issues in implementing open computa- tional systems. Finally, in respect to a systemic perspective of system behaviour, it stands clear that static models of open computational systems are inadequate. This result was primarily grounded in the notion of systems not existing in the real world, but rather as unique perceptions made by multiple observers. In pursuit of important aspects to support by architectures for open computational systems, we addressed the notion of open systems and, in particular, their complexity. In principle, we found that homeostasis is the main issue to address. Furthermore, negentropy, differentiation, and, throughput, were identified as the main origin of this issue. Having the characteristics of open systems identified we continued with open computational systems and found this class of systems has the char- acteristics of open systems in a computational setting.
With the characteristics and general issues of open computational systems in mind, we introduced three related strategies for implementing such systems. Consequently, a service-oriented approach toward architec- tures for open computational systems was selected as the most promising strategy.
S e c t i o n 2 I M P L I C A T I O N S
To cope with the characteristics and issues of open computational systems, arguably, standard systems analysis is an insufficient method- ological approach, due to certain limitations in accounting for homeo-
Concluding remarks 27
static systems behaviour. Synthesis on the other hand explicitly addresses the notion of homeostatic systems behaviour, i.e., behaviour in open computational systems. In principle, we found that in order to use synthesis as the methodological approach of choice we need the ability to observe systems behaviour from multiple perspectives. After studying and comparing object-oriented, agent-oriented and service-oriented approaches, we found that a service-oriented approach suits a synthetic approach toward observation and construction of open computational systems, by means of multiple perspectives. However, since open compu- tational systems show a stochastic behaviour of shifting size, we find that contemporary implementations of service-oriented architectures lack suf- ficient support for scalability.
S e c t i o n 3 R E S U L T S
In order to cope with the particular issue of architectural support for homeostatic systems behaviour, service-oriented architectures can, arguably, be complemented by means of service-oriented layered architec- ture for communicating entities (SOLACE). Such an approach would nec- essarily need to provide for additional architectures mechanisms;
explicitly focused on system observation from multiple perspectives and thereby support the ability to create multiple simultaneous models of the same set of system entities. To that end, Solace decouples the current per- spective of system behaviour (see Figure 2.2), in order to not include both system entities and models. Instead, Solace introduces a new perspective of behaviour, namely a domain layer. The domain layer is a modelling layer, which has the effect of separating the models from the system entities and thereby enabling multiple models of a single set of computa-
tional entities. Looking back at general systems theory, we find that having the possibility to create multiple models of the same systems as an observer supports the fundamental ideas of systems thinking, namely homeostasis. The proposed solution of SOLACE also addresses the issue of scalability, by means of a mechanism that automatically includes and excludes physical network nodes, by means of periodically signalling the surrounding environment. In summary, if we would rephrase the original hypothesis;
“Implementing open computational systems can be done by means of service- oriented architectures.”
we find that the hypothesis is falsified due to the insufficient support from service-oriented architectures for homeostatic systems behaviour.
In essence, the main reason for this state of affairs originates from a number of missing mechanisms, which obviously could be provided by future implementation strategies (as previously described).
S e c t i o n 4 F U T U R E W O R K
In relation to the results presented herein, a possible continuation of the work on homeostatic behaviour in open computational would be to implement the suggested mechanisms and thereby empirically test the solution.
29
B I B L I O G R A P H Y
1. Ackoff, R. (1981) Creating the corporate future. John Wiley and Sons.
2. Bieber, G. and Carpenter, J. (2001) Introduction to service-oriented programming. At www.openwings.org/download/specs.
3. Boulding, K. (1956) General systems theory: The skeleton of science. In Management science, no. 2.
4. Boulding, K. (1985) The world as a total system. London, Sage Publications 5. Checkland, P. (1981) Systems thinking, systems practice. John Wiley and Sons.
6. Estrin, D., Govindan, R., and Heidemann, J. S. (2000) Embedding the Internet: Intro- duction. In Communications of the ACM, vol. 43, no 5, pp. 38-41. ACM Press.
7. Fredriksson, M. and Gustavsson, R. (2002) Theory and practice of behavior in open computational systems. In International worksop on From agent theory to agent implementation.
8. Huhns, M. N. and Singh, M. P. (1998) Agents and multiagent systems: Themes, approaches, and challenges. In Readings in agents, pp. 1-24. Morgan Kaufmann.
9. Katz, D. and Kahn, R. L. (1965) Organizations and the system concept. In The social pshychology of organizations, pp. 17-35. John Wiley and Sons.
10. Marr, D. (1982) Vision. H. Freeman and Co.
11. Miller, J. (1990) Introduction: The nature of living systems. In Behavioral science, vol.
35, no. 3, La Jolla, California.
12. Rumbaugh, J. et al. (1991) Modeling as a design technique. In Object-oriented model- ing and design, pp. 15-20. Prentice Hall.
13. Schreiber, G. et al. (1999) Knowledge engineering basics. In Knowledge engineering and management: The CommonKADS methodology, pp. 13-24. MIT Press.
14. Skyttner, L. (2000) Basic ideas of general systems theory. In General systems theory:
Ideas and applications, pp. 45-101. World Scientific.
15. Tanenbaum, A. S. (1996) Reference models. In Computer networks, pp. 28-43. Pren- tice Hall.
