public class Container {
	private Item item=null;
	public Container(){
		println();
		this.item=new Item();
		
	}
	public void println(){
		System.out.println("Container:"+this.getClass().getClassLoader());
	}
}
public class Item {
public Item(){
	println();
}
public void println(){
	System.out.println("Item:"+this.getClass().getClassLoader());
}
}

private void start() {
        try {
        	System.out.println("***************************");
            // Load up the bootstrap container
            final ClassLoader parent = findParentClassLoader();

            String libDirString = System.getProperty("load_dir");

            File libDir;
            if (libDirString != null) {
                libDir = new File(libDirString);
                if (!libDir.exists()) {
                    throw new NullPointerException("dir not exit");
                }
            }
            else {
            		throw new NullPointerException("dir not exit");
            }

            System.out.println("parent is:"+parent.getClass());
            ClassLoader loader = new MYClassLoader(parent, libDir);
            
            Thread.currentThread().setContextClassLoader(loader);
            Class containerClass = loader.loadClass(
                    "Container");
            containerClass.newInstance();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
}

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛

这一次，我们需要跨平台通用远程调用框架的神话么？

事情起因是开发各方讨论系统中的两种接口

接口基本需求：1、用户数据的同步接口 2、业务接口，包含客户端对服务器端的控制接口和服务器端对客户端的实时状态汇报接口。

接口非功能性需求：跨平台，第二类接口中客户端可能在企业内网，要求穿越防火墙、NAT、并且可能没有外部IP。

拿到这样的一个需求，HTTP基本的通信协议基本是必选，对上层应用协议，大家首先想到的都是SOAP。于是有了下面的解决方案：

1、 对第一类接口定义了SOAP接口，并对用户属性的变化进行了预计设计。接口类似如下update(propertyList list)，propertyList定义为KEY/Value的值对。好处如下是客户端和服务器端与服务器端之间只保存一个WSDL文件，在用户数据发生变化的时候，该接口不用发生变化。

2、 第二类接口不能直接使用SOAP，并且服务器端到客户端的状态推送需要使用HTTP推的技术。有人提出了定义一个XML SCHEMA，该SCHEMA描述的接口如FuncName（param1,param2,param3……）来作为第二类接口，好处是：任何业务相关的控制状态信息都可以通过该接口通信，客户端与服务器端之间只维护一份XML SCHEMA

上述方案中，第一类接口和第二类接口是类似的思路，都是定义一个通用的远程调用函数接口，并且从远程调用的角度去分析其优缺点。在这些冠冕堂皇的优点后面大家都甘之如饴，以为跨平台通用远程调用框架发挥了化腐朽为神奇的作用。然而恕我直言，消息传输就是消息传输，面向消息的通信方式可以解决的问题，完全没有必要扯上远程过程调用，在上述的场合直接的HTTP+业务数据已经可以很简洁的解决问题。由于第二类接口中打算自造轮子实现通用远程调用框架，和用SOAP实现没有本质的区别，归作一类进行分析：

1、 如果把HTTP+XML业务消息的通信方式描述成函数Post（XML DATA），update(propertyList list)这种接口和Post（XML DATA）一样都具有下面的特性：

a) 接口也很稳定
b) 任何业务数据都能通过，当然任何数据都可以通过。

通用的通信协议原本就具有通用远程过程调用接口梦寐以求的特性。

2、 通用远程调用框架下的通信消息的消息结构可以是HTTP+基于XML通用远程调用层+业务消息的结构。比起HTTP+XML的通信方式多了一个基于XML通用远程调用层，这层的实现可以使用SOAP类库，但是由于定义成通用的SOAP接口并只有一个WSDL文件，消息只能分发到一个函数入口，虽然添加了庞大的SOAP处理引擎，但无法利用现成的SOAP类库将请求分发到后端的各个不同业务处理函数，因此这种模式下仍然必须手工实现对消息的分发。而在HTTP+XML的方式中，也需要分发机制，然而却简洁很多。可以说，由于平白无故增加了基于XML通用远程调用层增加了性能消耗和处理复杂度，无比辛苦的把XML消息映射成具体平台相关的数据结构（这个映射耗费性能并且带来互操作性的问题）之后，还是需要做消息的分发，起点并没有比HTTP+XML高。
 

