Web Service：是一个较新得分布式服务组件。本质是以标准化得方式实现企业内外各个不同服务系统之间得互调或者集成。

Web Service:通过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，并通过UDDI进行注册。

2、WSDL（Web Service Description Lanaguage）

基于Xml格式得关于Web服务得描述语言。

如一段代码：

package com.sample.ejb.sessionbean;

public interface UserAccountMgr extends javax.ejb.EJBObject {

   public boolean checkUserLogin( java.lang.String loginName,java.lang.String password );

}

WSDL得三部分得描述：

1） Type代码：

 <wsdl:types>
     <!--服务接口方法-->  
     <element name="checkUserLogin">
      <complexType>
       <sequence>
        <!--输入参数及其类型-->
        <element name="loginName" nillable="true" type="xsd:string"/>
        <element name="password" nillable="true" type="xsd:string"/>
       </sequence>
      </complexType>
   <!--返回结果的类型-->
      <element name="checkUserLoginResponse">
       <complexType>
        <sequence>
         <element name="checkUserLoginReturn"  type="xsd:boolean"/>
        </sequence>
       </complexType>
     </element>
</wsdl:types>

2） Message代码

<!--请求消息--> 
  <wsdl:message name="checkUserLoginRequest">

      <wsdl:part name="in0" type="xsd:string"/>

      <wsdl:part name="in1" type="xsd:string"/>

   </wsdl:message>
<!--返回消息-->
   <wsdl:message name="checkUserLoginResponse">

      <wsdl:part name="checkUserLoginReturn" type="xsd:boolean"/>

   </wsdl:message>

3） PortType代码

<!--服务接口-->
   <wsdl:portType name="CheckUserLoginMgr">
<!--所包含得服务接口方法-->
      <wsdl:operation name="checkUserLogin" parameterOrder="in0 in1">
<!--服务接口方法所对应得请求消息和返回消息-->
         <wsdl:input message="impl:checkUserLoginRequest" name="checkUserLoginRequest"/>
         <wsdl:output message="impl:checkUserLoginResponse" name="checkUserLoginResponse"/>
         <wsdl:fault message="impl:ApplicationException" name="ApplicationException"/>
      </wsdl:operation>
   </wsdl:portType>

2、How部分

<wsdl:binding name="checkUserLoginServiceSoapBinding" type="impl:CheckUserLoginMgr">
      <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <wsdl:operation name="checkUserLogin">
         <wsdlsoap:operation soapAction=""/>
         <wsdl:input name="checkUserLoginRequest">
            <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:7001/webModule/services/checkUserLoginService" use="encoded"/>
         </wsdl:input>
         <wsdl:output name="checkUserLoginResponse">
            <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://localhost:7001/webModule/services/checkUserLoginService" use="encoded"/>
         </wsdl:output>
         <wsdl:fault name="ApplicationException">
            <wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="ApplicationException" namespace="http://localhost:7001/webModule/services/checkUserLoginService" use="encoded"/>
         </wsdl:fault>
      </wsdl:operation>
   </wsdl:binding>

3、Where部分

   <wsdl:service name="CheckUserLoginMgrService">

      <wsdl:port binding="impl:checkUserLoginServiceSoapBinding" name="checkUserLoginService">

         <wsdlsoap:address location="http://localhost:7001/webModule/services/checkUserLoginService"/>

      </wsdl:port>

   </wsdl:service>

3、SOAP（Simple Object Application Propotol）

SOAP作用：请求（request）消息将客户端请求消息发给服务器

            答复（response）消息，从服务器返回给客户端消息

服务A需要创建相应得SOAP请求消息，并发给服务B。包括服务接口，服务接口方法，参数值等信息。通过SOAP/HTTP传输方式传到服务B在WSDL文件中指定得URL地址

4、UDDL

Universal Description, Discovery and Integration将自己得服务注册到相应得UDDL商用注册网站上去

以资源共享的方式由多个运作者一起以Web Service的形式运作UDDI商业注册中心。

　　UDDI计划的核心组件是UDDI商业注册，它使用XML文档来描述企业及其提供的Web Service。

　　UDDI商业注册提供三种信息：

　　White Page包含地址、联系方法、已知的企业标识。

　　Yellow Page包含基于标准分类法的行业类别。

