企业计算中的Java
概述
长期以来，Client/Server结构一直是企业计算中使用最普遍的计算架构之一。但广大用户在享受C/S结构带来的利益时，也忍受着越来越大的成本投入和使用与管理上的麻烦。
在C/S结构当中，几乎所有的应用逻辑都在客户端实现，导致客户端的应用程序越来越复杂，也给开发人员带来了大量的移植工作；同时要维护如此“肥”且节点众多的客户机更是一件庞杂的工作。
Java给上述问题的解决带来了曙光。跨平台和从服务器下载执行等特性使Java技术在企业计算中得到越来越多的应用。C/S正逐渐退出舞台，代之而起的是一种新的分布式计算架构：三层次（3－tier）企业计算架构。
三层架构中处于第一层的是客户端表示层。与C/S结构中的“肥”客户端不同，客户层仅仅是整个应用系统中的图形用户界面表示，不表示任何应用逻辑，其运行代码可以从位于第二层的Web服务器下载到本地的浏览器中执行，几乎不需要任何管理工作，是我们平时说的“瘦”客户机；处于第二层的是应用服务层，由一或多台服务器（Web
服务器也位于这一层）组成，处理企业应用中的所有业务逻辑和对数据库的访问等工作，该层具有良好的可扩充性，可以随着应用的需要任意增加服务器的数目（构成“宽”的服务器层）；处于第三层的是数据中心层，由数据库系统和企业中的已有系统组成。
比三层计算更新的概念是多层计算，主要是将三层计算中的应用服务层继续细分为Web服务器层和应用服务层，Web服务器不再处理任何业务逻辑，而只是将处理请求转发到相应的应用服务单元。
在多层计算中，用户的开发工作主要集中在应用服务层进行，许多中间件(Middleware)厂商推出了各自的应用服务器中间件产品，负责提供较底层的服务如负载均衡、状态监测等，以便用户能够将大部分精力集中在业务逻辑的开发。
Java为多层计算中的每个层次都提供了强大的技术。Java
2平台的JFC所提供的客户端技术，成为开发客户图形用户界面的首选。在应用服务层和数据中心层，包括Servlet、RMI、JDBC、Java
IDL在内的四种技术能够让企业快速地开发他们的分布式应用；对于市场上各式各样的中间件产品，Java也提供了独特而有效的解决方案。Java技术正逐渐成为企业计算的潮流。
Java分布式计算技术
下面分别介绍一下Servlet、RMI、JDBC和Java IDL等四种技术在企业计算中的应用和它们的技术特点。
1．Servlet
与applet是采用Java语言编写的在客户端浏览器中运行的小应用程序相比，Servlet是采用Java编写的在服务器端运行的小应用程序。正如applet扩展了Browser的功能一样，servlet扩充了Web
server的功能。Servlet （实际上专指HTTP Servlet）需要一个位于Web
server的运行环境（Jeeves）做支撑，目前市场上的大部分Web服务器如IBM、Netscape等都已经支持Jeeves.
在以Web为中心的应用中，用户通过访问企业Web站点上的主页请求需要的应用服务，由Web站点将服务请求传递给相应的业务逻辑处理单元（business
logic object）进行处理，并将处理结果返回给Web站点，再由Web站点将结果送回到用户的浏览器中。如图：
在传统的基于Web的应用中，CGI (Common Gateway Interface)程序在上述处理过程中扮演着重要的角色，用户的处理请求将由Web服务器调用相应的CGI程序（业务逻辑处理单元）来完成。但是CGI程序本身存在着许多缺陷。当用户的请求需要启动CGI程序来完成时，Web服务器将启动一个进程（process）来运行该CGI程序，由于进程对于系统资源有较大的消耗，一旦在某个时刻有大量的访问者访问该Web站点（这种情况经常发生），Web服务器的性能将直线下降。另外每个CGI程序都需要有一个相应的脚本描述程序（script），由于CGI的开发缺乏IDE(Integrated
Developing Enviroment)工具的支持，这使得CGI的开发工作变得非常繁琐，尤其是在编写脚本描述程序的时候。
Java对此的回答是Servlet。与每个CGI程序都占用一个进程不同，每个Servlet
在运行时只占用系统的一个线程（Thread）。与进程相比，线程对系统资源的消耗要小得多，在很大程度上保证了系统在有大量的用户访问时仍能保持良好的性能。目前Servlet
技术不但正被越来越多的 Web server所支持，而且正被越来越多的应用服务器（Application
Server）中间件开发商所采用，如WebLogic 公司的Tanga、ATG的Dynamo等产品都已完全支持Servlet。Servlet与协议无关，HTTP
servlet只是其中的一种，这使得Servlet可以嵌入多种服务器之中。
与CGI程序一旦将请求结果返回给浏览器以后即终止运行不同，Servlet一旦被系统管理员装载，它一直处于激活状态，就像Web
server提供的一种服务一样，除非系统管理员将之终止。Servlet的这一特性使开发人员可以利用Servlet永久性保留某些信息以备后用。比如建立与数据库的连接是一件费时的工作，我们可以利用Servlet保存一些已经建立的连接，提高系统的使用效率。
Sun公司提供了JSDK（Java Servlet Development Kit）,包括类库javax.servlet.＊，（Servlet
API 是Java 2平台的标准扩展之一）和一个servlet开发与测试引擎，用于servlet的开发和测试。此外，许多IDE开发工具如JBuilder2
也提供对servlet开发的支持。
2． RMI: Remote Method Invocation
在大型的企业计算中，需要将整个应用系统分解成若干子系统并运行于相应的部门当中，以提高整个系统的应用效率和可维护性及安全性。由于不同的工作由不同的系统来完成，在它们之间需要一种安全便利的通讯机制。从面向对象的角度来说，企业计算需要一种分布式的对象模型，使得运行于不同主机之间的对象能够互相进行方法调用，假设某企业分别有一个人事管理系统（HRMS）和财务管理系统（FMS）分别运行于人事部和财务部，HRMS计算每个员工的出勤率，而FMS根据员工的出勤率计算员工的当月工资。如图：
当FMS需要计算某员工的月工资时，FMS必须找到HRMS（可能运行在其它的主机上）然后调用其方法getWorkingdayNo以计算该员工的出勤率，并将结果返回本系统以计算该员工的月工资。RMI是基于Java的能够满足上述计算的分布式计算模式，实现了在运行于不同虚拟机的对象之间的方法调用。
RMI的研究工作其实在1994年（Java诞生之前）就已在Sun公司的实验室里开始了。研究人员在充分评估了分布计算的趋势并比较了多种分布式系统以后开发了RMI对象模式，在1997年JDK1.1发布时正式推出，成为Java分布式计算的重要技术之一。JDK1.1为RMI的开发提供了一系列的API，简化了RMI的开发工作。
从调用方式来看，RMI和RPC（远过程调用）有很大的相似之处，但二者之间最大的不同在于：RMI是面向对象，而RPC是基于过程调用的。由于RMI面向对象的特性，RMI调用可以直接将对象在调用的两端之间进行传递，不但可以传送数据，而且还可以传递方法（mobile
behavior）,扩展了RMI的使用；另外RMI还支持两个RMI对象之间的方法回调（callback）。
RMI赋予每个RMI对象一个唯一的名字，并将之与实际的对象捆绑在一起（binding）,这种对象关系登记在RMI的注册登记表中，调用者通过对象的名字找到相应的对象后调用它的方法，而不需要考虑该对象的实际物理存储位置。这不但更符合人们的使用习惯，而且提高了系统的可扩充性和鲁棒性。RMI将多个RMI对象的名字登记在同一张登记表中（监听于某端口），一个对象有一或多个方法以供远程调用，从而使一个端口可以提供多种服务，节约了系统的端口资源。
目前，RMI还只限于用Java语言编写的RMI对象之间的调用，它们之间通过JRMP（Java
Remote Method Protocol）进行通信；对于另一种对象模式CORBA，RMI还不能实现同CORBA对象之间的互相调用。不过Sun公司开发的进行二者之间相互通讯的产品（RMI
over IIOP）已进入最后测试阶段，不久将正式发布。
3． JDBC: Java Database Conectivity
在所有的企业中，数据库保存着它的重要信息。对数据库的访问能力在企业计算占据着重要的地位，直接影响着应用系统的使用。
JDBC提供了Java与数据库进行连接和访问的能力。与ODBC相类似，JDBC是由Sun公司提出的一系列对数据库进行操作的规范，其最后的使用依赖于对各数据库产品的JDBC
驱动程序（JDBC driver）。目前市场上所有的主流数据库产品都有相应的JDBC
驱动程序，这些驱动程序有的由数据库厂商自己提供，有的由第三方厂商开发，并且有的已经通过了“100％”Java纯认证。
根据各种JDBC 驱动程序采用的技术的不同，大致可将JDBC
驱动程序分成四类：
·JDBC－ODBC bridge
将JDBC访问指令转换成ODBC指令，然后通过ODBC
驱动程序完成数据库的访问。这类驱动程序的效率最为低下。
·Native－API partly－Java driver
将JDBC访问转成数据库驱动程序，在客户端的API直接完成对数据库的操作。这类驱动程序需要在每台客户机上预先安装，不利于维护和使用。
·Net－protocol all－Java driver
将JDBC访问转换成与数据库无关的网络协议送出，然后由一个中间件服务器再将之转换成特定数据库的访问指令，完成对数据库的操作，中间件服务器能支持对多种数据库的访问。这类驱动程序具有最大的灵活性，只是需要一个中间服务器的支持。
·Native－protocol all－Java driver
将JDBC访问转换成数据库能够识别的协议，完成对数据库的操作。由于这类协议基本上都是个数据库厂商自己专用，因此使用这类驱动程序也就极大地限制了数据库产品的选择自由度。
综合比较这四类驱动程序，第三类驱动程序应是企业计算中比较合适的选择。
Java 2平台中的JDBC API定义了一系列的Java类用来表示数据库连接、SQL语句、结果集、存储过程等数据库对象，开发人员能够利用这些API开发数据库应用。
4． JavaIDL: Java Interface Definition Language
当前有许多企业采用CORBA作为它们的分布式计算对象模型，它们需要Java提供开发CORBA应用的能力。Java
IDL正是为了满足这一需求而推出的，Java成为又一种能够开发CORBA对象的语言。
Java IDL与CORBA/IIOP2.0规范兼容，包括一个ORB（Object
Request Broker）和一个IDL语言编译器用于将用IDL语言定义的界面编译成Java源代码，然后用Java来实现该CORBA对象。Java
IDL还提供了一个名服务器用于通过名称寻找CORBA对象。开发人员通过Java
IDL API可以快速开发CORBA应用。
Java Enterprise Platform Servlet、RMI、JDBC和Java IDL等强大的分布式计算技术使Java具备了在企业计算中一展身手的能力，但并不能算是完整的企业计算解决方案。一般认为，现代的企业计算解决方案除了企业的业务逻辑（business
logic）外，还需要提供对8种基本的服务的支持，分别是：
·名/目录服务（Naming and Directory Service）
在企业范围内的信息共享（包括计算机、用户、打印机、应用程序等所有资源）过程中，名/目录服务扮演着重要的角色，它维护着名字和实际资源之间的连接关系，以便使用者能通过名字实现对实际资源的透明访问。在一个大型的企业中可能有多种名/目录服务并存，如何将所有的名/目录服务在现有的计算架构完整地统一起来，以便让应用程序透明地访问所有的名/目录服务，就成了企业计算解决方案必须解决的问题之一。
·Data Access Service
大部分的应用都需要访问数据库。企业计算解决方案必须提供一种统一的界面对所有的数据库进行访问。
·Distributed Object Service
在一个分布式的环境中，构成整个应用的所有组件可能位于不同的服务器上，这些组件通常通过CORBA进行互联。在企业计算环境里必须提供一种统一的方法访问这些组件，以保护企业的投资。
·Enterprise Management Service
在任何分布式环境中，管理都是一个关键的需求，需要应用程序提供远程管理的能力，以防止出现非法操作和访问以及对设备、应用程序状态的管理。
·Transaction Processing Service
一些关键部门在日常工作中有大量的事务处理，事务处理的开发是一件极其复杂的工作，它们一般依赖于TP
Monitor完成工作。
·Messaging Service
在一些企业，特别是一些对同步传输要求不高的企业通常采用消息机制在应用程序之间进行通讯。
·Security Service
应用程序的安全性是任何企业都关心的焦点之一，任何企业计算解决方案都不能回避。
·Web Service
大部分企业级应用都以Web服务器为中心。Web服务成为企业计算解决方案的重要组成部分之一。
综合这八种服务，结合企业业务逻辑（business logic）开发的需要,
Sun提出了Java企业计算解决方案——Java Enterprise Platform。如图：
Java Enterprise Platform由EJB和八种企业级API组成，八种企业级API对应于上述八种服务，分别是JNDI(Java
Naming and Directory Interface)、JDBC、JavaIDL/RMI、JMAPI(Java Management
API)、JTS/JTA(Java Transaction Service/API)、JMS( Java Messaging Service)、Java
Security API和Java Server ＆ Servlet。
后面将对EJB和一些企业级API做一个简单的介绍。
1.EJB ：Enterprise JavaBeans
EJB能够使企业计算的开发人员专注于业务逻辑的开发，而不需将过多的精力放在底层的计算细节，诸如多线程和通讯协议上，而且开发的组件能够运行于所有支持EJB的环境之中，具有可重用性。
在通常的开发过程中，开发人员除了要保证所从事领域逻辑规则的正确性以外，还要花很多精力以保证所开发程序的安全性和可扩充性等特征。
EJB将这种情况彻底改变，让“恰当的专家做恰当的事情”，应用领域的开发人员将开发精力放在应用逻辑方面，而不用考虑底层的计算技术；而计算机专业开发人员去处理底层的计算技术细节，而不用考虑应用领域的专业知识。
在EJB的开发周期中存在着四个不同的角色：Deployer,负责将EJB组件分发到企业的计算环境中；EJB
Developer,
某领域业务逻辑处理组件的开发者，具有丰富的专业知识；EJB
Container,提供EJB的生存环境和各种服务（如Transaction Service）,一般为各种应用服务的开发商;
EJB Server,
负责与操作系统打交道的底层细节，诸如和其他组件或系统的通信协议、多线程、负载均衡等等。EJB
Container 和Server共同组成了EJB的运行环境，目前的产品基本都将二者绑在了一起，Container的提供者基本都实现了Server。
在企业的应用开发过程中，只要具备EJB的运行环境，就可以将精力放在本身的逻辑处理组件的开发上面。由于EJB组件与Container之间有统一的界面，每一个EJB组件都可以运行在所有的运行环境中。目前已有越来越多的中间件厂商支持EJB,
如WebLogic等。
2.Enterprise API
在八种企业级API中，除了前面介绍过的几种技术（RMI、JDBC等）以外，还包括以下几部分：
2.1 JNDI（Java Naming and Directory Interface）
如前所述，在一个企业内部往往多种名／目录服务并存，如何将它们统一起来，以使企业在开发应用程序时能忽略各名／目录服务之间的区别而透明地访问这些名／目录服务，成为企业需要考虑的问题。JNDI解决了这一难题。JNDI从名／目录服务本身的特性出发提出了一些统一的访问名／目录服务的界面，由各名／目录服务开发商对这些界面加以实现，使用者就可以通过这些统一的界面去访问底层的各种服务。因此在JNDI中其实存在两种角色：一个是JNDI
API, 另一个是JNDI SPI( Service Provider Interface)。SPI是各名／目录服务开发商对JNDI
API 的实现，以便用户通过JNDI API访问他们提供的服务。
通过JNDI API, 开发人员只要了解JNDI就可以开发适用于所有实现了JNDI的名／目录服务的应用，保证了应用程序的可移植性，且免去了大量的学习精力。
2.2 JMS(Java Message Service)
消息机制在一些异步传输系统中被普遍使用。同名／
目录服务相似，市场上存在着许多名／目录服务产品实现这种应用，如Tibco、MessageQ等。JMS将这些所有的产品统一于一个界面，且获得了大量的中间件厂商的支持，包括BEA
System、Etsee Soft、IBM MQSeries、Novell和Sybase等在内的中间件厂商都已宣称要实现JMS,
有的如Etsee Soft已经实现。
2.3 JTS(Java Transaction System Connections)
同JMS / JNDI 一样, JTS以统一的界面掩盖了各TP Monitor之间的不同，并获得了各TP
Monitor生产商的支持，以同样的方式给企业计算带来利益。
2.4 JMAPI(Java Management API)
JMAPI是一组与协议无关的API, 开发的应用不但可
以在不同的硬件平台上运行，而且适用于多种网管协议。
2.5 Java Security API
企业计算的安全性主要体现在四个方面：认证（Authentication）、授权(Authorization)、信息在传输过程中的完整性(Integrity)和私有性(Privacy)。Java
2平台提供了包括公钥（public key）加密、数字签名（DSA）等功能在内的加密框架，实现各加密功能，以保证Java
计算的安全性。
综合JTS、JMS、JNDI等API的特点可以发现，Java Enterprise
API不是自己去重新开发这些应用软件，而只是在这些产品之上又增加了一个抽象层，以此来提升Java和各类应用软件在企业中的应用，保证了用Java开发的企业计算应用能够在多种平台上运行。
短短的三年多时间，Java已经从当初只能开发applet等小小的应用、发展到今天在企业计算中的大量运用。相信随着Java技术的进一步发展，一定会有越来越多的企业受益于Java技术革命带来的好处。
(中国计算机报1999年第20期 潘逸群)
|