- 浏览: 143547 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
gadmyth:
beta reduction也介绍错了(λx . e)f →β ...
Lamda演算简介 -
gadmyth:
左结合法则是错的,因为Application binds mo ...
Lamda演算简介 -
hongmeikaile:
...
Struts2与ajax的组合 -
aguai0:
非常详细,学习了
prototype-1.3.1.js 开发笔记 -
左看右看:
...
DAO编程模式(转)
本文是关于 Java 管理扩展(Java Management Extension (JMX))的三部分系列文章的第一部分,在本文中,Sing Li 研究了网络管理软件的历史,以及它是如何从开始阶段粗陋的软件发展成现今这样复杂而成熟的企业管理系统的。他还研究了困扰这些系统的许多常见问题的根源。以及如何利用 JMX 来解决它们。
Java 管理扩展(JMX)是 Java 平台上热门的新增部分,它承诺为与企业网络管理相关的老问题提供可伸缩的、低实现成本和与旧系统兼容的解决方案。新型的软件服务器(包括象 Jakarta Tomcat 和 JBoss 这样的流行开放源码服务器)能迅速地将 JMX 用作其管理标准。我们将通过研究网络管理软件的历史以及它是如何发展的,来开始我们对 JMX 的研究。
早期的网桥、协议转换器和路由器都是简单的专用硬件设备,通常是通过直接连接到该设备本身串口的终端来配置的。配置命令通常用来启用或禁用端口,或者更改设备支持的协议的特征。这些“黑箱”上可配置参数的数量是有限的,串行终端界面通常比较“神秘”并且只有受过大量培训的网络操作员才能够理解,如图 1 所示:
图 1. 专门的串行连接
由于网络规模的增长,以及这些“黑箱”的数目激增,很明显需要一些方法来寻址和控制这些大量的网络设备。一些供应商选择了提供用于管理这些设备的单独的“带外(out-of-band)”互连或集中器网络,如图 2 所示:
图 2. 带外多路复用控制
其他供应商使用了“带内(in band)”技术,这种技术中,在运行这些“黑箱”的同一网络上发送寻址和控制信息,如图 3 所示:
图 3. 带内设备控制和管理
客户机软件(称为管理控制台,该名称是从终端控制台等类似的名称继承而来)从“神秘的”终端样式的界面缓慢地发展成增强的 GUI 配置工具,后者能够对网络上每个可寻址的设备单独地进行配置。由此产生了早期的网络管理系统(NMS)。很大程度上,专用网络协议在这一时期处于支配地位,早期 NMS 通常使用专用协议来寻址、控制和监控供应商的设备。
接着进入了 TCP/IP 网络的时代。通过早期的因特网雏形,TCP/IP 协议族成为全球性互连网络的标准。大型企业发现:他们需要连接其分别发展的、专用的异构内部网络孤岛(其中许多来自于全球范围内不同的供应商),但同时又不失去对整个企业内所有设备的控制。
此外,基础设施构建人员在其运作中将维护越来越多的联网黑箱。这经常要跨越位于不同地理区域的多个网络运营中心。因此需要从集中的位置来管理、控制和监控所有这些设备。来自这两大用户群体的迫切需求催生了早期企业 NMS 的概念。
在此期间,管理控制台(客户机)使用最新的图形工作站和处理技术,并通常包括受管设备位置的交互式地图,以及网络网状拓扑的示意图。通过在地图上或 GUI 网络图的节点上点击,网络操作中心工作人员可以监控任何特定设备的状态并更改其设置和配置。作为异构网络管理的实际标准,SNMP(简单网络管理协议 ― 一个完全为 TCP/IP 网络上的网络管理而设计的协议)变得更流行了。尽管由于实践和经济上的原因,最初 SNMP 受到了抵制,但专用联网硬件供应商最终还是采纳 SNMP 作为管理其联网设备的备选方法。
几乎与 TCP/IP 革命同时,装备了 PC 和 LAN 的办公室的数量呈爆炸性地增长。这需要一些企业的 NMS 承担新的范围:管理和控制 PC 工作站、打印机、外设以及其它 LAN 设备,如图 4 所示:
图 4. 向管理混合体中添加 PC 和 LAN 设备
许多供应商将其新取得的能力作为营销优势来推动其企业管理系统或简称 EMS(注意并未强调“网络”这个字眼)。在此期间,领先的供应商提供的商业 EMS 的规模和复杂性都提高了,但许多供应商的产品仍然维持着大量的专用代码库,并支持所有特定于供应商的旧系统。现有的基于 GUI 的管理控制台(客户机)软件,被反复地“移植”到新兴的桌面操作系统的许多不同版本上,这放宽了限制,但增加了底层代码库的复杂性。SNMP 协议被扩展到了其极限,以支持它设计时从未考虑的新的和不同的设备。由于受管的网络端点数量激增并超出了可管理级别,因而,几乎在每种商业 EMS 中,增值智能管理辅助都成为了标准。
随着受 EMS 管理的端点骤增,因特网革命给大多数 EMS 系统和架构设计师带来了冲击。突然之间,曾经完全迥异的大型网络都通过因特网连接了起来,而客户要求这个“网络的网络”可以使用他们了解和喜欢的同一种对用户友好的管理控制台进行管理(请参阅图 5)。
随着各种智能网络设备、PC 和外围设备的不断出现,在对这些端点的日常管理和监控中需要越来越多的智能。此外,对通过因特网进行业务的需求的不断增长,致使 EMS 需要支持一种新的端点:智能软件服务器/服务。
对于新型的 EMS 系统而言,能够访问企业在全球各地的每一台数据库服务器、Web 服务器、应用程序服务器和特大容量磁盘(disk farm)(新的、高智能、宽带宽、自适应特大容量磁盘现在称为 存储区域网络或 SAN)都有管理访问权,这并不希奇。
图 5. 新型 EMS
在当今 EMS 时代,智能管理辅助不再是一个选项,而是必需的。对于处理组成和拓扑都经常变化的动态网络,该需求也是必须的。此外,适应和支持任何新的和未来设备的能力是一项明确的要求。但是,这些新 EMS 还必须继续支持旧设备、协议和软件的混合物并能与之协调一致地工作,因为客户在艰难的发展过程中,曾经对它们作过巨大投资。实际上,客户对于支持现有的基于 GUI 的 EMS 客户机有着强烈的需求,因为对这些复杂的工具进行过培训方面的投资。同时,EMS 的新用户还要求最新型的基于 Web 的管理界面以支持可能的远程管理和监控。
使用这些新 EMS 系统,您仍然可以启用和禁用旧的“哑”联网黑箱上的端口,但只要轻松地发出类似这样的命令:
必要时自动地切换到备份应用程序服务器群集和数据库服务器,以便在接下来的 24 小时中保持 95% 的正常运行时间;当发生灾难性故障时通过寻呼机 808-555-1212 向网络操作员报警。换句话说,当在典型的 应用程序服务供应商(ASP)环境中出现网络故障时,您还可以依靠智能管理辅助来管理它们。
在因特网时代,软件体系结构和联网协议有哪些更改,以便这种复杂的网络管理能继续发挥功能呢?实际上,我们已经描述过的 EMS 案例很大程度上仍是“发展中的工作”。JMX 是朝向实现动态网络的通用管理的一个关键步骤,它具有完全的向后兼容性以及对现有的和旧 EMS 基础结构的支持。
|
Java 平台所具有的许多特性使之成为复杂网络管理解决方案实现的自然的候选者,这些特性包括平台和 OS 无关性、联网和动态适应性。
因为 Java 语言的平台和 OS 无关性,NMS 开发人员不再需要为每种 OS 和硬件平台组合维护一个代码库版本。相反,现在可以将用来提高产品功能的精力和工作集中到单个代码库上。
与大多数其它编程语言不同,联网是 Java 平台的核心部分。它不是事后添加的或第三方库,因此,可以确信和保证它与 OS/硬件平台的其它部分能良好协作。这很重要,因为较早的网络管理产品常常依靠第三方联网库来满足平台/OS 组合不能提供的需求,或实现作为目标的稳定性。
网络管理软件可以方便地利用跨网络动态且安全地装入类的能力。例如,基于 Java 的 EMS 可以仅仅跨网络“装入”它的支持模块来支持它们,并可按照需要动态地升级实现网络管理智能的软件模块。
|
JMX 是业界广泛合作创建一套规范的成果,它将描述可扩展的体系结构、API 和一组使用 Java 编程语言用于网络管理的分布式服务。正如先前详细描述的,它利用了 Java 平台的网络管理能力。在撰写本文时,最新的规范是 Java 管理扩展工具和代理规范 v1.1(Java Management Extension Instrumentation and Agent Specification,v1.1)。
可交付使用的 JMX 包括一组规范、API 文档、符合 JMX 规范的参考实现和兼容性测试套件。请参阅 参考资料以获取 JMX 1.1 规范和更多信息。
JMX 的目标只是定义构成 JMX 体系结构内系统的接口,而不在不必要时指定实现和策略。对于赢得在现有网络和服务管理技术方面有既得专利权益的供应商的支持,这一思想是必需的。它将使新的基于 JMX 的应用程序在设计上享有最大的自由度和灵活性 ― 避免了规定的实现和策略可能不适合于未来需求的情形。这样,参考实现仅提供了一个关于如何满足指定的一组接口的示例,而没有建议或推荐实现这一点的方法。
|
JMX 的体系结构和操作模型旨在满足下列目标:
- 可伸缩性:适应从管理少数设备或服务到管理因特网时代的企业可能拥有的数万个可管理端点的能力
- 旧系统集成和兼容性:与现有 NMS 或 EMS 解决方案以及与可能不支持 JMX 的旧的可管理端点协作的能力
- 低成本实现:无需大量设计和编码工作,即可轻松地将 JMX 兼容性设计到现有软件产品和设备中
在 JMX 体系结构中,采用三级分而治之的体系结构化方法来降低可伸缩网络管理的复杂性。 图 6 说明了这三个松散耦合的层。它们是:
- 工具层:在本层,可管理端点(设备、软件服务等)可通过 JMX 指定的接口访问。这是通过创建公开可配置属性、可访问操作和事件的 Java 对象实现的。这些对象称为 ManagedBean(简称 MBean)。在规范中将可通过这些对象管理的端点称为 JMX 可管理的资源。通过提供 Java MBean 封装器,可以轻松地将旧的非 JMX 设备和服务器(如 SNMP 兼容的设备或子网)“调整”成 JMX 可管理的资源。这一层上的 JMX 可管理资源可以完全独立于任何其它 JMX 体系结构层上的对象进行设计。
- 代理层:在本层中,公开了 JMX 代理的内部体系结构。 JMX 代理是软件组件,它向远程管理组件公开一组标准化代理服务并通过 JMX 可管理资源的 MBean 接口直接控制这些资源。实际上,在 JMX 代理内可通过能够动态地装入和卸装 MBean 的 MBean 服务器来管理 MBean。访问 MBean 服务器的接口由 JMX 指定。大型 EMS 系统中的增值服务(如本地化智能监控和自动化响应),可在该层的 JMX 体系结构中实现。可以独立于其它层的对象设计这一层的代理。代理通过连接器或协议适配器与管理应用程序通信。但是,用于这些组件的规范仍处于开发过程中。
- 分布式服务层:在本层中,目标是指定为 JMX Manager 组件提供的接口。JMX Manager 可以访问代理或代理组来管理由代理公开的 JMX 可管理的资源。实质上,这些是 EMS 应用程序开发人员进行编程所依赖的接口。Manager 组件可以是 EMS 应用程序或管理多个代理和相关资源的中间智能层。
图 6. JMX 体系结构的三层
图 6 说明了三个层上的 JMX 对象,以及由 JMX 1.1 指定的接口。利用面向对象设计和 Java 编程语言,JMX 体系结构中的每层都是高度组件化的并由良好定义的接口进行划分的。按照这些良好规定的接口编写符合规定的代码,确保了我们的工具和代理逻辑可以与任何兼容 JMX 1.1 的实现一起使用。虽然 JMX 1.1 规范中规定了工具和代理层,但分布式服务层仍属于未来规范的范畴(在图 6 中显示为水平灰点线以及其上的点框)。现有网络管理标准(包括 SNMP 和 CIM/WBEM)的标准 JMX 接口正在由其它组同步进行制定。
工具层的核心是 MBean 接口。MBean 接口指定了如何访问属性、如何调用操作(类似于 Java 编程语言中的方法)以及如何从 MBean 发送事件。MBean 有两种主要类型,表 1 中作了详细说明。
MBean 类型 | 描述 |
标准 MBean | 与标准 MBean 相关联的所有属性、操作和事件都在其接口中静态地指定。它们是固定的,不随时间变化而变化。标准 MBean 必须实现按固定编码约定(在 JMX 1.1 规范中称为 词法设计模式)编码的管理接口,MBean 规范中对此有详细描述。例如,要用标准 MBean 使用名为 WebServer 的类,则其管理接口必须称为 WebServerMBean 。JMX 代理通常使用“自省(introspection)”来发现标准 MBean 的管理接口。 |
动态 MBean | 所有动态 MBean 都实现 javax.management.DynamicMBean 接口。通过使用 DynamicMBean 接口,与 MBean 相关联的一组属性、操作和事件直到运行时才是确定的。这满足了拥有可能随时间改变而改变的属性、操作和事件的可管理 JMX 资源的需要(例如,工具应用程序服务器可能以不同的发行版级别 ― Tomcat 4.1.4 和 Tomcat 4.1.5 ― 支持不同属性)。它也自然地适合于由联合的网络技术工具,如 Jini/Jiro。 |
有两种用于特殊用途的动态 MBeans 子类型,如表 2 所示:
MBean 类型 | 描述 |
模型 MBean(Model MBean) | 所有 JMX 实现都必须提供一个模型 MBean 的实例 ― 实现 javax.management.modelmbean.ModelMBean 接口。它必须命名为 javax.management.modelmbean.RequiredModelMBean 。模型 MBean 提供了“现成的”MBean 实现,您可以立即使用它来快速地利用任何 JMX 可管理资源。它是预制的、通用的和动态的 MBean 类,作为参考实现的一部分提供,已经包含了所有必要缺省行为的实现 ― 允许您在运行时添加或覆盖需要定制的那些实现。这使得基于 Java 的、非工具化的资源能够在运行时提供保证兼容的 MBean 虚包,使它们能够通过 JMX 体系结构进行管理。 |
开放 MBean(Open MBean) | 开放 MBean 是一种动态 MBean,其中所有的 MBean 属性都属于一组指定的 Java 数据类型( String 、 Integer 、 Float 等),并且 bean 通过一组 javax.management.openmbean.* 接口提供自我描述的数据。任何代理和任何管理器/EMS 都可以轻松地管理由这些 bean 提供的 JMX 可管理资源。JMX 1.1 中没有完整地详细说明开放 MBean 的细节,并且参考实现也没有包括它们。 |
图 7 说明了如何使用 MBean 来将工具添加到设备和软件服务。请注意,相应的 MBean 是设备或服务的 JMX 内部表示。任何已向 JMX 代理中的 MBean 服务器(稍后讨论)注册的 MBean 都可以将其管理接口(属性、操作和事件)向远程 NMS 或其它 JMX 应用程序公开。但是,当我们添加 MBean 以利用设备或软件服务时,我们不必考虑将哪种 JMX 代理或 NMS 用于管理工作。
图 7. JMX 的操作模型
一些 MBean 可能需要持久性支持以确保正确的操作。这些 MBean 应该总是实现 javax.management.PersistentMBean
接口。这个接口仅有 save()
和 load()
方法。持久 MBean 实现负责在 bean 构造期间调用 load()
方法,以根据被持久化的值初始化 MBean 的状态。
|
图 7 揭示了典型 JMX 代理的内部构造。请注意,代理内部的四种主要组件是 MBean 服务器、一组代理服务、连接器和协议适配器以及定制代理逻辑。
MBean 服务器是代理内部的核心组件。所有 MBean 在可以通过远程应用程序访问之前都必须向 MBean 服务器注册。当使用 MBean 服务器时,通过唯一的对象名对已注册的 MBean 进行寻址。远程管理器应用程序(或分布式服务)只能通过 MBean 的管理接口(已公开的属性、操作和事件)发现和访问 MBean。
代理还提供了一组代理服务,定制代理逻辑可以使用它们在 MBean 服务器中对已注册的 MBean 进行操作。为了符合 JMX 1.1,这些服务是必需的 ―所有代理都必须提供它们。有趣的是,可以用 MBean 本身的形式实现这些服务。以 MBean 的形式实现服务有几个优点:
- 可以通过 Manager 组件或 EMS 远程访问该服务的操作。
- 通过从远程管理器应用程序进行访问,EMS 可以远程地管理服务本身。
- 可以通过下载 MBean 在运行时动态地执行服务逻辑的更新。
表 3 显示了 JMX 1.1 规范中定义的一组代理服务。
m-let 或管理 Applet 服务 | 支持跨网络从 URL 位置装入动态类(请参阅 javax.management.loading.MLetMBean 和相关联的类/接口)。 |
监视器服务 | 将代价高昂的远程轮询操作转换成本地操作;监控 MBean 属性的特定更改并在观察到更改时发送事件。 |
计时器服务 | 经历了指定的时间量后发送事件,或以指定时间间隔定期发送事件(请参阅 javax.management.monitor.MonitorMBean 和相关的类/接口)。 |
关系服务 | 支持 MBean 之间的关系定义,并强制关系的完整性(请参阅 javax.management.relation.RelationServiceMBean 和相关的类/接口)。 |
增值代理逻辑通常是编写的代码。它是能够提供本地化智能的定制代理逻辑,用来管理向该代理注册的 JMX 可管理资源。例如,如果我们有两个冗余的应用程序服务器群集,就可以创建定制代理,监控负载级别并且动态地将入站请求重定向到不同的群集 ― 通过对已注册的服务器的 MBean 进行操作。通常,NMS 的供应商也会提供定制逻辑。一旦分布式服务的规范得以充实,可以预言,某种特定的定制代理逻辑将可以与定制远程 JMX 管理器组件良好地协作,以提供更高级别的网络管理功能。
代理不与分布式服务、NMS 或其它管理应用程序直接通信。而是使用连接器和协议适配器。这种体系结构与 J2EE 连接器体系结构(J2EE Connector Architecture)是一致的(请参阅 参考资料)。协议适配器是一种软件组件,它通过标准化协议(如 HTTP 和 SNMP)提供对代理管理的资源的访问。
连接器是一种专用软件组件,它提供了到代理和/或该代理上的受管资源的远程接口(通常使用诸如 CORBA 或 RMI 这样的远程过程调用技术来完成 ― 为了安全性通常通过 SSL)。当代理有多个活动的连接器和协议时,可以通过多个异构的应用程序或 NMS 同步地访问受管资源。可以用协议适配器来提供对现有的和已建立的 NMS 的向后兼容性。例如,我们可以为支持这个标准的 NMS 创建 通用信息模型/基于 Web 的企业管理(CIM/WEBM)适配器,或者可以创建 电信管理网络(TMN)协议适配器来启用由 JMX 代理管理的电信资源上的 操作、管理和维护(OAM)。JMX 连接器和协议适配器的精确规范属于正在同时开发的规范的范畴(请参阅 参考资料)。
|
构仅完整定义了工具和代理层,但它已经在基于 Java 的企业技术开发人员中赢得了广泛的支持。
2002 年 8 月 18 日提议的 J2EE v1.4 最终草案版本(请参阅 参考资料)详细描述了基于 JMX 的工具将如何成为 J2EE Web 容器(JSP/Servlet 引擎)、EJB 容器和应用程序客户机容器的标准部分。这是很自然的发展,因为基于 J2EE 服务器的广泛部署正使得可管理性成为明确的需求。(正如您可以想象的,在部署了数百台服务器的大型站点中,手工或专门配置、管理和监控几乎是不可能的。)
迄今为止,商业服务器产品已经通过专用方式或特殊添加物(使产品与现有 NMS 产品兼容)来支持可管理性。J2EE v1.4 规范中作为管理基础的 JMX 标准化,对于确保来自不同供应商的服务器产品普遍地与 NMS 兼容(并可由 NMS 管理)大有帮助。
实现的案例研究:Apache Jakarta Tomcat 4.1.x
Tomcat 4.1.x 服务器的最新 beta 测试版与 J2EE v1.4 规范保持一致,它已经集成了 JMX 工具。请参阅 参考资料一节以获得关于从哪里下载的信息。大多数 Tomcat 工具集中于配置组件,这些组件对应于 Tomcat 的 Catalina 引擎中的运行时对象。原本只能通过 conf
目录中的 server.xml
和 web.xml
文件更改的配置组件(如 <Engine>、<Host>、<Server>、<Service>、<Connector>、<Context> 和 <Realm>),现在都可以通过 JMX MBean 实现使用。
如果您研究一下 org.apache.catalina.mbeans
包(在源代码分发版或 API Javadoc 中),就会发现所有公开 Tomcat 配置组件的 JMX 工具 MBean 类。一些示例包括利用 <Context> 配置组件的 org.apache.catalina.mbeans.StandardContextMBean
,而 org.apache.catalina.mbeans.MemoryUserDatabaseMBean
利用 <MemoryUserdatabase> 组件。如果您研究实际的源代码,您将发现 Tomcat 4 工具广泛利用了 JMX 实现提供的模型 MBean 模板。
目前,Tomcat 4.1.x 使用 MX4J JMX 实现(一个开放源码许可的 JMX 实现),而不是 Sun 的参考 JMX 实现。但是,两个实现都是完全兼容 JMX 1.1 的。请参阅 参考资料一节以找到 MX4J 最新版本的链接。
广泛的 Tomcat 工具的一个立杆见影的好处就是可以很容易地创建一个基于 Web 的 GUI 管理应用程序。Tomcat 4.1.x 提供了一个称为 admin 的应用程序。应用程序本身是用 Struts 应用程序框架和 JSP 技术创建的。它通过本地 JMX 代理的 MBean 服务器访问所有的配置组件(与 server.xml 文件中定义的那些相同)。在 Tomcat 环境中,JMX 代理是由 org.apache.catalina.mbeans.ServerLifeCycleListener
类创建的。该类是一个在 Tomcat 启动和关闭时会调用的 LifeCycleListener
。
要尝试这个基于 JMX 的 admin 实用程序,首先您必须编辑 Tomcat 分发版的 conf
目录下的 tomcat-users.xml
文件。确保您为 tomcat 用户添加了 admin 角色:
|
<MemoryUserdatabase> 组件将使用该文件在运行时验证访问,要运行这个实用程序,用户必须具有 admin 角色。接下来,启动 Tomcat 4.1.x。
打开浏览器并输入 URL:
|
在登录页面,输入:
|
现在,请研究 admin 实用程序并观察 JMX MBean 是如何支持实时显示和修改 Catalina 配置组件值的。例如,图 8 显示了 <Context> 配置组件的属性的配置页面:
图 8. 基于 JMX 1.1 的 Tomcat 4 GUI admin 实用程序
当然,除了基于 Web 的 admin 应用程序之外,Tomcat 的工具支持由其它代理和 EMS 来管理它。
|
通过利用 Java 平台和谨慎的设计,JMX 达到了其设计目标:可伸缩性、低实现成本和与现有技术的兼容性。在下一篇文章中,我们将使用参考 JMX 1.1 代码,实现我们自己的标准 MBean 和动态 MBean,利用所需的模型 MBean 作为快速工具,并用 JMX 代理进行实验。
|
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- 下载 最新 JMX 规范、参考实现和兼容性测试套件。
- 要获得完全开放源码的 JMX 1.1 实现,也是 Jakarta Tomcat 当前使用的 JMX,请查看 MX4J项目。
- 有关 SNMP 的更多信息,请参考因特网工程任务组(Internet Engineering Task Force)的 RFC 1157文档,或者请参阅 SNMP 版本 3的最新进展。
- 有关 CIM/WEBM 的详细信息和最新进展,请查看 分布式管理任务组(Distributed Management Task Force)的网站。
- 可从 Jakarta 项目下载带有 JMX 1.1 工具的 Tomcat 4.1.x 服务器的最新版本。也可获取源代码分发版。
- 对于有关 JMX 分布式服务、协议适配器和连接器规范的正在进行的工作,请参阅 JSR 160 JMX Remoting 1.2、 JSR 146 WEBM Services和 JSR 70 IIOP Protocol Adapter for JMX。
- JMX 以一个代理连接器/适配器体系结构为特色,类似于 J2EE 连接器体系结构。
- J2EE 1.4 以为 JMX 提供完整的容器为特色。请下载新出现的 J2EE 1.4 规范的最新版本。
- IBM 的 Tivoli软件以安全的企业管理解决方案为特色,这些方案支持各种现有的和新出现的网络管理标准,包括 TMX4J― 一个可从 alphaWorks 获取的兼容 JMX 的实现。
- 请一定要访问最新的 developerWorks产品园地的 Tivoli Developer Domain Lite以获取关于 Tivoli 软件和安全性产品的技术信息。
- 请在 developerWorks Java 技术专区上查找数百篇与 Java 技术相关的参考资料。
发表评论
-
始终会用上的Common BeanUtils
2007-12-12 09:27 1167Beanutils用了魔术般的反射技术,实现了很多夸张有用的功 ... -
代理模式之理解
2007-10-17 17:22 2027代理模式解决不同请求和相应的目标对象的中介作用,实现面向接口编 ... -
DAO编程模式(转)
2007-10-12 14:55 1389J2EE开发人员使用数据访 ... -
Learn techniques for building better DAOs
2007-10-12 13:57 1414Software Engineer 7 October 200 ... -
JAVA设计模式之事务处理
2007-10-12 11:08 1152事务处理是企业应用需要解决的最主要的问题之一。J2EE通过JT ... -
JAVA字符集
2007-07-03 16:34 9591. 概述 本文主要包括 ... -
多级反向代理[Squid]下获取客户端真实IP地址
2007-06-18 17:05 5721多级反向代理[Squid]下获取客户端真实IP地址 在很多应 ... -
导入导出
2007-04-11 16:35 1292How to create a new workbo ... -
汉字按拼音排序
2007-04-05 16:11 20911。将要排序字符串设置成GBK编码 2。自定义一个类,实现Co ...
相关推荐
《打开量化投资的黑箱》是一本深入探讨量化投资策略和技术的书籍,特别是第二版更加深入地揭示了这个领域的精髓。量化投资,顾名思义,是借助数学模型、统计方法和计算机编程来做出投资决策的过程,而Python作为当今...
1. **整体优化**:黑箱理论强调的是从整体的角度来考察系统,而不是仅仅关注局部细节。这意味着在分析问题时,会更多地考虑系统各个组成部分之间的相互作用以及它们与外部环境的关系。 2. **功能导向**:相较于结构...
打开量化投资的黑箱 分享
MATSuMoTo是MATLAB(矩阵实验室)中的一个代理模型工具箱,专为构建和分析黑箱模型而设计。黑箱模型是一种不依赖于内部结构或机制,仅根据输入和输出数据来描述系统的数学模型。在工程、科学和数据分析领域,这种...
Python核心技术与实战 06-Python“黑箱”:输入与输出.pdf
面对算法黑箱引发的问题,需要从技术、法律和伦理三个角度进行法治化管理: 1. 技术角度 开发更加透明的算法模型,采用可解释性更强的技术,如增强机器学习模型的可解释性。此外,实施算法审计,对算法的设计和决策...
"2022 可解释 AI 发展报告:打开算法黑箱的理念与实践" 本报告旨在探讨可解释 AI 的发展趋势和实践经验,旨在打开算法黑箱,提高 AI 的透明度和可靠性。 一、可解释 AI 的必要性 随着 AI 技术的普及和应用,人们...
**第四章 从典型案例分析我国企业内部控制存在的问题** 1. **内部控制环境不理想**:企业文化建设缺失,管理者观念落后,阻碍了内部控制制度的实施。 2. **监督机制不健全**:缺乏有效的内部监督,无法及时发现和...
### 揭秘黑箱:YOLO预测结果的可解释性探究 #### 1. 引言 在深度学习领域,模型的可解释性一直是研究者和开发者关注的重要议题。随着模型变得越来越复杂,如何理解这些模型如何做出决策成为了至关重要的问题。YOLO...
3. 调节行为的起源:从维纳的控制论到艾什比的学习机制,企业管理中也寻求类似动态平衡的自我调整机制,以适应内外部环境的变化。 4. 目的性、大脑和学习机制:组织如生物体一样,具有目标导向和学习能力,企业通过...
综上所述,现代企业理论与公司治理涵盖了从企业诞生、组织形态、决策过程到治理结构的多个方面,揭示了企业如何在市场中生存和发展的深层次逻辑。这些理论为理解企业行为、设计有效的企业政策以及优化公司治理提供了...
这篇文档是关于管理学试题的答案集,涵盖了名词解释、填空题、单项选择题、多项选择题、简答题和论述题等多个部分,主要涉及管理学的基础概念和理论。以下是其中的一些关键知识点: 1. **管理**:管理是指在特定...
相关系数的值介于-1和1之间,其中-1表示完全负相关,1表示完全正相关,0表示无相关。计算结果表明,成分A和成分B的含量之间的相关系数为0.85,这表明它们之间存在强的正相关关系。 因此,通过黑箱建模作业11,我们...
民营企业作为市场经济的重要组成部分,其内部控制和风险管理的健全性直接影响到企业的稳定运营和持续发展。本研究主要关注民营企业在内部控制和风险管理方面的理论与实践,旨在提出一套适合民营企业特点的风险管理...
本文将从“创业黑箱”、“团队建设”、“商业化路径”以及“节奏路径策略”四个方面展开讨论。 首先,创业是一个黑箱,表面看似简单的商业模式背后隐藏着复杂的运作机制。创业者往往只能看到产品和服务,而忽视了...
用多用电表判断黑箱内电学元件的问题PPT课件 本PPT课件主要讲解了如何使用多用电表来判断黑箱内电学元件的问题。黑箱问题是电学中的一种常见问题,即不知道黑箱内部电路的结构和组成,需要通过外部接线柱的测试结果...
1. **多用电表的基本原理与使用**: 多用电表是一种集电压表、电流表和电阻表于一体的便携式测量工具。使用时,红表笔通常代表正极,黑表笔代表负极。在测量电压时,电流应从红表笔流入多用表,而在测量电阻时,...