分布式组件在外贸ERP应用中的研究
上海交通大学
硕士学位论文
分布式组件在外贸ERP应用中的研究
姓名：邓玉洁
申请学位级别：硕士
专业：计算机应用
指导教师：张忠能
20040108
分布式组件在外贸ＥＲＰ中应用的研究
摘要
本文研究了分布式组件模型在外贸ＥＲＰ中的应用
并实现了其中部分功能
ＯＯＡＯＯＤ
深入探讨了建立ＥＲＰ系统的组件对象模型的面向对象分析方法和设计方法以及实现过程中的国际化问题
其过程是通过标识系统用户和他们的整体责任最后建造分析模型需要对ＯＯＡ模型进行细化和扩充对组件的组织进行设计
在实现方面以ｗｅｂ方式作为客户端供用户使用而采用Ｏｒａｃｌｅ作为后台数据库由于ＥＲＰ系统的新的发展趋势和需求国际化大致可以分为以下几个方面的问题２． 后台组件本地化
本文用ｓｔｒｕｔｓ解决问题１但问题３和４还需要进一步研究寻求解决方案采用Ｊｂｕｉｌｄｅｒ
使用Ｗｅｂｌｏｇｉｃ作为应用服务器
构建了一个分布式的组件开发平台信用证管理
系统建立的虚拟企业开发模式可应用于一般中小型外贸企业的ＥＲＰ的深入研究中
分布式组件ＥＲＰ，ＥＪＢ， 工作流
ABSTRACT
This paper works over the application of distributed component model (EJB) in foreign trade ERP, and creates a architecture with ERP system kernel, and implements some functions.
This paper discusses the merits and limits on OOA and OOD, and the strategy of designation and implementation the component object model of ERP, and furthermore discusses the OOA, OOD methods to create ERP system component object model, component design and implementation methods, at the same time, discusses the internationalization, design and implementation of database.
OOA mainly uses Jacobson method, the process is to create requirement model through marking system’s users and their totalresponsibilities, then construct analyse model. During component design phase
management a nd credit management are implemented, message transfer is also supported by the system. Because the system’s business tier is composed by EJB components, the system can be distributed in network and it can be maintained easily, also has more scalability and ability of expansion of function.
KEY WORDS: Distributed component, RMI
附件四
上海交通大学
学位论文原创性声明
本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行研究工作所取得的成果。除文中已经注明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的作品成果。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律结果由本人承担。
学位论文作者签名：邓玉洁
日期： 2004 年 1 月8 日
附件五
上海交通大学
学位论文版权使用授权书
本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权上海交通大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
保密□，在 年解密后适用本授权书。
本学位论文属于
不保密√□。
（请在以上方框内打“√”）
学位论文作者签名：邓玉洁 指导教师签名：张忠能
日期： ２００４ 年 １ 月 ８ 日 日期：２００４ 年 １ 月 ８ 日
第一章绪论
1.1 ERP简介
ERP是一个信息高度集成的企业管理系统，它是经过20世纪70年代的MRP 和80年代的MRP Ⅱ发展而来的。从功能上看，MRP Ⅱ面向企业内部产、供、销以及财务的信息集成，而ERP则是在MRP Ⅱ的基础上向供应链和价值链管理的扩展，它在强调提高企业内部效率的同时，更注重与企业外部资源，如供应商、客户等业务合作伙伴的协同。从这个意义上说，ERP的主体“E”已不仅仅是实施ERP的企业本身，而是包含该企业整个供需链的的虚拟企业。进入90年代，随着市场竞争的进一步加剧，企业竞争空间与范围的进一步扩大，80年代MRP Ⅱ主要面向企业内部资源全面计划管理的思想逐步发展为90年代怎样有效利用和管理整体资源的管理思想，ERP（Enterprise Resource Planning）——企业资源计划也就随之产生。ERP是在MRP-Ⅱ的基础上扩展了管理范围，给出了新的结构。
根据统计，典型的制造业，若从企业的增值活动链进行分析，只有10％到35％是直接投入在生产产品上，其余65％到90％的活动，都是知识性或服务性的活动。所以，以高新技术为核心，以信息电子化为手段，提高工业产品的附加值以及成为现代工业企业一个重要的发展目标。
ERP系统是实现该目标的重要手段之一，通过建立企业内部的高度集成管理信息系统，达到企业内部的信息共享，提高管理效率，强化运作流程，降低管理成本，减少运营风险、优化资源配置，并快速的对外部环境的变化做出响应，从而使得企业能够发挥出自身的最大潜力，提高在市场上的竞争力。
随着我国市场经济和现代企业制度的建立，社会经济模式和企业管理方式日渐和国际接轨，出现了ERP系统的应用热潮。可以预见，随着我国经济体制改革的日益深化，全球经济一体化步伐的加快，ERP系统在我国将会有更广阔的应用前景[1]。
1.2 ERP系统面临的问题
企业当前的内外部环境，要求外贸ERP系统一般应具有如下一些特点：
实施灵活：每一部分即可独立运行，安装在一起又可相互配合，共同工
作。这样才能满足不同规模，不同层次，不同类型的用户要求。
维护便捷：企业需要快速的对市场环境的变化作出响应。包括迅速改造自己业务流程以适应外部环境的变化。
跨国应用和多点多厂：即使一家不大的公司，其子公司何下属部门也可能分部在世界上多个不同的地点。
弹性的负荷能力：企业的规模可能增长很快，系统的性能不应该因为企业规模的增长而迅速下降。
然而，对于传统的两层结构的软件系统来说，却很难满足以上的要求，另外系统也存在其他的一些问题，总的说来，ERP系统目前存在着以下几个问题： 系统升级和维护困难
整个软件系统一般由单一的或几个大的应用程序组成，对系统任何微小的修改都需要对整个系统或其中一个大的模块重新进行编译和发行，无论是对企业还是对于软件供货商，都需要消耗大量的人力和时间，这种软件升级的过程不是平滑无缝的。另外，业务规则既分布于客户端，又存在于服务器上，因此对业务规则的改变是非常困难的。
不具有良好的扩充能力
随着企业规模的增长，系统的性能会下降，通过升级数据库服务器或所有客户机的硬件来提高性能显然是一项高成本的工作，同时升级数据库服务也有一定的风险。
对企业的限制较多，实施不够灵活
正因为对ERP软件的升级和维护困难，所以ERP供应商一般是一整套尽可能大而全的系统来适应各类企业的不同需求。在设计ERP系统时，一般就已经确定了一个标准的模式，即定义了一套标准的业务规则。在实施过程中，ERP 供货商会同企业内部的管理专家进行商讨，对企业管理方式、业务流程实施改造，并使企业的业务流程尽可能接近系统所定义的标准模式，然后对系统中不适应企业真正需求的具体细节进行修改，最后才会安装系统交付用户使用。这种方法虽然使得企业管理方式更加规范化，但同时也使得企业在管理上失去自己的特色，在管理上难以创新。同时，对大部分的中小企业来说，在内部管理的很多环节上并不需要向大型企业那样严格控制，ERP系统设定的标准运作模式限制了中小型企业自身的灵活性。
1.3 分布式计算简介
简单的说，分布式计算是两个或多个软件相互共享信息。这些软件既可以在通一台机器上运行，也可以在通过网络连接起来的几台不同的机器上运行。绝大多数分布式计算是基于客户/服务器模型的。
相对传统的客户/服务器体系结构，分布式计算现在更倾向于用来指一种多层的体系结构。在这种多层的体系结构中，有多个机器（软件）互为客户/服务器，他们相互协作，共同完成一次事务[2]。
1.3.1分布式计算的优点
客户端软件变简单了，硬件要求也相应降低。
数据库服务器的工作更单一，对数据库服务器的性能要求也会降低.
系统具有很好的扩展性能：当系统规模增大或用户数目增多时，可通过增加业务层服务器的数目来分担负载，数据库服务器在系统负载增加是
不会受到显著影响。
平衡计算负载：当系统用的某台服务器因用户数目增加而导致性能显著下降时，可以通过引导部分用户到另外一台负载较轻的服务器上。
1.3.2布式计算的支持机制
目前，能够较方便的支持这种分布式计算而不用考虑底层的网络通信问题的机制主要有3个：OMG（对象管理组）制定的一种面向对象应用程序体系规范CORBA；Microsoft推出的DCOM以及SUN推出的EJB[3]。
Enterprise JavaBeans 技术把 Java 组件的概念从客户机域扩展到了服务器域：这是 Java 技术成长过程中有重大意义的一步，它使 Java 技术发展成为一种强健的、可伸缩的环境，能够支持以任务为关键的企业信息系统。采用Enterprise JavaBeans环境可以获得以下好处：
EJB组件使编写应用程序更为简单。尽管EJB体系结构复杂，但应用程序开发人员一般不必在编写用于访问系统服务的代码。一种称为EJB容
器的系统组件使系统服务可用于EJB组件的任务。
服务器端商务逻辑可以移植。除了 Java 语言固有的可移植性外，EJB 体系结构还在 bean 和支持该 bean 的容器之间提供了一套标准化的应用
程序编程接口。这使开发人员能够将 bean 从一种操作环境移植到另一
种操作环境，而无须重新编写其源代码。
可以从现有的软件组件装配出服务器端应用程序，这于从现有的Java Bean可以装配出客户端应用程序是一样的，从而使软件能够重用。
EJB体系结构内置了对典型企业级系统服务的支持，包括分布式对象、事务处理、数据库、安全和全局命名。
多家 IT 供应商都采纳 EJB 体系结构，这是由于有这样的承诺：客户将能够从选定的供应商那里选购软件组件，如EJB组件、容器及EJB服务
器；也由于承诺了不同供应商的产品，只要符合EJB体系结构，就都是
可互操作的。
用 EJB 组件构建的应用程序可以从一个服务器移植到另一个服务器，从而支持可伸缩性，这是因为在 EJB 模型中，各个软件组件都是严格分离
的。
EJB 体系结构能保障原有的IT 投资，这是通过允许将现有的信息系统和资产“包裹”在这些应用程序中，而不要求客户更换现有技术。事实
上，在关系数据库中存储数据的企业已经有了一套已有雏形的实体 bean，正等着通过EJB外壳去访问。
1.3.3 外贸ERP与分布式计算的结合
前面讲述了采用EJB实现分布式计算机和分布式计算的一些优点。在ERP系统中引入分布式计算，可以在较大的程度上缓解ERP系统在设计、维护及实施过程中的一些问题。
利用EJB实现分布式的ERP系统，系统将具有很好的扩展性、灵活性和安全性。这种可扩展性通过EJB组件的相对独立性及EJB组件的互操作性实现的。系统在开发初期，并不需要以大而全的系统为目标，可以开发一些基本部件，其他部分以后可以插入到原有的系统中，并重新设计原有部件的一些内部实现方法，这些新旧部件就可以一起工作了。而重新设计组件内部的实现方法是很容易的。
分布式计算中倾向于三层客户机/服务器应用程序使用一个中间或中间层，应用程序服务器，它在客户机应用程序和后端数据库之间操作。中间层存储了系统的商业逻辑和服务（如安全性和事务），并协调客户机上后端数据库交互的显示。这样的三层系统更有可伸缩性和可用性，同时也提高商业系统灵活性和可扩展性。
另外，由于客户机于中间组件是以Java语言实现的，那么极有可能具有可
移植性。可以非常容易地将实现客户机和应用程序服务器的类文件重新安置在当前最合适的主机上。
1.4 分布式组件技术介绍
今天，世界上主要的三种分布式组件对象标准有：OMG（对象管理组）制定的一种面向对象应用程序体系规范CORBA；Microsoft推出的DCOM以及SUN 推出的用JA V A开发的RMI。
传统的面向对象技术有两个基本的特点：封装性和继承性，通常其强调的是代码复用，对象往往仅存在于一个程序中，程序的外界并不可能感知和访问这些对象。而分布式对象技术主要使用了面向对象技术的封装性，组件可以分布在网络的任何位置。对外界来说，它所需关心的只是组件的界面，至于内部是如何实现的则无需考虑，远程客户通过方法调用来访问它。这是分布式对象技术和传统的面向对象技术的最大的不同点。
1.4.1组件对象模型
组件对象模型是描述可重用组件和组件之间如何相互作用以实现具体应用规范。一个有效的组件对象模型应该满足以下基本要求：
接口可靠性：组件接口是不应该改变的，一旦组件被发布，接口就应该保持不变，这是组件使用者对组件的基本要求。这样可以保证一旦组件
使用者通过某接口得到一项服务后，就一定能够从这个接口得到服务。
因此，组件被封装后，只能通过已定义的接口来提供合理、一致的服务。
这种接口定义的稳定性使客户应用开发者能构造出坚固的应用。
可扩充服务：每个组件都是自治的，有其独自的功能，只能通过接口和外界通信。当一个组件需要提供新的服务时，可以通过增加新的接口来
定义，新的接口不会影响系统已经存在的用户。
提供有效的基础服务：这些基础服务时组件获得可重用性、可移植性和可互操作性的有效保证。这些基础服务包括分布式对象的透明访问、请
求事务服务、系统资源管理等。
具有构建和部署组件的工具：在设计与其它应用程序接口时，利用构建和部署工具可以方便地增加和替换应用的组件，或者改变运行中组件的
运行属性。这样可以充分发挥组件可重用的优势，实现了客户应用程序
的组装和升级。
1.4.2 分布对象的基本结构
分布对象系统是现代三层结构的基础，所有的分布式对象协议都建立在相同的基础结构上，这种结构实现了分布式对象的位置透明。位置透明表示一个服务对象的真正位置，使用对象的客户端并不需要知道。结果是分布在不同计算机上的对象看上去好像在本地机上一样。
远程方法调用（Remote Method Invoke, RMI）是实现分布式对象间位置透明性的机制。从本质上来说，这种结构分为三个部分：对象服务器、架构（Skeleton）和存根（Stub）。
对象服务器是位于中间层上的商务对象，之所以称之为“服务器”，是为了把它和相对应的Stub类和Skeleton类区分开。每个对象服务器类都会有与之相对应的stub类何skeleton类。比如，一个名叫Person的分布式商务对象和有相应的Person_Stub类和Person_Skeleton类。对象服务器和Skeleton分布于中间层，而Stub分布于客户端。
Stub类和Skeleton类一起负责生成中间层上的对象服务器，使得对象看上去是在本地的客户机上运行。当一个应用被部署好之后，中间层上的每个对象服务器的实例都被相应的Skeleton类的实例所包装，Skeleton在中间层上的一个IP 地址和端口上监听Stub发来的请求：Stub类被部署在客户机上，并通过网络通信层与Skeleton相连。Stub类作为对象服务器在客户端的代理，负责通过Skeleton 将请求从客户端送到对象服务器。
图1-1说明了从客户端到服务器对象和从服务器对象返回的方法调用的通信过程。
图1-1 RMI通信过程图
Figure 1-1 The process of RMI communication
Stub和Skeleton对象封装了客户端和中间层之间RMI协议的详细通信过程。使用分布式对象结构的开发者不需要关心RMI协议的细节，只需要使用Stub对象提供的接口就可以了。Stub用与对象本身相同的商务方法实现了一个接口。当Stub的方法并不包含商务逻辑，它实现了所有将请求送到对象服务器上而且得到结果的网络操作[4]。当客户端使用一个Stub上的商务方法时，通过将使用的方法名和值作为参数传递给Skeleton（图中步骤1和步骤2）；当Skeleton接收到进来的数据时，它通过解析数据确定哪个方向被调用了，然后调用对象服务器上的响应的商务方法（图中步骤3）。所有通过Skeleton从对象服务器上的方法得到的值都通过网络返回给Stub，然后由Stub将值返回给客户端应用程序（图中步骤4和步骤5）。
以上过程被称为RMI循环。RMI循环是分布式对象系统的基础，它实现了分布式对象的位置透明。需要注意的是，虽然客户程序可以向使用本地对象一样使用远程对象，但理解RMI循环是如何实现位置透明是很有必要的，在设计时不能将分布对象认为是本地对象，因为他们的执行情况是不同的。(本地对象:指分布在同一个独体系统中的对象，互称为本地对象[5]。)
真正的分布式对象协议提供了比上面解释的RMI循环更多的分布式对象基础结构。特别地，他们都提供了为对象服务器自动生成合适的Stub和Skeleton 的方法和工具，就更不需要客户自己开发这些结构了。而且他们还允许在Stub 和Skeleton中包含更多的功能。
1.5 DCOM 与RMI比较
DCOM：用IDL定义接口，它是从Iunknown继承来的。激发代理/桩，用类工厂实现服务器。服务器主程序创建新的类工厂，用信号通知事件，然后等待，直到对象被COM库删除。客户端使用CoCreateInstance()创建接口指针。用QueryInterface()访问另外的接口，用接口指针来调用。对于众多熟悉Windows 的程序员而言, DCOM程序开发是非常简便的。
DCOM依赖于对象远程处理过程调用（OPRC）以达到相同的目的。
DCOM的优点：1)广大的用户基础和组件市场；2)二元的软件集成：大规模的软件复用，跨语言的软件复用，COTS工具的复用；3)在线软件更新:允许在一个应用程序中更新一个组件，而不需要重新编译，链接或启动；4)每个对象多个接口；5)编程工具有多种选择。
但DCOM它由单一开发者(Microsoft)定义并控制,这大大限制了DCOM使用者
的选择范围。另外,DCOM缺乏众多的平台支持,这极大程度地制约了代码的可重用性和DCOM应用的可扩展性。
RMI：用JAVA定义接口（继承java.rmi.Remote接口）每个方法必须在java.rmi.RemoteException中定义。实现时，需要有以下几步：继承java.rmi.server.RemoteObject，实现每一个远程方法，安装安全管理，创建一个或多个实例，在bootstrap registry中注册远程对象。写客户端applet或application时，参考registry。然后编译文件，用rmic启动stubs和skeletons，最后设置路径并发布。
RMI系统包括框架层、远程引用层和传输层。目前，RMI的传输层是基于TCP 实现的，将来的RMI体系结构建立在IIOP协议之上，可以实现，Java技术与CORBA 技术的深层融合。
RMI的优点：单一的语言开发。可以平滑的集成到 JAVA，简洁的编程模型，在浏览器端可以跨平台执行。每个对象有多个接口，真正的多态计算能力，即客户端可以传送代码给服务器执行。对异构环境有着很强的支持，这是由 JAVA 良好的跨平台特性所支持的，但它对集成的支持却很弱。
1.6 课题研究目的
在调研和做课题的过程中，我们并没有把目标仅限于开发一个只适用于某企业目前需要的管理信息系统，而是期望能有更广泛的使用范围和更好的应付日后需求变化的能力，ERP成功的关键请参见文献[5]。正是在这一想法的驱动下，了解了ERP的基本原理，考虑到现在网络社会的发展趋势，研究了分布式组件技术，希望在ERP系统的基本框架中采用分布式技术来实现一种健壮的、便于升级和维护的、高扩展性的ERP核心系统。同时建立一个针对本行业更一般、更能被广泛被复用的组件对象模型以及底层的一些框架。这也正是本课题研究的目的。
1.7 论文章节安排
全文共分为六章，各章内容安排如下：
第一章：绪论：主要是对ERP和分布式组件技术的介绍。
第二章：EJB模型体系结构：介绍以RMI为通信基础的EJB模型体系结构。
第三章：面向对象的系统分析：用面向对象的Jacobson方法对本系统进行分析，得出分析模型。
第四章：三层结构的系统设计：从客户层，业务层，数据层对系统进行设计。
第五章：系统框架及部分功能实现：提出系统的整体框架以及它部分的功能实现。
第六章：总结与展望。本章将对全文工作进行总结，对在本文基础上的后续工作进行概述。
第二章 EJB模型体系结构
本节着重介绍EJB模型的基本概念Bean和容器（Container），并就EJB体系结构中的角色、应用EJB带来的好处进行探讨[6]。
2.1 企业JavaBean
SUN公司对EJB的定义是：EJB的结构是开发和配置基于组件的分布式商务应用程序的一种组件结构。用EJB结构开发的应用程序是可伸缩的、事务型的、多用户安全的。这些应用程序可能只需编写一次，而可以在支持EJB规范的任何服务器平台上配置。这个定义显得有些冗长。简单的说，EJB结构是一种分布式的服务器端组件模型，用来开发安全的、可扩展的、多用户的组件；而EJB就是一些包含业务逻辑的可重用的软件单元。EJB是以RMI为通信基础的。
每个企业Bean由下列部件构成：企业Bean类、企业Bean客户视图API和部署描述符。
2.1.1企业Bean类
企业Bean类是一个java类，它实现了业务方法以企业Bean对象生命周期的方法。企业Bean类也可以使用其它的帮助类或者整个类库来实现业务方法。
有三种企业级的Bean：会话Bean（Session Bean），实体Bean（Entity Bean），和消息驱动Bean（Message-driven Bean）。会话Bean表示与客户端程序的临时交互，当客户端程序执行完后，会话Bean和相关数据就会消失；相反，实体Bean 表示数据库的表中一行永久的记录，当客户端程序中止或服务器关闭时，就会有潜在的服务保证实体Bean的数据得以保存。消息驱动Bean结合了会话Bean和JMS的消息监听器的特性，允许一个业务层组件异步接收JMS消息[7]。
2.1. 2企业Bean客户视图API
企业Bean客户视图API是由企业Bean的home接口和企业Bean的远程接口构成的。企业Bean的home接口定义了create、remove以及查找方法，他们控制着企业Bean对象的生命周期；企业Bean的远程接口定义了客户在这个特定的企业Bean对象上能够调用的业务方法。在远程接口中的业务方法以及home
接口中的create和查找方法，反映了各个特定Bean的需求，从而随企业Bean的不同而不同。
2.1. 3部署描述符
部署描述符（Deployment descriptor）也叫配置描述符，是一个XML文档。它包含有关此企业Bean的声明信息。这个信息是为企业Bean的应用程序装配者和部署者准备的。部署描述符也包含了这个企业Bean的环境项声明。这些声明用来将企业Bean定制到运行环境中去。
使用部署描述符可以说明性地定义企业Bean的某些行为，例如它的事务处理方式或者它的数据库模式，而不是在Bean中通过编程定义行为。
2.2 容器
企业Bean实现了一个应用的业务逻辑，但是企业Bean本身并不是一个完整的可操作的应用。首先必须将一个企业Bean部署到一个容器中去，这样这个企业Bean才能成为一个可运行应用的一个部分。
一个完整的应用是由企业Bean、容器和容器所生成的容器元素构成的。容器包含了应用所需的系统级服务的实现，容器元素使得容器能够将这些系统级服务插入到应用中。也就是说，容器使用这些生成的元素干预客户对企业Bean的调用，这样容器就能够实现系统级服务的插入。
2.2.1容器定义
容器的概念不仅仅局限于EJB，它是整个J2EE体系结构中一个用来管理应用程序组件，提供访问J2EE API的运行环境，并向运行在其中的组件提供系统级服务器。J2EE定义了四种容器，当然其中最重要的是EJB容器[8]。图2-1描述了这四种容器。
1、EJB容器管理所有J2EE应用程序中企业级Bean的执行。Enterprise Bean
和它们的容器运行在J2EE服务器上。
2、Web容器管理所有J2EE应用程序中JSP页面和Servlet组件的执行。Web 组件和他们的容器运行在J2EE服务器上。
图2-1 J2EE的四种容器图
Figure 2-1 Four containers in J2EE
3、应用程序客户端容器管理所有J2EE应用程序中应用程序客户端组件的执
行。应用程序客户端和他们的容器运行在客户机上。
4、Applet容器是运行在客户端机器上的Web浏览器和Java插件的结合。
2.2.2容器元素
容器元素是由容器在部署企业Bean时生成的额外类，这些类对于企业Bean 绑定到容器运行时环境是必须的。在这些容器元素中，最重要的是实现企业Bean 的home接口和远程接口的类。由于EJB体系结构的目标是让客户在网络上通过home接口和远程接口访问企业Bean，所以实现企业Bean的home接口和远程接口的不是简单的java对象，而是分布式对象。他们具体实现了一个远程客户与部署在容器中的企业Bean间的通信。目前，EJB规范没有规定客户与容器之间使用的分布式对象协议，但很多容器的实现都使用了RMI-IIOP .当容器基于RMI-IIOP时，容器工具通常生成两个RMI-IIOP对象，如2-2图所示。
KsztBean是开发者实现的企业Bean类，KsztHome和Kszt分别是开发者定义的home接口和远程接口。KsztRMI和KsztHomeRMI是容器生成的RMI-IIOP
对象类型，KsztHomeRMI对象类型提供了企业Bean的home接口KsztHome的实现，KsztRMI对象类型提供了企业Bean的远程接口Kszt的实现。
RMI-IIOP对象类型的实例是实现客户与企业Bean之间通信的分布式对象，客户与RMI-IIOP对象类型的实例直接通信而从不与企业Bean类的实例直接通信。因为容器提供了KsztRMI对象和KsztHome对象的实现，所以这些对象在将客户调用的方法委托给企业Bean实例时具有插入容器服务的能力[7]。
create()
remove()
find()
debit() credit() getBalance()ejbCreate() ejbFind() ejbRemove() debit() credit() getBalance()
图2-2 容器元素 Figure 2-2 Container element
2.2.3容器提供的服务
容器为部署在其中的企业Bean提供下列服务：分布对象协议、线程管理和同步、事务处理、安全、状态管理、资源共享、数据存取、系统管理支持、高可用性及群集。下面表2-1描述了这些容器运行时服务[9]。
表2-1 容器的服务
table 2-1 Container’s services
服务种类 描 述 带来的益处
分布式对象协议 容器实现了用于企业Bean和他们的客户之间
通信的分布式对象协议。
例如，如果容器对于与客户的通信使用
RMI-IIOP,那么容器就包含了一个ORB和
RMI-iiop运行时类库。容器在部署企业Bean
的home和远程接口时自动地生成RMI-IIOP
的Stub和Skeleton。
使得企业Bean开发者只需要
编写本地Java代码，开发者
不必实现分布式管理。
线程管理和同步 容器负责启动和停止线程，当需要服务于多个
客户请求时，容器同步这些线程以避免并发地
激活一个企业Bean的方法。
企业Bean开发者编码这些业
务方法好像企业Bean实例只
被一个用户使用。
事务处理 容器按照部署描述符中的信息管理事务处理。
基于部署描述符中的指令，容器可以：
－将一个方法调用包装在一个事务处理中
－直接运行方法
－引入客户端发起事务处理
如果一个方法在事务执行时，那么容器会将这
个事务处理扩散到资源管理器和此企业Bean
所调用的其它企业Bean，并执行事务处理的
提交协议。 企业Bean开发者不必实现分布式系统中事务处理所需的负责管理。
安全 容器在准许一个客户访问一个企业Bean的业
务方法时执行安全检查。容器在委派一个客户
调用之前检查客户是否被授权来调用一个业
务方法。 企业Bean部署者和系统管理员可以使用部署和管理工具来设置安全策略以满足应用的需要。
状态管理 容器负责企业Bean的状态管理，并优化资源
的使用。容器在需要释放资源时可以钝化
(Passivate)一个企业Bean对象；以后这个对
象被一个客户端调用时，容器激活（Activate）
这个对象。 由容器进行状态管理意味着应用能够达到一个高质量用户要求的可伸缩性，而企业Bean开发者的负担很小。