　　Green Page包含关于该企业所提供的Web Service的技术信息，其形式可能是指向文件或URL的指针，而这些文件或URL是为服务发现机制服务的。

1 定义

抽象类：所有的对象都是通过类来描绘的，但是反过来却不是这样。并不是所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就是抽象类。

例如

2 语法

2.1 abstract class

可以有自己的数据成员

有非abstarct的成员方法

继承关系，一个类只能使用一次继承关系

可以赋予方法的默认行为

因为如果后来想修改类的界面（一般通过abstract class或者interface来表示）以适应新的情况（比如，添加新的方法或者给已用的方法中添加新的参数）时，就会非常的麻烦，可能要花费很多的时间（对于派生类很多的情况，尤为如此）。但是如果界面是通过abstract class来实现的，那么可能就只需要修改定义在abstract class中的默认行为就可以了。

    同样，如果不能在抽象类中定义默认行为，就会导致同样的方法实现出现在该抽象类的每一个派生类中，违反了"one rule，one place"原则，造成代码重复，同样不利于以后的维护。因此，在abstract class和interface间进行选择时要非常的小心。

2.2 interface

只能够有静态的不能被修改的数据成员

所有的成员方法都是abstract的

实现关系，一个类却可以实现多个interface

不可以赋予方法的默认行为

3 设计理念

abstarct class：父类和派生类之间必须存在"is a"关系，即父类和派生类在概念本质上应该是相同的

3.1 interface

不要求interface的实现者和interface定义在概念本质上是一致的，仅仅是实现了interface定义的契约而已

4 实例

AlarmDoor在概念本质上是Door

同时它有具有报警的功能

abstract class Door {

abstract void open();

abstract void close()；

}

interface Alarm {

void alarm();

}

class AlarmDoor extends Door implements Alarm {

void open() { … }

void close() { … }

void alarm() { … }

}

这个问题，搞了很长时间，一直以为是自己的设置没设对，最后发现是redhat的一个bug，考，郁闷。
解决方法：
到/etc/sysconfig/network-scripts/ifcfg-eth<n>
  /etc/sysconfig/networking/devices/ifcfg-eth<n>  
其中<n>表示Ethernet adapter的标识数字，一般为0。当为零的时候，就是
  /etc/sysconfig/network-scripts/ifcfg-eth0 
  /etc/sysconfig/networking/devices/ifcfg-eth0   
