The Role of Java in InfoSleuth Agent-based Exploitation of Heterogeneous Information Resour
javaagent javassist方法记述
javaagent javassist方法记述（实用版3篇）目录（篇1）1.JavaAgent 简介2.Javassist 简介3.JavaAgent 中的 Javassist 方法4.示例：使用 JavaAgent 和 Javassist 实现方法拦截正文（篇1）1.JavaAgent 简介JavaAgent 是一种 Java 字节码生成技术，可以在运行时动态生成、修改或替换 Java 类的字节码。
这使得开发者可以在不修改原始源代码的情况下，对 Java 类进行增强或修改其行为。
JavaAgent 通常与 Java 类加载器（ClassLoader）一起工作，以便在类加载过程中对类进行定制。
2.Javassist 简介Javassist（Java Assistant）是一个开源的 Java 字节码生成库，它提供了简单易用的 API，让开发者可以方便地生成、修改和解析 Java 字节码。
Javassist 支持许多字节码操作，例如添加、删除或修改类、方法、字段等。
3.JavaAgent 中的 Javassist 方法在 JavaAgent 中，可以使用 Javassist API 来实现对 Java 类和方法的定制。
以下是一些常用的 Javassist 方法：- CGenProxy.getProxyMethod：用于获取代理对象的某个方法的代理实现。
- CGenProxy.setInterceptor：用于设置方法拦截器，可以在方法执行前或执行后执行自定义代码。
- CMethodInterceptor.intercept：方法拦截器的核心实现，可以在方法执行前或执行后执行自定义代码。
4.示例：使用 JavaAgent 和 Javassist 实现方法拦截以下是一个简单的示例，展示了如何使用 JavaAgent 和 Javassist 实现方法拦截：```java// 1.创建一个 JavaAgent 对象JavaAgent agent = new JavaAgent();// 2.设置代理目标类agent.setTarget("java.util.ArrayList");// 3.创建一个方法拦截器class MethodInterceptor implements CMethodInterceptor {@Overridepublic void intercept(MethodInterceptor.MethodInfo methodInfo) {System.out.println("Before method execution");// 在这里编写方法执行前的自定义代码System.out.println("After method execution");// 在这里编写方法执行后的自定义代码}}// 4.设置方法拦截器agent.setInterceptor(new MethodInterceptor());// 5.启动 JavaAgentagent.start();```在这个示例中，我们使用 JavaAgent 和 Javassist 实现了对ArrayList 类的方法拦截。
Java技术专题-探针Agent底层运作原理和分析(2)
Java技术专题-探针Agent底层运作原理和分析（2）JavaAgent启动时加载的 JavaAgent 是 JDK1.5 之后引入的新特性，此特性为用户提供了在 JVM 将字节码文件读入内存之后，JVM 使用对应的字节流在 Java堆中生成一个 Class 对象之前，用户可以对其字节码进行修改的能力，从而JVM也将会使用用户修改过之后的字节码进行 Class 对象的创建。
JVM Tool Interface•JVMTI 是 JVM 暴露出来的一些供用户进行自定义扩展的接口集合，每当 jvm 执行到一些特定的逻辑的时间，就会去进行触发这些回调接口，用户就恰好可以在此回调接口之中做一些自定义逻辑。
•而对于此次所要描述的 JavaAgent 也恰恰是基于 JVMTI 的，JPLISAgent 就是用作实现 javaagent 功能的动态库。
JPLISAgentJPLISAgent 实现了 Agent_OnLoad 方法，Agent_OnLoad 方法就是整个启动时加载的 JavaAgent 的入口方法，后续也会说明整个运行流程。
如何使用虽然大多数同学可能已经使用过 JavaAgent 了，但是为了下面原理的平滑过渡，我这里还是大概写一下使用：编写 premain 启动类编写一个含有以下 premain 函数的类public static void premain(String agentArgs, Instrumentation instrumentation);[1] p ublic static void premain(String agentArgs);[2]•上面的两个方法只需要实现一个即可，且 [1] 的优先级是高于 [2] 的，即如果上面的两个方法同时出现，则只会执行 [1] 方法。
•agentArgs是javaagent:xx.jar=yyy传入yyy字符串是ng.instrument.Instrumentation 实例，由本地方法实例化并由 jvm自动传入。
javaagent参数用途
javaagent参数用途JavaAgent是Java虚拟机（JVM）的一种特殊参数，它可以在运行时修改、增强或监控Java应用程序。
本文将介绍JavaAgent的用途以及它在不同场景下的应用。
一、什么是JavaAgent？JavaAgent是一种在JVM启动时通过"-javaagent"参数加载的特殊Java程序。
它可以在应用程序启动之前或之后，通过字节码转换技术来修改或增强应用程序的行为。
JavaAgent可以访问应用程序的字节码，并在运行时对其进行修改，从而实现对应用程序的增强或监控。
二、JavaAgent的用途1. 性能监控和调优JavaAgent可以监控应用程序的性能指标，如CPU利用率、内存使用情况、线程状态等。
通过收集这些数据，开发人员可以深入了解应用程序的性能瓶颈，从而进行调优和优化。
2. 日志记录和跟踪JavaAgent可以拦截应用程序的方法调用，并记录相关的日志信息。
这对于排查应用程序的问题和调试非常有帮助。
开发人员可以在方法执行前后插入自定义的逻辑，记录方法的输入参数和返回值，或者记录方法的执行时间等信息，从而实现对应用程序的详细跟踪和分析。
3. 安全检查和控制通过JavaAgent，可以在应用程序运行时对代码进行安全检查和控制。
例如，可以通过JavaAgent拦截敏感方法的调用，并进行权限校验，确保只有具备相应权限的用户才能执行该方法。
4. AOP（面向切面编程）JavaAgent可以实现AOP编程，通过在运行时修改字节码来实现对应用程序的切面增强。
AOP是一种常用的编程范式，可以将一些通用的横切逻辑（如日志记录、事务管理等）与业务逻辑解耦，提高代码的重用性和可维护性。
5. 动态加载类和修改类JavaAgent可以在应用程序运行时动态加载类，并修改类的字节码。
这为应用程序的扩展和动态更新提供了可能性。
通过JavaAgent，可以在不重启应用程序的情况下，动态地加载新类、修改现有类的行为，从而实现应用程序的灵活性和可扩展性。
java agent原理完全解读
Java Agent原理完全解读一、Java Agent的概念在Java编程中，我们经常会听到Java Agent这个词，但是对于它的概念和原理，很多人可能并不是很清楚。
所以在本文中，我们将对Java Agent的概念进行深入解读，希望能够帮助大家更好地理解和使用Java Agent。
1. Java Agent是什么？Java Agent是一种可以动态地为Java应用程序添加功能和修改行为的一种技术。
它可以在Java应用程序运行的过程中，通过某种方式注入到Java虚拟机中，然后对Java应用程序进行监控、诊断和修改。
通过Java Agent，我们可以在不修改应用程序源代码的情况下，实现一些特定的功能，比如性能监控、代码注入、动态修改类等。
2. Java Agent的作用Java Agent可以被用于很多方面，比如性能监控、代码调试、AOP编程、代码注入等。
它可以帮助开发人员更好地理解和掌握Java应用程序的运行状态，从而更好地进行性能优化、问题定位和功能扩展。
3. Java Agent的原理Java Agent的实现原理主要是通过Java虚拟机提供的Instrumentation API来实现的。
通过Instrumentation API，我们可以在类加载的过程中动态地修改类的字节码，从而实现一些特定的功能。
Java Agent在启动时会被加载到Java虚拟机中，并通过Instrumentation API对目标应用程序进行修改和监控。
二、Java Agent的实现方式Java Agent的实现方式主要分为两种：基于Java代理机制和基于字节码工具。
1. 基于Java代理机制的实现方式基于Java代理机制的实现方式是通过ng.instrument包提供的Instrumentation API来实现的。
开发人员可以通过实现一个代理工具类，然后在启动Java应用程序时，通过-javaagent参数指定代理工具类的jar包，从而实现对目标应用程序的监控和修改。
java -javaagent 用法
java -javaagent 用法Java 中的-javaagent选项用于指定Java 虚拟机(JVM) 启动时加载的代理(agent)。
代理是一种能够在运行时修改或监视类的工具，通常用于执行字节码增强、性能监控、代码注入等任务。
使用-javaagent选项，可以在应用程序启动时将代理嵌入到JVM 中，从而实现对类加载和字节码的操控。
1. -javaagent选项的基本语法-javaagent选项的基本语法如下：bashjava -javaagent:<agent-jar>[=<options>] -jar<your-application.jar>其中：•<agent-jar>是代理JAR 文件的路径。
•<options>是传递给代理的参数，通常使用等号(=) 连接。
2. 代理JAR 文件的结构代理JAR 文件通常包含一个名为premain或agentmain的方法，这些方法会在JVM 启动时被调用。
premain方法用于在主类加载之前被调用，而agentmain方法用于在运行时动态加载代理。
以下是一个简单的代理类的示例：javaimport ng.instrument.Instrumentation;public class MyAgent {public static void premain(String agentArgs,Instrumentation inst){// 在主类加载之前执行的代码}public static void agentmain(String agentArgs,Instrumentation inst){// 在运行时动态加载代理时执行的代码}}3. 代理的应用场景3.1 字节码增强通过-javaagent可以实现对类字节码的增强，例如在方法前后插入日志、修改类的行为等。
字节码增强工具如Byte Buddy、ASM 等常用于这一目的。
java agent机制
java agent机制Java Agent机制是Java编程语言中的一项功能，它允许开发人员在运行时修改和增强Java应用程序的行为。
本文将介绍Java Agent机制的原理和使用方法，以及它在实际应用中的一些常见场景和优势。
一、Java Agent机制的原理Java Agent机制是通过Java虚拟机（JVM）中的Instrumentation API实现的。
该API允许开发人员在应用程序加载到JVM之前修改字节码，从而实现对应用程序的增强和修改。
具体来说，Java Agent机制的工作流程如下：1. 开发人员编写一个Java Agent程序，该程序包含一个Agent类和一个Agentmain方法。
2. 通过Java命令的-javaagent参数将Java Agent程序指定为应用程序的代理。
3. JVM在启动应用程序时，会自动加载Java Agent程序，并调用Agentmain方法。
4. 在Agentmain方法中，开发人员可以使用Instrumentation API对应用程序的字节码进行修改和增强。
5. 修改后的字节码会被重新加载到JVM中，从而实现对应用程序的增强和修改。
二、Java Agent机制的使用方法要使用Java Agent机制，开发人员需要按照以下步骤进行操作：1. 编写Agent类和Agentmain方法，实现对应用程序的增强和修改逻辑。
2. 将Agent类打包成一个独立的Jar文件。
3. 在运行Java应用程序时，使用-javaagent参数指定Agent Jar 文件的路径。
例如，假设我们编写了一个名为MyAgent的Java Agent程序，将其打包为MyAgent.jar。
要在命令行中运行一个名为MyApplication的Java应用程序，并使用MyAgent对其进行增强，可以使用以下命令：java -javaagent:MyAgent.jar MyApplication三、Java Agent机制的应用场景Java Agent机制可以应用于多种场景，以下是一些常见的应用场景：1. 性能分析和调优：通过在应用程序的关键代码部分插入性能监控逻辑，可以实时监测应用程序的性能指标，并进行调优。
java agent原理
java agent原理JavaAgentJava拟机（JVM）上的一个重要组件，它是一种灵活的工具，可以插入到 JVM 中，以实现非常有用的任务。
虽然它是一种基本的组件，但它的功能却是非常强大和多样的，它可以用于收集一些有用的数据，并将其持久化到线上或线下，以改善 Java用性能和可靠性。
Java Agent基本原理是，它会在 Java序的类加载期间插入到JVM 中，在类加载后，它可以通过 Java拟机的特定的帧来访问 Java 法的属性和参数，它可以对方法的执行进行拦截，对其进行监控和跟踪，并在方法执行前进行性能测试，从而使系统更加高效。
此外，Java Agent可以用于实现执行代理，可以通过代理来替换方法的具体实现，以达到优化系统性能的目的。
Java Agent一些重要的特性包括：（1）性能分析：Java Agent以通过插入方法帧来对 Java法进行性能分析，可以测量每个方法的执行时间，从而可以将系统的性能瓶颈排查出来。
（2）性能优化：Java Agent可以用于提升应用性能，可以实现用 Java 代码替换原有的方法实现，比如，可以使用缓存或其他技术来优化查询等，使系统达到最优性能。
（3）调试和监控：Java Agent可以用于调试和监控，可以收集应用程序运行期间的相关数据，绘制应用性能图表，可以进行性能监控和错误跟踪，从而可以及早发现问题，提升应用程序的可靠性和可用性。
（4）基于策略的数据收集：Java Agent以使用特定的策略来获取 Java用程序中的一些重要数据，比如 HTTP求和日志等，以及一些其他的数据，并将这些数据持久化到线上或线下，以便做后续的分析。
以上就是 Java Agent本原理的概述。
Java Agent 以独特的方式提升了 Java用程序的性能和可靠性，它可以在 Java序运行期间收集有用的数据，进行性能分析和优化，并可以进行调试和监控，从而可以及早发现问题，提升应用程序的可靠性和可用性。
Java Agent 探针的技术介绍
Java Agent 探针的技术介绍前提概要•Java 调式、热部署、JVM 背后的支持者 Java Agent：o各个 Java IDE 的调试功能，例如 eclipse、IntelliJ ；o热部署功能，例如 JRebel、XRebel、spring-loaded；o各种线上诊断工具，例如 Btrace、Greys，还有阿里的 Arthas；o各种性能分析工具，例如 Visual VM、JConsole 等；Agent 的介绍Java Agent 直译过来叫做 Java 代理，还有另一种称呼叫做 Java 探针。
首先说Java Agent 是一个 jar 包，只不过这个 jar 包不能独立运行，它需要依附到我们的目标 JVM 进程中。
我们来理解一下这两种叫法。
•代理：比方说我们需要了解目标 JVM 的一些运行指标，我们可以通过Java Agent 来实现，这样看来它就是一个代理的效果，我们最后拿到的指标是目标 JVM , 但是我们是通过 Java Agent 来获取的，对于目标 JVM 来说，它就像是一个代理；•探针：这个说法我感觉非常形象，JVM 一旦跑起来，对于外界来说，它就是一个黑盒。
而 Java Agent 可以像一支针一样插到 JVM 内部，探到我们想要的东西，并且可以注入东西进去。
o拿 IDEA 调试器来说吧，当开启调试功能后，在 debugger 面板中可以看到当前上下文变量的结构和内容，还可以在 watches 面板中运行一些简单的代码，比如取值赋值等操作。
o还有 Btrace、Arthas 这些线上排查问题的工具，比方说有接口没有按预期的返回结果，但日志又没有错误。
这时，我们只要清楚方法的所在包名、类名、方法名等，不用修改部署服务，就能查到调用的参数、返回值、异常等信息。
o上面只是说到了探测的功能，而热部署功能那就不仅仅是探测这么简单了。
热部署的意思就是说再不重启服务的情况下，保证最新的代码逻辑在服务生效。
恩士迅java面试英文题
恩士迅java面试英文题Enson Java Interview English Questions1. What is Java?Java is a high-level, object-oriented programming language developed by Sun Microsystems (now owned by Oracle) in 1995. It is known for its platform independence, which means that Java programs can run on any device or operating system that has a Java Virtual Machine (JVM). Java is widely used for creating web applications, mobile applications, desktop software, and enterprise solutions.2. What are the main features of Java?Java has several key features that make it popular among developers:- Object-oriented: Java follows the principles ofobject-oriented programming (OOP), allowing developers to create reusable and modular code.- Platform independence: Java's 'write once, run anywhere' approach allows programs to be run on any device with a JVM, making it highly portable.- Memory management: Java uses automatic garbage collection, freeing developers from managing memory manually. - Multi-threading: Java supports concurrent programmingwith its built-in support for threads, allowing multiple tasks to run simultaneously.- Security: Java provides a secure environment with its built-in security features, such as sandboxing and permission-based access control.3. What is the difference between JDK and JVM?JDK (Java Development Kit) and JVM (Java Virtual Machine) are both essential components of the Java platform, but they serve different purposes.- JDK: JDK is a software development kit that provides tools and libraries necessary for Java development. It includes the Java compiler, debugger, and other utilities required to write, compile, and run Java programs.- JVM: JVM is a runtime environment that executes Java bytecode. It interprets the compiled Java code and converts it into machine code that can be understood by the underlying operating system. JVM also handles memory management and provides various runtime services.4. What is the difference between an abstract class and an interface?- Abstract class: An abstract class is a class that cannot be instantiated and is typically used as a base class for otherclasses. It can contain both abstract and non-abstract methods. Subclasses of an abstract class must implement its abstract methods. An abstract class can also have fields and constructors.- Interface: An interface is a collection of abstract methods and constants. It cannot be instantiated and is used to define a contract for implementing classes. A class can implement multiple interfaces, but it can only extend a single class. Interfaces are used to achieve multiple inheritance in Java.5. What are the different types of exceptions in Java? Java has two types of exceptions: checked exceptions and unchecked exceptions.- Checked exceptions: These are exceptions that are checked at compile-time. The developer must either handle these exceptions using try-catch blocks or declare them in the method signature using the 'throws' keyword. Examples of checked exceptions include IOException and SQLException.- Unchecked exceptions: These are exceptions that are not checked at compile-time. They are subclasses of RuntimeException and Error classes. Unchecked exceptions do not need to be declared or caught explicitly. Examples ofunchecked exceptions include NullPointerException and ArrayIndexOutOfBoundsException.These are just a few sample questions that can be asked during a Java interview. It is important to remember that the depth and complexity of questions may vary depending on the level of the position being applied for. It is advisable to thoroughly prepare and revise various topics related to Java programming to increase the chances of success in a Java interview.。
An agent-based intelligent environmental monitoring system
An agent-based intelligent environmental monitoring system Ioannis N. Athanasiadis and Pericles A. Mitkas ABSTRACT Fairly rapid environmen al changes call for con inuous surveillance and on -line decision-making. Two areas where IT technologies can be valuable. In this paper we present a multi -agent system for monitoring and assessing air-quality attributes, which uses data coming from a met eorological st at ion. A communit y of soft ware agent s is assigned o moni or and valida e measuremen s coming from several sensors, t o assess air-quality, and, finally, to fire alarms to appropriate recipients, when needed. Da t a mining t echniques have been used for adding da t a-driven, cus t omized in t elligence in t o agen t s. The archi t ec t ure of t he developed sys t em, i ts domain ont ology, and t ypical agent int eract ions are present ed. Finally, t he deployment of a real-world test case is demonstrated.Keywords : Mult i -Agent Syst ems, Int elligent Applicat ions, Dat a Mining, Induct iveAgents, Air-Quality MonitoringIntroductionEnvironmental Information Systems (EIS) is a generic term that describes the class of systems that perform one or more of the following tasks: environmental monitoring, dat a st orage and access, disast er descript ion and response, environment al report ing, planning and simulat ion, modeling and decision -making. As t he requirement s for accura t e and t imely informa t ion in t hese sys t ems are increasing, t he need for incorpora t ing advanced, in t elligen t fea t ures in EIS is revealed. In t his con t ex t advances in Informa t ion Technology (IT) sec or are promising o sa isfy hese requirements. Enviromatics (an abbreviation of the term “environmental informatics”) is t he research init iat ive examining t he applicat ion of Informat ion Technology in environmen t al research, moni t oring, assessmen t , managemen t, and policy (IFIP 1999).In Management of Environmental Quality,An International Journal vol.15,no.3,pp.238-249,2004.Emerald Publishers.The deploymen t of modern, in t elligen t sys t ems for moni t oring and evalua t ing me t eorological da t a series and assessing air quali t y is only one of several enviromat ics applicat ions. Our focus in t his work is t o take advantage of powerful tools for software development and demonstrate their application for monitoring air-quality attributes.Air Qualit y Operat ional Cent ers (AQOC) have been est ablished worldwide in areas wi h po en ial air pollu ion problems. Their responsibili t y is t o moni t or cri t ical atmospheric variables and publish regularly their analysis results. Currently, real -time decisions are made by human experts, whereas mathematical models are used for off-line study and understanding of the atmospheric phenomena involved. For example, in the London Air Quali y Ne work (h p:///london/) flexible da t aanalysis is support ed t hrough st at ist ical t ools and in t he Texas Nat ural Resource Conserva t ion Commission (h t t p://www.t nrcc.s t a t e.t ), me t eorologis t s se t t he criteria for making predictions.Several Environmental Monitoring Information Systems (EMIS) have been developedworldwide for assist ing environment alist s in t heir t asks. These syst ems vary from platforms for integrating heterogen eous data sources, to real -time monitoring systems. For example, the New Zealand Distributed Information System (NZDIS) is an agent -based archit ect ure for int egrat ing environment al informat ion syst ems (Purvis et al. 2003). Similarly, t he InfoSleuth project used agen t s for querying dis t ribu t ed environmental data-clusters in a transparent way (Nodine et al. 2000) and Java Agents for Monitoring and Management use a collection of software agents that can perform various administ rat ive t asks in a monit oring net work (Tierney et al. 2000). Ot her approaches t owards EMIS include t he Knowledge-based Environmental Data Analysis Assistant project , which provides an interface between the user and off-the-shelf analysis packages for off-line st udy (Fine 1998) and DNEMO , a mult i -agent syst em for managing air qualit y in real -t ime (Kalapanidas & Avouris 2002). These systems incorporate domain knowledge and their reasoning capabilities are deployed in the form of expert systems, case-based reasoning, or knowledge bases.The system described in this paper, adapts a different approach since it employs data mining t echniques for adding cust omized int elligence int o an EMIS. The syst em,called O 3RTAA, is developed as a mult i -agent syst em. Several soft ware agent s co–operate in a distributed agent society, in order to monitor both meteorological and air–pollut ant s at ribut es in an effort t o evaluat e air qualit y and, ult imat ely, t o t rigger alarms.O 3RTAA relies on the Agent Paradigm for building intelligent software applications, while t aking advan t age of Machine Learning algori t hms and Data Mining met hodologies for ext ract ing knowledge. The implement ed syst em is equipped wit h powerful, advanced feat ures, such as measurement validat ion, missing measurement estimation and custom alarm i d entification, while it also performs more rudimentary tasks, such as data monitoring, storage, and access.The approachThe sys t em developed, improves exis t ing environmen t al moni t oring sys t ems by adding custom ized intelligence int o t heir modules. Our approach is t o couple t he software agent paradigm with the knowledge discovery roadmap, in order to provide Intelligent Environmental Software Applications. This approach has been enabled by the use of Agent Academy, an integrated platform for creating intelligent agents, with training and retraining capabilities. (Agent Academy Consortium 2000)According to the software agent paradigm (Jennings et al. 1998), agents in our system are aut onomous problem-solvers t hat co-operat e t o achieve t he overall goals of the syst em. Thus, cert ain syst em goals are assigned t o specific agent s. Advanced t asks, such as incoming measuremen t valida t ion or cus t om alarm iden t ifica tion, are performed with the use of decision models discovered using data mining algorithms.In general, the knowledge discovery roadmap is used for identifying useful patterns in vast volumes of dat a. In t he case of environment al syst ems, t here is cert ainly an abundance of data. In our approach, interesting patterns hidden in environmental data sets are discovered and subsequently embedded into our system, essentially adapting the problem-solving method to local conditions. As a consequence, decision -making is performed more accurat ely since t he charact erist ics of t he problem at hand may differ from general trends or ‘rules of thumb’.In t he following sect ions t he approach for developing an agent -based environmental moni t oring sys t em is described. The sys t em’s func t ionali t y and archi t ec ture are detailed and deployment steps are outlined.Functional DescriptionThe overall goal of O 3RTAA is o moni or air-qualit y dat a, including pollut ant s’ dist ribut ions, measured by a single met eorological st at ion. Current ly, t he st at ion’s field sensors measure these attributes and human experts are responsible for assessing these measurements and identifying possible alarms. Our system intervenes betweenthe sensors and the experts and undertakes several tasks in order to assist humans int heir evaluat ion. Besides t he usual housekeeping t asks, such as t he updat ing of t he da t abase wi t h incoming measuremen t s, O 3RTAA is empowered wi th advanced features including measurement validation, estimation of missing values, and custom alarm identification. These advanced features are enabled through the exploitation of data mining techniques.− The syst em operat es bet ween t he field sensors and human expert s in order t o achieve specific goals, organized in three layers, as shown in Figure 1. The system goals form a pyramid, as t he success of higher-level goals depends on t he fulfillment of lower-level ones.Take in Figure 1Caption: System goals and corresponding agent roles.A he firs layer, he Con ribu ion Layer, sys em goals rela ed o preprocessing ac ivi ies are ga hered. Preprocessing includes efficien measuremen cap ion, incoming data-series verification, possible malfunctions identification and restoration, and, finally, delivery of preprocessed measurement values. These tasks are assigned to the diagnosis agent role.The second layer of goals, the Management Layer, is responsible for the manipulation of t he preprocessed measurement values arriving from t he cont ribut ion layer. It s major objective is the identification of alarms. There are two types of alarms: a) the “formal alarms”, regulat ed by law-imposed thresholds, and b) t he “cust om alarms”, defined by user requirements and taking under account local phenomena and trends. Alarm agent and database agent roles deliver these tasks in close collaboration.At t he t op level, t he Dist ribut ion Layer, goals are relat ed t o t he distribution of the identified alarms to the appropriate recipients, based on previously described profilesof t he int erest ed part ies. The alarms t riggered at t he management layer are resolved and finally delivered t o t he appropriat e recipient s at t he manner t hey have specified (i.e., email message, SMS, etc).System ArchitectureThe implement ed mult i-agent syst em is shown in Figure 2. Agent s are organized in t hree layers, cont ribut ion, management and dist ribut ion, following t he classificat ion of system goals discussed in the previous section. Thick arrows below the agent layers indicate the critical tasks realized through each one of them.Take in Figure 2.Caption: Agent System Architecture and related critical tasks.Informat ion flows from field sensors (on t he left in Figure 2) t o t he users (on t he right) through the three agent layers. Air-quality measurements arrive into the system from t he sensors. Diagnosis Agent s capt ure t hem, and aft er t he validat ion process, deliver t hem t o t he Management layer. The Alarm Agent receives t he validat ed measurements and determines whether a formal or custom alarm must be issued. The validat ed measurement s are st ored int o t he dat abase for fut ure use by t he Dat abase Agent. Possible alarms are forwarded to the Distribut ion Agent, which delivers them in the appropriate format to the corresponding end-users.Diagnosis Agent TypeDiagnosis Agents are in charge of monitoring various air quality attributes including pollutants emissions and meteorological attributes. Each one of the Diagnosis Agentinstances is assigned to monitor a certain field sensor. For the developed system thereare eleven attributes monitored: SO 2 (Sulfur dioxide), O 3 (Ozone), NO (Ni t rogen oxide), NO 2 (Nit rogen dioxide), NO X (Nit rogen oxides), VEL (Wind velocity), DIR (Wind direct ion), TEM (Temperat ure), HR (Relat ive humidit y), RAD (Radiat ion), and PRE (Pressure). Diagnosis agents are also responsible for ensuring t he efficient operation of sensors. In case of a sensor breakdown, diagnosis agents are in charge of estimating the missing values.Take in Figure 3Caption: Diagnosis Agent type internal structure. (Reasoning Engines are in bold)The int ernal st ruct ure of t he Diagnosis Agent t ype is shown in Figure 3. When a message is received by a diagnosis agent it is checked. If it is a measurement request by another agent, the diagnosis agent will respond by sending the value of its currentmeasurement. If a new measurement has arrived, it is checked for its validity. In any ot her case, t he incoming message is not underst ood and t he agent responds wit h an appropria t e message. The incoming measuremen t valida tion (IMV) procedureinvolves the application of the corresponding inference engine. The IMV engine runs a decision model ext ract ed wit h t he use of dat a mining on hist orical dat a. The out come of t his decision model is t he classificat ion of t he incoming measurement either as ‘valid’ or ‘invalid’.In the first case, the valid measurement is preprocessed in a semantic way. Qualitative in t erpre t a t ions of t he real value are calcula t ed, such as value range, trend, or persistence. The real measurement along with the qualitative attributes is sent to the Alarm Agent. When the measurement is classified as invalid, the Missing Value Estimation (MVE) rule engine is act ivat ed. This rule engine incorporat es an induct ive decision st rat egy discovered also by performing dat a mining on hist orical dat a. The MVE engine es t ima t es t he missing value level in a quali t a tive form (i.e. ‘low value’). The qualitative indication of t he missing measurement is forwarded t o t he Alarm Agent. When a Diagnosis Agent ident ifies t hat t he sensor’s measurement s are persist ent ly invalid, triggers a sensor malfunction message to the alarm agent.The Diagnosis Agent behavior implements JADE’s cyclic behavior. This is indicated in Figure 3 with the dotted arrow connecting the end state to the starting node. Alarm Agent TypeAlarm Agents are responsible for triggering formal alarms and custom alarms. Formal alarms are the ones imposed by law, indicating dangerous situations in the atmosphere exceeding legal t hresholds. Cust om alarms are alert s for t he syst em users about si t ua t ions of t heir concern. In t he presen t implemen t a t ion cus t om alarms warn environmen t alis t s for even t s based on t heir scien t ific in t eres t rela t ed t o ozone pollut ion. An expanded version of t he syst em may include ot her t ype of cust om alarms for patients, public administration, or industry, among others.Take in Figure 4Caption: Alarm Agent type internal structure. (Reasoning Engines are in bold)The Alarm Agen t workflow is shown in Figure 4. Alarm Agen t ga t hers t he measuremen s coming from field sensors hrough he Con ribu ion Layer.As he Alarm Agent receives the validated measurements from the Diagnosis Agent, a tuple (record) of all concurrent measurements is created. When the tuple is completed, the Alarm Agent performs three parallel activities:− It sends the measurements to the Database Agent in order for them to be stored to the Database.− I t may trigger ‘formal alarms’. This ac ivi y involves he applica ion of an inference engine for Formal Alarm Triggering (FAT Engine).− It may identify and subsequently issue a custom alarm through the Identification of Custom Alarms (ICA) engine. The ICA rule engine implements a decision model extracted using data mining techniques.Whenever Formal or Cus t om alarms are iden t ified, appropria t e messages are forwarded to the Distribution Agent. Note that the behavior of the Alarm Agent is alsocyclic. Database Agent TypeThe Dat abase A gent is responsible for updat ing environment al dat abases wit h dat a from field sensors. This task, although trivial, is vital for the system performance, as itrelieves humans from manipulating all this amount of information.The Da t abase Agen t receives a message from t he Alarm Agen t , con t aining t he measurement tuple. It establishes a connection to the related databases and stores all information in the appropriate format to the corresponding table.Distribution Agent TypeThe Distribution Agent pushes the alarms raised by the alarm agent to the appropriate users. As an alarm message is received, t he Dist ribut ion Agent queries user profiles for selecting target users interested in the alarm and selects the appropriate medium of not ificat ion (i.e. email or SMS). As t he set of recipient s and mediums has been prespecified, the alarm is transformed properly into an alert and finally transmitted to the users.System DeploymentThe aforemen ioned agen ypes have been developed using he Agen Academy platform following a certain procedure discussed in Mitkas et al. 2003. This procedure involves t he definit ion of agent t ype funct ions, domain ont ology, along wit h agent interactions, and communication language.Agent AcademyAgen Academy is a framework for developing agent s empowered wit h t raining capabilit ies exploit ing dat a mining t echniques and is dist ribut ed under t he less-GPL license. (Agent Academy Consort ium 2000, Mit kas et al. 2002). Agent Academyfacili t a t es t he whole procedure for developing a mul t i -agent communi t y. Agen t Academy supports the creation of agents with limited initial referen cing capabilities,along wit h a cert ain agent t raining process t arget ing t o augment agent intelligence efficien t ly, t hrough t he embedding of da t a–driven decision s ra egie s in t o t hem (Athanasiadis et al. 2003b).Technologies adoptedThe development of O 3RTAA involved a variety of technologies. The JADE platform was used for agent creat ion (Bellifemine et al. 2000) and JESS engine for rule execut ion (Friedman -Hill 2003). Ont ology design and specificat ion was done wit h Prot égé 2000 Ont ology Edit or (Grosso et al. 1999). Dat a mining experiment s were performed using the core of the WEKA tool for knowledge analysis (Witten & Frank 1999) and PMML format was select ed for knowledge m odel represent at ion (Dat a Mining Group 2001). FIPA standards were adopted for agent communication (FIPA 2000).Informat ion flow among agent s is st ruct ured in agent messages, while rule engines support data-driven decision -making.Agent Ontology and MessagingIn our system, the content of agent messages is structured using a common ontology, creat ed wit h t he Prot égé 2000 ont ology edit or. Part of t he developed ont ology is shown in Figure 5, cont aining t he main concept s of t he syst em. The slot s of t hevarious concepts have been configured in order to contain the appropriate information communicated by the agents. For example, concept ‘Pollutants’ has the followingslots: value, level, and variability for describing a measurement in bothquantitative and qualitative form.Take in Figure 5Caption: Main concept structure as a part of the domain ontology.Informat ion shift s bet ween agent layers via messages communicat ed among agent instances. The ontology is exported in RDFS format, which is compatible with JADE agents.The agent communicat ion language is FIPA-ACL and a sample message bet ween a Diagnosis Agent and t he Alarm agent is shown in Figure 6. Using t he implement ed ont ology, t he ozone Diagnosis Agent report s it s measurement t o t he alarm agent, as needed. Agent predicate concept ‘sendMeasurement’is used for informing the Alarm Agent about a measurement and has two slots: one is instance of the ‘TimeStamp’ concept and t he ot her an inst ance of t he ‘O3’ concept. Note that O3 concept inherits its slots from the Pollutants concept.In a similar way, all informat ion is exchanged bet ween agent s, conforming t o FIPA specifications and realizing the developed domain ontology.Take in Figure 6Capt ion: Ozone Diagnosis Agentreportstothe Alarm Agent the currentmeasurement.Agent Decision Making ModelsAgent decision-making is the most critical part of the system as it is related with all advanced features of the system. O3RTAA contains four different reasoning engines. IVM, MVE and ICA Engines realize induct ive decision models and FAT Engine realizes a deductive decision model. Inductive decision models are those created using data mining techniques and incorporating data-driven knowledge into the system.In general, the goal of the data mining procedure is to rev eal interesting patterns from dat a volumes and use t hem for fut ure decision making. A predict ive model is built based on these patterns. Predictive models are comprised of two parts: the predictor and the response. The predict or consist s of a set of independent at t ribut es used t o make the prediction, while the response is the target value or class. Predictive models could be in he form of decision rees, neural ne works or associa ion rules. A predic ive model can be ransformed in o logical rules having he form: ‘If assumption then consequence’ and t hus is easy t o implement and execut e t hrough a Rule Engine.To develop our system, we have used data mining techniques for adding customized in elligence in he form of da a-driven decision s ra egies. For he knowledge ex rac ion process, Agen Academy’s Da a Miner componen was used, which extends the Waikato Environment for Knowledge Analysis (WEKA) tool. Predictive models ext ract ed wit h t he Agent Academy Dat a Miner are formed using Predict ive Model Markup Language (PMML). PMML document s are t ransformed int o JESS rules and finally incorporated into software agents.The test case deploymentHist orical dat a coming from t he Onda met eorological st at ion, in t he Communit y of Valencia, Spain, were used for creat ing dat a-driven rules. More specifically, several met eorological at t ribut es and air-pollut ant values, along wit h validat ion t ags, were recorded on a quart er-hourly basis during years 2000 and 2001. There are about 70,000 records in the volume. Raw measurements have been preprocessed properly in order to create training and validation datasets compliant with agent goals and suitable for data mining.As an example, let us focus on t he Incoming Measurement Validat ion process. The dat aset was preprocessed in order t o cont ain t he corresponding validat ion t ag as t he response at t ribut e and t he current value of a specific pollut ant along wit h a set of previous values and measures as predict or at t ribut es. These measures are shown in Table 1. The preprocessed dataset was split into two sets. Data recorded in year 2000 were used as t he t raining set and dat a recorded in 2001 were used as t he t est set. Quinlan’s C4.5 algorithm for decision tree induction (Quinlan 1993) was applied on the data. The resulted decision tree contains 15 leaves, i.e. it can be implemented as a set of fifteen rules. The predictive accuracy of the decision model on the validation set is 99.71%, which is satisfactory. Our data mining experiments are discussed in detail in Athanasiadis et al (2003a,b).O3The current ozone value O3_30The ozone value 30 min ago O3_90The ozone value 90 min ago MinMax60 The difference bet ween t he maximum and t he minimum ozone value in t he last 60minMinMax150 The difference between the maximum and the minimum ozone value in the last 150minO3val The corresponding validation tag (valid/erroneous)Take in Table 1Caption: Attributes used for the validation decision modelSummary and future workIn his paper we have presen ed an in elligen environmen al moni oring sys em, developed wi t h sof t ware agen t s and using da t a mining techniques for adding cust omized int elligence int o t hem. Syst em goals have been assigned successfully t oagent s, which act as medi at ors and deliver validat ed informat ion t o t he appropriat e st akeholders. Agent communicat ion and semant ic represent at ion of informat ion is performed using state of the art tools.System customization has been based on the application of data mining techniques on hist orical environment al dat a for adding dat a-driven int elligence. The use of C4.5 algorithm yielded trustworthy decision models for validating incoming measurements, es t ima t ing t he erroneous ones and iden t ifying cus t om alarms in t he described application.The system developed will be installed as a pilot case at the Mediterranean Centre for Environment al St udies Foundat ion (CEAM), Valencia, Spain, in collaborat ion wit h IDI-EIKON, Valencia, Spain. Having the system validated for a single meteorological st at ion, fut ure work will be focused on expanding t he archit ect ure for covering t he whole network.AcknowledgementsAuthors would like to express their gratitude to the Agent Academy Consortium for their valuable help. Special thanks go to the IDI-EIKON team for their efforts within Agen t Academy projec t t o deploy t he O 3RTAA sys t em and t o CEAM for t he provision of the ONDA dataset. The Agent Academy project is partially funded by the European Commission under the IST programme (IST-2000-31050).ReferencesAgent Academy Consortium (2000), Agent Academy: A Data Mining Fram ework for Developing Intelligent Agents. (Available at: http://AgentAcademy.iti.gr). A hanasiadis, I. N., Kaburlasos, V. G., Mi kas, P. A. and Pe ridis, V. (2003), Applying machine learning techniques on air quality data for real -time decision support , in “Informat ion Technologies in Environment al Engineering”, ICSC-NAISO, Canada. At hanasiadis, I. N., Mit kas, P. A., Laleci, G. B.and Kabak, Y. (2003), Embedding dat a-driven decision st rat egies on soft ware agent s: The case of a mult i -agent syst em for monit oring air-quality indexes, in Jardim-Goncalves, R., Cha J. and Steiger-Garcao A. (eds), “Concurrent Engineering: The Vision for t he Fut ure Genera t ion in Research and Applica t ions”, Balkema Publishers, Madeira, Portugal, pp.23-30. Bellifemine, F., Poggi, A. and Rimassa, G. (2000), Developing mult i -agent systems wi t h JADE, in “Seven t h In t erna t ional Workshop on Agen tTheories, Archi t ec t ures and Languages (ATAL-2000)”, Bos t on, MA. (Available a t : http://jade.cselt.it). Da t a Mining Group (2002), Predic tive Model Markup Language (PMML), Specifications, (Available at: ).Fine, S. S., Smith, W. T., Thorpe, S. R., Wheeler, N. J. M. and Eyth, A. M. (1998), An au t oma t ed assis t an t for environmen t al da t a analysis, in “Four t een t h International Conference on Interactive Information and Processing Systems for Me t eorology, Oceanography and Hydrology”, American Me t eorological Society, Phoenix, AZ, pp. 38-40. FIPA (1999), Foundat ion for Int elligent Physical Agent s, Specificat ions, (Available at: ). Friedman-Hill, E. J. (2003), Jess, the expert system shell for the java platform, version 6.1, Sandia Na t ional Labora t ories, CA. (Available a t : /jess/). Grosso, W. E. et al. (1999), Knowledge modeling at the millennium, The design and evolution of Prot_ eg_e-2000. (Available at:). IFIP (1999), Comput ers and t he environment , Working Group 5.11, Int ernat ional Federa t ion for Informa t ion Processing. (Available a t : ). Jennings, N. R., Sycara, K. and Wooldridge, M. J. (1998), A roadmap of agent research and development , in “Aut onomous Agent s and Mult i -Agent Systems 1”, Kluwer Academic Publishers, Boston, pp. 7-38. Kalapanidas, E. and Avouris, N. (2002), “Air quality management using a multi -agent sys em”, In erna ional Journal of Compu er Aided Civil and Infras ruc ure Engineering 17(2), 119-130. Mit kas, P., Symeonidis, A., Kehagias, D., At hanasiadis, I. et al. (2002), An agent framework for dynamic agent retraining: Agent academy, in B. Stanford-Smith, E. Chiozza and M. Edin, eds, “Challenges and Achievements in e -business and e-work”, Prague, Czech Republic, pp. 757-764. Mit kas, P. A., Symeonidis, A. L., Kehagias, D. and At hanasiadis, I. N. (2003), A framework for cons t ruc t ing mul t i-agen applica ions and raining in elligen agen t s, in “Four t h In t erna t ional Workshop on Agen t -orien t ed Sof t ware Engineering (AOSE-2003). Held a t Au t onomous Agen t s and Mul t i -Agent Systems (AAMAS 2003)”, Melbourne, Australia. Nodine, M., Fowler, J., Ksiezyk, T., Perry, B., Taylor, M. and Unruh, A. (2000), “Ac t ive informa t ion ga t hering in InfoSleu t h”, In t erna t ional Journal of Cooperative Information Systems 9(1-2), 3-28. Purvis, M., Cranefield, S., Ward, R., Nowost awski, M., Cart er, D. and Bush, G. (2003), “A mult i -agent syst em for t he int egrat ion of dist ribut ed environment al information”, Environmental Modelling and Software 18(6), 565-572. Tierney, B., Crowley, B. et al. (2000), A monitoring sensor management system for grid environment s, in “High Performance Dist ribut ed Comput ing (HPDC-9)”, American Meteorological Society, Pittsburg, Pennsylvania. Wit t en, I. H. and Frank, E. (1999), Dat a Mining: Pract ical Machine Learning Tools and Techniques wi t h Java Implemen t a t ions, Morgan Kaufmann Publishers, USA.。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
The Role of Java in InfoSleuth:Agent-based Exploitation of Heterogeneous Information ResourcesNigel Jacobs and Ray SheaMicroeclectronics and Computer Technology Corporation (MCC)3500 Balcones Center Dr.Austin, Texas 78759Copyright 1996 Microelectronics & Computer Technology Corporation. All Rights Reserved. Abstract1 Introduction1.1 Carnot1.2 InfoSleuth2 Technologies2.1 KQML2.2 KIF2.3 LDL++2.4 CLIPS3 High-level Architecture3.1 Agent Layer3.2 Semantic Layer3.3 Application Layer4 Ontologies and Meta-models5 Query Views6 Physical Agent Architecture6.1 User Agent6.2 Monitor6.3 Broker Agent6.4 Ontology Server6.5 Execution Agent6.6 Resource Agents6.7 Data Analysis Agents6.8 Viewer Server7 Sample Scenario8 Java8.1 Advantages8.2 Disadvantages8.2.1 Netscape Security Model8.2.2 AWT8.2.3 Classes and instantiation9 Security Concerns10 Current Status and Future DirectionReferencesAbstractFinding, retrieving, and integrating information from geographically disparate data resources is a difficult problem that large organizations have faced for decades. In recent years, the size and variety of data networks have increased dramatically, and a host of new issues have been raised by the need to mine information from dynamic sources such as the World Wide Web, where information is constantly being updated, there is a high-level of local autonomy, and central control is almost non-existent.InfoSleuth is a consortial research project at MCC which is developing technologies for addressing these issues. Based on MCC’s successful Carnot project, InfoSleuth is developing a network of semi-autonomous software agents which perform semantic data integration and retrieval across a widely distributed network environment. To achieve this, the project employs recent advances in ontology management, data mining, workflow automation, object brokering and language translation.The InfoSleuth architecture consists of agents communicating with each other via the high-level language KQML. Queries are specified in the flexible knowledge representation language KIF, with respect to common ontologies that are managed in knowledge-base management systems such as Ontolingua and CLIPS. The queries are routed by mediation and brokerage agents to specialized agents for data retrieval from distributed resources, and for integration and analysis of results. User interaction with this web of agents is via a personalized intelligent user agent which communicates with the user via Java applets running inside a Java-capable Web browser such as Netscape.1 IntroductionThe InfoSleuth project seeks to develop and deploy new technologies for finding information available in both corporate Intranets and the global Internet, through the use of cooperating software agents [1]. This paper gives an overview of the history and architecture of InfoSleuth, and explores the advantages and disadvantages of using Java [2] as one of the bases of that architecture.1.1 CarnotIn 1990, MCC’s Carnot project [3,4] began investigating the problem of integrating corporate-wide distributed heterogeneous databases. By project completion in 1995, Carnot had deployed functioning prototypes which have been used by sponsor companies to develop applications in the areas of workflow management, heterogeneous database access, and knowledge discovery. The Carnot system consists of a set of services implementing:· semantic execution of queries· inter-resource consistency management· enterprise modeling and model integrationComponents of the enterprise model (or ontology) are mapped directly onto components of individual database schemas; thus, any operation (update or retrieval) can be performed on an enterprise-wide basis by performing the operation against the model, or against any of the integrated schemas. In this way, individual applications are decoupled from the variety of changingdatabase resources.Many of the core technologies and techniques developed for Carnot serve as a basis for the work which is continuing with InfoSleuth. These include advances in:· enterprise model capture and mapping to database schemas· knowledge mining techniques· knowledge representation· distributed processing1.2 InfoSleuthThe InfoSleuth project began in 1995 [5,6], with the task of extending the core ideas developed in Carnot to apply to a geographically distributed and continually changing network of information resources, such as the World Wide Web. The dynamic nature of the environment and the lack of any central control or structure creates new challenges for finding, accessing, updating, and analyzing information that exists on the network.InfoSleuth’s approach to these challenges is to develop an architecture based on cooperating autonomous agents, which collaborate in order find and analyze data [7]. Previous Carnot techniques of semantic integration are now embodied within intelligent agents which advertise their services and process requests for those services. Additional agents support both general and domain-specific services such as knowledge mining, fuzzy queries, brokering, query decomposition and result integration, query format conversion, and user monitoring and result sharing.A key advantage to the new architecture is its dependence on standards such as KQML, KIF, HTTP, and Java. This provides a higher level of openness, flexibility, and extensibility than previously existed in Carnot.2 TechnologiesInfoSleuth is utilizing several key technologies, of which some are successful products of Carnot, and others are emerging standards which have been developed in the database and artificial intelligence communities.2.1 KQMLThe cornerstone of the InfoSleuth agent architecture is the Knowledge Query and Manipulation Language, or KQML [8]. KQML is a specification of a message format and protocol for semantic knowledge-sharing between cooperative agents, developed as part of the DARPA Knowledge Sharing Effort [9]. Agents communicate via a standard set of KQML performatives, which specify a set of permissible actions that can be performed on the recipient agent. Performative categories include basic query performatives (e.g., "evaluate", "ask-one", "ask-all"), informational performatives (e.g., "tell", "untell"), capability-definition performatives (e.g., "advertise", "subscribe", "monitor") and more.Since KQML is not tied to any one representation language, it can be used as a "shell" which can contain messages in various languages and knowledge representation formats, and permit routing by agents which do not necessarily understand the syntax or semantics of the content message.As part of the InfoSleuth project, we have developed a prototype Java implementation of theKQML language and protocol.2.2 KIFThe Knowledge Interchange Format, or KIF [10], is a language developed by the InterLingua Group of the DARPA Knowledge Sharing Effort, which allows the interchange of knowledge between widely disparate programs with differing internal knowledge representation schemes. It is a human-readable format, with declarative semantics (its meaning is defined without the need for an interpreting program), and the ability to express first-order logic sentences, with some second-order capabilities. Although KIF is not as efficient as many internal knowledge representation schemes employed in knowledge bases and knowledge applications, it provides a common communication mechanism for existing and future systems, and several translators exist that convert existing knowledge representation languages to and from KIF. KIF will soon be an ANSI standard.InfoSleuth agents currently share data via KIF. Typically, an agent converts queries or data from its internal format into KIF, then wraps the KIF message in a KQML performative before sending to the recipient agent.2.3 LDL++LDL++ [11] is a deductive database system based on formal logic with object-oriented facilities, which supports a declarative database language (also called LDL++). LDL++ provides standard database query functionality, including updates, with additional capabilities for recursive query processing, meta-level constructs, nested objects, and rule-based inferencing.LDL++ has proven particularly useful for building knowledge-based applications which need efficient access to very large collections of data (e.g., expert systems with large common-sense knowledge bases). Access to LDL++ is via a C/C++ API. For InfoSleuth, we have developed a prototype resource agent which translates KIF-based queries into LDL++ queries and executes them against various local databases.2.4 CLIPSCLIPS [12] is a production and delivery tool which enables construction of rule-based andobject-based expert systems. It contains powerful facilities for knowledge representation, semantic rule-checking, and validation. CLIPS is extensible, and is easily embedded in other applications.Some InfoSleuth agents, such as the query execution agent (see section 6.5 "Execution Agent") are being partially implemented in CLIPS and communicate with other agents via KQML.3 High-level ArchitectureThe general InfoSleuth architecture is pictured in Figure 1. It consists of three layers:· the Agent Layer· the Semantic (Ontologies) Layer· the Application LayerFigure 1. High-level Architecture3.1 Agent LayerThe bottom-most layer of the InfoSleuth architecture is provided by the network of cooperative agents linked via KQML. These agents are declarative rule-based agents, implemented in LISP, CLIPS, LDL++, and Java. They advertise their services and process requests for those services either by inferencing based on local knowledge, by routing the request to a more appropriate agent, or by decomposing the request into a collection of sub-requests, then routing these requests to the appropriate agents and integrating the results.3.2 Semantic LayerThe Semantic Layer (or Ontologies Layer) provides collaborating agents with a common vocabulary and a common semantic model for interaction in a particular problem domain. For example, a set of agents in a medical application may have access to a health care ontology; some agents would communicate strictly in terms of this ontology, while other agents may be responsible for mapping ontology-based requests onto other ontologies or onto individual database schemas that contain health care information. Other agents would be responsible for brokering data and applets between the health care agents.3.3 Application LayerAt the application layer, InfoSleuth currently focuses on three main areas:· resource discovery (e.g., finding agents and databases appropriate to a particular domain) · pattern discovery & analysis (e.g., knowledge mining, visualization)· collaboration, discovery & execution (e.g., intelligent, dynamic collaboration)These three areas are obviously intertwined and overlapping. Examples of application domains for which InfoSleuth is currently being used as a basis for application prototypes include:· wafer fabrication process analysis· health care administration4 Ontologies and Meta-modelsOntologies in Infosleuth are semantically-precise, hierarchically-organized descriptions of resources. They can be used to capture database schema (e.g. relational, object-oriented, hierarchical), conceptual models (e.g. entity-relationship models, object models, business rules, user models), mappings (e.g. integration maps between ontologies) and even aspects of the Infosleuth agent architecture (e.g. workflow specifications, agent configurations). Rather than choose one universal ontology format, InfoSleuth allows multiple formats, representing each ontology format with an ontology meta-model. The meta-model approach makes it easier to integrate between different ontology types.The Java version of the ontology meta-model implementation, pictured in Figure 2, has athree-layer architecture:· Frame layer· Meta-model layer· Ontology layerFigure2. Ontology Meta-modelThe bottom Frame layer (consisting of Frame, Slot, and MetaModel classes) allows creation, population, and querying of new meta-models. Meta-model layer objects are instances of frame layer objects, and simply require instantiating the frame layer classes. Ontology layer objects are instances of meta-model layer objects. Since Java does not allow objects to be both classes and instances, and classes may not be created dynamically (see section 8.2 "Disadvantages"), ontology layer objects are all instances of one general class and are accessed via a hash table associated with their meta-model parent object.The implementation approach outlined above serves as a proof-of-concept of the generalmeta-model approach to ontology representation, but would not scale well for larger applications with very large ontologies. Also, the only persistence currently provided is the ability to save entire ontologies to disk. We plan to enhance our ontology architecture by storing ontology layer objects in an object database, providing both scalability and persistence.Simple ontology constraints such as referential integrity and inverse link maintenance are currently implemented in Java. By incorporating CLIPS inferencing capabilities, we plan to handle more complex constraints, both on the ontology structure (expressed in the meta-model layer) and within the ontologies. This should also allow InfoSleuth agents to perform more sophisticated query processing internally, based on ontology meta-data alone.5 Query ViewsQuery views are database applications implemented as Java applets which can be used to retrieve and manipulate data from the network. Query views take advantage of the core capabilities that Java has to offer.Query view applets are written on top of a query API layer which provides an abstract, high-level method for modifying ontologies, constructing queries against the ontologies, executing the queries, and retrieving the results. The underlying functionality of the API is actually carried out by the agent network; in essence, the API is a wrapper to the query implementation provided by the network of query agents.Query views can implement either general purpose or domain-specific metaphors for query construction and data visualization. The viewer server, which maintains the repository of query views, can fulfill requests for query view applets based on the desired functionality and the ontology or domain model which the query view supports. When the user selects a domain (or ontology) and a task or set of tasks he wishes to accomplish, the user agent retrieves the necessary set of applets for accomplishing this from one or more viewer servers on the network, and allow the user to load and use these applets, then discard them.This is a very powerful paradigm. With Java, we have extended the notion of using a network of agents to find and retrieve data, and now use that same network of agents to dynamically find, retrieve, and load the proper GUI applets for interacting with that data, based on the task domain and qualities of the data itself. In a sense, we are automating the software distribution process using the same techniques with which we are automating the data retrieval process.6 Physical Agent ArchitectureOne can think of the InfoSleuth network as a cloud of agents (Figure 3), through which data passes back and forth between users and data resources. All communication within this cloud is conducted by means of KQML and high-level ontologies. The user interacts with data resources (the existence of which may be unknown at the time requests are made) by passing requests into the cloud via his personal user agent, with which he communicates via Java applets. At the other end, a data resource (for example, an Oracle database) accepts requests from the cloud via its own resource agent, which translates the KQML/ontology-based query into the query language understood by the local resource (for example, SQL).Figure3. Cloud of AgentsFigure 4 shows a simple implementation of this network of agents, with the cloud of agents actually providing only a single thin layer between the user agents and resource agents. Since the communication mechanism between all agents is based on KQML, and since an agent can participate simply by advertising its services to a broker, it is a simple matter to integrate other KQML-aware agents into the system, thus providing a high degree of extensibility.Figure4. A Simple Agent NetworkEach of the agents depicted in Figure 4 is capable of handling multiple user sessions, except for the user agent, which is intended to serve as a personal agent to a single user (although it can managemultiple sessions with other agents).Following is an overview of the function of each agent.6.1 User AgentThe user agent is the user’s intelligent gateway to the network of InfoSleuth agents. As such, it is primarily responsible for handling requests from the user via Java applets, routing those requests to appropriate server agents, and passing responses back to the user. The user agent is persistent and autonomous, thus it is able to maintain the user’s context beyond a single browser session, allowing long-term autonomous data retrieval and other tasks to continue in the user’s absence. It is capable of storing information (data and queries) for the user, maintaining a user model, and can act as a resource for other agents, for instance as a means of sharing information with other user agents. The user agent is implemented as a stand-alone Java application.6.2 MonitorThe monitor is an HTTP proxy which serves two roles:· monitor user web access and report to the user agent for later inferencing and patterndetection.· accept Java applets via the user agent and place them in the proper directories so that they can be accessed by the user. (See Section 9, "Security Concerns").This agent is closely tied to the user agent, and like it, is implemented in Java.6.3 Broker AgentThe broker agent acts as a matchmaker which pairs requests from agents to other agent services that can fulfill that request. As agents come on line, they can advertise their services to the broker via KQML. Any agent can ask the broker for a recommendation on how to fulfill a particular request, and the broker will respond with the addresses of the agents that have advertised that service. Possible future capabilities for the broker include delegation (i.e., "passing the buck"), and subscription, allowing requesting agents to subscribe to various kinds of information, enabling asynchronous notification when the desired resources become available. The broker is a Java application.6.4 Ontology ServerThe ontology server is responsible for managing the creation, update and querying of multiple ontologies. KIF is used both to query the ontologies and to express the query results. Ontologies may be imported and exported in KIF and several other representation languages. Different ontology formats (e.g., relational or object database schema, entity-relationship models) are described via ontology meta-models. Ontologies may be nested, and references may be made between ontologies. The ontology server maintains internal consistency. Many ontology servers may be deployed, with each server advertising the ontologies it maintains via the broker agents. The server is currently implemented as a Java application.6.5 Execution AgentThe execution agent is responsible for high-level execution of ontology-based queries. It acceptsKQML messages containing KIF-based queries, decomposes the queries into sub-queries based on its knowledge of appropriate resource agents that can satisfy the query, and sends the high-level sub-queries off to the resource agents. It then can merge the results received and transmit them to the agent which originated the query. The execution agent is implemented in Java with embedded CLIPS functions.6.6 Resource AgentsThe resource agent is to the local database what the user agent is to the user. It acts as an intelligent front-end interface for the relatively dumb DBMS or other data store, accepting high-level ontology-based queries from the network and translating them into whatever local query language (e.g., SQL) is necessary to execute the queries against the local database. Results are then translated back into the terms of the ontology and returned to the requesting agent. Just as the user agent maintains the user context, the resource agent is able to maintain resource context, allowing for incremental retrieval of query results by requesting agents. Additionally, resource agents are able to obtain, store, and advertise meta-information about the contents of their local resource. Current resource agents are implemented in Java and LDL++, with ODBC and SQL versions under development, and JDBC versions [13] planned.6.7 Data Analysis AgentsData analysis agents perform various analysis, knowledge mining, and pattern recognition tasks on data returned by a query. These agents are implemented in Java, CLIPS, LDL++, and LISP.6.8 Viewer ServerThe viewer server is a specialized resource agent, in that it maintains a storehouse of Java applets which are designed to manipulate KIF ontologies and queries based on those ontologies, via a standard InfoSleuth meta-model query API. In a sense, the viewer server is an applet broker which serves database applications, query editors, and visualization tools for manipulating and displaying query results. It is implemented as a stand-alone Java process.7 Sample ScenarioSuppose the user is interested in locating real estate data stored in a variety of distributed databases, based on various factors such as price, location, zoning, etc. Using InfoSleuth, she logs in to her user agent via a login applet in Netscape, and requests recommendations for ontologies and applications that are appropriate to the problem domain. The user agent queries a broker agent for servers that could fulfill the request for ontologies, and is directed to an ontology server. The ontology server recommends a list of ontologies it knows about that relate to the problem domain, and the user agent allows the user to select one.Now that the particular ontology is selected, the user agent again asks the broker to recommend a server that can supply query and visualization applets that work with the selected ontology. Again the broker recommends a viewer server, the user agent sends the request to the viewer server, and the server responds by sending one or more Java applets that fulfill the requirements. Assuming verification of the trustworthiness of the applets is done (see Section 9, "Security Concerns"), the user agent passes the applets to the security monitor, which places the applets in the appropriate codebase hierarchy for access by the user. At this point the user agent send the names of the applets to the login applet, which permits the user to load them.The user iteratively constructs an appropriate query via the domain-specific applet, using concepts from the selected ontology. She can then submit the queries for execution. The user agent consults the broker for recommendations on how to execute the query, and is directed toward an execution agent. The execution agent decomposes the query into sub-queries, submits the sub-queries to one or more resource agents, which resolve the sub-queries against their respective local databases and return the results to the execution agent, which collates the results and passes them back, via the user agent, to the user.8 Java8.1 AdvantagesThe use of Java in InfoSleuth offers several key advantages.Most crucial is the ability to safely download platform-independent applets into a Java-compatible web browser. This allows us to extend the basic model of retrieval of data in a dynamic environment, to also encompass distribution of functionality in the same dynamic environment. We are able to find and retrieve data from disparate sources, and with Java, we are able to deliver that data packaged with the appropriate applets for viewing them. The user no longer needs to find and install the appropriate graphing or visualization tools; all that is necessary is for the applet writer to make the applet available at a viewer server which can advertise the applet’s capabilities. Although this model seems to hold promise for changing the nature of software distribution over the Internet in the long term, we believe that it can provide a workable near-term solution within a corporate intranet.The interpreted platform-independent nature of Java is a second important feature. InfoSleuth agents are primarily stand-alone server processes. Because of the "write once, run anywhere" nature of Java, our agents are able to be easily deployed on a heterogeneous network without concern for which platform architecture is supported by which agent.Not critical to the architecture, but advantageous none-the-less, are features in Java which make it a robust general purpose programming language, including multithreading support, garbage collection, and strong compile-time type-checking.8.2 Disadvantages8.2.1 Netscape Security ModelThe current security model implemented by Netscape makes much of our work problematic. Although necessary at the present time to guarantee safety for the general Netscape user, the following security features have hampered InfoSleuth development:· The inability to make socket connections to any host except the one from which the applet originated. This has made it necessary for the user agent to run on the same host as the HTTP proxy server.· The inability to replace the ClassLoader with a custom class loader. This has necessitated the current rather kludgy method of passing downloaded applets to the security manager so that it can place them in the proper directories on the server host to make them available within the same codebase as the login applet. (See Section 9, "Security Concerns".)· The inability to configure security preferences based on the needs of the particular site.The strategy that Netscape has taken is the correct one: introduce the product with the strictest security possible in order to allay initial fears of possible security-related flaws in the architecture, then implement gradually more relaxed (or configurable) options. We look forward to enhanced mechanisms for providing client-side security while at the same time allowing more flexibility and power for applets distributed over internal corporate intranets.8.2.2 AWTThe Abstract Windowing Toolkit from Sun has caused us a variety of problems. The primary difficulties include:· layout manager usability· restricted access to peer events· only a very basic set of drawing functions· inconsistencies in behavior between Windows 95 and Solaris versions· lack of some key widget types, such as Motif combo boxes, image pushbuttons, and popup menus.We understand the difficulties faced by the Java development team due to the unexpected response to their product, and eagerly await an improved windowing toolkit in the future, either from Sun or from third-party developers.8.2.3 Classes and instantiationIn using the Java language to implement knowledge base facilities, we were unable to represent meta-model instances (ontology layer ‘classes’) as Java classes, as Java does not allow dynamic class creation and objects that are both classes and instances. These ‘meta-programming’ facilities which are available in some interpreted object languages are presumably absent from Java for performance and security reasons, and because of its similarity to C++, which also lacks these capabilities.As Java is unlikely to have these capabilities in the near future, we will probably implement knowledge representation facilities in more suitable languages, and provide Java interfaces where necessary.9 Security ConcernsBecause of the security policies enforced by the Netscape browser (described above), we have been forced to use a work-around to accomplish some of the tasks that are necessary for our architecture. When the user requests recommendations for a particular query view applet, the user agent finds and retrieves appropriate applets from agents on the network. We would prefer that the user agent be able to recommend applets for the user to choose from, then fetch the applets via a KQML request and feed them to the browser as a bytecode stream. Unfortunately, this would require replacing the default ClassLoader in Netscape, which is currently not allowed.Our work-around is for the user agent to report the name of the applet class to the login applet, and also to manually load the.class files into the proper directories so that the login applet can load them. This allows applets which originate from a network agent to be able to make socket connections to the user agent, since as far as Netscape can tell, the applets now originate at the same host where the user agent is running. We are taking advantage of the fact that the http proxy。