日韩亚洲国产综合高清,亚洲欧美第一成人网站7777,亚洲情综合五月天

Algorithms Chapter2 Answer

Daniel — Mon, 23 Jul 2012 14:12:00 GMT

2.1-1�q�题可以参照书上17自己�l�出�q�程�Q�这里就略去了�?/p>

2.1-2 先给��Z��上insertion-sort的C源代码吧�Q�然后再�l�出按照非升序的代码�Q?/p>

课本�?非降序的)insertion-sort代码�Q?/p>

void insertion_sort(int *A, int n)  
{  
    int i,j;  
    int key; 
 
    for(i = 1; i < n; i++)  
    {  
        j = i - 1;  
        key = A[i]; 
 
        while(j >= 0 && A[j] > key)  
        {  
            A[j+1] = A[j];  
            j = j - 1;  
        } 
 
        A[j+1] = key;  
    }  
}

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

void insertion_sort(int *A, int n)  
{  
    int i,j;  
    int key; 
 
    for(i = 1; i < n; i++)  
    {  
        j = i - 1;  
        key = A[i]; 
 
        while(j >= 0 && A[j] < key)  
        {  
            A[j+1] = A[j];  
            j = j - 1;  
        } 
 
        A[j+1] = key;  
    }  
}

2.1-3�q�题�l�出伪代码：

int find(int *A , int n, int v) 
 
{ 
 
    int  i = 0; 
 
    for( ; i < n; i++) 
 
    { 
 
        if(v == A[i]) 
 
            return i; 
 
    } 
 
  
 
    return NIL; 
 
}

2.1-4直接�l�出代码�Q?/p>

/*在A[]和B[]中，数组的最低位对应与二�q�制的高位，卛_��果一个二�q�制数是011100�Q�用数组表示���是A[] = {0,1,1,1,0,0}*/ 
 
void add(int *A ,int *B, int *C, int n)  
{  
    int i, a, c = 0;  
    int s;  
    for(i = n - 1; i >= 0 ; i--)  
    {  
        s = A[i] + B[i];  
         
        C[i+1] = (s + c) % 2;  
        c = (s + c) / 2;  
    } 
 
    C[0] = c;  
}

Daniel 2012-07-23 22:12 发表评论

Daniel — Mon, 25 Jun 2012 04:05:00 GMT

优化屏障和内存屏�?/span>

优化屏障 (Optimization Barrier)

�~�译器编译源代码�Ӟ��会将源代码进行优化，��源代码的指令进行重排序�Q�以适合于CPU的�ƈ行执行。然而，内核同步必须避免指��o重新排序�Q�优化屏障（Optimization barrier�Q�避免编译器的重排序优化操作�Q�保证编译程序时在优化屏障之前的指��o不会在优化屏障之后执行�?br style="font-family: song, Verdana; font-size: 12px; " />
Linux用宏barrier实现优化屏障�Q�gcc�~�译器的优化屏障宏定义列出如下（在include/linux/compiler-gcc.h中）�Q?nbsp;

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

上述定义中，“__asm__”表示插入了汇�~�语�a��E�序�Q?#8220;__volatile__”表示��L��~�译器对该��D��行优化，��保变量使用了用户定义的�_��地址�Q�而不是装有同一信息的一些别名�?#8220;memory”表示指��o修改了内存单元�?/span>

内存屏障 (Memory Barrier)

软�g可通过��d��屏障强制内存讉K��ơ序。读写屏障像一堵墙�Q�所有在讄��d��屏障之前发�v的内存访问，必须先于在设�|�屏障之后发��L��内存讉K��之前完成�Q�确保内存访问按�E�序的顺序完成�?br style="font-family: song, Verdana; font-size: 12px; " />
��d��屏障通过处理器构架的�Ҏ��指��omfence�Q�内存屏障）、lfence�Q�读屏障�Q�和sfence�Q�写屏障�Q�完成，见《x86-64构架规范》一章。另外，在x86-64处理器中�Q�对��g�q�行操作的汇�~�语�a�指��o�?#8220;串行�?#8221;�Q�也��h��内存屏障的作用，如：对I/O端口�q�行操作的所有指令、带lock前缀的指令以及写控制寄存器、系�l�寄存器或调试寄存器的所有指令（如：cli和sti�Q��?br style="font-family: song, Verdana; font-size: 12px; " />
Linux内核提供的内存屏障API函数说明如表2。内存屏障可用于多处理器和单处理器系�l�，如果仅用于多处理器系�l�，��׃��用smp_xxx函数�Q�在单处理器�pȝ��上，它们什么都不要�?/span>

Daniel 2012-06-25 12:05 发表评论

Java concurrent �ȝ��一

Daniel — Mon, 25 Jun 2012 01:37:00 GMT

