Download A Parallel Processing Paradigm Utilizing Mobile Agents

A Mobile Agent System Built Upon Microsoft’s .NET Remoting
Framework
by Student B
University of Washington – Tacoma, Institute of Technology
Capstone Project Proposal for Masters Thesis in CSS
Thesis Committee Members: Dr. Jones
July 28, 2017
Abstract:
Mobile Agents are a fairly recent concept of having an autonomous piece of code (an agent) performing
work and having the ability to move to other systems across a network. Mobile Agents are becoming more
popular as the use of the Internet (and networking, in general) creates a suitable environment for mobile
agents to efficiently roam and perform essential processing.
This project seeks to create a mobile agent system utilizing the Microsoft.NET framework. I believe many
of the advances of the .NET framework allow for a mobile agent system with greater flexibility than
current implementations. A functional prototype of this system will be constructed. Also, an
implementation will be created to demonstrate the use of the system.
Page 1 of 11
Project Background
Microsoft .NET Framework
In 2001 Microsoft released its new development paradigm dubbed “.NET” (pronounced,
“dot net”). This initiative was very extensive and only a fraction will be covered here. In
short, the .NET framework strived for interoperability, flexibility, robustness, and
security. .NET code runs in a managed environment which performs features like
garbage collection, type checking, and code access security checks. Thus, .NETcompliant code is also called “Managed” code [1].
There are many .NET compilers in existence today (for example, C#, J#, Visual Basic,
C++, COBOL, FORTRAN, and more) allowing for a wealth of languages to be utilized.
Furthermore, units of code written in different languages can be fully interoperable if
they adhere to the Common Language Specification, CLS, which is an ECMA standard.
This CLS contains a common type system (CTS) which ensures this interoperability.
Thus, a class created in FORTRAN can be extended and used in C++.
Compilers generate files containing metadata and intermediate language (IL, or
sometimes MSIL or CIL) code. The metadata is a set of tables that allows for a detailed
accounting of the types (classes), methods, dependencies, etc. of the file created. The IL
is a stack-based language which will be further compiled into native code at runtime.
The main executable entity in .NET is the assembly. An assembly is a unit containing a
combination of metadata, IL, and resources. Typically, each assembly is compiled into a
single file but assemblies may be compiled into multiple files, if desired [2, 3].
Microsoft .NET Remoting
A subset of the functionality within the .NET framework is a suite of object remoting
technologies. These technologies enable distributed object usage in .NET. Before .NET,
the operating system process was the domain of the application. Everything executing in
a process had full access to the resources allocated to that process. In .NET, there is an
added concept of an application domain. An application domain is a logical space where
an application is ensured to run unhindered from another, provided both applications are
managed. Thus a physical operating system process can now host multiple application
domains, all free to execute (or crash) without affecting one another [3, 4].
Now here is where remoting comes in. Application domains are well bounded execution
contexts and there must be a structured and safe way to make object calls between them.
Remoting is the only way to make these calls between two application domains whether
they are in the same process or across the Internet. One of the benefits of the .NET
implementation (versus CORBA or RMI), is that the remoting architecture distances it
self from both the protocol it uses to communicate and even the format of the messages
sent between application domains. The .NET Framework ships with two
implementations of each. The shipped protocols are TCP and HTTP(S) and the message
formats are binary and SOAP. In keeping with extensibility, the architecture allows you
to define your own protocols and message formats. Thus, someone could create a
remoting application using SMTP. There are also many ways to place custom hooks into
Page 2 of 11
the communication process to do whatever may be needed (i.e. custom encryption of
data) [4].
Mobile Agents
Agents are a paradigm, based in artificial intelligence, which encapsulates code and data
into a single entity that is given some-level of autonomy within its defined environment.
A mobile agent has the added ability to transfer and be transferred to other environments
for continued execution. In this paradigm, a program is not tied to a particular process
and/or CPU any more [5-11]. The program literally moves to where the resources are
that it needs.
Mobile agents offer advantages over other distributed computing paradigms for some of
the following reasons:
 Reduced network traffic – Synchronous, blocking network IO calls consume
