tag:blogger.com,1999:blog-78488007613854849052024-02-07T02:49:03.250+00:00Software OrganismSoftware systems, Autonomous systems, Distributed systems and Formal methods.Dr. Bippin Makoondhttp://www.blogger.com/profile/10489437598692319170noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-7848800761385484905.post-91621951047731908062010-11-06T11:55:00.030+00:002010-11-06T14:05:55.832+00:00A Multi-Level Approach for Modelling & Simulation of Distributed Agent Network<div align="justify"><span style="font-size:78%;">Journal of Algorithms & Computational Technology, Volume 4, No. 3 September 2010, Multi-Science Publishing Co. Ltd<br /></span><br /></div><div align="justify"></div><div align="justify"><a href="http://cism.kingston.ac.uk/people/details.php?AuthorID=316"><span style="font-size:85%;">Bippin Makoond</span></a><span style="font-size:85%;">, </span><a href="http://cism.kingston.ac.uk/people/details.php?AuthorID=115"><span style="font-size:85%;">Souheil Khaddaj</span></a><span style="font-size:85%;">, </span><a href="http://www.systonomy.com/"><span style="font-size:85%;">Radouane Oudrhiri</span></a><span style="font-size:85%;"><br /></div></span><div align="justify"></div><div align="justify"></div><div align="justify"></div><div align="justify"></div><div align="justify"><br /></div><div align="justify">ABSTRACT<br /><span style="font-size:85%;">The task of building distributed application network is plagued by cost, ambiguous requirements and schedule overrun. A fundamental problem in building distributed applications is the presence of unreliable estimation to formulate the list of requirements in the initial stage of project life cycle. Subsequently, this often leads to reactive response from decision-makers against error occurrences, leaving a very small space for developers to establish forward planning. Unless estimations are enhanced to include more sophisticated verification and validation methodologies, the problem will remain. This paper looks at Petri Nets as a modelling and simulation instrument to verify and validate models of distributed application networks. </span></div><div align="justify"><span style="font-size:85%;"></span></div><div align="justify"></div><div align="justify"><br />1. INTRODUCTION<br /><span style="font-size:85%;">Historically, life critical software projects have routinely incurred significant checks, simulation and validation in order to reinforce the safety protocols and this approach does now apply also to critical business applications. In attempting to incorporate the simulation strategies in business critical systems, researchers in software engineering have developed several simulation tools with the intention of improving the effectiveness of estimation. An emerging area of research takes into account methodologies such as formal methods. Languages like B- method, pi-calculus and the Z notation [2] provide mathematical formalism to illustrate and evaluate consistencies in software projects.<br />Building distributed multi-component systems introduces another layer of uncertainty, which very much depends on the underlying network and infrastructure. In this paper we particularly concerned with mobile communication and its infrastructure. The wireless networks with their mobile clients differ from traditional client server models and given that numerous wireless devices are likely to increase [1], the process of integrating those devices under a single server solution can become very complex and inefficient as the network grows. A more practical solution is to operate these mobile devices over a decentralised distributed application system [15]. In this work, the research questions the requirements that exist in building a highly distributed network applications and investigates if simulation can be resourcefully established to examine the model of a particular network. The work focuses on modelling communication agents based on the blueprint of the Virtual Mobile Redirector (VMR) [4] queue structure and subjects it to Petri Nets [3] simulation to carry out a number of experiments. The experiments include several simulation scenarios which when combined together yield an estimation of the agent’s performance and simulating different agents operating in tandem provides a fairly accurate approximation of the network performance.<br />The paper starts with a brief description of Virtual Mobile Redirector together with the problem domain, and Quality of Service (QOS) issues in a networking environment. Then, the simulation and modelling environment is presented. This is followed by describing the simulation process together with a number of experiments. Finally, we conclude with some suggestions for future work. </span></div><div align="justify"><br /></div><div align="justify">2. THE VIRTUAL MOBILE REDIRECTOR<br /><span style="font-size:85%;">The Virtual Mobile Redirector (VMR) is a multi agent messaging system which enables mobile phones to connect to IP based application through protocol conversion [4]. The application consists of different interconnected software agents, wherein an agent encapsulates a series of methods as one class function and comprises of input/output components expressed as “sensors” with the primary purpose to receiving and dispatching packets of information via queues (sensor class). The agent also contains a processing unit, which identifies which methods are to be triggered when the sensors receive data.<br />The VMR represents a logical organisation of agents, which interact in a common environment to achieve a particular goal. It focuses on the collaborative resolution of global problem by a set of distributed entities. Like typical Multi Agent System (MAS), the VMR abstracts the interaction between individual agents, defining the independency of the underlying architecture, which can be deployed on both centralised and highly distributed systems. The VMR agents communicate using interconnected queues which are typically the most commonly used data structures within the implementation of communication mediums (substratum) for distributed systems [14]. Queuing theory is the mathematical study of queues within a system which is essentially applied to analyse attributes such as performance, robustness and reliability of multi programmed computer systems.<br />The VMR architecture has been established on a hierarchical structure of a Multi Agent System (MAS) which can be decomposed into three levels of controls; 1) the agent level, 2) cluster level and 3) system level. Each level has different structures, activities and mechanisms, but the levels interact with each other during local / global communication. The fact that the VMR was designed in a symmetrical and hierarchical manner, it enabled us to design the simulation of the model based on the hierarchical features of Coloured Petri Nets, though the process is not a one to one mapping, it still helped in the design translation process as will be discussed in the following sections. </span></div><div align="justify"><br /></div><div align="justify"></div><div align="justify"></div><div align="justify">3. THE PROBLEM DOMAIN AND QUALITY OF SERVICE ISSUES<br /><span style="font-size:85%;">Simulation aims at observing a system enforced to react under a number of predefined circumstances to finally evaluate the behavioural outcome [6]. A key factor, however, prior to simulation, is to underline what features of the system one needs to simulate in order to maximise knowledge capture with a minimum amount of resources. Considering a distributed application network, at the highest level of observation, the features that a simulator should question are distinguished by five entities [7]. First, for a given network architecture, the task requires knowing the amount of data entering and leaving the system. This is termed as the traffic rate. For example, a network designer is required to decide on the size of a queue component over a network against the traffic rate.<br />Second, the traffic inside the network may be congested and the designer would be required to know the congestion rate so as to alter the specification of the network for better performance. Third, the rate at which the data is flowing inside the network is also crucial to identify the latency that through simulation can be calibrated to an acceptable level. Fourth, is the throughput; the designer will need to know the delivery rate of the network under different condition. Throughput is usually the first measure that the customer investigates [1]. Finally, data loss is yet another important factor that illustrates how reliable the network system is. The above five entities form the programme’s framework and are termed as the Quality of Service [7] [13].<br />The Quality of Service of a network is described by its performance, i.e. how efficiently the system delivers its service to the world. Hence, acquiring knowledge on the quality of a system prior to product deployment would be competitive gain for any organisation building network application. We propose that to measure the Quality of Service of a distributed network application at the early stage of development imply the use of simulation tools since a real network system is not available at that level. This can be done using the five entities described earlier; the simulation engine should derive test scenarios to observe the network behaviour and reaction when any of the entities is questioned. The outcome from the simulation is analysed to develop contingencies and self-protecting mechanism when and where required [5]. In this paper we refer to these contingencies as handlers [7]. Each of the entities has their handlers. We hypothesise that a successful simulation procedure should be able to search and locate deficiencies related to the any of the five entities and next propose, with an acceptable degree of error, the appropriate handlers for recovery. The simulation can then test out such a procedure using four different measures to handle the five entities:<br />(i) Traffic metering to control and monitor traffic rate.<br />(ii) Resource allocation strategy to boost resource performance should the rate of throughput falls.<br />(iii) Data drop policy to regulate the rate of data loss.<br />(iv) Switching / Routing (Re-routing) strategy to alleviate congestion rate over the network.<br />(v) Resource allocation strategy to reduce network latency.<br />To evaluate the quality of service of a distributed network application, the experiments should look at three features of performance; namely the entities traffic rate, throughput and latency. The simulation scenarios position the Petri Net model of the network application under different situations whilst the experiments distinctively track the network behaviour and relate the relevant handlers for each situation. </span></div><div align="justify"><br /></div><div align="justify">4. THE SIMULATION ENVIRONMENT<br /><span style="font-size:85%;">In the last three decades research in computer science strongly contributed to the generation of simulation tools. Several formalisms and related automatic tools have been developed, others extended to accommodate simulation engines and are currently available on the market. Within the wide spectrum of simulation techniques, we were required to focuses on a selected subset of simulation tools [8–11], which represents, either for historical reasons or recently achieved popularity, and subsequently choose a platform that best agrees with the basic entities needed to model and simulate a distributed network application, which is Petri Nets in our case.<br />Petri Nets are a formal modelling technique for the description of concurrent and distributed system behaviour [3]. Since their introduction in the 1960s they have impressively evolved. Currently, several versions of this graphical modelling language exist, which find widespread application in specification, verification, and performance analysis of distributed parallel systems, communication protocols included. Typical applications of Petri Net are in the field of communication protocols, telecommunication networks, and software engineering. Despite a modelling philosophy that is not easy to be acquired,<br />Petri Nets, with their engaging graphical notation are a powerful modelling language to describe and investigate communicating and resource-sharing processes. Coloured Petri Net combines the basic formalism with programming language CPN ML [3] to enable the creation of accurate system models taking into account temporal and stochastic issues. Similar to other graphical tools, embedding user-defined functions into the specification is an interesting possibility to avoid heavy graphical descriptions of deterministic calculations. For undertaking the experiments, we considered CPN Tools, a freeware Coloured Petri Net tool available on the market. CPN Tools is a new platform for modelling and simulation of Petri Nets, which allows editing, simulating and analysing Coloured Petri Nets (CPN). </span></div><div align="justify"><br /></div><div align="justify">5. SIMULATION AND OBSERVATIONS<br /><span style="font-size:85%;">The models as well as the procedures of the experiments are discussed in this section. The aim is to carry out an investigation as to how Petri Nets are utilised to simulate the VMR multi agent system (VMR MAS) at the highest level and the communication agent queue component at the lowest one. Thus, the information from the exercise can be statistically interpreted so that handlers (contingencies) can be formulated for the necessary QoS measures.<br /><strong>5.1. Modelling and Simulation<br /></strong>When making use of the hierarchical decomposition feature of CPN, we are able to describe the architecture of an agent-distributed system at different level of perceptions. At the highest level of expression, we modelled the incoming of data packets from the external networks to the VMR system which is illustrated in Figure 1.</span><br /></div><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYPDeKVC_ikvZ6DSxucbGYuqX_vCXT2dXkyMV4z-Jthe1rW02ucd9zM1n0ihhYM1ZixU5huQc0GsXPdYe8y_85TcjrSK68Uhc1ID0_vqfUAfSnO3tGJm8BMa1c3LWRvpgyvU-ThgyIIl4/s1600/VMR+MAS+CPN.png"><img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 400px; DISPLAY: block; HEIGHT: 319px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5536412420615893346" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYPDeKVC_ikvZ6DSxucbGYuqX_vCXT2dXkyMV4z-Jthe1rW02ucd9zM1n0ihhYM1ZixU5huQc0GsXPdYe8y_85TcjrSK68Uhc1ID0_vqfUAfSnO3tGJm8BMa1c3LWRvpgyvU-ThgyIIl4/s400/VMR+MAS+CPN.png" /></a> <p align="justify"><span style="font-size:85%;">The CPN model starts with the transition Dispatch receiving one packet at a random time, which follows a Poisson distribution with a mean of 5.0 ms, from an external source. Since the model is a timed Petri Net, variable E at place M is timed in millisecond whilst each packet is numbered at the place TICKER, thus the place Dispatch (P1), knows about the packet number (packetNo). Next, at transition Dispatch, a function ch() is triggered to randomly select between 2 transition operations, either Translate Packet or Decrypt Packet. These functions add more knowledge to the model; hence during simulations more complex processes can be investigated in an attempt to mimic reality as closely as possible. Inside the transitions Translate Packets and Decrypt Packets, there are a series of distinct software agents communicating to each other with a common objective. In the VMR system, operations like “translate the packet structure to a general format” are performed by a cluster of agents. In an attempt to simulate these functions, we constructed a hierarchical transition Translate Packet within which are a group of agents connected to each other, and the same design applies to the transition Decrypt Packet.</span><img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 400px; DISPLAY: block; HEIGHT: 309px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5536415754360503362" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXmuCrlNrGMttJPbpdd9c7np7kqTN02FuQowEW96jV9hfMk6tFieKb42pkE7MlyDM9dlGNcTB32UyTW-FNqq3bXNMo08OLDWrEnZKx5KwBuOM7tqfVgo2JEOA_JRMtSs3yRVFOJTbE1pU/s400/VMR+Agent+Communication.png" /></p><p align="justify"><span style="font-size:85%;">Figure 2, depicts the internal design of the transition Translate Packet, wherein, several agents are non-linearly assembled. Packets move concurrently across the agent system which is supported by the CPN infrastructure for such dynamic data movements. An agent receives the packetNo and the arrivalTime from the place DISPATCHED. As the packet travels from one agent to another, the task of translating a message to a generic format is distributed among various agents. Drilling further through the Petri Net hierarchy, we find the design of one agent which triggers several processes towards translating a packet into different formats. However, for simplicity we only present a model of the lowest level of the hierarchy, the FIFO queue sub-net structure (Figure 3), that buffers all the packets that reaches the agent, and which represents the communication medium of each agent, found in the sensor class of the VMR (see section 2). The queue component resides within the sensor class of an agent with the value vh, being dynamic and adjustable during simulation, indicating the top stop mark capacity of the queue’s buffer and when hit, it blocks the packet entry. Unless the buffer is freed, outgoing packets have to wait for their acceptance. Another watermark is the high watermark denoted by h, and when reached, the rate of incoming packet is decreased until the number of packets inside the queue’s buffer reaches the low water mark which indicates that the queue is within normal parameters of operation and no protective measures are required.<br />When the Transition Packet Arrives is fired, the queue receives a new packet, hence a token is added to the place arrived. Upon arrival, each packet is paired with a number, (see place packet stamped), which contains a time stamp and it is equal to the current model time, created by means of the function timeStamp(), on the arc between Packet Arrives and arrived. The place arrived characterises the packets that reached the queue and are waiting for clearance. Next, the queue pushes the packet into its buffer and the waiting line is shown by the occurrence of the transition PushIntoBuffer.<br /></p></span><br /><img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 400px; DISPLAY: block; HEIGHT: 332px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5536416869000877810" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsJkk04WVE41A1wGlKzHoxIeUyZRRCw0K-ppWXC20cbiH58OZlGJH8-9pntr3E_L69NMC0g6aWcyunxU1HHCoByEpXx8S0-zihL0YkqGSWVPtoHfSQ379r-V4-O7TUcLeHuRS9-Vtnl9Y/s400/VMR+Agent+Queue+Model.png" /> <p align="justify"><span style="font-size:85%;">The arcs between NextPacket and PushIntoBuffer ensure that packets are loaded into the queue in the same order in which they joined which enforces the FIFO structure. When packets are loaded onto the buffer, shown by the place buffered, they are counted (see the inscriptions on the arcs between PushIntoBuffer and buffered, noOfPackets). At this point, packets are inside the buffer and waiting for the next run where the queue might perform some simple processing to the packets before releasing them. Once one packet completes its processing cycle, a token is added to the place leaves. Any claims from the place, causes the transition Claims Packets to be fired which finally state that a packet has left the queue.<br />The model is an integer-timed Petri Nets, i.e. the queue is processed with relation to time. The Poisson function, at the entry point is used to model the inter-arrival time for packets, and it can be found in the code segment associated with Packet Arrives. By changing the value in the function’s argument, the mean of the Poisson is altered and thus providing different spectrum of simulation conditions. The function CalcAccTime() in the code segment for the transition PushIntoBuffer to calculate how much time is needed for loading a given packet. The function NormDistr() is used to calculate how much time is used for a packet to be processed, as shown in the code segment for Process. This is particularly useful when one needs to make a number of simulations using different parameters.</span><span style="font-size:85%;"><br />In summary the objectives of the simulation of the VMR CPN model are as follows:<br />(i) To observe the percentage time a unit (packet) leaves an agent given a high input rate. This is to probe the information on the throughput of the queue during high input to the VMR system.<br />(ii) To observe the average time a unit (packet) spends in the VMR System. This is to provide information on the likelihood of out-of-time packet(s), should the latter wait excessively in any queue buffer of any agent.</span><br /><br /><span style="font-size:85%;"><strong>5.2. Results and Observations</strong><br />The simulation exercises investigate how packets move amongst the VMR Agents, with variable parameters at different level of hierarchy. The model was fed with packets at random intervals and the output was observed and recorded. The experiments were broken down into two series (experiment 1 & 2).<br />• Experiment 1 explains that the queues inside the agents resorted to protect themselves whenever the time interval between incoming packets was smaller than the service time of the queue, which consequently resulted in some packets being rejected.<br />• Experiment 2 stresses on the likelihood of out-of-time packet in the VMR System. This is defined by a function of the agent’s internal latency, queue’s buffer size and the input rate at the receiving end. It confirms that while attempting to gracefully slow down the number of packets entering the buffer, should an overflow occur; the queue inside an agent consequently causes packets to wait longer in its buffer.<br /><br />Experiment 1 starts by investigating the percentage unit time (ms) a packet leaves the multi agent system given a burst of input. The objective is to observe the throughput of the system in unconditional circumstances and evaluate its behaviour and efficiency to protect itself. We run through three simulations of 4000 steps and at step 1000 , we changed the Poisson mean from 1 packet per 10 ms to 1 packet per 3 ms, which provided the scenario for the burst and is the type of situation common to the domain of messaging. At each simulation we decreased the value of the watermarks, thus decreasing the waiting line in view of achieving conditions where packets have to wait longer to be serviced.</span><br /><br /></p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSZRSFG3I5zRr75sqVN_FZoNnjsU7n3gUAwork_M9b2Wy2V7WGcF6Utzcoe_-JhhNB8gUrg6YtFLQarM3T8swXJHQBz-KzFa3K7LPPE4XHY2aqzLtjEfPF1ezM6dfobVqXiETj_MXCEfk/s1600/Queue+Throughput+performance.png"><img style="TEXT-ALIGN: center; MARGIN: 0px auto 10px; WIDTH: 400px; DISPLAY: block; HEIGHT: 163px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5536431659663728578" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSZRSFG3I5zRr75sqVN_FZoNnjsU7n3gUAwork_M9b2Wy2V7WGcF6Utzcoe_-JhhNB8gUrg6YtFLQarM3T8swXJHQBz-KzFa3K7LPPE4XHY2aqzLtjEfPF1ezM6dfobVqXiETj_MXCEfk/s400/Queue+Throughput+performance.png" /> <p align="justify"></a><span style="font-size:85%;">Figure 4 runs through the simulation as the buffer sizes of the queues inside the agents were increased. We sampled the data into batches of 100 ms interval and recorded the number of packets entering and leaving the queue. Given a burst in packet entry, the graph shows the difference between the input rate and the output rate. The close proximity between the input and output rate justifies that that the service rate of queues within the VMR system is adequately lower than the input rate given an input rate of 100 packets per second (1 pck/10 ms) and a burst of approximately 350 packets per second (1 pck/3 ms). The simulation validates both decisions on the buffer size of lower limit 10 and upper limit 20.<br /></p></span><p align="justify"><span style="font-size:85%;">In experiment 2 we investigate the period of time a packet stays in the VMR at a given queue of an agent and draws the distribution of the packet’s lifetime. The experiment reports on the time taken for a large sample of packets to leave any queue of an agent. The objective was to estimate the number of out-of-time packet that exists given an input burst and a decrease in the buffer size. We analysed the period of time a packet takes to leave an agent, e.g. over hundred packets take 12 ms to leave the queue of a VMR agent. Hence using such analysis, a threshold can be established to identify the packets that have a probability of being out-of-time when claimed. For instance, should the out-of-time threshold be marked at 15 ms, any packet beyond this mark is irrelevant for the system.<br /><br />The experiments show how Petri Nets can be exploited to mine appropriate data so that the potential behaviour of a model under a set of parameters can be known. The obtained results provide a very good idea about the performance of the model, hence the formulation of directives prior to product deployment. If we look back at experiment 1 where a discussion on burst of input rate is presented, this is often very true in the mobile telecommunication and messaging systems. For instance, if we consider the message entry to a SMS Centre (SMSC) for one day, there is a pattern, wherein bursts can be found during the morning when people wake up and starts sending text message and burst at lunch time during their break time. To deal with the surge, system designers over-estimate the buffer size of queues within their systems, which is very inefficient in terms of resource allocation and economic viability. However, using simulation based on historical data of typical message distribution, one can provide a range, a lower limit specification size for off peak period and upper limit specification size for peak period. This is type of design is called design for capacity, which is a competitive advantage if possessed. Moreover, the simulation of the VMR model can be used to capture the user requirements at the early stage of the life cycle. This can be done by translating these requirements into the Petri Net simulation model which can help in identifying and observing the different behavioural patterns under different requirements. For example, if the user requirements place an important weight on reliability aspects of QoS, implying the high priority of reducing data loss, resources can be allocated within the model to reflect the importance of this requirement. Moreover, the simulation will provide detailed observations on the impact of increased reliability on other QoS parameters, particularly performance, as well as its impact on resource allocations i.e. cost. Thus, such observations provide more knowledge to enforce better accuracy for quality estimations, in terms of QoS. </span></p><p align="justify"><span style="font-size:85%;"></p></span><p align="justify">6. CONCLUSIONS<br /><span style="font-size:85%;">The paper presented an approach for modelling and simulation a multi-agent messaging system (VMR) using multi-level Petri Net formalism and CPN Tools. The paper also presented the potential of capturing and estimating the user requirements at the early stage of the software life cycle. As it can be observed, Petri Net is an adaptable tool, i.e. it allows alterations to a model so as to retrieve the necessary information from it. Two experiments were conducted to show how simulation can be executed to question a model. The results and observations provided more knowledge to enforce better accuracy to estimations particularly at the early stages. In terms of QoS, it shows how Petri Nets can be exploited to mine appropriate data so that the potential behaviour of a model under a set of parameters can be known. The obtained results provide a good idea about the performance of the model prior to product deployment.<br /></span></p><p align="justify"><span style="font-size:85%;"></p><p align="justify"></span>REFERENCES<br /><span style="font-size:78%;">1. Price Water House Cooper, “Technology Forecast: 2009”, 2009.<br />2. J. M. Wing, “A Specifier’s Introduction to Formal Methods”, IEEE Computer, vol. 23, 1990.<br />3. Kurt Jensen, “Coloured Petri Net – Basic Concepts, Analysis Methods and Practical Use ”, Vol 1, 2nd Edition, Springer, 1997.<br />4. Empower Interactive Group Ltd, “Virtual Mobile Redirector Manual Guide”, 2003.<br />5. Roger S. Pressman, “Software Engineering, A Practitoner’s Approach”, 5th Edition, McGrawHill, 2000.<br />6. Cisco Systems, “IP Quality of Service, – The complete resource for understanding and deploying IP quality of service for cisco networks”, Cisco Press, 2004.<br />7. J. Ellsberger, D. Hogrefe, and A. Sarma, SDL Formal Object Oriented Language for Communication Systems, Prentice Hall, 1997.<br />8. C-M. Huang and J-M. Hsu, “An Estelle-Based Probabilistic Partial Timed Protocol Verification System,” Int’l. Conf. Parallel and Distributed Systems, 2004.<br />9. T. Bolognesi and E. Brinskma, “Introduction to the ISO Specification Language LOTOS,” Computer Networks and ISDN Systems, vol. 14, Apr. 1987.<br />10. L. Millett and T. Teitelbaum, “Slicing Promela and Its Applications to Protocol Understanding and Analysis,” Proc. 4th SPIN Wksp., Paris, France, 1998.<br />11. Nam, S.Y., Sung, D.K., “Measurement Based Delay Performance Estimation in ATM Networks”, Globecom, 2000, pp. 1766–70.<br />12. Mouharam, A.A.K., “Monitoring Quality of Service on Broadband Networks”, PhD Thesis, Kingston University, 2002.<br />13. Makoond, B, “An Integrated Modelling Framework for the Design and Constructions of Distributed Messaging Systems”, PhD Thesis, Kingston University, 2008.<br />14. Khaddaj S, B Makoond and R Oudrhiri, “Distributed Computing Techniques for Wireless Messaging Systems” in ‘Journal of Algorithms and Computational Technology’, Multi-Science Publishing Co Ltd, 2008, pp. 1748–3018. Journal of Algorithms & Computational Technology Vol. 4 No. 3 323 </span></p>Dr. Bippin Makoondhttp://www.blogger.com/profile/10489437598692319170noreply@blogger.com3tag:blogger.com,1999:blog-7848800761385484905.post-16494309314151814682010-03-18T22:18:00.054+00:002010-03-19T02:18:55.583+00:00The Adoption of Testable Architecture to Model Service Discovery Mechanism within a Distributed system<div align="justify"><span style="font-size:85%;"><strong>Overview<br /></strong>This paper reports on the study that has been carried out on the process of designing the capability of service discovery within the mechanics of a distributed architecture to supports the paradigm of service oriented. Using classical software modelling tools, the ability to model discovery capabilities is constrained due to the static nature of the tools. We are required to adopt the approach of inductive modelling discipline, i.e. the formulation of dynamic models in order to test the model against a yield that conforms to the dynamic nature of distributed behaviours during the act of communicating. Service discovery is typically a dynamic facet of distributed models and due to the fact that there are different discovery approaches, we need to know, upfront, which ones best conform to the character of the distributed model one is planning to build. Testable architecture (TA), with its advances to accomodate the formalism of Coloured Petri Nets, to complement pi-calculus provide the neccessary framework and mathematical rigour to model the dynamism of service discovery before any lines of codes have to be created. This helps to reduce the cost of development by reducing the rate of defect injections, from design to build, since the phenomenon of emergent behaviours amongst communicating behaviours can be tested and be revealed at the early stage of the Software Development Life Cycle (SDLC). In our study we exploit TA to provide us with a simulation environment in order to model and test the dynamic behaviours of distributed systems for the problematic of service discovery.<br /><br /><strong>Service Discovery</strong><br />The word discovery, as the oxford dictionary illustrates, is the act or process of finding out or becoming aware of what was yet not found (Oxf03). In the context of the network engineering, service discovery is a method of determining and instantiating the resources required to manage and operate network entities and their associated software composition. The latter are often deployed across multiple nodes within a cluster and communicate with each other to mutually form a series of defined services. Existing models to service discovery have been developed primarily for fixed network backbone environments and typically rely on centralised components being accessible to potential service clients at any given time (Gutt99, Arn99 and Mic99). In highly dynamic nature of underlying network topology, these models lack the designated service infrastructures, hence rendering such discovery mechanisms unsuitable for ad hoc environments. The concept of service discovery is well established in distributed systems, since networked entities need to discover available remote resources (Mull85). Work on service discovery focus on using decentralised architectures to overcome the limitations of traditional discovery mechanisms, such as Service Location Protocol (SLP) (Gutt99), Jini (Arn99) and UPnP (Mic99), which rely on fixed infrastructure. Research in service discovery architectures for mobile environments can be classified into lower layer service discovery protocols (Haa99, li00 Xue01 and Koz03) and higher-layer service platforms (Herm00, Chak02 and Hel02). Service discovery protocols emphasise on efficiency and distributed infrastructure while service platforms focus on providing a middleware layer that enables applications to use a service oriented programming model. The reader should note that the works carried out on service discovery architectures, (Zhu02, Cho05 and Enge05), provide a survey and an evaluation analysis of different service discovery models.<br /><br />In our study we place emphasis on the higher layer service platform, with the objective of designing and simulating the different service discovery strategies in the context of distributed messaging services. The aim is to model and build fast and robust service discovery strategies, which are the main drivers for efficient management and organisation of distributed system.</span></div><p><span style="font-size:85%;"></span></p><div align="justify"><span style="font-size:85%;"></span></div><div align="justify"><span style="font-size:85%;"></span></div><div align="justify"><span style="font-size:85%;"><strong>Structure & Data Model<br /></strong></span><span style="font-size:85%;">The data model explains the relationships between the known entities, showing how services are provided by a given application (see Figure 1). It also shows how the participants or software components and the physical nodes relate to each other within a cluster by means of service discovery strategies. </span></div><div align="justify"><span style="font-size:85%;"></div></span><p align="center"><span style="font-size:85%;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCQXHhMnPkLgqJsh1M8KopgLNM9zCNKUhpxcs0kguVM2MCjkGJMF3QvfBqj53f_aU9pGg5IT8yoewl-lm6R6t-R9KXE16-axy2A9fvjF93PF36codZKPHVcnZ3H7yNRLwFL8aPZZBvbo0/s1600-h/ERD+of+SD.PNG"><img style="WIDTH: 400px; HEIGHT: 315px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450150587364755490" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCQXHhMnPkLgqJsh1M8KopgLNM9zCNKUhpxcs0kguVM2MCjkGJMF3QvfBqj53f_aU9pGg5IT8yoewl-lm6R6t-R9KXE16-axy2A9fvjF93PF36codZKPHVcnZ3H7yNRLwFL8aPZZBvbo0/s400/ERD+of+SD.PNG" /></a></p><div align="center">Figure 1 ERD of Service Discovery Model<br /></div></span><div align="justify"><span style="font-size:85%;">The Entity Relationship Diagram (ERD) in Figure 1, shows that the entity Service Discovery Strategy has many types, (entity Types) which defines the properties of a distinct strategy and the cluster of nodes they manage. The purpose of the Service Discovery Strategy is to locate a particular service, represented by the association search for entity Service. This association will define the route, shown by entity Route, which will be used by a node to process a particular service. The entity Route describes the connectivity model between nodes and associated services.<br /></div></span><p></p><p align="justify"><span style="font-size:85%;"><strong>The Communication Model of Service Discovery</strong><br />The communication model for the purpose of service discovery explains two essential concepts.<br /><u>Communication Agreement Model</u><br />The communication agreement model describes the five distinct states of affairs during the deployment and run time of a cluster of services. It shows that there are defined sequences of operations at a distinct phase of the network life cycle. The five communication agreement models are as follows:<br />o Cluster Establishment (CE)<br />o Cluster Maintenance (CM)<br />o Service Agent Establishment (SAEST)<br />o Service Agent Enablement (SAEN)<br />o Service Agent Maintenance (SAM)<br /><u>Communication Styles</u><br />The communication style defines the manner in which information is exchanged and how it determines the service discovery strategy. We considered the four most common strategies of service discovery:<br />o Exhaustive search<br />o Broadcast All acknowledge<br />o Broadcast 1 acknowledge<br />o Transactional publish subscribe<br />The hypothesis states that the implementation of a particular communication style depends on the type of communication agreement model in place which implies that using only one type of service discovery strategy e.g. broadcast, to manage all types of communication agreement models may be not efficient and eventually implausible to manage as the system evolves. The study has been designed to validate the hypothesis and applies a blended modelling approach to join simulation models with the qualitative modelling techniques.<br /><strong>Communication Agreement Model<br /></strong>The communication agreement model represents the distinct states of a cluster within a defined life cycle. It holds a collection of operations which are enforced by a cluster manager in order to start, run and maintain a system. We have identified 5 distinct collections of operations and each of them is carried out using one or more service discovery strategies. Subject to the type of operations in place and the state of a cluster, each of the service discovery strategies has different properties influencing the overall quality of a system.<br /><u>Cluster Establishment</u><br />In order for a cluster to be established, the service manager initiates the start-up sequence within a physical node, and attempts to discover the availability of other nodes within the cluster (see Figure 2). It establishes a communication channel between each active node and these allow for the transfer of heartbeats between Service Managers as well as updates regarding service agent establishment and service agent maintenance messages across the cluster. If more than one service manager is active, a mechanism should determine a Master Service Manager for the Cluster and information from the master should be distributed to Slave Service Managers. Both master and slave service managers are Local Service Managers for their respective nodes. Should no other service managers be found during the start-up sequence, the started service manager begins service agent establishment.<br /></p></span><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxY3ZikUVTenLyrYBj2HZmoOQSbjQ3eR8xXC2yuuG3towhUeMiYMoF_EQpQmVKapT0uuLy3LZwUNR77hL9no88p1xvTRMvfxtir-dxZVo_RHC_eESpU1NdQnxmDHG5oFtQAQfS14zxwAA/s1600-h/Cluster+Est.PNG"><span style="font-size:85%;"><img style="WIDTH: 388px; HEIGHT: 237px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450121735115107874" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxY3ZikUVTenLyrYBj2HZmoOQSbjQ3eR8xXC2yuuG3towhUeMiYMoF_EQpQmVKapT0uuLy3LZwUNR77hL9no88p1xvTRMvfxtir-dxZVo_RHC_eESpU1NdQnxmDHG5oFtQAQfS14zxwAA/s400/Cluster+Est.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Figure 2 Cluster Establishment </span></p><p align="justify"><span style="font-size:85%;"><u>Cluster Maintenance<br /></u>In order for a Cluster to be maintained, the master service manager should be capable of handling the introduction and removal of slave service managers (essentially the addition or removal of nodes from the cluster). Should the master service manager fail, one of the remaining (if any) slave service managers should adopt the role of a master service manager. This may result in service agent establishment, enablement and maintenance as necessary which are described below.<br /><u>Service Agent Establishment</u><br />In order for a Cluster to be fully functional, the Local Service Manager should be capable of starting Service Agents upon the node as determined by the Master Service Manager (see Figure 3). The Local Service manager controls different types of service agents which are responsible for distinct tasks. For instance a particular Service agent may be responsible for managing the connection to external entities such as Billing Platforms, whereas others are responsible for Customer Data Managements.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBpHI2IUpOdXS0iXA9ha-0Qv7yRsZKgF-0ovAirzGS6Zsch6zgBQYLLyowryNzM0XJ75DLXni0e1vHRazgs_9FQiprJYMyW5srgyuEI6pvUVXY_5HfW7bBURhyphenhyphenCSc-JCnaVcv5cjzE2m8/s1600-h/Cluster+Agent+Est.PNG"><span style="font-size:85%;"><img style="WIDTH: 360px; HEIGHT: 221px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450122287990473074" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBpHI2IUpOdXS0iXA9ha-0Qv7yRsZKgF-0ovAirzGS6Zsch6zgBQYLLyowryNzM0XJ75DLXni0e1vHRazgs_9FQiprJYMyW5srgyuEI6pvUVXY_5HfW7bBURhyphenhyphenCSc-JCnaVcv5cjzE2m8/s400/Cluster+Agent+Est.PNG" /></span></a></p><p align="justify"><span style="font-size:85%;"></span></p><p align="justify"><span style="font-size:85%;"></span></p><p align="center"><span style="font-size:85%;">Figure 3 Service Agent Establishment </span></p><p align="justify"><span style="font-size:85%;"><u>Service Agent Enablement</u><br />Service agent enablement is the process wherein the local service managers, instantiate service agents on individual nodes and report the start-up status to the master service manager. The master service manager will then issue routing information to the local service managers, which is then propagated to the service agents on each node. The master service Manager upon validation that the minimum required agent base is available to run an application instance e.g. an underwriting workflow, should issue a signal to the local service managers to inform the service components to initiates business process. Figure 4, shows an example of service agent communication across a cluster and the communication channels between service agents. The communication between the service managers’ communication and service agents is not shown for diagram simplicity.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7f3MgWiyzo-7ELQ2Wjso-3yJuflJGcB_HYSmuGLTBQG6jAAmo4cv1lTscPsaU6jORESe8gVZbu6oyIM1nU6S-ozcTsMPFpj9jm0TrA1BT-VfxBJX-nPEB0IzMTPozV8GmnQlAs_wl1qE/s1600-h/Service+Agent+Enable.PNG"><span style="font-size:85%;"><img style="WIDTH: 374px; HEIGHT: 221px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450122903300315810" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7f3MgWiyzo-7ELQ2Wjso-3yJuflJGcB_HYSmuGLTBQG6jAAmo4cv1lTscPsaU6jORESe8gVZbu6oyIM1nU6S-ozcTsMPFpj9jm0TrA1BT-VfxBJX-nPEB0IzMTPozV8GmnQlAs_wl1qE/s400/Service+Agent+Enable.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Figure 4 Service Agent Enablement </span></p><p align="justify"><span style="font-size:85%;"><u>Service Agent Maintenance</u><br />Service agent maintenance is performed by a local service manager and is responsible for handling the start-up and shutdown of service agents as determined by the master service manager. The Local Service Manager is also responsible for reporting to the Master Service manager any failure of a Service Agent so that it can be instantiated elsewhere within the cluster. </span></p><p align="justify"><span style="font-size:85%;"><strong>Communication Styles</strong> </span></p><p align="justify"><span style="font-size:85%;">We define communication styles as the ways or manner information is conveyed across dispersed nodes within a cluster. The communication styles are the different strategies applied to locate and instantiate services within a cluster of services. As mentioned earlier, the discovery strategies are available with various properties and can be broken down into the following categories:<br /><u>Exhaustive Search Strategy</u><br />Exhaustive search is a brute force method where a service polls for information against the known services until the desired response is received (see Figure 5).<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMTKamQ4G-1Gjuhto50sGlwxMY0IwUeyesHgvxCPh-9WBxU9jlpGbGIVhyp8ovbH5qMDdRoAPymMQOQaSysoaHzT68oF7Up0naVRHqYccSMrNdIHwN6QSBrhNd2rooQPbNPXnHuHxc6Vo/s1600-h/op+model+exhaustive+search+model.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 203px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450123248690199490" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMTKamQ4G-1Gjuhto50sGlwxMY0IwUeyesHgvxCPh-9WBxU9jlpGbGIVhyp8ovbH5qMDdRoAPymMQOQaSysoaHzT68oF7Up0naVRHqYccSMrNdIHwN6QSBrhNd2rooQPbNPXnHuHxc6Vo/s400/op+model+exhaustive+search+model.PNG" /></span></a></p><p align="center"><br /><span style="font-size:85%;">Figure 5 Operational Model of the Exhaustive Search Strategy<br /></span></p><p align="justify"><span style="font-size:85%;">With an exhaustive search any service will iteratively poll other services starting with the first, wait for a response and if the result is negative will continue to the second and await its response until such time as the desired response is obtained or no further services to be polled remain. </span></p><p align="justify"><span style="font-size:85%;"><u>Broadcast Strategy</u><br />Broadcast discovery is a method where a polling service broadcasts a request to a number of services in order to receive a response. This is normally an information request or a request for something to be processed. There are two models which can be considered: </span></p><p align="justify"><span style="font-size:85%;"><u>Broadcast (All Respond)</u><br />With the “Broadcast All Respond” model, all services that can possibly handle a request are transmitted and each polled service issues a request response (see Figure 6). This request response can be either a positive response indicating a service has been performed successfully or an information response passing data to the polling service. It can also be a negative response indicating that the service request cannot be performed or the information requested is not available or accessible by the polled service. The polling service should have a timeout mechanism if only unsuccessful responses or no response be forthcoming.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaCYQEx2XrJpQ0448UcAwZwli4BPADapv4Wlt0EFjwrGdqCpnjgT1GqEN23adM2gy-zV66jhY3W2gThBZeihA3-WatXJaVdOybqwB10fMbrRN2OOpIWTmxvKwB_Yto2awMlTshGDAP8w8/s1600-h/op+model+Broadcast+active+responsel.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 198px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450123731789780098" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaCYQEx2XrJpQ0448UcAwZwli4BPADapv4Wlt0EFjwrGdqCpnjgT1GqEN23adM2gy-zV66jhY3W2gThBZeihA3-WatXJaVdOybqwB10fMbrRN2OOpIWTmxvKwB_Yto2awMlTshGDAP8w8/s400/op+model+Broadcast+active+responsel.PNG" /></span></a></p><p align="center"><br /><span style="font-size:85%;">Figure 6 Operational Model of the Broadcast Strategy </span></p><p align="justify"><span style="font-size:85%;"><u>Broadcast (Active Respond)</u><br />With the “Broadcast Active Respond” model (see Figure 7), all services that can possibly handle a service request are transmitted however only polled services that can issue a positive response indicating a service has been performed successfully or return data to the polling service, responds. All other services continue as if the service request was never received. The polling service should have a timeout mechanism if no response be forthcoming. </span></p><span style="font-size:85%;"><p align="center"><br /></span><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXCVM1Y_kNYI8AUAZpfyrvhKPfgpUC9DzE7bZ629eDYwHaPSoRshRukllpak8lvIv5oZ22IdhfMLCfoqPe0SwJ_MxifTAldqOSDPjcYjTwthJj7rfawsXL06b3KISuEhS8zFMxUZPRlwY/s1600-h/op+model+Broadcast+active+response1.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 199px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450124285297217106" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXCVM1Y_kNYI8AUAZpfyrvhKPfgpUC9DzE7bZ629eDYwHaPSoRshRukllpak8lvIv5oZ22IdhfMLCfoqPe0SwJ_MxifTAldqOSDPjcYjTwthJj7rfawsXL06b3KISuEhS8zFMxUZPRlwY/s400/op+model+Broadcast+active+response1.PNG" /></span></a><span style="font-size:85%;"><br /></span><span style="font-size:85%;">Figure 7 Operational Model of the Broadcast Active Respond Strategy<strong><br /></strong></p></span><p align="justify"><span style="font-size:85%;"><u>Transactional Publish Subscribe Strategy</u><br />The “Transactional Publish/Subscribe” method involves publishing a service request to a list (see Figure 8). The service request list is a FIFO list and any servicing entity may remove the first request from a list, however only one service may subscribe to process a single service request. Upon completion of a service request the servicing entity sends its response to the Posting service. It is possible to have multiple posting services publishing to the same service list. The posting service should have a timeout mechanism to recover if a response to a published request is not forthcoming. </span></p><span style="font-size:85%;"><p align="center"><br /></span><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpxfk-4p6Vjwcs9nrOI6xXtC1aTJMEX4xsvNFg6LYll0zkUM8iIe6_vLM-oBZESE0WVNBiIeG2gK6FJ-zIK5nOicYJJaa0p6N2Has-BnNjJU3yb2dD6Icjdu_apnb47Ohgxg8WlkjyYKI/s1600-h/op+model+TPS.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 172px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450124610397286322" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpxfk-4p6Vjwcs9nrOI6xXtC1aTJMEX4xsvNFg6LYll0zkUM8iIe6_vLM-oBZESE0WVNBiIeG2gK6FJ-zIK5nOicYJJaa0p6N2Has-BnNjJU3yb2dD6Icjdu_apnb47Ohgxg8WlkjyYKI/s400/op+model+TPS.PNG" /></span></a><span style="font-size:85%;"><br />Figure 8 Operational Model of the TP Subscribe Strategy </span></p><p align="justify"><span style="font-size:85%;">As part of the “Transactional Publish/Subscribe” method the question arises as to where the location of a service list resides and if the list should have local copies (caches) located across the cluster rather than in a central location. The relevance of whether a local cache is advantageous depends on the nature of the data stored within the service list. Data which has a short life span is less suitable for caching locally than data that has a longer life span. Also data that requires constant updating is less suitable to local caching than any data that has a fixed value. The reason for this is that constant updating of the primary list affects all cached lists and updating of the local caches requires significantly more resources than simply the maintenance of the primary list. As the number of caches increases so does the amount of required resources to maintain them.<br />All the above discussed strategies, share a common format in that services expose an availability notice to the service discovery element and running services communicate to each other using one or more of the strategies mentioned.<br /><br /><strong>Simulation Model</strong> </span></p><p align="justify"><span style="font-size:85%;">In this section we demonstrate the use of TA to formulate the dynamic Petri Net models of service discovery mechanism so as to validate which discovery strategy best conforms to the SLAs and quality requirements of the system. As mentioned earlier, there are five communication agreement models that define the state of a cluster within a life cycle. The following sections show the characteristics of the communication agreement models to understand the frequency of their occurrences within the life cycle of a cluster and to test each service discovery strategy (communication style) against each of the communication agreement models. </span></p><p align="justify"><span style="font-size:85%;"><u>Cluster Establishment<br /></u>Cluster establishment happens once in the system life cycle, at initialising time. There are several service managers and each manager is required to know about their neighbouring services. The simulation performs a many to many relationships between the service managers wherein all service discovery strategies compete with each other to find the best strategy for service discovery at that level. </span></p><p align="justify"><span style="font-size:85%;"><u>Cluster Maintenance<br /></u>Cluster Maintenance occurs periodically during the system life cycle. At run time, the master service manager communicates with the slave service managers to check their existence through distinct “heart beats” which is configurable. This process maintains a quorum defining the instance of a cluster, where the communication is based on one-to-many relationships. </span></p><p align="justify"><span style="font-size:85%;"><u>Service Agent Establishment</u><br />Service agent establishment happens once during the system life cycle, when a cluster is established and its boundary is defined. The next operation is to identify and initiate the service agents within the cluster. The service managers communicate with the service agents, which is based on one-to-many relationships. </span></p><p align="justify"><span style="font-size:85%;"><u>Service Agent Enablement<br /></u>Service agent enablement happens once during the system life cycle. It concludes the final phase of initialising the service agents, after all the services have been established. In our scenario, the service enablement process will cluster all the related service agents to formulate a particular instance of a messaging gateway application. This is a many to many communication style of service discovery.</span></p><p align="justify"><span style="font-size:85%;"><u>Service Agent Maintenance<br /></u>Service agent maintenance occurs periodically during the system life cycle. In this state, service agents are connected and communicate to complete a typical service. During this operation, some information might be required from service agents, thus triggering service discovery, which is a many to many communication style of service discovery. </span></p><p align="justify"><span style="font-size:85%;">We observe that service discovery mechanisms are implemented at different states of a cluster life cycle and also that it is used at two phases of execution; 1) at initialisation time – frequency of occurrence is once, 2) during run time – frequency of occurrence is periodical.<br />In order to simulate the different service discovery scenarios, the high level description of the proposed communication styles are translated into a dynamic Petri Nets model. </span></p><p align="justify"><span style="font-size:85%;"><strong>The Broadcast Strategy<br /></strong>Figure 9, shows a number of configurable Places representing individual agents, where each of them has two states, ready and performing, depicted by the place Agent. When the simulation starts, the transition SendMessage is fired to broadcast discovery requests to all the clustered agents. The post condition of such flow is defined by the place sent which is of type TimedMSG. A message therefore, consists of a source and a destination. When a message is sent, the destination agents receive those messages which enable the transition ReceiveDTMessage to occur, firing the place received. On receipt, the agents process the message, shown by the transition ProcessMessage and acknowledges to the source which is done by firing the transition SendAcknowledgement. The place ack explains that the source agent has received an acknowledgement, i.e. the transition ReceivedAcknowledgement is fired. This ends the first round of broadcast strategy and another process with a different source is initiated. Figure 9 describes the discovery traffic that occurs during a broadcast where the Petri Nets distinguish between the application traffic and the network traffic. Application traffic is any type of traffic that is not related to service discovery but can request an initiation of service discovery. An analogy is a service agent dedicated to storage and its objective is to read from and write to databases. So the reading and writing of data exchange occurs over the application traffic. </span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisI2cXbd9CgjwyO95z3sy06cQA7kQnCLYMNdEOMEnrj3zM9CRJwczM5frZ50p9xGcKU6UbLKrC1HhR2xA0ltqGjxR68w46uV6N_IvMjIlvUxyXxNidmXQ9F_7JM4ohMZvW-mxU5tHFF-E/s1600-h/CPN+Broadcast+strategy.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 256px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450124956759696962" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisI2cXbd9CgjwyO95z3sy06cQA7kQnCLYMNdEOMEnrj3zM9CRJwczM5frZ50p9xGcKU6UbLKrC1HhR2xA0ltqGjxR68w46uV6N_IvMjIlvUxyXxNidmXQ9F_7JM4ohMZvW-mxU5tHFF-E/s400/CPN+Broadcast+strategy.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Figure 9 CPN Model of the Broadcast Strategy</span></p><p align="justify"><span style="font-size:85%;">In Figure 9, there is a producer of events that causes application traffic by assigning a message for agent. When a message arrives, an agent fires the transition ReceivedNTMessage. Consequently the place arrived shows a message exist and an agent needs to process the message. The transition ProcessMessage is triggered and the place processed contains a resource which is a message. The final phase of the system is the transition Execute that occurs when the message leaves the system. Therefore the model allows agents to handle both application traffic and discovery traffic. The impact of network traffic over application traffic provides a key indicator of throughput performance which can be observed through simulation. </span></p><p align="justify"><span style="font-size:85%;"><strong>The Transactional Publish Subscribe Strategy</strong><br />Figure 10 shows some similarities in the design of the broadcast and the Transactional Publish Subscribe (TPS). Transitions such as ReceiveDT/NTMessage, ProcessMessage and Execute perform the same tasks as described in the broadcast model. However, there exist an agent pools where agents are able to subscribe to a service for publishing information on a board. This is depicted by the transition SubscribeAgent, which after successfully subscribing to the board, represented by the place subscribed, the agents enters a FIFO queue, EnterAgentQueue and goes to the ready state, shown by the place ready. When the agents are in the ready state, three things may happen; 1) the agent may be a source and publish information on the board which will consequently fire the transition SendMessage; 2) The agent may be a destination and receives discovery traffic, shown by the transition ReceiveDTMessage, or 3) the agent may also be a handler which handles application traffic when a message event occurs.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu37UTJ1Pkm9IuBVPQEvNAniwktQrK89QZhPUUi0VltZkW6Vz9LiukGGpkUppGwlNfwhVOALz1k9lf02BS01jStnKcBH7lZyx5LnzVJ0zZMYa4rNKxQl7bRJYDu9A23sNEDwlCgYNipuQ/s1600-h/CPN+TPS+strategy.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 250px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450125279876890258" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu37UTJ1Pkm9IuBVPQEvNAniwktQrK89QZhPUUi0VltZkW6Vz9LiukGGpkUppGwlNfwhVOALz1k9lf02BS01jStnKcBH7lZyx5LnzVJ0zZMYa4rNKxQl7bRJYDu9A23sNEDwlCgYNipuQ/s400/CPN+TPS+strategy.PNG" /></span></a><span style="font-size:85%;"><br />Figure 10 CPN Model of the TPS Strategy </span></p><p align="justify"><span style="font-size:85%;"><strong>The Exhaustive Search Strategy</strong><br />The Exhaustive search model (see Figure 11) is again very similar to the broadcast model. The difference is that in exhaustive search, the message from the transition SendMessage is not publicised. Here only, one message leaves the transition SendMessage and one destination agent receives it, shown by transition ReceiveDTMessage. The source agent will not send another message until it receives an acknowledgement from the destination agent. The place wake & sleep allows an agent to send a message but it needs to wait until it receives an acknowledgement from the destination to be able to ask another agent.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGf_t8cWWglZoGsSWskcVxY8DeWUZnPeJaWzK-wV9an-YkhcMjWZnUC0c6RWFCofiGb6CrzIZY7bxV7xnMUPcsqKaS7Mb1wXUQqRdnVn5lQ0nEr55-Tn9L4YUOz64Nsey_G64EB3zAyEc/s1600-h/CPN+Exhaustive+search+strategy.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 247px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450125655189593106" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGf_t8cWWglZoGsSWskcVxY8DeWUZnPeJaWzK-wV9an-YkhcMjWZnUC0c6RWFCofiGb6CrzIZY7bxV7xnMUPcsqKaS7Mb1wXUQqRdnVn5lQ0nEr55-Tn9L4YUOz64Nsey_G64EB3zAyEc/s400/CPN+Exhaustive+search+strategy.PNG" /></span></a></p><p align="center"><br /><span style="font-size:85%;">Figure 11 CPN Model of the Exhaustive Search Strategy </span></p><p align="justify"><span style="font-size:85%;"><strong>Application of Service Discovery Strategies to a typical Messaging Scenario</strong><br />This section introduces a scenario, which attempts to position the concept of simulation and dynamic modelling into a real life situation of distributed messaging services. The process is called a Delivery Request which is a work flow model, designed to represent that a SMSC requires an acknowledgement that a message has been delivered to an IP based application. The objective of the simulation scenario is to find out which service discovery strategy (communication style) best conforms to the specifications of this particular work flow. </span></p><p align="justify"><span style="font-size:85%;">When the simulation starts, a transition ApplicationSendMSG sends message to the system, hence the place arrived indicates that a message has reached the system (see Figure 12). Upon arrival, the message is processed i.e. an agent is assigned to the message, resulting to the transition ProcessMessage to be fired. Each message has a ticketNo which is checked by the agent to know which SMSC the message is ought to be sent. If the agent does not know about the message, it finds it by triggering a service discovery mechanism. As mentioned there are three types of strategy, Broadcast (all respond / active respond); Transactional Publish Subscribe; Exhaustive Search. When an agent who knows about the existence of the message is found, it sends an acknowledgement to the sender, shown by the transition sendAcknowledgement. The sender receives the acknowledgement and fires the transition ReceiveAcknowledgement. Next the sender sends the message to the destination agent which is depicted by the transition SendMessageToAgent. The agent then sends the message to the committed SMSC, shown by the transition DeliverToSMSC. The Petri Net model was simulated wherein each service discovery strategy proposed was submitted to the test for a delivery request.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRiOVucB5AGp7KYc5LqyI7nz_uVismLoKQU81UrMQ0ooMR-QjZ_eOyugktls3mHcAHaA2wA8pxJ8ec6Nr6AFkxfmJmFpa1vkbr5B7FzNWvN6bFgpJ0sNEBzWwOhe3Oo3Df3P64vQIUWHc/s1600-h/CPN+Delivery+Req.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 242px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450126007387736658" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRiOVucB5AGp7KYc5LqyI7nz_uVismLoKQU81UrMQ0ooMR-QjZ_eOyugktls3mHcAHaA2wA8pxJ8ec6Nr6AFkxfmJmFpa1vkbr5B7FzNWvN6bFgpJ0sNEBzWwOhe3Oo3Df3P64vQIUWHc/s400/CPN+Delivery+Req.PNG" /></span></a><span style="font-size:85%;"><br />Figure 12 CPN Model of Delivery Request Model in Messaging </span></p><p align="justify"><span style="font-size:85%;"><strong>Observations</strong><br />A cluster is complete after the service agent enablement state has been reached, thus all the service agents, that are required to complete a distinct messaging gateway application, are enabled. The service managers are responsible for one or more service agents. In order to establish a messaging gateway, the service managers need to find out about themselves and ask each other the type of service hosted.<br />We looked at the generic model of broadcasting, exhaustive search and transactional publish subscribe. Three simulations of 30,000 steps with one millisecond interval each, were executed. We change the agent population from 4 to 20 units for each simulation to address the quality attribute of Scalability. The first scenario considered was the process of establishing a cluster, referred to as the cluster establishment. After the simulation, we tested for the normality of the observed results, then conducted a 2 sample T Test (Park07) on the service discovery message processed per unit time. We then compared which strategy has a greater mean for message processed per second, i.e. the speed for processing service discovery message relating to the quality attribute of Performance.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfXSpBbAy0NSUjcbiNtwM1HrEAGrrQg7fEAVeyVu5HKDk7zRrPDPjnvazujRpDlKJjhofZT3Aty-pUKmTUOntL1ldqRBS_q3nqNTgR-dCEU_yqv01aurFW2ou8FP0n27ak84JURt8e3_s/s1600-h/Ind+Value+Plot+Braodcast+vs+TPS.PNG"><span style="font-size:85%;"><img style="WIDTH: 373px; HEIGHT: 250px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450126391940137762" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfXSpBbAy0NSUjcbiNtwM1HrEAGrrQg7fEAVeyVu5HKDk7zRrPDPjnvazujRpDlKJjhofZT3Aty-pUKmTUOntL1ldqRBS_q3nqNTgR-dCEU_yqv01aurFW2ou8FP0n27ak84JURt8e3_s/s400/Ind+Value+Plot+Braodcast+vs+TPS.PNG" /></span></a><span style="font-size:85%;"><br />Figure 13 Individual Value Plot of Broadcast vs. TPS Strategies </span></p><p align="justify"><span style="font-size:85%;">We plot the service discovery packet processed per millisecond of the broadcast strategy against the Transactional Publish Subscribe (TPS). We observed that the mean message processed per second of Broadcast is bigger than the one of TPS. The distribution shows that the Broadcast strategy allowed more messages per second to be processed by destination agents rather than TPS. Hence the likelihood of Broadcast strategy finding a bigger population of agents within a period of time in a system is greater than TPS. However, the standard deviation of Broadcast against its mean is bigger than that of the TPS where the individual plots are more crowded around the mean (see Figure 13). Yet the distribution of TPS is steadier which shows that the overall network traffic is more stable and reliable. This is understandable since within the TPS model, there exist a FIFO queuing model allowing only one agent to process only one message for each simulation turn and if there is a burst of incoming message, the message waits in the queue’s buffer instead of flooding the system. TPS provides reliable network mode, yet the drawback for such strategy is that message may pile up at the queue, and messages have to wait longer than, perhaps, the defined Service Level Agreement (SLA). The flexibility of such system lies on how elastic the FIFO queue is, i.e. dynamic adjustment of its buffer. When compared to the Transactional Publish Subscribe strategy, Exhaustive Search really shows that very few messages are processed per second, thus exhibiting poor performance. As the number of agents scaled up, the performance dropped drastically (see Figure 14).<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1ridlvHixdDDPlAGJbQRlP4yqna-q7FTXL-Nea3Geguf9cLqgS0qOU_4wnnv-iXZkuP4IFyfPmnOGTPSNB94tmptCYzfhYIvRckgB3sqx4Sr8Jfv1rQ0JKyrfhGfkpsB0K-kjwWF7EPY/s1600-h/Ind+Value+Plot+TPS+vs+Exhaustive+Search.PNG"><span style="font-size:85%;"><img style="WIDTH: 366px; HEIGHT: 250px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450126805097841266" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1ridlvHixdDDPlAGJbQRlP4yqna-q7FTXL-Nea3Geguf9cLqgS0qOU_4wnnv-iXZkuP4IFyfPmnOGTPSNB94tmptCYzfhYIvRckgB3sqx4Sr8Jfv1rQ0JKyrfhGfkpsB0K-kjwWF7EPY/s400/Ind+Value+Plot+TPS+vs+Exhaustive+Search.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Figure 14 Individual Value Plot of TPS vs. Exhaustive Strategies </span></p><p align="justify"><span style="font-size:85%;">So both performance and scalability were poor for the Exhaustive Search strategy. We can understand that because in exhaustive search, when the source is looking for a destination agent, he waits idly for an acknowledgement and then search for the following agents, and so on, thus within a given time period, less discovery message is processed. However, with the exhaustive search strategy, the process to looking for a service and waiting for an answer make the strategy more robust, which addresses the quality attribute of Robustness. Should the reply from the destination agent be critical and necessary, we demonstrate that the exhaustive search strategy provides more robust solutions.<br />In Figure 15, the Box plot of the broadcast strategy against the transactional publish subscribe strategy, is another representation of the number of message processed per second. The area of the Box Plot for Broadcast is larger than TPS and it shows the weight of the distribution for message processed per unit time against TPS. So far, we found that the Broadcast is faster in processing service discovery message per a given unit time than TPS but TPS is faster than Exhaustive Search. What is required to understand is how the three service discovery strategies influence the application traffic of the network. When sampling data for the T Test of application traffic, we observed that there were not sufficient data points for the broadcast strategy. This is due to the fact that compared to the other two service discovery strategies, the broadcast strategy processes far too little of the application traffic. This is logical and observable when we increased the number of agents in the CPN model to 20 agents; a broadcast strategy floods the system with service discovery messages leaving very few agents idle to process application traffic. This is the case when there is no network separation between application and service discovery traffic.<br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiowb5oOVp4jMVzC2VDGqo1pgsZDeulao20akhT1NUmy8GgykgJS4GmDB7QlG37xd6glSKrv2j6BW0NVMblSjFVTTV2ZibUIIWp0rM2NhejUefaNaHSkzTH3Cb4hdBut3Rx_q9eQd6u0KY/s1600-h/Box+Plot++Braodcast+vs+TPS.PNG"><span style="font-size:85%;"><img style="WIDTH: 366px; HEIGHT: 250px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450127234911771394" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiowb5oOVp4jMVzC2VDGqo1pgsZDeulao20akhT1NUmy8GgykgJS4GmDB7QlG37xd6glSKrv2j6BW0NVMblSjFVTTV2ZibUIIWp0rM2NhejUefaNaHSkzTH3Cb4hdBut3Rx_q9eQd6u0KY/s400/Box+Plot++Braodcast+vs+TPS.PNG" /></span></a><span style="font-size:85%;"><br />Figure 15 Box plot of Broadcast vs. TPS Strategies </span></p><p align="justify"><span style="font-size:85%;">Figure 16 shows a graphical visualisation of application traffic processing between the broadcast TPS strategies. </span></p><span style="font-size:85%;"><p align="center"><br /></span><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhx2FllZqM6bm8uaZ4NpeJAGcZLvPde2mVirr5XUaG8jI6s9xZS6UPuJMYsyuIfcp91-Wpf1Rsl3TTfp9-iBwzKOpjaZ4YwEPYiMp0IMmjhqd0IwPhULLOwfgtPAlhJsQ_r4bjFASM3VZE/s1600-h/Throughput+Performane+Braodcaast+vs+TPS.PNG"><span style="font-size:85%;"><img style="WIDTH: 366px; HEIGHT: 247px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450127700255910834" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhx2FllZqM6bm8uaZ4NpeJAGcZLvPde2mVirr5XUaG8jI6s9xZS6UPuJMYsyuIfcp91-Wpf1Rsl3TTfp9-iBwzKOpjaZ4YwEPYiMp0IMmjhqd0IwPhULLOwfgtPAlhJsQ_r4bjFASM3VZE/s400/Throughput+Performane+Braodcaast+vs+TPS.PNG" /></span></a><span style="font-size:85%;"><br />Figure 16 Throughput Performance of TPS vs. Broadcast Strategies </span></p><p align="justify"><span style="font-size:85%;">The result of the analysis compares the throughput performance of application traffic of two systems, one using a broadcast strategy for service discovery, and the other utilises transactional publish subscribe (TPS) method with each system hosting 20 software agents. It can be observed, that the worst case of deprivation for application traffic is when the broadcast strategy is implemented. Using the transactional publish subscribe strategy application traffic performance was observed to be much higher. We applied a two sample T test (Park07) to compare the mean of the number of application traffic messages processed per second for the transactional publish subscribe and exhaustive search strategies (see Figure 17). </span></p><p align="center"><span style="font-size:85%;"><br /></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYR1gNZKABDFUPyyMwqzOkSxBf45ZbP824e7pnopl-vZ7j4XClEBxSpRRc5DcN889mle5Iwo5gDJjCVXvFQ5AGjfJIm4whwHVMQPGobA3ie8RIpj7JqksQ7TispWyM6Tie24Y6thrzRpQ/s1600-h/Individual+Plot+Exhaustive+vs+TPS.PNG"><span style="font-size:85%;"><img style="WIDTH: 390px; HEIGHT: 250px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450128070851517234" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYR1gNZKABDFUPyyMwqzOkSxBf45ZbP824e7pnopl-vZ7j4XClEBxSpRRc5DcN889mle5Iwo5gDJjCVXvFQ5AGjfJIm4whwHVMQPGobA3ie8RIpj7JqksQ7TispWyM6Tie24Y6thrzRpQ/s400/Individual+Plot+Exhaustive+vs+TPS.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Figure 17 Individual Plot of Exhaustive Search vs. TPS Strategies<br /></p></span><p align="justify"><span style="font-size:85%;">We observed that the exhaustive strategy processes more of the application traffic than the TPS strategy. This is true because, within the Exhaustive Search strategy, one agent sends a discovery message and waits for an acknowledgement. While waiting, it is idle to carry out its application traffic, hence increasing the flow of application traffic in the system. However, if we look at transactional publish subscribe we see that the distribution of application traffic in Figure 17 is similar to the distribution of discovery traffic in Figure 13. This demonstrates that the transactional publish subscribe method more or less uniformly shares the load of application traffic and service discovery traffic that is essential to support high scalability. Figure 18 shows the comparisons of all three Service Discovery strategies applied for the single problem of Delivery Request (see Figure 12).</span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLQKvWkRf9YCZzlpKWiLrB52_w1pxlw4S00Ra0R0QUkbyashFZwTKUpeN_o477vR5vO6WNBpBr7GIP8iBuyPFB0emtf8h4bePBWOK-K3LvfXV7ayNybaKAmLUctjayv5BNjBrvvpg1iMM/s1600-h/Barchart+all+SD+stratetegies.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 252px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450128424904428146" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLQKvWkRf9YCZzlpKWiLrB52_w1pxlw4S00Ra0R0QUkbyashFZwTKUpeN_o477vR5vO6WNBpBr7GIP8iBuyPFB0emtf8h4bePBWOK-K3LvfXV7ayNybaKAmLUctjayv5BNjBrvvpg1iMM/s400/Barchart+all+SD+stratetegies.PNG" /></span></a><span style="font-size:85%;"><br />Figure 18 Broadcast, Exhaustive Search and TPS strategies in a Delivery Request Scenario </span></p><p align="justify"><span style="font-size:85%;">The metric used to draw the graph, in Figure 18, is the cumulated probability that a packet is delivered within 10 millisecond of its arrival. This graph compares the mean evolution of the probability for all three service discovery strategies and shows their performance. The ideal system would guarantee a mean of 1. As we can observe, the broadcast strategy is closer to 1 than the other two service discovery strategies. This is possible because the Petri Net in Figure 12 models the agents as a multi-threaded system and can run service discovery traffic and application traffic concurrently. That model makes the assumption that service discovery and application traffic run on separate networks which implies that the broadcast service discovery strategy has a higher probability of delivering a packet within a small time of its arrival on a multi-threaded model dichotomising the application traffic with the Service Discovery Traffic. However, we did that at a cost of introducing a new problem of economics, since threads consumes CPU processing time (resources).<br />Figure 19 shows the ratio of packet delivery over packet arrival within 10 ms and allows packet forwarding should the ratio be outside the 10 ms timeframe. This occurs when packets are not delivered in turn but wait in the system and are delivered in the next or next + n turn. The Box plot shows the performance and reliability of each strategy for delivery request. The standard deviation tells us that transactional publish subscribe is steadier for service discovery per message and the least steady is broadcast. </span></p><p align="center"><span style="font-size:85%;"></span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP-623tKOjlurkhr2NCdi-fUimPADJr59YN7L0NJXTuL0KU22GcWevXBtBGliLjaI7-XWbN-X_dSYivHtbNIVk1jf7yyN79KdcTBZVr3MGQqWH_5JQ8SL57sUVXBkyxW4yVu3OkCxPZ-0/s1600-h/Boxplot+all+SD+stratetegies.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 253px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450128737763690770" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiP-623tKOjlurkhr2NCdi-fUimPADJr59YN7L0NJXTuL0KU22GcWevXBtBGliLjaI7-XWbN-X_dSYivHtbNIVk1jf7yyN79KdcTBZVr3MGQqWH_5JQ8SL57sUVXBkyxW4yVu3OkCxPZ-0/s400/Boxplot+all+SD+stratetegies.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Figure 19 Box plot of Broadcast, Exhaustive Search and TPS strategies<br /></p></span><p align="justify"><span style="font-size:85%;">So far what we have observed is that:<br />-Broadcast is faster than the other two strategies to discover new services<br />-Broadcast deprives the system from application traffic since the system is overwhelmed with discovery traffic.<br />- TPS more or less shares the application traffic and discovery traffic uniformly.<br />- TPS allows the system to run at a steady state due to the FIFO queue.<br />- ES allows more application traffic in the system and minimises discovery traffic.<br />On the grounds of our finding, we see that one service discovery strategy alone cannot conform to all requirements of the communication agreement models within a given distributed service model. At each phase of the communication life cycle a blended service discovery model is required as summarised in Table 1. </span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKzZARBVnLLV6aF0n1KOicGlXYUH1WCM2myfH2s5AYrHoBRe3iSJtyHjvBLQbQbUXs3vLf-C81TN9pMpq7NS4PskNBUsOTID1_Cnq8DZBZzwbZwXv1ZwZ00bA1OYNtjnxDuUevycHaoaE/s1600-h/Table+All+Conclusion.PNG"><span style="font-size:85%;"><img style="WIDTH: 400px; HEIGHT: 137px; CURSOR: hand" id="BLOGGER_PHOTO_ID_5450129388790628082" border="0" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKzZARBVnLLV6aF0n1KOicGlXYUH1WCM2myfH2s5AYrHoBRe3iSJtyHjvBLQbQbUXs3vLf-C81TN9pMpq7NS4PskNBUsOTID1_Cnq8DZBZzwbZwXv1ZwZ00bA1OYNtjnxDuUevycHaoaE/s400/Table+All+Conclusion.PNG" /></span></a></p><p align="center"><span style="font-size:85%;">Table 1 Observational Matrix of the Service Discovery Model </span></p><p align="justify"><span style="font-size:85%;"><strong>Conclusion<br /></strong>We demonstrated how different service discovery strategies work across distributed nodes and how they influence the choice of communication styles. The results of the experiments demonstrated that one service discovery strategy alone cannot provide full compliance to the overall system requirements. This means that at various stages of system life cycle enacting different workflows or business processes, different types of service discovery strategies have to be implemented in order to manage the nodes. To know which strategy to use, we have to look at the characteristics and CTQs which are essential for that particular communication agreement model. The example that was considered shows that to establish a cluster of nodes, one of the CTQs is performance and one of the characteristics is the occurrence of that process. In this case the observational results illustrate that the Broadcast strategy matches the criteria and should be implemented as far as performance is concerned. Moreover, we also showed that the Broadcast strategy overwhelms the network traffic and is not recommended during high volume of application traffic. Since establishing a cluster happens only once during the system life cycle, prior to any application traffic, the strategy conforms to the characteristic of the communication agreement model. We have shown that this type of knowledge and study can only be obtained through dynamic modelling techniques and indeed such knowledge has been acquired from the simulation of Testable Architecture.<br /><p></p><p align="justify"><span style="font-size:78%;">(Oxf03) Oxford University, “Oxford Dictionary of ENGLISH”, Oxford University Press, 2Rev Ed edition, August 2003<br />(Gutt99) Guttman E, Perkins C, Veizades J, Day M, “Service Location Protocol, Version 2”, IETF, 1999<br />(Arn99) Arnold K, Scheifler R, Waldo J, O'Sullivan B, Wollrath A, “Jini Specification”, Addison-Wesley Longman Publishing Co., 1999<br />(Mic99) Microsoft Corporation, “Universal Plug and Play: Background”, Microsoft Corporation, 1999(Mull85)<br />(Haa99) Haas Z J, Liang B, “Ad-Hoc Mobility Management with Randomized Database Groups”, in Proceedings of the IEEE International Conference on Communication, IEEE Computer Society, pp. 1756-1762, 1999<br />(li00) Li J, Jannotti J, Couto D S J D, Karger D R, Morris R, “A Scalable Location Service for Geographic Ad Hoc Routing”, in Proceedings of the 6th Annual International Conference on Mobile Computing and Networking, ACM Press, pp. 120-130, Boston, Massachusetts, USA, 2000<br />(Xue01) Xue Y, Li B, Nahrstedt K, “A Scalable Location Management Scheme in Mobile Ad-Hoc Networks”, in Proceedings of the 26th Annual IEEE Conference on Local Computer Networks: IEEE Computer Society, pp. 102-112, 2001<br />(Koz03) Kozat U C, Tassiulas L, “Network Layer Support for Service Discovery in Mobile Ad Hoc Networks”, in Proceedings of IEEE INFOCOM, vol. 23, IEEE Computer Society, pp. 1965-1975, 2003<br />(Herm00) Hermann R, Husemann D, Moser M, Nidd M, Rohner C, Schade A, “DEAPspace: Transient Ad-Hoc Networking of Pervasive Devices”, in Proc.of the 1st ACM International Symposium on Mobile Ad Hoc Networking & Computing, IEEE Press, pp. 133-134, Boston, Massachusetts, USA, 2000<br />(Chak02) Chakraborty D, Joshi A, Finin T, Yesha Y, “GSD: A Novel Group Based Service Discovery Protocol for MANETS”, in Proceedings of the 4th IEEE Conference on Mobile and Wireless Communications Networks,MWCN, IEEE Press, Stockholm, Sweden, 2002<br />(Hel02) Helal S, Desai N, Verma V, Lee C, “Konark: A Service Discovery and Delivery Protocol for Ad-hoc Networks”, in Proceedings of the 3rd IEEE Conference on Wireless Communication Networks WCNC, IEEE Press, New Orleans, USA:, 2002<br />(Zhu02) Zhu F, Mutka M, Ni L, “Classification of Service Discovery in Pervasive Computing Environments”, MSU-CSE-02-24, Michigan State University, 2002<br />(Cho05) Cho C, Lee D, “Survey of Service Discovery Architectures for Mobile Ad hoc Networks”, Mobile Computing, CEN 5531, Department of Computer and Information Science and Engineering, CICE, University of Florida, 2005<br />(Enge05) Engelstad P E, Zheng Y, “Evaluation of Service Discovery Architectures for Mobile Ad Hoc Networks, in Proceedings of the 2nd Annual Conference on Wireless On-demand Network Systems and Services, WONS, 2005<br />(Park07) Park H M, "Comparing Group Means: The T-test and One-way ANOVA Using Stata, SAS, and SPSS", Indiana University, 2007</span><br /><br /></p></span><p></p>Dr. Bippin Makoondhttp://www.blogger.com/profile/10489437598692319170noreply@blogger.com1tag:blogger.com,1999:blog-7848800761385484905.post-47102270604187509642009-12-18T02:10:00.047+00:002009-12-18T19:49:06.205+00:00Innovation Using TRIZ and Testable Architecture for the Formulation of a Broker Appointment System<span style="font-size:85%;"><strong><span style="font-size:100%;">Introduction </span></strong></span><br /><div align="center"><em><span style="font-size:78%;">“Two pints of London Pride please” asked the underwriter.<br />“Would you like to keep a tab behind the bar?” asked the bartender<br />The underwriter turned to the broker and enquired<br />“How many risks shall we be negotiating today Bruce?”<br />“Around 7 of them” replied the broker<br />“Then yes, please open a tab for me” said the underwriter to the bartender</span></em></div><span style="font-size:85%;"><br /><div align="justify">The London Insurance Market is a unique marketplace. For over 3 centuries, the relationship between broker and underwriter has transformed the London Insurance Market into one of the most dynamic and successful financial markets in the world. Whilst, it is traditionally a face-to-face business based within the area of the “City of London”, many of the participants have managed to achieve a global presence. Thus, this exclusive marketplace has continued to influence the global markets by being a major player by virtue of its efficiency and productivity.<br /><br />Brokers play a pivotal role in placing large volumes of business in hands of Insurers on a daily basis. As a result the meeting between broker and underwriter becomes fundamental to the Insurance business. Many technologies have been proposed to enhance the meetings of broker and underwriter. Nevertheless, most the value propositions focussed on the aspect of collaborative tools that enable broker to virtually meet with underwriter over the Internet. Yet brokers and underwriters are always willing to meet each other, face-to-face, following a long and successful tradition, and utterly dislike any interfering technologies. Many of the online collaborative tools have failed to deliver value to both brokers and underwriters.<br /><br />Unlike these traditional solutions, our business value proposition, which is the Mobile Broker Quest, is an innovative solution which does not attempt to act as a mediator in between the broker and the underwriter, but foster a catalyst to bring broker and underwriter together in a more efficient and prompt manner by focussing on the problem of broker appointment system.<br /></div><div align="justify"></div><div align="justify"><span style="font-size:100%;"><p><strong>Problem Statement</strong></p></span>Traditionally, insurance companies provision a trading floor, with an appointment system, used by the brokers to book meetings with underwriters. One of the observed limitations of the existing appointment system is that the full capability of the service is constrained by the need for the broker to be physically present in the office. The waiting time is only known when the broker logs into system. Very often, the queue tends to be very too long, resulting to brokers leaving to meet other insurers or clients. The broker may or may not come back to the underwriter. This usually leads to an unsatisfactory customer experience and loss of potential business.<br /><br />There is an apparent problem in the current broker appointment system at a major insurance group. When one profiles the statistics, it reports a drop of 60% in appointment booked since 2005. Brokers are not using the system anymore, since the solution does not offer the value they need. In identifying a process which is no longer supporting the goals of the underwriting process, this paper explains how an innovative solution, Mobile Broker Quest (MBQ), has been articulated and designed by merging two robust methods together, namely, The Theory of Inventive Problem Solving (TRIZ) [Kap96] and Testable Architecture (TA) [Tal04][Yang06] into a Blended Modelling Approach for innovation.</div><div align="justify"><p><strong><span style="font-size:100%;">Blended Modelling Approach<br /></span></strong></p>The rationale behind the blended modelling approach is primarily due to the nature of a typical innovation life cycle. The variations which exist in an innovation process require more flexibility than the constraints of the classical software development life cycle. According to Garlan and Shaw, in their analysis of advances in software engineering [Gar93] [Shaw01], there is a lack of scientific rigour within software engineering, wherein structural design alone cannot exhaustively define a software problem. Since the yield of a given research cannot be known and guaranteed upfront, the mindset of formulating, inventing and treating requirements has to shift from a deterministic to a probabilistic method to manage the variations.<br /><br />There are two acceptable attitudes of modelling, namely deductive modelling and inductive modelling [Oud02]. In the problem realm of deductive modelling, a model is an a priori representation of observed phenomena from reality wherein the process is to assume the model to be true upfront and the representation often becomes a structure which can be cloned or reproduced. These structures becomes moulds and knowledge from similar phenomenon observed in one’s problem domain can be “poured into these mould” which will lead to models of the problem definition. In the realm of inductive modelling, a model is an a posteriori representation of observed phenomena from reality and we understand that the reality and/or observation may change. Designers attempt to map the observations to a formal system so that these formalisms can be tested and simulated against the observations. Should the formal system be proven to be true, then a model exists, i.e. it has been induced, otherwise there is no existence of a model at this time.<br /><br />In order to manage the variations and unknowns of an innovation process model, we are required to use both the inductive and deductive modelling techniques. This potentially adds scientific rigour to remove ambiguity in requirements, resolve design defects, increasing the power of modelling. However to join both discipline requires a robust framework. Our proposed blended modelling approach merges the 2 attitudes of modelling together using a formal and mathematical framework called Testable Architecture [Tal09].<br /><p><strong>The Mind Model of the AS – IS Process</strong></p>We formulated a mind model by observing and learning from the customer problem domain. The point of focus was the trading floor at a global insurance group in London. Brokers need to be physically in the trading floor in order to enter the waiting line system by interacting with a touch screen interface, provisioning his/her credentials.</div><br /><br /><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOY9jcPuuLv3GsUj77ogW9uYSNgUi7wN7Pjuw-sPVJfcPTG3oA7ZC5pcv4wnvJLpzB7GRXAboN4ych29bkC8rIDCutmrTJUWYTqJS-O30K4DnqbjJgdAGR6EFwT50ftA7EIUKR3JF0OI0/s1600-h/AS+IS+Model+MBQ.PNG"><img id="BLOGGER_PHOTO_ID_5416396113430349554" style="WIDTH: 406px; CURSOR: hand; HEIGHT: 179px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOY9jcPuuLv3GsUj77ogW9uYSNgUi7wN7Pjuw-sPVJfcPTG3oA7ZC5pcv4wnvJLpzB7GRXAboN4ych29bkC8rIDCutmrTJUWYTqJS-O30K4DnqbjJgdAGR6EFwT50ftA7EIUKR3JF0OI0/s400/AS+IS+Model+MBQ.PNG" border="0" /></a><br /></p><br /><br /><div align="center"><a name="_Ref248740080"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">1 as -is Model of Broker Waiting Line System</span><br /></div><div align="justify"></div><div align="justify">The waiting time is known only after the appointment is booked in the queue and when the latter is too long; the broker may leave for other business. The may be a potential loss of business as Figure 1 depicts.</div><div align="justify"><p><strong><span style="font-size:100%;">Quality Modelling<br /></span></strong></p>As we probed the underwriters and brokers on the issue of quality, there is a clear gap between the SLAs and the capability of the as-is process. The quality model required for the appointment system is, on the one hand, underwriters want more appointments in one day and better time management for their meetings, and on the other hand, brokers, being always on the move, require the flexibility to book appointment anytime and anywhere. We employed the House of Quality [Yoji90] to model the quality attributes and refine them to measurable and controllable attributes, as depicted in Figure 2.</div><div align="justify"><span style="font-size:100%;"><p><strong>The House of Quality</strong></p></span></div><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQot5eKAV-MwmpeFxVAGbR89CV0K3twzs9vm0NVkXO6vl0yDRiMxOj3h4El0URv35NEBqEzEyEI-4K6LvNAbz48nMf0WFzMtv568-J15_cTFiK9yVG2KyDgnbk_vlYuwhMayLPigiqYIY/s1600-h/HoQ.PNG"><img id="BLOGGER_PHOTO_ID_5416397719983247906" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 317px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQot5eKAV-MwmpeFxVAGbR89CV0K3twzs9vm0NVkXO6vl0yDRiMxOj3h4El0URv35NEBqEzEyEI-4K6LvNAbz48nMf0WFzMtv568-J15_cTFiK9yVG2KyDgnbk_vlYuwhMayLPigiqYIY/s400/HoQ.PNG" border="0" /></a><br /></p><br /><br /><div align="center"><a name="_Ref248745891"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">2 House of Quality of Broker Quest SLAs</span><br /></div><br /><br /><div align="justify">We are left with two fundamental conflicting quality attributes, the ad-hocness of broker appointment requests, and the need for better time management from underwriter. In coupling the flaws of the AS-IS model with the conflicting quality attributes, we now apply a technique called TRIZ to guide the process of inventive problem solving.</div><div align="justify"></div><div align="justify"><span style="font-size:100%;"><p><strong>The Implementation of the Theory of Inventive Problem Solving (TRIZ)</strong></p></span>TRIZ is interdisciplinary and closely related to logic, psychology, history of technology and philosophy of science. The two basic principles in TRIZ 1) “Somebody, someplace, has already solved your problem or one similar to it. Creativity means finding that solution and adapting it to the current problem;” and 2) “Don't accept compromises. Eliminate them”. The main concept applied by Altshuller, the inventor of TRIZ, in developing the 40 principles is that contradictions (or trade-offs) are the constraints that inventions seek to resolve. Inventive solutions do not seek equilibrium along the trade-off, but “dissolve” the contradiction. Inventions are intended to solve problems which are fundamentally “the difference between what we have and what we want” (De Bono). The problems in turn are derived from contradictions. Any invention is therefore intended to “resolve” or “dissolve” these contradiction. From these premises Altshuller developed the 40 principles and the “Matrix of Contradictions”, see Figure 3. </div><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjFgEhgZUvdQcCrioe9O4DyPsPNODtVZTDP3amC-qGF_8UBCc9LqU6UVmtMy7_5L-v9AYckt3b9aQ8K8nwMk4VfkoTUyuoiPfjfGqg-IeHXdWLqdXnUp49YU1vGly2vy8jlwMn70LtzrU/s1600-h/TRIZ+MBQ.PNG"><img id="BLOGGER_PHOTO_ID_5416399004056764482" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 264px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjFgEhgZUvdQcCrioe9O4DyPsPNODtVZTDP3amC-qGF_8UBCc9LqU6UVmtMy7_5L-v9AYckt3b9aQ8K8nwMk4VfkoTUyuoiPfjfGqg-IeHXdWLqdXnUp49YU1vGly2vy8jlwMn70LtzrU/s400/TRIZ+MBQ.PNG" border="0" /></a><br /></p><div align="center"><a name="_Ref248748652"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">3 The TRIZ Matrix of Contradictions<br /></span><br /></div><div align="justify">Within the problem domain of the Broker appointment system, we started by identifying the two core contradictions in the Broker and Underwriter relationship: 1) there is the need for the ad- hoc style of meeting from the brokers which is natural to their operation and they need the ease of operation to run their daily business while 2) there is the need for a better time management method from the underwriters to reduce the loss of time of an inefficient and uneconomical waiting line. In applying the TRIZ matrix, the following principles to solve these contradictions: Improving <25> Loss of Time without damaging <33> Ease of operation. As we traverse the matrix, Figure 3, we discover four principles which are defined as follows:<br /></div><div align="justify"><4>Asymmetry means to change the shape of an object from symmetrical to asymmetrical and if an object is asymmetrical, then increase its degree of asymmetry.<br /></div><div align="justify"><28> Mechanics substitution means to change from a static field to movable fields, i.e. to add another Sense to the solution.<br /></div><div align="justify"><10> Preliminary action or Prior Action means to pre-arrange objects such that they come into action from the most convenient place and without losing time for their delivery.<br /></div><div align="justify"><34> Discarding and recovering means to apply solution into the flexibility of transactions.<br />As observed, TRIZ does not provide the breakthrough idea, but spells out the principles to guide designers / innovators in catalysing the process of idea generation, i.e. the seed idea.<br /></div><div align="justify"><strong><span style="font-size:100%;"></span></strong></div><div align="justify"><p><strong><span style="font-size:100%;">The Seed Idea</span></strong></p>In translating the principles as prescribed by TRIZ, designed natively for the manufacturing domain, into the problematic of business process and software enablement, the following principles guides us to produce the seed idea. The latter comes from a mixture of understanding the pain points, potential enhancements of business processes creativity and the dissolution of contradictions. There is no process for creativity but there are indicators that can help to build an environment that fosters and directs creativity. The translation process harvested the following:<br /></div><div align="justify"><4>Asymmetry means to change the symmetricity of the transactions into an asymmetric model, which indicate that the underwriter side of the appointment process has to be asymmetric to the broker side of the appointment process. This is an essential guiding principle as traditionally in software engineering, one tends to design solution that are structurally similar throughout the solution to improve manageability and reuse of solution components.<br /></div><div align="justify"><28> Mechanics substitution means to change from static field to movable fields. The principle indicates the addition of another sense or channel to resolve the contradictions. The aspect of movable fields can be linked to the aspect of location and mobility, to the problem, that is the substitution of a static location for a dynamic one. In adding the aspect of mobility to the appointment system, leads us to look at the very common Mobile Technology.<br /></div><div align="justify"><10> Preliminary action <prior>means to gather and prepare all the relevant documents required for underwriting the risk in advance and allowing the system to place them in the order required during the course of the meeting. These documents can also be pre provisioned with all known information such as date, broker details, underwriter details etc. which saves time during the meeting. This given principle reduces the duration of a meeting, hence creating more space in the waiting line to accommodate the ad-hocness of broker’s requests. Incorporating such feature dissolves the contradictions of time management i.e. reduce loss of time and ease of operation.<br /></div><div align="justify"><34> Discarding and recovering <thin>means that the broker appointment system should be thin <easy>and flexible to use with fewer click and screens to complete a booking transaction. The principle also indicates that the underwriter should also provide the flexibility to delegate a meeting request amongst his/her peers. Hence, the seed idea can be formulated around the method and technology of 1) Mobile Technology; 2) Pre-provisioned, Positioned and Attach relevant documentation within appointment request, 3) Flexibility in changing appointment variables, e.g. Time and delegation of appointment amongst underwriters and 4)User Friendly Interface.<br /><p><strong><span style="font-size:100%;"></span></strong></p></div><div align="justify"><strong><span style="font-size:100%;">Requirement Invention<br /></span></strong><p></p>The seed idea is evaluated and rationalized in order to invent the user requirements of the solution. The process of translating the seed idea into requirement consist of fact-finding, identifying constraints as well as expanding information. This involves the analysis of the as-is model (see Figure 1) to understand the problem by delineating and refining constraints. Classically, in the problematic of software engineering, requirements are classified into two classes which are functional and non functional requirement [Boeh76]. However, it has been argued that user requirements have to be classified into their distinct styles which are more profound than the conventional two classes. The process of classification will provide the directives to which type of modelling tools, including inductive modelling tools, should be employed to the different styles of requirement. This is typically to address the approach of blended modelling which is supported by Testable Architecture. Typically, there are four types of the requirement styles which are 1) the data style, 2) the functional and logical style, 3) the communication and behavioural style and 4) the quality styles. </div><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhU9QjhoKEu3GaOeLdFx1Bi2S7WJ0ZNB53hKdYTiD21c27Xx0OrVmQFZmBMQIu9TQwX5BuB_oisFQHRmPc2u0euSf5wifb8SetvGBvMd7SbKfDksaScrhrDNQentGWG5yeLUR_i1ZuC0CE/s1600-h/REQ+CLASS+Table.PNG"><img id="BLOGGER_PHOTO_ID_5416400147027418722" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 161px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhU9QjhoKEu3GaOeLdFx1Bi2S7WJ0ZNB53hKdYTiD21c27Xx0OrVmQFZmBMQIu9TQwX5BuB_oisFQHRmPc2u0euSf5wifb8SetvGBvMd7SbKfDksaScrhrDNQentGWG5yeLUR_i1ZuC0CE/s400/REQ+CLASS+Table.PNG" border="0" /></a><br /><a name="_Ref248820353"><span style="font-size:78%;">Table </span></a><span style="font-size:78%;">1 Understanding the character of requirement<br /></span></p><div align="justify"><p><strong><span style="font-size:100%;">The TO – BE MODEL of the Mobile Broker Quest</span></p></div></strong><p></p><div align="justify">We have formulated a series of high level requirements to how the Mobile Broker Quest will be operated leading to the design of the TO-BE process model (see Figure 4 ) designed to enhance the appointment system in conforming to the quality model or SLAs in Figure 2.</span></div><p align="center"><span style="font-size:85%;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTMKJ_ZEzMCDU7gfH7hhydGDq7WtsRmODx3gKJhtPuFKroruGgWTKruCwDMz40gBoebmyx2537RxIVVcaYHihWV7_ZmH1c03uewvvowD6mRrY9Z8h5kB-294t3tiyJwAD3-EEPvMVrhm0/s1600-h/TO+BE+Model+MBQ.PNG"><img id="BLOGGER_PHOTO_ID_5416400788593935778" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 179px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTMKJ_ZEzMCDU7gfH7hhydGDq7WtsRmODx3gKJhtPuFKroruGgWTKruCwDMz40gBoebmyx2537RxIVVcaYHihWV7_ZmH1c03uewvvowD6mRrY9Z8h5kB-294t3tiyJwAD3-EEPvMVrhm0/s400/TO+BE+Model+MBQ.PNG" border="0" /></a></span></p><p align="center"><a name="_Ref248825751"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">4 To- Be model of the Mobile Broker Quest</span></p><span style="font-size:85%;"><div align="justify">The to-be process model is in its static form, and we can experience some optimization feature in the reduction of the number of clicks required from the broker to provision the system when compared to the as-is model. Yet, in order to profoundly understand if the proposed model conforms to the SLAs and to maximise the probability of containing design defects, the static model has to be translated into a dynamic and formal model and this leads to the application of Testable Architecture.<br /><span style="font-size:100%;"></span></div><div align="justify"><span style="font-size:100%;"><p><strong>The Application of Testable Architecture</strong></p></span>A dynamic model is based on formal methods, subsequently enabling designer to type check and simulate the proposed model against the refined requirements and the quality model. This part of the modelling discipline is inductive and primarily it allows design and requirement defects to be found and fixed prior to coding. Testable Architecture (TA) is the core engine of the innovation process model and key to the success of the proposed idea, i.e. the Mobile Broker Quest. TA is a methodology that abstracts the complexity of formal methods, pi calculus [Miln80a] [Miln80b] [Miln93], Petri nets [Pet62] and Z Notation to provide a “run time simulation engine” and type check compiler to dynamic models. It fundamentally has the capability of blending structural modelling with inductive modelling, acting as a compiler to design and models. As we journey through the process of building a dynamic representation of the requirement that describe the phenomenon of two participants booking appointments, we are able to exercise the dynamic model to verify and validate against two key question: 1) Is the model representing the right thing?; and 2) Is the model representing the thing right?<br /></div><div align="justify"></div><div align="justify">In Figure 6, we illustrated the Coloured Petri Net Model of the to-be process highlighting the dynamics of the waiting line for Brokers. We exploited the simulation engine of CPN to assess the model against the quality attributes (see Figure 2) and constraints, to validate if the proposed model conforms to the business values and goals.Coloured Petri Net [Jeff91] is a modelling technique to model parallel behaviour and high-level programming languages to define data, functions, and computation on data. The process model is represented by token exchange between different parts of the Petri Net wherein places are connected to transitions via arcs. Tokens are inserted or removed from places, which carry, as a timestamp, the deterministic or randomly distributed temporal length of the transition they enable. </div><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk-faGOipN72Yy7XkFYbJ1fKfvP7j3h-N9PwSxZAZx1vNG_FSzXtw61flACf7XKGcs25bTEWbvpCQOr7ObzvxLNeKgCCQ5K36jIp2NXmxC6lX2Xvfg_NmzqoroVbeZ5pQj-lMBdSA_7nk/s1600-h/CPN+META+Model.PNG"><img id="BLOGGER_PHOTO_ID_5416401690897865474" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 204px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk-faGOipN72Yy7XkFYbJ1fKfvP7j3h-N9PwSxZAZx1vNG_FSzXtw61flACf7XKGcs25bTEWbvpCQOr7ObzvxLNeKgCCQ5K36jIp2NXmxC6lX2Xvfg_NmzqoroVbeZ5pQj-lMBdSA_7nk/s400/CPN+META+Model.PNG" border="0" /></a><br /><br /><span style="font-size:78%;">Figure 5 The Meta Model of the Mechanics of CPN<br /></p></span><p align="justify"><strong><span style="font-size:100%;">Formal and Dynamic Modelling</span></strong></p><div align="justify">In Figure 6, we illustrate a Petri Net model of a waiting line component of the Broker appointment systems. We employ Petri Net to model the queue wherein simulation processes are performed to understand how the queues work under different condition, e.g. an increase in appointment request and continuously check against conformance. In order to emulate the dynamics of the waiting we use some of the historical data of the existing broker quest system and couple the statistics with some probabilistic model. Based on the empirical research of the queuing theory, we assigned the following distribution behind the CPN model for simulation 1) the arrival rate follows a Poisson distribution, 2) the buffering rate of the queue follows a normal distribution and the processing time of servers follows an Exponential distribution and the waiting line follows a FIFO structure.</div><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5sZrYY8shjrZJeay7seHkbj09pZii_oOpufZkLha2wYGitZCvUEFLH6T_BoayzdbSG-thfCRbCBH_qmJ6fzzUpidnGqqCw3xNw4lrdBDcG_ChX5DabbLdRPRsAhPqaKeCKbJ09Y1JFT8/s1600-h/CPN+Model+of+Broker+Waiting+Line.PNG"><img id="BLOGGER_PHOTO_ID_5416403460669312882" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 244px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5sZrYY8shjrZJeay7seHkbj09pZii_oOpufZkLha2wYGitZCvUEFLH6T_BoayzdbSG-thfCRbCBH_qmJ6fzzUpidnGqqCw3xNw4lrdBDcG_ChX5DabbLdRPRsAhPqaKeCKbJ09Y1JFT8/s400/CPN+Model+of+Broker+Waiting+Line.PNG" border="0" /></a></p><p align="center"><a name="_Ref248827558"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">6 CPN Model of the Waiting Line</span> </p><p align="justify"><span style="font-size:100%;"><p><strong>Observations</strong></p><div align="justify"></span>Consider Figure 7, where given a burst of 1 appointment request per 10 minutes to 1 appointment request per 3 minutes, the graph shows the gap between the input rate against the output rate. It justifies that the close proximity between the input and output rate shows that the service rate of the Queue System is adequately lower than the input rate. The two graphs differentiate the latency added to the queue system. </div><p></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTz1_OOQTimusRR5RD2guKNUOZOJnArWGo7_bJotY1eCAQRTNcJ8TYA_gWVOBdiLYqpIoDil4642-4dwdIzTQkrTlrzXfQFNYN-aLM685n-Co2Rn99IUadKB0AJoOlwxybO9_WwaypcA0/s1600-h/Graph+1+MBQ.PNG"><img id="BLOGGER_PHOTO_ID_5416404901479856674" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 146px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTz1_OOQTimusRR5RD2guKNUOZOJnArWGo7_bJotY1eCAQRTNcJ8TYA_gWVOBdiLYqpIoDil4642-4dwdIzTQkrTlrzXfQFNYN-aLM685n-Co2Rn99IUadKB0AJoOlwxybO9_WwaypcA0/s400/Graph+1+MBQ.PNG" border="0" /></a><br /><a name="_Ref248830469"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">7 Waiting Line Dynamics of Mobile Broker Quest</span></p><p align="justify">In Figure 8, the graph reports on the time taken for a large sample of appointment requests to leave the system. The objective is to estimate the number of brokers waiting for more than n minutes (where n is defined by the SLA) that exist given an input burst. The graph shows the period of time a number of brokers take to meet an underwriter, e.g. over hundred appointment requests, a broker take 12 minutes. Hence using such analysis, a threshold can be established to identify those brokers that have a probability of waiting for too long. </p><p align="center"><img id="BLOGGER_PHOTO_ID_5416405345362849410" style="WIDTH: 219px; CURSOR: hand; HEIGHT: 164px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6cz09Rc4g-VTR0psderYsVVz3B7B2zrzJc3G6adOwDi6FZOlGuVFxbBD5NxrzwIOLjQlERmFS9PgBhxq15I6_-q5FEZwEqlNEkAX6ZRm8nQUc85safnGYC2RljfneaR04Lf0JuTqWn4A/s400/Graph+2+MBQ.PNG" border="0" /></p><p align="center"><a name="_Ref248830797"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">8 Waiting Time of Broker<br /></p></span><p align="justify">In order to reduce the number of variables in the experiments, we employed the Taguchi Method of Design of Experiment (DoE), used to determine the relationship between the different factors (Xs) affecting a process and the output of that process (Y). In the defined quality model we are seeking the fundamental SLAs of the MBQ which is to increase the number of appointments in a day to increase revenue in new business. So the function exercised into DoE is as follows:</p><p align="center"><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyuNrYzyRjBIUbYxX5p8VE3D4sIq8zHybs7xiE1Fk0F6RSWuWY7VwgXUpzmQsktdcTjm6oMJpu2SPBMiW9TenE00_yM-n9qkFUazlkT75at3mKqFUCB4N0Gdl66SCj-ltuhbBKDbJLG90/s1600-h/Formula+perf.PNG"><img id="BLOGGER_PHOTO_ID_5416407037949876770" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 36px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyuNrYzyRjBIUbYxX5p8VE3D4sIq8zHybs7xiE1Fk0F6RSWuWY7VwgXUpzmQsktdcTjm6oMJpu2SPBMiW9TenE00_yM-n9qkFUazlkT75at3mKqFUCB4N0Gdl66SCj-ltuhbBKDbJLG90/s400/Formula+perf.PNG" border="0" /></a></p><div align="justify">DoE establishes the most important Xs, of the function to reduce the number of simulations against the SLAs.The iterative process of simulating the dynamic model (see Figure 9) leads to the reinforcement and refinement of the requirements and containment of design defects [Boeh76]. The refined requirements are validated and transformed into formal specifications that are given to the designer of the solution architect.The iterative process of simulating the dynamic model (see Figure 9) leads to the reinforcement and refinement of the requirements and containment of design defects [Boeh76]. The refined requirements are validated and transformed into formal specifications that are given to the designer of the solution architect.<br /></div><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0OcxMiJSWZeH12vxlYEaKDsiiyVUOTDfjetoCODfh37QMge0t1pUJ1MCV6nsmj4nSKkg-fA9k10tredcmjHJap7moD0L7TKpjBQz0GMXQR3w0P45uvJ9b2HoiQOFBPDg3Pv0QEib0mvk/s1600-h/Iterative+Process+of+Req+Refinement.PNG"><img id="BLOGGER_PHOTO_ID_5416407882562028610" style="WIDTH: 312px; CURSOR: hand; HEIGHT: 143px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0OcxMiJSWZeH12vxlYEaKDsiiyVUOTDfjetoCODfh37QMge0t1pUJ1MCV6nsmj4nSKkg-fA9k10tredcmjHJap7moD0L7TKpjBQz0GMXQR3w0P45uvJ9b2HoiQOFBPDg3Pv0QEib0mvk/s400/Iterative+Process+of+Req+Refinement.PNG" border="0" /></a></p><div align="center"><a name="_Ref248833188"><span style="font-size:78%;">Figure </span></a><span style="font-size:78%;">9 Iterative Refinement of Requirement<br /></div></span><br /><br /><span style="font-size:100%;"><p align="justify"><strong>The Solution Architecture</strong></p><div align="justify"></span>The architecture lays the foundation for analytical optimization of function, cost, quality and performance by gaining understanding of: 1) how the system and the system elements function ideally; 2) understanding of the interfaces and their interactions and 3) the understanding of behaviours influenced by the interactions as formalized by Testable Architecture. The process of modelling the latter can only be formally understood by exercising Testable Architecture.<br /><br />As the solution architecture is formulated, the continuity of the innovation life cycle follows the path of the classical Software Development Life Cycle for coding and testing which ideally fits into the constraints of the Spiral Model.<br /></div><span style="font-size:100%;"><p align="justify"><strong>Conclusion</strong></p><div align="justify"></span>MBQ yields to an improved time management strategy, increasing the number of brokers an underwriter can meet. It fundamentally addresses the problem of customer intimacy and customer satisfaction as broker may plan their day in advance. The capability of MBQ enables the insurer to maximise the probability of winning of potential business by reducing the number of broker walkouts. In the journey towards the MBQ, we have demonstrated the application of TRIZ to successfully provide the principles required to enhance the process of seed idea generation. Those principles force us to think laterally which ensures that key attributes of a solution are not missed as they are very often during solution envisioning exercise. We also observed that Innovation endeavours carry several facets of the unknowns and variations that require inductive models to test their viability at the early stages of requirements. Hence, we proposed a blended modelling approach, founded on the discipline of Testable Architecture to apply simulation and validation to the proposed model of the broker appointment system. </div><div align="justify"><span style="font-size:100%;"><p><strong>Reference</strong></p></span><br /><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;">[Boeh76] Boehm B W, “Software Engineering”, IEEE Trans. Computers, pp. 1,226 - 1,241, December 1976 </span></div><div align="justify"><span style="font-size:78%;"><br />[Gar93] Garlan D, Shaw M, “An Introduction to Software Architecture, in Advances in Software Engineering and Knowledge Engineering” Vol 1, ed. Ambriola and Tortora World scientific Publishing Co., 1993<br /></span></div><div align="justify"><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;"><br />[Jeff91] Jeffrey J M, “Using Petri nets to introduce operating system concepts”, Paper presented at the SIGCSE Technical Symposium on Computer Science Education, San Antonio, USA, 7-8 March 1991<br /></div></span><div align="justify"><span style="font-size:78%;"><br />[Kap96] Kaplan S, “An Introduction to TRIZ – The Russian Theory of Invention Problem Solving”, Ideation Intl Inc, 1996<br /></span></div><div align="justify"><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;"><br />[Miln80a] Milner R, “A Calculus of Communicating Systems”, Lecture Notes in Computer Science, volume 92, Springer-Verlag, 1980<br /></div></span><div align="justify"><span style="font-size:78%;"><br />[Miln80b] Milner R, “A Calculus of Communicating Systems”, Lecture Notes in Computer Science, volume 92, Springer-Verlag, 1980<br /></span></div><div align="justify"><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;"><br />[Miln93] Milner R, “The Polyadic pi-Calculus: A Tutorial”, L. Hamer, W. Brauer and H. Schwichtenberg, editors, Logic and Algebra of Specification, Springer-Verlag, 1993<br /></div></span><div align="justify"><span style="font-size:78%;"><br />[Oud02] Oudrhiri R, “Une approche de l’évolution des systèmes,- application aux systèmes d’information”, ed.Vuibert, 2002<br /></span></div><div align="justify"><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;"><br />[Pet62] Petri C A, "Kommunikation mit Automaten", PhD thesis, Institut f¨ur instrumentelle Mathematik, Bonn, 1962<br /></div></span><div align="justify"><span style="font-size:78%;"><br />[Shaw01] Shaw M, “The coming-of-age of software architecture research”, in Proceedings of ICSE, pp. 656–664, Carnegie Mellon University, 2001<br /></span></div><div align="justify"><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;"><br />[Tal04] Ross–Talbot S, “Web Service Choreography and Process Algebra”, W3C Consortium, 2004<br /></div></span><div align="justify"><span style="font-size:78%;"><br />[Tal09] Ross-Talbot S, “</span><a name="seminar-12"><span style="font-size:78%;">Savara - from Art to Engineering: It’s all in the description</span></a><span style="font-size:78%;">”, University of Leicester, Computer Science Seminar, 2009<br /></span></div><div align="justify"><span style="font-size:78%;"></span></div><div align="justify"><span style="font-size:78%;"><br />[Yang06] Yang H et al, “Type Checking Choreography Description Language”, Lecture Notes in Computer Science Springer-Berlin / Heidelberg, Peking University, 2006<br /></div></span><div align="justify"><span style="font-size:78%;"><br />[Yoji90] Akao Y, “Quality Function Deployment: Integrating Customer Requirements into Product Design” (Translated by Glenn H. Mazur), Productivity Press, 1990 </span></div></span>Dr. Bippin Makoondhttp://www.blogger.com/profile/10489437598692319170noreply@blogger.com3tag:blogger.com,1999:blog-7848800761385484905.post-58148362924083771622009-09-26T00:01:00.029+01:002009-09-26T17:22:43.303+01:00Testable Architecture: The Device to Craft Complex Communicating Systems<div align="justify"><span style="font-size:85%;"><span style="color:#333333;"><u><strong>Introduction</strong> </u><br />It is very often argued that Software Engineering within distributed system is an engineering of complex system. According to Gödel incompleteness theorem, a complex system can be defined as one that can only be modelled by an infinite number of modelling tools (Chai71). The development of distributed systems in domains like telecommunications, industrial control, supply-chain and business process management represents one of the most complex construction tasks undertaken by software engineers (Jenn01) and the complexity is not accidental but it is an innate property of large systems (Sim96). </span></span><br /></div><div align="justify"><span style="font-size:85%;color:#333333;"></span></div><div align="justify"><span style="color:#333333;"><span style="font-size:85%;"></span></span></div><div align="justify"><span style="color:#333333;"><span style="font-size:85%;">In distributed systems we observe emergent behaviour since logical operations may require communicating and multi channel interactions with numerous nodes and sending hundreds of messages in parallel. Distributed behaviour is also more varied, because the placement and order of events can differ from one operation to the next. Modelling the interactions of distributed system is not straight forward and inherently demands a multi-disciplinary approach and a change in traditional mindset to be resolved.</span><br /></div></span><span style="font-size:85%;"><span style="color:#333333;"><strong><u></u></strong></span></span><div align="justify"><span style="font-size:85%;"><span style="color:#333333;"><strong><u></u></strong></span></span></div><div align="justify"><span style="font-size:85%;"><span style="color:#333333;"><strong><u>A Multi-disciplinary Class of Problems<br /></u></strong>The class of problems of modelling distributed systems is multidisciplinary, suggesting that there are several ways of modelling the problems attributes and we were required to combine several of these approaches and models, as Figure 1 shows: </span></span></div><div align="center"><span style="font-size:85%;color:#333333;"><img id="BLOGGER_PHOTO_ID_5385544889661673410" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 320px; CURSOR: hand; HEIGHT: 212px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUfuFonxHmXi6nLjG-dzSB5GXjKcfX0_0DgKDOEp8IwrXxvbN3TUHh_oJFqWkAkjGsZOxsewel_Z7ACDkCtUg4PBx3-Rd_5cb7VQvJYQoZDqx3xxA6CcxeR8Z_GcAset7Ihustaj2Rk54/s320/TA1.PNG" border="0" /></span><a name="_Ref181605069"><span style="font-size:85%;color:#333333;">Figure </span></a><span style="font-size:85%;color:#333333;">1 Multi-disciplinarism in Modelling </span></div><div align="center"><span style="font-size:85%;color:#333333;"></span><br /></div><div align="justify"><span style="font-size:85%;color:#333333;">Arguably, there are two types of modelling approaches, inductive and deductive, within the field of software engineering. </span></div><ul><li><div align="justify"><span style="font-size:85%;color:#333333;">Deductive Modelling includes the aspect of structural, functional and collaborative designs and is commonly used in classical software engineering, such as Class Diagrams, Sequence Diagrams, Object Diagrams, Entity Relationship Diagrams (ERD), Data Flow Diagrams (DFD), Flow Charts, Use Cases, etc… </span></div></li><li><div align="justify"><span style="font-size:85%;color:#333333;">Inductive Modelling, are critical dynamic modelling techniques that primarily characterise the aspect of non-determinism within a system mainly arising from the occurrence of emergent behaviour and interactions. Commonly used techniques are formal methods (e.g. Testable Architecture), simulations and probabilistic models of the software artefact. </span></div></li></ul><p align="justify"><u><span style="color:#333333;">M</span></u><a name="_Toc191573023"><strong><span style="font-size:85%;color:#333333;"><u>odelling Concepts and Techniques</u></span></strong></a><span style="font-size:85%;"><span style="color:#333333;"><br />Unlike many engineering fields, software engineering is a particular discipline where the work is mostly done on models and rarely on real tangible objects (Oud02). According to Shaw, (Shaw90), Software engineering is not yet a true engineering discipline but it has the potential to become one. However, the fact that software engineers’ work mainly with models and a certain limited perception of reality, Shaw believes that the success in software engineering lies in the solid interaction between science and engineering. </span></span></p><p align="justify"><span style="font-size:85%;color:#333333;">In 1976, Barry Boehm (Boeh76) proposed the definition of the term Software Engineering as the practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them. This definition is consistent with traditional definitions of engineering, although Boehm noted the shortage of scientific knowledge to apply.</span></p><p align="justify"><span style="font-size:85%;color:#333333;">On one hand, science brings the discipline and practice of experiments, i.e. the ability to observe a phenomenon in the real world, build a model of the phenomenon, exercise (simulate or prototype) the model and induce facts about the phenomenon by checking if the model behaves in a similar way to the phenomenon. In this situation, the specifications of the phenomenon might not be known upfront but induced after the knowledge about the phenomenon is gathered from the model. These specifications or requirement are known a posteriori.</span></p><p align="justify"><span style="font-size:85%;color:#333333;">On the other hand, engineering is steered towards observing a phenomenon in reality, deducing facts about the phenomenon, build concrete blocks; structures (moulds) or clones based on the deduced facts and reuse these moulds to build a system that mimics the phenomenon in reality. In this situation, the specifications of the phenomenon are known upfront, i.e. deduced before even constructing any models, whilst observing the phenomenon. The process of specifying facts about the phenomenon is rarely a learning process, and requirements are known a priori. </span></p><p align="justify"><span style="font-size:85%;"><span style="color:#333333;">The scientific approach is based on inductive modelling and the engineering approach is based on deductive modelling. Usually in software engineering we are very familiar with the deductive modelling approach, exploiting modelling paradigm such as UML, ERD, and DFD that are well established in the field. However, the uses of inductive modelling techniques are less familiar in business critical software engineering, but applied extensively in safety critical software engineering and academia. Typically, inductive modelling techniques are experiments carried out on prototypes, or simulation of dynamic models which are based on mathematical (formal methods), statistical and probabilistic models. The quality of the final product lies in the modelling power and the techniques used to express the problem. As mentioned earlier, we believe that the power of the modelling lies in the blending of the inductive and deductive modelling techniques. </span></span></p><p align="justify"><span style="font-size:85%;"><span style="color:#333333;">The rationale of integrating inductive modelling techniques within the domain of our study is due to the elements of non-determinism, emergent behaviours, communicational dynamics which are those parts of the problem that cannot be known or abstracted upfront i.e. a priori. These elements differs from those parts of the problem that can be abstracted from a priori based on experience and domain knowledge, which are normally deduced and translated into structures or models (moulds) i.e. using deductive modelling techniques.</span></span></p><p align="justify"><span style="font-size:85%;color:#333333;">Inductive modelling techniques require a different approach of addressing the problem attributes. In these circumstances, we tend to believe that the requirements are false upfront, and the objective is to validate these requirements against predefined quality attributes. To do so, we build formal models (formal methods) to mimic the functionalities of the suggested requirements and run the models (dynamically) to check if the models conform to the expected output and agreed quality. The modelling tools are dynamic in nature, and very often they offer themselves very easily to simulation engines and formal tests that allow system designers to run and exercise the designs, to perform model validation and verification. Through several simulation runs, the models are modified, adjusted and reinforce until they match, to certain level of confidence, the quality attributes. </span></p><p align="justify"><span style="font-size:85%;color:#333333;"><strong><u>Testable Architecture as a Blended Modelling Approach</u></strong><br />For many years, computer scientists have tried to unify both types modelling techniques in order to capture the several facets of the distributed communication systems and demonstrate the power of modelling to develop software artefacts of high quality. </span></p><div align="justify"><span style="color:#333333;"><span style="font-size:85%;">The development of distributed messaging system is a complex activity with a large number of quality factors involved in defining success. Despite the fact that inductive modelling is scientifically thorough for analysing and building quality engineered systems, it brings additional cost into the development life cycle. Hence, a development process should be able to blend inductive and deductive modelling techniques, to adjust the equilibrium between cost (time resource) and quality. As a result, the field of software process simulation has received substantial attention over the last twenty years. The aims have been to better understand the software development process and to mitigate the problems that continue to occur in the software industry which require a process modelling framework. </span></span></div><div align="justify"><span style="color:#333333;"></div></span><div align="justify"><span style="font-size:85%;"><span style="color:#333333;">When it comes to modelling the interaction and communication of Distributed System, Choreography Description Language (CDL) is one of the most efficient and robust tool. CDL forms part of Testable Architecture, hereafter TA, and is based on pi calculus (Miln99), which is a formal language to define the act communicating.<br /></div></span></span><span style="font-size:85%;"><span style="color:#333333;"></span></span><div align="justify"><span style="font-size:85%;"><span style="color:#333333;"></span></span></div><div align="justify"><span style="font-size:85%;"><span style="color:#333333;">Many other formal methods exist such as B Methods, Z Notations and lambda calculus that are used to unambiguously describe software requirements. However when it comes to describing distributed interactions of several participants, they fail, since they were not design to do so. Lambda calculus was designed for parametric description of passing arguments across functions; Z Notation was designed to classify and group attributes of the problem domain into logical sets; and B Methods was designed to describe requirement into logical and consistent machines. Pi calculus is a formal language that uses to concept of channels and naming to describe interactions and fits very well in the problem domain of distributed systems.<br />Unlike other modelling frameworks, TA is not limited to deductive and static modelling techniques, as it uses pi calculus based on non-deterministic models, that are well known within the academic world, but not yet of a common use within industry. In fact TA acts as a natural “glue” to blend the various modelling approaches providing a framework with the primary objective of removing the characteristic of ad-hocness and ambiguity within the modelling Process.<br /></div></span></span><div align="justify"><span style="font-size:85%;"><span style="color:#333333;">Using TA, the formal description of the requirements can be translated into different types of modelling tools starting with dynamic modelling tools (inductive modelling) such as Coloured Petri Nets (CPN) and prototyping, then moving to event based modelling tools such as State Chart Diagrams and Sequence diagrams and finishing with structural modelling tools (deductive modelling) such as class diagrams. Throughout the translation process, the specifications and requirements can be tested, validated and reinforce.<br /></div></span></span><div align="justify"><br /><span style="font-size:85%;"><span style="color:#333333;"><strong><u>Case Study: Testable Architecture used in Large Communication Model of Business Critical Systems<br /></u></strong>In the case study, we focus on the fundamental problem of underwriting within a global insurance group, which includes the characteristics of Underwriting Workflow System, Policy Manager, Document Management System and the Integration Layer.<br /></div></span></span><div align="justify"><br /><span style="font-size:85%;color:#333333;">We demonstrate how TA is used to reinforce the power of modelling by avoiding classical modelling pitfalls, defining traceability across the lifecycle, providing a reference model through iterations, and addressing defects at early stage, hence increasing the maturity of the process model. </span></div><div align="justify"><br /><span style="font-size:85%;color:#333333;">As we mentioned earlier, the design approach employs both the deductive and inductive modelling techniques, and TA employs a formal method, Pi Calculus, that provides the ability to test a given architecture, which is an unambiguous formal description of a set of components and their ordered interactions coupled with constraints on their implementation and behaviour. Such a description may be reasoned over to ensure consistency and correctness against requirements. </span></div><div align="justify"><br /><a name="_Ref235200132"><span style="font-size:85%;color:#333333;"><strong><u>The Communication Architecture</u></strong></span></a><span style="color:#333333;"><span style="font-size:85%;"><br /></span><span style="font-size:85%;">The architecture provides communication management and enablement of external systems deployed over an ESB layer, conforming to the principle and discipline of SOA. The architecture diagram, Figure 2, outlines the communication between an Underwriting Workflow System and a Policy Manager (PM) . The communication is handled by the integration layer, employing BizTalk as technology and the Underwriting Workflow System is implemented using Pega PRPC. </span></span><br /></div><p align="justify"><span style="font-size:85%;color:#333333;">The primary use of TA in the given problem domain, is to achieve a model of communication that can evolve to allow BizTalk to move from being purely an EAI to the capability of an ESB wherein heterogeneous types of communication which includes communication will be possible. Such conversation will be with Document Management Systems, Claims Repository Service, external Rating Services and others. </span><span style="font-size:85%;"><span style="color:#333333;">In our problem domain, BizTalk maps the message of Pega PRPC, hereafter Pega, to the legacy Policy Manager. This is carried by transforming the data structure of the Pega messages into the data structure of native Policy Manager. There are 3 generic types of communication that describes the conversation between Pega and BizTalk. </span></span><span style="font-size:85%;color:#333333;"><br /></p></span><span style="font-size:85%;color:#333333;"><img id="BLOGGER_PHOTO_ID_5385549706985896114" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 247px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwH570QdvGOstLc85gE0STD1rEdjuFlZzpl7npVZ-GL-qML4eBVZxIKqS2vzRucFFqHkZ0pMDH8JD8tZRVLOCE0VHCjz0XA5GXBjwH_ItzJdTHBxfBIVHDIC08JwSsh2BOqB4iFXJCsEw/s400/TA2.PNG" border="0" /></span><br /><p align="center"><a name="_Toc227400587"></a><a name="_Ref214115627"><span style="font-size:85%;color:#333333;">Figure </span></a><span style="font-size:85%;color:#333333;">2 Communication Model</span></p><div align="justify"><span style="font-size:85%;color:#333333;">The communication model illustrates 3 communication types 1) notification, error and data, expressed as CS_Not, CS_Err and CS_Dat respectively which is channelled from Pega to BizTalk. BizTalk accesses the data mapping schema and transform the incoming schema into response schema which is agreed by the Policy Manager. The Data Mapper is logically represented by the ERD.</span></div><div align="justify"><span style="font-size:85%;color:#333333;"></span><br /><span style="font-size:85%;"><span style="color:#333333;">From BizTalk to the Policy Manager, there are two types of communication which are 1) notification, CS_Not and 2) Data, CS_Dat. The communication model represented follows an asynchronous mode, which is handled by the Request/Reply map repository. The latter holds the state that assigns the corresponding response from the Policy Manager to a Request from Pega. There is a polling mechanism to notify Pega that a response has been received for a corresponding request.<br /></span></div></span><div align="justify"><span style="font-size:85%;color:#333333;">There are 3 return communication types from the Policy Manager to BizTalk which are CS_Not, CS_Err and CS_Dat. The latter holds the data which is required by Pega to update any underwriting transactions. As we modelled the communication using TA, it has been observed that the existing legacy Policy Manager interface does not differentiate between success and failure response, hence there is no separation of identity between the error and success, which complicates the design of the integration layer. The design flaw has been identified whilst validating and type checking the communication model with TA. This has lead to some mistake proof mechanism within BizTalk to manage error and trace the error back to the presentation layer, i.e. General Underwriting System. BizTalk has to transform the Policy Manager schema into a structure agreeable by Pega. The communication medium employed across Pega, BizTalk and Policy Manager is SOAP.<br />The process starts at the requirement gathering phase, where TA is used to identify the core aspects of the communication which are in our context, the Pega component, The BizTalk component and Policy Manager (PM), as shown in Figure 3.</span><span style="font-size:85%;"><br /></div></span><span style="font-size:85%;"><span style="color:#333333;"><img id="BLOGGER_PHOTO_ID_5385549968929554418" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 375px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguuBdcH8XVV5zIn1OO5I3TFJzIb9-IkA-ruIu0hctfAGlcRYtD1FwneK4D6Lte3ZyHTcbZcUhkxsQBzi14ZyAPVkizt0wrrgkjKsI4CybTsUjmipefmFLZCI_0dv6VLQqPCzWwDgDY7SY/s400/TA3.PNG" border="0" /></span><br /><p align="center"></span><a name="_Toc227400588"></a><a name="_Ref235210941"><span style="font-size:85%;color:#333333;">Figure </span></a><span style="color:#333333;"><span style="font-size:85%;">3 Requirement communication model<br /></span><br /></span></p><div align="justify"><span style="font-size:85%;"><span style="color:#333333;">At the very early stage of design, while validating the communication with TA through formal checking, it has been observed that the BizTalk component includes two primary modules, which is required to be modelled separately, and these are the Mapper component and the Mediator component respectively. This is a typical problem of separation of concerns. The separation showed that the mediator service is solely concerned with the orchestration of the communication model whereas the mapper service is related to the data modelling which ought to be abstracted to the problematic of Canonical Data Model within an ESB. Using classical modelling techniques, purely static design such as sequence diagram, this dichotomy would have been missed in requirement and only be found at the late stage of design or coding. It is also possible that the separation would have been missed completely, adding overheads and reworks to preserve the characteristic of extensibility to the architecture.<br /></span></div></span><br /><span style="font-size:85%;color:#333333;"><img id="BLOGGER_PHOTO_ID_5385550501160298338" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 336px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLrUs6E2Buw3d5GR99GGYXurgc8hIJFhO8qi94ZlA7rOC0EXKeibCazZuq_c_pMUaZwm09_INyWR8aFaLV6WhTM2QTJzyg4j-yEdsE04JzStpyLVv3XanrmzsrL3Pvi9XMKidbSwHgYMo/s400/TA4.PNG" border="0" /></span><br /><div align="center"><a name="_Toc227400589"></a><a name="_Ref227396255"><span style="font-size:85%;color:#333333;">Figure </span></a><span style="font-size:85%;color:#333333;">4 Conversation Model</span></div><br /><div align="justify"><span style="font-size:85%;"><span style="color:#333333;">Whilst requirements are gathered, a model of the conversation within problem emerges as shown in Figure 4. This is static diagram that simply lays out the roles, the swim lanes (see Figure 3), and who can talk to who. This enables us to manage the conversation in the system and to also extend the model to add new components and test if the communication model still holds when new participants are added.<br />The next step is to bind the model in Figure 3 to a choreography, which will enable us to type check the model against the requirement in order to validate the model and remove ambiguity in the requirements for the communication model. The choreography is shown in Figure 5.<br /></span></span></div><div align="center"><span style="font-size:85%;color:#333333;"><img id="BLOGGER_PHOTO_ID_5385550920457804962" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 242px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEix6dnAukP_5knZ1dZJR90DMmSGHsfLmghAcLSXEWAdPJRVYJY2sjl1PL0po8fbYQGiBQb2paYznh7lQniCw6b3LbwL27hT4-lgS7DSAWEy0jT6bEXSDx_Ec_4aNQSthXkhZQl2FqATtTY/s400/TA5.PNG" border="0" /></span><a name="_Ref235211983"><span style="font-size:85%;color:#333333;">Figure </span></a><span style="font-size:85%;color:#333333;">5 Architecting the Design<br /></span></div><br /><div align="justify"><span style="font-size:85%;color:#333333;">The binding process involves the process of referencing the model in the requirement and binding the interactions. The binding process also has the effect of filling in some of the missing information on identity and business transactions. </span></div><span style="font-size:85%;"><div align="justify"><br /><span style="color:#333333;">With a bound model, the choreography in Figure 5 can be exercised in order to prove the model against the architectural parameters as shown in Figure 6. The model shows the participants which are Pega, conversing with the BizTalk mediator, then the mapper (for data transformation) to finally be passed to the Policy Manager participant.<br /></span></span></div><span style="font-size:85%;"><span style="color:#333333;"><img id="BLOGGER_PHOTO_ID_5385551692727017138" style="DISPLAY: block; MARGIN: 0px auto 10px; WIDTH: 400px; CURSOR: hand; HEIGHT: 366px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhriUe7_TcTRX3AiXDzN8mwoGyMaTTGu1h6oY0Ufl7fCyGnMypZkLGP4DOYAvJJvbXo5C-1Sqqa7EgXhGekmTJLUIn_uDDX2NljBUNX_6d_xhZQ1OavPfW0YRqC1JwyRweK5wIy6YgaSOc/s400/TA7.PNG" border="0" /></span><br /><p align="center"></span><a name="_Toc227400591"></a><a name="_Ref227394189"><span style="font-size:85%;color:#333333;">Figure </span></a><span style="font-size:85%;color:#333333;">6 Proving the Communication Model</span></p><span style="font-size:85%;"><p align="justify"><span style="color:#333333;">During the test of the architecture, the proof goes green (see Figure 6) if the configuration and parameters or more precisely the types of the interactions are correct and should it be red, the proof reveals that the model deviates from the requirements, highlighting the defects. </span></p><p align="justify"><span style="color:#333333;">Thus for each interaction we can see clearly what the identity is, what we call the type for that identity (the token or tokens) and the Xpath expressions which when executed over the example message (in our case the risk xml of Pega and the Policy Manager Process UW xml) return the appropriate values.</span></p><p align="justify"><span style="color:#333333;"><strong><u>Blended Modelling Approach</u></strong></span></p><p align="justify"><span style="color:#333333;">After the proof of the model is demonstrated, we believe that the models are true and they conform to the pre defined requirements and many of the ambiguities in the requirements have been detected and consequently resolved at the requirement and design phase of the Software Development Life Cycle (SDLC). Then, in exploiting the capabilities of model generation, TA provides us with a rich a proven set of artefacts such as UML designs and state-charts diagram of the model. In Figure 7, we show the state-charts generated from the proven dynamic models. This is typically the translation of the inductive models (the CDL model) to the more common deductive models (UML and BPMN). Then the course of the SDLC resumes with the normal route of the classical software engineering processes.</span></p><p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzvyTiS5z63ZR6VbbtRaT8L3Am0jU4pxtlZxR41Ew-HttNXHl3irCD48YGjIMPbKhaZt0CWirEccYFisZ0d7KZ_YRiU3nuYnIATxl_OVBlTpnx19uM76fUlIT-kAuy-xJGyfvP81M8uN0/s1600-h/TA8.PNG"><img id="BLOGGER_PHOTO_ID_5385743768784936578" style="WIDTH: 400px; CURSOR: hand; HEIGHT: 210px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzvyTiS5z63ZR6VbbtRaT8L3Am0jU4pxtlZxR41Ew-HttNXHl3irCD48YGjIMPbKhaZt0CWirEccYFisZ0d7KZ_YRiU3nuYnIATxl_OVBlTpnx19uM76fUlIT-kAuy-xJGyfvP81M8uN0/s400/TA8.PNG" border="0" /></a></p><p align="justify"><span style="color:#333333;"></span></p><p align="center"><a name="_Ref241732641">Figure </a>7 Generated UML Artefacts State Chart of the Underwriting System<br /></p><p align="justify"><span style="color:#333333;">The generated models along with auto-generated documentations are compiled into the design directives and coding principles that can be handed over to the software designer and the developers. The communication to these parties is founded on formal and mathematical checks which makes the design and the development of the system far less error prone. </span></p><p align="justify"><span style="color:#333333;"><strong><u>Conclusion</u></strong><br />In employing TA, we were able to identify business and core service easily and test them against requirements for the mediator business service and mapper core service. We worked very closely with key decision makers to ensure a full understanding and gain agreement on requirements through inductive modelling of requirements and the collaboration model that is embodied in TA. This allowed rapid turn-around with Business Analyst and reduced the overall design time. </span></p><p align="justify"><span style="color:#333333;">Secondly we were able to detect errors both as conflicting requirements (reported back and then remediated with the stakeholders) and technical design errors prior to coding, the latter being the legacy Policy Manager’s error handling problem. We were also able to simplify the design segmenting it and ensuring that it truly represented the requirements through TA. </span></p><p align="justify"><span style="color:#333333;">Finally, TA enabled the generation of implementation artefacts, such as UML designs and state charts that were guaranteed to meet requirements and were an order of magnitude more precise which reduced the communication need to ensure a high quality delivery. This is typically the capability of TA to blend the inductive with the deductive modelling techniques. </span></p><p align="justify"><span style="color:#333333;"><strong><u>Reference</u></strong><br /></span></p><br /><p align="justify"><span style="color:#333333;">(Chai71) Chaitin G J, “Computational Complexity and Godel's Incompleteness Theorem”, ACM SIGACT News, No. 9, IBM World Trade, Buenos Aires, pp. 11- 12, April 1971<br /></span></p><br /><p align="justify"><span style="color:#333333;">(Jenn01) Jennings N R, “An Agent-based approach for building complex software systems”, Communications of the ACM, Vol 44, No. 4, April 2001<br /></span></p><br /><p align="justify"><span style="color:#333333;">(Sim96) Simon H A, “The Sciences of the Artificial”, MIT Press, 1996<br /></span></p><br /><p align="justify"><span style="color:#333333;">(Oud02) Oudrhiri R, “Une approche de l’évolution des systèmes,- application aux systèmes d’information”, ed.Vuibert, 2002<br /></span></p><br /><p align="justify"><span style="color:#333333;">(Shaw90) Shaw M, “Prospects for an Engineering Discipline of Software”, IEEE Journal, Carnegie Mellon University, 1990<br /></span></p><br /><p align="justify"><span style="color:#333333;">(Boeh76) Boehm B W, “Software Engineering”, IEEE Trans. Computers, pp. 1,226 - 1,241, December 1976<br /></span></p><br /><p align="justify"><span style="color:#333333;">(Miln99) Milner R, “Communicating and Mobile Systems”, Cambridge Press, June 1999<br /><br /></span></span><br /></p><span style="font-size:85%;color:#333333;"><br /><br /><br /><br /></span><br /><br /><p><span style="font-size:85%;color:#333333;"></span></p>Dr. Bippin Makoondhttp://www.blogger.com/profile/10489437598692319170noreply@blogger.com8tag:blogger.com,1999:blog-7848800761385484905.post-10883997147358630992009-07-28T14:45:00.002+01:002009-09-26T10:00:14.052+01:00Evolution of Systems<div align="justify"><span style="font-family:lucida grande;font-size:85%;">In the discussion on evolution of systems, Hugues Bersini (Bersini05) states that:</span></div><div align="justify"><br /><span style="font-family:lucida grande;"><span style="font-size:85%;"><em>Of the many types of systems organisations models, those that are in the form of networks and which are based on distributed architectures are the ones that survive and are economically most viable.</em> </span></span></div><div align="justify"><br /><span style="font-family:lucida grande;font-size:85%;">The study on dynamic evolution (Fung04) supports Bersini’s statement as the authors explain that one can easily achieve evolution in a component-based distributed system. In this paper, Hay Fung explains the abstraction of components and their connectors facilitates system structures to accommodate changes, and the process of accommodation becomes an innate property of the system.<br /><br />Currently the software industry is in favour of the iterative and incremental development approach over the traditional waterfall model, in order to achieve flexible processes that handle requirements and reduce the risk by deploying smaller changes. In such an environment, dynamic evolution provides the flexibility in implementing changes to unforeseen and fluctuating business requirements which is very true for the type of economic climate we are now living in. We have moved form the industrial age to the knowledge age.<br /><br />Evolution is a key factor to software systems, because these types of systems are never isolated, but implicitly constrained by their users, the communication with external systems (man or machines) and the infrastructures (software or hardware) with which they communicate (Oud02). Each adjustment or modification from any connecting peers (interactive participants) may change or affect the internal system, hence the state machine. The system may be provided with some resiliency and intelligence through predefined logic, to either protect itself from these changes or adapt itself to these changes, depending on the hostility of the environment. In other words some decision dominance may be given to the system, defining an aspect of autonomy, and since the working environment is non-deterministic, the system will need to adapt and re-adapt itself, changing its course many times during its life time (Oud02)<br /><br />Unfortunately, investments in software systems are mostly focus on designing systems based on strict protocols and precise specifications and constraints, thus restricting the systems from its external communication. If we agree that software systems are never isolated, these types of design approach (strict protocols and precise specifications) go against the natural progress of software systems. The need for evolution in the design of complex enterprise system can be mapped to Lehman’s 8 laws of software evolution (Leh80).<br /><br />We considered Lehman’s 8 laws of evolution to establishing a new discipline to the formulation of a framework which will attempt to incorporate some aspects of evolution within enterprise wide systems.<br /><br />Law (3) Self Regulation - Global system evolution processes needs to be self-regulating to adapt to change. In mathematical terms, these regulations are pre-defined elements of a subset which are in turn elements of a global set, i.e. the enterprise architecture.<br /><br />Law (4) Conservation of Organisational Stability - Unless feedback mechanisms are appropriately adjusted, recorded and statistically analysed, average effective global productivity rate in an evolving system tends to remain constant over product or service lifetime.<br /><br />Law (5) Conservation of Familiarity – In general, the incremental growth and long term growth of systems tend to decline. Over the lifetime of a system, the incremental system change in each release is approximately constant.<br /><br />The laws 3,4,5 of software evolution, has not been the main point of focus, in this blog article, since they have some dependencies on other laws and are more abstract in nature. For instance laws 3 and 4, self-regulation and conservation of organizational stability respectively, are dependent on robust feedback mechanism which is law 8. Law 5, conservation of familiarity is very dependent on law 6 and 7 which are continuous growth and decline in quality. As a result, the following laws have been addressed in the research.<br /><br />Law (1) Continuing Change – “A program that is used in a real-world environment must change, or become progressively less useful”. A software system is never isolated and constantly communicates with external entities, which during the course of conversation changes the state of the software continuously. These changes cause variations within the internal system and are required to be managed and monitored to ensure that the changes tallies with the changes of the organisation. Continuous change is the basic law of evolution and is inherently implied even if most of the time, the client does not explicitly state it.<br /><br />Law (2) Increasing Complexity - “As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure”. As the number of communication agents (Service Components and network elements) increases, the communication model tend to become more complex and non-deterministic. Within an enterprise wide architecture, the law also applies to the message, as the content of the message tend to become more complex as the organisation matures from a B2C business model to B2B business models, extra resources are needed to preserve or simplify the structure of the systems in terms of manageability and serviceability. In an attempt to address the problematic of complexity, many decision makers are tempted to move towards a more manageable character of a common data model, the substratum of their service bus, yet on the longer term, this solution proves gruelling to scale and adapt to external systems. The very symmetric nature of the data model tends to hinder the evolution of systems.<br /><br />Law (6) Continuing Growth - “The functional capability of systems must be continually increased to maintain user satisfaction over the system lifetime”. Scalability of the functionalities is key in the design of extendable software solutions. Although software solutions may be well structured internally, exploiting the capabilities of hierarchically structured class libraries, the programs have grown large and monolithic, with a high degree of interdependence of the internal modules. The size of the programs and their relatively high level of user oriented interfaces make them inflexible and discomfited to use for the construction of new functions and applications or new service interactions. As a result, new applications usually have to be constructed at a relatively low level, as compiled programs, which are expensive and inflexible. The high degree of integration at the class library level makes it difficult to construct heterogeneous applications that use modules from different systems, since there is a lack of abstraction. This problem can be addressed by distributed systems which allow software modules to be represented as either stand alone or pluggable components in a distributed application through defined interface or configurable resource adapters. This technique will require the compositions of meta models and the continuous process of abstracting (reinforcing the meta models from lesson learned) and concretizing (deriving pluggable components from the meta model to satisfy the custom requirements of specific scenarios), hence scaling the capabilities of the systems.<br /><br />Law (7) Decline Quality – “Unless rigorously adapted to take into account for changes in the operational environment, the quality of a system will appear to be declining.” In order to manage the quality of the system, a quality process has to be put in place to improve both the operational environment and the system itself. In many studies directed to the evolution of computerised system (Zhan01, Mikk00 and Kout01), the aspect of quality management is very rarely considered. Yet, Lehman stresses that a decline in quality influences the viability of an adaptive system and for diverse reasons this is often the case for system that evolves. We firmly believe that the aspect of quality modelling and quality awareness has to be embedded within the system gene (at the code level if necessary). We refer to this model as the Run Time Quality Assurance (RTQA), modelled in the shape of an algorithm called the BipRyt algorithm (Mak04). The BipRyt algorithm was designed primarily to take into account the operational environment and steer the system, adjust its parameters to conform to the environment at run time, thus preserving the quality of the system as the system scales. The algorithm provides the aspect of autonomy to the collaborative participants of a system, which exploits a multi-purpose decision making mechanism for the management, control and optimisation of computational resources (e.g. node, CPU, channel, etc). The decision matrices regard all these participants as resources with diverse economical values (values which may be relative to each user).<br /><br />Fundamentally the algorithm is founded on the basis that:<br /><br />Rather than just using Quality modelling tools (such as the House of Quality, Analytical Hierarchy Process and Hypothesis Testing) as requirement and design activities, the BipRyt mechanism has embedded these approaches as a feature of the system (automating the methods of the tools) and made the system self-aware of its own quality attributes and react accordingly when there are SLA breaches or increased demand of resources<br /><br />Law (8) Feedback System – “Evolution processes are multi-level, multi-loop, multi-agent feedback systems.” Feedback is a strong management tool to revise and improve a system. Since, software systems are never isolated, a robust feedback mechanism is required to validate the compliance of system functions over which the system developers have little or no control (Morr00). Due to the lack of control over the external components, the most economic approach is to implement feedback mechanism to obtaining statistics on how the components and the interface behaves, and then evolve in the light of that feedback. We have formulated and implemented an automated feedback mechanism (based on the concept of hypothesis Testing and Design of Experiment) within the decision process of resource management of service components of enterprise wide architectures to create an adaptive, decision making algorithm.<br /><br />However, in order to design systems that evolve, one is also required to consider the aspect of autonomy within the distributed participants of the system. The study on the drive behind evolution of software architecture (Estu99) shows that systems are evolving under the pressure of a number of factors, which are: 1) distribution requires components to be more autonomous and to communicate through explicit means (not linked); 2) maintainability does not requires changing of the source code of components; 3) evolution of system and mobility require keeping components independent and autonomous and 4) Cost requires buying instead of building.<br /><br />We believe that there is a 9th law missing in Lehman’s law of software evolution which is:<br /><br /><em>“For a system to evolve, it has to be distributed in nature with autonomous parts collaborating and exercising the 8 laws.”</em><br /><br />What is a neurone on its own... what is an ant on its own? In my next blog, I will be discussing about autonomous Systems.<br /><br />References:<br /><br />(Bersini05) Bersini H, “Des réseaux et des sciences – Biologie, informatique, sociologie: l’omniprésence des reséaux”, Vuibert, Paris 2005<br /><br />(Fung04) Hay Fung K, Low G, Bay P K, “Embracing dynamic evolution in distributed systems Software”, IEEE Vol. 21, Issue 2, pp. 49 – 55, March-April, 2004<br /><br />(Oud02) Oudrhiri R, “Une approche de l’évolution des systèmes,- application aux systèmes d’information”, ed.Vuibert, 2002<br /><br />(Leh80a) Lehman MM, “On Understanding Laws, Evolution and Conservation in the Large Program Life Cycle”, Journal of System and Software, vol 1, no. 3, 1980<br /><br />(Zhan01) Zhang T, “Agent-based Interperability in Telecommunications Applications”, PhD Thesis, University of Berlin, 2001<br /><br />(Mikk00) Mikkonen T; Lahde E; Niemi J; Siiskonen M, “Managing software evolution with the service concept”, in the Proceedings of International Symposium on Principles of Software Evolution, pp 46 – 50, 2000<br /><br />(Kou01) Koutsoukos G, Gouveia J, Andrade L, Fiadeiro J L, “Managing Evolution in Telecommunications Systems”, IFIP Conference Proceedings, Vol. 198, 2001<br /><br />(Mak04) Makoond B, Khaddaj S, Saltmarsh C, "Conversational Dynamics", Kingston University, February 2004<br /><br />(Morr00) Morrison R, Balasubramaniam D, Greenwood R M, Kirby G N C, Mayes K, Munro D S, Warboys B C, “A Compliant Persistent Architecture, in Software Practice and Experience” vol. 30, no. 4, pp. 363 – 386, 2000<br /><br />(Estu99) Estublier J, “Is a process formalism an Architecture Description Language?”, Dassault Système / LSR, International Process Technology Workshop (IPTW), Villard de Lans, France, September, 1999<br /></div></span>Dr. Bippin Makoondhttp://www.blogger.com/profile/10489437598692319170noreply@blogger.com1