posts - 1,  comments - 25,  trackbacks - 0
  2013年4月5日
     摘要: 这两天又做了个Execute Jar Project.觉得以前的Path的知识都忘的差不多了,决定自己总结一下。1. 获取类路径    返回类路径内容,一般为:lib1.jar;lib2.jar。1System.getProperty("java.class.path");     在命令行运行Java程序时...  阅读全文
posted @ 2013-04-05 13:38 Daniel 阅读(244) | 评论 (1)编辑 收藏
  2012年7月23日

2.1-1这题可以参照书上17自己给出过程,这里就略去了。

2.1-2 先给出书上insertion-sort的C源代码吧,然后再给出按照非升序的代码:

课本中(非降序的)insertion-sort代码:

 

  1. void insertion_sort(int *A, int n)  
  2. {  
  3.     int i,j;  
  4.     int key; 
  5.  
  6.     for(i = 1; i < n; i++)  
  7.     {  
  8.         j = i - 1;  
  9.         key = A[i]; 
  10.  
  11.         while(j >= 0 && A[j] > key)  
  12.         {  
  13.             A[j+1] = A[j];  
  14.             j = j - 1;  
  15.         } 
  16.  
  17.         A[j+1] = key;  
  18.     }  

 

在这题中,只要讲非降序改成非升序排序,所以改后代码如下:

 

  1. void insertion_sort(int *A, int n)  
  2. {  
  3.     int i,j;  
  4.     int key; 
  5.  
  6.     for(i = 1; i < n; i++)  
  7.     {  
  8.         j = i - 1;  
  9.         key = A[i]; 
  10.  
  11.         while(j >= 0 && A[j] < key)  
  12.         {  
  13.             A[j+1] = A[j];  
  14.             j = j - 1;  
  15.         } 
  16.  
  17.         A[j+1] = key;  
  18.     }  

 

2.1-3这题给出伪代码:

 

  1. int find(int *A , int n, int v) 
  2.  
  3.  
  4.     int  i = 0; 
  5.  
  6.     for( ; i < n; i++) 
  7.  
  8.     { 
  9.  
  10.         if(v == A[i]) 
  11.  
  12.             return i; 
  13.  
  14.     } 
  15.  
  16.   
  17.  
  18.     return NIL; 
  19.  

 

2.1-4直接给出代码:

 

  1. /*在A[]和B[]中,数组的最低位对应与二进制的高位,即如果一个二进制数是011100,用数组表示就是A[] = {0,1,1,1,0,0}*/ 
  2.  
  3. void add(int *A ,int *B, int *C, int n)  
  4. {  
  5.     int i, a, c = 0;  
  6.     int s;  
  7.     for(i = n - 1; i >= 0 ; i--)  
  8.     {  
  9.         s = A[i] + B[i];  
  10.          
  11.         C[i+1] = (s + c) % 2;  
  12.         c = (s + c) / 2;  
  13.     } 
  14.  
  15.     C[0] = c;  

 

posted @ 2012-07-23 22:12 Daniel 阅读(127) | 评论 (0)编辑 收藏
  2012年6月25日

优化屏障和内存屏障

优化屏障 (Optimization Barrier)

编译器编译源代码时,会将源代码进行优化,将源代码的指令进行重排序,以适合于CPU的并行执行。然而,内核同步必须避免指令重新排序,优化屏障(Optimization barrier)避免编译器的重排序优化操作,保证编译程序时在优化屏障之前的指令不会在优化屏障之后执行。

Linux用宏barrier实现优化屏障,gcc编译器的优化屏障宏定义列出如下(在include/linux/compiler-gcc.h中): 

#define barrier() __asm__ __volatile__("": : :"memory")

上述定义中,“__asm__”表示插入了汇编语言程序,“__volatile__”表示阻止编译器对该值进行优化,确保变量使用了用户定义的精确地址,而不是装有同一信息的一些别名。“memory”表示指令修改了内存单元。

内存屏障 (Memory Barrier)

软件可通过读写屏障强制内存访问次序。读写屏障像一堵墙,所有在设置读写屏障之前发起的内存访问,必须先于在设置屏障之后发起的内存访问之前完成,确保内存访问按程序的顺序完成。

读写屏障通过处理器构架的特殊指令mfence(内存屏障)、lfence(读屏障)和sfence(写屏障)完成,见《x86-64构架规范》一章。另外,在x86-64处理器中,对硬件进行操作的汇编语言指令是“串行的”,也具有内存屏障的作用,如:对I/O端口进行操作的所有指令、带lock前缀的指令以及写控制寄存器、系统寄存器或调试寄存器的所有指令(如:cli和sti)。

Linux内核提供的内存屏障API函数说明如表2。内存屏障可用于多处理器和单处理器系统,如果仅用于多处理器系统,就使用smp_xxx函数,在单处理器系统上,它们什么都不要。

posted @ 2012-06-25 12:05 Daniel 阅读(480) | 评论 (0)编辑 收藏
     摘要: Preface最近看了一下<Java Concurrency In Practice> 这本书, 总体来说还是一本不错的书, 不过粒度不够细, 是从大的角度, 例如: 设计整体项目上如何考虑并发的多方面因素,不过总体上来说还是一本不错的书,结合部分网络上的资料,总结一下自己的知识,免的忘了。下面是一些最基本的知识,不想再写了,反正网上多的是,挑了一篇还不错的转过来,大家要支持别人的成果...  阅读全文
posted @ 2012-06-25 09:37 Daniel 阅读(1275) | 评论 (0)编辑 收藏
  2012年4月25日

java nio小结

根据网上的资料做些整理

Java NIO API详解

http://www.blogjava.net/19851985lili/articles/93524.html

这篇文章对nio的api讲解比较全,可以帮助在宏观上把握nio。

BIO 方式使得整个处理过程和连接是绑定的,只要连接建立,无论客户端是否有消息发送,都要进行等待处理,一定程度上浪费了服务器端的硬件资源,因此就有了NIO 方式。Java 对于 NIO 方式的支持是通过 Channel和 Selector 方式来实现,采用的方法为向 Channel注册感兴趣的事件,然后通过 Selector 来获取到发生了事件的 key,如发生了相应的事件,则进行相应的处理,否则则不做任何处理,是典型的Reactor 模式,按照这样的方式,就不用像 BIO 方式一样,即使在没有消息的情况下也需要占据一个线程来阻塞读取消息,从而提升服务器的使用效率, 为实现 TCP/IP+NIO 方式的系统间通讯, Java 提供了 SocketChannel和 ServerSocketChannel两个关键的类,网络 IO 的操作则改为通过ByteBuffer 来实现,具体的基于 java实现TCP/IP+NIO 方式的通讯的方法如下所示。

服务器端:

复制代码
package com.eric.test.nio;

import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.util.Iterator;
import java.util.Set;
import java.nio.channels.SocketChannel;

public class NIOServer {
/*标志数字*/
private static int flag = 0;
/*定义缓冲区大小*/
private static int block = 4096;
/*接收缓冲区*/
private static ByteBuffer receiveBuffer = ByteBuffer.allocate(block);
/*发送缓冲区*/
private static ByteBuffer sendBuffer = ByteBuffer.allocate(block);
/*定义Selector*/
private Selector selector;

public NIOServer(int port) throws IOException{
//打开服务器套接字通道
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();

//服务器配置为非阻塞
serverSocketChannel.configureBlocking(false);

//检索与此服务器套接字通道关联的套接字
ServerSocket serverSocket = serverSocketChannel.socket();

//进行服务的绑定
serverSocket.bind(new InetSocketAddress(port));

//通过open()方法找到Selector
selector = Selector.open();

//注册到selector
serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);

System.out.println("Server Start -----8888:");
}
//监听
public void listen() throws IOException{

while(true){
//监控所有注册的 channel ,当其中有注册的 IO 操作可以进行时,该函数返回,并将对应的 SelectionKey 加入 selected-key set
selector.select();

//Selected-key set 代表了所有通过 select() 方法监测到可以进行 IO 操作的 channel ,这个集合可以通过 selectedKeys() 拿到
Set<SelectionKey> selectionKeys = selector.selectedKeys();

Iterator<SelectionKey> iterator = selectionKeys.iterator();
while(iterator.hasNext()){
SelectionKey selectionKey = iterator.next();
handleKey(selectionKey);
iterator.remove();
}
}

}
//处理请求
public void handleKey(SelectionKey selectionKey) throws IOException{

//接受请求
ServerSocketChannel serverSocketChannel = null;

SocketChannel socketChannel = null;
String receiveText;
String sendText;
int count;
//测试此键的通道是否准备好接受新的套接字连接
if(selectionKey.isAcceptable()){

//返回创建此键的通道
serverSocketChannel = (ServerSocketChannel)selectionKey.channel();

//接受客户端建立连接的请求,并返回 SocketChannel 对象
socketChannel = serverSocketChannel.accept();

//配置为非阻塞
socketChannel.configureBlocking(false);

//注册到selector
socketChannel.register(selector, SelectionKey.OP_READ);

}else if(selectionKey.isReadable()){
//返回为之创建此键的通道
socketChannel = (SocketChannel)selectionKey.channel();

//将缓冲区清空,以备下次读取
receiveBuffer.clear();

//将发送来的数据读取到缓冲区

count = socketChannel.read(receiveBuffer);


if(count>0){
receiveText = new String(receiveBuffer.array(),0,count);
System.out.println("服务器端接受到的数据---"+receiveText);
socketChannel.register(selector, SelectionKey.OP_WRITE);
}
}else if (selectionKey.isWritable()) {
//将缓冲区清空以备下次写入
sendBuffer.clear();

// 返回为之创建此键的通道。
socketChannel = (SocketChannel) selectionKey.channel();

sendText="message from server--" + flag++;
//向缓冲区中输入数据
sendBuffer.put(sendText.getBytes());

//将缓冲区各标志复位,因为向里面put了数据标志被改变要想从中读取数据发向服务器,就要复位
sendBuffer.flip();

//输出到通道
socketChannel.write(sendBuffer);

System.out.println("服务器端向客户端发送数据--:"+sendText);
socketChannel.register(selector, SelectionKey.OP_READ);
}

}
public static void main(String[] args) throws IOException {
int port = 8888;
NIOServer server = new NIOServer(port);
server.listen();
}

}
复制代码

客户端

复制代码
package com.eric.test.nio;

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.SocketChannel;
import java.util.Set;

public class NIOClient {
/*标识数字*/
private static int flag = 0;
/*缓冲区大小*/
private static int BLOCK = 4096;
/*接受数据缓冲区*/
private static ByteBuffer sendBuffer = ByteBuffer.allocate(BLOCK);
/*发送数据缓冲区*/
private static ByteBuffer receiveBuffer = ByteBuffer.allocate(BLOCK);
/*服务器端地址*/
private final static InetSocketAddress SERVER_ADDRESS = new InetSocketAddress(
"localhost", 8888);

public static void main(String[] args) throws IOException {
// 打开socket通道
SocketChannel clientChannel = SocketChannel.open();

// 设置为非阻塞方式
clientChannel.configureBlocking(false);

// 打开选择器
Selector selector = Selector.open();

// 注册连接服务端socket动作
clientChannel.register(selector, SelectionKey.OP_CONNECT);

// 连接
clientChannel.connect(SERVER_ADDRESS);


SocketChannel socketChannel;
Set<SelectionKey> selectionKeys;
String receiveText;
String sendText;
int count=0;

while (true) {
//选择一组键,其相应的通道已为 I/O 操作准备就绪。
//监控所有注册的 channel ,当其中有注册的 IO 操作可以进行时,该函数返回,并将对应的 SelectionKey 加入 selected-key set
selector.select();

//返回此选择器的已选择键集。
selectionKeys = selector.selectedKeys();

//System.out.println(selectionKeys.size());
for(SelectionKey selectionKey:selectionKeys){

//判断是否为建立连接的事件
if (selectionKey.isConnectable()) {

System.out.println("client connect");
socketChannel = (SocketChannel) selectionKey.channel(); //
// 判断此通道上是否正在进行连接操作。
// 完成套接字通道的连接过程。
if (socketChannel.isConnectionPending()) {

//完成连接的建立(TCP三次握手)
socketChannel.finishConnect();

System.out.println("完成连接!");
sendBuffer.clear();
sendBuffer.put("Hello,Server".getBytes());
sendBuffer.flip();
socketChannel.write(sendBuffer);
}
socketChannel.register(selector, SelectionKey.OP_READ);
} else if (selectionKey.isReadable()) {
socketChannel = (SocketChannel) selectionKey.channel();
//将缓冲区清空以备下次读取
receiveBuffer.clear();

//读取服务器发送来的数据到缓冲区中
count=socketChannel.read(receiveBuffer);

if(count>0){
receiveText = new String( receiveBuffer.array(),0,count);
System.out.println("客户端接受服务器端数据--:"+receiveText);
socketChannel.register(selector, SelectionKey.OP_WRITE);
}

} else if (selectionKey.isWritable()) {
sendBuffer.clear();
socketChannel = (SocketChannel) selectionKey.channel();
sendText = "message from client--" + (flag++);
sendBuffer.put(sendText.getBytes());
//将缓冲区各标志复位,因为向里面put了数据标志被改变要想从中读取数据发向服务器,就要复位
sendBuffer.flip();

socketChannel.write(sendBuffer);
System.out.println("客户端向服务器端发送数据--:"+sendText);
socketChannel.register(selector, SelectionKey.OP_READ);
}
}
selectionKeys.clear();
}
}
}
复制代码

小结:之前对Selector注册事件和SocketChannel有点小困惑。SocketChannel就像一根水管,当监听到写事件时,就往管道写数据;当监听到读事件时,就从管道读出数据。

posted @ 2012-04-25 15:34 Daniel 阅读(309) | 评论 (1)编辑 收藏
  2011年12月21日

I、关系数据库设计范式介绍

1.1 第一范式(1NF)无重复的列

 
      所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。

说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。 

1.2 第二范式(2NF)属性完全依赖于主键[消除部分子函数依赖]

 
      第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。 
        第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是属性完全依赖于主键。 

1.3 第三范式(3NF)属性不依赖于其它非主属性[消除传递依赖]


            满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。 

II、范式应用实例剖析


        下面以一个学校的学生系统为例分析说明,这几个范式的应用。首先第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 
首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息,说关心的问题有如下几个方面。 
  • 学生有那些基本信息
  • 学生选了那些课,成绩是什么
  • 每个课的学分是多少
  • 学生属于那个系,系的基本信息是什么。

2.1 第二范式(2NF)实例分析

 
      首先我们考虑,把所有这些信息放到一个表中(学号,学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话)下面存在如下的依赖关系。 
        (学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话) 
         (课程名称) → (学分) 
        (学号,课程)→ (学科成绩)
2.1.1 问题分析
 
      因此不满足第二范式的要求,会产生如下问题 

        数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。 

        更新异常: 
             1)若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。 
            2)假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。 

       删除异常 : 假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。