摘要: Preface最�q�看了一�?lt;Java Concurrency In Practice> �q�本书， ��M��来说�q�是一本不错的书，不过�_�度不够�l�，是从大的角度�Q?例如�Q?设计整体��目上如何考虑�q�发的多斚w��因素�Q�不�q��M��上来说还是一本不错的书，�l�合部分�|�络上的资料�Q��ȝ��一下自��q��知识�Q�免的忘了。下面是一些最基本的知识，不想再写了，反正�|�上多的是，挑了一��还不错的�{�q�来�Q�大家要支持别�h的成�?.. 阅读全文

Daniel 2012-06-25 09:37 发表评论

java nio��结

Daniel — Wed, 25 Apr 2012 07:34:00 GMT

java nio��结

�Ҏ��|�上的资料做些整�?/p>

Java NIO API详解

http://www.tkk7.com/19851985lili/articles/93524.html

�q�篇文章对nio的api讲解比较全，可以帮助在宏观上把握nio�?/p>

BIO 方式使得整个处理�q�程和连接是�l�定的，只要�q�接建立�Q�无论客��L��是否有消息发送，都要�q�行�{�待处理�Q�一定程度上��费了服务器端的��g资源�Q�因此就有了NIO 方式。Java 对于 NIO 方式的支持是通过 Channel�?Selector 方式来实玎ͼ�采用的方法�ؓ�?Channel注册感兴��的事�g�Q�然后通过 Selector 来获取到发生了事件的 key�Q�如发生了相应的事�g�Q�则�q�行相应的处理，否则则不做�Q何处理，是典型的Reactor 模式�Q�按照这��L��方式�Q�就不用�?BIO 方式一��P��即��在没有消息的情况下也需要占据一个线�E�来��d��d��消息�Q�从而提升服务器的��用效率，为实�?TCP/IP+NIO 方式的系�l�间通讯�Q?Java 提供�?SocketChannel�?ServerSocketChannel两个关键的类�Q�网�l?IO 的操作则改�ؓ通过ByteBuffer 来实玎ͼ�具体的基�?java实现TCP/IP+NIO 方式的通讯的方法如下所�C��?/p>

服务器端�Q?/p>

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;
    /*定义�~�冲区大��?/span>*/
    private static int block = 4096;
    /*接收�~�冲�?/span>*/
    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();
        //服务器配�|��ؓ非阻�?/span>
        serverSocketChannel.configureBlocking(false);
        //���索与此服务器套接字通道兌���的套接字
        ServerSocket serverSocket = serverSocketChannel.socket();
        //�q�行服务的绑�?/span>
        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 �Q�当其中有注册的 IO 操作可以�q�行�Ӟ��该函数返回，�q�将对应�?SelectionKey 加入 selected-key set
            selector.select();
            //Selected-key set 代表了所有通过 select() �Ҏ��监测到可以进�?IO 操作�?channel �Q�这个集合可以通过 selectedKeys() 拿到
            Set selectionKeys = selector.selectedKeys();
            Iterator iterator = selectionKeys.iterator();
            while(iterator.hasNext()){
                SelectionKey selectionKey = iterator.next();
                handleKey(selectionKey);
                iterator.remove();
            }
        }
        
    }
    //处理��h��
    public void handleKey(SelectionKey selectionKey) throws IOException{
        //接受��h��
        ServerSocketChannel serverSocketChannel = null;
        SocketChannel socketChannel = null;
        String receiveText;
        String sendText;
        int count;
        //���试此键的通道是否准备好接受新的套接字�q�接
        if(selectionKey.isAcceptable()){
            //�q�回创徏此键的通道
            serverSocketChannel = (ServerSocketChannel)selectionKey.channel();
            //接受客户端徏立连接的��h���Q��ƈ�q�回 SocketChannel 对象
            socketChannel = serverSocketChannel.accept();
            //配置为非��d��
            socketChannel.configureBlocking(false);
            //注册到selector
            socketChannel.register(selector, SelectionKey.OP_READ);
        }else if(selectionKey.isReadable()){
            //�q�回��Z��创徏此键的通道
            socketChannel = (SocketChannel)selectionKey.channel();
            //���缓冲区清空�Q�以备下�ơ读�?/span>
            receiveBuffer.clear();
            //���发送来的数据读取到�~�冲�?/span>
            
            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();  
            // �q�回��Z��创徏此键的通道�? 
            socketChannel = (SocketChannel) selectionKey.channel();  
            sendText="message from server--" + flag++;  
            //向缓冲区中输入数�? 
            sendBuffer.put(sendText.getBytes());  
             //���缓冲区各标志复�?因�ؓ向里面put了数据标志被改变要想从中��d��数据发向服务�?���p��复位  
            sendBuffer.flip();  
            //输出到通道  
            socketChannel.write(sendBuffer);  
            System.out.println("服务器端向客��L��发送数�?-�Q?+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();
    }

}

客户�?/p>

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;  
    /*�~�冲区大��?/span>*/  
    private static int BLOCK = 4096;  
    /*接受数据�~�冲�?/span>*/  
    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();  
        // 讄���为非��d��方式  
        clientChannel.configureBlocking(false);  
        // 打开选择�? 
        Selector selector = Selector.open();  
        // 注册�q�接服务端socket动作  
        clientChannel.register(selector, SelectionKey.OP_CONNECT);  
        // �q�接  
        clientChannel.connect(SERVER_ADDRESS);  
    
        SocketChannel socketChannel;
        Set selectionKeys;    
        String receiveText;  
        String sendText;  
        int count=0;  
  
        while (true) {  
            //选择一�l�键�Q�其相应的通道已�ؓ I/O 操作准备���q�A�? 
            //监控所有注册的 channel �Q�当其中有注册的 IO 操作可以�q�行�Ӟ��该函数返回，�q�将对应�?SelectionKey 加入 selected-key set 
            selector.select();  
            //�q�回此选择器的已选择键集�? 
            selectionKeys = selector.selectedKeys();  
            //System.out.println(selectionKeys.size());  
            for(SelectionKey selectionKey:selectionKeys){ 
                //判断是否为徏立连接的事�g
                if (selectionKey.isConnectable()) {  
                    System.out.println("client connect");  
                    socketChannel = (SocketChannel) selectionKey.channel();  //
                    // 判断此通道上是否正在进行连接操作�? 
                    // 完成套接字通道的连接过�E��? 
                    if (socketChannel.isConnectionPending()) { 
                        //完成�q�接的徏立（TCP三次握手�Q?/span>
                        socketChannel.finishConnect();  
                        System.out.println("完成�q�接!");  
                        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();  
                    //���缓冲区清空以备下次��d��  
                    receiveBuffer.clear();  
                    //��d��服务器发送来的数据到�~�冲��Z��  
                    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了数据标志被改变要想从中��d��数据发向服务�?���p��复位  
                    sendBuffer.flip();  
                    socketChannel.write(sendBuffer);  
                    System.out.println("客户端向服务器端发送数�?-�Q?+sendText);  
                    socketChannel.register(selector, SelectionKey.OP_READ);  
                }  
            }  
            selectionKeys.clear();  
        }  
    }  
}

��结�Q�之前对Selector注册事�g和SocketChannel有点��困惑。SocketChannel��像一�Ҏ��，当监听到写事件时�Q�就往��道写数据；当监听到��M��件时�Q�就从管道读出数据�?/p>

Daniel 2012-04-25 15:34 发表评论

数据库设计准则（�W�一、第二、第三范式说明）

Daniel — Wed, 21 Dec 2011 08:46:00 GMT

数据库设计准则（�W�一、第二、第三范式说明）

I、关�p�L��据库设计范式介绍

1.1 �W�一范式�Q?NF�Q�无重复的列

所谓第一范式�Q?NF�Q�是指数据库表的每一列都是不可分割的基本数据��，同一列中不能有多个��|��卛_��体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，��可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间�ؓ一对多关系。在�W�一范式�Q?NF�Q�中表的每一行只包含一个实例的信息。简而言之，�W�一范式��是无重复的列�?/div>

说明�Q�在��M��一个关�p�L��据库中，�W�一范式�Q?NF�Q�是对关�p�L��式的基本要求�Q�不满��W�一范式�Q?NF�Q�的数据库就不是关系数据库�?nbsp;

1.2 �W�二范式�Q?NF�Q�属性完全依赖于主键[消除部分子函��C��赖]

�W�二范式�Q?NF�Q�是在第一范式�Q?NF�Q�的基础上徏立�v来的�Q�即满��W�二范式�Q?NF�Q�必��d��满��W�一范式�Q?NF�Q�。第二范式（2NF�Q�要求数据库表中的每个实例或行必��d��以被惟一地区分。�ؓ实现区分通常需要�ؓ表加上一个列�Q�以存储各个实例的惟一标识。例如员工信息表中加上了员工�~�号�Q�emp_id�Q�列�Q�因为每个员工的员工�~�号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称��Z��关键字或主键、主码�?nbsp;
�W�二范式�Q?NF�Q�要求实体的属性完全依赖于��d��键字。所谓完全依赖是指不能存在仅依赖��d��键字一部分的属性，如果存在�Q�那么这个属性和��d��键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关�p�R��ؓ实现区分通常需要�ؓ表加上一个列�Q�以存储各个实例的惟一标识。简而言之，�W�二范式��是属性完全依赖于主键�?nbsp;

1.3 �W�三范式�Q?NF�Q�属性不依赖于其它非��d��性[消除传递依赖]

满��W�三范式�Q?NF�Q�必��d��满��W�二范式�Q?NF�Q�。简而言之，�W�三范式�Q?NF�Q�要求一个数据库表中不包含已在其它表中已包含的非��d��键字信息。例如，存在一个部门信息表�Q�其中每个部门有部门�~�号�Q�dept_id�Q�、部门名�U�、部门简介等信息。那么在的员工信息表中列出部门编号后��׃��能再��部门名�U�、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF�Q�也应该构徏它，否则��׃��有大量的数据冗余。简而言之，�W�三范式��是属性不依赖于其它非��d��性�?nbsp;

II、范式应用实例剖�?/h3>

下面以一个学校的学生�pȝ��Z��分析说明�Q�这几个范式的应用。首先第一范式�Q?NF�Q�：数据库表中的字段都是单一属性的�Q�不可再分。这个单一属性由基本�c�d��构成�Q�包括整型、实数、字�W�型、逻辑型、日期型�{�。在当前的�Q何关�p�L��据库��理�pȝ��Q�DBMS�Q�中�Q�傻瓜也不可能做��Z��W�合�W�一范式的数据库�Q�因��些DBMS不允�怽�把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的�?nbsp;
首先我们��定一下要设计的内容包括那些。学受��学生姓名、年龄、性别、课�E�、课�E�学分、系别、学�U�成�l�，�p�d��地址、系办电话等信息。�ؓ了简单我们暂时只考虑�q�些字段信息。我们对于这些信息，说关心的问题有如下几个方面�?nbsp;
学生有那些基本信�?/li>
学生选了那些课，成�W是什�?/li>
每个评��学分是多��?/li>
学生属于那个�p�，�pȝ��基本信息是什么�?/li>

2.1 �W�二范式�Q?NF�Q�实例分�?/h4>

首先我们考虑�Q�把所有这些信息放��C��个表�?学号�Q�学生姓名、年龄、性别、课�E�、课�E�学分、系别、学�U�成�l�，�p�d��地址、系办电�?下面存在如下的依赖关�p�R�?nbsp;
�Q�学��P��→ (姓名, �q�龄�Q�性别�Q�系别，�p�d��地址、系办电�?
(评��名称) → (学分)
�Q�学��P��评��Q?#8594; (学科成�W)

2.1.1 问题分析

因此不满��第二范式的要求�Q�会产生如下问题

数据冗余�Q?同一门课�E�由n个学生选修�Q?学分"��重复n-1�ơ；同一个学生选修了m门课�E�，姓名和年龄就重复了m-1�ơ�?nbsp;

更新异常�Q?nbsp;
1)若调整了某门评��的学分，数据表中所有行�?学分"值都要更斎ͼ�否则会出现同一门课�E�学分不同的情况�?nbsp;
2)假设要开设一门新的课�E�，暂时�q�没有�h选修。这��P��׃��q�没�?学号"关键字，评��名称和学分也无法记录入数据库�?nbsp;

删除异常 �Q?假设一批学生已�l�完成课�E�的选修�Q�这些选修记录��应该从数据库表中删除。但是，与此同时�Q�课�E�名�U�和学分信息也被删除了。很昄��Q�这也会��D��插入异常�?/div>

2.1.2 解决�Ҏ��

把选课关系表SelectCourse改�ؓ如下三个表：

学生�Q�Student(学号�Q�姓�? �q�龄�Q�性别�Q�系别，�p�d��地址、系办电�?�Q?/li>
评��Q�Course(评��名称, 学分)�Q?/li>
选课关系�Q�SelectCourse(学号, 评��名称, 成�W)�?/li>

2.2 �W�三范式�Q?NF�Q�实例分�?/h4>

接着看上面的学生表Student(学号�Q�姓�? �q�龄�Q�性别�Q�系别，�p�d��地址、系办电�?�Q�关键字为单一关键�?学号"�Q�因为存在如下决定关�p�：

�Q�学��P��→ (姓名, �q�龄�Q�性别�Q�系别，�p�d��地址、系办电�?
但是�q�存在下面的军_��关系
(学号) → (所在学�?→(学院地点, 学院电话)
卛_��在非关键字段"学院地点"�?学院电话"对关键字�D?学号"的传递函��C��赖�?nbsp;
它也会存在数据冗余、更新异常、插入异常和删除异常的情��c�?(數據的更斎ͼ�刪除異常這里��׃��分析了，可以參照2.1.1進行分析)

�Ҏ��W�三范式把学生关�p�表分�ؓ如下两个表就可以滿��W�三范式了：

学生�Q?学号, 姓名, �q�龄, 性别�Q�系�?�Q?nbsp;
�p�d��Q?�p�d��, �p�d��地址、系办电�?�?nbsp;

�ȝ��

上面的数据库表就是符合I,II,III范式的，消除了数据冗余、更新异常、插入异常和删除异常�?nbsp;

Daniel 2011-12-21 16:46 发表评论

Daniel — Thu, 01 Dec 2011 15:03:00 GMT

光标位置

点击 TextArea 实现光标定位 </div><div>HIGHHEEL</div><div>sfsfsfs</div><div>s1123</div><div>432434</div><div>asf</div><div>fsa</div><div>sf</div><div>3232 光标位置�Q?lt;input type="text" value="0" id="pnum" size="8"> -- 选择查找字符 �Q?lt;input type="text" value="" id="cbox" size="8">	boundingHeight:
	boundingWidth:
	boundingTop:
	boundingLeft:
	offsetLeft:
	offsetTop:
	text:

Daniel 2011-12-01 23:03 发表评论

Daniel — Wed, 31 Aug 2011 05:25:00 GMT

14.1 Web Services和面向服务的软�g架构�Q�Service Oriented Architecture�Q�简�U�SOA�Q�概�q�ͼ�

在最新Java开发世界里�Q�我们经�怼�遇到�q�样一个名词：Web Services�Q�Web服务�Q�。同时还会发玎ͼ�与这个名词同时出现的多是各大��L��技术供应商�Q�各大技术供应商无一不在��x��q�一领域的发展。从Microsoft�?NET架构�Q�到SUN的SUN ONE�Q�以及IBM的Web Services�Q�都体现了这些重量��的技术提供者对Web Services的推崇与重视�?/p>

电子商务的发展促�q�了Web Services的发展。Web服务可以使公叔R��低进行电子商务的成本�Q�更快地部��v解决�Ҏ��以及开拓更多的新机遇。Web服务使应用程序的集成比以前更快、更�Ҏ��而且更便宜。它更注重服务语义而不那么注重�|�络协议语义的消息，从而实��C��业务功能的松散耦合。这些特性对于在企业之间和企业内部通过web�q�接业务功能是非常理想的。它提供了一致化�Q�Uniform�Q�的�~�程模型�Q�从而在企业内外都可以利用通用的基��设施�q�以一�U�通用的方法进行应用程序集成�?/p>

要理解Web Services, 首先需要认识面向服务的软�g架构�Q�Service Oriented Architecture�Q�简�U�SOA�Q�，Web Services是SOA架构�pȝ��的一个实例�?/p>

14.1.1面向服务的��Y件架构（SOA�Q?/p>

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

在面向服务的架构中包含一些基本的概念�Q�透过�q�些基本概念可以�q�一步了解面向服务的架构�?/p>

(1) 服务的概�?/p>

在SOA中的服务是指能够处理一些�Q务过�E�的动作的抽象概念，�q�些服务可以被描�q�ͼ�可以被发玎ͼ�可以由服务代理负责向��h��者提供服务�ƈ�l�出�l�果。代理是指请求或者提供服务的人所使用的��Y件工��P��人通过代理�q�行交互操作�?/p>

(2) 消息的概�?/p>

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

(3) 服务的描�q�和发现

众多的服务组成一个开攄��l�，除了需要提供信息交互方式以外，�q�需要提供相互了解的机制�Q�这��需要提供描�q�和发现的方式。代理可以通过服务的描�q�来了解一个服务的内容�Q�包括��用这个服务的技术信息、访问这个服务的地址信息�{�内宏V��当新的服务被投入到�pȝ��之中后，它需要被注册�Q��ƈ且要能够被发玎ͼ�使它可以被利用�v来�?/p>

2.��Z��么需要面向服务的软�g

�׃��软�g需求的扩大�Q��Y件系�l�变得越来越复杂。面对复杂的�pȝ��资源�Q�我们需要一�U�更加合理的方式��不同类型、不同位�|�的子系�l�有力地�l�合��h��Q�这�U�整合�ƈ不是��它们之间绑定得更加紧密�Q�而是利用更加松散的方式来建立�q�个�pȝ��?/p>

SOA通过松散的方式将分布式的软�g模块�l�合��h��Q�与旧有�pȝ��集成相比有着明显的优�ѝ��对于服务的使用者来��_��可以��单地通过服务的描�q�来获取服务�Q�系�l�各部分之间不必��Z��某一部分的升�U�而改变，在服务的�q�程中不同的软�g模块可以充当不同的角�Ԍ��从而构成整个系�l�的工作体系�?/p>

在SOA当中�Q�一个服务代表的是一个由服务提供者向服务��h��者发布的一些处理过�E�，�q�个�q�程在被调用之后�Q�获得服务请求者所需要的一个结果。在�q�个�q�程中，服务��h��者可以向��M��能够提供此项服务的服务提供者来��h��服务�Q�服务实现的�q�程对于服务��h��者来说是透明的�?/p>

随着�pȝ��分布式和多种�l�构复合�E�度的提高，SOA的巨大优势将�q�一步被挖掘�?/p>

(1) 建立松散耦合的系�l?/p>

松散耦合�pȝ��的优点已�l�被业内充分地认可，SOA作�ؓ一�U�分布式的系�l�，它实��C��一�U�服务和描述�{�概�늛��l�合的架构�?/p>

SOA中的服务在SOA架构中被标准的描�q�语�a�所描述�Q��ƈ通过与某�U�传输协议的�l�定来实现相互之间的交互。这�U�基于服务的架构使整个系�l�成��Z��个松散耦合的结构，利用与通信协议的绑定将分布式系�l�中的所有部分连接�v来，利用语义和服务的描述�Q�在代理之间�q�行交互�?/p>

(2) 提高软�g的重用�?/p>

面向服务的架构还提高了对软�g的重用性。与�l��g方式相比�Q�SOA�pȝ��中的单个服务的改变不会对其他部分造成严重的媄响，同时利用服务的描�q�C��同一服务可以充分地被其他�pȝ��所调用�Q�各个系�l�之间�Ş成了高度的重用性�?/p>

现在正在被广泛��用的一些服务，正在不断地被各个�pȝ��所重用�Q�重用的条�g十分��单，只要了解服务的描�q�ͼ�或者可以访问到服务的描�q�地址卛_��。与�l��g重用相比�Q�服务的重用�q�具有与实现语言无关的特点，重用服务的客��L��E�序不需要��用与服务实现部分同样的开发语�a��Q�一切交互的�q�程都是利用与实现无关的方式�q�行的�?/p>

(3) 提供按需服务的代�?/p>

面向服务的架构也使得�pȝ��的实现虚拟化�Q�在SOA架构中的��h��和提供之间交互或�怺�代理的过�E�中�Q�可计算的代码资源分布在松散�l�构中的各个部分上，当请求发生时才被调用和服务，所有计��过�E�都是按照请求者的需求进行的。服务的对象分�ؓ有状态和无状态两�U�方式提供服务，按照需求提供服务，也可以利用缓冲机制优化系�l�的�pȝ��?/p>

��M��Q�SOA使代码的开发变得更有服务的目的性，使开发更加有效和合理�?/p>

14.1.2 SOA�?Web 2.0

另外�Q�我们补充一下SOA与目前同��L��门的Web 2.0的关�p�R�?/p>

实际上Web 2.0 和SOA的概念在很大�E�度上是相同的，只是被粉饰成��Y件的不同部分�Q�如果的��存在不同的话）�Q�也��是说SOA和Web 2.0有很多重叠的东西�Q�例如都是基于调用（invoke�Q�的服务�Q�都能存在于�|�络的�Q何位�|�等�{��?/p>

SOA和Web 2.0的共性远大于它们之间的区别，而且Web 2.0在推�q�SOA斚w��起到了一定作用。到现在为止�Q�SOA和Web 2.0拥有不同的支持�? SOA更多涉及企业�l�构和商务开拓，而Web 2.0更关注用戗��这�U�差别随着更多企业接纳Web 2.0而在变化�Q�但是这两项技术有着不同的重�? Web 2.0告诉我们数据是��Y件应用中最重要的部分，而SOA告诉我们服务才是中心。SOA中传输数据的服务也非帔R��要，但是传统SOA更关注IT�pȝ��的接合处而不是那些能使接合处更具价值的东西。也��是��_��SOA也许是通畅的管道，但�ƈ不是�pȝ��中通过的水的�h倹{��许多行业领��D��说企业同时需要SOA�c�L��法的�l�构和Web 2.0�Ҏ��的创业能力�?/p>

SOA和Web 2.0之间有许多共有的要素�Q?/p>

l 软�g重组

l ��理

l 软�g��是服务

l 应用��是�q�_��

l 无意识的使用

l 开�?/p>

l AJAX

l 互操作�?/p>

l 货币�?/p>

l 安全

l �|�络导向架构

特别要说的是�Q�最后一条网�l�导向架构或者Web Oriented Architecture�Q�WOA�Q�是关键的内容，最�l�有可能会将SOA和Web 2.0合�ؓ一体�?/p>

了解了SOA后，我们来介�l�什么是Web Services。Web Services是SOA架构�pȝ��的一个实例。从技术角度来�Ԍ��Web Services是一�U�新的技术架构、新的��Y件应用环境。它的系�l�架构和实现技术完全��承已有的技术，可以认�ؓWeb Services是Internet的一�U��g伸，是现有的Internet面向更好的互操作能力的一个�g伸�?/p>

14.2�Q?Web Services的概�?/p>

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

对于Web Services�Q�很多�h会与Web Service混�ؓ一谈，认�ؓ二者指的是同一个事物。其实不�Ӟ��前者指的是用于建构Web Service的技术框�Ӟ��后者指的是使用Web Services技术而创建的应用实例。Web Services是描�q�C��一些操作的接口�Q�基于标准化的XML消息传输机制�Q�我们可以通过�|�络讉K��q�些操作。Web Services使用规范的、基于XML的WSDL(Web Services Description Language)语言描述的，�q�称为Web Services的服务描�q�。这一描述囊括了与服务交互所需要的全部�l�节�Q�包括消息格式（详细描述操作的输入输出消息格式）、传输协议和位置。该接口隐藏了服务实现的�l�节�Q�允讔R��过独立与服务实现、独立于软硬件��^台、独立于�~�写服务所用的�~�程语言的方式��用该服务。这使得��Z��Web Services的应用程序具有松散耦合、面向组件和跨技术实现的特点。Web Services都��行一定的特定业务或�Q务，可以实现同其他Web Services一��L��于实现复杂的商业交易�?/p>

从外部��用者角度而言�Q�Web Services是一�U�部�|�在Web上的对象和组�Ӟ��具备以下特征�Q?/p>

.完好的封装性：

Web服务既然是一�U�部�|�在web上的对象�Q�自然具备对象的良好��装性，对于使用者而言�Q�他能且仅能看到该对象提供的功能列表�?/p>

.松散耦合

�q�一特征也是源于对象�Q�组件技术，当一个Web服务的实现发生变更的时候，调用者是不会感到�q�一点的�Q�对于调用者来��_��只要Web服务的调用界面不变，Web服务实现的�Q何变更对他们来说都是透明的，甚至是当Web服务的实现��^��C��J2EE�q�移��C��Q�NET或者是相反的迁�U�L��E�，用户都可以对此一无所知。对于松散耦合而言�Q�尤其是在Internet环境下的Web服务而言�Q�需要有一�U�适合Internet环境的消息交换协议，而XML�Q�SOAP正是目前最为适合的消息交换协议�?/p>

.使用协议的规范�?/p>

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

.高度可集成能�?/p>

�׃��Web服务采取��单的、易理解的标准，Web协议作�ؓ�l��g界面描述和协同描�q�规范，完全屏蔽了不同��Y件��^台的差异�Q�无论是CORBA、DCOM�q�是EJB�Q�都可以通过�q�一�U�标准的协议�q�行互操作，实现了在当前环境下最高的可集成性�?/p>

14.2.1 Web Services的核心技�?/p>

Web Services 是一�U�基于组件的软�g�q�_��,是面向服务的Internet 应用。Web Services 是应用于Internet �?而不是限于局域网或试验环境，�q�就要求Web Services 框架必须适用于现有的Internet 软�g和硬件环�?��x��务的提供者所提供的服务必��d��有跨�q�_��、跨语言的特性。其��?Web Services 所提供的服务不但是面向�?而且需服务于其它应用系�l�。现有的Web�|�站也可以认为是面向服务�?但这�U�服务仅仅可以提供给��Z��?只有人类才可以读懂浏览器下蝲的页�? 。而新一代的Web Services 所提供的服务应能被机器所��L��,例如其它应用�E�序及移动设备中的��Y件系�l�。这�?我们可以看出,Web Services 的发展方向实际上是构造一个基于现有Internet 技术之上的分布计算�pȝ��?/p>

Web Services 框架的核心技术包括SOAP(Simple Object Access Protocol,��单对象访问协�? ,WSDL(Web Services Description Lanuage,Web服务描述语言) 和UDDI�Q�Universal Description�Q�Discovery and Integration�Q�通用描述�Q�发玎ͼ�集成) ,它们都是以标准的XML 文档的�Ş式表�q�的�?/p>

XML是Web Services技术体�p�M��最基础的标准，Web Services的一切都建立在XML技术的基础之上�Q�包括Web Services的消息、描�q�和服务实现的各个环节。利用XML�Q�Web Services的服务提供者和��h��者可以利用不同的开发语�a�来协作完成服务调用的�q�程。XML是Web Services技术体�p�M��的很多标准得以徏立的基础�Q�在Web Services�pȝ��中无处不在�?/p>

SOAP 是Web services 的通信协议。SOAP是一�U�简单的、轻量��的基于XML 的机�Ӟ��用于在网�l�应用程序之间进行结构化数据交换。SOAP包括三部�?一个定义描�q�消息内容的框架的信��，一�l�表�C�应用程序定义的数据�c�d��实例的编码规则，以及表示�q�程�q�程调用和响应的�U�定�?/p>

WSDL表示WEB服务说明语言。WSDL文�g是一个XML 文档�Q�用于说明一�l�SOAP消息以及如何交换�q�些消息�Q�通过WSDL可以描述一个服务的信息。这些信息��不了解这个服务的开发者可以徏立调用这个服务的客户端代码，或者通过WSDL帮助生成实现它的基本代码�l�构。WSDL在Web Services的实际开发过�E�中��L��重要的作用�?/p>

　　Web Services是基于互联网的应用程序模块，用于在互联网上运行，它采用开攄��UDDI�Q�Universal Description�Q�Discovery and Integration�Q�通用描述�Q�发玎ͼ�集成�Q�标准。UDDI标准先由IBM、微软、Ariba制订�Q�到目前为止获得�?30多家公司的支持。UDDI 提供一�U�发布和查找服务描述的方法。UDDI 数据实体提供对定义业务和服务信息的支持。WSDL 中定义的服务描述信息是UDDI注册中心信息的补充。UDDI提供了一个开放，�q�_��独立的技术框�Ӟ��来��企业之间能在互联�|�上扑ֈ��Ҏ��的服务，定义它们在互联网上的交互�z�d��Q�以及这些信息的�׃�n方式�?/p>

Web 服务体系�l�构��Z��三种角色�Q�服务提供者、服务注册中心和服务��h��者）之间的交互�?/p>

服务提供者。从企业的角度看�Q�这是服务的所有者。从体系�l�构的角度看�Q�这是托��访问服务的�q�_��?nbsp;
服务��h��者（用户�Q�。从企业的角度看�Q�这是要求满��特定功能的企业。从体系�l�构的角度看�Q�这是寻扑�ƈ调用服务�Q�或启动与服务的交互的应用程序。服务请求者角色可以由��览器来担当�Q�由人或无用��L��面的�E�序�Q�例如，另外一�?Web 服务�Q�来控制它�?nbsp;
服务注册中心。这是可搜烦的服务描�q�注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期��_��服务��h��者查找服务�ƈ获得服务的绑定信息（在服务描�q�C��Q�。对于静态绑定的服务��h��者，服务注册中心是体�pȝ��构中的可选角�Ԍ��因�ؓ服务提供者可以把描述直接发送给服务��h��者。同��P��服务��h��者可以从服务注册中心以外的其它来源得到服务描�q�ͼ�例如本地文�g、FTP 站点、Web 站点、广告和服务发现�Q�Advertisement and Discovery of Services�Q�ADS�Q�或发现 Web 服务�Q�Discovery of Web Services�Q�DISCO�Q��?nbsp;

　　Web Services 的体�p�L��构如�? 所�C?br />

Web Services 服务提供斚w��过WSDL(Web Services Description Language) 描述所提供的服�?�q�将�q�一描述告知Web Services 注册服务器。注册服务器依据WSDL 的描�q?依照UDDI (Universal Description Discovery and Integration) 的协定更新服务目录�ƈ在Internet 上发布。用户在使用Web Services 前先向注册服务器发出��h��,获得Web Services 提供者的地址和服务接口信�?之后使用SOAP 协议(Simple Object Access Protocol) 与Web Services 提供者徏立连�?�q�行通信。Web Services 的技术主要徏立在XML 的规范之�?�q�保证了�q�一体系�l�构的��^台无��x��、语�a�无关性和人机交互性能�?/p>

14.2.2 Web 服务开发生命周�?/p>

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

Web 服务开发生命周期有以下四个阶段�Q?/p>

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

2. 部��v
部��v阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义�Q�以及把 Web 服务的可执行文�g部��v到执行环境（典型情况下，Web 应用�E�序服务器）中�?/p>

3. �q�行
在运行阶�D�，可以调用 Web 服务。在此，Web 服务完成部��v�Q�成为可操作的服务。服务请求者可以进行查扑֒��l�定操作�?/p>

4. ��理
��理阶段包括持箋的管理和�l�营 Web 服务应用�E�序。安全性、可用性、性能、服务质量和业务��程问题都必��被解决�?/p>

接下来我们具体展开Web Services原理�?/p>

14.3�Q�Web Services原理

首先�Q�我们将看看 Web 服务的一个概忉|��协议栈以及�q�个协议栈的�l�节。然后我们将讨论选择�|�络协议的标准。我们还��回��一下基本的��Z�� XML 的消息传递分布式计算。我们将用服务描�q�扩展基本的 XML 消息传递，而服务描�q�是�Ҏ��它的协议栈来解释的。接下来�Q�我们将讨论服务描述�?Web 服务体系�l�构中的角色�Q�说明支持静态和动�?Web 服务应用�E�序的服务发布技术的范围。我们还��围�l�服务发布讨论服务发现的角色。最后，我们��描�q�基�?Web 服务体系�l�构的扩展，电子商务需要这些扩展才能��?Web 服务�?/p>

14.3.1 Web 服务协议�?/p>

要以一�U�可交互操作的方式执行发布、发现和�l�定�q�三个操作，必须有一个包含每一层标准的 Web 服务协议栈。图 2 展示了一个概忉|�?Web 服务协议栈。上面的几层建立在下面几层提供的功能之上。垂直的条表�C�在协议栈中每一层必��L��的需求�?/p>

�?. Web 服务概念性协议栈

Web 服务协议栈的基础是网�l�层。Web 服务要被服务��h��者调用，��必��L��可以通过�|�络讉K��的。互联网上可以公用的 Web 服务使用普遍适用的网�l�协议。HTTP 凭借其普遍性，成�ؓ了互联网可用�?Web 服务真正的标准网�l�协议。Web 服务�q�可以支持其它互联网协议�Q�包�?SMTP �?FTP。内部网域可以��用可靠消息传递和调用基础�l�构�Q�如 MQSeries �?CORBA �{�等�?/p>

下一层是��Z�� XML 的消息传递，它表�C�Z��?XML 作�ؓ消息传递协议的基础。选择 SOAP 作�ؓ XML 消息传递协议有很多原因�Q?/p>

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

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

协议栈的最下面三层��立了保证一致性和互操作性的技术，而它们上面的两层�Q�即服务发布和服务发玎ͼ�可以用多�U�解��x��案来实现�?/p>

��M��能够让服务请求者��?WSDL 文档的操作，不管它处于服务请求者生命周期的哪个阶段�Q�都�W�合服务发布的标准。该层中最��单、最静态的实例��是服务提供者直接向服务��h��者发�?WSDL 文档。这被称为直接发布。电子邮件是直接发布的蝲体之一。直接发布对静态绑定的应用�E�序来说很有用。另外，服务提供者还可以��描�q�服务的文档发布��C��机本�?WSDL 注册中心、专�?UDDI 注册中心�?UDDI �q�营商节炏V�?/p>

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

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

�|�络�?/p>

Web 服务协议栈的最底层是网�l�层。该层可表示��L��多个�|�络协议�Q�HTTP、FTP、SMTP、消息排队（Message Queuing�Q�、互联网 ORB 间协议（Internet Inter ORB Protocol�Q�IIOP�Q�上的远�E�方法调用（Remote Method Invocation�Q�RMI�Q�、电子邮件等�{�。在��M��l�定的情况下使用的网�l�协议都依赖于应用程序需求�?/p>

对于可以从互联网讉K��?Web 服务�Q��h们选择�|�络技术的时侯通常会們֐�于选择普遍部��v的协议，�?HTTP。对于内部网中提供和使用�?Web 服务�Q��用另外的�|�络技术也会被认同。我们可以根据其它需求选择�|�络技术，包括安全性、可用性、性能以及可靠性。这使得 Web 服务可以利用已有的功能更高��的联�|�基��l�构和面向消息的中间�Ӟ��?MQSeries。在有多�U�网�l�基��l�构的企业中�Q�HTTP 可以用来在这些基��l�构之间搭徏桥梁�?/p>

Web 服务的好处之一在于�Q�它��Z��用内部网和公用互联网服务的开发和使用提供了统一的编�E�模型。所以，�|�络技术的选择�Ҏ��务开发者来说是透明的�?/p>

��Z�� XML 消息传递的分布式计��?/p>

Web 服务体系�l�构最基础的支柱是 XML 消息传递。当�?XML 消息传递的行业标准�?SOAP。IBM、Microsoft 以及其它企业都向 W3C �� SOAP 作�ؓ XML 协议工作�l�（XML Protocol Working Group�Q�的基础。XML 协议��代�?SOAP 作�ؓ行业标准 XML 消息传递协议的位置。当 W3C 发布 XML 协议的草案标准时�Q�Web 服务体系�l�构��׃��?SOAP �q�移�?XML 协议�?/p>

SOAP 是一�U�简单的、轻量��的基�?XML 的机�Ӟ��用于在网�l�应用程序之间进行结构化数据交换。SOAP 包括三部分：一个定义描�q�消息内容的框架的信��、一�l�表�C�应用程序定义的数据�c�d��实例的编码规则，以及表示�q�程�q�程调用�Q�remote procedure calls�Q�RPC�Q�和响应的约定。SOAP 可以和各�U�网�l�协议（�?HTTP、SMTP、FTP �?IIOP �?MQ 上的 RMI�Q�相�l�合使用�Q�或者用�q�些协议重新��装后��用�?/p>

虽然理解�q�个基础很重要，但多�?Web 服务开发者不必直接处理这个基��l�构。大多数 Web 服务都会使用�?WSDL 生成的经�q�优化的特定于编�E�语�a�的绑定。当服务提供者和服务��h��者都在类似的环境中执行时�Q�这�U�优化可能尤为重要�?/p>

�?4 展示�?XML 消息传递（�?SOAP�Q�和�|�络协议如何�l�成Web 服务体系�l�构的基��?/p>

�?4. 使用 SOAP �?XML 消息传�?/p>

�|�络节点在基�?XML 消息传递的分布式计��中扮演提供者和��h��者角色的基本要求是构建、解�?SOAP 消息的能力（或两者兼而有之）�Q�以及在�|�络上通信的能力（接收、发送消息，或两者）�?/p>

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

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

那么�Q�服务请求者如何知道请求消息应该��用什么格式呢�Q�这个问题在下面会得到回�{��?/p>

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

服务提供者是通过服务描述��所有用于调�?Web 服务的规范传送给服务��h��者的。要实现 Web 服务体系�l�构的松散耦合�Q��ƈ减少服务提供者和服务��h��者之间所需的共识的�E�度和定制编�E�与集成的程度，服务描述��是关键。例如，不管是请求者还是提供者，都不必了解对方的底层�q�_��、编�E�语�a�或分布式对象模型�Q�如果有的话�Q�。服务描�q�C��底层 SOAP 基础�l�构相结合，��以��装服务��h��者的应用�E�序和服务提供者的 Web 服务之间的这个细节�?/p>

基本服务描述

Web 服务体系�l�构使用 WSDL 作�ؓ基本服务描述。WSDL 已经被提交到 W3C 作�ؓ标准。WSDL 是一�U?XML 文档�Q�它��?Web 服务描述��Z��l�端点，�q�些端点会处理包含面向文档或面向�q�程的（RPC�Q�消息的消息。操作和消息都是被抽象描�q�的�Q�然后它们会被绑定到一个具体的�|�络协议和消息格式，用来定义端点。相关的具体端点被合�q�到抽象的端�Ҏ��服务中。WSDL 可以扩展为允许端点和其消息的描述�Q�不��用哪�U�消息格式或�|�络协议�q�行通讯都可以。然而，目前�l�过描述的绑定只能用�?SOAP 1.1、HTTP POST 以及多用途互联网邮�g扩展�Q�Multipurpose Internet Mail Extensions�Q�MIME�Q��?/p>

Web 服务体系�l�构中对 WSDL 的��用按照常规将基本的服务描�q�分成了两部分：服务接口和服务实现。这使每个部分都可以被分开独立定义�Q��ƈ可以由另一部分重新使用�?br />
服务接口定义是一�U�抽象或可重用的服务定义�Q�它可以被多个服务实现定义实例化和引用。我们可以将服务接口定义惌��成接口定义语�a��Q�Interface Definition Language�Q�IDL�Q�、Java 接口�?Web 服务�c�d��。这使常见的行业标准服务�c�d��可以被多个服务实现者定义和实现。这�c�M��于在�~�程语言中定义抽象接口然后得到多个具体实现。服务接口可以由行业标准�l�织定义�?/p>

服务接口包含 WSDL 元素�Q�它们组成了服务描述中的可重用部分，�q�些元素有：WSDL: binding、WSDL: portType、WSDL: message �?WSDL: type 元素�Q�如�?5 中所描述。WSDL: portType 元素中定义了 Web 服务的操作。操作定义了输入和输出数据流中可以出现的 XML 消息。您可以��操作想象成�~�程语言中的�Ҏ��说明。WSDL: message 元素指定哪些 XML 数据�c�d��l�成消息的各个部分。WSDL: message 元素用于定义操作的输入和输出参数。WSDL: types 元素中描�q�消息中复杂数据�c�d��的��用。WSDL: binding 元素描述特定服务接口�Q�WSDL: portType�Q�的协议、数据格式、安全性和其它属性�?/p>

服务实现定义是一个描�q�给定服务提供者如何实现特定服务接口的 WSDL 文档。Web 服务被徏模成 WSDL: service 元素。服务元素包含一�l�（通常是一个）WSDL: port 元素。端口将端点�Q�例如网址位置�?URL�Q�与来自服务接口定义�?WSDL: binding 元素兌��h��?/p>

��Z��说明职责的安排，开攑ֺ�用程序组�Q�Open Applications Group�Q�OAG�Q��ؓ开攑ֺ�用程序组集成规范�Q�Open Applications Group Integration Specification�Q�OAGIS�Q�购买标准定义了一个服务接口定义。这个服务接口定义会定义 WSDL: type、WSDL: message、WSDL: portType �?WSDL: binding�?/p>

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

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

完整�?Web 服务描述

完整�?Web 服务描述建立在服务基本的 WSDL 定义之上。完整的 Web 服务描述可以解决�q�样的问题：什么企业在托管�q�个服务�Q�它是何�U�类型的企业�Q�与服务相关联的产品有哪些？各种公司和��品类别中与该企业或其 Web 服务相关联的分类有哪些？有没有服务的其它斚w��Q�如服务质量�Q�会影响到请求者是否选择调用服务�Q��ؓ了��查找该服务更�Ҏ��Q�可以提供哪些关键字�Q?/p>

�?6 中描�q�C��一个完整的 Web 服务描述�?/p>

�?6. 完整�?Web 服务描述协议�?br />
UDDI 提供了一个保�?Web 服务描述的机制。虽�?UDDI 通常会被认�ؓ是一�U�目录机�Ӟ��但是它也定义了一个用 XML 表示服务描述信息的数据结构标准。UDDI 条目中有四种基本数据�l�构�Q�如�?7 中所�C��?/p>

�?7. 基本 UDDI 数据�l�构

UDDI 条目�?businessEntity 开始。businessEntity 元素对关于企业的信息�q�行建模�Q�包括基本的企业信息�Q�例如企业名�U�和联系方式信息是什么？�Q�、分�c�M��息（例如�q�是何种�c�d��的企业？�Q�以及标识信息（�?Dunn and Bradstreet �~�号是什么？�Q�。businessEntity 包含一�l?businessService 元素�Q�每个元素对应于企业希望发布的每�?Web 服务。每�?businessService 元素都包含和 businessEntity 元素�?Web 服务有关的技术性和描述性信息。businessService 包含一�l?bindingTemplate 元素。bindingTemplate 描述讉K��信息�Q�例如端点地址�Q�，�q�描�q?businessService 如何使用各种不同的技术规范。技术规范在�q�里的模型是 tModel。tModel 可以为很多不同概念徏模，如：一�U�服务、一个诸�?HTTPS 之类的��^台技术或一个类别。与 businessService 相关联的那一�l?bindingTemplate 元素代表�?businessService 所使用的技术的印记�?/p>

在Web 服务体系�l�构中，完整�?Web 服务描述包括用于端点描述的一层，�q�个端点描述使用 UDDI 条目向服务描�q�添加企业和实现环境�?/p>

端点描述遵��@�l�合 WSDL 使用 UDDI 的约定。端�Ҏ��q�C��?UDDI 提供企业信息和类别的标准表示。这�?UDDI-WSDL �U�定规定了如何从�?Web 服务相关联的 UDDI 条目中得出服务接口定义和服务实现定义�?WSDL 描述。这个约定对于在Web 服务体系�l�构中��?UDDI 作�ؓ��Z�� WSDL 的服务的服务注册中心来说臛_��重要�?/p>

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

服务描述协议栈中的最后一层是协议描述。协议描�q�反映两个企业伙伴之间�ؓ了完成一个多步企业交互而进行的 Web 服务调用的一个简单的�~�排。例如，“协议定义”定义了购买协议中诸如购买者和出售者之�cȝ��角色。协议定义规定了每个角色必须辑ֈ�的要求。例如，出售者必��L��接受报�h��h��Q�request for quote�Q�RFQ�Q�消息、购买订单（purchase order�Q�PO�Q�消息和付款消息�?Web 服务。购买者的角色必须有接受报��P��RFQ 响应信息�Q�、发��消息和帐户摘要信息�?Web 服务。这个简单的 Web 服务��C��业角色的�~�排对于在企业伙伴之间徏立多步的、面向服务的交互来说臛_��重要。在很多不同的企业协议标准下�Q�一个给定的服务��h��者或服务提供者也许能够扮演购买者或出售者的角色。通过昑ּ�地徏立企业协议和每个节点在企业协议中扮演各种角色的能力，��h��者可以选择在面对各�U�提供者企业伙伴时加入哪种企业协议�?/p>

�q�个领域充满了创新。对于企业协议定义来��_��目前�q�没有一个单独的标准。ebXML 协作-协议概要和协定规范（ebXML Collaboration-Protocol Profile and Agreement Specification�Q�描�q�C��q�些概念�Q�但不是�Ҏ��作�ؓ该体�pȝ��构的一部分描述�?Web 服务技术而描�q�的。Web 服务��程描述�?Web 服务端点描述�q�两层正处于开发中�Q�它们可以提供这个��别的服务描述�?/p>

服务描述的发布和发现

服务发布

Web 服务的发布包括服务描�q�的生成和之后的发布。发布可以��用各�U�不同机制�?/p>

生成服务描述
我们可以生成、手工编码服务描�q�ͼ�也可以根据已有的服务接口定义�l�成服务描述。开发者可以手工编码整个服务描�q�ͼ�包括 UDDI 条目。有些工具可以从�~�程模型和可执行 Web 服务的部�|�生�?WSDL�Q�还有可能生成来自元数据构�g的部�?UDDI 条目。部分服务描�q�可能已�l�存在（例如�Q�Web 服务可以��Z��一个行业标准服务接口定义）�Q�这样就只须�q�一步生成一��部分就可以了�?/p>

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

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

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

内部企业应用�E�序 UDDI 节点�Q�Internal Enterprise Application UDDI node�Q�节点：公司内部��Z��q�行内部企业应用�E�序集成而��用的 Web 服务应该被发布到�q�一�c?UDDI 节点。此�c?UDDI 节点的范围可以是部门的或公司的单独的应用�E�序。这�?UDDI 位于防火墙之后，允许服务发布者对他们的服务注册中心和它的讉K��权、可用性以及发布要求有更多的控制�?nbsp;
门户�|�站 UDDI 节点�Q�Portal UDDI node�Q�节点：由公司发布以供外部伙伴查扑֒�使用�?Web 服务可以使用门户�|�站 UDDI 节点。门��L��站节点运行在服务提供者的防火墙之外或之间。这�U�专�?UDDI 节点只包含公司希望向来自外部伙伴的请求者提供的那些服务描述。这允许公司保留对他们服务描�q�的控制、UDDI 节点的访问以�?UDDI 节点的服务质量。此外，通过使用门户�|�站中固有的��Z��角色的可见性，企业��服务描�q�的可见性局限在允许看到它们存在的伙伴中�?nbsp;
伙伴目录 UDDI 节点�Q�Partner Catalog UDDI node�Q�节点：��q��定公�怋�用的 Web 服务可以被发布到伙伴目录 UDDI 节点。伙伴目�?UDDI 节点位于防火墙之后。此�c�M��?UDDI 节点只包含来自合法企业伙伴的�l�过允许的、测试过的、有效的 Web 服务。此�c?Web 服务的业务环境和元数据可以被定位到特定的��h��者�?nbsp;
电子市场 UDDI 节点�Q�E-Marketplace UDDI node�Q�节点：对于服务提供者打��用来与其它 Web 服务竞争��h��者的业务�?Web 服务来说�Q�服务描�q�应该被发布到电子市�?UDDI 节点�?UDDI �q�营商节炏V��电子市�?UDDI 节点�׃��个行业标准组�l�或�C�֛�托管�Q�包含特定行业中的企业的服务描述。我们可以要求这些服务支持特定的标准、可搜烦元数据、接口或数据�c�d��。电子市�?UDDI 节点一般会�q��o掉某些非法的条目�Q��ƈ提供有保证的服务质量�?nbsp;
UDDI �q�营商节点：如果您希�?Web 服务可以被潜在的新的企业伙伴或服务用户发玎ͼ��q�可以将其发布到 UDDI �q�营商节炏V��IBM、Microsoft �?Ariba 都支持、复制和托管 UDDI �q�营商节炏V��在发布 UDDI �q�营商节点的时侯�Q�如果要让潜在的服务��h��者发现服务的话，完整的业务环境和�l�过深思熟虑的分类法是很必要的�?br />

�?8. 服务发现�q�箋�?br />
�?8 展示了从发布和发��C��最静态、最��单的技术到最动态、更复杂的技术的�q�箋体。Web 服务的用��h��实现者不必严格遵循这个发展顺序�?/p>

服务发现

Web 服务的发现包括获取服务描�q�和使用描述。获取过�E�可以��用各�U�不同机制�?/p>

获取服务描述

和发�?Web 服务描述一��P��Ҏ��服务描述如何被发布以�?Web 服务应用�E�序可能辑ֈ�的动态程度，获取 Web 服务描述也会有所不同。服务请求者将在应用程序生命周期的两个不同阶段�Q�即设计时和�q�行时查�?Web 服务。在设计�Ӟ��服务��h��者按照他们支持的接口�c�d��搜烦 Web 服务描述。在�q�行�Ӟ��服务��h��者根据他们通讯的方式或公告的服务质量搜�?Web 服务�?/p>

使用直接发布�Ҏ��Ӟ��服务��h��者在设计时对服务描述�q�行高速缓存，以在�q�行时��用它。服务描�q�可以被静态地用程序逻辑表示�Q��ƈ存储在文件或��单的本地服务描述资源库中�?/p>

服务��h��者可以在设计时或�q�行时在服务描述资源库（��单的服务注册中心�?UDDI 节点�Q�中��索一条服务描�q�。查找机刉��要支持一�U�查询机�Ӟ��它提供按接口�c�d��Q�基�?WSDL 模板�Q�、绑定信息（卛_��议）、属性（�?QoS 参数�Q�、所需的中介类型、服务分�c�L��、企业信息等�{�的查找�?/p>

不同�c�d��?UDDI 节点会显�C�可以选择的运行时�l�定 Web 服务的数目、多选一的策略，或者调用服务之前必��ȝ��h��者作出预选的量�?/p>

内部企业应用�E�序 UDDI 节点和伙伴目�?UDDI 节点��不需要预选来建立�Ҏ��务的信�Q。服务选择可以建立在绑定支持、历史性能、服务质量分�c�R��相似性或负蝲�q��的基��之上�?/p>

电子市场 UDDI 节点��有更多的运行时服务可以选择。必��L��行某�U�预选以保证 Web 服务提供者是有�h值的伙伴。我们可以根据�h格承诺、开销、经�q�允许的伙伴列表的出席情况，同样�q�有�l�定支持、历史性能、服务质量分�c�d��怼�性来选择服务�?/p>

如果服务��h��者从 UDDI �q�营商节�Ҏ��?Web 服务提供者，他们在预选可能的服务提供者时��必��d��可能谨慎和认真。应该有一个有效和准确的机制就位，�q��o掉无用的服务描述和没有�h值的服务提供者�?/p>

使用服务描述
在获取了服务描述之后�Q�服务请求者需要处理它以调用服务。服务请求者��用服务描�q�生成对 Web 服务�?SOAP ��h��或特定于�~�程语言的代理。该生成可以在设计时或运行时�q�行�Q�从而对 Web 服务的调用进行格式化。我们在设计时和�q�行时可以��用各�U�工具从 WSDL 文档生成�~�程语言�l�定。这些绑定表�C�应用程序的 API�Q��ƈ��装了来自应用程序的 XML 消息传递的�l�节�?/p>

在下一部分�Q�我们将描述基本 Web 服务体系�l�构的扩展，电子商务需要这些扩展才能��?Web 服务�?/p>

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

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

安全�?/p>

真的需�?Web 服务安全层吗�Q�对于基于消息的体系�l�构�Q�业界已�l�有一套现成的而且�q�泛接受的传输层安全机制�Q�比如，安全套接字层�Q�Secure Sockets Layer�Q�SSL�Q�和�|�际协议安全�Q�Internet Protocol Security�Q�IPSec�Q�，��Z��么还要再加别的呢�Q��ؓ了回�{�这个问题，我们不仅要研�I�要求，�q�将探讨一些只依靠现有的几�c�M��输层安全机制�q�不能在 Web 服务模型内提供��够的安全性的情况�?/p>

通常�Q�Web 服务安全层必��L��供以下四个基本的安全性要求：

机密性（Confidentiality�Q�是指信息对没有�l�过授权的个人、实体或�q�程的不可用性或不公开性，�q�保证消息内容不�Ҏ��有经�q�授权的个�h公开�?nbsp;
授权�Q�Authorization�Q�是指权限的授予�Q�包括根据访问权限授予访问权和保证发送方被授权发送消息�?nbsp;
数据完整性（Data integrity�Q�是指数据没有以未经授权的方式或被未�l�授权的用户不可察觉的改变或者破坏的性质�Q�从而确保消息在传送的�q�程中不会被偶然或故意修攏V�?nbsp;
原始性证明（Proof of origin�Q�是�Ҏ��息或数据的发送者进行标识的证据。断�a�消息由正��标识的发送者传送，�q�且不会重新发送以前传送过的消息。这一要求隐含了数据完整性的要求�?nbsp;
�׃��需要在��Z�� XML 消息和工作流的动�?Web 服务世界中管理不同风格的资源讉K��Q�所以必��重新评估策略、信��d��风险评估�q�三者相互之间的关系。现有的��Z��个�h�w�䆾的访问控制模型正在发展成为基于角色的信�Q域关�p�，在该�U�关�p�M��Q�可信�Q的权威机构将执行某项��d��的权限授予个人，其行为受该权限限制。Web 服务体系�l�构定义了需要信息的代理�Q�服务请求者）、提供信息的代理�Q�服务提供者）�Q�有时还有提供关于信息的信息的代理（服务中介者、元信息提供者或服务注册中心�Q�。服务中介者经�怼�收到大量信息��h��Q�这样就需要它能够军_��谁想要哪些信息以及请求者是不是已经被授予访问权。基��设施和关�p�d��化迅速，因此有关的策略需要能灉|��的允许或拒绝讉K��?/p>

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

SOAP 信封是用 XML 定义的，从而��您可以向消息��d��U�类众多的元信息�Q�比如事�?ID、消息�\�׃��息和消息安全性。SOAP 信封�׃��个部分组成：头和��M��。头是把功能��d��?SOAP 消息中的通用机制。SOAP 头元素下一�U�的所有子元素都叫做头条目。主体是为最�l�的消息接收�Ҏ��要的应用数据�Q�如 RPC�Q�准备的容器。因此，可以�?SOAP 看作是在传输层（例如 HTTP�Q�和应用层（例如�Q�业务数据）之间引入的另外一层，在此可以方便的传送消息元信息。SOAP 头提供可扩展机制以扩�?SOAP 消息使其可以适用于多�U�用途。虽�?SOAP 头是向消息添加安全性功能最合理的地方，但是 SOAP 规范本��n�q�没有指定这��L��头元素�?/p>

让我们仔�l�的分析一下在 Web 服务模型中现有的各种各样的传输层安全机制��Z��么不够，又�ؓ什么会需�?Web 服务安全层，以及�q�个安全层最初是怎样的�?/p>

端对端的消息传递。安全传输协议，�?SSL �?IPSec�Q�可以在传输�q�程中提供消息完整性和机密性，但只有在点对点的情况下，它们才会�q�样做。但是，因�ؓ SOAP 消息是由中介体接收�ƈ处理的，所以即便两两之间的通信链�\�Q�communication link�Q�是可信�ȝ��Q�只要在所有的中介体间没有信�Q兌��Q�trust association�Q�，那么安全的端对端通信��是不可能的。如果有一条通信链�\不安全，那么端对端安全性也会被削弱。就 Web 服务拓扑来看�Q�安全的传输对于 SOAP 消息的端对端安全性是不够的�?/p>

中间件的独立性。最�l�，唯一能提供端对端安全性的方式��在于应用层或中间�g层。如果消息在通信方之间的某点是纯文本�Q�那么就有可能在�q�点受到��d��。但是，既要在新的或现有的应用中集成加密功能�Q�又不能引入额外的安全性弱�Ҏ��增加风险�Q�这是一��不�Ҏ��又不受欢�q�的��d��。因此，在大多数情况下，��Z��希望安全性功能尽可能靠近应用�Q�但不在应用本��n中构建�?/p>

传输的独立性。SOAP 中介体的原意是用来把信息转发��C��同的�|�络上去�Q�通常使用的传输协议也会有所不同。虽然所有的通信链�\都是安全的，中介体也是值得信赖的，但是�Q�安全信息（如消息发送者的�w�䆾验证�Q�需要被转移到消息�\径上的下一个传输协议安全性域�Q�这个过�E�冗长而且复杂�Q�还可能会导致完整性方面的�~�陷�?/p>

异步多阶消息传递。传输层安全性保证数据在通信链�\上传输时的安全。它与存储在��M��中介体上的数据都无关。在一�ơ传输被接收�q�解密后�Q�传输层安全性对保护数据免受没有�l�过授权的访问和可能的改变就不是很有帮助了。在先存储消息然后�{发的情况下（持久的消息队列）�Q�消息层保护是有必要的�?/p>

因�ؓ我们已经看到安全的传输机制不��以满�� Web 服务开发方法和使用场景的要求，所以我们的��d��是要创��Z��个概忉|�?Web 安全层，包括下列几个�l��g�Q?/p>

对于�|�络安全性：
支持�?SSL �?HTTPS �{�提供机密性和完整性的安全传输机制�?nbsp;
对于 XML 消息�Q?nbsp;
如果通信没有中间节点�Q�那么发送方可以依靠 SSL �?HTTPS 来保证用��h��识和密码的机密性�?nbsp;
W3C 正在标准�?XML 数字�{�֐�工作的支持。它定义了生成消息摘要与利用发送方的私钥来�{�֏�消息的标�?SOAP 头和��法。因此，接收方就可以证明消息发送方的��n份�?nbsp;
对网�l�内部的、可信�Q的第三方验证服务�Q�例�?Kerberos�Q�的支持�?nbsp;
概念�?XML 消息传递模型还必须支持端对端保护消息及其子元素。�ؓ了全面的支持�Q�过�E�和��能力需要被扩展到包括消息交换的安全性特征。应该有一�U�方式可以定义多�D�|��息和用预期接收方的公钥来保护消息�D�c��需要探讨的一些论题有�Q?/p>

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

W3C 有一�?XML 加密工作�l�，帮助提供数据元素的机密性，�q�样验证交换成�ؓ可能�?nbsp;
W3C 已发布了一�?XML 密钥��理服务�Q�XML Key Management Services�Q�XKMS�Q�的备忘录，来帮助分发及��理在端点之间进行安全的通信所需的密钥�?nbsp;
OASIS 已经成立了一个技术委员会来定义授权和验证断言�Q�Authorization and Authentication assertions�Q�SAML�Q�。这��帮助端�Ҏ��受和��x��讉K��控制权�?nbsp;
OASIS 已经成立了一个技术委员会来标准化讉K��控制权的表达�Q�XACML�Q�。这��帮助端点能够以一致的方式解析 SAML 断言�?nbsp;
随着我们不断的研�I?Web 服务模型中遇到的所有威胁和对策�Q�Web 服务安全性体�pȝ��构也在不断发展着�?/p>

服务质量�Q�QoS�Q�和可靠的消息传�?/p>

服务质量垂直塔提供与 Web 服务概念栈每一层有关的信息的规范。对于网�l�层�Q�这��会暗示能��用各�U��别的服务质量的网�l��?/p>

�׃��需要通过�|�络�q�行可靠的消息传递，所以得�Ҏ��在这一领域内发送高质量服务的能力来选择�|�络技术。可靠的消息传递指基础设施把消息一�ơ发送（只发送一�ơ）到预定目标或提供��定的事�Ӟ��如果发送没能完成，也许会重新发送到源）的能力。结合网�l�层�?XML 消息传递将需要支持四个等�U�的消息传递服务质量：

1. 最佛_��力：服务��h��者发送消息，服务��h��者和基础设施不尝试重发�?/p>

2. 臛_��一�ơ：服务��h��者提��求，�q�一直重试直到它接收到确认�ؓ止。服务提供者重复消息处理不是问题，例如��单的查询处理。实现这可能意味着每个消息包含唯一的标识。服务请求者以自己��定的时间间隔重发没有得到确认的消息。服务提供者发出确认消息，�?RPC 响应消息�Q�如果不能处理的话，��发送不能处理的消息异常�?/p>

3. 臛_��一�ơ：�q�徏立在最��一�ơ情�늚�基础之上。服务请求者试着��h��直到它得到回应。象现有的全局唯一标识�W�（universal unique identifier�Q�UUID�Q�这��L��机制允许服务提供者抑刉��复多�ơ的��h��Q�以��保��h��不会被多�ơ执行。例如，��h��Ҏ��库存目录中的一个号码拿一件东�ѝ�?/p>

4. 刚好一�ơ：服务��h��者提��求，��h��已经执行的回应��其得��C��证。刚好一�ơ交换模式排除了重传��h��的需要�ƈ且适应失效的情��c�?/p>

可靠的消息传递通常是通过标准设计模式传送的�Q�在该模式中�Q�一件基��设施�Q�有时叫做端点管理器�Q�将会被用来在通信的每一端协调消息发送。在�q�种模式中，发送方通过同步��h��把消息发�l�端点管理器。一旦发送到�Q�发送方��可以得��C��证，一定会把消息发送出��L��引发��定的事�Ӟ��例如��时�Q�。端点管理器与其它资源管理器参与本地事务�Q�在一�ơ事务中不仅可以��q��点管理器�Ҏ��息进行排队，�q�有可能在数据库中记录业务过�E�步骤。应用程序应该指�z��点管理器来负责发送消息或者检��发送失败的原因�Q�它在网�l�传输层�?XML 消息传递层都可以�v作用�?/p>

可靠的一�ơ性消息发送的技术和目的都不会引起争议。但是，围绕如何�?SOAP �?XML 的上下文中支持这��Ҏ��术已�l�提��Z��重要的质疑。关键问题是�Q�应不应该在 XML 消息层上定义必要的协议和消息格式�Q�从而允许可靠的消息发送成��Z��端应用程序的责�Q�Q�或者能不能在较低的层（如传输层上）定义协议和消息格式？

在没有支持可靠的消息传递的传输方式的情况下�Q�即互联�|�）�Q�XML 消息传递层��需要在不可靠的基础设施之上支持�q�些服务质量。端点管理器��需要修�Ҏ��息，而不是修�Ҏ��息的传输信封�Q�这��h��能成功扮演其角色。应用程序和业务�q�程的定义将必须考虑所有可能的�l�果�Q�如拒收消息或在可接受的旉��长度内发送不出去。但是，�q�些定义�q�需要考虑在发送过�E�中发生的中间状态。向业务�q�程公开�q�些状态可能会大大增加其定义的复杂�E�度�Q�但对于定义�q�程的业务分析师而言�q�无太大意义。在一些情况下�Q��?XML 消息传递来发送可靠的消息传递格式可能会��D��使用现有的这些传输毫无效率。最好能开发一�U�在互联�|�上使用的可靠的 HTTP 标准�?/p>

在有支持可靠的消息传递的传输方式的情况下�Q�即在企业内部）�Q�它可以用于发送可靠的消息�Q�而不�?XML 消息传递层�Q�可能缺省�ؓ�I�实玎ͼ�。端点管理器��会只修改传输信��，而不会修�?XML 消息。��用可靠的传输使应用程序和业务�q�程定义不需要知道或处理消息发送的中间状态�?/p>

需要在��来�q�行的几点补充：

互联�|�的 HTTP 需要加以改�q�才能提供可以在企业间��用的��单可靠的消息传递。这会带来额外的好处�Q�不�?SOAP�Q�许多种消息�c�d��都可以采用可靠的消息传递。需�?XML 消息传递层处理可靠的消息传递的情况��׃��随之减少�Q�促�q�不依赖于网�l�选择的应用程序开发�?nbsp;
HTTP 上的 XML 消息传递层也需要处理发布和订阅、消息排序、发送时间限制、优先��和多点传送等�{�问题�?nbsp;
服务提供者对可靠的消息传递的质量和实现的支持情况��会在服务描�q�的�l�定信息中定义�?/p>

服务实现层（例如�Q�通过事务的或安全�?SOAP �l�定�Q�的服务描述以及接口层（例如�Q�从��h��者开始等待来自提供者的响应之后最长经�q�多久）的其它服务描�q�C��都会关系到服务质量（Quality of Service�Q�信息。�h们期待着开发出 WSDL 扩展或新的服务描�q�层来允许指定其它服务质量和功能的规范�?/p>

Web 服务层上的服务质量可以在服务合成和服务流中��用。在为流选择服务或提�C�流��理器该开始恢复或其它的流�Ӟ��预期的执行时间、超时倹{��历史��^均执行时间值都可以作�ؓ输入。服务描�q�栈的端�Ҏ��q�层和工作流描述层必��L��供这一信息�?/p>

Web 服务的服务质量问题和解决�Ҏ��仍然很紧�q��?/p>

�pȝ��和应用程序管�?Management)

随着 Web 服务成�ؓ商业�q�作的重要因素，��需要对其进行管理。在�q�种情况下，所谓管理是指专为应用程序定制的或从厂商那里买来的管理应用程序可以发�?Web 服务的基��设施、Web 服务、服务注册中心和 Web 服务应用�E�序存在性、可用性以及健康度。最令�h满意的结果是��理�pȝ��q�应当能够控制和配置基础设施及组件�?/p>

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

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

对于�|�络层，现有的网�l�管理��品几乎支持目前所有的�|�络基础设施。这些��品应当用于管理企业内部的 Web 服务的网�l�基��设施。当企业�怺�作用�Ӟ��应该向其合伙�h提供有关 Web 服务基础设施可用性的基本报告。媄�?Web 服务基础设施可用性的�|�络可用性应作�ؓ因素之一写入报告�?/p>

�?XML 消息传递层�Q�协议应该在企业内部��q��有的基础设施��理工具来管理。在企业�怺�作用的情况下�Q�每个站炚w��有必要提供协议的基本报告和恢复办法。例如，如果站点 A 支持会话�Q�就该向站点 B 提供可用于查询活跃的 IBM Software Group Architecture Overview Web Services Conceptual Architecture 28 会话以及��回滚的接口。协议层需要正常的频道与协议和�c�M��对等的控制接口�?/p>

��理的第二个斚w��?Web 服务本��n的可��理性。一些主要的考虑是性能、可用性、事件和使用量度�Q�因为它们将为服务提供者市场收取所提供的服务��用费提供必要信息�?/p>

服务描述可以用于宣传可管理性特征和��理需求。这斚w��的约定正在开发之中�?/p>

服务注册中心的�Q何实玎ͼ�不管是用于私人消费还是公共消费，都要求基��设施是可用的、发送承诺的服务质量�q�能够报告��用情��c��这些系�l�管理元素对于成功采�?UDDI 是十分重要的�?/p>

对于 Web 服务应用�E�序�l��g来说�Q�支持管理环境可能会大大增加应用�E�序的复杂性。由�?Web 服务必须易于开发，所以必��d��可能向开发者隐藏这��L��复杂性。Web 服务的管理方式要使基��设施能自动提供量度、审计日志、启动和停止处理�q�程、事仉��知和作�?Web 服务�q�行时的一部分�Q�也��是��_��L��?SOAP 服务器）的其它管理功能。因为基��设施通过观察它所托管的组件的行�ؓ不可能收集到所有的信息�Q�所�?Web 服务实现也许会需要向托管它的服务器提供基本的健康度和监督信息�?/p>

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

Web 服务体系�l�构的��^台独立性��它不适合套用��M��一�?Web 服务��理标准。因此，需要有一�U�基�?Web 服务而且允许 Web 服务与管理系�l�通信的方法。�ؓ了达到这一目的�Q�还应当定义�?WSDL 文档描述的、可接收来自可管�?Web 服务的事件以及量度更新的��理服务�Q��ƈ使其可用。管理服务的实现技术与 Web 服务无关。但是，对于��Z�� Java 技术的环境�Q�Java ��理扩展�Q�Java Management Extension�Q�JMX�Q�应该是合乎逻辑的而且厂商不可知的选择。通过使用 JMX �q�样的开放标准，对现有的�pȝ��理提供者来��_��要把其目前所提供的��品扩展�ؓ包括 Web 服务关键元素的管理应该是很容易的。Web 服务的管理体�pȝ��构仍在向前发展�?/p>

14.4 Web Services ��目实战

14�Q?�Q? Web Services实现

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

Web 服务遵��@ Java 2 �q�_��Q�企业版�Q�Java 2 Platform�Q�Enterprise Edition�Q�J2EE�Q�、通用对象��h��代理体系�l�构�Q�Common Object Request Broker Architecture�Q�CORBA�Q�以及其它针对与耦合较紧的分布式或非分布式应用程序集成的标准。Web 服务是部�|��ƈ提供通过 Web 讉K��业务功能的技术；J2EE、CORBA 和其它标准是实现 Web 服务的技术�?/p>

J2EE 1.4��Z��用常规Java�c�L��企业�U�Java Beans来创建和部��vweb services提供了一个全面的�q�_��。以下表格给��Z��J2EE 1.4中包括的web service APIs的细节�?nbsp;

定义在Java Community Process的JSR 101之下的JAX-RPC�Q�提供了创徏和访问web services的Java API,因此它是使用J2EE�q�_��创徏和部�|�web services�?#8220;心脏和灵��?#8221;。通过向应用程序开发者隐藏XML�c�d��和Java�c�d��映射的复杂性，以及处理XML和SOAP消息的底层细节，它提供了一个简单的�Q�健壮的创徏web services应用的��^台。�ؓ了引入一个方法调用范式，它提供了两种�~�程模式:服务器端模式�Q��用Java�c�L��无状态EJB开发web service 端点�Q�和客户端模式，创徏作�ؓ本地对象讉K��web services的Java客户端。JAX-RPC 1.1要求使用SOAP 1.1�Q��ƈ且实��C��使用其他技术创建的web services之间的互操作性，比如微��Y�?NET。实��C��J2EE1.4规范的应用服务器�Q�比如OC4J 10.1.3和SUN的Java System Application Sever,提供了对于JAX-RPC的支持�?/p>

JAX-RPC的叫法有点用词不当，因�ؓ它既支持RPC�c�d��的web services�Q�也支持文档�c�d��的web services�?/p>

Web Services部��v模型

在J2EE 1.4之前�Q�所有J2EE商家都��用他们私有的部��v模型支持web services。J2EE 1.4为Java Web Services定义了部�|�模型。它为J2EE�q�_��上的web services制定了开发，部��v以及服务发布和��用的标准�?/p>

有了J2EE 1.4对web services的支持，让我们学习��用J2EE�q�_��来徏造web service的方法�?/p>

使用J2EE创徏一个Web Service

把web service创徏成一个轻便的和可互操作的分布式组件不是一��琐��的��d��。如之前讨论的，你既可以把常规Java�c�，也可以把无状态EJB部��v成web services。常规Java�c�被打包在一个web模块中，而EJB web services被打包在标准的ejb-jar模块中�?/p>

在这两种部��v选择中，你会使用哪一个呢?

Java �c�d��无状态EJB:永无止境的争�?/p>

你会选择常规Java�c�还是EJB作�ؓ你创建web service的技术可能是一个长期的争论。Java�c�L��EJB更容易开发，它是�U�的Java对象�Q��ƈ且它不具有EJB带来�?#8220;额外辎重”。但是，EJB提供了几个很好的特点�Q�比如被声明的事务和安全性，因此它��开发者将�_�֊�集中于徏立商业逻辑�Q�而不需要担心基��服务架构。EJB 3.0大大��化了设计模型�Q�在它的规范中，EJB看�v来就像常规Java�c�R�?/p>

使用J2EE 5.0��化SOA的开�?/p>

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

　　��Z��在J2EE 1.4中开发一个简单的Java web service�Q�你需要几个web service定义文�g:WSDL�Q�映��文件和几个冗长的标准以及私有的web services部��v描述�W�。Web Services元数据规范��用一�U�类��g��EJB 3.0的缺省配�|�方法来使开发更��ѝ��Web Services元数据注解处理器(或web services 装配工具)会�ؓ你生成这些文�Ӟ��因此你只需要关心类的实现�?/p>

　　当你使用Web Services元数据开发时�Q�这是一个看��h��如此��单的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";
}
}

　　正如我之前提到的�Q�EJB 3.0使用常规Java�cȝ��化了EJB的开发。通过利用EJB 3.0和Web Services元数据，开发基于EJB的web services��会变得��来��简单。当使用EJB 3.0和web services元数据时�Q�这是一个看��h��如此��单的HelloWorld EJB web service。你不必担心创徏WSDL�Q�部�|�描�q�符�{�等�Q�应用服务器会在部��v�q�程中生成这些定义文件�?/p>

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�Q�服务开发正在变得越来越��单。现在，你可以在实现了J2EE规范的应用服务中�Q�比如JBoss Application Server�{�，开始创建和部��v你的web services了�?/p>

14.4�Q? Web Services ��目实战

14.4.2.1 Web Services的实�?br />本节使用EJB 3.0 实现一个web Services��d��的例子。下面我们创��Z��个工�E�叫�Q�EmployeeManager。加入用到的EJB 3.0的jar包�?/p>

我们先创建服务器端的实体Bean�Q�这和创建普通的Ejb3.0实体bean是一��L��Q?/p>

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;

}

接着创徏�q�程接口�Q?/p>

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�c�M��要注意的是Remote接口是要实现的，@SOAPBinding(style=Style.RPC)�Q�Soap的绑定方式也是需要的�Q�不然在客户端是找不到LoginDao �?/p>

下面创徏会话bean�Q?/p>

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;

}

��x��服务器端的类是徏好了�Q�这里又两个问题�Q�需要说明一�?/p>

A�Q?两个�cȝ��Ҏ��中都没有抛出异常�Q�可不可以抛出呢? 可以。但到实现SOA的时候会有一些问题，��是异常在经axis 通过WSDL2Java 生成后，在程序运行时有可能会出现找不到的情�Ş。所以本文�ؓ了让大家在仿照这个例子时都能成功�Q�所以也��抛弃了异常的抛出�?/p>

B�Q?两个�cȝ��Ҏ��的返回值是基本�c�d��Q�而不是自定义�c�d��Q��ؓ什么会�q�样呢，自定义类型可以不可以呢，可以�?/p>

现在我们的webservice的服务器端就已经创徏好了�Q�我们把服务器端的三个类和persistence.xml文�g一��h��包部�|�到jboss服务器里。包名是�Q�empdEjb�?/p>

下面我们来创建客��L��Q?/p>

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!");

}

把服务器端发布出��M��后，服务器端会自动发布一个webService�Q��ƈ且生成�ƈ发布一个WSDL文�g�Q�通过讉K��http://localhost:8080/empdEjb/LoginDaoBean?wsdl�q�个�|�址是可以找到的。http://bean.webservice.ascent.com/jaws �?LoginDaoService 字符�Ԍ��在客��L��E�序当中出现了上面两个字�W�串�Q�它们在你生成的wsdl 文�g中有详细的描�q�。在地址栏里输入http://localhost:8080/empdEjb/LoginDaoBean?wsdl�Q�就可以看到wsdl文�g了。这里你所需要做的是按照你自��q��情况�~�写你自��q��客户端程序。启动服务器后，在机子上�q�行客户端程序就可以了。当然你也可以去�~�写自己的jsp客户端去调用它。wsdl文�g的内容如下：

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

�q�样一个WebService+Ejb 3.0的例子就实现了�?/p>

14.4.2.2 SOA的实�?br />本例�q�是��Z��前两个例子的基础上的�Q�要保证上面的例子是能正常运行的�?/p>

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

�q�里�Q�在原来的EmployeeManager工程下面��Z��个wsdl文�g夹，��它攑֜�下面�Q�然后所要做的准备工作是�Q�把包括axis在内的几个jar包找刎ͼ�讄��在你的classpath里面。然后在命��o行下�q�行WSDL2Java�?/p>

哪几个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

�q�是我classpath 里面所讄��的几个jar包，后面两个可以不需要，�W�二个也可以不需要，后俩个只是保证运行的时候没有警告�?/p>

1�Q?��LoginDaoBean.wsdl 攑֜�wsdl文�g夹下面。E:\workspace\EmployeeManager\wsdl

2�Q?在命令行下进入E:\workspace\EmployeeManager\wsdl

3�Q?执行 java org.apache.axis.wsdl.WSDL2Java LoginDaoBean.wsdl

�q�个时候，你会发现在wsdl文�g夹下面生成了一个目录，它里面包含了几个java�c�R�?/p>

LoginDao.java�Q�LoginDaoBindingStub.java�Q�LoginDaoService.java�Q�LoginDaoServiceLocator.java

2 SOA的实�?br />本节是一个以SOA+struts实现��d��的例子。新��Z��个web工程�Q�EmployeeWebService�Q�然后将上面生成的几个类攑օ�你的src目录下面�Q�是放整个目录，别只攑և�个类�q�去. 构徏struts资源。创建struts的过�E�就不在�q�里�l�说了。创建的action内容如下�Q?/p>

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();

}

�q�里用到的LoginDaoServiceLocator�c�d��getLoginDaoPort()�Ҏ��是使用WSDL2Java命��o把wsdl文�g生成的类。现在就可以打包成叫employee的war文�g�Q�运行它。至此，你便可以在浏览器中输�?a href="http://localhost:8080/employee/login.jsp">http://localhost:8080/employee/login.jsp�Q�运行你�q�个SOA的应用了。如果是把服务器端部�|�到别的机器上，只要把localhost改�ؓ相应的ip��可以了�?/p>

��结
本章首先介绍了目前一个前沿技术：Web Services和面向服务的软�g架构�Q�Service Oriented Architecture�Q�简�U�SOA�Q�。在理解了Web Services原理之后�Q?接下来我们讲解了如何使用J2EE和EJB3.0来实现Web Services�?br />

Daniel 2011-08-31 13:25 发表评论

Difference Between RPC and Document Style WSDL

Daniel — Wed, 31 Aug 2011 05:24:00 GMT

rpc和document的区�?/span>

2008-10-24 18:48:07| 分类�Q?/span> webservice|字号订阅

��译�?The Difference Between RPC and Document Style WSDL

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

binding的style和use

通常情况下，web服务是由一个wadl文�g来描�q�的的。在�q�个文�g中，抽象的描�q�所支持的web服务操作和消息，然后兌��C��个具体的�|?/p>

�l�歇息和消息格式。典型的wsdl文�g��p��个几个元素组�?tyoes,message.porttype用来描述抽象的定�?biding和service指定具体的实

现。所有的�q�些元素包装在definitions元素中�?/p>

在binding元素中，rpc和document是最值得我们��x��的元素。wsdl �?binding描述了如何将service兌��到消息协议；�q�些消息协议�?/p>

http�Q�mime�Q�soap中的��L��一�U�。不�q�，实际中，soap是最常用的协议；rpc和document的区别也是在soap的下的区别（it is SOAP that

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

元素包含一对参敎ͼ�style(rpc|document)和use(encoded|literal)�Q�他俩会影响到soap消息的格�?他们的��用方式如�?/p>

�Q?/p>

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

style属�?

wsdl1.1要求binding的style要么是rpc要么是doucment。这个选择与如何组�l�soap的负��L��兟뀂下面是分别他们如何影响�?/p>

容的�l�节�?/p>

document�Q?lt;soap:body>的内容由定义�?lt;wsdl:type>中的xml模式指定。他不需要遵循特定的soap规范。简�a�之，soap消息是通过

中的document发送出去，而没有额外的要遵循的格式规则。document style是一�U�默认的选择�?/p>

rpc�Q?元素的结构需要遵循特定的规则�Q�soap1.1规范�W?部分有细节）。根据这些规则，可以包含唯一一个元�?/p>

�Q�这个元素在operation后被命名�Q�所有的参数都必��d��成这个元素的子元素�?/p>

因�ؓ可以自由的选择哪种消息格式�Q�遵循document格式的soap消息看上��d��像rpc格式�?/p>

现在�Q�决定性的问题是：选择其中��L��一个选项后的�l�果是什么样�Q��ؓ何要选择rpc或者document�Q�很多情况下�Q�选择他们后，soap消息

的格式看��h��很相像，那么��Z��么还要提供这�U�选择呢？原因要从soap标准化的历程中寻找�?/p>

use属�?/p>

�q�个属性指定了soap消息的编码规则。他同样�?lt;wsdl:binding>元素中完成。他的��gؓencoded或者literal.

他引用了一�p�d��规则�Q�soap客户端和soap服务端都遵��@�q�些规则以解�?lt;body>元素中的内容�?/p>

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

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

encoded�?/p>

附文章全文：

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 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:

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 element - can be structured. Here are some details of how each style affects the contents of :

Document: the content of is specified by XML Schema defined in the section. It does not need to follow specific SOAP conventions. In short, the SOAP message is sent as one "document" in the element without additional formatting rules having to be considered. Document style is the default choice.
RPC: The structure of an RPC style element needs to comply with the rules specified in detail in Section 7 of the SOAP 1.1 specification. According to these rules, 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 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 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:

RPC/encoded
RPC/literal
document/encoded
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.

Daniel 2011-08-31 13:24 发表评论

Three ways to convert TIF to JPG with JAI

Daniel — Fri, 27 May 2011 14:39:00 GMT

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/

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

Code 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;

}

Daniel 2011-05-27 22:39 发表评论

日韩亚洲国产综合高清,亚洲欧美第一成人网站7777,亚洲情综合五月天

Algorithms Chapter2 Answer

Java concurrent �ȝ��一

java nio���结

java nio���结

数据库设计准则（�W�一、第二、第三范式说明）

I、关�p�L��据库设计范式介绍

1.1 �W�一范式�Q?NF�Q�无重复的列

1.2 �W�二范式�Q?NF�Q�属性完全依赖于主键[消除部分子函��C��赖]

1.3 �W�三范式�Q?NF�Q�属性不依赖于其它非��d��性[消除传递依赖]

2.1.1 问题分析

2.1.2 解决�Ҏ��

�ȝ��

Difference Between RPC and Document Style WSDL

rpc和document的区�?/span>

Three ways to convert TIF to JPG with JAI

java nio��结

java nio��结