3、 一个WSDL文件能够适应所有情况的“银弹”。

WSDL文件本意是定义客户端与服务器端的消息约束文件。换成了通用的WSDL文件之后，WSDL文件无法告知服务器端能接收什么样的消息。例如update(propertyList list)，propertyList定义为KEY/Value的值对。这种接口客户端看了WSDL文件其实还是不知道服务器端能接收什么样的消息，它能接收什么的KEY NAME？每个KEY对应的Value是什么类型的数据？这一部分的信息接口完全没有涉及。因此仍然需要一个约束的文档描述具体的业务消息约束，在非通用的远程过程调用的场合，这个业务消息约束是WSDL，在HTTP+XML通信中，则可以定义成普通的XMLSCHEMA。

面向操作的开发模式中WSDL和具体语言的具体操作接口绑死，导致修改WSDL需要重新使用工具导出具体语言的接口。这个是SOAP实现的远程过程调用本身带来的问题，面向消息的处理机制中则从来没有这方面的问题。

4、 其他优缺点比较
a) 通用远程过程调用通信框架如果用SOAP实现则引入SOAP在不同平台下的互操作性的问题。为了最大限度的避免互操作性的问题，必须遵守WebService Base Profile 1.x系列标准，但是仍然不是彻底解决SOAP的互操作性问题。

b) 通用远程过程调用通信框架如果用SOAP实现则通信协议实际上是绑死了HTTP。上述第一类接口其实含有一个隐含的架构需求，数据的批量处理，和减少服务器之间的连接数。HTTP+XML业务数据的通信方式其实很容易移植到UDP+XML业务数据、TCP+XML业务数据和FTP+XML业务数据文件等批量数据快捷处理方式。SOAP协议虽然号称设计上预计在不同传输协议上传输，应用上却没有见过其他协议上成功应用。

c) HTTP+XML业务消息模式中XML处理实现上可以更灵活，XML数据处理可以使用通用的XML引擎，也可以在每个业务方法中使用XML PULL机制加速XML数据处理速度，XML PULL 资料可以参见http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/。

d)HTTP+XML业务消息中可以多个XML业务消息放到同一个HTTP请求中，减少连接数和通信量，而在通用的WSDL方案中，多个数据放到同一个HTTP消息中则导致一个庞大的XML消息，庞大的XML消息处理在还原成内存中的数据结构的时候很可能有占用太大的缓存的问题。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

1、SOAP数据传输样式介绍

SOAP 规范中style与use这两个属性决定SOAP数据的编码样式。

style属性可是两个值中的一个： rpc 或 document 。当属性被设定为文档样式时，客户端使用 XML 模式调用约定；当属性设置成RPC，客户端使用远程过程调用约定。

第一种RPC/Encoded曾在JAVA开发中应用非常广泛；第二种编码样式是DOT NET开发社区使用的缺省编码方式；第三种编码样式是第一种和第二种编码方式的混合，使用RPC的方式传送文档型数据。最近几年RPC/Encoded遭受了不少质疑和反对声浪。

在WS-I 基本概要1.1（WS-I Basic Profile Version 1.1）中，已经禁止使用这种编码样式。WS-I 基本概要1.1要求使用 WSDL SOAP 绑定的 RPC/literal 或 Document/literal形式。WS-I 基本概要禁止对 soap:Envelope 或派生的 soap:Body 元素使用 soap:encodingStyle 属性。因此， RPC/literal 和 Document/literal 是 WS-I 标准唯一支持的 2 种格式。引用原文如下：

R1007 An ENVELOPE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any element that is a grandchild of soap:Body.

为什么RPC/Encoded被抛弃？

2、RPC/Encoded的问题。

