Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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