2.1.2 解决方案
 
      把选课关系表SelectCourse改为如下三个表:
  • 学生:Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话);
  • 课程:Course(课程名称, 学分);
  • 选课关系:SelectCourse(学号, 课程名称, 成绩)。

2.2 第三范式(3NF)实例分析


        接着看上面的学生表Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话),关键字为单一关键字"学号",因为存在如下决定关系: 

       (学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话) 
        但是还存在下面的决定关系 
       (学号) → (所在学院)→(学院地点, 学院电话) 
        即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。 
        它也会存在数据冗余、更新异常、插入异常和删除异常的情况。 (數據的更新,刪除異常這里就不分析了,可以參照2.1.1進行分析)

        根据第三范式把学生关系表分为如下两个表就可以滿足第三范式了: 

        学生:(学号, 姓名, 年龄, 性别,系别); 
        系别:(系别, 系办地址、系办电话)。 

总结


       上面的数据库表就是符合I,II,III范式的,消除了数据冗余、更新异常、插入异常和删除异常。 
posted @ 2011-12-21 16:46 Daniel 阅读(133) | 评论 (0)编辑 收藏
  2011年12月1日
<html>   
  <head>   
  <meta http-equiv="Content-Type" content="text/html; charset=gb2312">   
  <meta name="GENERATOR" content="Microsoft FrontPage 4.0">   
  <meta name="ProgId" content="FrontPage.Editor.Document">   
  <title>光标位置</title>   
  <style>   
  INPUT{border: 1 solid #000000}   
  BODY,TABLE{font-size: 10pt}   
  </style>   
  </head>   
  <body>   
  <table border="0" width="700" cellspacing="0" cellpadding="0">   
  <tr>   
  <td width="479" rowspan="17">   
  点击 TextArea 实现光标定位   
  <p>   
  <input type="Button" value="ff" onclick="fo()"/>
  <input type="Button" value="UPLINE" onclick="upLine()"/>
  <input type="Button" value="DOWNLINE" onclick="downLine()"/>
  <textarea rows="17" cols="49" id="box" onclick="tellPoint()" >
HIGHHEEL
sfsfsfs
s1123
432434
asf
fsa
sf
3232</textarea> 
  <script type="text/javascript">
  function getPos(textarea) {
  var rangeData = {text: "", start: 0, end: 0 };
 
  if (textarea.setSelectionRange) { // W3C 
   textarea.focus();
   rangeData.start= textarea.selectionStart;
   rangeData.end = textarea.selectionEnd;
   rangeData.text = (rangeData.start != rangeData.end) ? textarea.value.substring(rangeData.start, rangeData.end): "";
  } else if (document.selection) { // IE
   textarea.focus();
   var i,
    oS = document.selection.createRange(),
    // Don't: oR = textarea.createTextRange()
    oR = document.body.createTextRange();
   oR.moveToElementText(textarea);
   
   rangeData.text = oS.text;
   rangeData.bookmark = oS.getBookmark();
   
   // object.moveStart(sUnit [, iCount]) 
   // Return Value: Integer that returns the number of units moved.
   for (i = 0; oR.compareEndPoints('StartToStart', oS) < 0 && oS.moveStart("character", -1) !== 0; i ++) {
    // Why? You can alert(textarea.value.length)
    if (textarea.value.charAt(i) == '/r' ) {
     i ++;
    }
   }
   rangeData.start = i;
   rangeData.end = rangeData.text.length + rangeData.start;
  }
  
  return rangeData;
  }
  
  function fo(){
 var text = new String(document.getElementById("box").value);
 var currentCurrosr = document.getElementById("pnum").value;
 alert(text.substring(currentCurrosr-1, currentCurrosr));
 pos = getPos(document.getElementById("box"));
 alert(pos.start);
//       var end = text.indexOf("\r\n", document.getElementById("pnum").value);
//      if(end == -1){
//     alert("END");
//      }
//     var start = text.lastIndexOf("\r\n", currentCurrosr);
//     if(start == -1){alert("START");}
//     var currentLine = getLine(currentCurrosr);
//     alert("CUL"+currentLine+"L"+currentLine.length);
//     var nextLine = getLine(end + 1);
//     alert("NEXT"+nextLine+"L"+nextLine.length);
//     var preLine = getLine(start - 1);
//     alert("PRE"+ preLine+"L"+preLine.length);
  }
  
  function upLine(){
 var text = new String(document.getElementById("box").value);
 var currentCurrosr = document.getElementById("h1").value;
      var end = text.indexOf("\r\n",currentCurrosr);
      var start = null;
      if(currentCurrosr == end){
start =text.lastIndexOf("\r\n", currentCurrosr-1);  
      }else{
      start = text.lastIndexOf("\r\n", currentCurrosr);
      }
      if(start == -1){alert("Already the toppest!");
      return;
      }
      var preLine = getLine(start-1);
      var currentLine = getLine(currentCurrosr);
      var preLineStart = text.lastIndexOf("\r\n", start-1);
      var sq = null;
      var endPart = text.substring(end,text.length);
    alert(text.length);
      if(preLineStart == -1){
    sq = new String(currentLine).substring(2, currentLine.length).concat("\r\n").concat(preLine).concat(endPart);
    alert(sq);
    alert(sq.length);
      }else{
     alert(preLineStart);
     sq = text.substring(0, preLineStart).concat(currentLine).concat(preLine).concat(endPart);
          alert(sq);
          alert(sq.length);
      }
      document.getElementById("box").value=sq;
  }
  
  function downLine(){
 
  }
  
   
  
  
  function getLine(currsor){
var text = new String(document.getElementById("box").value);
var end = text.indexOf("\r\n", currsor);
if(end == -1){
return text.substring(text.lastIndexOf("\r\n", text.length), text.length);
}
var tmp = text.substring(0, end);
var start = tmp.lastIndexOf("\r\n", end);
if(start == -1){
}
// alert(tmp);
// alert(start);
// alert(text.substring(start+4, end).length);
// alert(text.substring(start+4, end));
return text.substring(start, end);
}
  function movePoint()   
  {   
  var pn=parseInt(pnum.value);   
  if(isNaN(pn))   
  return;   
  var rng=box.createTextRange();   
  rng.moveStart("character",pn);   
  rng.collapse(true);   
  rng.select();   
  returnCase(rng)   
  }   
  function tellPoint()   
  { 
  var rng=event.srcElement.createTextRange();   
  rng.moveToPoint(event.x,event.y);   
  rng.moveStart("character",-event.srcElement.value.length)   
  h1.value=rng.text.length; 
  pnum.value=rng.text.length;
  returnCase(rng)   
  }   
   
  function returnCase(rng)   
  {   
  bh.innerText=rng.boundingHeight;   
  bl.innerText=rng.boundingLeft;   
  bt.innerText=rng.boundingTop;   
  bw.innerText=rng.boundingWidth;   
  ot.innerText=rng.offsetTop;   
  ol.innerText=rng.offsetLeft;   
  t.innerText=rng.text;   
  }   
   
  function selectText(sp,ep)   
  {   
  sp=parseInt(sp)   
  ep=parseInt(ep)   
  if(isNaN(sp)||isNaN(ep))   
  return;   
  var rng=box.createTextRange();   
  rng.moveEnd("character",-box.value.length)   
  rng.moveStart("character",-box.value.length)   
  rng.collapse(true);   
  rng.moveEnd("character",ep)   
  rng.moveStart("character",sp)   
  rng.select();   
  returnCase(rng);   
  }   
  var rg=box.createTextRange();   
  function findText(tw)   
  {   
  if(tw=="")   
  return;   
  var sw=0;   
  if(document.selection)   
  {   
  sw=document.selection.createRange().text.length;   
  }   
  rg.moveEnd("character",box.value.length);   
  rg.moveStart("character",sw);   
   
  if(rg.findText(tw))   
  {   
  rg.select();   
  returnCase(rg);   
  }   
  if(rg.text!=tw)   
  {   
  alert("已经搜索完了");   
  rg=box.createTextRange();   
  }   
  }   
  </script>   
  </p>   
  <p></p>
  
  <input type="hidden" id="h1">   
  光标位置:<input type="text" value="0" id="pnum" size="8"> <input type="button" onclick="movePoint()" value="移动光标到指定位置">   
  <p></p>   
  选择指定范围:<input type="text" size="9" id="sbox"> -- <input type="text" size="9" id="ebox"> <input type="button" onclick="selectText(sbox.value,ebox.value)" value="选择">   
  <p></p>   
  选择查找字符 :<input type="text" value="" id="cbox" size="8"> <input type="button" onclick="findText(cbox.value)" value="查找下一个并选择">   
  </td>   
  <td width="217">boundingHeight:&nbsp;<span id="bh"></span></td>   
  </tr>   
  <tr>   
  <td width="217">boundingWidth:&nbsp;<span id="bw"></span></td>   
  </tr>   
  <tr>   
  <td width="217">boundingTop:&nbsp;<span id="bt"></span></td>   
  </tr>   
  <tr>   
  <td width="217">boundingLeft:&nbsp;<span id="bl"></span></td>   
  </tr>   
  <tr>   
  <td width="217">offsetLeft:&nbsp;<span id="ol"></span> </td>   
  </tr>   
  <tr>   
  <td width="217">offsetTop:&nbsp;<span id="ot"></span> </td>   
  </tr>   
  <tr>   
  <td width="217">text:&nbsp;<span style="position: absolute; z-index: 10" id="t" ></span> </td>   
  </tr>   
  </table>   
  </body>   
  </html>
posted @ 2011-12-01 23:03 Daniel 阅读(202) | 评论 (0)编辑 收藏
  2011年8月31日


14.1 Web Services和面向服务的软件架构(Service Oriented Architecture,简称SOA)概述:

 

在最新Java开发世界里,我们经常会遇到这样一个名词:Web Services(Web服务)。同时还会发现,与这个名词同时出现的多是各大主流技术供应商,各大技术供应商无一不在关注这一领域的发展。从Microsoft的.NET架构,到SUN的SUN ONE,以及IBM的Web Services,都体现了这些重量级的技术提供者对Web Services的推崇与重视。

 

电子商务的发展促进了Web Services的发展。Web服务可以使公司降低进行电子商务的成本,更快地部署解决方案以及开拓更多的新机遇。Web服务使应用程序的集成比以前更快、更容易而且更便宜。它更注重服务语义而不那么注重网络协议语义的消息,从而实现了业务功能的松散耦合。这些特性对于在企业之间和企业内部通过web连接业务功能是非常理想的。它提供了一致化(Uniform)的编程模型,从而在企业内外都可以利用通用的基础设施并以一种通用的方法进行应用程序集成。

 

要理解Web Services, 首先需要认识面向服务的软件架构(Service Oriented Architecture,简称SOA),Web Services是SOA架构系统的一个实例。

14.1.1面向服务的软件架构(SOA)

 

1. 面向服务中的基本概念

在面向服务的架构中包含一些基本的概念,透过这些基本概念可以进一步了解面向服务的架构。

(1) 服务的概念

在SOA中的服务是指能够处理一些任务过程的动作的抽象概念,这些服务可以被描述,可以被发现,可以由服务代理负责向请求者提供服务并给出结果。代理是指请求或者提供服务的人所使用的软件工具,人通过代理进行交互操作。

(2) 消息的概念

服务代理之间需要通过消息的传递进行交互操作,消息的内容含有一定的语义和数据,消息传输需要与某个通信协议相绑定才能够实现。

(3) 服务的描述和发现

众多的服务组成一个开放系统,除了需要提供信息交互方式以外,还需要提供相互了解的机制,这就需要提供描述和发现的方式。代理可以通过服务的描述来了解一个服务的内容,包括使用这个服务的技术信息、访问这个服务的地址信息等内容。当新的服务被投入到系统之中后,它需要被注册,并且要能够被发现,使它可以被利用起来。

 

2.为什么需要面向服务的软件

由于软件需求的扩大,软件系统变得越来越复杂。面对复杂的系统资源,我们需要一种更加合理的方式将不同类型、不同位置的子系统有力地结合起来,这种整合并不是将它们之间绑定得更加紧密,而是利用更加松散的方式来建立这个系统。

SOA通过松散的方式将分布式的软件模块结合起来,与旧有系统集成相比有着明显的优势。对于服务的使用者来说,可以简单地通过服务的描述来获取服务,系统各部分之间不必为了某一部分的升级而改变,在服务的过程中不同的软件模块可以充当不同的角色,从而构成整个系统的工作体系。

在SOA当中,一个服务代表的是一个由服务提供者向服务请求者发布的一些处理过程,这个过程在被调用之后,获得服务请求者所需要的一个结果。在这个过程中,服务请求者可以向任何能够提供此项服务的服务提供者来请求服务,服务实现的过程对于服务请求者来说是透明的。

随着系统分布式和多种结构复合程度的提高,SOA的巨大优势将进一步被挖掘。

(1) 建立松散耦合的系统

松散耦合系统的优点已经被业内充分地认可,SOA作为一种分布式的系统,它实现了一种服务和描述等概念相结合的架构。

SOA中的服务在SOA架构中被标准的描述语言所描述,并通过与某种传输协议的绑定来实现相互之间的交互。这种基于服务的架构使整个系统成为一个松散耦合的结构,利用与通信协议的绑定将分布式系统中的所有部分连接起来,利用语义和服务的描述,在代理之间进行交互。

(2) 提高软件的重用性

面向服务的架构还提高了对软件的重用性。与组件方式相比,SOA系统中的单个服务的改变不会对其他部分造成严重的影响,同时利用服务的描述使同一服务可以充分地被其他系统所调用,各个系统之间形成了高度的重用性。

现在正在被广泛使用的一些服务,正在不断地被各个系统所重用,重用的条件十分简单,只要了解服务的描述,或者可以访问到服务的描述地址即可。与组件重用相比,服务的重用还具有与实现语言无关的特点,重用服务的客户端程序不需要使用与服务实现部分同样的开发语言,一切交互的过程都是利用与实现无关的方式进行的。

(3) 提供按需服务的代码

面向服务的架构也使得系统的实现虚拟化,在SOA架构中的请求和提供之间交互或相互代理的过程中,可计算的代码资源分布在松散结构中的各个部分上,当请求发生时才被调用和服务,所有计算过程都是按照请求者的需求进行的。服务的对象分为有状态和无状态两种方式提供服务,按照需求提供服务,也可以利用缓冲机制优化系统的系统。

总之,SOA使代码的开发变得更有服务的目的性,使开发更加有效和合理。

 

14.1.2 SOA与 Web 2.0

另外,我们补充一下SOA与目前同样热门的Web 2.0的关系。

实际上Web 2.0 和SOA的概念在很大程度上是相同的,只是被粉饰成为软件的不同部分(如果的确存在不同的话),也就是说SOA和Web 2.0有很多重叠的东西,例如都是基于调用(invoke)的服务,都能存在于网络的任何位置等等。

SOA和Web 2.0的共性远大于它们之间的区别,而且Web 2.0在推广SOA方面起到了一定作用。到现在为止,SOA和Web 2.0拥有不同的支持者- SOA更多涉及企业结构和商务开拓,而Web 2.0更关注用户。这种差别随着更多企业接纳Web 2.0而在变化,但是这两项技术有着不同的重心: Web 2.0告诉我们数据是软件应用中最重要的部分,而SOA告诉我们服务才是中心。SOA中传输数据的服务也非常重要,但是传统SOA更关注IT系统的接合处而不是那些能使接合处更具价值的东西。也就是说,SOA也许是通畅的管道,但并不是系统中通过的水的价值。许多行业领导者说企业同时需要SOA类方法的结构和Web 2.0方法的创业能力。

SOA和Web 2.0之间有许多共有的要素:

l 软件重组

l 管理

l 软件就是服务

l 应用就是平台

l 无意识的使用

l 开放

l AJAX

l 互操作性

l 货币化

l 安全

l 网络导向架构

特别要说的是,最后一条网络导向架构或者Web Oriented Architecture(WOA)是关键的内容,最终有可能会将SOA和Web 2.0合为一体。

 

了解了SOA后, 我们来介绍什么是Web Services。Web Services是SOA架构系统的一个实例。从技术角度来讲,Web Services是一种新的技术架构、新的软件应用环境。它的系统架构和实现技术完全继承已有的技术,可以认为Web Services是Internet的一种延伸,是现有的Internet面向更好的互操作能力的一个延伸。

14.2. Web Services的概念

Web Services,从字面上理解就是通过Web提供的服务。我们可以理解Web Services是自包含的、模块化的应用程序,它可以在网络(通常为Web)中被描述、发布、查找以及调用;也可以理解Web Services是基于网络的、分布式的模块化组件,它执行特定的任务,遵守具体的技术规范,这些规范使得Web Sevices能与其他兼容的组件进行互操作;也可以这样理解,所谓Web服务,它是指由企业发布的完成其特别商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项应用服务

对于Web Services,很多人会与Web Service混为一谈,认为二者指的是同一个事物。其实不然,前者指的是用于建构Web Service的技术框架,后者指的是使用Web Services技术而创建的应用实例。Web Services是描述了一些操作的接口,基于标准化的XML消息传输机制,我们可以通过网络访问这些操作。Web Services使用规范的、基于XML的WSDL(Web Services Description Language)语言描述的,这称为Web Services的服务描述。这一描述囊括了与服务交互所需要的全部细节,包括消息格式(详细描述操作的输入输出消息格式)、传输协议和位置。该接口隐藏了服务实现的细节,允许通过独立与服务实现、独立于软硬件平台、独立于编写服务所用的编程语言的方式使用该服务。这使得基于Web Services的应用程序具有松散耦合、面向组件和跨技术实现的特点。Web Services都履行一定的特定业务或任务,可以实现同其他Web Services一起用于实现复杂的商业交易。

从外部使用者角度而言,Web Services是一种部署在Web上的对象和组件,具备以下特征:

.完好的封装性:

Web服务既然是一种部署在web上的对象,自然具备对象的良好封装性,对于使用者而言,他能且仅能看到该对象提供的功能列表。

.松散耦合

这一特征也是源于对象/组件技术,当一个Web服务的实现发生变更的时候,调用者是不会感到这一点的,对于调用者来说,只要Web服务的调用界面不变,Web服务实现的任何变更对他们来说都是透明的,甚至是当Web服务的实现平台从J2EE迁移到了.NET或者是相反的迁移流程,用户都可以对此一无所知。对于松散耦合而言,尤其是在Internet环境下的Web服务而言,需要有一种适合Internet环境的消息交换协议,而XML/SOAP正是目前最为适合的消息交换协议。

.使用协议的规范性

这一特征从对象而来,但相比一般对象,它更加规范化和易于理解。首先,作为Web服务,对象界面所提供的功能应当使用标准的描述语言来描述(比如WSDL);其次,由标准描述语言描述的服务界面应当是能够被发现的,因此这一描述文档需要被存储在私有的或公共的注册库里面。同时,使用标准描述语言描述的使用协约将不仅仅是服务界面,它将被延伸到Web服务的聚合、跨Web服务的事务、工作流等,而这些又都需要服务质量(QoS)的保障。其次,我们知道安全机制对于松散耦合的对象环境的重要性,因此我们需要对诸如授权认证、数据完整性(比如签名机制)、消息源认证以及事务的不可否认性等运用规范的方法来描述、传输和交换。最后,在所有层次的处理都应当是可管理的,因此需要对管理协约运用同样的机制。

.高度可集成能力

由于Web服务采取简单的、易理解的标准,Web协议作为组件界面描述和协同描述规范,完全屏蔽了不同软件平台的差异,无论是CORBA、DCOM还是EJB,都可以通过这一种标准的协议进行互操作,实现了在当前环境下最高的可集成性。

 

14.2.1 Web Services的核心技术

 

Web Services 是一种基于组件的软件平台,是面向服务的Internet 应用。Web Services 是应用于Internet 的,而不是限于局域网或试验环境,这就要求Web Services 框架必须适用于现有的Internet 软件和硬件环境,即服务的提供者所提供的服务必须具有跨平台、跨语言的特性。其次,Web Services 所提供的服务不但是面向人,而且需服务于其它应用系统。现有的Web网站也可以认为是面向服务的,但这种服务仅仅可以提供给人使用(只有人类才可以读懂浏览器下载的页面) 。而新一代的Web Services 所提供的服务应能被机器所读懂,例如其它应用程序及移动设备中的软件系统。这样,我们可以看出,Web Services 的发展方向实际上是构造一个基于现有Internet 技术之上的分布计算系统。

Web Services 框架的核心技术包括SOAP(Simple Object Access Protocol,简单对象访问协议) ,WSDL(Web Services Description Lanuage,Web服务描述语言) 和UDDI(Universal Description,Discovery and Integration,通用描述,发现,集成) ,它们都是以标准的XML 文档的形式表述的。

XML是Web Services技术体系中最基础的标准,Web Services的一切都建立在XML技术的基础之上,包括Web Services的消息、描述和服务实现的各个环节。利用XML,Web Services的服务提供者和请求者可以利用不同的开发语言来协作完成服务调用的过程。XML是Web Services技术体系中的很多标准得以建立的基础,在Web Services系统中无处不在。

 

SOAP 是Web services 的通信协议。SOAP是一种简单的、轻量级的基于XML 的机制,用于在网络应用程序之间进行结构化数据交换。SOAP包括三部分:一个定义描述消息内容的框架的信封,一组表示应用程序定义的数据类型实例的编码规则,以及表示远程过程调用和响应的约定。

WSDL表示WEB服务说明语言。WSDL文件是一个XML 文档,用于说明一组SOAP消息以及如何交换这些消息,通过WSDL可以描述一个服务的信息。这些信息使不了解这个服务的开发者可以建立调用这个服务的客户端代码,或者通过WSDL帮助生成实现它的基本代码结构。WSDL在Web Services的实际开发过程中起着重要的作用。

 

  Web Services是基于互联网的应用程序模块,用于在互联网上运行,它采用开放的UDDI(Universal Description,Discovery and Integration,通用描述,发现,集成)标准。UDDI标准先由IBM、微软、Ariba制订,到目前为止获得了130多家公司的支持。UDDI 提供一种发布和查找服务描述的方法。UDDI 数据实体提供对定义业务和服务信息的支持。WSDL 中定义的服务描述信息是UDDI注册中心信息的补充。UDDI提供了一个开放,平台独立的技术框架,来使企业之间能在互联网上找到对方的服务,定义它们在互联网上的交互活动,以及这些信息的共享方式。

 

Web 服务体系结构基于三种角色(服务提供者、服务注册中心和服务请求者)之间的交互。

服务提供者。从企业的角度看,这是服务的所有者。从体系结构的角度看,这是托管访问服务的平台。 
服务请求者(用户)。从企业的角度看,这是要求满足特定功能的企业。从体系结构的角度看,这是寻找并调用服务,或启动与服务的交互的应用程序。服务请求者角色可以由浏览器来担当,由人或无用户界面的程序(例如,另外一个 Web 服务)来控制它。 
服务注册中心。这是可搜索的服务描述注册中心,服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间,服务请求者查找服务并获得服务的绑定信息(在服务描述中)。对于静态绑定的服务请求者,服务注册中心是体系结构中的可选角色,因为服务提供者可以把描述直接发送给服务请求者。同样,服务请求者可以从服务注册中心以外的其它来源得到服务描述,例如本地文件、FTP 站点、Web 站点、广告和服务发现(Advertisement and Discovery of Services,ADS)或发现 Web 服务(Discovery of Web Services,DISCO)。 

  Web Services 的体系架构如图1 所示

Web Services 服务提供方通过WSDL(Web Services Description Language) 描述所提供的服务,并将这一描述告知Web Services 注册服务器。注册服务器依据WSDL 的描述,依照UDDI (Universal Description Discovery and Integration) 的协定更新服务目录并在Internet 上发布。用户在使用Web Services 前先向注册服务器发出请求,获得Web Services 提供者的地址和服务接口信息,之后使用SOAP 协议(Simple Object Access Protocol) 与Web Services 提供者建立连接,进行通信。Web Services 的技术主要建立在XML 的规范之上,这保证了这一体系结构的平台无关性、语言无关性和人机交互性能。

 

14.2.2 Web 服务开发生命周期

Web 服务开发生命周期包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。

Web 服务开发生命周期有以下四个阶段:

1. 构建 
生命周期的构建阶段包括开发和测试 Web 服务实现、定义服务接口描述和定义服务实现描述。我们可以通过创建新的 Web 服务、把现有的应用程序变成 Web 服务和由其它 Web 服务和应用程序组成新的 Web 服务来提供 Web 服务的实现。

2. 部署 
部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义,以及把 Web 服务的可执行文件部署到执行环境(典型情况下,Web 应用程序服务器)中。

3. 运行 
在运行阶段,可以调用 Web 服务。在此,Web 服务完成部署,成为可操作的服务。服务请求者可以进行查找和绑定操作。

4. 管理 
管理阶段包括持续的管理和经营 Web 服务应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。

 

接下来我们具体展开Web Services原理。

 

14.3.Web Services原理

 

首先,我们将看看 Web 服务的一个概念性协议栈以及这个协议栈的细节。然后我们将讨论选择网络协议的标准。我们还将回顾一下基本的基于 XML 的消息传递分布式计算。我们将用服务描述扩展基本的 XML 消息传递,而服务描述是根据它的协议栈来解释的。接下来,我们将讨论服务描述在 Web 服务体系结构中的角色,说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。我们还将围绕服务发布讨论服务发现的角色。最后,我们将描述基本 Web 服务体系结构的扩展,电子商务需要这些扩展才能使用 Web 服务。

 

14.3.1 Web 服务协议栈

要以一种可交互操作的方式执行发布、发现和绑定这三个操作,必须有一个包含每一层标准的 Web 服务协议栈。图 2 展示了一个概念性 Web 服务协议栈。上面的几层建立在下面几层提供的功能之上。垂直的条表示在协议栈中每一层必须满足的需求。

图2. Web 服务概念性协议栈

Web 服务协议栈的基础是网络层。Web 服务要被服务请求者调用,就必须是可以通过网络访问的。互联网上可以公用的 Web 服务使用普遍适用的网络协议。HTTP 凭借其普遍性,成为了互联网可用的 Web 服务真正的标准网络协议。Web 服务还可以支持其它互联网协议,包括 SMTP 和 FTP。内部网域可以使用可靠消息传递和调用基础结构,如 MQSeries 和 CORBA 等等。

 

下一层是基于 XML 的消息传递,它表示使用 XML 作为消息传递协议的基础。选择 SOAP 作为 XML 消息传递协议有很多原因:

它是使用 XML 传送以文档为中心的消息以及远程过程调用的标准化封装机制。 
SOAP 很简单;它基本上是一个用 XML 信封作为有效负载的 HTTP POST。 
SOAP 比对 XML 简单的 HTTP POST 更受青睐,因为它定义了一个标准机制,这个机制将正交扩展(orthogonal extension)合并为使用 SOAP 报头和对操作或函数进行标准编码的消息。 
SOAP 消息支持 Web 服务体系结构中的发布、查找和绑定操作。 
服务描述层实际上是描述文档的一个协议栈。首先,WSDL 是基于 XML 的服务描述的真正标准。这是支持可交互操作的 Web 服务所需的最小标准服务描述。WSDL 定义了服务交互的接口和结构。要指定业务环境、服务质量和服务之间的关系,我们还需要另外的描述。WSDL 文档可以由其它服务描述文档来补充,从而描述 Web 服务的这些更高级的方面。例如,描述业务环境除了使用 WSDL 文档,还要使用 UDDI 数据结构。Web 服务流程语言(Web Services Flow Language,WSFL)文档中则描述了服务组成和流程。

因为 Web 服务被定义为可以通过 SOAP 从网络进行访问,并由服务描述表示,所以该协议栈中的前三层需要提供或使用 Web 服务。最简单的协议栈将包括网络层的 HTTP、XML 消息传递层的 SOAP 协议以及服务描述层的 WSDL。所有企业间或公用 Web 服务都应该支持这种可交互操作的基础协议栈。Web 服务,特别是企业内部或专用 Web 服务,能够支持其它的网络协议和分布式计算技术。该协议栈提供了互操作性,它使 Web 服务能够利用现有的互联网基础结构。这将使进入普遍存在的环境的成本非常低。另外,灵活性并不会因为互操作性需求而有所降低,因为我们可以为选择性和增值的技术提供另外的支持。例如,我们必须支持 HTTP 上的 SOAP,但也可以同时支持 MQ 上的 SOAP。

协议栈的最下面三层确立了保证一致性和互操作性的技术,而它们上面的两层,即服务发布和服务发现,可以用多种解决方案来实现。

任何能够让服务请求者使用 WSDL 文档的操作,不管它处于服务请求者生命周期的哪个阶段,都符合服务发布的标准。该层中最简单、最静态的实例就是服务提供者直接向服务请求者发送 WSDL 文档。这被称为直接发布。电子邮件是直接发布的载体之一。直接发布对静态绑定的应用程序来说很有用。另外,服务提供者还可以将描述服务的文档发布到主机本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点。

Web 服务如果没有被发布就不能被发现,所以说服务发现依赖于服务发布。该层的各种发现机制和一组发布机制互相平行。任何允许服务请求者获得对服务描述的访问权,并在运行时使应用程序能够使用该服务描述的机制都必须符合服务发现的标准。最简单、最静态的发现的实例是静态发现,其中服务请求者从本地文件获取 WSDL 文档。这通常都是通过直接发布获取的 WSDL 文档,或者前面查找操作的结果。另外,也可以通过使用本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点在设计时或运行时发现服务。因为 Web 服务实现是一种软件模块,所以通过组建 Web 服务来产生 Web 服务是很自然的。Web 服务的组合可以扮演很多角色之一。企业内部的 Web 服务可能会相互合作,从而对外显示出一个单独的 Web 服务接口,或者,来自不同企业的 Web 服务可以相互合作,从而执行机器到机器、企业到企业的事务。另外,工作流程管理者还可以在参与业务流程的时侯调用每个 Web 服务。最上面一层,即服务流程,描述了如何执行服务到服务的通讯、合作以及流程。WSFL 用于描述这些交互。要使 Web 服务应用程序满足当今电子商务的迫切需求,就必须提供企业级基础结构,包括安全性、管理和服务质量。这几个垂直条在协议栈的每一层都必须得到解决。每一层的解决方案可以彼此独立。随着 Web 服务范例的采用和发展,将会出现更多此类垂直条。

该协议栈的最下面几层表示基础 Web 服务协议栈,它们相对于协议栈中上面几层来说更成熟,也更标准。Web 服务的成熟和采用将会带动协议栈中上面几层和垂直条的开发和标准化。

网络层

Web 服务协议栈的最底层是网络层。该层可表示任意多个网络协议:HTTP、FTP、SMTP、消息排队(Message Queuing)、互联网 ORB 间协议(Internet Inter ORB Protocol,IIOP)上的远程方法调用(Remote Method Invocation,RMI)、电子邮件等等。在任何给定的情况下使用的网络协议都依赖于应用程序需求。

对于可以从互联网访问的 Web 服务,人们选择网络技术的时侯通常会倾向于选择普遍部署的协议,如 HTTP。对于内部网中提供和使用的 Web 服务,使用另外的网络技术也会被认同。我们可以根据其它需求选择网络技术,包括安全性、可用性、性能以及可靠性。这使得 Web 服务可以利用已有的功能更高级的联网基础结构和面向消息的中间件,如 MQSeries。在有多种网络基础结构的企业中,HTTP 可以用来在这些基础结构之间搭建桥梁。

Web 服务的好处之一在于,它为专用内部网和公用互联网服务的开发和使用提供了统一的编程模型。所以,网络技术的选择对服务开发者来说是透明的。

基于 XML 消息传递的分布式计算

Web 服务体系结构最基础的支柱是 XML 消息传递。当前 XML 消息传递的行业标准是 SOAP。IBM、Microsoft 以及其它企业都向 W3C 建议 SOAP 作为 XML 协议工作组(XML Protocol Working Group)的基础。XML 协议将代替 SOAP 作为行业标准 XML 消息传递协议的位置。当 W3C 发布 XML 协议的草案标准时,Web 服务体系结构就会从 SOAP 迁移到 XML 协议。

SOAP 是一种简单的、轻量级的基于 XML 的机制,用于在网络应用程序之间进行结构化数据交换。SOAP 包括三部分:一个定义描述消息内容的框架的信封、一组表示应用程序定义的数据类型实例的编码规则,以及表示远程过程调用(remote procedure calls,RPC)和响应的约定。SOAP 可以和各种网络协议(如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI)相结合使用,或者用这些协议重新封装后使用。

虽然理解这个基础很重要,但多数 Web 服务开发者不必直接处理这个基础结构。大多数 Web 服务都会使用从 WSDL 生成的经过优化的特定于编程语言的绑定。当服务提供者和服务请求者都在类似的环境中执行时,这种优化可能尤为重要。

图 4 展示了 XML 消息传递(即 SOAP)和网络协议如何组成Web 服务体系结构的基础。

图 4. 使用 SOAP 的 XML 消息传递

网络节点在基于 XML 消息传递的分布式计算中扮演提供者和请求者角色的基本要求是构建、解析 SOAP 消息的能力(或两者兼而有之),以及在网络上通信的能力(接收、发送消息,或两者)。

通常,在 Web 应用程序服务器中运行的 SOAP 服务器将执行这些功能。另外,我们也可以使用在 API 中封装这些功能的特定于编程语言的运行库。应用程序与 SOAP 的集成可以通过使用四个基本步骤来实现:

在图 4 中,服务提供者的应用程序在(1)创建一条 SOAP 消息。这条 SOAP 消息是调用由服务提供者提供的 Web 服务操作的请求。消息主体中的 XML 文档可以是一个 SOAP RPC 请求,也可以是一个服务描述中所描述的以文档为中心的消息。服务请求者将此信息和服务提供者的网址一起提供给 SOAP 基础结构(例如一个 SOAP 客户机运行时)。SOAP 客户机运行时与一个底层网络协议(例如 HTTP)交互,然后在网络上将 SOAP 消息发送出去。 
网络基础结构在(2)将消息传送到服务提供者的 SOAP 运行时(例如一个 SOAP 服务器)。SOAP 服务器将请求消息路由到服务提供者的 Web 服务。如果应用程序需要,SOAP 运行时负责将 XML 消息转换为特定于编程语言的对象。这个转换由消息中可以找到的编码模式所控制。 
Web 服务负责处理请求信息并生成一个响应。该响应也是一条 SOAP 消息。响应的 SOAP 消息在(3)被提供给 SOAP 运行时,其目的地是服务请求者。在 HTTP 上的同步请求/响应的情况中,联网协议的底层请求/响应本质用于实现消息传递的请求/响应本质。SOAP 运行时将 SOAP 消息响应发送到网络上的服务请求者。 
响应消息在(4)由服务请求者节点上的联网基础结构接收。消息会经过整个 SOAP 基础结构;可能会将 XML 消息转换为目标编程语言中的对象。然后,响应消息被提供给应用程序。 
本示例使用了请求/响应传送基本原理,这种原理在大多数分布式计算环境中都很常见。请求/响应交换可以是同步的,也可以是异步的。其它传送基本原理,如单向消息传递(无响应),通知(推动式响应)以及发布/订阅,也可能用到 SOAP。

那么,服务请求者如何知道请求消息应该使用什么格式呢?这个问题在下面会得到回答。

 

服务描述:从 XML 消息传递到 Web 服务

服务提供者是通过服务描述将所有用于调用 Web 服务的规范传送给服务请求者的。要实现 Web 服务体系结构的松散耦合,并减少服务提供者和服务请求者之间所需的共识的程度和定制编程与集成的程度,服务描述就是关键。例如,不管是请求者还是提供者,都不必了解对方的底层平台、编程语言或分布式对象模型(如果有的话)。服务描述与底层 SOAP 基础结构相结合,足以封装服务请求者的应用程序和服务提供者的 Web 服务之间的这个细节。

基本服务描述

Web 服务体系结构使用 WSDL 作为基本服务描述。WSDL 已经被提交到 W3C 作为标准。WSDL 是一种 XML 文档,它将 Web 服务描述为一组端点,这些端点会处理包含面向文档或面向过程的(RPC)消息的消息。操作和消息都是被抽象描述的,然后它们会被绑定到一个具体的网络协议和消息格式,用来定义端点。相关的具体端点被合并到抽象的端点或服务中。WSDL 可以扩展为允许端点和其消息的描述,不管使用哪种消息格式或网络协议进行通讯都可以。然而,目前经过描述的绑定只能用于 SOAP 1.1、HTTP POST 以及多用途互联网邮件扩展(Multipurpose Internet Mail Extensions,MIME)。

Web 服务体系结构中对 WSDL 的使用按照常规将基本的服务描述分成了两部分:服务接口和服务实现。这使每个部分都可以被分开独立定义,并可以由另一部分重新使用。

服务接口定义是一种抽象或可重用的服务定义,它可以被多个服务实现定义实例化和引用。我们可以将服务接口定义想象成接口定义语言(Interface Definition Language,IDL)、Java 接口或 Web 服务类型。这使常见的行业标准服务类型可以被多个服务实现者定义和实现。这类似于在编程语言中定义抽象接口然后得到多个具体实现。服务接口可以由行业标准组织定义。

服务接口包含 WSDL 元素,它们组成了服务描述中的可重用部分,这些元素有:WSDL: binding、WSDL: portType、WSDL: message 和 WSDL: type 元素,如图 5 中所描述。WSDL: portType 元素中定义了 Web 服务的操作。操作定义了输入和输出数据流中可以出现的 XML 消息。您可以将操作想象成编程语言中的方法说明。WSDL: message 元素指定哪些 XML 数据类型组成消息的各个部分。WSDL: message 元素用于定义操作的输入和输出参数。WSDL: types 元素中描述消息中复杂数据类型的使用。WSDL: binding 元素描述特定服务接口(WSDL: portType)的协议、数据格式、安全性和其它属性。

服务实现定义是一个描述给定服务提供者如何实现特定服务接口的 WSDL 文档。Web 服务被建模成 WSDL: service 元素。服务元素包含一组(通常是一个)WSDL: port 元素。端口将端点(例如网址位置或 URL)与来自服务接口定义的 WSDL: binding 元素关联起来。

为了说明职责的安排,开放应用程序组(Open Applications Group,OAG)为开放应用程序组集成规范(Open Applications Group Integration Specification,OAGIS)购买标准定义了一个服务接口定义。这个服务接口定义会定义 WSDL: type、WSDL: message、WSDL: portType 和 WSDL: binding。

服务提供者可以选择开发实现 OAGIS 购买订单服务接口的 Web 服务。服务提供者会开发一个服务实现定义文档,描述 WSDL 设备、端口和地址位置元素,这些元素描述提供者的 Web 服务的网址及其它特定于实现的细节。

服务接口定义和服务实现定义结合在一起,组成了服务完整的 WSDL 定义。这两个定义包含为服务请求者描述如何调用以及与 Web 服务交互的足够信息。服务请求者可以要求获得其它关于服务提供者端口的信息。此信息由服务完整的 Web 服务描述提供。

 

完整的 Web 服务描述

完整的 Web 服务描述建立在服务基本的 WSDL 定义之上。完整的 Web 服务描述可以解决这样的问题:什么企业在托管这个服务?它是何种类型的企业?与服务相关联的产品有哪些?各种公司和产品类别中与该企业或其 Web 服务相关联的分类有哪些?有没有服务的其它方面(如服务质量)会影响到请求者是否选择调用服务?为了使查找该服务更容易,可以提供哪些关键字?

图 6 中描述了一个完整的 Web 服务描述。

图 6. 完整的 Web 服务描述协议栈

UDDI 提供了一个保存 Web 服务描述的机制。虽然 UDDI 通常会被认为是一种目录机制,但是它也定义了一个用 XML 表示服务描述信息的数据结构标准。UDDI 条目中有四种基本数据结构,如图 7 中所示。

图 7. 基本 UDDI 数据结构

UDDI 条目由 businessEntity 开始。businessEntity 元素对关于企业的信息进行建模,包括基本的企业信息(例如企业名称和联系方式信息是什么?)、分类信息(例如这是何种类型的企业?)以及标识信息(即 Dunn and Bradstreet 编号是什么?)。businessEntity 包含一组 businessService 元素,每个元素对应于企业希望发布的每个 Web 服务。每个 businessService 元素都包含和 businessEntity 元素的 Web 服务有关的技术性和描述性信息。businessService 包含一组 bindingTemplate 元素。bindingTemplate 描述访问信息(例如端点地址),还描述 businessService 如何使用各种不同的技术规范。技术规范在这里的模型是 tModel。tModel 可以为很多不同概念建模,如:一种服务、一个诸如 HTTPS 之类的平台技术或一个类别。与 businessService 相关联的那一组 bindingTemplate 元素代表了 businessService 所使用的技术的印记。

在Web 服务体系结构中,完整的 Web 服务描述包括用于端点描述的一层,这个端点描述使用 UDDI 条目向服务描述添加企业和实现环境。

端点描述遵循结合 WSDL 使用 UDDI 的约定。端点描述使用 UDDI 提供企业信息和类别的标准表示。这个 UDDI-WSDL 约定规定了如何从和 Web 服务相关联的 UDDI 条目中得出服务接口定义和服务实现定义的 WSDL 描述。这个约定对于在Web 服务体系结构中使用 UDDI 作为基于 WSDL 的服务的服务注册中心来说至关重要。

端点描述向应用到服务的特定实现的服务描述添加了另外的语义。安全属性可以定义对 Web 服务的访问进行控制的策略。服务质量属性指定面向性能的能力,例如服务在一定时间内作出响应的能力,或所支持的可靠消息传递的级别。服务开销属性描述服务的资源需求。还可以定义支持哪些对话语义。

服务描述协议栈中的最后一层是协议描述。协议描述反映两个企业伙伴之间为了完成一个多步企业交互而进行的 Web 服务调用的一个简单的编排。例如,“协议定义”定义了购买协议中诸如购买者和出售者之类的角色。协议定义规定了每个角色必须达到的要求。例如,出售者必须有接受报价请求(request for quote,RFQ)消息、购买订单(purchase order,PO)消息和付款消息的 Web 服务。购买者的角色必须有接受报价(RFQ 响应信息)、发票消息和帐户摘要信息的 Web 服务。这个简单的 Web 服务到企业角色的编排对于在企业伙伴之间建立多步的、面向服务的交互来说至关重要。在很多不同的企业协议标准下,一个给定的服务请求者或服务提供者也许能够扮演购买者或出售者的角色。通过显式地建立企业协议和每个节点在企业协议中扮演各种角色的能力,请求者可以选择在面对各种提供者企业伙伴时加入哪种企业协议。

这个领域充满了创新。对于企业协议定义来说,目前还没有一个单独的标准。ebXML 协作-协议概要和协定规范(ebXML Collaboration-Protocol Profile and Agreement Specification)描述了这些概念,但不是根据作为该体系结构的一部分描述的 Web 服务技术而描述的。Web 服务流程描述和 Web 服务端点描述这两层正处于开发中,它们可以提供这个级别的服务描述。

 

服务描述的发布和发现

服务发布

Web 服务的发布包括服务描述的生成和之后的发布。发布可以使用各种不同机制。

生成服务描述 
我们可以生成、手工编码服务描述,也可以根据已有的服务接口定义组成服务描述。开发者可以手工编码整个服务描述,包括 UDDI 条目。有些工具可以从编程模型和可执行 Web 服务的部署生成 WSDL,还有可能生成来自元数据构件的部分 UDDI 条目。部分服务描述可能已经存在(例如,Web 服务可以基于一个行业标准服务接口定义),这样就只须进一步生成一小部分就可以了。

发布服务描述 
服务描述可以使用各种不同机制来发布。根据应用程序将使用服务的动态程度,这些不同的机制提供不同的能力。服务描述可以使用多种不同机制发布到多个服务注册中心。

最简单的情况是直接发布。直接发布意味着服务提供者直接将服务发布给服务请求者。这可以通过使用电子邮件附件、FTP 站点甚至光盘分发来实现。直接发布可以在企业伙伴双方就在 Web 上使用电子商务的条款达成一致后进行,或在请求访问服务的服务请求者支付了费用之后进行。在这种情况下,服务请求者可以保留服务描述的一份本地副本。

稍微更动态一点的发布使用 DISCO 或 ADS。DISCO 和 ADS 两者都定义了一个从给定 URL 获取 Web 服务描述的简单的 HTTP GET 机制。增强的服务描述资源库会提供服务描述的一个本地高速缓存,不过还提供了附加的搜索能力。对于在企业内部跨越主机的服务描述资源库来说,服务提供者会向专用的 UDDI 节点发布。我们可以根据发布到节点的 Web 服务的域的范围,使用几种专用的 UDDI 节点。

内部企业应用程序 UDDI 节点(Internal Enterprise Application UDDI node)节点:公司内部为了进行内部企业应用程序集成而使用的 Web 服务应该被发布到这一类 UDDI 节点。此类 UDDI 节点的范围可以是部门的或公司的单独的应用程序。这些 UDDI 位于防火墙之后,允许服务发布者对他们的服务注册中心和它的访问权、可用性以及发布要求有更多的控制。 
门户网站 UDDI 节点(Portal UDDI node)节点:由公司发布以供外部伙伴查找和使用的 Web 服务可以使用门户网站 UDDI 节点。门户网站节点运行在服务提供者的防火墙之外或之间。这种专用 UDDI 节点只包含公司希望向来自外部伙伴的请求者提供的那些服务描述。这允许公司保留对他们服务描述的控制、UDDI 节点的访问以及 UDDI 节点的服务质量。此外,通过使用门户网站中固有的基于角色的可见性,企业将服务描述的可见性局限在允许看到它们存在的伙伴中。 
伙伴目录 UDDI 节点(Partner Catalog UDDI node)节点:由特定公司使用的 Web 服务可以被发布到伙伴目录 UDDI 节点。伙伴目录 UDDI 节点位于防火墙之后。此类专用 UDDI 节点只包含来自合法企业伙伴的经过允许的、测试过的、有效的 Web 服务。此类 Web 服务的业务环境和元数据可以被定位到特定的请求者。 
电子市场 UDDI 节点(E-Marketplace UDDI node)节点:对于服务提供者打算用来与其它 Web 服务竞争请求者的业务的 Web 服务来说,服务描述应该被发布到电子市场 UDDI 节点或 UDDI 运营商节点。电子市场 UDDI 节点由一个行业标准组织或社团托管,包含特定行业中的企业的服务描述。我们可以要求这些服务支持特定的标准、可搜索元数据、接口或数据类型。电子市场 UDDI 节点一般会过滤掉某些非法的条目,并提供有保证的服务质量。 
UDDI 运营商节点:如果您希望 Web 服务可以被潜在的新的企业伙伴或服务用户发现,还可以将其发布到 UDDI 运营商节点。IBM、Microsoft 和 Ariba 都支持、复制和托管 UDDI 运营商节点。在发布 UDDI 运营商节点的时侯,如果要让潜在的服务请求者发现服务的话,完整的业务环境和经过深思熟虑的分类法是很必要的。

图 8. 服务发现连续体

图 8 展示了从发布和发现中最静态、最简单的技术到最动态、更复杂的技术的连续体。Web 服务的用户或实现者不必严格遵循这个发展顺序。

服务发现

Web 服务的发现包括获取服务描述和使用描述。获取过程可以使用各种不同机制。

获取服务描述

和发布 Web 服务描述一样,根据服务描述如何被发布以及 Web 服务应用程序可能达到的动态程度,获取 Web 服务描述也会有所不同。服务请求者将在应用程序生命周期的两个不同阶段,即设计时和运行时查找 Web 服务。在设计时,服务请求者按照他们支持的接口类型搜索 Web 服务描述。在运行时,服务请求者根据他们通讯的方式或公告的服务质量搜索 Web 服务。

使用直接发布方法时,服务请求者在设计时对服务描述进行高速缓存,以在运行时使用它。服务描述可以被静态地用程序逻辑表示,并存储在文件或简单的本地服务描述资源库中。

服务请求者可以在设计时或运行时在服务描述资源库(简单的服务注册中心或 UDDI 节点)中检索一条服务描述。查找机制需要支持一种查询机制,它提供按接口类型(基于 WSDL 模板)、绑定信息(即协议)、属性(如 QoS 参数)、所需的中介类型、服务分类法、企业信息等等的查找。

不同类型的 UDDI 节点会显示可以选择的运行时绑定 Web 服务的数目、多选一的策略,或者调用服务之前必须由请求者作出预选的量。

内部企业应用程序 UDDI 节点和伙伴目录 UDDI 节点将不需要预选来建立对服务的信任。服务选择可以建立在绑定支持、历史性能、服务质量分类、相似性或负载平衡的基础之上。

电子市场 UDDI 节点将有更多的运行时服务可以选择。必须执行某种预选以保证 Web 服务提供者是有价值的伙伴。我们可以根据价格承诺、开销、经过允许的伙伴列表的出席情况,同样还有绑定支持、历史性能、服务质量分类和相似性来选择服务。

如果服务请求者从 UDDI 运营商节点查询 Web 服务提供者,他们在预选可能的服务提供者时就必须尽可能谨慎和认真。应该有一个有效和准确的机制就位,过滤掉无用的服务描述和没有价值的服务提供者。

使用服务描述 
在获取了服务描述之后,服务请求者需要处理它以调用服务。服务请求者使用服务描述生成对 Web 服务的 SOAP 请求或特定于编程语言的代理。该生成可以在设计时或运行时进行,从而对 Web 服务的调用进行格式化。我们在设计时和运行时可以使用各种工具从 WSDL 文档生成编程语言绑定。这些绑定表示应用程序的 API,并封装了来自应用程序的 XML 消息传递的细节。

在下一部分,我们将描述基本 Web 服务体系结构的扩展,电子商务需要这些扩展才能使用 Web 服务。

 

在下一部分,我们将描述基本 Web 服务体系结构的扩展,电子商务需要这些扩展才能使用 Web 服务。

 

14.3.2 真正的电子商务的 Web 服务

虽然对于可互操作的 XML 消息传递来说 SOAP 和 HTTP 就足够了,而且 WSDL 也足可以传达服务请求者和服务提供者之间需要什么样的消息,但是要覆盖电子商务的全部需求还需要更多的技术。为了完全支持电子商务,安全性、可靠的消息传递、服务质量、Web 服务协议栈的每一层的管理都需要扩展。

 

安全性

真的需要 Web 服务安全层吗?对于基于消息的体系结构,业界已经有一套现成的而且广泛接受的传输层安全机制,比如,安全套接字层(Secure Sockets Layer,SSL)和网际协议安全(Internet Protocol Security,IPSec),为什么还要再加别的呢?为了回答这个问题,我们不仅要研究要求,还将探讨一些只依靠现有的几类传输层安全机制并不能在 Web 服务模型内提供足够的安全性的情况。

通常,Web 服务安全层必须提供以下四个基本的安全性要求:

机密性(Confidentiality)是指信息对没有经过授权的个人、实体或进程的不可用性或不公开性,并保证消息内容不对没有经过授权的个人公开。 
授权(Authorization)是指权限的授予,包括根据访问权限授予访问权和保证发送方被授权发送消息。 
数据完整性(Data integrity)是指数据没有以未经授权的方式或被未经授权的用户不可察觉的改变或者破坏的性质,从而确保消息在传送的过程中不会被偶然或故意修改。 
原始性证明(Proof of origin)是对消息或数据的发送者进行标识的证据。断言消息由正确标识的发送者传送,并且不会重新发送以前传送过的消息。这一要求隐含了数据完整性的要求。 
由于需要在基于 XML 消息和工作流的动态 Web 服务世界中管理不同风格的资源访问,所以必须重新评估策略、信任和风险评估这三者相互之间的关系。现有的基于个人身份的访问控制模型正在发展成为基于角色的信任域关系,在该种关系中,可信任的权威机构将执行某项任务的权限授予个人,其行为受该权限限制。Web 服务体系结构定义了需要信息的代理(服务请求者)、提供信息的代理(服务提供者),有时还有提供关于信息的信息的代理(服务中介者、元信息提供者或服务注册中心)。服务中介者经常会收到大量信息请求,这样就需要它能够决定谁想要哪些信息以及请求者是不是已经被授予访问权。基础设施和关系变化迅速,因此有关的策略需要能灵活的允许或拒绝访问。

此外,尽管 XML 发誓要为这样的服务提供通用接口,但 XML 不会提供实现这一梦想所需要的整个基础设施。而且,XML 可能不适合构建整个 Web 服务安全层。目标是要确定在哪些场合用 XML 格式提供信息以顾及通用数据交换较为重要,以及在哪些场合利用目前已存在于平台之上的现有安全性机制较为重要。

SOAP 信封是用 XML 定义的,从而使您可以向消息添加种类众多的元信息,比如事务 ID、消息路由信息和消息安全性。SOAP 信封由两个部分组成:头和主体。头是把功能添加到 SOAP 消息中的通用机制。SOAP 头元素下一级的所有子元素都叫做头条目。主体是为最终的消息接收方想要的应用数据(如 RPC)准备的容器。因此,可以把 SOAP 看作是在传输层(例如 HTTP)和应用层(例如,业务数据)之间引入的另外一层,在此可以方便的传送消息元信息。SOAP 头提供可扩展机制以扩展 SOAP 消息使其可以适用于多种用途。虽然 SOAP 头是向消息添加安全性功能最合理的地方,但是 SOAP 规范本身并没有指定这样的头元素。

让我们仔细的分析一下在 Web 服务模型中现有的各种各样的传输层安全机制为什么不够,又为什么会需要 Web 服务安全层,以及这个安全层最初是怎样的。

端对端的消息传递。安全传输协议,如 SSL 和 IPSec,可以在传输过程中提供消息完整性和机密性,但只有在点对点的情况下,它们才会这样做。但是,因为 SOAP 消息是由中介体接收并处理的,所以即便两两之间的通信链路(communication link)是可信任的,只要在所有的中介体间没有信任关联(trust association),那么安全的端对端通信就是不可能的。如果有一条通信链路不安全,那么端对端安全性也会被削弱。就 Web 服务拓扑来看,安全的传输对于 SOAP 消息的端对端安全性是不够的。

中间件的独立性。最终,唯一能提供端对端安全性的方式就在于应用层或中间件层。如果消息在通信方之间的某点是纯文本,那么就有可能在这点受到攻击。但是,既要在新的或现有的应用中集成加密功能,又不能引入额外的安全性弱点或增加风险,这是一项不容易又不受欢迎的任务。因此,在大多数情况下,人们希望安全性功能尽可能靠近应用,但不在应用本身中构建。

传输的独立性。SOAP 中介体的原意是用来把信息转发到不同的网络上去,通常使用的传输协议也会有所不同。虽然所有的通信链路都是安全的,中介体也是值得信赖的,但是,安全信息(如消息发送者的身份验证)需要被转移到消息路径上的下一个传输协议安全性域,这个过程冗长而且复杂,还可能会导致完整性方面的缺陷。

异步多阶消息传递。传输层安全性保证数据在通信链路上传输时的安全。它与存储在任何中介体上的数据都无关。在一次传输被接收并解密后,传输层安全性对保护数据免受没有经过授权的访问和可能的改变就不是很有帮助了。在先存储消息然后转发的情况下(持久的消息队列),消息层保护是有必要的。

因为我们已经看到安全的传输机制不足以满足 Web 服务开发方法和使用场景的要求,所以我们的任务就是要创建一个概念性 Web 安全层,包括下列几个组件:

对于网络安全性: 
支持如 SSL 和 HTTPS 等提供机密性和完整性的安全传输机制。 
对于 XML 消息: 
如果通信没有中间节点,那么发送方可以依靠 SSL 或 HTTPS 来保证用户标识和密码的机密性。 
W3C 正在标准化 XML 数字签名工作的支持。它定义了生成消息摘要与利用发送方的私钥来签发消息的标准 SOAP 头和算法。因此,接收方就可以证明消息发送方的身份。 
对网络内部的、可信任的第三方验证服务(例如 Kerberos)的支持。 
概念性 XML 消息传递模型还必须支持端对端保护消息及其子元素。为了全面的支持,过程和流能力需要被扩展到包括消息交换的安全性特征。应该有一种方式可以定义多段消息和用预期接收方的公钥来保护消息段。需要探讨的一些论题有:

端点负责实现验证及授权。应该支持在企业之间交换信息的合同的任何描述中都要定义哪些雇员可以使用哪些服务。中介体负责审计和服务原始性证明。中介体还可能需要执行验证、授权和数字签名验证以及有效性检查。 
在服务端点的服务描述层中需要定义支持上文论述的安全性问题的面向安全性元数据。这些安全性描述将根据主体或角色定义 Web 服务层访问控制。服务描述将会描述是否支持数字签名、加密、验证和授权以及如何支持它们。 
请求者将使用服务描述的安全性元素来查找服务端点,该端点应符合政策要求及其安全性方法。 
标准组正在调查如下主题和技术。随着这些标准固定下来,它们将会被并入 Web 服务安全性体系结构。

W3C 有一个 XML 加密工作组,帮助提供数据元素的机密性,这样验证交换成为可能。 
W3C 已发布了一个 XML 密钥管理服务(XML Key Management Services,XKMS)的备忘录,来帮助分发及管理在端点之间进行安全的通信所需的密钥。 
OASIS 已经成立了一个技术委员会来定义授权和验证断言(Authorization and Authentication assertions,SAML)。这将帮助端点接受和决断访问控制权。 
OASIS 已经成立了一个技术委员会来标准化访问控制权的表达(XACML)。这将帮助端点能够以一致的方式解析 SAML 断言。 
随着我们不断的研究 Web 服务模型中遇到的所有威胁和对策,Web 服务安全性体系结构也在不断发展着。

 

服务质量(QoS)和可靠的消息传递

服务质量垂直塔提供与 Web 服务概念栈每一层有关的信息的规范。对于网络层,这将会暗示能使用各种级别的服务质量的网络。

由于需要通过网络进行可靠的消息传递,所以得根据在这一领域内发送高质量服务的能力来选择网络技术。可靠的消息传递指基础设施把消息一次发送(只发送一次)到预定目标或提供确定的事件(如果发送没能完成,也许会重新发送到源)的能力。结合网络层与 XML 消息传递将需要支持四个等级的消息传递服务质量:

1. 最佳努力:服务请求者发送消息,服务请求者和基础设施不尝试重发。

2. 至少一次:服务请求者提出请求,并一直重试直到它接收到确认为止。服务提供者重复消息处理不是问题,例如简单的查询处理。实现这可能意味着每个消息包含唯一的标识。服务请求者以自己确定的时间间隔重发没有得到确认的消息。服务提供者发出确认消息,为 RPC 响应消息,如果不能处理的话,就发送不能处理的消息异常。

3. 至多一次:这建立在最少一次情况的基础之上。服务请求者试着请求直到它得到回应。象现有的全局唯一标识符(universal unique identifier,UUID)这样的机制允许服务提供者抑制重复多次的请求,以确保请求不会被多次执行。例如,请求根据库存目录中的一个号码拿一件东西。

4. 刚好一次:服务请求者提出请求,请求已经执行的回应使其得到保证。刚好一次交换模式排除了重传请求的需要并且适应失效的情况。

可靠的消息传递通常是通过标准设计模式传送的,在该模式中,一件基础设施,有时叫做端点管理器,将会被用来在通信的每一端协调消息发送。在这种模式中,发送方通过同步请求把消息发给端点管理器。一旦发送到,发送方就可以得到保证,一定会把消息发送出去或引发确定的事件(例如超时)。端点管理器与其它资源管理器参与本地事务,在一次事务中不仅可以由端点管理器对消息进行排队,还有可能在数据库中记录业务过程步骤。应用程序应该指派端点管理器来负责发送消息或者检测发送失败的原因,它在网络传输层或 XML 消息传递层都可以起作用。

可靠的一次性消息发送的技术和目的都不会引起争议。但是,围绕如何在 SOAP 和 XML 的上下文中支持这项技术已经提出了重要的质疑。关键问题是:应不应该在 XML 消息层上定义必要的协议和消息格式,从而允许可靠的消息发送成为两端应用程序的责任,或者能不能在较低的层(如传输层上)定义协议和消息格式?

在没有支持可靠的消息传递的传输方式的情况下(即互联网),XML 消息传递层将需要在不可靠的基础设施之上支持这些服务质量。端点管理器将需要修改消息,而不是修改消息的传输信封,这样才能成功扮演其角色。应用程序和业务过程的定义将必须考虑所有可能的结果,如拒收消息或在可接受的时间长度内发送不出去。但是,这些定义还需要考虑在发送过程中发生的中间状态。向业务过程公开这些状态可能会大大增加其定义的复杂程度,但对于定义过程的业务分析师而言并无太大意义。在一些情况下,使用 XML 消息传递来发送可靠的消息传递格式可能会导致使用现有的这些传输毫无效率。最好能开发一种在互联网上使用的可靠的 HTTP 标准。

在有支持可靠的消息传递的传输方式的情况下(即在企业内部),它可以用于发送可靠的消息,而不是 XML 消息传递层(可能缺省为空实现)。端点管理器将会只修改传输信封,而不会修改 XML 消息。使用可靠的传输使应用程序和业务过程定义不需要知道或处理消息发送的中间状态。

需要在将来进行的几点补充:

互联网的 HTTP 需要加以改进才能提供可以在企业间使用的简单可靠的消息传递。这会带来额外的好处:不止 SOAP,许多种消息类型都可以采用可靠的消息传递。需要 XML 消息传递层处理可靠的消息传递的情况就会随之减少,促进不依赖于网络选择的应用程序开发。 
HTTP 上的 XML 消息传递层也需要处理发布和订阅、消息排序、发送时间限制、优先级和多点传送等等问题。 
服务提供者对可靠的消息传递的质量和实现的支持情况将会在服务描述的绑定信息中定义。

服务实现层(例如,通过事务的或安全的 SOAP 绑定)的服务描述以及接口层(例如,从请求者开始等待来自提供者的响应之后最长经过多久)的其它服务描述中都会关系到服务质量(Quality of Service)信息。人们期待着开发出 WSDL 扩展或新的服务描述层来允许指定其它服务质量和功能的规范。

Web 服务层上的服务质量可以在服务合成和服务流中使用。在为流选择服务或提示流管理器该开始恢复或其它的流时,预期的执行时间、超时值、历史平均执行时间值都可以作为输入。服务描述栈的端点描述层和工作流描述层必须提供这一信息。

Web 服务的服务质量问题和解决方案仍然很紧迫。

 

系统和应用程序管理(Management)

随着 Web 服务成为商业运作的重要因素,就需要对其进行管理。在这种情况下,所谓管理是指专为应用程序定制的或从厂商那里买来的管理应用程序可以发现 Web 服务的基础设施、Web 服务、服务注册中心和 Web 服务应用程序存在性、可用性以及健康度。最令人满意的结果是管理系统还应当能够控制和配置基础设施及组件。

管理概念性 Web 服务栈各层的 Web 服务和 Web 服务模型组件必定是有可能的。对管理的需求可以分成两个集中的领域。第一个领域是用于实现 Web 服务的基础设施的可管理性。主要的考虑应当是确保可用性和提供服务描述、消息传递和网络的关键元素的性能。Web 服务基础设施提供者应当提供这一层上的系统管理。

企业对其自己的基础设施及管理拥有完全的自主权。但是,当企业在对等基础上相互作用时,就应当提供对网络层、XML 消息传递层、服务注册中心和 Web 服务实现的基本报告和恢复办法。此外,企业向其合伙人提供的管理接口应当是在服务层上操作的,而不是在相对低级的基础设施层上。合伙人应该能够访问到报告操作和请求处理的状态和健康度的接口,但不一定要理解企业如何管理其请求的细节。

对于网络层,现有的网络管理产品几乎支持目前所有的网络基础设施。这些产品应当用于管理企业内部的 Web 服务的网络基础设施。当企业相互作用时,就应该向其合伙人提供有关 Web 服务基础设施可用性的基本报告。影响 Web 服务基础设施可用性的网络可用性应作为因素之一写入报告。

在 XML 消息传递层,协议应该在企业内部由现有的基础设施管理工具来管理。在企业相互作用的情况下,每个站点都有必要提供协议的基本报告和恢复办法。例如,如果站点 A 支持会话,就该向站点 B 提供可用于查询活跃的 IBM Software Group Architecture Overview Web Services Conceptual Architecture 28 会话以及强行回滚的接口。协议层需要正常的频道与协议和类似对等的控制接口。

管理的第二个方面是 Web 服务本身的可管理性。一些主要的考虑是性能、可用性、事件和使用量度,因为它们将为服务提供者市场收取所提供的服务使用费提供必要信息。

服务描述可以用于宣传可管理性特征和管理需求。这方面的约定正在开发之中。

服务注册中心的任何实现,不管是用于私人消费还是公共消费,都要求基础设施是可用的、发送承诺的服务质量并能够报告使用情况。这些系统管理元素对于成功采用 UDDI 是十分重要的。

对于 Web 服务应用程序组件来说,支持管理环境可能会大大增加应用程序的复杂性。由于 Web 服务必须易于开发,所以必须尽可能向开发者隐藏这样的复杂性。Web 服务的管理方式要使基础设施能自动提供量度、审计日志、启动和停止处理过程、事件通知和作为 Web 服务运行时的一部分(也就是说,起码是 SOAP 服务器)的其它管理功能。因为基础设施通过观察它所托管的组件的行为不可能收集到所有的信息,所以 Web 服务实现也许会需要向托管它的服务器提供基本的健康度和监督信息。

Web 服务基础设施应该为服务提供一种简单的方式以参与管理和利用管理基础设施。可管理的服务的 WSDL 文档的定义应当是 Web 服务能实现提供通过管理系统访问 Web 服务的管理信息的功能。这一接口可能包括的能力是获得配置和量度数据、更新配置及接收来自可管理的 Web 服务的事件。

Web 服务体系结构的平台独立性使它不适合套用任何一条 Web 服务管理标准。因此,需要有一种基于 Web 服务而且允许 Web 服务与管理系统通信的方法。为了达到这一目的,还应当定义由 WSDL 文档描述的、可接收来自可管理 Web 服务的事件以及量度更新的管理服务,并使其可用。管理服务的实现技术与 Web 服务无关。但是,对于基于 Java 技术的环境,Java 管理扩展(Java Management Extension,JMX)应该是合乎逻辑的而且厂商不可知的选择。通过使用 JMX 这样的开放标准,对现有的系统管理提供者来说,要把其目前所提供的产品扩展为包括 Web 服务关键元素的管理应该是很容易的。Web 服务的管理体系结构仍在向前发展。

 

14.4 Web Services 项目实战

14.4.1 Web Services实现

 

本书是重点讲解EJB 3.0的。在理解了Web Services原理之后, 接下来我们讲解如何使用J2EE和EJB3.0来实现Web Services

 

Web 服务遵循 Java 2 平台,企业版(Java 2 Platform,Enterprise Edition,J2EE)、通用对象请求代理体系结构(Common Object Request Broker Architecture,CORBA)以及其它针对与耦合较紧的分布式或非分布式应用程序集成的标准。Web 服务是部署并提供通过 Web 访问业务功能的技术;J2EE、CORBA 和其它标准是实现 Web 服务的技术。

 

J2EE 1.4为使用常规Java类或企业级Java Beans来创建和部署web services提供了一个全面的平台。以下表格给出了J2EE 1.4中包括的web service APIs的细节。 

定义在Java Community Process的JSR 101之下的JAX-RPC,提供了创建和访问web services的Java API,因此它是使用J2EE平台创建和部署web services的“心脏和灵魂”。通过向应用程序开发者隐藏XML类型和Java类型映射的复杂性,以及处理XML和SOAP消息的底层细节,它提供了一个简单的,健壮的创建web services应用的平台。为了引入一个方法调用范式,它提供了两种编程模式:服务器端模式,使用Java类或无状态EJB开发web service 端点,和客户端模式,创建作为本地对象访问web services的Java客户端。JAX-RPC 1.1要求使用SOAP 1.1,并且实现与使用其他技术创建的web services之间的互操作性,比如微软的.NET。实现了J2EE1.4规范的应用服务器,比如OC4J 10.1.3和SUN的Java System Application Sever,提供了对于JAX-RPC的支持。

JAX-RPC的叫法有点用词不当,因为它既支持RPC类型的web services,也支持文档类型的web services。

Web Services部署模型

在J2EE 1.4之前,所有J2EE商家都使用他们私有的部署模型支持web services。J2EE 1.4为Java Web Services定义了部署模型。它为J2EE平台上的web services制定了开发,部署以及服务发布和使用的标准。

有了J2EE 1.4对web services的支持,让我们学习使用J2EE平台来建造web service的方法。

使用J2EE创建一个Web Service

把web service创建成一个轻便的和可互操作的分布式组件不是一项琐碎的任务。如之前讨论的,你既可以把常规Java类,也可以把无状态EJB部署成web services。常规Java类被打包在一个web模块中,而EJB web services被打包在标准的ejb-jar模块中。

在这两种部署选择中,你会使用哪一个呢?

Java 类对无状态EJB:永无止境的争论

你会选择常规Java类还是EJB作为你创建web service的技术可能是一个长期的争论。Java类比EJB更容易开发,它是纯的Java对象,并且它不具有EJB带来的“额外辎重”。但是,EJB提供了几个很好的特点,比如被声明的事务和安全性,因此它使开发者将精力集中于建立商业逻辑,而不需要担心基础服务架构。EJB 3.0大大简化了设计模型,在它的规范中,EJB看起来就像常规Java类。

使用J2EE 5.0简化SOA的开发

  使用J2EE创建面向服务的应用程序确实很困难,因此通过使用由JSR 181定义的Web Services 元数据注解,J2EE 5.0将使开发更简单。EJB 3.0和Web Services元数据具有相似的目标,就是向开发者提供亲和力。

  为了在J2EE 1.4中开发一个简单的Java web service,你需要几个web service定义文件:WSDL,映射文件和几个冗长的标准以及私有的web services部署描述符。Web Services元数据规范使用一种类似于EJB 3.0的缺省配置方法来使开发更简便。Web Services元数据注解处理器(或web services 装配工具)会为你生成这些文件,因此你只需要关心类的实现。

  当你使用Web Services元数据开发时,这是一个看起来如此简单的Java web service:

package com.ascenttech.ejb30.ws.demo; 
import javax.jws.WebMethod; 
import javax.jws.WebService; 
@WebService(name = "HelloWorldService", 
targetNamespace = "http://hello/targetNamespace" ) 
public class HelloWorldService { 
@WebMethod public String sayhello(String name ) { 
return "Hello” +name+ “ from jws";

}

  正如我之前提到的,EJB 3.0使用常规Java类简化了EJB的开发。通过利用EJB 3.0和Web Services元数据,开发基于EJB的web services将会变得越来越简单。当使用EJB 3.0和web services元数据时,这是一个看起来如此简单的HelloWorld EJB web service。你不必担心创建WSDL,部署描述符等等,应用服务器会在部署过程中生成这些定义文件。

package com.ascenttech.ejb30.ws;
import javax.ejb.Remote;
import javax.jws.WebService;
@WebService 
public interface HelloServiceInf extends java.rmi.Remote{
@WebMethod java.lang.String sayHello(java.lang.String name) 
throws java.rmi.RemoteException;
}

  如下是EJB 3.0中 HelloWorld EJB的实现类:

package com.ascenttech.ejb30.ws;
import java.rmi.RemoteException;
import javax.ejb.Stateless;
@Stateless(name="HelloServiceEJB")
public class HelloServiceBean implements HelloServiceInf {
public String sayHello(String name) {
return("Hello "+name +" from first EJB3.0 Web Service");
}
}

  以上例子清楚的表明了通过使用web services元数据和EJB 3.0,服务开发正在变得越来越简单。现在,你可以在实现了J2EE规范的应用服务中,比如JBoss Application Server等,开始创建和部署你的web services了。

14.4.2 Web Services 项目实战

14.4.2.1 Web Services的实现
本节使用EJB 3.0 实现一个web Services登录的例子。下面我们创建一个工程叫:EmployeeManager。加入用到的EJB 3.0的jar包。

我们先创建服务器端的实体Bean,这和创建普通的Ejb3.0实体bean是一样的:

package com.ascent.ejb.po;

import java.io.Serializable;

 

import javax.ejb.Remote;

import javax.ejb.Stateless;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.Id;

import javax.persistence.Table;

@SuppressWarnings("serial")

@Entity

@Table(name = "usr")

 

public class User implements Serializable

{

private Integer id;

private String name;

private String password;

private String description;

@Id

@GeneratedValue

public Integer getId()

{

return id;

}

public void setId(Integer id)

{

this.id = id;

}

@Column(name = "name", nullable = false)

public String getName()

{

return name;

}

public void setName(String name)

{

this.name = name;

}

@Column(name = "password", nullable = false)

public String getPassword()

{

return password;

}

public void setPassword(String password)

{

this.password = password;

}

@Column(name = "description", nullable = true, length = 100)

public String getDescription()

{

return description;

}

public void setDescription(String description)

{

this.description = description;

}

}

接着创建远程接口:

package com.ascent.webservice.bean;

 

import java.rmi.Remote;

import javax.jws.WebMethod;

import javax.jws.WebService;

import javax.jws.soap.SOAPBinding;

import javax.jws.soap.SOAPBinding.Style;

@WebService

@SOAPBinding(style=Style.RPC)

public interface LoginDao extends Remote {

@WebMethod

public boolean isLogin(String name, String password);

}

在LoginDao类中要注意的是Remote接口是要实现的,@SOAPBinding(style=Style.RPC),Soap的绑定方式也是需要的,不然在客户端是找不到LoginDao 。

下面创建会话bean:

package com.ascent.webservice.bean;

import java.util.List;

import javax.ejb.Stateful;

import javax.ejb.Stateless;

import javax.jws.WebService;

import javax.persistence.EntityManager;

import javax.persistence.PersistenceContext;

import javax.persistence.Query;

@Stateless

@WebService(endpointInterface = "com.ascent.webservice.bean.LoginDao")

public class LoginDaoBean

{

@PersistenceContext

protected EntityManager em;// the manager of entity

public boolean isLogin(String name, String password)

{

// define query sentence

StringBuffer hql = new StringBuffer();

hql.append("from User u where u.name='" + name + "'");

hql.append(" and u.password='" + password + "'");

// create the query

Query query = em.createQuery(hql.toString());

List queryList = query.getResultList();

// if the result is null

if (queryList.size() == 0)

{

return false;

}

// if the user's length greater 1

if (queryList.size() > 1)

{

return false;

}

// return single user

return true;

}

}

至此服务器端的类是建好了,这里又两个问题,需要说明一下

A. 两个类的方法中都没有抛出异常,可不可以抛出呢? 可以。但到实现SOA的时候会有一些问题,就是异常在经axis 通过WSDL2Java 生成后,在程序运行时有可能会出现找不到的情形。所以本文为了让大家在仿照这个例子时都能成功,所以也就抛弃了异常的抛出。

B. 两个类的方法的返回值是基本类型,而不是自定义类型,为什么会这样呢,自定义类型可以不可以呢,可以。

现在我们的webservice的服务器端就已经创建好了,我们把服务器端的三个类和persistence.xml文件一起打包部署到jboss服务器里。包名是:empdEjb。

下面我们来创建客户端:

package com.ascent.webservice.client;

import java.net.URL;

import javax.xml.namespace.QName;

import javax.xml.rpc.Service;

import javax.xml.rpc.ServiceFactory;

import com.ascent.webservice.bean.LoginDao;

public class LoginClient

{

public static void main(String[] args) throws Exception

{

String userName ="lxl";

String password = "lxl";

URL url = new URL("http://localhost:8080/empdEjb/LoginDaoBean?wsdl");

QName qname =

new QName("http://bean.webservice.ascent.com/jaws","LoginDaoService");

ServiceFactory factory = ServiceFactory.newInstance();

Service service = factory.createService(url, qname);

LoginDao loginDao = (LoginDao) service.getPort(LoginDao.class);

boolean isExists = loginDao.isLogin(userName, password);

if(isExists)

{

System.out.println("hello " + userName);

}

else

{

System.out.println("sorry " + userName + ", you are not user in the system!");

}

}

}

把服务器端发布出去以后,服务器端会自动发布一个webService,并且生成并发布一个WSDL文件,通过访问http://localhost:8080/empdEjb/LoginDaoBean?wsdl这个网址是可以找到的。http://bean.webservice.ascent.com/jaws 和 LoginDaoService 字符串,在客户端程序当中出现了上面两个字符串,它们在你生成的wsdl 文件中有详细的描述。在地址栏里输入http://localhost:8080/empdEjb/LoginDaoBean?wsdl,就可以看到wsdl文件了。这里你所需要做的是按照你自己的情况编写你自己的客户端程序。启动服务器后,在机子上运行客户端程序就可以了。当然你也可以去编写自己的jsp客户端去调用它。wsdl文件的内容如下:

<definitions name="LoginDaoService"

targetNamespace="http://bean.webservice.ascent.com/jaws">

<types/>

<message name="LoginDao_isLogin">

<part name="String_1" type="xsd:string"/>

<part name="String_2" type="xsd:string"/>

</message>

-

<message name="LoginDao_isLoginResponse">

<part name="result" type="xsd:boolean"/>

</message>

-

<portType name="LoginDao">

-

<operation name="isLogin" parameterOrder="String_1 String_2">

<input message="tns:LoginDao_isLogin"/>

<output message="tns:LoginDao_isLoginResponse"/>

</operation>

</portType>

-

<binding name="LoginDaoBinding" type="tns:LoginDao">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

-

<operation name="isLogin">

<soap:operation soapAction=""/>

-

<input>

<soap:body namespace="http://bean.webservice.ascent.com/jaws" use="literal"/>

</input>

-

<output>

<soap:body namespace="http://bean.webservice.ascent.com/jaws" use="literal"/>

</output>

</operation>

</binding>

-

<service name="LoginDaoService">

-

<port binding="tns:LoginDaoBinding" name="LoginDaoPort">

<soap:address location="http://lixinli:8080/empdEjb/LoginDaoBean"/>

</port>

</service>

</definitions>

这样一个WebService+Ejb 3.0的例子就实现了。

14.4.2.2 SOA的实现
本例还是基于前两个例子的基础上的,要保证上面的例子是能正常运行的。

1.WSDL2Java
从名字上可以看出,是把wsdl 转化为java的.在上面的例子中我们在服务器端生成了一个wsdl文件,现在要做的就是你把那个wsdl文件给别人或者别的公司,让他们根据wsdl中所描述的你所提供的服务,去开发一个应用,来访问你所提供的接口。拿到这个WSDL文件后要做什么呢,to java。我们来看看怎么to java。

这里,在原来的EmployeeManager工程下面建一个wsdl文件夹,将它放在下面,然后所要做的准备工作是,把包括axis在内的几个jar包找到,设置在你的classpath里面。然后在命令行下运行WSDL2Java。

哪几个jar包?

C:\axis-1_4\lib\axis.jar;C:\axis-1_4\lib\axis-ant.jar;C:\axis-1_4\lib\commons-discovery-0.2.jar;C:\axis-1_4\lib\commons-logging-1.0.4.jar;C:\axis-1_4\lib\jaxrpc.jar;C:\axis-1_4\lib\log4j-1.2.8.jar;C:\axis-1_4\lib\saaj.jar;C:\axis-1_4\lib\wsdl4j-1.5.1.jar;E:\jboss-4.0.5\server\default\lib\activation.jar;E:\jboss-4.0.5\server\default\lib\mail.jar

这是我classpath 里面所设置的几个jar包,后面两个可以不需要,第二个也可以不需要,后俩个只是保证运行的时候没有警告。

1. 将LoginDaoBean.wsdl 放在wsdl文件夹下面。E:\workspace\EmployeeManager\wsdl

2. 在命令行下进入E:\workspace\EmployeeManager\wsdl

3. 执行 java org.apache.axis.wsdl.WSDL2Java LoginDaoBean.wsdl

这个时候,你会发现在wsdl文件夹下面生成了一个目录,它里面包含了几个java类。

LoginDao.java,LoginDaoBindingStub.java,LoginDaoService.java,LoginDaoServiceLocator.java

2 SOA的实现
本节是一个以SOA+struts实现登录的例子。新建一个web工程,EmployeeWebService,然后将上面生成的几个类放入你的src目录下面,是放整个目录,别只放几个类进去. 构建struts资源。创建struts的过程就不在这里细说了。创建的action内容如下:

package com.ascent.webservice.struts.action;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.http.HttpSession;

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

import org.apache.struts.action.Action;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

import org.apache.struts.action.ActionMessage;

import org.apache.struts.action.ActionMessages;

import com.ascent.webservice.struts.form.LoginForm;

import com.ascent.webservice.bean.jaws.LoginDao;

import com.ascent.webservice.bean.jaws.LoginDaoServiceLocator;

public class LoginAction extends Action

{

public ActionForward execute(ActionMapping mapping, ActionForm form,

HttpServletRequest request, HttpServletResponse response)

throws Exception {

LoginForm loginForm = (LoginForm) form;

String userName = loginForm.getLoginName();

String password = loginForm.getPassword();

LoginDaoServiceLocator loginDaoServiceLocator = new LoginDaoServiceLocator();

LoginDao loginDao=

loginDaoServiceLocator.getLoginDaoPort();

boolean isExists = loginDao.isLogin(userName, password);

if(isExists)

{

System.out.println("hello " + userName);

HttpSession session = request.getSession();

session.setAttribute("loginName", loginForm.getLoginName());

return mapping.findForward("success");

}

else

{

System.out.println("sorry " + userName + ", you are not user in the system!");

ActionMessages messages = new ActionMessages();

messages.add("login",new ActionMessage("error.login.jsp.loginName.exists"));

this.saveErrors(request, messages);

return mapping.getInputForward();

}

}

}

这里用到的LoginDaoServiceLocator类和getLoginDaoPort()方法就是使用WSDL2Java命令把wsdl文件生成的类。现在就可以打包成叫employee的war文件,运行它。至此,你便可以在浏览器中输入http://localhost:8080/employee/login.jsp,运行你这个SOA的应用了。如果是把服务器端部署到别的机器上,只要把localhost改为相应的ip就可以了。

小结
本章首先介绍了目前一个前沿技术:Web Services和面向服务的软件架构(Service Oriented Architecture,简称SOA)。在理解了Web Services原理之后, 接下来我们讲解了如何使用J2EE和EJB3.0来实现Web Services。

 

posted @ 2011-08-31 13:25 Daniel 阅读(6151) | 评论 (0)编辑 收藏

rpc和document的区别  

2008-10-24 18:48:07|  分类: webservice|字号 订阅

 

翻译自 The Difference Between RPC and Document Style WSDL

rpc和document到底是什么意思?他们如何同"encoded/literal"相关联?二者的冲突来自哪里?

binding的style和use

通常情况下,web服务是由一个wadl文件来描述的的。在这个文件中,抽象的描述所支持的web服务操作和消息,然后关联到一个具体的网

络歇息和消息格式。典型的wsdl文件由这个几个元素组成:tyoes,message.porttype用来描述抽象的定义;biding和service指定具体的实

现。所有的这些元素包装在definitions元素中。

在binding元素中,rpc和document是最值得我们关注的元素。wsdl 的 binding描述了如何将service关联到消息协议;这些消息协议是

http,mime,soap中的任意一种。不过,实际中,soap是最常用的协议;rpc和document的区别也是在soap的下的区别(it is SOAP that

the RPC/document distinction refers to)。通常http(s)是传输soap消息的协议。

<wsdl:binding>元素包含一对参数,style(rpc|document)和use(encoded|literal),他俩会影响到soap消息的格式.他们的使用方式如下

<wsdl:binding name="Config1Binding" type="prt0:CreditLimitLocalWebServiceVi_Document">

    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

     <wsdl:operation name="creditLimitCheck">

        <soap:operation soapAction="" />

         <wsdl:input>

            <soap:body use="literal" parts="parameters" />

         </wsdl:input>

        <wsdl:output>

            <soap:body use="literal" />

         </wsdl:output>

</wsdl:operation>

</wsdl:binding>

style属性:

wsdl1.1要求binding的style要么是rpc要么是doucment。这个选择与如何组织soap的负荷相关。下面是分别他们如何影响<soap:body>内

容的细节。

document:<soap:body>的内容由定义在<wsdl:type>中的xml模式指定。他不需要遵循特定的soap规范。简言之,soap消息是通过

<soap:body>中的document发送出去,而没有额外的要遵循的格式规则。document style是一种默认的选择。

rpc: <soap:body>元素的结构需要遵循特定的规则(soap1.1规范第7部分有细节)。根据这些规则,<soap:body>可以包含唯一一个元素

,这个元素在operation后被命名,所有的参数都必须写成这个元素的子元素。

因为可以自由的选择哪种消息格式,遵循document格式的soap消息看上去很像rpc格式。

现在,决定性的问题是:选择其中任意一个选项后的结果是什么样?为何要选择rpc或者document?很多情况下,选择他们后,soap消息

的格式看起来很相像,那么为什么还要提供这种选择呢?原因要从soap标准化的历程中寻找。

use属性

这个属性指定了soap消息的编码规则。他同样在<wsdl:binding>元素中完成。他的值为encoded或者literal.

他引用了一系列规则,soap客户端和soap服务端都遵循这些规则以解释<body>元素中的内容。

use="literal" 意味着type定义遵循xml模式定义

use="encoded" 参考xml中已有的应用数据,通常指的是soap1.1规范中的soap编码规则。如果文档中没有自定义数据,就可以选择

encoded。

附文章全文:

The Difference Between RPC and Document Style WSDL

Summary

RPC style and document style are catchphrases frequently heard in the context of web services and the SOAP protocol. What exactly do they mean? How do they relate to the pair of terms "encoded/literal"? Where does the confusion about these terms come from? This article describes the WSDL binding style and use attributes.

By Susanne Rothaug

20 Nov 2004

Binding Style and Use

A web service is usually described by a WSDL (Web Services Description Language) document. In this document, the supported web service operations and messages are described abstractly and then bound to a concrete network protocol and message format. A typical WSDL document consists of the following elements: "types," "message," and "portType" for the abstract definitions; "binding" and "service" for the concrete specification. All of these elements are wrapped inside a "definitions" element.

In the context of RPC and document style, it is the binding element that we need to take a closer look at. A WSDL binding describes how the service is bound to a messaging protocol, either HTTP GET/POST, MIME, or SOAP. In practice, SOAP is the most universally used protocol; it is SOAP that the RPC/document distinction refers to. Usually HTTP(S) is used as transport protocol for the SOAP message – "SOAP over HTTP(S)."

The <wsdl:binding> element of the WSDL contains a pair of parameters that influence the form of the resulting SOAP messages: binding style (RPC or document) and use (encoded or literal). See how style and use are defined in the WSDL fragment below: <wsdl:binding name="Config1Binding" type="prt0:CreditLimitLocalWebServiceVi_Document">     <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />      <wsdl:operation name="creditLimitCheck">         <soap:operation soapAction="" />          <wsdl:input>             <soap:body use="literal" parts="parameters" />          </wsdl:input>         <wsdl:output>             <soap:body use="literal" />          </wsdl:output> </wsdl:operation> </wsdl:binding>

The "Style" Attribute

WSDL 1.1 specifies the style of the binding as either RPC or document. This choice corresponds to how the SOAP payload - i.e., how the contents of the <soap:Body> element - can be structured. Here are some details of how each style affects the contents of <soap:Body>:

  • Document: the content of <soap:Body> is specified by XML Schema defined in the <wsdl:type> section. It does not need to follow specific SOAP conventions. In short, the SOAP message is sent as one "document" in the <soap:Body> element without additional formatting rules having to be considered. Document style is the default choice.

  • RPC: The structure of an RPC style <soap:Body> element needs to comply with the rules specified in detail in Section 7 of the SOAP 1.1 specification. According to these rules, <soap:Body> may contain only one element that is named after the operation, and all parameters must be represented as sub-elements of this wrapper element.

As a consequence of the freedom of choice that the document style offers, the SOAP messages conforming to a document style WSDL may look exactly the same as the RPC equivalent.

The decisive question now is: What are the consequences of choosing one option or another? Why choose RPC over document, or document over RPC? In many cases, the SOAP messages generated from either RPC or document style WSDLs look exactly the same - so why offer the choice at all? The reason may be found in the history of the SOAP standard.

SOAP has its roots in synchronous remote procedure calls over HTTP and the appearance of the document accordingly followed these conventions. Later, it was seen as a simplification to use arbitrary XML in the SOAP body without adhering to conventions. This preference is reflected in the document style WSDL documents. So far, both options are represented in the WSDL specification and the choice of one or the other is mainly a question of personal taste since most SOAP clients today accept both versions.

The "Use" Attribute

The use attribute specifies the encoding rules of the SOAP message. This is also done within the <wsdl:binding> element, as seen in the example above. The value can be encoded or literal. It refers to the serialization rules followed by the SOAP client and the SOAP server to interpret the contents of the <Body> element in the SOAP payload.

  • use="literal" means that the type definitions literally follow an XML schema definition.

  • use="encoded" refers to the representation of application data in XML, usually according to the SOAP encoding rules of the SOAP 1.1 specification. The rules to encode and interpret a SOAP body are in a URL specified by the encodingStyle attribute. Encoded is the appropriate choice where non-treelike structures are concerned, because all others can be perfectly described in XML Schema.

The combination of the style and use attributes leads to four possible style/use pairs:

  1. RPC/encoded

  2. RPC/literal

  3. document/encoded

  4. document/literal

Some of these combinations are rarely used in practice, such as document/encoded. In general, the literal use is gaining importance, and as far as RPC/encoded is concerned, the Web Services Interoperability Organization (WS-I) in its Basic Profile Version 1.0a of August 2003 ruled out the use of SOAP encoding with web services. Document/literal and RPC/literal will be the only allowed style/use combinations in the future.

posted @ 2011-08-31 13:24 Daniel 阅读(1056) | 评论 (0)编辑 收藏
  2011年5月27日

The project requirements: Should convert TIF into JPG with JAVA, But seems only IMAGEIO can't support TIF.
So should use JAI, Java Advantage Image jars.

JAI api download page: http://download.java.net/media/jai/builds/release/1_1_3/

J
AI API document page: http://download.oracle.com/docs/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/index.html



C
ode as below:
package com.ebay.test1;
import java.awt.image.RenderedImage;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import javax.imageio.ImageIO;
import javax.media.jai.JAI;
import javax.media.jai.RenderedOp;
import org.junit.Test;
import com.sun.media.jai.codec.ImageCodec;
import com.sun.media.jai.codec.ImageDecoder;
import com.sun.media.jai.codec.ImageEncoder;
import com.sun.media.jai.codec.JPEGEncodeParam;
public class Snippet {
@Test
public void testTif2JPG2(){
try{
String filename =  "F:\\Downloads\\CCITT_2.TIF";
String jpegFileName = "F:\\Downloads\\CCITT_2.JPG";
RenderedOp source = JAI.create("fileload", filename);
FileOutputStream stream = null;
stream = new FileOutputStream(jpegFileName );
com.sun.media.jai.codec.JPEGEncodeParam JPEGparam = new
com.sun.media.jai.codec.JPEGEncodeParam();
ImageEncoder encoder =
ImageCodec.createImageEncoder("jpeg",stream,JPEGparam);
encoder.encode(source);
}catch(Exception e){
e.printStackTrace();
}
}
@Test
public void testTif2JPG3(){
try{
String filename =  "F:\\Downloads\\CCITT_2.TIF";
String jpegFileName = "F:\\Downloads\\CCITT_2.JPG";
FileOutputStream stream = null;
stream = new FileOutputStream(jpegFileName );
byte[] b = getBytesFromFile(new File(filename));
InputStream bais = new ByteArrayInputStream(b);
ImageDecoder decoder = ImageCodec.createImageDecoder("tiff", bais, null);
            RenderedImage ri = decoder.decodeAsRenderedImage();
// RenderedOp source = JAI.create("TIFF", bais);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
JPEGEncodeParam JPEGparam = new JPEGEncodeParam();
JPEGparam.setQuality(Float.MIN_VALUE);
ImageEncoder encoder = ImageCodec.createImageEncoder("jpeg",baos,JPEGparam);
encoder.encode(ri);
byte[] byteArray = baos.toByteArray();
FileOutputStream fos = new FileOutputStream(new File(jpegFileName));
fos.write(byteArray);
}catch(Exception e){
e.printStackTrace();
}
}
 @Test
public void testTif2JPG4(){
try{
String filename =  "F:\\Downloads\\CCITT_2.TIF";
String jpegFileName = "F:\\Downloads\\CCITT_2.JPG";
FileOutputStream stream = null;
stream = new FileOutputStream(jpegFileName );
byte[] b = getBytesFromFile(new File(filename));
InputStream bais = new ByteArrayInputStream(b);
            ImageDecoder decoder = ImageCodec.createImageDecoder("tiff", bais, null);
            RenderedImage ri = decoder.decodeAsRenderedImage();
            ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
            ImageIO.write(ri, "JPEG", outputStream);
            stream.write(outputStream.toByteArray());
}catch(Exception e){
e.printStackTrace();
}
}
// Returns the contents of the file in a byte array.
    public static byte[] getBytesFromFile(File file) throws IOException {
        InputStream is = new FileInputStream(file);
    
        // Get the size of the file
        long length = file.length();
    
        // You cannot create an array using a long type.
        // It needs to be an int type.
        // Before converting to an int type, check
        // to ensure that file is not larger than Integer.MAX_VALUE.
        if (length > Integer.MAX_VALUE) {
        throw new IllegalArgumentException("File is too big, can't support.");
        }
    
        // Create the byte array to hold the data
        byte[] bytes = new byte[(int)length];
    
        // Read in the bytes
        int offset = 0;
        int numRead = 0;
        while (offset < bytes.length
               && (numRead=is.read(bytes, offset, bytes.length-offset)) >= 0) {
            offset += numRead;
        }
    
        // Ensure all the bytes have been read in
        if (offset < bytes.length) {
            throw new IOException("Could not completely read file "+file.getName());
        }
    
        // Close the input stream and return bytes
        is.close();
        return bytes;
    }
}
posted @ 2011-05-27 22:39 Daniel 阅读(1930) | 评论 (0)编辑 收藏
仅列出标题  
<2019年10月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

常用链接

留言簿(3)

随笔档案

文章分类

文章档案

相册

搜索

  •  

最新评论