这两个文件中加入 
 check_link_down () {
       return 1;

1、当你全身心投入你正在做得事情时，心思就不会游离不定。你享受生活，你也会更快乐更有效率，你下决定只关注那一刻发生得事情，那种集中和专注将带领你走向成功。
2、 礼物就是把握此刻，全神贯注于正在发生得事。珍惜和欣赏每天得到得东西。
3、即使在最艰难得环境中，只要你专注于此刻美好得事，现在就能感到更加快乐。这将给你说需得力量和自信。
4、痛苦，就是现实和理想之间得差距。此刻得痛苦和其他所有东西一样，是不断变化得。它会出现也将消失。当你完全专注于此刻，感受到了痛苦并饱受折磨得时候，你就可以开始寻找一些好得方面，然后再此基础上回复信心和勇气
5、把握此刻，就不能分心旁顾，而要专注于此刻重要得事情。你将注意头像此刻，就创造除属于自己得此刻，这也是你给自己最好得礼物。
6、专注于此刻正在发生得事情。发现其中好得方面，并在此基础上建立信心和勇气。将注意力放在此刻重要得事情上
7、你无法改变过去，但可以从中学习。

早期的Java

  Oak语言的吉祥物，Duke

Java平台和语言最开始只是升阳公司在1990年12开始研究的一个内部项目。升阳公司的一个叫做帕特里克•诺顿的工程师被升阳自己开发的C++和C语言编译器搞得焦头烂额，因为其中的API极其难用。帕特里克决定改用NeXT，同时他也获得了研究公司的一个叫做“Stealth 计划”的项目的机会。

“Stealth 计划”后来改名为“Green计划”，詹姆斯•高斯林和麦克•舍林丹也加入了帕特里克的工作小组。他们和其它几个工程师一起在加利福尼亚州门罗帕克市沙丘路的一个小工作室里面研究开发新技术，瞄准下一代智能家电（如微波炉）的程序设计，升阳公司预料未来科技将在家用电器领域大显身手。团队最初考虑使用C++语言，但是很多成员包括升阳的首席科学家比尔•乔伊，发现C++和可用的API在某些方面存在很大问题。

工作小组使用的是内嵌类型平台，可以用的资源极其有限。很多成员发现C++太复杂以至很多开发者经常错误使用。他们发现C++缺少垃圾回收系统，还有可移植的安全性、分布程序设计、和多线程功能。最后，他们想要一种易于移植到各种设备上的平台。

根据可用的资金，比尔•乔伊决定开发一种集C语言和Mesa语言大成的新语言，在一份报告上，乔伊把它叫做“未来”，他提议升阳公司的工程师应该在C++的基础上，开发一种面向对象的环境。最初，高斯林试图修改和扩展C++的功能，他自己称这种新语言为 C++ ++ --，但是后来他放弃了。他将要创造出一种全新的语言，被他命名为“Oak”（橡树）,以他的办公室外的树而命名。

就像很多开发新技术的秘密的工程一样，工作小组没日没夜地工作到了1992年的夏天，他们能够演示新平台的一部分了，包括Green操作系统，Oak的程序设计语言，类库，和其硬件。最初的尝试是面向一种类PDA设备，被命名为Star7，这种设备有鲜艳的图形用户界面和被称为“Duke”的智能代理来帮助用户。1992年12月3日，这台设备进行了展示。

同年11月，Green计划被转化成了“FirstPerson有限公司”，一个升阳公司的全资子公司，团队也被重新安排到了帕洛阿尔托。FirstPerson团队对建造一种高度互动的设备感兴趣，当时代华纳发布了一个关于电视机顶盒的征求提议书时（Request for proposal），FirstPerson改变了他们的目标，作为对征求意见书的响应，提出了一个机顶盒平台的提议。但是有线电视业界觉得FirstPerson的平台给予用户过多地控制权，因此FirstPerson的投标败给了SGI。与3DO 公司的另外一笔关于机顶盒的交易也没有成功，由于他们的平台不能在电视工业产生任何效益，公司再并回升阳公司。

JAVA遭遇互联网

为Java量身订做的浏览器-Web Runner

1994年6、7月间，在经历了一场历时三天的头脑风暴的讨论后，约翰•盖吉、詹姆斯•高斯林、比尔•乔伊、帕特里克•诺顿、韦恩•罗斯因和埃里克•斯库米，团队决定再一次改变了努力的目标，这次他们决定将该技术应用于万维网。他们认为随着Mosaic浏览器的到来，因特网正在向同样的高度互动的远景演变，而这一远景正是他们在有线电视网中看到的。作为原型，帕特里克•诺顿写了一个小型万维网浏览器，WebRunner，后来改名为HotJava。
在HotJava中看最早的java.sun.com网页

版本历史（timesheet）

从Java 2开始出现的，Java互联网启动中心

• 1995年5月23日，Java语言诞生
• 1996年1月，第一个JDK-JDK1.0诞生
• 1996年4月，10个最主要的操作系统供应商申明将在其产品中嵌入JAVA技术
• 1996年9月，约8.3万个网页应用了JAVA技术来制作
• 1997年2月18日，JDK1.1发布
• 1997年4月2日，JavaOne会议召开，参与者逾一万人，创当时全球同类会议规模之纪录
• 1997年9月，JavaDeveloperConnection社区成员超过十万
• 1998年2月，JDK1.1被下载超过2,000,000次
• 1998年12月8日，JAVA2企业平台J2EE发布
• 1999年6月，SUN公司发布Java的三个版本：标准版、企业版和微型版（J2SE、J2EE、J2ME）
• 2000年5月8日，JDK1.3发布
• 2000年5月29日，JDK1.4发布
• 2001年6月5日，NOKIA宣布，到2003年将出售1亿部支持Java的手机
• 2001年9月24日，J2EE1.3发布
• 2002年2月26日，J2SE1.4发布，自此Java的计算能力有了大幅提升。
• 2004年9月30日18:00PM，J2SE1.5发布，是Java语言的发展史上的又一里程碑事件。为了表示这个版本的重要性，J2SE1.5更名为J2SE5.0
• 2005年6月，JavaOne大会召开，SUN公司公开Java SE 6。此时，Java的各种版本已经更名以取消其中的数字“2”：J2EE更名为Java EE, J2SE更名为Java SE，J2ME更名为Java ME。
• 2006年11月13日，SUN公司宣布Java全线采纳GNU General Public License Version 2，从而公开了Java的源代码。

Java试图通过新的方式解决软件编写的复杂性。很多人认为Java语言做到了它承诺的一切。但是Java并不是一门完

美的语言，在编程风格、编程环境和需求方面并没有获得全球性的认可。

·   并不是所有的工程和环境需要企业级别的复杂性，比如一个简单的个人网站或者独自编程的程序员所写

·   的程序。这些程序员会发现Java的复杂管理对于自己要做的程序来说过于强大了。

·   Java经常让那些并不是对面向对象编程很热心的程序员感到不满。

·   一些人觉得Java在面向对象上面做的没有Ruby和Smalltalk纯粹。但是最新出现的用Java实现的语言

·   Groovy解决了这些问题。

·   作为一种已经建立的新技术，Java显然综合了很多语言的特性，比如C++、C语言、Python等等。一些

·   对于Java的评论认为Java的不变性在动摇，有些人认为Java只是一种“新的COBOL"语言。

语言问题

·   有些程序员不喜欢原始类型和类的分离，尤其是那些曾经使用过Smalltalk和Ruby的程序员。他们会问

·   ：“这就是一切皆对象？”

·   事实上，JAVA语言本身只是Smalltalk的一个不完整的代替品。JAVA的流行与SUN背后的支持分不开。

·   Java的代码相对于其它的代码来说过于冗长，这与它的轻便化声明相违背。

·   Java语言在单范例程序方面非常出色。历史上的Java则在这方面做的不好。

·   Java是一种单层继承的语言。这也导致了程序员在试图使用多重继承时候的不便，而很多语言都可以

·   使用这个特性。但是Java可以使用接口类，把多重继承可能导致的风险减少到最小。

·   Java不支持运算符重载，这是为了防止运算符重载使得代码的功能变的不清晰。但是用Java实现的语

·   言Groovy可以进行运算符重载。

·   5.0版本增加了大量的基本类的支持，可以节省大量的额外编程工作。

·   过去Java对于文本的操作和其它语言，比如perl和PHP相比差的较多，但Java在1.4版本时候引入了

·   正则表达式。

·   准确地说，JAVA不是平台无关的，它本身就是一个平台。

类库问题

使用Swing平台编写的带有GUI（图形用户界面）的程序和其它原始程序非常不同。选用AWT工具包编写程序的程序

员看到的都是原始界面，而且也无法获得先进的GUI编程支持，如果使用的话，就要提供每个平台上面所需的API，

这将是一项庞大的工程。Swing则是完全用Java语言所写的程序，避免了界面元素重复的问题，只使用所有平台都

支持的最基本的绘图机制。但是很多用户不知道如何在Java风格和Windows风格之间进行转换，结果造成了Java程

序的界面在很多程序中非常特殊。苹果电脑已经提供了优化过的Java运行时程序，包含了Mac OS X的经典Aqua界面风格。

IBM公司提供的SWT和JFace提供了具有本地化风格的界面。

性能问题

由于Java编译器和虚拟机的不同对Java代码的性能影响比语言本身的影响大的多，所以统一讨论Java的程序的性能经

常是有误导性的。据IBM的数据，在同样的硬件上2001年时的IBM JDK版本的性能是1996年的JDK版本的十倍左右。

见IBM东京研究院的数据： http://www.is.titech.ac.jp/ppl2004/proceedings/ishizaki_slides.pdf

而即使是在同一时期，不同公司的JDK和JRE的性能也不一样，比如SUN、IBM、BEA等公司都有自己开发的JDK和JRE。

Java语言的一些特性不可避免的有额外的性能代价，例如数组范围检查、运行时类型检查等等。Java程序的性能还会

因为不同的动态复杂性和垃圾处理机制使用的多少而各有不同。如果JVM的实现比较优化的话，那么这些功能甚至可以

增加内存分配的性能。这和总是使用STL或者托管C++的程序的情况类似。

尽管如此，仍然有许多人认为Java的性能低。这部分归因于Sun公司最初的JVM实现使用未优化的解释机制来执行字节码

。一些新版本的JVM使用Just-In-Time(JIT)编译器，在加载字节码的时候将其编译成针对运行环境的本地代码来实现

一些本地编译器的优化特性。Just-In-Time机制和本地编译的性能比较仍旧是一个有争议的话题。JIT编译需要很多时

间，对于运行时间不长或者代码很多的大型程序并不适宜。但是不算JIT编译阶段的话，程序的运行性能在很多JVM下可

以和本地编译的程序一争短长，甚至在一些计算比较密集的数值计算领域也是这样。目前，Java已经使用更先进的

HotSpot技术来代替JIT技术，Java的性能有了更进一步的提升。另外，在使用-server选项运行java程序时，也可以对

java进行更深入的优化，比如在运行时将调用较多的方法内联(inline)到程序中来提高运行速度，这就是所谓的

“动态优化”，而本地编译器是无法做到这一点的；这也是一些java代码比对应用C/C++等语言编写的本地代码运行的更快

的原因之一。微软的.NET平台也使用JIT编译器，所以也有类似问题。

Java的设计目的主要是安全性和可移植性，所以对于一些特性，比如对硬件架构和内存地址访问的直接访问都被去除了。

如果需要间接调用这些底层功能的话，就需要使用JNI（Java本地接口）来调用本地代码，而间接访问意味着频繁调用这

些特性时性能损失会很大，微软的.NET平台也有这样的问题。所以到目前为止，性能敏感的代码，例如驱动程序和3D视频

游戏，还是大多使用本地编译，甚至直接以不直接支持面向对象的C语言或机器码编写。但最近已经有了许多用纯Java编写

的3D游戏，其效果与用C语言编写的不相上下，例如“合金战士”（英文名:Chrome）。这主要是因为新版的Java 3D技术

已经能像C++一样调用硬件加速，也就是使用显卡来加速，无论是C++还是Java语言写的3D游戏都是使用显卡及GPU来处理，

从而使得CPU可以专注于其它方面的工作。

关于Java的性能，可以参看以下文章：

http://www-128.ibm.com/developerworks/cn/java/j-jtp09275.html

http://www.matrix.org.cn/thread.shtml?topicId=16092&forumId=18

Java运行时环境，即Java Runtime Environment，简称为JRE，是在任何平台上运行Java编写的程序都需要用到的软件。

终端用户可以以软件或者插件方式得到和使用JRE。Sun公司还发布了一个JRE的更复杂的版本，叫做JDK，即Java 2 开发包，

里面包含了Java需要的编译器、参考文档和调试器等。

JRE的成分：

·   Java的类库，包含了编译Java程序所需要的最核心文件。

·   核心库文件，其中有

·   数据结构的库，包括列表、字典和树等

·   XML分析库

·   安全方面应用库

·   国际化和本地化应用库

·   综合库文件，包含了程序员和其它系统通信的功能文件。

·   JDBC，即Java数据库联通的API

·   JNDI，即Java命名和目录接口

·   RMI和CORBA用于重新分发软件

·   用户界面库文件，包含：

·   AWT，即抽象窗口开发包，提供了产生图形用户界面所需要的功能

·   Swing库

·   其它用于回访媒体文件、录音、截图的库

·   一个用于执行软件的Java虚拟机

·   插件，可以在浏览器里面使用

·   JWS，可以让终端用户连接到互联网

·   许可文件和文档

扩展和与Java程序设计语言紧密相关的架构（按字母排序）。

• Groovy ，一种用纯Java实现的脚本语言，Python的强有力竞争者
• JAIN (Java API for Integrated Networks)Java综合网络应用程序开发接口
• JAI，(Java Advanced Imaging)Java进阶图像
• Java EE(原名J2EE)，Java平台企业版
• Java ME(原名J2ME) ，Java平台微型版为PDA和智能手机开发的移动版本
• Java SE(原名J2SE)，Java平台标准版
• JDBC ，(Java Database Connectivity)Java数据库联通
• JDMK，(Java Dynamic Management Kit)Java动态管理开发包
• JDO ，(Java Data Objects)Java数据对象
• JJSF，Java服务器界面
• JMF，(Java Media Framework) Java媒体框架
• JMI，Java元数据接口
• JML ，(Java Modeling Language)Java建模软件
• JMX ，(Java Management Extensions)Java管理扩展
• JNDI ，(Java Naming and Directory Interface)Java命名和目录接口
• JNI ，Java原始界面
• JOGL，使用OpenGL的低阶三位游戏开发接口
• JSML ，(Java Speech API Markup Language)Java的语音和标记语言
• JSP ，(JavaServer Pages)Java服务器页面
• JSF ，(JavaServer Faces)
• JXTA ，P2P虚拟网络协议
• Java Card
• Java3D ，用于三维游戏编程的高阶应用程序开发接口
• JavaSpaces
• Jini ，Java网络分布计算结构
• Jiro
• OSGi，(Dynamic Service Management and Remote Maintenance)动态服务管理和远程控制
• Rhino, 用Java实现的JavaScript语言。
• SuperWaba ，手持设备的虚拟机程序

不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：

一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
 

SOA的基本特征

1可从企业外部访问

通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。

除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务

2 随时可用

　　当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。

　　许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。

　　当相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。

　　服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。

　　当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。

　　3  粗粒度服务接口

　　粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚??向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。

　　采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

　　除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。

　　4 分级

　　一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。

　　在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。

　　5  松散耦合

　　SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

　　服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

　　大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。

　　当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。

　　消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。

　　6  可重用的服务及服务接口设计管理

　　如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。

　　服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷??走捷径的项目战术与企业构建可重用通用服务的长期目标。

　　超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。
在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。

　　简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。

　　7  标准化的接口

　　近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是专有的、并且要求IT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。这具有巨大的意义！

　　Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。
你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。

　　8  支持各种消息模式

　　SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。

　　﹡无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。

　　﹡有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。

　　﹡等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。

　　9  精确定义的服务接口

　　服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。

　　META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。

首先SOA更接近一种思想 而ejb更接近一种技术
就好像你可以说J2EE WITHOUT EJB 但是不你能说 J2EE without 设计模式 一样

基于SOA构建的系统号称是encapsulation, loose coupling, contract, granularity, reusability, composability, interoperability...

SOA其实就是"解耦"思想的延续, 只要你无法证明软件中的"解耦"是错误的,那么你就很难证明SOA是错误的
目前各大厂商忽悠的不是SOA本身. 而是因为这种思想本身可以说是无懈可击, 你喜欢小品的话,可以套用那句"EJB是一根筋, SOA现在是两头堵"

例如有的厂商鼓出ESB 有的鼓吹面向构件 ,另外SOA由于太正确 太宏观了,所以他下面又引出了很多名词术语 SDO DAS SOC ....等等,
而每个名词背后都蕴藏着一片很大的市场.所以厂商们忽悠的是那些市场 而不是SOA本身.

所以 我对SOA的观点是:
SOA是正确的伟大的但是不具体的.
它未来的命运决定于围绕SOA开发出的产品.而这个产品到底是出自IBM ORACLE 普元 还是其他,这个目前我们只能拭目以待.

我觉得任何技术的出现都必须体现出易用性，SOA的出现，概念上提出了以服务为中心的体系架构，
并从三大方面：前端整合(门户)，数据整合,还有流程整合加以阐述，但是根据我最近做的一个SOA的项目来说(姑且称之为SOA)，

SOA叫做面向服务的架构，从广义的概念上来说，是现在软件发展的趋势。
比方说Facebook的开放性平台，Rails提倡的REST架构，以及用Rails的REST提供开放API的twitter网站，
甚至Amazon，Google这些开放服务的平台等等，本质上都是“面向服务的架构”。

但是狭义的放到企业应用领域，可能特指的是企业各种异构系统的整合，
以及要求新系统能够以符合统一标准的方式来开发。从这个意义上来说，
从传统的EDI，到ESB，组件化，Web服务，到现在的SOA，
都是同一条路线走下来的，所不同者不过是引入了不同时代的技术方案和标准而已。
-------------------------------------------------------------------------
说到底是要异构集成，但为什么要异构集成？异构集成能解决多少问题？
一个非要说汉语，一个非要说英语，再加上个说日语的，效率再怎么也高不了。

为什么不能同构？
有了统一的TCP-IP，大家才可以舒舒服服互连互通；有了html，大家才可以舒舒服服照章办事。
数据可以用XML来统一，业务逻辑和服务调用呢？成百上千的语言和技术成天在瞎折腾呢。
于是什么SOA、SOAP、REST跳出来忽悠了，可忽悠到最后能解决多少问题？只怕是带来的问题更多。

说的极端点，业务层就该统一用开发效率和运行效率达到最佳平衡的JavaBean重写了，天下也就太平了。
还想折腾的，表示层玩去吧。
----------------------------------------------------------------------------------------------
soa更多的是为了配合商业流程的快速重构和应对多变的商业环境的产物。这个事情企业的流程是柔性的，风格是多样化的，
服务的对象也是非格式化的。也就是说昨天的那种大规模生产，大规模铺货，大规模销售的模式，已经让位为——更加强调客户定制，
更加有针对性的小区域和小群体铺货，更加针对性的销售，一句话就是更加具有服务的针对性。在这样的情况下，
企业即便希望开发一套新系统来满足这样的要求，也会面临许多需要能够更多可以定制，可以快速伸缩性部署，
可以更加有效益的信息流转，更加紧密的多流程协调一致的新系统。这样的系统不仅仅需要健壮，也需要数据和部署以及维护和改变的更加灵活快速。
而实施soa的前提条件是必须具有强大的企业业务分析能力和再造能力，已经对支撑此应用对系统要求的测算能力。
只有具备了这样的业务分析能力，才能把握住企业运转的真实流程；只有具备这样的再造能力，才能形成一种柔性的企业生态系统；
只有具备这样的测算能力，才能把握住企业信息建设的关键环节的约束性指标。
而技术的实现仅仅是在前面这些关键性工作驱动下的一种实现的手段，具体的方式可以多种多样。
但是其成本构成和资源的配置必须要能够合乎关键环境的约束性指标。
可以说soa更加看重的是企业对信息系统的规划能力，是企业高层的战略考量的一种在信息系统建设方面的考量。
而其针对开发人员的内容相对较少，针对软件公司的技术内容也相对较少。
----------------------------------------------------------------------------------------------
就soa来说，不管如何搞，如何做，都是要以业务为主线，以流程为线索，以技术为辅助。
---------------------------------------------------------------------------------
soa95%以上的工作是在做业务流程的分析解构和重整，技术层面的支持只占5%不到。
这点同ERP类似，也就是你那个产品和开发能力在这个事情上根本就是最最不重要的那个部分，想靠这个打开局面简直就是开玩笑。
---------------------------------------------------------------------------------
soa的基础思想在技术上的要求是能够把各种异构的资源，以一种通用的形式展现和协调起来，
从而形成一种能够在技术上比较便宜的组织和部署方式。在这个领域只有那些有深厚用户基础的公司，才可能有机会进入
---------------------------------------------------------------------------------
其实soa所要求的不是首先你们去提客户考虑，而是要首先要客户有一种将业务流程解构为元流程要素和进行再工程重装的思想，
是一种客户思维方式的变革。也就是说首先要叫客户改变他们对业务的看法，对流程的看法，而不是叫他们给你们提需求。
这也就是为什么soa的重点在业务咨询，而不是技术实现的根本所在。而可以说如果你们能有这样的能力，你们这些做开发的就可有可无了。
---------------------------------------------------------------------------------
soa更多的是一种商业技术，而不是软件开发技术。
而就如同dlee那erp跟soa做对比，我认为今天的soa实际上是具有悠久历史的mis的一种发展。
而我们现在来分析一下真正推行soa见到成效的企业的例子，其实也就是IBM、甲骨文和SAP这些即有技术背景，
同时又有强大的商业咨询能力的公司。而普元之类的公司，只能算作跳梁小丑一样的二角色，在忽悠罢了。
而实际上如果你有时间重读我当初的话，里面就已经阐述清楚了，soa更多的是为了配合商业流程的快速重构和应对多变的商业环境的产物。
这个事情企业的流程是柔性的，风格是多样化的，服务的对象也是非格式化的。也就是说昨天的那种大规模生产，大规模铺货，
大规模销售的模式，已经让位为——更加强调客户定制，更加有针对性的小区域和小群体铺货，更加针对性的销售，
一句话就是更加具有服务的针对性。在这样的情况下，企业即便希望开发一套新系统来满足这样的要求，
也会面临许多需要能够更多可以定制，可以快速伸缩性部署，可以更加有效益的信息流转，更加紧密的多流程协调一致的新系统。
这样的系统不仅仅需要健壮，也需要数据和部署以及维护和改变的更加灵活快速。
而实施soa的前提条件是必须具有强大的企业业务分析能力和再造能力，已经对支撑此应用对系统要求的测算能力。
只有具备了这样的业务分析能力，才能把握住企业运转的真实流程；只有具备这样的再造能力，才能形成一种柔性的企业生态系统；
只有具备这样的测算能力，才能把握住企业信息建设的关键环节的约束性指标。
而技术的实现仅仅是在前面这些关键性工作驱动下的一种实现的手段，具体的方式可以多种多样。
但是其成本构成和资源的配置必须要能够合乎关键环境的约束性指标。
可以说soa更加看重的是企业对信息系统的规划能力，是企业高层的战略考量的一种在信息系统建设方面的考量。
而其针对开发人员的内容相对较少，针对软件公司的技术内容也相对较少。
---------------------------------------------------------------------------------
工作流的思想基础是静态的流程，而现在企业需要的是动态的流程。其实也正是因为流程的高度动态化，和高度的柔性，
才使得soa的必要性凸显出来。也就是现在的企业更加希望提供的是特异性的有针对用户自身情况的个性服务，极端的说就是一个客户一个服务
，一个服务一个流程。而工作流引擎的考虑是把企业现有流程能够更加容易的部署和分配到信息系统中去，是一种静态的思维方式。
------------------------------------------------------------------------------------
SOA中的三大核心技术——BPM/ESB企业服务总线/Webservice
----------------------------------------------------------------------------------------------

SOA的工作流是指跨系统的业务流程，包括人工活动的长流程和自动运行的短流程，同步或异步的流程。SOA的工作流节点是细分到各系统的每一步的具体操作
---------------------------------------------------------------------------------
如果你面对的是成千上万系统的做业务整合的时候，我实在想不出来除了SOA，你怎么去比较合适的规划——不是小打小闹的让两个系统对接，
而是让成千上万个系统对接。（这里面可以问很多问题：比如为什么rpc需要改进，corba需要改进，
rmi需要改进?这些问题本来应该是那些对xmlrpc顶礼膜拜的人能够回答的，只是可惜他们不知就里）
记得dlee曾经就敏捷开发说个一个很让人佩服的话：“我几个月开发一个系统，然后修修改改倒腾3年，
3年以后，重新开发一个新的系统”，可惜这样的标准不能用在SOA的那个S上.
SOA本身就是一个谁都没有搞懂的东西，从最初的吧SOA的那个S当做WebService，到后来SCA,SDO的出现，
显示的都是大家认识上的不足。SCA是什么？他就是一个Spring for WebService,换句话说就是一堆按着Spring风格配置的Webservice,SDO更搞笑，
你甚至可以直接认为它就是基于数据库层的共享，当然安全，性能调谐等方面就无从谈起。
直到后来终于大家意识到服务分层的出现，意识到标准消息的问题，于是才有了点样子，有了个ESB（本人不保证技术出现的前后相续问题，
没有兴趣考古，也实在太乱了），但是也就仅限于此了，有那么比较关键的几点：业务分层原理，没有谁提出个标准包括IBM,BEA,ORACLE,
我知道国内倒是有几家公司各个各自的做法，靠谱，但是明显的理论修养不够，（当然不包括普元，我没有在普元工作过，也没有听到普元的某个人提起过，
于是我大胆的猜测，普元甚至连这里也没有），一个是业务的发布，UDDI那个东西被证明实际应用中用处不大，新的标准又没有出来
，有些公司采用的是业务路由，可惜仅仅是自己的实现，一个是标准消息的流通渠道，ESB是以总线方式布置的，但是总线方式是不是最好的，
能不能解决所有的问题，谁也说不准。（当然，这仅仅是本人的一些看法，不负任何责任）
说到spring+hibernate,SOA设计面对的原子对象是各层次级别的业务服务，根本就不直接和数据库打交道，你用hibernate干啥？
spring那个没有性能管理的东西，真的能够大小通吃么？
----------------------------------------------------------------------------------------------