XML——这种用于表示客户端与服务器间数据交换有效负载的格式，几乎已经成了Web services的同义词。然而，由于Ajax和REST技术的出现影响了应用程序架构，这迫使人们开始寻求`XML的替代品，如：JavaScript Object Notation（JSON）。

　　JSON 作为一种更轻、更友好的 Web services客户端的格式（多采用浏览器的形式或访问 REST风格 Web服务的Ajax应用程序的形式）引起了 Web 服务供应商的注意。

　　本文将阐述JSON在Web services设计中备受推崇的原因，以及它作为XML替代方案的主要优势和局限性。文中还会深入探讨：随着相应的Web 服务客户端选择使用JSON，如何才能便捷地在Java Web services中生成JSON输出。

XML的十字路口: 浏览器和 Ajax

　 　XML设计原理已经发布了将近十年。时至今日，这种标记语言已经在广阔的软件应用领域中占据了主导地位。从Java、.NET等主流平台中的配置和部署 描述符到应用集成场景中更复杂的应用，XML与生俱来的语言无关性使之在软件架构师心目中占据着独特的地位。但即便最著名的XML权威也不得不承认：在某 些环境中，XML的使用已经超出了它自身能力的极限。

　　围绕Ajax原理构建的那些Web应用程序最能说明XML的生存能力，从这一点来 看，一种新的有效负载格式的发展壮大也得益于XML。这种新的有效负载格式就是JavaScript Object Notation (JSON)。在探索这种新的标记语言的复杂性之前，首先来分析一下在这种独特的设计形式中，XML具有哪些局限性。

　　Ajax建立了一 个用于从远程Web services发送和接收数据的独立信道，从而允许Web程序执行信道外（out-of-band）客户端/服务器调用。通俗地说，Ajax程序中的更 新和导航序列在典型的客户端/服务器环境之外完成，在后台（即信道外）接受到信息后，必须进行一次完整的屏幕刷新。更多背景信息，请参阅David Teare的 Ajax简介（Dev2Dev）。

　 　这些应用程序更新通常是通过REST风格（RESTful）Web services获得的，一旦被用户的浏览器接收到，就需要整合到HTML页面的总体布局之中，这正是XML发挥强大力量的场合。尽管近年来，脚本语言支 持和插件支持已使大多数主流浏览器的功能得到了强化，但许多编程任务依然难于开展，其中之一就是操纵或处理文本，这通常是使用DOM实现的。

　 　采用DOM的复杂性源于其基于函数的根，这使得对数据树的简单修改或访问都需要进行无数次方法调用。此外，众所周知，DOM在各种浏览器中的实现细节不 尽相同，这一过程将带来极为复杂的编程模式，其跨浏览器兼容性出现问题的可能性极大。接下来的问题显而易见，那就是：如何使一种标记语言轻松集成到 HTML页面中以满足Ajax的要求？

　　问题的答案就是：利用所有主流浏览器中的一种通用组件——JavaScript引擎。XML需要 使用DOM之类的机制来访问数据并将数据整合到布局之中，采用这种方法，我们不再使用像XML这样的格式来交付Ajax更新，而是采用一种更为简单直观的 方式，采用JavaScript引擎自然匹配的格式——也就是JSON。

　　既然已经明确了JSON与XML和Ajax之间的关系，下面将进一步探讨JSON背后的技术细节。

JSON剖析：优点和不足

　 　对于JSON，首先要明白JSON和XML一样也是一种简单文本格式。相对于XML，它更加易读、更便于肉眼检查。在语法的层面上，JSON与其他格式 的区别是在于分隔数据的字符，JSON中的分隔符限于单引号、小括号、中括号、大括号、冒号和逗号。下图是一个JSON有效负载：

				{"addressbook": {"name": "Mary Lebow",       "address": {           "street": "5 Main Street"           "city": "San Diego, CA",           "zip": 91912,       },       "phoneNumbers": [           "619 332-3452",           "664 223-4667"       ] }}		

　　将上面的JSON有效负载用XML改写，如下：

				<addressbook> <name>Mary Lebow</name> <address>        <street>5 Main Street</street>       <city zip="91912"> San Diego, CA </city>       <phoneNumbers>         <phone>619 332-3452</phone>         <phone>664 223-4667</phone>       </phoneNumbers> </address></addressbook>		

　　是不是很相似？但它们并不相同。下面将详细阐述采用JSON句法的优点和不足。

优点

　　乍看上去，使用JSON的数据分隔符的优点可能并不那么明显，但存在一个根本性的缘由：它们简化了数据访问。使用这些数据分隔符时， JavaScript引擎对数据结构（如字符串、数组、对象）的内部表示恰好与这些符号相同。

　　这将开创一条比DOM技术更为便捷的数据访问途径。下面列举几个JavaScript代码片段来说明这一过程，这些代码片段会访问先前的JSON代码片段中的信息：

• 访问JSON中的名称： addressbook.name
• 访问JSON中的地址： addressbook.address.street
• 访问JSON中的电话号码第一位：addressbook.address.phoneNumbers[0]

　　如果您具备DOM编程经验，就能很快地看出区别；新手可以参看 Document Object Model 的这一外部资源，这里提供了关于数据导航的实例。

　 　JSON的另一个优点是它的非冗长性。在XML中，打开和关闭标记是必需的，这样才能满足标记的依从性；而在JSON中，所有这些要求只需通过一个简单 的括号即可满足。在包含有数以百计字段的数据交换中，传统的XML标记将会延长数据交换时间。目前还没有正式的研究表明JSON比XML有更高的线上传输 效率；人们只是通过简单的字节数比较发现，对于等效的JSON和XML有效负载，前者总是小于后者。至于它们之间的差距有多大，特别是在新的XML压缩格 式下它们的差距有多大，有待进一步的研究。

　　此外，JSON受到了擅长不同编程语言的开发人员的青睐。这是因为无论在Haskell中或 Lisp中，还是在更为主流的C#和PHP中，开发都可以方便地生成JSON（详见 参考资料）。

不足

　 　和许多好东西都具有两面性一样，JSON的非冗长性也不例外，为此JSON丢失了XML具有的一些特性。命名空间允许不同上下文中的相同的信息段彼此混 合，然而，显然在JSON中已经找不到了命名空间。JSON与XML的另一个差别是属性的差异，由于JSON采用冒号赋值，这将导致当XML转化为 JSON时，在标识符（XML CDATA）与实际属性值之间很难区分谁应该被当作文本考虑。

　　另外，JSON片段的创建和验证过程比一般的XML稍显复杂。从这一点来看，XML在开发工具方面领先于JSON。尽管如此，为了消除您对这一领域可能存在的困惑，下节将介绍一些最为成熟的JSON开发。

从Web services生成JSON输出

　 　既然JSON的首要目标是来自浏览器的信道外请求，那么我们选择REST风格（RESTful）Web服务来生成这些数据。除了用典型业务逻辑探究 Web服务之外，还将采用特定的API把本地Java结构转化为JSON格式（详见 参考资料）。首先，下面的Java代码用来操纵Address对象：

// Create addressbook data structureSortedMap addressBook = new TreeMap();// Create new address entries and place in Map // (See download for Address POJO structure)Address maryLebow = new Address("5 Main Street","San Diego, CA",91912,"619-332-3452","664-223-4667"); addressBook.put("Mary Lebow",maryLebow);Address amySmith = new Address("25 H Street","Los Angeles, CA",95212,"660-332-3452","541-223-4667"); addressBook.put("Sally May",amySmith);Address johnKim = new Address("2343 Sugarland Drive","Houston, TX",55212,"554-332-3412","461-223-4667"); addressBook.put("John Kim",johnKim);Address richardThorn = new Address("14 68th Street","New York, NY",,12452,"212-132-6182","161-923-4001"); addressBook.put("Richard Thorn",richardThorn);

　　该Java结构在哪里生成并不重要（可能是在JSP、Servlet、EJB或POJO中生成），重要的是，在REST风格Web 服务中有权使用这些数据。如下示：

				// Define placeholder for JSON responseString result = new String();// Get parameter (if any) passed into application String from = request.getParameter("from");String to = request.getParameter("to");try {        // Check for parameters, if passed filter address book        if(from != null && to != null) {          // Filter address book by initial          addressBook = addressBook.subMap(from,to);       }       // Prepare the convert addressBook Map to JSON array       // Array used to place numerous address entries       JSONArray jsonAddressBook = new JSONArray();       // Iterate over filtered addressBook entries       for (Iterator iter = addressBook.entrySet().iterator(); iter.hasNext();)     {         // Get entry for current iteration                   Map.Entry entry = (Map.Entry)iter.next();        String key = (String)entry.getKey();        Address addressValue = (Address)entry.getValue();        // Place entry with key value assigned to "name"         JSONObject jsonResult = new JSONObject();        jsonResult.put("name",key);        // Get and create address structure corresponding to each key         // appending address entry in JSON format to result         String streetText = addressValue.getStreet();        String cityText = addressValue.getCity();        int zipText = addressValue.getZip();        JSONObject jsonAddress = new JSONObject();        jsonAddress.append("street",streetText);        jsonAddress.append("city",cityText);        jsonAddress.append("zip",zipText);        jsonResult.put("address",jsonAddress);        // Get and create telephone structure corresponding to each key         // appending telephone entries in JSON format to result         String telText = addressValue.getTel();        String telTwoText = addressValue.getTelTwo();        JSONArray jsonTelephones = new JSONArray();        jsonTelephones.put(telText);        jsonTelephones.put(telTwoText);        jsonResult.put("phoneNumbers",jsonTelephones);        // Place JSON address entry in global jsonAddressBook         jsonAddressBook.put(jsonResult);      } // end loop over address book         // Assign JSON address book to result String             result = new JSONObject().put("addressbook",jsonAddressBook).toString();     } catch (Exception e) {         // Error occurred              }		

　 　为了便于说明，我们已将这段代码将置入JSP（restservice.jsp)中。如果它真是一段程序，那么类似这样的代码也会出现在servlet 或helper类中。 REST风格Web服务首先提取两个通过URL请求传递给它的输入参数，根据这些值过滤现有的地址簿以适应请求。过滤过地址簿后，即可开始循环检查 Java映射中的每个条目。

　　您会注意到，在循环内部，json.org API被广泛用于将本地Java格式转化为JSON字符串。虽然仅使用了少量类（即JSONArray和JSONObject），但API提供的转换方法 相当广泛，甚至能将XML结构转换成JSON输出。但回到我们的Web服务，一旦循环遍历了所有条目，那么变量“result”会包含准备返回给请求方的 地址簿的JSON同等部分。

　　既然已经生成了JSON输出，下面来看看等式的另一边：浏览器应用程序中JSON有效负载的使用。

JSON有效负载的使用

　 　作为基于浏览器的客户端，我们的设计中大部分工作都是在HTML、JavaScript加上附加的JavaScript 框架下完成的。例如利用Prototype库轻松创建跨浏览器样式的Ajax调用。下面的清单包含了我们的应用程序的第一部分，以及相应的 JavaScript函数。

				<html> <head> <title> JSON Address Book </title> <script type="text/javascript" src="prototype-1.4.0.js"></script> <script type="text/javascript"> // Method invoked when user changes letter rangefunction searchAddressBook() {     // Select values from HTML select lists     var fromLetter = $F('fromLetter');     var toLetter = = $F('toLetter');     // Prepare parameters to send into REST web service     var pars = 'from=' + fromLetter + '&to=' + toLetter;     // Define REST web service URL      var url = 'restservice.jsp';     // Make web service Ajax request via prototype helper,      // upon response, call showResponse method         new Ajax.Request( url, { method: 'get', parameters: pars,                               onComplete: showResponse });}</script> </head>		

　 　首先导入了prototype库，该库用于促进对REST风格Web服务的Ajax调用。接下来是searchAddressBook()函数，当用户 修改其下所示的HTML选择列表时，将会触发此函数。该函数被触发后，用户将会获得HTML选择列表中已选中的选项，并将其放入两个用于过滤地址簿的变量 中，随后定义一个指向REST风格服务URL restservice.jsp的附加变量。

　　此方法中还包括借助原型函数new Ajax.Request( url, { method: 'get', parameters: pars, onComplete: showResponse }); 的实际Ajax Web服务调用；表明了对相关URL的一个请求，其请求参数包含在pars中；最后一旦Ajax请求终止，即执行showResponse()。

　　下面以showResponse()为例说明用于评估JSON有效负载并将其放入HTML主体布局环境中的的必要代码。

				// Method invoked when page receives Ajax response from REST web service function showResponse(originalRequest) {      // Get JSON values       jsonRaw = originalRequest.responseText;      // Eval JSON response into variable       jsonContent = eval("(" + jsonRaw + ")");      // Create place holder for final response             finalResponse = "<b>" + jsonContent.addressbook.length +                       " matches found in range</b><br/>";      // Loop over address book length.      for (i = 0; i < jsonContent.addressbook.length; i++) {           finalResponse += "<hr/>";           finalResponse += "<i>Name:</i> " + jsonContent.addressbook[i].name + "<br/>";                        finalResponse += "<i>Address:</i> " + jsonContent.addressbook[i].address.street + " -- " +                              jsonContent.addressbook[i].address.city + "," +                                           jsonContent.addressbook[i].address.zip + ".<br/>";                        finalResponse += "<i>Telephone numbers:</i> " + jsonContent.addressbook[i].phoneNumbers[0] + " & " +            jsonContent.addressbook[i].phoneNumbers[1] + ".";                   }      // Place formatted finalResponse in div element      document.getElementById("addressBookResults").innerHTML = finalResponse; }		

　 　此方法的输入参数是REST风格Web服务在调用时返回的响应。既然预先已经知道需要处理JSON字符串，那么可以利用JavaScript eval()函数，将这个JSON字符串放入内存，并允许数据访问，正是这样的简便性促使开发人员使用JSON。完全不需要进行解析，一个简单的eval ()即可得到JavaScript结构，我们可以像操纵其他任何JavaScript结构一样地去操纵它。

　　一旦JSON响应经过 eval处理，将创建一个JavaScript循环来提取每个地址条目，并将各个匹配项放入一个名为finalResponse的容器变量中。而这个容器 变量本身包含所有必要的格式，用于在页面布局中显示最终地址簿。循环结束时，匹配项也通过document.getElementById ("addressBookResults").innerHTML放置完毕。

　　最后，为了保持完整，页面的实际布局由这些代码组成：

				<body> <h4 style="text-align:left">Request address book matches:</h4><table style="text-align:left" cellpadding="15"><tr><td valign="top">From:<br/><select id="fromLetter" size="15" onchange="searchAddressBook()"> <option>A</option> ... <option>Z</option></select></td><td valign="top">To:<br/><select id="toLetter" size="15" onchange="searchAddressBook()"> <option>A</option> ... <option>Z</option></select></td><td valign="top"><h5> Results </h5> <div style="text-align:left" id="addressBookResults">Please select range</div></td></tr></table></body> 		

　 　上面的代码清单中最值得一提的是HTML选择列表，因为修改触发器Java程序需要调用信道外Ajax请求。其次，<div>元素就是放置 格式化后的JSON响应的地方。                                                                           

JSON适合您吗

　　就像在软件设计中编程语言的选择一样，JSON的选择与否取决于您自身的需求。如果Web services使用者将 在传统、功能完备的编程环境（如Java 、.NET、PHP、Ruby等）中创建，那么完全可以不使用JSON。给定大多数编程语言环境的无限制能力可提供完整的配置控制权（更不必说对定制库、 分析器或helper类的访问），那么JSON与XML及其他Web services有效载荷之间的差别可以忽略不计。

　　反之，如果Web services使用者被 限制在浏览器环境之外，那么JSON是值得认真考虑的对象。 在浏览器中使用Web services并非兴趣使然，而是实际业务需求。如果这时需要一个加载数据时不会出现延迟/刷新的“漂亮的Web 2.0界面”， 就不得不在浏览器中嵌入Ajax和Web services技术。

　　在这种情况下，您不仅受限于通过网络访问处理环境，而且还会受到随机用户的限制，迫使经验丰富的开发人员用最普遍的工具在浏览器中处理文本，例如：前述的DOM，与访问JSON树相比，DOM使用起来非常困难。

示例代码

　　您可下载与本文相关的代码。

• json_addressbook.zip ——示例代码和实用工具

　 　安装之前先解压下载得到的文件，将addressbook.html,prototype-1.4.0.js和restservice.jsp放入任意 程序的目录下。将内含的json.jar复制到所选程序的/WEB-INF/lib目录下。访问<yourhost>/< yourappdir>/addressbook.html，并在HTML列表中进行选择。一切就绪，可以运行JSON了！

结束语

　　尽管 “Ajax”中的“x”代表XML，Web services也通过坚持使用XML格式而成为主流，但这并不意味着这种方式无懈可击。在文本处理方面，XML在Ajax程序的应用中已经暴露出一些缺点。在这种情形下，JSON逐渐成为引人注目的XML替代方案。

　 　通过对JSON语法优缺点的论述，以及对如何从REST风格Web services创建JSON输出、如何将其嵌入Web页面布局等问题的介绍，您现在应该能够为最终用户提供支持JSON的Web services，接触当前提供的大量利用这一极具前途的格式的Web services。

参考资料

• Ajax简介（David Teare，Dev2Dev，2005年8月）——介绍Ajax的相关技术背景
• JSON in Java ——介绍使用Java API将本地Java结构转换成JSON输出
• Prototype ——介绍用于创建Ajax应用程序的JavaScript框架
• JSON.org ——JSON主页，其中包含可生成JSON的各种语言库的资源和链接

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=2036870

摘自：http://www.cnblogs.com/fanjunhan/articles/57760.html

如果William Vambenepe愿意承认这种新型基础设施所声称的：

• “灵活性” （感谢OSGi）

• “可测试性”（感谢Spring）

• “可重用性” （感谢SCA）

那么他不太同意白皮书作者的观点，表现在：

• “简单性”……除非你是一少部分对所有三种工具都有涉猎的人之一。

• “可管理性”，让我们称之为“可管理潜力”，并保持友好。
  

SOA似乎正将一些单块（monolithic）应用模型的复杂性推给了管理和运营。这是你得以实现、部署、伸缩或者保护你解决方案的每个独立部分所必须付出的代价。

William在他更早的一篇文章里对SCA在可管理性上的影响做了评论：

我看到了SCA的另一个优势：它是机器可读的组合应用的逻辑的描述，并位于一个对应用和服务管理有用的粒度层次。

与SCA[类似]，BPEL不是针对可管理性而设计的。它更多定位于提高生产力、可移植性以及灵活性。[……] 它还提供了对应用管理非常有用的元数据。无论是从突显应用流程（通过活动），还是从阐明依赖和关联策略（通过伙伴链接）的方面来说。

SCA，OSGi 和 Spring 还有助于填补那个空白。它们提供额外的应用元数据，这些元数据可以被应用管理工具用来给管理任务提供更多的应用上下文。

在这篇对OSGi进行了广泛介绍的白皮书里，作者指出：

OSGi服务平台是专为那些能够无人值守操作或者在一个平台操作员的控制下操作的设备而设计的。这些就是需要远程管理的设备。

远程管理设备需要一个协议。选择一个适当的协议很困难，因为有太多的选择，包括SNMP、CMISE、CIM、OMA DM或者其它协议。

OSGi联盟决定不优先选择其中一个协议而否定其它的，因为没有一种协议能够适合各种情况。因此OSGi联盟选择了一个体系结构，其提供了一个能够 被一个经过授权的Bundle使用的管理API。这时，这个经过授权的Bundle就能够扮演一个管理Bundle，在这里Bundle将一个协议映射到 API调用上。

事实上，西班牙的马德里综合技术大学（Universidad Politécnica de Madrid）的电讯工程系（Departamento de Ingeniería Telemática）已经为OSGi服务平台开发出了一个叫做JMood的基于JMX的管理代理。

结尾，William提出了一些注意事项：

虽然这一切很令人兴奋，不过我们中的一些人还想知道，这样冒着风险将这些规范过于紧密的衔接到一起是不是太早了。我见过太多这种“标准框架”的powerpoint幻灯片，来展示一系列开发中的规范能够如何如何准确地协同工作来满足世界的所有需求。

查看原文：Enhanced Manageability with OSGi, SCA, BPEL and Spring

<Resource name="jdbc/student" auth="Container" type="javax.sql.DataSource" />
<ResourceParams name="jdbc/student">
  <parameter>
    <name>factory</name>
    <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
  </parameter>
  <parameter>
    <name>username</name>
    <value>root</value>
  </parameter>
  <parameter>
    <name>password</name>
    <value>sa</value>
  </parameter>
  <parameter>
    <name>driverClassName</name>
    <value>com.mysql.jdbc.Driver</value>
  </parameter>
  <parameter>
    <name>url</name>
    <value>jdbc:mysql:// localhost:3306/student?useUnicode=true&amp;characterEncoding=UTF-8</value>
  </parameter>
  <parameter>
    <name>maxActive</name>
    <value>20</value>
  </parameter>
  <parameter>
    <name>maxIdle</name>
    <value>5</value>
  </parameter>
  <parameter>
    <name>maxWait</name>
    <value>10000</value>
  </parameter>
</ResourceParams>

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null'

解决方法：
其实在5.5的文档里面，已经给出了配置的标准写法。将数据源修改为如下格式即可

<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"
   maxActive="100" maxIdle="30" maxWait="10000"
   username="javauser" password="javadude" driverClassName="com.mysql.jdbc.Driver"
   url="jdbc:mysql://localhost:3306/javatest?autoReconnect=true"/>

　　Gartner、IDC、Forrester等公司的分析师们认为，企业级软件在2008年将会有不小的变化，这些变化包括软件供应商之间的联盟、软件的定价策略以及软件本身的创新等。

　　这种变化的很大一部分原因在于，人们对2008年经济形势的不乐观估计将会影响企业的IT预算和CIO可以支配的资金。由于很多人对今年的 经济形势并不看好，因此，CIO们普遍面临更大的压力，新的一年里他们需要以更小的投入获得更大的回报。而对CIO而言，企业的核心应用软件和软件平台自 然是落实这种回报的重点。

　　“全球化、快速变化的市场、员工的变动以及新规定的出台使得企业对软件的灵活性和可用性要求越来越高，” Forrester公司业务流程和应用软件研究经理Sharyn Leaver说，“结果，从事流程和应用软件开发的公司就不得不提供更加灵活、好用的软件。”

　　不仅如此，Gatner研究副总裁Jeff Woods补充说，来自业务方面的压力也越来越大，业务人员希望企业的应用软件能够给企业带来实实在在的回报。同时，通过采用各种最新的技术(如SOA) 可以为企业提供更加可靠的计算环境，这使得CIO的决策对企业的未来发展越来越重要。

　　对于企业CIO来说，2008年以下6个趋势值得关注，这些趋势将对CIO的未来决策产生重要影响。

　　趋势1:

　　软件公司继续兼并

　　过去的一年可以说是软件企业的并购重组之年，IBM并购了Cognos，Oracle买下了Hyperion、SAP吃下了Business Objects，惠普买下了Opsware，微软买下了多个软件企业。SAP、Oracle、IBM、微软等软件巨头们之所以投入了数十亿美元来购买那些 稍小一些的竞争对手，只因为这些企业开发出了它们非常急需的某些软件或者某些功能。

　　那么，CIO们应该如何看2008年的软件市场呢?技术咨询公司451集团(451 Group)去年年底进行的一项调查显示，软件界的人士普遍预计2008年还会有更多的并购事件发生。那些最近一年内并购了其他公司的决策者有85%以上 的人认为，今年的并购次数将保持甚至超过去年。调查还显示，有一半以上大型软件企业在并购方面的预算将增加。451集团进行的这项研究访问了那些在过去的 5年内进行过并购的公司中的开发和战略决策人士，这些公司5年内总计投入了1500亿美元并购了500多家企业。其中只有不到10%的人认为今年购并次数 将减少。

　　杜克(Duke)大学和《CFO》杂志进行的一项调查也显示，40%的美国公司计划在2008年购买一些其他公司的资产，其中，1/3的公司计划购买一家或者几家公司，22%的公司计划从其他公司中购买一部分但不是整个公司。

　　Forrester的Leaver说，她预测2008年将会有更多的并购事件发生，并购的对象将主要是那些行业特征非常明显的、专注在特定领域 的软件公司。她说:“我想这些并购的影响不会再像2007年那么大，因为去年被并购的都是一些较大的公司，而现在这样的公司市场上剩下的已不多了。”

　　趋势2:

　　软件生态链将重组

　　作为一系列兼并事件之后的必然结果，市场上中等规模和大型的软件公司越来越少(当然，这是相对而言)，可供CIO们选择的合作对象也越来越少。 而对那些软件巨头们来说，它们的创新和未来成功将越来越依赖于它们与其他小软件公司、合作伙伴和开发者社区的关系。因为，尽管表面上看CIO可以购买 SAP或者Oracle的套装软件，而实际上，CIO会花很多时间来考虑SAP或者Oracle各自的生态链上都有哪些公司、它们都提供哪些产品以及这些 产品是否与企业技术战略一致?

　　“ERP系统本质上只是一个软件平台，生态链上的其他公司围绕这个平台提供产品和服务，”Gartner的Wood说，“这是今天的CIO必须认识到的一点，未来这一点还会越来越明显。”

　　Forrester的Leaver强调说，以往CIO在应用软件的购买上只是被动地受几个软件巨头的推动，而今天，CIO必须认真考虑哪个供应 商的生态链能更适合自己公司的长期战略。这一点非常关键，因为如果软件供应商的生态链中已有某个行业应用软件(如零售行业)能满足你的长期需要，你在部署 这样的软件时无疑将容易得多，也更容易将此类杀手级的应用集成到你的ERP系统中。

　　Wood说，软件巨头们都有各自不同的产品开发计划和发展战略，比如，Oracle倾向于购买或者自己开发行业软件(如零售行业和通信行业的软件)，而SAP更愿意开放自己的平台给合作伙伴，让它们来开发这些杀手级的应用。

　　“CIO们一定不能忽视围绕软件巨头形成的生态链。请记住，没有杀手级应用，光有一个软件平台肯定无法长久存在。” Wood说。

　　趋势3:

　　激烈竞争仍将延续

　　尽管企业级应用软件市场的竞争从来都是非常激烈的，但是2008年CIO们将看到软件供应商们在这个市场进行更为激烈的争夺。

　　“目前，我们还看不出这个领域的竞争有丝毫减缓的迹象，”Wood说，“这对CIO们来说应该算一个好消息。”

　　虽然软件供应商通过自己开发或者并购，积累了越来越丰富的行业经验和提供更多的技术平台，从而提高了自己的盈利能力，但是在这些领域仍然有不少 竞争对手，因为这一行业仍然有比较丰厚的利润。因此，对于CIO来说，不要害怕用一家软件商来牵制另一家，以帮助自己在合同的谈判中争取到更有利的价格。

　　“供应商们现在也越来越聪明，它们知道什么时候该竞争、什么时候该合作、哪些值得竞争、哪些不值得竞争。”Woods说，如果你认为价格值得认真协商，那今年就应该能够尽力得到一个满意的价格。

　　另外，Forrester首席分析师Ray Wang补充说，由于这些公司间的并购刚刚宣布或者宣布不久，因此现在是一个非常好的时机，可以和这些公司订立一个长期的价格非常优惠的软件维护合同，或 者以一个非常优惠的折扣购买新的软件模块。“根据过去的经验，在公司宣布正式被收购后，其销售人员通常会在公司的最后这一点时间内为客户提供一些非常优惠 的合同。”趋势4:

　　小公司更注重创新

　　软件巨头们并不是因创新而知名的，而更小些的软件企业必须靠创新赢得在这个市场上的生存机会。

　　Leaver 说: “与软件巨头们相比，小公司更有可能更快速地提供企业需要的应用。”

　　未来，这些小公司将更加努力地开发具有更好的适应能力、能即插即用的应用软件，而那些软件巨头很难做到这一点。Leaver解释说，例如，大多 数的中小软件公司开发的应用都运行在IBM的Websphere、SAP的Netweaver和Oracle的中间件产品之上，从而使得用户的IT人员可 以非常容易而且快速地配置和修改它们。正是由于存在大批这样的应用软件，CIO才不用过多地关心软件架构，而把注意力放在这些软件是否好用本身。

　　另外，IDC的企业应用研究主任Albert Pang补充说，这些创新将导致越来越多的Web 2.0 应用和其他企业用户非常喜欢的应用出现。“不久，企业用户就能用上软件公司提供的各种工具让他们轻松地完成企业级的Mashup应用。”

　　例如，Pang解释说，企业级Mashup能很容易地创建新的财务系统，这些财务系统允许用户把外部的一些变量(如天气预报和环境影响研究结果)集成到他们的财务规划、预测和报表生成流程以及投资回报的风险评估中。

　　Pang认为，对于CIO来说最为重要的一点是，必须寻求短期与中长期发展之间的平衡，避免受到来自软件供应商的影响而盲目购买。“如果真的需要购买什么产品或者服务，CIO应该学会比较多个软件开发商为自己赢得一个较好的价格。”

　　趋势5:

　　软件付费策略面临挑战

　　长期以来，CIO们似乎从来没有停止过抱怨企业级软件高昂的维护和服务费。据统计，这笔费用往往占到企业IT投入的22%以上，成为很多企业IT部门的一个沉重负担。

　　Woods说: “在软件供应商们一再强调它们的维护能给用户带来诸多好处，比如软件功能有很大改善的时候，CIO们却常常问自己，这笔维护费给我带来了什么回报?”

　　过去的一年多时间里，有些CIO或者尝试或者已经开始转向第三方(如被SAP收购的TomorrowNow)来维护自己的EPR和CRM系统。不过，Oracle指控TomorrowNow以及SAP在处理这件事上的犹豫给这种由第三方维护的模式带来了一片阴云。

　　即便如此，第三方维护的方式也已经激起了很多IT经理们的兴趣，2008年尝试这种模式的CIO会越来越多。“TomorrowNow的存在使得人们开始思考软件维护的成本，”Woods说，“几乎每一个CIO都在问，我能换一种软件维护的方式吗?”

　　对CIO而言一个不大好的情况是，一些供应商的软件设计得不够好，用户无法采用新一代的企业软件工具自己进行维护和升级。因此，CIO要做出最后的决定并不容易。

　　事实上，由于备受用户指责的软件维护费用收入占到很多软件公司收入的90%以上，因此，不少软件公司根本不愿意触及这个问题，更不提考虑进行一 些实质上的改变了。但是，Leaver认为，这种情形在2008年将会有所改观。如果软件公司希望继续让它们的客户满意，软件公司就必须重新考虑它们的价 格策略和软件维护费的定价问题。

　　趋势6:

　　供应链更无线化、更危险

　　无线技术将继续影响供应链的未来发展。对供应链的未来影响最大的无线技术首选RFID，它也吸引了众多人的注意。尽管这种技术仍然处于不断完善之中，但是，分析师们认为，在2008年，它的应用将继续扩展和普及。

　　值得注意的是，恰恰是供应链上采用的其他一些先进技术使得供应链的效率有了很大提高，比如，无线数据传输技术和配送中心日常运营中使用的无线技 术等。但是，分析师们指出，供应链摆脱了线缆羁绊的同时也增加了风险。零售系统研究公司(Retail Systems Research)最近的一份研究表明，在供应链系统因采用新设备而引发的重大安全漏洞中，源于无线技术的比例有明显增加。

　　零售系统研究公司分析师Steve Rowen认为，无线系统的攻击者已经不是那些无聊的黑客，他们懂技术、有目的，在他们看来，那些不认真对数据传输进行保护的公司就是在为他们提供一个挣 钱的机会。Rowen说，“最近几年，因为窃取客户的数据可以为犯罪分子换得比较高的回报，针对无线系统的有组织犯罪正在成为‘大生意’。”

　　在2008年，Rowen提出的第一个建议就是引起公司高层的注意。“最成功的安全保护办法就是尽快让CXO们重视这一隐患，”他说，“尽管不 同的零售商其具体的安全措施不尽相同，但有一点是共同的，就是这些具体的办法都受限于公司董事会和管理层目前对安全问题的重视程度。”

1、 甚么是WebService？

WebService基于SOAP协议，而SOAP主要基于Http协议，因为Http应用最为广泛，几乎不受限制。SOAP的作用是：

Ø         Access data and process services over the web

Ø         Transfer data objects between clients and services over the web

2、 如何生成WebService？

   通过一些工具对Java类生成WSDL文件。

（1）      编写Java类

（2）      生成WSDL文件。如通过Axis生成，Axis依赖web服务器。

3、 如何使用WebService？

在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件。所以，我们需要一种方法来发布我们的Web服务，即UDDI。

对于商业用户来说，要找到一个自己需要使用的服务，他必须知道如何来调用，即使用WSDL。

当商业用户通过UDDI找到你的WSDL描述文档后，他通过可以Simple Object Access Protocol (SOAP) 调用你建立的Web服务中的一个或多个操作。

为了支持UDDI在Java平台上的功能，Java APIs for XML Registries (JAXR)允许开发者来访问注册中心。值得注意的是，JAXR并不是建立Web服务必需的，你可以利用其他常用的XML APIs来直接集成这些协议。

4、 WebService的应用场景和领域有哪些？

5、 WebService的优缺点有那些？

优点：平台独立，易于使用，是SOA的基础。

相关技术：

1、 UDDI (Universal Description, Discovery, and Integration)

       是一个主要针对Web服务供应商和使用者的新项目。UDDI 项目中的成员可以通过UDDI Business Registry (UBR) 来操作Web服务的调用，UBR是一个全球性的服务。 Web服务供应商可以在UBR中描述并且注册他们的服务。 用户可以在UBR中查找并定位那些他们需要的服务。 UDDI是一种根据描述文档来引导系统查找相应服务的机制。 UDDI包含标准的“白皮书”类型的商业查询方式， “黄皮书”类型的局部查找，以及 “绿皮书”类型的服务类型查找。 UDDI利用SOAP消息机制（标准的XML/HTTP）来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。

2、 WSDL (Web Services Description Language) 规范

       是一个描述接口，语义以及Web服务为了响应请求需要经常处理的工作的XML文档。这将使简单地服务方便，快速地被描述和记录。

3、SOAP

       是XML文档形式的调用商业方法的规范，它可以支持不同的底层接口，象HTTP(S)或者SMTP。 之所以使用XML是因为它的独立于编程语言，良好的可扩展性以及强大的工业支持。之所以使用HTTP是因为几乎所有的网络系统都可以用这种协议来通信，由于它是一种简单协议，所以可以与任何系统结合，还有一个原因就是它可以利用80端口来穿越过防火墙。 SOAP的强大是因为它简单。SOAP是一种轻量级的，非常容易理解的技术，并且很容易实现。它有工业支持，可以从各主要的电子商务平台供应商那里获得。从技术角度来看，SOAP详细指明了如何响应不同的请求以及如何对参数编码。一个SOAP封装了可选的头信息和正文，并且通常使用HTTP POST方法来传送到一个HTTP 服务器，当然其他方法也是可以的，例如SMTP。SOAP同时支持消息传送和远程过程调用。

4、 JAXR

       是一个方便的API，它提供了Java API来发布，查找以及编辑那些注册信息。它的重点在于基于XML的B2B应用，复杂的地址本查找以及对XML消息订阅的支持等Web服务。 它也可以用来访问其他类型的注册中心，象ebXML注册中心。这些对Web服务的注册信息进行的操作，可以使用当前的一些Web服务工具来完成（例如第三方的SOAP和ebXML消息工具）。另外，当JAXP提供了一致并具有针对性的API来完成这些操作，这将使开发变得更加容易。

5、  JAX/RPC

       为了使开发人员专注于建立象SOAP那样的基于XML的请求，JCP正在开发基于RPC (JAX/RPC) 的Java API。JAX/RPC是用来发送和接收方法调用请求的，它基于XML协议，象SOAP，或者其他的象XMLP (XML Protocol，要了解更多可以参考http://www.w3.org/2000/xp/)。JAX/RPC使你不用再关注这些协议的规范，使应用的开发更快速。不久，开发人员就不用直接以XML表示方法调用了。目前有很多第三方实现了SOAP，开发人员可以在不同的层次上调用SOAP，并选择使用哪一种。将来，JAX/RPC会取代这些APIs并提供一个统一的接口来构造以及处理SOAP RPC请求。在接收一个从商业伙伴那里过来的SOAP请求的时候，一个Java servlet用JAX/RPC来接收这个基于XML的请求。一旦接收到请求后，servlet会调用商务方法，并且把结果回复给商业伙伴。

6、JAXM

       当从商业合作伙伴那里接收一个Web服务的请求时，我们需要Java API实现一个Servlet来处理ebXML消息，就象我们用JAX/RPC来处理SOAP请求一样。 Java API for XML Messaging (JAXM) 是集成XML消息标准（象ebXML消息或者SOAP消息）的规范。 这个API是用来推动XML消息处理的，它检测那些预定单的消息格式以及约束。它控制了所有的消息封装机制，用一种直观的方式分割了消息中的信息，象路由信息，发货单。这样，开发人员只要关注消息的有效负载，而不用去担心那些消息的重复处理。目前的开发人员用JAXP来实现JAXM将要提供的功能，JAXM将会提供一套非常具有针对性的API来处理基于XML的消息传送。这将大大简化开发人员的代码，并使它们具有统一的接口。 JAXM和JAX/RPC的差别在于处理消息导向的中间件以及远程过程调用的不同。JAXM注重于消息导向，而JAX/RPC是用来完成远程过程调用的。

7、JAXB

       XML绑定技术可以把XML文档和Java对象进行自由转换。 用JAXB，你可以在后台的EJB层，把XML文档转换成Java对象。同样你也可以把从EJB中取出的Java对象转换成XML文档返回给用户。 JAXB接口提供了比SAX和DOM更高级的方法来处理XML文档。它提供的特性可以在XML数据和Java类之间互相映射，提供了一个简单的方法来转换XML数据。它比逐个解析标记更简单。