在RPC/Encoded中，SOAP 编码定义了一系列的编码规则，方便了从SOAP数据模型到 XML 的映射。编码规则非常灵活并支持图形数据和多态的表示，而Document/literal依赖于自然树结构来表示数据对象。

在SOAP编码中，使用SOAP 编码规则的多引用，引用可以很简单地表示，因此，循环引用如果采用 SOAP 编码作为消息绑定，可以表达一个循环的对象图。

在DOC/LIT中，方法基于 XML 脚本定义了消息类型作为固定类型。XML 脚本利用 XSD 基本类型作为叶子节点来表示自然树结构，一个循环对象图不能够转换为树结构。因此对象的引用必须在每一处对象引用中重复定义对象。

从上面的分析看来，无疑是RPC/Encoded更加有吸引力，事实上，很长一段时间来大部分 J2EE Web 服务缺省采用 RPC/encoded 方式。然而WS-I 基本概要（WS-I Basic Profile）为何抛弃这种编码样式呢？

当然这个不是程序员考虑的问题，各种WebService开发工具包屏蔽了SOAP编码方案的细节，呈现给程序员的，是面向接口编程熟悉的领域，然而却带来了处理的复杂性。有性能测试文章表明，RPC/ENC的样式实现的远程调用性能不佳，特别是随着XML消息payload的增大性能非线性下降，而DOC/LIT则能保持线性下降。

比起DOC/LIT，RPC/ENC样式下的SOAP协议栈除了单纯的XML处理之外，还要处理SOAP编码的逻辑，还原多引用的对象图。

对DOC/LIT的样式来说，是单纯的XML处理。应用定义WSDL文件，由应用本身进行解释，因此要简单快捷。

性能测试的相关文章如下：

http://dev2dev.bea.com/pub/a/2003/03/Cohen.html

http://www.ibm.com/developerworks/cn/webservices/ws-soapenc/index.html

三：Document/literal的好处。

1、更松散的客户端和服务器端耦合性

RPC样式，定义了SOAP客户端和服务器端之间的远程方法调用接口。该接口引用了抽象的SOAP数据类型，根据编码方案将SOAP数据模型转换成SOAP消息。客户端和服务器端的耦合度是远程过程调用的接口。

在Document样式，SOAP客户端与服务器端交互的是符合WSDL约束一段文本型数据。SOAP客户端与服务器端的契约或者说耦合度是仅仅WSDL描述的限制。

可以看出，Document样式中，客户端和服务器端的耦合性更低，远程过程调用必须是相对静态的，并且对接口的任何变化都将破坏服务和应用程序之间的契约。如果服务是广泛分布的，那么很可能大量的应用程序已经从它的 WSDL 文档中产生了存根代码。改变 WSDL 将会导致所有依赖于特定方法签名的应用程序被破坏。使用文档消息传递，规则更不严格，并且可以使 XML 模式得到显著增强和改变，同时又不会破坏调用应用程序。

2、充分利用XML的好处，包括自描述、自验证等

3、在异步调用的场合，由于文档消息通常是自包含的，因此适合于异步处理，可以直接放到服务器的队列中。

4、更好的互操作性

四：Document/literal模拟的RPC调用

在标准Document/literal 方式下，程序员不得不处理所有的事务，包括基于 XML 的 SOAP 消息的序列化和逆序列化。标准的Document/literal不是面向RPC的，也没有定义与远程调用相关的信息，对仍然酷爱RPC调用的开发者来说无疑是欠缺的，在SOAP工具开发者看来Document/literal标准方式主要是缺乏函数的方法名。

于是微软提出了使用Document/literal模拟RPC的方法调用，定义了一种用特殊的Document/literal使用方法，有名称叫做Document/literal wrapped。其实就是故意在WSDL中定义一个复杂类型complexType节点，该节点的名称与远程调用的方法名相同，该节点把发送的所有参数再封装一层。这样，SOAP的开发工具可以在接受到XML消息的时候根据节点上的方法名将XML消息处理后分发到具体的处理函数中。