bandwidth to keep a connection alive. Many calls must be made as the processing
entity is distanced from where work needs to occur. An agent gets transferred to
the site of the resource that needs processing. This transfer is easy on the network
bandwidth and results in quicker processing as network latency will slow down a
process waiting for requests.
 Increased Robustness/Fault-Tolerant – In the case of sporadic network outages,
agents can seek refuge on reliable hosts and bide their time until they are able to
continue.
 Decentralized – Depending on the agent application architecture, the agents do
not need a centralized controlling entity. The agents can work autonomously to
perform the work needed. This autonomy can reduce synchronization steps which
are bottlenecks in any multi-threaded process.
Mobile Agents and Programming Languages
Currently, almost all mobile agent implementations utilize Java due to the introduction of
the Aglet API from IBM Japan. According to the creators of the aglet [6], the following
are advantages of using Java for mobile agents.
 Platform Independence – Java is abstracted from its environment via the Java
virtual machine. This provides a uniform environment for Java applications to
execute in.
 Secure Execution – Through its byte code verifier and Security Managers, Java
programs are protected from many types of attacks via buffer overruns or rogue
pointers.
 Dynamic Class Loading – An extensible way of loading classes at runtime,
providing unique namespaces to classes, ensuring safe and independent operation.
 Multithreaded – Since agents should behave autonomously, they should be able to
operate in parallel.
 Object Serialization – Java allows the serialization of objects into a binary format,
suitable for transfer across a network. This is vital as mobile agents are defined
by their ability to roam across a network.
Page 3 of 11

Reflection – Java has the ability to dynamically discover information such as
properties and methods about a class. This enables agents to be more flexible
about their environment.
They also specify some of the drawbacks of Java as follows.
 Inadequate Support for Resource Control – Java has no mechanism for regulating
the resource consumption of an object. For example, a denial of service attack
could flood a host and infinitely loop to consume CPU resources.
 No Protection of References – Anyone that has a reference to an agent can call its
public methods. There is no inherent way to regulate who can call these methods.
Aglets get around this by providing a proxy object.
 No Object Ownership of References – The garbage collector will not finally clean
up an object until there are no remaining references to it. Thus, if someone has a
reference to an agent, that agent’s object will not get removed from memory, even
if it has relocated to another host, against its will.
 No Support for the Preservation and Resumption of the Execution State – A Java
program does not have the ability to obtain its program counter and execution
stack. Thus, an agent can not truly preempt execution and resume elsewhere.
The agent will have to rely on internal mechanisms to track its state and progress.
So how does a .NET-compliant language match up?
 Platform Independence – The .NET framework provides an execution
environment, similar to the Java virtual machine, which provides an abstraction
from the hardware and operating system. Currently, the .NET runtime is only
supported on Microsoft Windows operating systems [12]. There are initiatives
underway to create .NET-compliant infrastructures on other operating systems
[13].
 Secure Execution – The .NET framework employs strict type checking and
