Ethelcofie’s how to articles has moved to http://blog.ethelcofie.com/
I thought it would be better to have all my stuff in one place
Cheers
October 6, 2008
September 24, 2008
Barcamp spillover event
Repost
BarcampLondon5 is full. Lots of people who wanted to go couldn’t get tickets. We figured: why not have our own, extra, mini-barcamp? The British Computer Society kindly volunteered to host, so it’s on: we’ll have a one-day barcamp on the Saturday (27th).
This will only be on the Saturday and there’ll be nowhere to sleep: apologies to those who can’t manage a trip to London just for the day.
The BCS are also providing tea and coffee throughout the day.
When?
Saturday 27th September, 9am-9pm
How?
We’re issuing tickets now through Eventwax. Go!
Where?
First Floor
The Davidson Building,
5 Southampton Street
London, WC2E 7HA
September 22, 2008
September 20, 2008
The Web 2.0 Concept
Article written to add to the pool of knowledge ob the evolution of the web .
Web 1.0 was “read-only”, Web 2.0 is “read-write”, and Web 3.0 will be “read-write-execute”.[ http://www.britannica.com/blogs/2007/07/web-30-the-dreamer-of-the-vine/]
Web 1.0 can only be described as read only.it was very much in the hands of the specialized web developers and designers .Content was generated by these specialized parties .
Then came along the concept of web 2.0 a term popularized by orielly media which as a natural progression of the web 1.0 .Technologies were/are being developed that enabled the web to become readable and writable.Technologies such as XML,RSS, AJAx just to name a few
The concept of web 2.0 is based on the concepts of collaboration,information sharing and user generated content and as a consequence social networks,web based communities,video sharing ,blog,wikis
Listed below are in my opinion three of the best videos that discuss the origins and concepts of web 2.0
Web 2.0 Introductions
September 24, 2008
Cover Letters the Speed Dating Version
Reposting a blog entry from one my favourite blog posts its non IT Though.
I really really hate cover letters. They restrict my breathing and cause traffic jams in my usually uncongested neural pathways. No matter how hard I try to sound unique and interesting, something about the process makes doesn’t quite ring true. Maybe it’s the formulaic nature of it all. Or that every recruiter believes keeping it short and to the point is crucial since no one has the time to bother with more than one A4 page anymore.
So, this is my ode to the cover letter (I will abide by some basic rules but essentially do away with all the pomp and ceremony that generally gets me nowhere). I am writing it as a blog entry that I’m hoping will one day be a part of the Twice archive. And if not, it will find a home at
http://vimbaikavhumbura.blogspot.com
WHO AM I – THE SPEED DATING VERSION
Bearing in mind that the reader may need to get back to work soon I will give the abridged version of it here. More detailed notes and insights are available on request. Born in Zimbabwe, raised in Swaziland, educated in Cape Town and Brighton I am a bit of a rolling stone. All four places complete my sense of home – which makes for interesting political debates and fights during cricket matches. I have always had a fascination with making things, from knitting to T-shirt design, papier mache piggy banks to cheesecake- still trying to master that one. I love the process of creating new things and the feeling of knowing that there is no other one like it in the world. When I’m not making stuff I dream of making stuff, which is probably why I’m a bit of an insomniac, really. So, I can speak English and Shona and passable basic Afrikaans, French and siSwati. What this means is most people need to be pretty creative to swear at me. I love to sing and dance (but try not to in the office as I’m not really an X Factor candidate). I’m fascinated by words: poetry, prose, hip hop. I collect remixes of my favourite songs. My favourite place in the world is the middle of the Namibian desert, and no, not because Angelina had a baby there. Visually I’m impressed by film making above all other forms of art.
My very first school report read: Vimbai is too talkative. Some might say I have the gift of the gab. I have since refined this skill into some impressive public speaking and presentation skills. I can chat about anything from Brian Lara’s batting average to why Sarah Palin will not be the next Vice President of the USA, and why Rex should not win Big Brother. I like to have opinions and share them occasionally. Despite the picture we’ve painted so far, I generally prefer to listen that to talk…you learn more that way. And I’d rather read or listen to the new Roots album than watch TV, unless there’s a good movie on.
So, that’s my attempt at unique and interesting. Did I mention I like chocolate?
WHY I WANT TO WORK AT TWICE
Ideas, ideas, ideas. It is my favourite way to shock people to suggest that people get dumber every generation. A favourite author of mine wrote: Too many morons, not enough Michelangelos. I really don’t think this is true. It’s just easier in most cases to wait for someone to give you the answer. I think there is a lot of power in this. The Church did it, then politicians did it. Now its global brands that tell us how to behave and what choices we should be making on everything from baby food to where to go on holiday. Brand designers are at the top of the pile here. We are the ones who tell the brands what to tell the people to think. And the key to this is persuasion and self awareness. At Twice, this process is clearly and simply laid out. Idea, relationship, action. No fuss, no strings. The best kept secret is the one that’s left in the open. Twice is a company that constantly produces results for their clients so the real secret must be in the execution. This is what I wish to learn.
WHY I’M IRRESISTIBLE
For me branding is the difference between a turkey and a peacock. Something that seems obvious, but that can be broken down on many levels and tweaked to achieve different results. Essentially they are the same bird, one just figured out a way not to be eaten. I’m still working on this thesis and would love some feedback on the premise. The facts and figures of what I’ve done so far that may be useful in a company like yours are basically that:
-I like to think and to do
-I know how to work with people and how to talk to them
-I think inside AND outside the box
-I love to muck in
I suppose that’s pretty much it. They say you shouldn’t give too much away on the first date and I hope that I’ve sparked you interest enough to discuss things further in person. I’m available at your convenience (though this is a bit of a text book ending to the cover letter, sometimes there’s no need to mess with a classic).
By Vimbai K
September 15, 2008
Program for simulation of mutual exclusion with the use of semaphores
Program for simulation of mutual exclusion with the use of semaphores
PROBLEM DESCRIPTION
In operating systems the problem of mutual exclusion is very often encountered because of multiple processes that access, modify certain shared resources such as data structures .The operating system need to ensure that these shared data structures are not accessed and modified by multiple processes at the same time causing incorrect results for the processes involved. One of the solutions to the problem of mutual exclusion is to use semaphores which as defined by http://encyclopedia.thefreedictionary.com as a protected variable (or abstract data type) and constitutes the classic method for restricting access to shared resources (e.g. storage) in a multiprogramming environment.
Semaphores have two basic functions, P():checks if critical section is filled then blocks or allows process as appropriate() function: checks when a process leaves critical section and removes it from semaphore queue.
The semaphores are used to implement these rules: to at most one process uses the shared data structure at a time (critical section) and all processes get their turn with the shared resource
PROGRAM DESCRIPTION
This java program simulates the use mutual exclusion using semaphores. The program involves four processes named process 1,2,3,4 who are competing for critical sections A,B,C,D,E,F,G. with a semaphore A for critical section A,sem Z for B,semC for B,sem D for section E, ,sem F for section F and lastly sem G for section G .
The simulation program implements mutual exclusion by implementing these three rules:
1. At most one process may execute in the critical section a time i.e. all processes that request a critical section that is occupied are denied request and are to wait.
2. Request to enter and exit a critical section is eventually succeed: All processes that have made a request for a critical section may be denied a request initially but after a wait will get into the critical section when it is available.
3. Critical section request are prioritized on First come first served basis
HOW PROGRAM WORKS
The program simulates a random request by any number of the processes for any of critical sections and implements the management of these process request using mutual exclusion rules stated above.
The program works by creating four processes, then creating 7 semaphores along corresponding to the 7 critical sections. The implements a P function whose primary task is to check when a process makes critical section request using the counter variable whether or not the critical section is occupied if it is it blocks the process until critical section is vacant else removing process from process queue and adding it to the semaphore queue
The program also implements the V function whose primary duty is to check for a process leaving a critical section decrease counter value flagging the critical section as vacant .This is implemented after a process sends a message of leaving the process
ALGORITHM
Create Processes
Create all 7 critical sections
Create corresponding semaphores for each critical section
If for a process request for a critical section
Then
Check if semaphore counter >0
Refuse permission to enter section for process and request process to hold till critical section if available
Add process to semaphore queue
If semaphore counter =0
Then
Grant permission to enter the critical section
Remove process from semaphore queue
If process sends an acknowledgement to leave the critical section
Then
Decrease semaphore counter
DRAWING OF A SCENARIO OF THE MUTUAL EXCLUSION SIMULATION PROGRAM
DRAWING OF A SCENARIO OF THE MUTUAL EXCLUSION
SCREEN SHOT OF MUTUAL EXCLUSION INVOLVING FOUR PROCESSES AND 7 CRITICAL SECTIONS AND THEIR METAPHORS
September 8, 2008
A developer’s plunge into the world of Test Analysis
I am a developer at work and at heart who had not done much formal testing except to verify that the system I was developing worked [J] .I however moved into a new job which dictated as part of my contract that I had to go through a two month period working as a full time test analyst for the experience .
My reaction: What! No building stuff, no development well at least not at work for the next two months *groan groan* I am going to die before I complete my time I just know [my melodramatic side showing]
So I started my stint praying time would go fast and I wouldn’t realize it. l also acknowledge above my melodramatics that it was probably a good learning experience which will make me a better developer in the long run .
I started out running manual scripts for an online financial system painful yes, by the end of the second week I was fast losing my will to live.
So to keep from going crazy I turned to reading materials on what testing was all about and what made a great tester. There had to be more to testing! Right?
Yes! Right, My perception of testing as developer changed dramatically when I moved to 2 relatively small size projects [less that 10 people ] working as the sole test analyst on the first and as an adjunct test analyst on the second .
So what changed for me?
Being the only test analyst on a project means I had to learn quickly what was required of me , what mentality I was to adopt to be effective in my role and of course how to work smart as opposed to laboriously , what tools would make my work better or not .
Fundamentally I believe I begun to thoroughly enjoy being a test analyst when I bought into the mentality and attitude of a tester.
No it’s not being sadistic it’s the fact that I am the last line of defense for the customer it’s my job to make sure that the customer gets the best product possible [or die trying J]
There will always be something wrong with the system and if it’s big enough to make the users experience or systems substandard then I will find it .oh yes I will ….
..And the love for breaking things especially software
Also automated testing appealed to the developer/programmer in me, I could write/program automated test s that could do a lot of the mundane repetitive tasks and User Acceptance Tests that needed to be done
What I learnt
I took away for my time as a test analyst:
Tact: saying to developer fix this! Fix this Now! Is hardly going to get you anywhere .When to push when to stop when to assert and to smile and let go.
A better eye for detail when I am developing :I have a sort of split personality now when I am working I look at the system through the eyes of a tester and a developer.[I still believe it not right for a developer to double as his/her own test analyst ]
…And a whole new respect for the testers I work with.
August 31, 2008
My Motivation for choosing a Career in Information Technology
I found a draft of my Graduate School Essay and it makes me realise that my reasons for starting a Bsc in Computer Science as a perlude to career in IT still holds true today : enjoy
ETHEL DELALI COFIE
SUPPORTING STATEMENT
The computer is dumb;
I am smart and the computer is only as smart as the one who writes its logic.
These were the thoughts that crossed my mind as I sat in my first programming class along with another thought “am I sure I understand correctly what this lecturer is saying”.
I had signed up for this computer training class after my secondary school education to learn for the first time in my life about computers and how they worked and my first class had succeeded in revolutionizing the way I thought of computers.
I begun think to myself, well this computer stuff isn’t that bad after all and then mentally put it on the list of my career options I was considering at the time. After 6 months of the computer training course, I decided that a career in computing was what I wanted; I therefore applied to Valley View University to pursue a BSc course in Computer science.
I was the unofficial Class President during my years in the university given that I was always the one who would organize and rally the class to complete tasks.
To further illustrate; The course work for the Expert system course included developing six expert system modules individually using the Knowledge Wright development platform from about a hundred pages of system requirement documents. I rallied the class and we decided that different groups of students would analyze and develop one system each, and make a presentation to the class for approval and onward dissemination, cutting down the effort and time needed to develop the system individually and enabling all of us to get much needed sleep.
In the University I took a semester’s course in distributed systems but I really developed interest in the subject area after taking an internet based applications course. Learning about object oriented client based systems,J2EE,Corba,Ole/ActiveX ,the concept of autonomous computers working together but seeming as one coherent system and the connectivity offered by the internet I realized there was limitless possibilities in this subject area.
I became fascinated for instance by the idea of developing a system connecting a company’s geographically dispersed sites as well as thousands of sales representatives which would effectively manage sales ,billing ,stock control ,delivery and order tracking all in real time .
This fascination led me to develop for my final year project a java based Client Server system for electoral data collation and statistic generation. This software is part of the few projects selected to be showcased in Valley View University’s annual press exhibition to be held in March 2006.
During my years in the university I endeavoured to acquire knowledge not only in the classroom but also in industry:
My first year summer break was spent as an intern in Softtribe one of West Africa foremost software houses. There I worked developing modules in C++ and Java for their major systems being developed at the time.
The second year summer break saw me studying French because I believe that to be successful you need to be internationally competitive.
During my third year summer break I became an intern at INIIT a computing research and development firm. After that summer I stayed on and worked part-time through to my final year and then after Graduation went on to work with them fulltime.
At INIIT, I initially worked on web applications using PHP and JavaScript, and then moved to system analysis and design.
I am presently the project leader involved in developing a Client Server System which will be accesses via the intranet using Visual basic and SqlServer and I also represented my organisation in an ICT, telecommunication and media convergence conference in Cotonou –Benin (West-Africa) in February 2006. This conference was organized by the Panos Institute West Africa ( CIPACO project), in collaboration with the Haute Autorité de l’Audiovisuel et de la Communication (HAAC) of Benin, the African Communication Regulation Authorities Network (ACRAN) and the West African Telecommunications Regulators Association (WATRA).
I was also part of the writing of the Cotonou Appeal on the Regulation of Convergence the document adopted at the conference.
I aim not only to develop more systems with a bias towards distributed systems and gradually move into the management of my own multinational computing firm and this has influenced my choice to study for an MSc in Distributed Systems Integration at De Montfort University.
This is because after a critical look at the course modules being offered I realised that there is the right blend of technical, management and e-business modules to give me the relevant skills, up-to-date tools and knowledge not only to be technologically savvy but also for management also because as stated in the prospectus the course was designed in conjunction with industry.
Ps : I didn’t end up going to De Montfort though they offered me a place ,
I went to Brighton University because they offered me a scholarship and they were by the sea
I do have my Msc in Distributed Systems now and everyday i happily work on a variety distributed Systems be it a financial sysytem or a booking system
August 28, 2008
Distributed computing paradigms: traditional client server or mobile agents.
SOFTWARE EVALUATION RESEARCH
TITLE: DISTRIBUTED COMPUTING PARADIGMS TRADITIONAL CLIENT SERVER OR MOBILE AGENTS.
ABSTRACT
A Distributed system can be described as collection of independent computers who are interconnected that work together to perform a computation task. Computers in the context of this paper includes mobile devices such as PDA(Personal Digital Assistant) and mobile phone .Distributed systems stem from the need to make better and more efficient use of computing power by combining the computing power of various independent machine. It also rides literally on the backbone of the technological advancement in networking Local area Networks (LAN), Wide area networks (WAN) and the internet.
Communication among the computers involved in a Distributed System is paramount because without the ability of the computers to communicate with each other the set computation task cannot be accomplished.
The objective of the paper is to investigate the different design paradigms of developing a distributed system based on how they implement communication and which paradigm is the most efficient and cost effective.
This paper introduces a short history of distributed systems, delving into its Goals and objectives with example of different types of distributed system.
The two most used design paradigms the traditional client server paradigm and the newer agent based paradigm are discussed in detail stating the how they work technically.
Finally this paper’s comparism includes the relative advantages of both paradigms with research on a practical experimentation of both paradigms using a Java based client server and agent based systems to determine which a better paradigm was.
1.0 INTRODUCTION
Since the modern era of computing begun in the mid 80’s ,the need for increased and efficient use of computing power has been a constant feature .This revolution started with development of increased power of microprocessors at a fraction of the price of the main frames and mini computers .
In pushing for the greater computation power with the PC (personal computer), there was not only an increase in the microprocessor power and storage of these computers but also the push to link these computers to enable the efficient use of the resources such as memory, printers, files etc.
This brought about the invention of the high speed networks: Local Area Networks: enabling computers to be interconnected within a closed geographical area e.g. an office building then Wide Area Networks (WAN’s) interconnecting large number of computers over wide geographical area, the internet is a good example of wide area networks: This would enable a company with branches in Milan, England and Australia to share databases.
This ability to interconnect machine regardless of the geographical location is the wave on which the distributed systems paradigm emerged.
There are variety of definitions of a distributed system two is listed below:
A distributed system is one in which components located at networked computers communicate and coordinate their actions only by passing messages. [George et al 2001, p.1]
A Distributed system is defined as a collection of independent systems that appear to the users of a system as a single system. Processes and/or data can (or cannot) move from host to host, share information. (IEEE distributed systems online)
As stated in the definition A Distributed is characterized by the fact that the computers are autonomous computers ,also the machines collaborate to work on tasks but appear to the user not as a fragmented groups of machines abut as one coherent unit .
As a further illustration of what a distributed system ,this System would be described as a distributes system: Sales representatives of an organization who may be spread over a wide geographical locations could place orders by means of laptop computers connected via telephone networks or possibly cell phones, incoming orders would then be automatically forwarded to the planning department, resulting in new internal shipping orders sent to the stock department, as well as billing orders to be handled by the accounting department. The system would then automatically forwards orders an available and appropriate and available person and all these processes would appears to the users as one centralized databases. [Anonymous]
Also Organizations with large projects to complete have attracted Internet users from across the world to donate their computer’s time. SETI@Home — by far the most popular with users — analyzes data from a telescope, searching for potential signals from extraterrestrial life. RC5-64, a project from Distributed.net, is testing out 72 quadrillion keys to unlock a 64-bit encryption code. The Great Internet Mersenne Prime Search sorts through numbers in the millions for a large prime number. [DC CENTRAL, 2000 http://library.thinkquest.org/C007645/english/0-application.htm]
1.1 The Goal/Characteristics of Distributed Systems is to:
Connecting Users and resources: The major goal of a distributed system is to enable users regardless of the geographical location of their users to connect with each other and share resources .This obviously has its security drawbacks: who should have access to which resource and how often, how the distributed system offers authentication and validation etc. Resources shared over a network could be a database, a printer, processing power etc. The internet shows examples of how resources can be shared over an electronic medium e.g. multimedia like music, movies, short clips etc
Transparency: By the very definition of a distributed system the users of a distributed system should not be able to detect that the different computation tasks are distributed across different machine .This is thus the argument where some researchers dismiss the internet as a distributed system whilst others do not because users do recognize on the internet that they are accessing different servers.
There are different types of transparency these are:
Access: Hide differences in data representation and how resource is accessed
Location: Hide where resources are located
Migration: Hide that resources may move to another location
Relocation: Hide that a resource may be moved to another location while in use
Replication: Hide that resources may be replicate (e.g. replicate websites and databases on the internet)
Concurrency: Hide that a resource may be shared by several competitive users
Failure: Hide the failure and recovery of a resource
Persistence: Hide whether a software resource is in memory or on disk
(Tanebaum et al, 2002, p.5)
Openness: An open system is a system that can interact with other systems according to certain laid down standards, meaning that even systems that are made from different manufactures and developers should be able to interact with each other according to set rules, syntax or standards. E.g. Interface Definition Language, XML, Web services protocol, Open Systems Interconnectivity (OSI) model.
Scalable: Distributes Systems ought to be infinitely scalable but due to technology advancement it cannot fully meet its target .However a distributed to large degree must be scalable new machines and users should be able to be added without decrease in performance of the system
Also the geographical areas of the distributed system could be increased with no fatal decrease in the distributed system performance.
In all these increase in size and geographical area the system should still be administratively manageable.
2.0 INTRODUCING THE RESEARCH TOPIC/AREA
As the paradigm of Distributed metamorphosis’s and come of age in it self, as in any technology there is drive to increase the efficiency to provide better service and efficiency to users and developers alike. The major bottle neck of distributed systems is communication/passing of messages between computers that enable the sharing of resources across the networks .In response two this two paradigms of how a computers passes and receives its messages have emerged.
Distributed System traditionally uses the client server paradigm in implementation where each autonomous machine become a client request a service or data from another autonomous machine (Server).
However another paradigm is emerging: This is the use of the Mobile Agents to implement a distributed system. In other words instead of the traditional invocation of a method or service from a remote machine/or computer. An Agent migrates to the Destination compute/Machine executes to retrieve the data or service it needs and returns the results to Host Machine.
This research paper is investigating these two paradigms/Architectures: the traditional client server paradigms and the newer mobile agent based paradigm.
This paper researches which is the most efficient implementation paradigm for distributed systems
2.1 Traditional Client Server Model
The traditional client server architecture of the distributed is primarily composed on two parties .The Client and the Server. These roles are interchangeable in a distributed system depending on the need of the machine at that point in time.
The Client makes a request by sending a message to the server and the Server unwraps the message, decodes it and processes the request and sends the reply in the form of a similar message back to the Client .There are some specific types of servers that serve a particular need e.g. an application server, file server, terminal servers, mail servers
Illustrating this fact a Client machine (Sales Executive) in Tokyo can make a request for sales numbers in the London Office from the London Office database server.
Tele workers can work from home based on this same principle.
Obviously in the Client Sever model there is a need for connection between the client and Server. Connection or connectionless protocols like TCP/IP may be used to as the channel to transmit, messages across the network.
In a connectionless protocol the Client sets up the connection with the Server, sends the message and cuts the communication connection .The Server receive the message processes it establishes a new connection to sends the requested reply. An Example of connectionless protocol is TCP/IP.
A transmission failure is invariably the one greatest disadvantage of the connectionless protocol. When does the system realise that the message did not arrive at its intended destination or was corrupted in the transmission process.
The connection protocol require that a connection is set and maintained between client and server till the request message is processed by the client and reply to client is
sent. It is much more costly in terms of bandwidth usage as compared to the connectionless protocol but less prone to transmission failure.
There are many variations of the client server architecture: Thin client where almost no processing is done on the client, all processing is on the server graduating to the next extreme fat client where the most of the processing is performed on the client.
In the Client Server model or paradigm it is the communication between machine that is the driving force but actually on the granular side it is the in the communication between processes that drive a distributed system.
A distributed program consists of multiple program units that may execute concurrently
on the nodes of a distributed system, and inter act by exchanging messages . A running program unit is a process. The distributed programming consists of implementing distributed applications. [ PATRICIA , November 1992]
In computing, a process is an instance of a computer program that is being executed. While a program itself is just a passive collection of instructions, a process is something which actually executes those instructions. Several processes can be associated with the same program – each would execute independently [http://en.wikipedia.org/wiki/Process(computing)]
In the client Server Model the communication models that are used to perform the reply request Client Server request are [Tanebaum et al .2002, p 57] Remote call procedure, Remote Invocation and Message–Oriented Middleware (MOM) stream.
Remote Procedure Call: In a standalone computer one process calls the other by calling that function necessary to perform that function along with supplying the requisite parameters. Remote procedure call uses the same kind of principle but in much more complex way.
Basically in remote procedure calls the client remotely calls a function on another machine that it might use to perform a function. The idea is to call a remote function as if it were a local function on the client machine. Thus is to ensure transparency where the requesting client or machine cannot tell whether the request is processed locally or remotely.
The Technical aspect of Remote procedure call is explained below:
Remote procedure calls are usually embedded in client/server program which in on compilation create a client and server stub.
According to research from ANDREW S TANEBAUM and MAATEN VAN STEEN’s book Distributed Systems Principles and paradigms :The client stubs duty is to pack the clients parameters into a message and request that the message to be sent to the server via the network connection.
The server stub is also defined as the server side equivalent of the client stub.
The server stub is a piece of code that transforms requests coming over the network into local procedure calls. [Tanebaum et al. 2002, p.71]
According to the research from [Tanebaum et al. 2002, p.71] When the packaged message arrives at the server the operating system of the sever machine send the message to the server stub who unpacks the message and then calls the server procedure needed to be executed.
RPC increases the flexibility of architecture by allowing a client component of an application to employ a function call to access a server on a remote system. RPC allows the remote component to be accessed without knowledge of the network address or any other lower-level information. Most RPCs use a synchronous, request-reply (sometimes referred to as “call/wait”) protocol which involves blocking of the client until the server fulfills its request. Asynchronous (“call/no wait”) implementations are available but are currently the exception.
RPC is typically implemented in one of two ways:
- Within a broader, more encompassing propriety product e.g. distributed computing environment, Sun RPC or Open Network Computing.
- by a programmer using a proprietary tool to create client/server RPC stubs
(http://www.sei.cmu.edu/str/descriptions/rpc.html )
In the research I culled an example to better explain the concept of RPC
A program at a Stock Exchange includes a read call to get data dollar –pound from a remote machine .The client stub on the client machine takes the parameters provided by the client packages it up into request and send it across the network to the server. The server operating system then the request and forwards it to the server stub who then unpacks the parameter and call the right read function for the request.
The client in the mean time is blocked. Once the read function is executed the server stub packages the reply and sends it back to the Client.
The Client operating machine receives the exchange rate and sends it to the client stub who then unpacks the exchange result sending it to the client for use.
Remote Object Invocation: In the programming paradigm, object-oriented programming is when an object is an individual unit of run-time data storage that is used as the basic building block of programs. These objects act on each other, as opposed to a traditional view in which a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility [culled from wikipedia]
The class of Dog defines all possible dogs by listing the characteristics that they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur. In programmer jargon, the object Lassie is an instance of the Dog class. The set of values of the attributes of a particular object is called its state. [Culled from wikipedia]
The object oriented concept become popular a few years over procedural programming being especially promoted by Java.
Thus as the Distributed have become diverse as some are implemented procedurally and others using the object orientation programming .Remote procedure Calls (RPC) which is solely procedural has being modified to accommodate the Object oriented concept using
According to research culled form [Tanebaum at al, 2002].”An object by its very nature can implement multiple interfaces .This strict separation allows us to place the interface at one machine while the object itself resides on a different machine. This organization is referred to as distributed object.
When a client binds to a distributed object, an implementation of the objects interface called a proxy is loaded into the client‘s address space. A proxy is analogous to a client stub in RPC. The only thing it does is to marshal methods of invocations into messages and unmarshal reply messages to return the result of the method invocation to the client.
The actual object resides at the server machine where it offers the same interface as it does on the client machine.
Incoming invocation requests are first passed to a server stub often referred to as skeleton, which unmarshals them to proper method invocations at the objects interface at the server. The server stub is also responsible for marshaling replies and forwarding reply messages to the client –side proxy.
A characteristic but somewhat counterintuitive feature of most distributed object is that their state is not distributed: it resides at the single machine .only the interfaces implemented by the object are made available on other machines. Such objects are also referred to as remote objects”. [Tanebaum et al 2002, p.86]
2.2 Mobile Agent Model/Paradigm
Having discussed The Client server architecture/paradigms, this research paper proceeds to the Mobile Agent paradigm of Distributed System Architecture.
Cumbersome computations can often be broken into discrete units for distribution among a pool of servers or processors. Each of these discrete units can be assigned to an agent, which is then dispatched to an “agent farm,” where the work is actually performed.
Upon completion, each agent can return home and the results can be aggregated and summarized…-– Stefan Marti, MIT Media Lab. in the article. Applications for Aglets.
This quote above amply describes the mobile code/agent paradigm of Distributed system architecture.
To better explain the concept of mobile code paradigm it is imperative that this research paper delves into what a Software Mobile Agent is and how they work relating it back to the how function as a paradigm for Distributed system development.
The Definition of what a software agent is quite a contentious topic. The views are varied and wide spread. Using the broadest definition is in the article Effectiveness and Suitability of Mobile Agents for Distributed Computing Applications (Case studies on distributed sorting & searching using IBM Aglets Workbench).
It states that a software agent is process or code that that is situated within an execution environment; possesses the following mandatory properties:
- Reactive; senses changes in the environment and acts in accordance with those changes;
- Autonomous; has control over its own actions;
- Goal-driven; is pro-active and is to perform a specific task
- Temporally continuous: executes continuously; and may possess one or more of the following orthogonal properties:
- Communicative; can communicate with other agents;
- Mobile; can travel from one host to another;
- Learning; adapts in accordance with previous experience;
- Believable; appears believable to the end user.
In other words agents are figuratively speaking the first step in the AI (Artificial Intelligence) Paradigm but with a more realistic approach and less hype.
There are wide arrays of processes that can be described as software agents within and without the distributed system environment .They perform various tasks as a single unit or in collaboration with other agents.
Borrowing an example from a paper on mobile code paradigms this real life example helps explain how the concept mobile paradigm works
Louise wants to prepare a chocolate cake. She has the right recipe and ingredients, but she has not an oven at home. However, she knows that her friend Christine has an oven at her place, and that she is very happy to lend it.
So, Louise prepares the chocolate dough ad then goes to Christine’s home, where she bakes the cake. [Carzaniga et al, 1997]
A typical role of an agent in a distributed system is a function of the type of distributed environment it operates. E.g. in an ATM (Automatic teller Machine) application consists of an account database server, with customer request agents distributed across the network submitting requests. The account server agent and the customer request agents are agents within the ATM application, but they might also serve agents residing at the financial institution’s headquarters, as part of an administrative application. Example culled from (http://www.unix.org.ua/orelly/java-ent/dist/ch01_01.htm)
There is no agreed taxonomy of categorizing the agents but agents are usually categorized by their characteristics and attributes .There are some agreed classes of Agents .These are:
Collaborative Agents: Agents in a multi agents system work to together to perform a task. This uses the characteristics of autonomy and collaboration
Mobile Agents: A prominent feature of some agents is the ability to remove them selves from one machine and execute themselves on another machine either the same of different platforms.
Interface Agents: They have learning capacity and they assist the user in the use of applications, learn user preferences and adjust accordingly.
Information Agents: Main ability of these types of Agents is to collect order sort and presents information from different sources. That tends to be a much used agents within the distributed system environment. (Tanebaum et al, 2002)
These characteristics of the of a software agent which allow to migrate to a host machine execute itself and retrieve the data it need and migrates it self back to the Source machine and collaborate with other agent in task performance is seen as alternate design paradigm to the traditional Client Server.
2.2.1How Mobile agent paradigm works
The Mobile agent/code is mostly dependant on the how it packages its self (code) and the execution environment and the method it takes to transfer itself from the Host node to the destination machine and its platform. This could be with homogeneous platforms meaning that the machines are of the same make and hence easily compatible or Heterogeneous where the machines have different makes are therefore less easily work together or are compatible.
Migration of the Agents especially between heterogeneous environments involved in the distributed environment is a technically difficult due to the fact that it involves issues with binary compatibility of the platforms involved.
There two types of Agent migration these are weak migration and strong Migration.
The mobile agent can be migrated in two ways .it migrates it self in other word its code and then its execution state (i.e.internal state and the private data)
Thus in weak mobility the agent code and /or state is transferred to the host machine whilst in strong mobility the agents code and execution state are sent to the host .
XML is one of the independent formats in which the agent state is saved so be transported and easily read by the host machine/node.
The agent-code is made available on both sides so that an agent process can be created on the destination platform, which is then initialized with the transferred agent state. This particular approach to weak migration is, for example, implemented in an extension of the Fipa-OS agent platform. [Groot et al, 1999]
This research identified two methods of agent migration which are used, the first being the process or code migration and code generation migration.
Process/code migration deals with migrating of the entire process (i.e. code and /or execution state) over the network to the node that the data is required from. Some Mobile agent programs employ this technique e.g. D’Agents and they seem to be the solution to the problem of migration of distributed mobile agents.
Process migration despite its best efforts lends itself better to migration within homogeneous environment. It is almost impossible to implement process migration without some level of homogeneity.
In summary the generative migration concept works by defining a structured agent behavior and functional into machine dependant syntax using a mechanism called an agent factory. This Blue print alone with the execution state of the agent is sent from the host machine to the host machine which should have its own agent factory that interprets it and transforms it using its class libraries to generate an executable code which is the distributed Agent. The Agent then reorients its self to its environment using its execution state and subsequently performs its predetermined task.
The Regenerative migration concept lend itself to many types of migration: Homogeneous migration, Cross platform migration which is migration of an agent from one agent platform to a different agent platform but with the same virtual environment , Heterogeneous migration where the agent migrates to a host with a different agent platform and different virtual environment and Agent regeneration migration which involves the migration of an agent to a different virtual target machine and hence require code regeneration maybe to a different executable[.Cofie,2006]
3.0 TRADITIONAL CLIENT SERVER PARADIGM VS. MOBILE AGENT PARADIGM
Having researched into the how both the of both the traditional client server design paradigm for Distributed systems and the agent migration design paradigm work ,this research paper goes on to discuss the relative weaknesses and strengths of both paradigms which is most appropriate for Distributed systems.
In this research it has being discovered that the agent migration paradigm work was developed because of the pitfalls of the Client Server paradigm.
Firstly the client server paradigm which is based on messaging uses up a lot of network bandwidth and causes network traffic and mobile agent paradigm solves this problem by using minimal number of messaging first message to migrate code and data and then second message to return the executed code and data to Server machine.
Secondly in the client server paradigm implementation of RPC (Remote procedure Call) in the event of a failure the client cannot distinguish between the message reply delay, a failure of the message to be retrieved or even network failure and hence cannot make an informed decision on resending the message. In instances where the request might just be retrieval of information resending a request is not a problem but in critical instances e.g. request to transfer ₤1000 from one account to another resending the request is not the best option.
The impetus for technologist and developers in developing the agent migration paradigm was primarily due to the network congestion caused by the messaging between client and server stub because in the mobile agent paradigm moves the code to the server. It has being found in this research the mobile agent paradigm decreases network traffic.
This research included a review of a research paper by D. Hagimort and L .Ismail titled A Performance Evaluation of the Mobile Agent Paradigm which uses two applications to compare the two paradigms.The experiment reviews issues of the two paradigms relating to
· Network Latency and Round Trip Time
· Transfer of huge data
· Tasks that involve complex computations to be performed on huge data sets
· Tasks that are inherently parallel and distributed in nature.
The experiment involved the use of Java runtime environment, Java based remote object invocation, Java based minimal platform to program agents and aglet()
The networks used were the:
- Workstations under Solaris, interconnected through a 10 Mbits Ethernet.
- Large scale network. It is composed of two comparable workstations interconnected through the Internet. The first machine is located in France (INRIA, Grenoble) and the second is located in United Kingdom (Queen Mary and Westfield College, London).
Java development kit 1.15 was used for all the experiments.
[Hagimont et al, 1999]
The First Experiment fetching a minimal amount of data
The first set of experiments using the RMI is below:
Culled from [Hagimont et al, 1999]
The experiment involving the Agent was a simple iterative to and fro migration
The agent size is 1475 bytes, including the code and
the data parts of the agent. The results is shown below
Culled from [Hagimont et al, 1999]
In this experiment the RMI outperforms the Agent by being faster at performing its set tasks.
The second Experiment varying the data to be retrieved
In this example in the server exports an interface that allows a client to fetch a copy of a document. The interested is in optimizing transfer for large documents using data compression [Culled from [Hagimont et al, 1999]
Culled from [Hagimont et al, 1999]
The graph below shows that with smaller document samples Remote Method Invocation is far more efficient in terms of time efficiency it then it begins to falter as the document size increases to Mobile agent paradigm.
4.0 CONCLUSION
This research has come to the conclusion though the mobile agent design paradigm was developed based on the short comings of client server design paradigm of network congestion and inability mobile agent paradigm is not the best distributed paradigm in all circumstances.
This research has brought the light the fact that there is no clear cut most efficient way of developing a distributed system.
The best paradigm has to be decided on a case by case basis that is the requirements of the distributed application to be developed .A distributed hypertext system and a data mining system have different data and network needs and hence have to be designed based on the volume of data that is to be retrieved and the volume of messaging that will be needed to retrieve the information needed. Efficiency and effectiveness in the context of this research paper is the time involved in completion of the computation task .The Client server paradigm after having being tested against the mobile agent paradigm is much more efficient when there is a minimal number of messaging between client and server and the volume of data to be transported is over 1000kilobytes .
Client server paradigm also lends it self better for use in homogeneous environment.
Mobile Agent are however much more efficient and effective with data intensive distributed system which require greater degree of messaging between the machines involved but are less conducive for use in a time critical distributed system.
The use of the mobile code paradigm reduces network traffic in a distributed although not necessarily making it faster.
Mobile Agent also lends it self better for use in heterogeneous environment.
I n conclusion mobile agent paradigm and traditional client server have their distinct characteristics and consequently the distributed systems they better suited for and hence there is no better paradigm but rather the best paradigm is based on the Distributed system to be developed.
Consequently this research end by pointing out the parameters that should aid any distributed system developer to choose the best paradigm for the application
Parameters to aid the choosing of the best paradigm to use.
- The timeliness over efficient network use
- Time critical ness of system
- Type of system heterogonous or homogeneous
- The volume of the Data that needs to be transferred.
- Complexity of distributed task.
BIBLIOGRAPHY
CARZANIGA ANTONIO,GIAN PIETRO PICCO ,GIOVANNI VIGNA, Designing Distributed Applications with Mobile Code Paradigms. International Conference on Software Engineering Proceedings of the 19th international conference on Software engineering, 1997, Boston, Massachusetts, United States , ACM Press New York, NY, USA. ACM Press New York, NY, USA
This paper primarily discusses the different design paradigms in distributed systems. It also discusses mobile code languages. The paper compare all the different paradigms concluded that there is no single best paradigm but the best paradigm is based on Distributed application needed.
COFIE ETHEL, 2006.Software Agents In Distributed System Environments .Brighton
This paper deals with Agents in distributed systems with particular attention to migration methods .This paper specifically compares the regenerative method and why it is a better method.
COULOURIS GEORGE, JEAN DOLLIMORE AND TIME KINDBERG,2001.United States of America :Pearson Education limited Distributed Systems concepts and design.3rd edition Pg1-25;
The authors define state their definition of a distributed system stating the real world examples of distributes system dwelling on and especially discussing the internet and why it is termed a distributed system. They authors end the chapter by discussing the major issues/challenges arising i.e. security, openness, mobile code, scalability, concurrency and fault handling.
COULOURIS GEORGE, JEAN DOLLIMORE AND TIME KINDBERG,2001.United States of America :Pearson Education limited Distributed Systems concepts and design.3rd edition Pg 29-62;
The authors discuss the architectural models of distributed systems starting with the software architecture/structures .Within the discussion on the software structures they described the platform and Middleware components their relation to a distributed system and their component functionality. They also enumerated the System architectures and their commonalities and differences. The chapter ended with the discussion of design requirements and interaction, failure and security
DC CENTRAL,2000. What is Distributed computing ?[online]. Thinkquest Team C007645 .Available at <URL: http://library.thinkquest.org/C007645/english/0-definition.htm > [Accessed November 2006]
The author launches straight into the need for distributed system with an exposition on a distributed system for analysing telescope data. Illustrations are used to simply explain a distributed systems advantages and disadvantages .The article ends with a description of alternative and forms of distributed system .Though the description of the forms of distributed system is centred on terminal systems.
DC Central,2000.[online] Thinkquest Team C007645 .Available at <URL: http://library.thinkquest.org/C007645/english/1-intro.htm >[Accessed November 2006]
A technical paper explaining how a distributed system works within a network, emphatically underlying premise that a network is the lifeline of a distributed system. The first part of focuses on an introduction to networks (hardware software components and types) and how they communication .In conclusion there is a focus on distributed communication and its methods, and information on parallel processing This article with simplified illustration simply explain the inner working of a distributed system.
TANEBAUM ANDREW S and MAATEN VAN STEEN,2002 Distributed Systems Principles and paradigms Pg 58-131
The authors describe communication in a distributed system with an exposition on the OSI model and its layers with a detailed explanation of how they work in synchronous and asynchronous modes. Using this background the authors ease into an explanation of distributed computing environment.
GODFREY BILL,2006. A primer on distributed computing [online]Available at <URL: http://www.bacchae.co.uk/docs/dist.html>> [Accessed November 2006]
This is a short non technical article on how distributed systems work practically and how to determine whether the task to be implemented actually requires distributed computing. The article concludes with an exposition of the securities needs of a distributed system and safeguards .An easily understandable explanation of distributed systems.
GOULD LAWRENCE S.. Sun’s Jini: Granting the Wish of Simplified Distributed Computing?.Automative design and production[Online]Available at <URL: http://www.autofieldguide.com/articles/069903.html >[Accessed November 2006]
The author uses the free ship software to show an example of a distributed system gone wrong. He then goes on to discuss the Jini a sun Microsystems inc platform which effectively enables dynamic object allocation/spontaneous networking using a lookup service .concluding the jinni biased article with a discussion on other platform for distributes application development and compares it with Jini.
GROOT, D.R.A., BRAZIER, F.M.T., AND OVEREINDER, B.J. (2004) , Cross-Platform Generative Agent Migration , In: Proceedings of the Fourth European Symposium on Intelligent Technologies, Hybrid Systems and their implementation on Smart Adaptive Systems , pp. 356-363 , June (EUNITE 2004, June 10-12, 2004, Aachen, Germany,
This paper is based on David de Groot’s Master’s thesis. It discusses the need for mobile agent and then going on the explain the difficulties mobile agent face in migration and the reasons why the cross platform generative migration of a better way of migrating agent
HAGIMONT DANIEL ,L. ISMAIL . A Performance Evaluation of the Mobile Agent Paradigm. Conference on Object Oriented Programming Systems Languages and Applications Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. 1999 . ACM Press New York, NY, USA . Denver, Colorado, United States . Pages: 306 – 313
This paper evaluates the different paradigms discusses the pitfalls and advatntages of each. The paper concluded by the observation of an experiment using java based system to test out which is the better distributed system design paradigm/
OTTE RANDY,PAUL PATRICK,MARK ROY,1996.New Jersey USA:Prentice Hall Inc. Understanding CORBA, pg 2-1 to 2-8
The authors give a simplistic view of CORBA and how it relates to distributed Systems
They give a conceptual overview of CORBA along with descriptions of its cardinal concepts and the technical aspect of how they partake in implementing the functionality of distributed system. It helps give a simplified view of CORBA.
SOARES PATRICIA GOMES ,November 1992, On Remote Procedure Call, Proceedings of the 1992 conference of the Centre for Advanced Studies on Collaborative research – Volume 2 CASCON , SESSION: Distributed systems – programming and management 1992, Toronto, Ontario, Canada ,IBM Press. Pages: 215 – 267
This paper discusses remote procedure calls dealing dealing with how they work generally and the concept behind RPC.It also discusses the pitfalls of the RPC paradigm ending with a discussion on the future of RPC.A good and insightful paper
VONDRAK CORY, 1997. Distributed Computing Environment Software Technology road map [online]. Redondo Beach CA: Carnegie Mellon University. Available at <URL:http://www.sei.cmu.edu/str/descriptions/dce.html> [Accessed November 2006]
Though this article outdated .it gives a good overview of the origin, purpose and technical details of the a distributed computing environment (dce)
With an illustration of the dce components it describes its services portability and suitability with examples of applications using dce’s.
The article concludes by lightly touching on the evolution of the dce its limitations and costs.
WIKIPEDIA,2006. Distributed computing [online] .Wikimedia Foundation, Inc .Available at <URL: http://en.wikipedia.org/wiki/Distributed_computing> [Accessed November 2006]
This article gives a general overview of a distributed system by defining a distributed system and how it related to parallel and cluster computing. It describes its goals stressing particularly on openness and scalability are examined .The advantages along with the drawbacks are also discussed. The author lightly touches on the architectural patterns of distributed system ending with an exposition on how distributed systems implement concurrency. The author also provides a good list of references for distributed systems.
Effectiveness and Suitability of Mobile Agents for Distributed Computing Applications
(Case studies on distributed sorting & searching using IBM . Aglets Workbench)
Ethelcofie's How To Articles 