为帮助理解，先看一段普通的Document/literal样式的WSDL 和SOAP消息。

这种编码样式，兼顾了Document/literal和RPC的好处，具有更好的跨平台互操作性，目前许多类库都是采用这种方案，例如，大名鼎鼎的XFIRE。当然，这个方案肯定也有一些问题。

参考资料：

http://www.eherenow.com/soapfight.htm

http://www.ibm.com/developerworks/cn/webservices/ws-tip-j2eenet1/index.html

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/?S_TACT=105AGX52&S_CMP=cn-a-ws

http://www.w3schools.com/schema/el_complextype.asp

http://www.ibm.com/developerworks/cn/webservices/ws-stand/part2/index.html

http://searchsoa.techtarget.com/ateQuestionNResponse/0,289625,sid26_cid494324_tax289201,00.html

http://www.ibm.com/developerworks/webservices/library/ws-docstyle.html?S_TACT=105AGX52&S_CMP=cn-a-ws

http://msdn2.microsoft.com/en-us/library/ms995710.aspx

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

        K(1) = hex(SHA-1(seed))
        K(2) = hex(SHA-1(K(1)))
        ...
        K(n) = hex(SHA-1(K(n-1)))

交互的XMPP消息流中 第一个消息包含newkey的属性，其值为第一个主键系列的值。
后续的客户端给服务器端发送的消息必须带上SID及key的值，每个key的值由前一个key的值计算而来。当循环用到最后一个key值
的时候，可以同时设置newkey的属性，开始新的一系列key值。
下面的交互过程从jwchat与openfire3.3.2的http-bind模块通信中截取。
xml 代码
 
Accept-Language: zh-cn  
Referer: http://191.1.11.56:8082/CIM/index.htm?jid=user1.org1&server=191.1.11.77&pass=123456&nickname=........  
Content-Type: text/xml; charset=utf-8  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)  
Host: 191.1.11.77:8080  
Content-Length: 151  
Connection: Keep-Alive  
Cache-Control: no-cache  
  
<body hold='1' xmlns='http://jabber.org/protocol/httpbind' to='191.1.11.77'   
wait='300' rid='803757' newkey='b543ff6c4c105dba31d70c6f1c7304ed7bece24b'/>  
Server返回一个SID，并给出认证的选择。
xml 代码
 
HTTP/1.1 200 OK  
Content-Type: text/xml; charset=utf-8  
Content-Length: 662  
Server: Jetty(6.1.x)  
  
  
  
<body xmlns="http://jabber.org/protocol/httpbind" 
xmlns:stream="http://etherx.jabber.org/streams" 
authid="1fc3b503" sid="1fc3b503" secure="true" 
requests="2" inactivity="30" polling="0" wait="10">
<stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">  
<mechanism>DIGEST-MD5mechanism>  
<mechanism>JIVE-SHAREDSECRETmechanism>  
<mechanism>PLAINmechanism>  
<mechanism>ANONYMOUSmechanism>  
<mechanism>CRAM-MD5mechanism>mechanisms>  
<compression xmlns="http://jabber.org/features/compress">
<method>zlibmethod>compression>
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
<session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>stream:features>body>  
下面是客户端发送认证

请求。digest的值为sha1(sid + password)
xml 代码
 