verification to ensure that unsafe code is not loaded and executed. Although some
.NET languages (i.e. C# and C++) do allow some direct pointer manipulation,
these blocks of code must be decorated with the ‘unsafe’ keyword. The default
functionality is to not allow unsafe code to be executed and you have to explicitly
authorize a block of unsafe code to execute. In addition to type checking, .NET
inherently allows for strong naming of assemblies. Strong naming entails
generating a unique public-private key pair to digitally sign an assembly’s
contents. Thus, a signed assembly can not be run if tampered with. Although the
.NET runtime will allow unsigned (weak named) assemblies to run, it is easy to
reject calls from these assemblies [1].
 Dynamic Class Loading – The .NET runtime has a plethora of ways to
dynamically load assemblies (and classes) at runtime. You can load assemblies in
several ways. The .NET framework has a global assembly cache (GAC) where
strong-named assemblies can be installed and globally found on a system. There
is also a default probing path where the runtime will look for private (local)
assemblies by searching the file path located around the executing assembly.
Thirdly, you can specify a location, via a URL to load from a file or web location
directly.
Page 4 of 11







Multithreaded – The .NET framework has the ability to create threads and
contains a default implementation of a thread pool for each. Synchronization is
also fully supported and allows for many ways to do so: interlocked methods, the
‘lock’ keyword, etc.)
Object Serialization – Serialization is also fully supported and it gives much
greater flexibility than preceding frameworks. As mentioned before, the
serialization architecture comes with several serialization classes allowing
different serialization formats. The two shipped with the runtime are binary and
SOAP formatters. The serialization system is extensible so custom formatters can
be implemented as needed.
Reflection – A complete reflection API is a part of the .NET framework allowing
for enumeration of types, methods, attributes, and more from an assembly or
class. Another feature of the reflection API is the ability to emit (create)
assemblies and types programmatically.
Support for Resource Control – Via its ‘diagnostics’ namespace, .NET
applications have the ability to find out how the system is performing. It is
possible for a system to find out the percent of processor usage for a particular
thread. The caveat to this is that this feature must be supported by the underlying
operating system. (For example, Windows 95/98/ME do not support this
functionality.)
Object Reference Protection – Unlike Java, it is possible to determine the
assembly that is calling your method, as well as the principal calling your method.
The assembly has an ‘evidence’ property which gives security information about
the assembly. Thus an object’s constructor can ensure that 1) the calling
assembly is strong-named, and 2) the calling assembly is trusted based on the
assembly’s evidence.
Object Reference Ownership – The managed .NET runtime performs garbage
collecting just as the Java runtime does. Thus, the same problem arises about an
object’s lifetime being regulated by anyone still having a reference. Unlike Java,
though, this is not as serious an issue since you can enforce reference protection.
Preservation and Resumption of the Execution State – As with Java, the .NET
runtime does not expose information of this kind to the application due to the
security and stability implications. Therefore, a .NET agent will also need to
manage its execution state itself.
Proposed Implementation
Overview
At this point in the plan, the mobile agent system will contain three major entities: the
agent, the host, and the registry. The agent is the mobile entity performing the task(s)
assigned to it. It is the worker bee, designed by the software engineer to perform
application-specific logic. The host is the entity that facilitates the execution and runtime
contexts for the agents. The registry serves as a host locator and allows agents and hosts
to communicate with and find each other. Each of these entities is further described
below.
Page 5 of 11
Agent Registry
An agent registry will be located at a well-known location so that all hosts, agents, and
miscellaneous clients can query it. The registry is an optional part of the system that will
contain information about hosts and agents, returning location and communication
information for each, in response to queries received. The registry can also optionally
contain custom host information to enable agents to make informed decisions on what
hosts can best suit their purposes. Host information can include, but is not limited to,
performance statistics and resource accessibility. (For example, host X might be a data
server whose services are needed by certain agent applications).
Agents and hosts who require the registry for operations are abstracted away from the
details to allow for many registry implementations. For example, a registry interface will
be defined allowing use of a registry service, but the implementation of that service could
be a remote web service, an LDAP container, or a database. The implementation chosen
depends on the needs of the agent application created. For enterprise scenarios, an LDAP
or database might be most efficient. For Internet scenarios, a web service will be most
accessible and would scale better.
Agent Host
The host service will be responsible for maintaining and facilitating the runtime contexts
of agents. The host service will maintain separate contexts for different agent
types/applications to increase robustness. The host itself will remain in a separate context
to eliminate the possibility of crashing due to buggy or hostile agents. This service will
be able to run agents previously unknown to it via dynamic loading of agent code
libraries. The host will have the ability to be exposed through various protocols using
various message formats. The host will also optionally query statistics of its execution
environment and report these to the registry service. Some of these statistics will include
performance-related information, the ids of agents currently being hosted, and more. The
host will provide all of the hooks needed by the agent to maintain its lifetime, to
communicate with intra-host and inter-host agents, and to access resources.
The host should also be responsible for the security of the system (although this feature
may not be fully implemented in this prototype) [2, 3, 14]. The security of the host
operates on many levels. An agent should not be allowed to access certain resources on
the host system (i.e., random files on the system, registry access (for Windows
machines), creating sockets and other communications of its own. The host should not
allow weak-named assemblies to make requests of it or of any agents it contains.
Agent
Apart from the base definition of an agent (described below), the agent will be
constructed as the agent application designer/architect sees fit. This architect will design
the agent in a manner suited to the application and can vary greatly from one
implementation to another. The only limitation is that of the .NET framework itself and
the restricted permissions of the host it executes in.
Page 6 of 11
The base functionality of an agent is as follows. It will have the ability to be remoted (or
remote itself) to a host. It will be able to query the local host and the registry for
information about the mobile agent system. The agent will have the ability to
communicate with other agents of the same type (within the same application) via
multicast and unicast protocols [5]. An agent will be able to be cloned, dehydrated
(persisted to secondary storage) and re-hydrated (restored from a persisted state).
Sample Implementation
Once the agent system has been prototyped a sample diagnostic application will be
created. This application’s agents will roam all hosts available to it and query the hosts
to determine the health or status of the systems. This sample application will retrieve
diagnostic information and return it to a common location for operations support. This
task is a good example of where mobile agents will be beneficial.
A fictional scenario of the usefulness of this application is as follows. A person in
operations could send out one or more agents to determine several characteristics of a
system. Such characteristics could be the operating system version, service packs
applied, hardware on the box, software installed on the system, etc. If this task was done
in a typical distributed scenario, much network bandwidth would be used in transferring
not only the data resulting from the task’s query, but all of the procedure calls necessary
to get the information. An agent will be transferred once and then the data will be
returned. This minimizes network traffic. Also, if there are many systems on a corporate
network, this task could take days with a normal distributed computing paradigm. A
single machine (or maybe even a small cluster of machines) would be making
synchronous, blocking calls to each system the operations group desired to query. In the
mobile agent scenario, the processor of each system is used instead of a central machine
and the processing executes in parallel. This is a simple example of how mobile agents
can be a much more powerful tool than typical distributed computing mechanisms.
Written Deliverables
At the successful completion of this project, the following written materials will be
submitted for final review.
A full write-up of what was technically achieved in this project and how it was
accomplished will be delivered. This will also include operational and installation
specifications of the system created so that future students, if desired, could use or build
upon this framework. The write-up will also include the implications of this work, what
was novel about this work, and what future work on this topic would look like.
A supplementary, perhaps as appendices to the afore-mentioned write-up, containing all
source code, installation scripts, and other misc. documentation will be included among
the written materials.
Page 7 of 11
Finally, an electronic copy of all software created (binaries and source) will be left with
my Graduate Advisor. An electronic copy of all written materials will also be made
available.
Oral Deliverables
Informal oral reports (updates) to my committee will be given as requested by committee
members or myself.
At the completion of this project, an oral presentation of this project will be given at the
departmental colloquium at quarter’s end. The date and time of this presentation will be
determined at a later time.
Education Statement
How will this project draw upon your coursework?
This project draws upon many subjects that I have met in my coursework. TCSS 435 –
Artificial Intelligence introduced the concepts of agents. TCSS 558 – Distributed
Computing introduced the notion of a mobile agent as well as supplementing the
distributed computing background I already had.
This project is a continuation and culmination of the coursework I have been matriculated
in during my attendance of this Masters program.
What will be researched and/or learned to make this a successful project?
My primary focus in research will be to review and understand what currently exists in
mobile agent architectures and how to improve upon this. Specifically, I will be
researching the Aglet model from IBM, Japan as it has been successfully implemented
and used for years.
Once I better understand a mobile agent paradigm, I then need to research how this can
best be implemented on Microsoft Windows using the .NET Framework and its
contained remoting technologies. Along with implementation, I will need to learn how to
deploy this system in an easy fashion so that it may be a useful tool for future UWTacoma students.
Page 8 of 11
Timeline and Milestones
February 25th, 2004 – Have final proposal submitted to thesis committee.
February 26th to March 7th – Register for 5 credits of capstone project.
March 29th – Spring term officially begins:
WEEK OF
March 29th
April 5th
TASK(S)
Research current mobile agent
architectures.
Same as above.
April 12th
Plan\model agent registry interface.
April 19th
April 26th
Plan\model agent host.
Same as above.
May 3rd
May 10th
Plan\model agent
Same as above.
May 17th
May 24th
Plan\model agent-host and agent-registry
interactions.
Same as above.
May 31st
Plan\model host-registry
DELIVERABLE(S)
A feature list for the mobile
agent system to be
designed.
A list of registry features
(methods & attributes).
A list of host features
(methods & attributes).
A list of agent features
(methods & attributes).
Interaction diagram(s).
Possibly modified versions
of previous deliverables.
Interaction diagram(s).
Possible modified versions
of previous deliverables.
April 19th to May 26th – Register for 5 credits of capstone project.
June 21st – Summer term officially begins:
WEEK OF
June 21st
June 28th
July 5th
July 12th
July 19th
July 26th
TASK(S)
Code host
Code host
Code agent
Code registry
Test & debug system
Plan diagnostic sample application.
August 2nd
Code sample application.
Page 9 of 11
DELIVERABLE(S)
Appropriate application
documentation (diagrams,
specs, etc.)
August 9th
Execute sample application.
August 16th
Prepare for colloquium and submission of
final write-up and deliverables.
Same as above.
Same as above.
August 23rd
August 30th
Report(s) on execution
statistics.
Pre-August 20th – Sign up for colloquium talk. Once it is scheduled.
TBD – Give colloquium presentation. Date and time will be determined later.
Page 10 of 11
Related Work
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
A. Troelsen, C# and the .NET Platform, First ed. New York: Apress, 2001.
J. Richter, Programming Applications for Microsoft Windows, Fourth ed.
Redmond: Microsoft Press, 1999.
J. Richter, Applied Microsoft .Net Framework Programming, First ed.
Redmond: Microsoft Press, 2002.
Developing XML Web Services and Server Component with Microsoft Visual
Basic.NET and Microsoft Visual C#.NET. Redmond: Microsoft Press, 2003.
M. L. Liu, Distributed Computing: Principles and Applications: Pearson
Addison Wesley, 2003.
D. B. Lange and M. Oshima, Programming and Deploying Java Mobile Agents
with Aglets, First ed: Addison-Wesley, 1998.
S. J. Russell, Artificial intelligence : a modern approach / Stuart J. Russell and
Peter Norvig ; contributing writers, John F. Canny ... [et al.], 2nd ed ed. Upper
Saddle River, N.J. :: Prentice Hall,, c2003.
D. Milojicic, F. Douglis, and J. Wheeler, Mobiliy: Processes, Computers, and
Agents, First ed: Addison-Wesley, 1999.
M. A. R. Dantas, J. G. R. C. Lopes, and T. G. Ramos, "An enhanced
scheduling approach in a distributed parallel environment using mobile
agents," presented at High Performance Computing Systems and
Applications, 2002. Proceedings. 16th Annual International Symposium on,
2002.
J. Cao, L. Zhang, X. Feng, and S. K. Das, "Path compression in forwardingbased reliable mobile agent communications," presented at Parallel
Processing, 2003. Proceedings. 2003 International Conference on, 2003.
J. Cao, X. Wang, and S. K. Das, "A framework of using cooperating mobile
agents to achieve load sharing in distributed Web server groups," presented
at Algorithms and Architectures for Parallel Processing, 2002. Proceedings.
Fifth International Conference on, 2002.
".NET Framework System Requirements."
http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA7462-47D0-8E56-8DD34C6292F0&displaylang=en, "Common Language
Infrastructure Source Listing."
K. Brown, Programming Windows Security, First ed. Boston: AddisionWesley, 2000.
Page 11 of 11