Java Server Programming:Principles and Technologies
By Subrahmanyam Allamaraju, Ph.D.Summary
Building and managing server-side enterprise applications has always been a challenge. Over the last two decades, the role and importance of server-side applications has increased. The twenty-first century economy dictates that ecommerce and other enterprise applications are transparent, networked, adaptable, and service-oriented. These demands have significantly altered the nature of applications. As enterprises migrate from closed and isolated applications to more transparent, networked, and service-oriented applications to enable electronic business transactions, server-side technologies occupy a more prominent place. Despite the disparity of applications that exist in any enterprise, server-side applications are what power twenty-first century enterprises! The purpose of this article is two-fold. Firstly, this article attempts to highlight the technical needs for server-side applications, and thereby establish a set of programming models. Secondly, based on these programming models, this article introduces the reader to the Java 2, Enterprise Edition (J2EE). If you are a beginner to server-side programming, or the J2EE, this article will help you gain an overall perspective of what this technology is about. If you are familiar with one or more J2EE technologies, this article will provide the basic principles behind server-side programming, and help you relate these principles to specific J2EE technologies.
Introduction
Building and managing server-side enterprise applications1 has always been a challenge. Over the last two decades, the role and importance of server-side applications has increased. The twenty-first century economy dictates that ecommerce and other enterprise applications are transparent, networked, adaptable, and service oriented. These demands have significantly altered the nature of applications. As enterprises migrate from closed and isolated applications to more transparent, networked, and service-oriented applications to enable electronic business transactions, server-side technologies become more prominent. Despite the disparity of applications that exist in any enterprise, server-side applications are the ones that power twenty-first century enterprises. The history of server-side applications dates back to the mainframe era, an era during which only mainframes roared across enterprises. They were centralized in nature, with all the computing—from user interfaces, to complex business process execution, to transactions—performed centrally. The subsequent introduction of minis, desktops, and relational databases fueled a variety of client-server style applications. This contributed to a shift in the way applications could be built, leading to various architectural styles, such as two-, three-, and multi-tier architectures. Of all the styles, database-centric client-server architecture was one of the most widely adapted. Other forms of client-server applications include applications developed using remoteprocedure calls (RPC), distributed component technologies, such as Common Object Request Broker Architecture (CORBA), and Distributed Component Object Model (DCOM), etc. Just as these technologies and architectures were diverse, so too were the nature of clients for such applications. The most commonly used client types for these applications were desktop based (i.e., those developed using Visual Basic or other similar languages). Other types of clients included other applications (viz., as in enterprise application integration) and even Web servers. Subsequently, what we see today are Internet-enabled server-side applications. The underlying technologies for building Internet-enabled server-side applications have evolved significantly and are more mature and less complex to deal with, as you will see later in this article. Apart from providing more flexible programming models, todayrsquo;s server-side technologies are infrastructure intensive.
What is server-side programming?
The terms server and server-side programming are very commonly used. But what is a server? Generally speaking, a server is an application hosted on a machine that provides some services to the other applications (clients) requesting the services. As is obvious from the definition, a server typically caters to several clients, often concurrently. The services offered by a server application can be very diverse— ranging from data, and other information, management to the execution of specialized business logic. Although several types of server applications are possible, you can quickly recognize the following two kinds of servers: 1. Commercial Database Servers (or Database Management Systems): Servers that manage data, which come from vendors, such as Oracle, Sybase, and Microsoft. Client applications use standard APIs, such as Open Data Base Connectivity (ODBC) or Java Data Base Connectivity (JDBC), in combination with SQL (Structured Query Language) to access/manipulate the data. In addition to these standard APIs, you may use vendor-specific client access APIs to communicate with the database server. These servers are responsible for consistently managing data such that multiple clients can manipulate the data without loss of consistency. 2. Web Servers: The other easily recognizable types of servers are Web servers. A Web server hosts content, such as HTML files. Clients (Web browsers) access this content by submitting requests using Hyper Text Transfer Protocol (HTTP). In its basic mode, a Web server maps a client request to a file in the file system, and then sends the content of the file to the client making the request. Similar to database servers, Web servers can deal with concurrent requests—often several thousands. Because we are accustomed to working with these types of servers, we often tend to overlook the fact that they are server-side applications, a
全文共66500字，剩余内容已隐藏，支付完成后下载完整资料
Java服务器编程：原理和技术
作者：Subrahmanyam Allamaraju，Ph.D.Summary
构建和管理服务器端企业应用程序一直是一个挑战。在过去二十年中，服务器端应用程序的作用和重要性有所增加。二十一世纪的经济要求电子商务和其他企业应用程序是透明的，网络化的，适应性强的和面向服务的。这些要求大大改变了应用的性质。随着企业从封闭和隔离的应用程序迁移到更透明，网络化和面向服务的应用程序，从而实现电子商务交易，服务器端技术占据更加突出的地位。尽管任何企业存在应用程序的差异，服务器端应用程序是二十一世纪的企业！这篇文章的目的是双重的。首先，本文尝试突出显示服务器端应用程序的技术需求，从而建立一套编程模型。其次，基于这些编程模型，本文介绍了Java 2企业版（J2EE）的读者。如果您是服务器端编程的初学者，或者是J2EE，本文将帮助您全面了解该技术的内容。如果您熟悉一个或多个J2EE技术，本文将提供服务器端编程背后的基本原理，并帮助您将这些原则与特定的J2EE技术相关联。
介绍
构建和管理服务器端企业应用程序一直是一个挑战。在过去二十年中，服务器端应用程序的作用和重要性有所增加。二十一世纪的经济规定电子商务和其他企业应用是透明的，网络化的，适应性强的和面向服务的。这些要求大大改变了应用的性质。随着企业从封闭和隔离应用程序迁移到更透明，网络化和面向服务的应用程序，实现电子商务交易，服务器端技术变得更加突出。尽管任何企业存在应用程序的差异，服务器端应用程序是为二十一世纪企业提供支持的应用程序。服务器端应用程序的历史可以追溯到大型机时代，这是一个只有大型机在企业中肆虐的时代。它们集中在本质上，所有的计算 - 从用户界面到复杂的业务流程执行，到集中执行的事务。随后推出的minis，桌面和关系数据库为各种客户端服务器风格的应用提供了动力。这有助于应用程序的构建方式发生转变，从而导致各种架构风格，例如两层，三层和多层架构。在所有风格中，以数据库为中心的客户端 - 服务器架构是最广泛适应的。其他形式的客户端 - 服务器应用程序包括使用远程调用调用（RPC）开发的应用程序，诸如通用对象请求代理体系结构（CORBA）和分布式组件对象模型（DCOM）等分布式组件技术。正如这些技术和体系结构客户的这种应用的性质也是多样的。这些应用程序最常用的客户端类型是基于桌面的（即使用Visual Basic或其他类似语言开发的）。其他类型的客户端包括其他应用程序（即在企业应用程序集成中）甚至Web服务器。随后，我们今天看到的是启用Internet的服务器端应用程序。构建基于互联网的服务器端应用程序的基础技术已经显着发展，并且更加成熟，并且处理不太复杂，如本文后面将会看到的。除了提供更灵活的编程模式外，今天的服务器端技术还是基础设施密集型的。
什么是服务器端编程？
术语服务器和服务器端编程非常常用。但是什么是服务器？一般来说，服务器是一个托管在机器上的应用程序，它向其他请求服务的应用程序（客户端）提供一些服务。从定义中可以看出，服务器通常同时适用于多个客户端。服务器应用程序提供的服务可能非常多样化，从数据，其他信息，管理到专门的业务逻辑的执行。尽管可能有几种类型的服务器应用程序，您可以快速识别以下两种服务器：1.商业数据库服务器（或数据库管理系统）：管理数据的服务器，来自供应商，如Oracle，Sybase和Microsoft 。客户端应用程序使用标准API，例如开放数据库连接（ODBC）或Java数据库连接（JDBC）与SQL（结构化查询语言）结合访问/操纵数据。除了这些标准API之外，您还可以使用供应商特定的客户端访问API与数据库服务器进行通信。这些服务器负责一致地管理数据，使得多个客户端可以在不损失一致性的情况下操纵数据。 2. Web服务器：其他容易识别的服务器类型是Web服务器。 Web服务器托管内容，如HTML文件。客户端（Web浏览器）通过使用超文本传输协议（HTTP）提交请求来访问此内容。在其基本模式中，Web服务器将客户端请求映射到文件系统中的文件，然后将文件的内容发送给发出请求的客户端。与数据库服务器类似，Web服务器可以处理并发请求 - 通常是几千个。因为我们习惯于使用这些类型的服务器，所以我们经常倾向于忽略它们是服务器端应用程序，尽管是标准化的。但是，当我使用术语服务器端编程时，我并不意味着开发这样的数据库Web服务器。这种应用在几年前是商品化的。这些通用服务器端应用程序提供标准的预定义功能。在服务器端编程的情况下，我们更有兴趣开发特殊用途应用程序来实现特定的业务用例。考虑服务器端应用程序为什么很重要或相关？为什么需要构建可以向多个客户端应用程序提供服务的应用程序？以下是一些常见的情况，说明了对服务器端应用程序的需求：1.执行一些可用于不同应用程序的逻辑。这是引发早期分布式技术发展的原因之一，如RPC 17.考虑到您正在开发一种实施某些新的业务用例的应用程序。假设有一些业务逻辑已经在不同的应用程序中实现了。在这种功能可用作单独/隔离的类或函数库的情况下，您可以考虑在新应用程序中重新使用相同的代码。但是，如果这样的逻辑（和代码）在很大程度上取决于现有应用程序管理的一些数据呢？在这种情况下，类/函数库不能重复使用，因为这些类/函数库可能无法执行，而不可用此类数据。或者，如果这样的代码依赖于现有应用程序的其他几个部分，如何在新应用程序中重用代码呢？处理这个的一个可能的解决方案是在现有的应用中执行这个逻辑;也就是说，新应用程序可以向现有应用程序发送一个请求（具有任何必需的数据），而不是重用现有的应用程序中的代码来执行此逻辑并获得任何结果。 2.访问另一应用程序维护的信息/数据。这是另一种强制服务器端应用程序和客户机的场景。数据库服务器和其他应用程序将持久存储中的信息保留在此类别下;然而，数据库服务器（如关系数据库管理系统）通常会管理原始数据（各种表中的数据行）。此类数据可能或可能不会由依赖于数据的其他应用程序直接使用（在业务意义上）。例如，考虑一个数据库，其中包含银行中所有客户的各种账户。这种系统的一个常见要求是整合给定客户的所有帐户，并提供所有帐户的摘要视图。根据该客户的帐户类型，生成摘要视图的过程可能涉及执行一些复杂的计算，包括评估一些业务规则。现在考虑银行中的几个应用程序执行其他银行业务，其中一些应用程序需要客户的所有帐户的总结视图。例如，负责计算每月帐户费用的申请可能需要合并账户余额的价值。当有几个这样的应用程序需要这些数据时，让其中一个应用程序处理所有其他应用程序的这个计算是合适的。集成应用程序在任何给定的企业中，找到用于执行不同业务任务多年来开发的多个应用程序并不罕见。您甚至可以发现，这种独立应用程序由不同的企业部门维护，并使用不同的编程语言和技术开发。在某种程度上，这种应用是将企业从基于大型机的应用程序分散的结果。然而，正如我们前面所讨论的，目前几乎所有企业遇到的一个需求就是能够互联互联这样的应用程序，以便在整个企业中建立业务流程。要进一步阐述，让我们来看一个传统的零售业务，通过呼叫中心，平面邮件等收集产品的订单。我们假设订单录入应用程序用于记录通过以下方式捕获的所有订单（在数据库中）这些渠道。我们还假设公司已经开发了一个内部订单履行应用程序，该应用程序将数据库中记录的订单进行处理，并执行完成每个订单所需的任务。这两个应用程序是火炉的，因为这些应用程序中的每一个都以解耦的方式处理特定的业务任务，而不了解整体业务流程。在这种情况下，总体业务流程是接收（并输入）订单，然后完成每个订单。这样的炉子应用程序不能单独实现端到端业务流程。为了实现这一点，您需要集成应用程序，以便订单输入应用程序可以直接或间接地自动触发履行应用程序。这是企业应用程序集成18的一个问题，但是有几种实现这种集成的方法。一种方法是使订单输入应用程序在捕获订单后直接调用（或通知）履行应用程序。然后，履行应用程序可以启动履行活动，从而简化跨这些应用程序的业务流程。
同步请求 - 响应模型
这种模式的基本思想是它允许客户端应用程序调用在远程应用程序上执行的方法/函数。技术，如CORBA，Java远程方法调用（RMI）和企业JavaBeans（EJB）遵循此模型。以下特征描述了同步请求 - 响应模型方法：1.客户端和服务器之间的契约是基于接口的。客户端和服务器之间的接口是远程接口。它指定客户端可以在服务器上调用的操作/方法。 2.客户端与服务器之间的通信是同步的。这与本地方法调用没有区别。调用方法后，客户端线程等待服务器响应。这也意味着应该启动并运行服务器，以便客户机调用服务器上的方法。通信是连接的。应用程序合同可以在客户端和服务器之间维护各种请求和响应。这两个功能缩小了调用本地对象上的方法并调用远程对象上的方法之间的界限。
基本要求
实施这种方法的技术要求是什么？在我们确定技术要求之前，让我们更详细地研究这个方法。下面的图4显示了在不同进程中调用方法的应用程序（客户端）。在面向对象的语言（如Java）中，接口或类上存在方法。因此，在Java环境中，此方法涉及客户机调用存在于不同进程（可能在不同机器上）的对象上的方法。
Java RMI
现在让我们演示如何开发客户端和服务器对象，并使用Java RMI生成代理和骨架类。 Java RMI是纯Java环境中的CORBA替代方案。 Java RMI定义了一个用于指定远程接口的框架，该框架在java.rmi包中指定。 J2SE还包括对远程对象和客户端服务器通信的运行时支持。您可以通过使您的接口扩展java.rmi.Remote接口（这表示它是远程接口的Java运行时）来指定远程接口，如下所示：public interface Process extends java.rmi.Remote {public void process（String arg）抛出java.rmi.RemoteExcetion; }这段代码片段使用一种方法定义了一个远程接口。需要使用exception子句来表示此方法可能会引发与通信相关的异常。下一步是实现一个实现远程接口的类。这是服务器object.public类ProcessImpl扩展UnicastRemoteServer实现Process {public ProcessImpl（）{super（）; } public void process（String arg）throws java.rmi.RemoteExcetion {//在这里实现方法}}一旦有了远程接口，下一步就是在实现类上使用rmic编译器来生成代理和框架类。您将在J2SE发行版下找到此编译器。此编译器具有为代理和骨架类创建源文件的选项。其他技术（如CORBA或EJB）使用类似的方法来指定远程接口并生成代理和骨架。虽然代理和骨架消除了网络级编程的需要，但应考虑以下两个问题：1.骨架如何维护对象B的实例？服务器应用程序应该最初为每个请求创建一个实例，还是应该为所有请求共享一个实例？任何策略的线程/并发影响是什么？ 2.位置透明度：如何指定服务器到代理对象的位置？您可以预先确定这一点，并强制代理调用给定网络位置可用的远程接口的特定实现？如果是这样，客户端应用程序将取决于服务器的位置。但是，是否可以实现位置透明度？
实例管理
一旦远程接口及其实现可用，下一个问题是如何使实现类的实例在运行时（进程）中可用。创建实现对象的新实例不足以通过远程接口使此实现可用。为了使服务器实现对象可用，并能够处理通过网络从客户端应用程序发出的请求，需要以下附加步骤：1.托管实例的进程应通过网络访问。通常，这归结为通过网络监听请求的服务器套接字（即，服务器进程应该具有必要的基础设施）。服务器进程应该分配一个线程来处理每个传入的请求。服务器通常需要多线程。服务器进程可能会托管多个远程接口的实现。根据传入网络请求中包含的一些信息，服务器进程应能够识别正确的实现对象。例如，接口的名称可以指定服务器的实现对象。在这种情况下，服务器应该知道哪个类实现哪个远程接口。一旦服务器识别正确的接口，它应该调用相关的骨架类。该类可以解除对请求参数的编排，并为实现类调用适当的方法。在上面的列表中，创建实例的任务取决于客户端服务器的通信是否需要有状态或无状态。当您期望多个客户端调用远程对象上的方法时，解决此问题。有状态和无状态通信之间的主要区别是远程实例是否可以维护并依赖来自客户端的多个方法调用之间的实例变量。例如，考虑到客户端A正在远程对象B上调用方法。我们还假设远程接口有几种方法。客户端可以一个接一个地调用这些方法。在实现方法时，远程对象可以将数据存储在其实例变量中。例如，它可以将一些计算结果存储在实例变量中。如果此对象上的后续方法取决于实例变量中存储的值，则通信状态为状态;也就是说，服务器应该确保从给定客户端的所有请求中使用相同的实例。这也意味着，当一个实例正在为客户端服务时，服务器不应该为其他客户端请求使用相同的实例。状态的一个重要分支是服务器将为每个客户端维护一个单独的实例。在具有非常大数量的客户端的系统中，状态可能会影响性能。另一方面，无状态通信对于给定的客户端不需要相同的实例（即调用方法）。在这种情况下，服务器可能能够为这10个客户端使用十个对象。因此，无状态通信在服务器端转移内存时更有效率。一般的做法是使用无状态方法实现远程对象。诸如RMI，CORBA和COM / DCOM之类的技术单独提供无状态远程对象。另一方面，EJB技术也允许有状态的服务器端对象。我们稍后再讨论一下。图10总结了实例管理。
位置和命名
如上一节所述，重要的是在分布式应用程序中实现位置透明度，其中几个客户端调用在由网络上的多个服务器进程管理的多个远程对象上的方法。还有一个我们以前没有考虑的问题。客户端应用程序如何创建代理对象的实例？在前面的讨论中，我们隐含地假定客户端将创建一个实例并使用它;然而，客户端也应该知道服务器进程的网络位置。虽然这两个任务似乎是独立的，但两者通常使用相同的方法来解决，具有命名和命名服务。命名背后的基本思想是远程引用可以命名。与远程引用（其基本上指向进程内的内存地址）不同，名称是可移植的，并且可以唯一地确定远
全文共20251字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[144561]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
