|
|
本文就java基础部分容易混淆的一些知识点进行了一下总结。因为Java本身知识点非常多，不可能在很短的篇幅就能叙述完，而且就某一个点来讲，如欲仔细去探究，也能阐述的非常多。这里不做全面仔细的论述，仅做为一个引子，抛砖引玉。具体个例，还需各位看官自己验证一下，以增进理解和记忆。
欢迎就这一部分各位朋友与我进行探讨，共同进步。
1、虽然有很多朋友可能进行了多年的java开发老手，但可能仍旧对某些点缺乏仔细探究。
2、去一些公司求职面试或笔试时的技术题目中，也往往会涉及到这里的一些内容。
所以，希望下边的这些总结能够对一些学习java或求职的朋友有些许帮助。
1、 关于java类中的缺省的构造器
如果一个java类没有显式定义没有参数的构造器，将有一个默认缺省的构造器。如果定义了一个有参数的构造器，那么原来的缺省的构造器将不在有效。
public class A{
}
此时如果用 new A(); java编译器将使用缺省的构造器。
public class A{
public A(int i){
}
}
如果此时用 new A(); 将产生一个编译错误，因为此时显式定义了，一个有参数的构造器。
2、Java中的类名与文件名
1、在一个java文件中可以有多于一个类定义(更常见于某些组件的监听器类)，但只能有一个public class定义，且与文件同名。
2、如果一个java源文件中没有public类，那么每个类的名字没特殊规则，即不必与文件同名。
3、在编译后产生的class文件中，仍旧是多个单独分开的class文件。
3、import关键字
1、import语句必须定义在所有的class定义之前。
2、import语句只是为编译器指明了一个路径，并不像C或C++中的#include，所以用import .*并不影响性能
4、Java中的几个特殊关键字
Java中的关键字许多大家都比较熟悉，而有几个就不是很常用，如：
1、goto和const是保留关键字，在java中没使用
2、strictfp和volatile不常用； sizeof、zhen不是关键字。
3、true,false,null不是严格意义上的关键字，而是literals。
5、java方法中的传递值参
在Java方法中传递参数，对于基本类型来讲传递的是值参数，相当于建立的一个参数的拷贝，不影响原来变量的值。
在引用方法中可以改变传递对象的内容，但对象引用(像A@5d87b2)从来不会改变。
public class tt{
public static void main (String args[]){
A aa = new A();
aa.num =5;
tt t = new tt();
System.out.println("11 aa="+aa + "num="+aa.num);
t.test(aa);
System.out.println("22 aa="+aa + "num="+aa.num);
}
void test(A a){
A ab = new A();
a = ab;
System.out.println("33 ab="+ab + "num="+ab.num);
}
}
class A{
int num;
}
6、变量初始化
java中的变量在使用之前必须被初始化，当创建一个对象的时候一些类的变量会自动初始化并赋予缺省值。
数字类赋值0；char类型赋值'\u0000'; boolean类型赋值false；引用对象赋值null;
注意的是在方法之外的类变量的值是自动赋初始值，而方法内的局部变量必须手工初始化。
class AA{
int num;
void test(){
int j;
j =5;//没有这一行则编译不会通过。
j = j+num;
}
}
7、switch语句
这个点经常在求职笔试题目中出现。default放在最上边编译没问题；碰到符合分支的，如果没有break会一直向下运行。
public class tt{
public static void main (String args[]){
tt t = new tt();
t.test(2);//可改变成3运行一下看一下结果
}
void test(int i){
switch (i){
default:
System.out.println("default");
case 1:
System.out.println("111");
break;
case 2:
System.out.println("222");
break;
}
}
}
8、关于java中的label使用
? break [label]
? continue[lbele]
? lable: statement; //这里的statement必须是一个loop循环
public class tt{
public static void main (String args[]){
tt t = new tt();
t.test();
}
void test(){
System.out.println("0000");
lb1:for (int i=0;i<10;i++){
lb2:for (int j=0; j<2; j++){
if (i==2) continue lb1;
System.out.println("i="+i +" j="+j);
}
}
System.out.println("111111");
}
}
9、类型转换校正
class Employee
|
class Manager
向上校正，总是允许的，Manager直接使用父类Employee的方法。
向下校正，必须用instanceof检验，才能将一个Employee转换为Manager对象。
public void test(Employee e){
if (e instanceof Manager){
Manager m = (Mnager)e;
...
}
}
10、方法重载(overloading)、方法覆盖(overriding)
方法重载(overloading)一定要求名字相同，参数不同，返回类型可以相同也可以不同
class A{
void test(int i){
}
}
class AA extends A{
int test(int i, int j){
return 5;
}
}
注：方法覆盖(overriding)要求名字，参数，返回类型全部必须相同，访问控制符可以不同，但必须大过父类的。因为如果名字和参数都已经相同了则一定要求返回类型相同，否则认为这是一个新的方法了，名字就必须不同了。
class A{
void test(int i){
}
}
class AA extends A{
public void test(int i){//若是换成private则编译不通过。
}
}
注：关于覆盖方法抛出异常的问题。如A是父类，B是继承A的子类。B中的方法meth()去覆盖父类A的此方法时，B中不能throws出新的异常，只能是父类抛出的异常或其子集。更甚至可以不抛出异常。
11、关于类的构造器重载问题
class A{
public A(int i){
}
}
class AA extends A{
public AA(){
int i = 5; // 这里出错，没有父构造器
}
}
由于父类A自定义了构造器，所以缺省的构造器就丢失了，当子类的构造器自动试图调用父类没参数的构造器时却没有，所以会编译出错。
12、关于static关键字总结：
1、不能在static修饰的方法中引用this变量，只能引用一些静态变量或方法，或new新的对象(可以定义局部变量)。
简言之，静态方法或块中，只能引用静态的方法或变量。
2、类中的成员变量(static修饰)有缺省值，而类的定义的方法中的局部变量没有缺省值。
3、在类的构造器中，可以引用任何的静态或非静态的变量和方法，可以在非static方法中调用static方法。
4、static{}块中的代码在类装载中仅执行一次。
5、在7-7，A static method cannot be overridden but can be hidden. 不理解。
6、不能在无论非static方法中或static方法中定义static变量。
13、关于final关键字
1、不能继承final修饰的类，不能覆盖final修饰的方法。
2、final修饰的变量，若没赋值，必须在构造器中赋初始值。
class A{
final int j;
public A(){
j = 9;//若没有此行，则编译不通过。
}
}
3、final类型的方法参数可定义，但不能改变。
class A{
void m(final int i){ //这一行的声明i为一个final没问题。
i ++ ; //但在这里面，i的值不能再被改变。
}
}
14、Interface接口关键字
1、接口中的变量
1、必须初始化其值。
2、默认修饰符为public+static+final,其他的修饰符不允许。
2、接口中的方法
1、默认为public+abstract
2、其它修饰符 static,private,protected,final,synchronized,native均不能有。
interface A{
void s();
}
class AA implements A{
void s(){ //编译器在这里提示由于接口中的方法s()修饰符默认是public，
//而这里的s()默认是protected，小于public所以不允许。
}
}
15、abstract抽象关键字
abstract class A{
private int i;
private void m();{}
}
抽象类中可以有私有的变量和私有属性，而接口就不行（原因如上），
这是因为java是按实例虚拟调用的，在生成某一个具体的对象可以有私有的属性或方法的。
abstract class A{
private int i;
private void m(){};
public abstract void n();//若是private则编译不通过。
}
抽象类中的抽象方法是让其他类继承的，如果本身都是私有的，就没有什么意义了
16、集合类型
以有无顺序，允许不允许重复区分
Collections: 一组对象，无序集合，允许重复
Set：无序集合，不允许重复
List：有序集合，允许重复
注意：在JDK1.1中定义的集合类型，都是线程安全的，所以都是“重量级”的。像HashTable,Vector
而在java2中定义的一些新的集合类型如HashMap, ArrayList不是线程安全的，是“轻量级”的，但速度快，性能好。这一点在许多公司面试试题都见过。
17、布局管理器
FlowLayout,BorderLayout,GridLayout,CardLayout
关于Panel和Frame默认的Layout常在一些公司的面试试题中出现。
1、Panel和Applet类默认的布局管理器是FlowLayout 一个一个的加上去
2、Frame和window类默认的布局管理器是BorderLayout 按东南西北加入
3、xyLayout是Borland公司开发的布局管理器。
18、面试试题中Applet部分
1、使用代码
<applet code = "a.class" width=100 height=200>
<param name=a vlaue"11">
</applet>
2、可以覆盖的方法init(),start(),stop(),destory(),paint(g)
19、面试试题中线程部分
1、基本实现方式两中，继承Thread类和实现Runnable接口
2、必须实现父类或接口中的run()方法。
3、有关线程方法，start()启动线程。
join()指在调用这个线程的方法或进程中，必须等待此线程运行结束才能继续其他进程。
4、线程中的同步synchronized,注意死锁。
20、对象串行化
1、仅仅对象类型的数据可以串行化。
2、标记为transient的数据不可以串行化。
存储一个对象到某种永久性存储叫persistence，如存储到磁盘、磁带或别的机器的内存中。
java.io.Serializable接口没有定义方法要实现，仅仅是一个标记暗示实现了这个接口的类可以被考虑串行化。没有实现这个接口的对象不能保存或存储它们的状态。
当一个对象被串行化的时候，仅仅数据被保留，而方法和构造器不是串行化的部分。
一些对象类是不能串行化的因为他们代表的数据是经常变化的。如java.io.FileInputSream和java.langThread。如果串行化的对象包含了不可串行化的对象，整个串行化动作会失败，并抛出NotSerializableException。
21、java中的网络通讯
一般的TCP/IP网络数据通信主要可分2种，TCP和UDP
TCP：TCP是面向连接的通信协议，就像打电话，先要拨通建立连接，传送的数据不会丢失。
java提供了ServerSocket和socket类。在server端，建立一个serverSocket，并指定端口，并侦听连接。
服务器端代码
ServerSocket sc=new ServerSocket(1111);
Socket socket1= sc.accept();
DataInputStream s_in = new DataInputStream(socket1.getInputStream());
客户端代码
Socket socket2 = new Socket("192.168.1.1",1111);
UDP：UDP非面向连接，就像写信，将传输的数据包成一个分组，可能有数据丢失
服务器端代码
DatagramSocket server = new DatagramSocket(1234);
DatagramPacket in_packet =new DatagramPacket(in_buf,2000);
server.recieve(in_packet);
客户端代码
DatagramSocket client= new DatagramSocket(1235);
DatagramPacket out_packet=
new DatagramPacket (out_buf,100,"192.168.1.1",1234);
client.send(outPacket);
22、String对象
一般讲来创建的两个对象如果用==来比较肯定是不等的，因为他们的引用地址是不同的，而==是对于对象来讲是比较对象地址的。但对于String对象来讲是一个例外，两个String对象如果值相同，==比较也是相同的。我想这可能与Sun公司对String对象定义有关。
public class tt{
public static void main (String args[]){
tt t = new tt();
t.test(2);
}
void test(int i){
String s1 = "123";
String s2 = "123";
if (s1==s2)
System.out.println("111111");
else
System.out.println("2222222");
}
}
结果输出：111111 |
|
|
Java语言接口与继承的本质
|
|
loveofgod
转贴 (参与分：2027，专家分：345) 发表：2006-07-20 02:25 版本：1.0 阅读：12次 |
|
计算机学院研二的兄弟与我讨论Java，一见面，几个问题全是关于接口，接口有什么用？为什么要用接口？什么时候该使用接口？很庆幸他们不是问我Java如何连接SQL Server，或者是如何开发J2EE应用，这类问题有杀伤力，避之则吉。今年计算机学院本科有个毕业设计课题是做J2ME，选这个题目的学生在5月末都还在苦着脸研究java.util.*这个包，这个这个……唉。
大多数人认为，接口的意义在于顶替多重继承。众所周知Java没有c++那样多重继承的机制，但是却能够实作多个接口。其实这样做是很牵强的，接口和继承是完全不同的东西，接口没有能力代替多重继承，也没有这个义务。接口的作用，一言以蔽之，就是标志类的类别（type of class）。把不同类型的类归于不同的接口，可以更好的管理他们。OO的精髓，我以为，是对对象的抽象，最能体现这一点的就是接口。为什么我们讨论设计模式都只针对具备了抽象能力的语言（比如c++、java、c#等），就是因为设计模式所研究的，实际上就是如何合理的去抽象。（cowboy的名言是“抽象就是抽去像的部分”，看似调侃，实乃至理）。
设计模式中最基础的是工厂模式（Factory），在我最近的一个很简单的应用中，我想尽量的让我的程序能够在多个数据库间移植，当然，这涉及很多问题，单是如何兼容不同DBMS的SQL就让人头痛。我们不妨先把问题简单化，只考虑如何连接不同的数据库。
假设我有很多个类，分别是Mysql.java、SQLServer.java、Oracle.java、DB2.java，他们分别连接不同的数据库，统一返回一个Connection对象，并且都有一个close方法，用于关闭连接。只需要针对你的DBMS，选择不同的类，就可以用了，但是我的用户他会使用什么数据库？我不知道，我希望的是尽量少的修改代码，就能满足他的需要。我可以抽象如下接口：
package org.bromon.test;
public interface DB
{
java.sql.Connection openDB(String url,String user,String password);
void close();
}
这个接口只定义两个方法，没有任何有实际意义的代码，具体的代码由实作这个接口的类来给出，比如Mysql.java：
Package org.bromon.test;
import java.sql.*;
public class Mysql implements DB
{
private String url=”jdbc:mysql:localhost:3306/test”;
private String user=”root”;
private String password=””;
private Connection conn;
public Connection openDB(url,user,password)
{
//连接数据库的代码
}
public void close()
{
//关闭数据库
}
}
类似的当然还有Oracle.java等等，接口DB给这些类归了个类，在应用程序中我们这样定义对象：
org.bromon.test.DB myDB;
使用myDB来操作数据库，就可以不用管实际上我所使用的是哪个类，这就是所谓的“开-闭”原则。但是问题在于接口是不能实例化的，myDB=new DB()，这样的代码是绝对错误的，我们只能myDB=new Mysql()或者myDB=new Oracle()。麻烦了，我还是需要指定具体实例化的是哪个类，用了接口跟没用一样。所以我们需要一个工厂：
package org.bromon.test;
public class DBFactory
{
public static DB Connection getConn()
{
Return(new Mysql());
}
}
所以实例化的代码变成：myDB=DBFactory.getConn()；
这就是23种模式中最基础的普通工厂(Factory)，工厂类负责具体实例化哪个类，而其他的程序逻辑都是针对DB这个接口进行操作，这就是“针对接口编程”。责任都被推卸给工厂类了，当然你也可以继续定义工厂接口，继续把责任上抛，这就演变成抽象工厂(Abstract Factory)。
整个过程中接口不负责任何具体操作，其他的程序要连接数据库的话，只需要构造一个DB对象就OK，而不管工厂类如何变化。这就是接口的意义----抽象。
继承的概念不用多说，很好理解。为什么要继承呢？因为你想重用代码？这绝对不是理由，继承的意义也在于抽象，而不是代码重用。如果对象A有一个run()方法，对象B也想有这个方法，所以有人就Class B extends A。这是不经大脑的做法。如果在B中实例化一个A，调用A的Run()方法，是不是可以达到同样的目的？如下：
Class B
{
A a=new A();
a.run();
}
这就是利用类的聚合来重用代码，是委派模式的雏形，是GoF一贯倡导的做法。
那么继承的意义何在？其实这是历史原因造成的，最开始的OO语言只有继承，没有接口，所以只能以继承来实现抽象，请一定注意，继承的本意在于抽象，而非代码重用（虽然继承也有这个作用），这是很多Java烂书最严重的错误之一，它们所造成的阴影，我至今还没有完全摆脱，坏书害人啊，尤其是入门类的，流毒太大。什么时候应该使用继承？只在抽象类中使用，其他情况下尽量不使用。抽象类也是不能实例化的，它仅仅提供一个模版而已，这就很能说明问题。
软件开发的万恶之源，一是重复代码而不是重用代码，二是烂用继承，尤以c++程序员为甚。Java中取缔多重继承，目的就是制止烂用继承，实是非常明智的做法，不过很多人都不理解。Java能够更好的体现设计，这是让我入迷的原因之一。
|
|
|
XML和J2EE的完美结合
|
|
loveofgod
转贴 (参与分：2027，专家分：345) 发表：2006-07-19 17:15 版本：1.0 阅读：15次 |
|
当前，Java 2平台企业版（J2EE）架构在厂商市场和开发者社区中倍受推崇。作为一种工具，可扩展标记语言（XML）简化了数据交换、进程间消息交换这一类的事情，因而对开发者逐渐变得有吸引力，并开始流行起来。自然，在J2EE架构中访问或集成XML解决方案的想法也很诱人。因为这将是强大系统架构同高度灵活的数据管理方案的结合。
XML的应用似乎是无穷无尽的，但它们大致上可以分为三大类：
●简单数据的表示和交换（针对XML的简单API（SAX）和文档对象模型（DOM）语法解析，不同的文档类型定义（DTDs）和概要（schemas））
●面向消息的计算（XML-RPC（远程过程调用），SOAP协议，电子化业务XML（ebXML））
●用户界面相关、表示相关的上下文（可扩展样式表语言（XSL），可扩展样式表语言转换（XSLT））
这几类应用在J2EE架构中恰好有天然的对应：数据表示和交换功能是EJB组件模型中持久化服务（persistence services）的一部分，基于消息的通讯由Java消息服务（JMS）API来处理，而界面表示正是Java服务器页面（JSP）和Java Servlets的拿手好戏。
在本文中，我们将看到当今基于J2EE的应用里，XML是如何在上述几个方面进行应用的，以及在相关标准的未来版本中这些应用将会如何发展。
基础：数据的表示和交换
原型化的XML应用（假设有的话）的内容通常是：数据以XML格式存放，为了进行显示、修改甚至写入某个XML文档而经常被读入到某个对象模型中。作为例子，假定我们正处理多种类型的媒体（图品、视频、文本文档等等），并且用下面这个简单的XML DTD来描述这些媒体的元数据：
<!-- DTD for a hypothetical media management system -->
<!-- Media assets are the root of the object hierarchy. Assets are also
hierarchical - they can contain other assets. -->
<!ELEMENT media-asset (name, desc?, type*, media-asset*, urn)>
<!-- Metadata about the asset -->
<!ELEMENT name (#PCDATA)>
<!ELEMENT desc (#PCDATA)>
<!ELEMENT type (desc, mime-type?)>
<!ELEMENT mime-type (#PCDATA)>
<!ELEMENT urn (#PCDATA)>
以下是一个基于上述媒体DTD的XML文档，描述了与某个课程讲座相关的内容：
<?xml version="1.0" ?><!DOCTYPE media-asset PUBLIC "-//Jim Farley//DTD
Media Assets//EN" "http://localhost/Articles/Sun/dtds/media.dtd">
<media-asset>
<name>第14讲</name>
<desc>与第14讲相关的所有内容</desc>
<!-- 内容对象"lecture 14"的一套子组件 -->
<media-asset>
<name>讲座的幻灯片</name>
<type>
<desc>MS PowerPoint</desc>
<mime-type>application/vnd.ms-powerpoint</mime-type>
</type>
<urn>http://javatraining.org/jaf/E123/lecture-
14/slides.ppt</urn>
</media-asset>
<media-asset>
<name>讲座的视频片断</name>
<type>
<desc>RealPlayer streaming video</desc>
<mime-type>video/vnd.rn-realvideo</mime-type>
</type>
<urn>http://javatraining.org/jaf/E123/lecture-
14/lecture.rv</urn>
</media-asset>
<!-- 讲座开始 -->
<urn>http://javatraining.org/jaf/E123/lecture-14/index.jsp</urn>
</media-asset>
从Web或者企业级应用的角度看，能以这种方式访问数据真是一种福音，因为它体现了高度的可移动性，使我们与元数据的实际资源本身隔离。这些资源可能来自一个关系数据库系统、某种活动媒体服务器或者Web服务器上的一个静态XML文档，等等。如果想把这些数据加载到Java应用中，我们可以从当前众多的Java语言XML解析器中选用一个，通过它将XML数据装入一个DOM文档，最后遍历文档，将所有这些数据转换到我们应用系统的对象模型中。
下面是个简单的基于DOM的解析程序，可对上述的媒体DTD进行解析。解析器用的是
Apache Xerces：
package jaf.xml;
import java.util.*;
import java.io.IOException;
import org.w3c.dom.*;
import org.xml.sax.*;
// XML文档解析程序，使用上述媒体DTD.
public class MediaParser implements ErrorHandler {
/** 使用Apache Xerces解析器 */
org.apache.xerces.parsers.DOMParser mParser =
new org.apache.xerces.parsers.DOMParser();
/** 构造函数 */
public MediaParser() {
// 告诉解析器验证并解析文档
try {
mParser.setFeature( "http://xml.org/sax/features/validation",
true);
}
catch (SAXException e) {
System.out.println("Error setting validation on parser:");
e.printStackTrace();
}
// 设置解析器的错误处理句柄
mParser.setErrorHandler(this);
}
/** 解析指定的URL，返回找到的XML文档
*/
public Document parse(String url) throws SAXException, IOException {
mParser.parse(url);
Document mediaDoc = mParser.getDocument();
return mediaDoc;
}
/** 解析指定URL的XML文档，将内容转换成 MediaAsset 对象
*/
public Collection loadAssets(String url) throws SAXException,
IOException {
Document doc = parse(url);
Collection assets = new LinkedList();
NodeList assetNodes = doc.getElementsByTagName("media-asset");
for (int i = 0; i < assetNodes.getLength(); i++) {
Node assetNode = assetNodes.item(i);
MediaAsset asset = new MediaAsset(assetNode);
assets.add(asset);
}
return assets;
}
/**
* 错误处理代码（为简洁起见省略了）
*/
}
MediaParser类的构造函数初始化了一个Xerces DOM解析器。parse()方法告诉解析器到哪个URL去找XML源，然后得到结果文档并返回。loadAssets()方法调用parse()方法从某个XML源加载文档，然后为文档中找到的每个“media-asset”节点创建一个MediaAsset对象。
以下是一个使用MediaAsset类的例子：
package jaf.xml;
import java.util.*;
public class MediaAsset {
// 资源元数据
private String mName = "";
private String mDesc = "";
private Collection mChildren = new LinkedList();
private Vector mTypes = new Vector();
private String mUrn = "";
protected MediaAsset(org.w3c.dom.Node assetNode) {
// 为简洁起见省略后面代码
.
.
.
}
}
因为篇幅的关系省略了MediaAsset类的详细代码，但应用模式依然是清晰的。MediaAsset类遍历文档的节点，当它碰到不同的子节点时，它用子节点的内容填充自己的成员数据。如果它发现了一个嵌套的子资源节点，它只需要创建一个新的MediaAsset对象，然后将子资源节点的数据填充到新对象的成员数据中。
实现上述处理的方法数不胜数。我们还可以使用其他的解析器或解析器架构，如Java API for XML Parsing (JAXP)。除了使用DOM模型外，事件驱动的SAX模型也可用于解析XML。类似的程序也可用来产生XML数据??前提是允许产生新的数据对象（在本例中是MediaAsset），它可将其相应的XML实体插入到DOM中，然后将DOM输出到一个流中（诸如一个文件，一个Socket，或者一个HTTP连接...）。还有其他更高层次的标准，可将XML映射到Java对象的过程进一步自动化（或简化）。例如，使用XML概要（Schema）和XML绑定处理引擎，您可以半自动地将满足某个XML 概要的XML数据转变成Java数据对象。代表性的引擎是Castor，是由ExoLab小组管理的一个开放源代码项目的产物。上述使用Xerces DOM的简单例子仅仅是演示了这一处理过程的底层模型。
上述示例表明，在Java环境中解析或产生XML是非常方便的，这与J2EE没有必然关联。格式化为XML的数据可以从应用程序的任何层次流入或输出，这使得与外部系统的集成性无可限量。但我们能否以一种更为直接的方式将XML数据源集成到J2EE架构中去呢？
驾驭消息
J2EE架构包含了对JMS（Java消息服务）API的访问，以实现面向消息的通信（J2EE 1.2.1版只需JMS API即可，在J2EE 1.3版中JMS基本定型，此时必须由某个兼容J2EE平台的服务器提供一个JMS API Provider）。这一类的异步交互（与之相对的是：本地或远程方法调用所代表的同步交互）被证明在某些应用环境中是非常有用的。某些时候，交互只需要通过间接的请求或回答来实现，即：在某些情况下，发出消息后不可能立即收到答复，但我们仍希望当消息发出者重新在线时，确保他能收到答复信息。
面向消息系统的实际应用之一就是企业之间的松散集成。类似于EDI（电子文档交换）时代的文档交换，两个企业由于业务的需要而交换消息，此时通常不能为了使用RPC或者RMI、CORBA、DCOM之类的远程方法交互而在两者之间进行紧密集成。象JMS API这样的消息系统允许双方交换基于JMS API的消息载荷，前提是双方在会话的时候均能提供兼容的JMS API服务。当前仍然存在的困难是：双方是否能尊从相同的格式或协议。
这正是XML大显身手的时候。XML明确地被设计来解决此类数据交换问题??灵丹妙药就是“面向消息的概要表”（Message-Oriented Communication Scheme），实质就是基于一个双方认同的DTD或schema，用XML格式来交换消息载荷。
JMS API支持好几种消息，其中的TextMessage代表文本消息载荷。一个简单而有效的XML消息交换方案是，在一端将我们的XML文档插入TextMessage，然后在另一端用自制的XML解析程序（如前面的MediaParser）解开数据并（可选地）将其转换成Java对象。这使得我们既可以用JMS API支持的公开预订的消息模型，也可以用JMS API支持的点对点的消息模型来发送XML消息。
上述方法有一些局限，因为对于JMS运行时处理而言，XML的内容基本上是不透明的。例如，JMS API允许使用基于特定消息头的路由。这很容易理解，尤其当我们希望XML消息根据其内容采取不同走向时。例如在我们的MediaAsset例子中，我们希望公开讲座内容，但只想把特定的内容传送给那些预订了课程的人，或传送给那些表明可以接受某些媒体格式（如视频流）的人。为了发挥JMS API的价值，以便实现上述基于内容的消息路由，我们有必要从XML数据中解析出关键信息，然后在构造标准JMS API消息头时插入这些信息。这是可行的，但要实现XML信息我们就得额外地写很多代码（交换消息的双方均如此）。
为了在XML和JMS API之间架起桥梁，一些厂商提供了自定义的JMS扩展，以便直接支持XML消息机制。例如，BEA系统公司基于J2EE的WebLogic应用服务器特别为TextMessage提供了XMLMessage子类，允许用XPath表达式来过滤XML消息。不过这是一种专有的扩展，这要求交换消息的双方必须都能处理这类消息。
为此，Sun公司目前正在开发用于XML消息的Java API（JAXM）。其目标是提供一个高级别的标准服务，以实现基于ebXML的消息的合成与传送。一个JAXM服务提供程序可以将这类消息映射到适当的物理消息系统（诸如JMS API）中去。
让XML看得见
将XML同Web系统的用户界面进行集成显然是一种有益的尝试。绝大多数的界面程序，无论是基于还是不基于Web，都是将数据进行转换，然后用易读的格式展现给用户。用诸如XML这种“易消化”的格式存放数据将简化上述工作，同时它还大大提高了内容的可管理性，接下来我们就可看到这一点。不过首先要大书一笔的是，XML在Web界面层的应用得益于JSP技术的发展。
一直以来大家都希望能清晰地区分Web应用程序的表示层与底层对象模型，JSP框架诞生于这些努力之中（包括早期JHTML尝试）。JSP框架允许将Java代码嵌入到HTML内容中，这样既可以实现动态内容，又不必经常修改Java Servlets的代码。在页面中包含Java技术的途径是通过JSP标记（JSP Tags），这些标记以XML风格出现。在JSP中，Java程序以代码片段、服务器端JavaBeans组件、在服务器端触发特定操作的不透明标记（标准的或自定义的）等形式存在。当某个用户通过浏览器请求JSP页面时，一个Java应用服务器解析该JSP页面，将其编译成一个Java Servlet，然后执行该Servlet以产生答复页面。
一种直接将XML数据源集成到JSP的界面中去的方法是，将XML加载到JavaBeans组件中（如同我们在MediaAsset例子中所做的），然后在JSP中直接引用这些JavaBeans组件。
下面是一个嵌入Java代码片断的例子：
<html>
<head>
<title>第14讲的媒体资源</title>
</head>
<body>
<!-- 引入我们的类 -->
<%@ page import="jaf.xml.*" %>
<center><H3>Media Assets for Lecture 14:</H3></center>
<!-- 定义一个资源对象，以便用于显示 -->
<jsp:useBean class="jaf.xml.MediaAsset" id="asset" />
<!-- 从一个先前定义的位置装载资源 -->
<% MediaParser parser = new MediaParser();
Collection assets = parser.loadAssets("http://javaschool.org
/jaf/E162/lecture14-assets.xml");
Iterator iter = assets.iterator();
%>
<table border=0>
<tr><th>Name</th><th>Type</th><th>URN</th></tr>
<%
while (iter.hasNext()) {
asset = (MediaAsset)iter.next();
%>
<tr><td><jsp:getProperty name="asset" property="name" /></td>
<td><jsp:getProperty name="asset" property="type" /></td>
<td><jsp:getProperty name="asset" property="URN" /></td>
</tr>
<%
}
%>
</table>
</body>
</html>
其中粗体部分为JSP代码片断和标记，其余部分是标准的HTML文本。
上述程序还有一种更简洁的写法，那就是使用自定义JSP页面标记。这样我们就可以从JSP页面中剔出代码段，只使用JavaBeans组件和自定义的JSP标记即可。比如说，为了去掉创建解析器、加载资源数据到集合中的那段代码，我们可创建一个自己的标记，由它在幕后完成这些工作。以下是例子：
.
.
.
<!-- 引入我们的类 -->
<%@ page import="jaf.xml.*" %>
<center><H3>Media Assets for Lecture 14:</H3></center>
<!-- 加载我们自定义的标记库 -->
<%@ taglib uri="http://javaschool.org/taglib" prefix="media" %>
<!-- 从一个先前定义的位置装载资源 -->
<media:load url="http://javaschool.org/jaf/E162/lecture14-assets.xml"
collectionName="assets" cursorName="asset" />
<table border=0>
.
.
.
使用自定义标记的最大好处是使我们的程序代码集中在一个地方（对Java技术而言，一般是指在“类”中），易于管理。这样可以将程序中对象层同界面层的集成关系定义得很清晰，修改代码所造成的影响是可以预测和管理的。
直接将XML数据转换成Web显示内容的另一种方法是使用XSL和XSLT。在这种方案中，将XML数据映射成HTML（或WML等）的逻辑由XSL样式表（XSL StyleSheet）来定义。样式表描述了每个特定XML数据实体应该怎样转换成界面数据实体（如HTML表格、内联标记等）。在JSP架构中，XSL转换只能应用于特定的XML数据源，最理想的是采用一套自定义的JSP标记并引用某个XSLT处理程序。这方面的典型示例请参考java.sun.com中关于XML同JSP构架集成的白皮书。
同前面那个JSP自定义标记加XML解析器组件的方案相比，XSLT方案的伸缩性要好一些，而且具有更好的可管理性。在这种情形下，我们的转换逻辑是编写在一个XSL样式表中，而不是在Java代码中。这意味着当需要修改界面时，大多数情况下只是编辑样式表或者HTML，代码不受影响。不过在决定选用何种方案之前，还是要根据实际状况仔细权衡。如果选用XSLT方案，那么就得有人负责维护这些XSL样式表（要么是负责界面的人，要么是编写程序的人）。XSLT既像内容，又像程序，因此双方都不能把责任推给对方，结果大家可能都被这不伦不类的XSLT弄得矛盾百出。从这点上考虑，采用自定义标记并由界面开发者将其嵌入表示层的方法似乎更有吸引力，因为这样软件工程师只考虑Java代码，而内容工程师也只操心内容标记。
Java servlet过滤器是J2EE 1.3版在其Web层最新发布的一种Web组件。当Sevelet将请求写入某个资源或者从某个资源中读取回答信息时，过滤器可以非常方便地转换其中的头信息和内容信息。这里所说的资源可以是一个Java servlet、一个JSP页面，甚至一个静态Web页。过滤器的确很“酷”，因为它允许开发人员从转换内容的代码中分离出生成内容的那部分代码，并加以重用。当需要通过XSLT方式将XML数据转换到不同的XML应用目标时，Java servlet过滤器尤其有用。
在J2EE应用程序中使用Java servlet过滤器转换其输出，以便兼容任何类型客户端的前景呼之欲出。servlet过滤器能够侦测到来自使用WAP协议（无线应用协议）的移动客户端的呼叫，并且将答复内容转换成WML（无线标记语言）格式。servlet过滤器也能检测到来自iMode无线客户的呼叫，并将其转变成cHTML（紧凑HTML）格式。当然，servlet过滤器也能够分辨出传统的HTML浏览器客户的请求，并用正确的格式进行回复。
结束语
在J2EE 1.2.1规范中，XML“集成”仅指组件或应用程序的XML格式的部署描述。在J2EE 1.3规范中，对XML的支持被扩展为要求具备SAX 2和DOM 2解析器，以及在兼容J2EE的服务器平台上提供XSLT转换处理程序。您可以毋庸置疑地相信，将来在J2EE架构中还会集成进更多的XML特性，因为J2EE规范的定义者们会认真倾听开发者社区中对在企业级应用中使用更多XML的渴求呼声。例如，JSR（Java定义请求）处理小组中与JAXM规范相关的部分（JSR 000067）承诺在J2EE后续规范中集成进JAXM。可以预见，在JSP架构、EJB和JDBC规范中均会有类似的变化。J2EE平台中上述组件的变革，将使Java技术开发者目前用的XML更为规范化（以及标准化），发挥出更大的威力。
|
|
|
|
|
|
|
|
posted on 2006-07-20 12:07
MEYE 阅读(660)
评论(0) 编辑 收藏 所属分类:
JAVA