POST /http-bind/ HTTP/1.1  
Accept: */*  
Accept-Language: zh-cn  
Referer:http://191.1.11.56:8082/CIM/index.htm?jid=user1.org1&server=191.1.11.77&pass=123456&nickname=........  
Content-Type: text/xml; charset=utf-8  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)  
Host: 191.1.11.77:8080  
Content-Length: 346  
Connection: Keep-Alive  
Cache-Control: no-cache  
  
<body rid='803759' sid='1fc3b503' xmlns='http://jabber.org/protocol/httpbind'   
key='aabcfc3ad7a327fa9542da51b24d024361d4b6f1' >  
<iq xmlns="jabber:client" type="set" id="auth2">  
<query xmlns="jabber:iq:auth">  
<username>user1.org1username>  
<resource>............resource>  
<digest>33f2e458193401a8eb12443b0f459c16079463d9digest>query>iq>  
body>  
xml 代码
 
HTTP/1.1 200 OK  
Content-Type: text/xml; charset=utf-8  
Content-Length: 136  
Server: Jetty(6.1.x)  
  
<body xmlns='http://jabber.org/protocol/httpbind'>
<iq type="result" id="auth2" to="user1.org1@domainname/............"/>
body>  
认证结束，客户端发送呈现的消息流，查询用户的状态
xml 代码
 
POST /http-bind/ HTTP/1.1  
Accept: */*  
Accept-Language: zh-cn  
Referer:http://191.1.11.56:8082/CIM/index.htm?jid=user1.org1&server=191.1.11.77&pass=123456&nickname=........  
Content-Type: text/xml; charset=utf-8  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)  
Host: 191.1.11.77:8080  
Content-Length: 266  
Connection: Keep-Alive  
Cache-Control: no-cache  
  
<body rid='803761' sid='1fc3b503' xmlns='http://jabber.org/protocol/httpbind' 
key='d32ea55815de2c52f1b736080a79825cc227e09d' >
<iq xmlns="jabber:client" type="get" id="jwchat_state">
<query xmlns="jabber:iq:private"><jwchat xmlns="jwchat:state"/>query>iq>  
body>  
查询状态返回：
xml 代码
 
HTTP/1.1 200 OK  
Content-Type: text/xml; charset=utf-8  
Content-Length: 265  
Server: Jetty(6.1.x)  
  
<body xmlns='http://jabber.org/protocol/httpbind'>
<iq type="result" id="jwchat_state" to="user1.org1@domainname/............">
<query xmlns="jabber:iq:private">
<jwchat xmlns="jwchat:state">
<presence>availablepresence>
<onlmsg/>
jwchat>query>iq>body>  
发布呈现信息
xml 代码
 
POST /http-bind/ HTTP/1.1  
Accept: */*  
Accept-Language: zh-cn  
Referer: http://191.1.11.56:8082/CIM/index.htm?jid=user1.org1&server=191.1.11.77&pass=123456&nickname=........  
Content-Type: text/xml; charset=utf-8  
Accept-Encoding: gzip, deflate  
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)  
Host: 191.1.11.77:8080  
Content-Length: 620  
Connection: Keep-Alive  
Cache-Control: no-cache  
  
<body rid='803763' sid='1fc3b503' xmlns='http://jabber.org/protocol/httpbind'
key='192ed9480229081924997e91a275411df3bdfb0f' >
<presence xmlns="jabber:client"><priority>10priority>presence>  
<iq xmlns="jabber:client" to="191.1.11.77" type="get" id="disco_item_1">
<query xmlns="http://jabber.org/protocol/disco#items"/>iq>
<iq xmlns="jabber:client" type="get" id="storage_bookmarks">
<query xmlns="jabber:iq:private"><storage xmlns="storage:bookmarks"/>query>iq>  
<iq xmlns="jabber:client" type="get" id="jwchat_notes">
<query xmlns="jabber:iq:private"><storage xmlns="storage:rosternotes"/>query>iq>
body>  
返回
xml 代码
 
HTTP/1.1 200 OK  
Content-Type: text/xml; charset=utf-8  
Content-Length: 201  
Server: Jetty(6.1.x)  
  
<body xmlns='http://jabber.org/protocol/httpbind'>
<presence from="user1.org1@domainname/............" 
to="user1.org1@domainname/............"><priority>10priority>
presence>body>  

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师

-Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

6)可能的问题原因分析：JCONSOLE连接上监控的进程，从监控进程下载了RMI远程调用的STUB文件？该STUB访问服务器的进程，
服务器端的地址可能是通过hostname -i类似机制获得。

• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

系统架构：

在架构中，连接管理器（Connection Manager）与 Server之间是原始的数据流（在XMPP的协议中就是XMPP的数据流），HTTP客户端与连接管理器之间是HTTP协议以及Body的TAG封装的数据流。

流程描述：

BOSH技术能够同时减小网络带宽和减小客户端响应的时间。其方案是对客户端的请求连接管理器不给于返回直到数据已经就绪，当客户端收取连接管理器返回的数据会向连接管理器发送下一个请求，于是连接管理器总是保持着一个客户端的请求，当服务器端数据就绪的时候，可以将数据封装在请求的响应包中，“推送”给客户端。

连接大不了多少。

由于大多数的客户端不支持HTTP的Pipeling（单一的连接上承载并发的请求），于是，客户端必须从第二条HTTP连接发送消息。当第二条HTTP连接有新的请求发送的时候，连接管理器将第一条连接中的请求返回，即便此时第一条连接中的返回的是空数据包。这样做的原因是让客户端有需要的话可以发送新的请求过来。客户段同一时间最多只能保持两条HTTP连接，否则的话，客户端必须等待旧的请求处理完之后才能发送新的请求

在网络经常中断的环境下，BOSH退化成每个数据请求一个新HTTP连接。然而，在通常情况下，网络环境良好，客户端可以使用http/1.1,这个时候，一个Session包含两个TCP长连接，所有的请求都在这两个长连接上传输。基本上任何时候，客户端通过一条连接能够推送数据到服务器，与此同时，服务器端可以“推送”数据到客户端。值得注意的是，这两条长连接的角色在客户端每发送一次请求则角色转换一次。

 尽管大多数时间可以随时推送数据到对端，但是，如果一方刚刚推送完数据，则需要等一个网络来回的时间才能推送下一个数据

• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师

1、用户通过浏览器登陆集成的门户

2、集成的门户返回页面，用户选择外域提供的功能链接

3、链接发送到跨域接口模块

4、跨域接口模块解密藏在cookie中的集成门户颁发的登陆票，获取userid，跨域接口模块生成一个重定向到外域应用门户网页，并将用户ID及本域服务器身份认证信息放置到自动提交的隐藏表单中。隐藏表单的提交地址是外域的页面地址

5、跨域接口模块把网页返回给浏览器，浏览器自动提交隐藏表单，请求发送外域WEB服务器。外域服务器登陆用户。

特点：

1、后续请求不过跨域接口模块，直接与外域WEB服务器连接

2、对同一个用户，本域WEB服务器与外域WEB服务器维护的是独立的两个COOKIE，有独立的超时时间。本域应用用户logout后，外域应用会话有可能还存活。

3、基于安全考虑，本域的传递到外域服务器的信息可以进行加密。

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。

• Oracle专区上线，有Oracle最新文章，重要下载及知识库等精彩内容，欢迎访问。
• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 快来参加7月17日在成都举行的SOA中国技术论坛
• JavaEye问答大赛开始了！ 从6月23日 至 7月6日，奖品丰厚 ！
• 搜狐网站诚聘Java、PHP和C++工程师

1、XCAP协议的简介

       XCAP（XML Configuration Access Protocol，XML配置访问协议），也称XML配置接入协议。它是IETF制定的一个协议，前面陆续发布了一系列草案，于2007年5月正式成为RFC规范（RFC 4825）。

       该协议允许客户端读、写、修改存放在服务器中的XML格式的应用配置数据。XCAP将XML文档中的节点映射到HTTP URIs中，使得这些组件能够直接通过HTTP访问。

2、XCAP协议的应用场合

       多个应用和服务之间共享好友列表（Buddy Lists）

       多个应用和服务之间共享安全策略（Authorization Policies）

       多个应用和服务之间共享呈现数据（Presence List）

开放移动联盟（OMA）定义的文档管理服务器（XDMS）结构中，其中的XDM3和XDM4接口是XCAP协议。

3、XCAP的 URI的组成

XCAP的URI映射分成两个部分：文档选择器（Document selector）与节点选择器(Node selector )，