blogjava-凯发k8网页登录

这里写了一个简单的例子来说明这种模式，其实写这个例子主要是自己想熟悉一下 jdk5 的 concurrency 包中 futuretask 的用法了。例子模拟的是一个会计算账的过程，主线程中已经获得其他帐户的总额了，为了不让主线程等待 privateaccount 返回而启用新的线程去处理，并使用 futuretask 对象来监控，最后需要计算总额的时候再尝试去获得 privateaccount 的信息。

代码如下：

 1 package  testcallable;
 2
 3 import  java.util.random;
 4 import  java.util.concurrent.callable;
 5 import  java.util.concurrent.executionexception;
 6 import  java.util.concurrent.futuretask;
 7
 8 /** */ /**
 9  *  @author  chenpengyi
10   */
11 public   class  sumaccountexample  {
12
13      public   static   void  main(string[] args)  {
14          //  init callable object and future task
15         callable paccount  =   new  privateaccount();
16         futuretask futuretask  =   new  futuretask(paccount);
17         
18          //  create a new thread to do so
19         thread paccountthread  =   new  thread(futuretask);
20         paccountthread.start();
21         
22          //  do something else in the main thread
23         system.out.println( " doing something else here. " );
24         
25          //  get the total money from other accounts 
26          int  totalmoney  =   new  random().nextint( 100000 );
27         system.out.println( " you have  "    totalmoney    "  in your other accounts. " );
28         system.out.println( " waiting for data from private account " );
29          //  if the future task is not finished, we will wait for it
30          while ( ! futuretask.isdone()) {
31              try   {
32                 thread.sleep( 5 );
33             }   catch  (interruptedexception e)  {
34                 e.printstacktrace();
35             }
36         }
37         integer privataaccountmoney  =   null ;
38          //  since the future task is done, get the object back
39          try   {
40             privataaccountmoney  =  (integer)futuretask.get();
41         }   catch  (interruptedexception e)  {
42             e.printstacktrace();
43         }   catch  (executionexception e)  {
44             e.printstacktrace();
45         }
46         system.out.println( " the total moeny you have is  "    (totalmoney   privataaccountmoney.intvalue()));
47     }
48
49 }
50
51
52 class  privateaccount  implements  callable {
53
54     integer totalmoney;
55     
56     @override
57      public  integer call()  throws  exception  {
58          //  simulates a time conusimg task, sleep for 10s
59         thread.sleep( 10000 );
60         totalmoney  =   new  integer( new  random().nextint( 10000 ));
61         system.out.println( " you have  "    totalmoney    "  in your private account. " );
62          return  totalmoney;
63     }
64     
65 }

既然得到了好书就要分享一下，这里不多做介绍了，赶紧把电子版传上来跟大家分享一下。

我们从mysql downloads page上下载了mysql 5.1 beta版，安装到xp上，启动mysql服务，用root用户打开mysql客户端：

mysql> use test;

database changed

mysql> create table test.t (s1 timestamp);

query ok, 0 rows affected (0.11 sec)

mysql> create event e on schedule every 1 second do

       insert into test.t values (current_timestamp);

query ok, 1 row affected (0.00 sec)

mysql> set global event_scheduler = 1;

query ok, 0 rows affected (0.00 sec)

/* 3-second delay */

  mysql> select * from test.t;

---------------------

| s1                  |

---------------------

| 2006-04-05 15:44:26 |

| 2006-04-05 15:44:27 |

| 2006-04-05 15:44:28 |

---------------------

上面是mysql “事件”特性的“hello world”例子，给大家演示的是每隔一秒钟向行内插入一条时间的记录。

方法 1 ：

通过 vpn 网络，让自己在美国或加拿大的朋友为自己建立一个 vpn 的网络，然后拨号过去，再启动一个 skype ，就可以实现。够简单吧，呵呵，我说起来当然简单了，但做起来就不一定了。

这里最难的就是如何架设 vpn 网络了，首先讲怎么建立 vpn 服务器，其实这个在 xp 中就自带了，大家可以根据我的教程试试看。不过这里的 vpn 服务器一定要是美国加拿大本地的，你可以跟那里的朋友说好，让他 24 小时开机就可以了。

建立 vpn 网络服务器的连接教程如下：

微软的 vpn 教学如下：

而如何让客户端拨号到 vpn 网络的方法也很简单，步骤如下：

开始 --> 连接到 --> 显示所有连接或者是控制面板 --> 网络连接 --> 新建连接 --> 选择连接到我的工作场所的网络 --> 虚拟专用网络连接 --> 输入一个你想要工作场所的名字（随意输入） --> 如果你是拨号上网的用户，最好选择自动的初始连接为你的拨号连接，其他的就无所谓的  --> 然后输入你的主机的 ip 地址就 ok 了。

最后就是双击这个新的连接，输入你设置的用户名和密码就好了。

这里我补充一点，很多人想过使用代理服务器来实现，但必须保证你的 skype 的通向外网的连接都通过这个服务器实现。

方法 2 ：

更简单，不需要设置什么 skype 专用的 vpn ，那就是使用 skype 的三方通话，首先让美加本地的一台电脑拨打你需要的那个号码，然后在邀请你的 skype 加入三方通话，这样你就可以实现拨打美加的电话了。其实这样也是很方便的，让对方的电脑给你开一个远程用户，你需要的时候只要登陆他的电脑，然后用 skype 拨打本地号码，接通后邀请国内的 skype 就可以了。

方法 3 ：

还有很多灵活的方法，大家也可以提供讨论一下，最后的方法就是找我咯， ^_^ ，写信或者留言给我都行。

2004 年 6 月 01 日

在这一节中，我们简要地描述了面向服务的体系结构的发展。然后，我们探究了面向组件的开发与面向服务的体系结构之间的关系，并且说明了如何将组件作为实现服务的基础设施。

虽然 it 经理一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。

在所有这些压力之下，有两个基本的主题：异构和改变。现在，大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品，因为改变应用程序套件和支持基础设施是如此之难。

在当今 it 经理面临的问题之中，改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争，产品周期缩短了，每个公司都想赢得超过竞争对手的优势。在竞争产品和可以从 internet 上获得的大量产品信息的推动下，客户要求更快速地进行改变。因而，在改进产品和服务方面展开的竞争进一步加剧了。

为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争激烈的环境中取得成功了，而 it 基础设施必须支持企业提高适应能力。

因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态系统业务范例发展。重点是扩展供应链，支持客户和凯发k8网页登录的合作伙伴访问业务服务。第 19 页的图 2-1 展示了企业的这种发展。

我如何使我的 it 环境更灵活且更快地响应不断改变的业务需求呢？ 我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢？我们如何达到企业目标而不使企业走向破产的深渊呢？

it 响应者/支持者是随着企业的这种发展而并行发展的，如图 2-2 所示。现在，许多 it 经理和专业人员都同样相信，我们真的快找到了一种满意的答案——面向服务的体系结构。

图 2-2 体系结构的发展

为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应该提供平台来构建具有下列特征的应用程序服务：

• 松散耦合
• 位置透明
• 协议独立

基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如 j2ee 或 .net）的技术规范不应该影响 soa 用户。如果已经存在一个服务实现，我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具有更好的服务质量。

自从“软件危机”促进软件工程的开创以来，it 界一直在努力寻求解决上述问题的方案。在过去几年里，下面简要概述的核心技术进展使我们走到了今天。我们将简要讨论这些核心技术，而我们重点关注的将是这些技术如何帮助解决 it 问题。

在“applying uml and patterns - an introduction to object-oriented analysis and design”中，larman 将面向对象的分析和设计的本质描述为“从对象（物体、概念或实体）的角度考虑问题域和逻辑凯发天生赢家一触即发官网的解决方案”。在“object-oriented softwareengineering: a use case driven approach”中，jacobson 等将这些对象定义为“特点在于具有许多操作和状态（记忆这些操作的影响）的物体”。

在面向对象的分析中，这样的对象是用问题域来标识和描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。

通过面向对象的分析和设计，可以封装对象（或对象组）的某些方面，以简化复杂业务场景的分析。为了降低复杂性，也可以抽象对象的某些特征，这样就可以只捕获重要或本质的方面。

基于组件的设计并不是一种新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。在应用程序开发和系统集成中，粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。通过这种方式，还可以将打包的凯发天生赢家一触即发官网的解决方案套件封装成这样的“组件”。

一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。可以将组件看作是打包、管理和公开服务的机制。它们可以共同使用一组技术：实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现

在“component-based development for enterprise systems”中，allen 涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。第 22 页的图 2-3 展示了重要的面向服务术语：

• 服务：逻辑实体，由一个或多个已发布接口定义的契约。
• 服务提供者：实现服务规范软件实体。
• 服务使用者（或请求者）：调用服务提供者的软件实体。传统上，它称为“客户端”。服务使用者可以是终端用户应用程序或另一个服务。
• 服务定位器：一种特殊类型的服务提供者，它作为一个注册中心，允许查找服务提供者接口和服务位置。
• 服务代理：一种特殊类型的服务提供者，它可以将服务请求传送到一个或多个其他的服务提供者。

在组件和服务开发中，都需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。因此，在基于组件和面向服务的系统中，“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义：

• 接口：定义一组公共方法签名，它按照逻辑分组但是没有提供实现。接口定义服务的请求者和提供者之间的契约。接口的任何实现都必须提供所有的方法。
• 已发布接口：一种可唯一识别和可访问的接口，客户端可以通过注册中心来发现它。
• 公共接口：一种可访问的接口，可供客户端使用，但是它没有发布，因而需要关于客户端部分的静态知识。
• 双接口：通常是成对开发的接口，这样，一个接口就依赖于另一个接口；例如，客户端必须实现一个接口来调用请求者，因为该客户端接口提供了某些回调机制。

第 23 页的图 2-4 定义了客户关系管理 (crm) 服务的 uml 定义，它表示为一个 uml 组件，实现接口 accountmanagement、contactmanagement 和 systemsmanagement。在这些接口中只有头两个接口是已发布接口，不过，后者是公共接口。注意，systemsmanagement 接口和 managementservice 接口构成了双接口。crmservice 可以实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。甚至有可能给特定类型的客户端提供不同或附加的服务。在一些运行时环境中，这样的功能也用于在单个组件或服务上支持相同接口的不同版本。

如前所述，面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法，但是您必须理解的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。一旦理解了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。第 24 页中的图 2-5 演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它更靠近应用程序的使用者）。为称呼系统的这一部分而创造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）。

面向服务的体系结构提供了一种方法，通过这种方法，可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和服务质量元素。第 25 页的图 2-6 展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。

注意：面向服务的体系结构堆栈可能是一个容易引起争议的问题，因为各方面的支持者已经提出了几种不同的堆栈。我们的堆栈不是作为服务堆栈提出的。我们之所以在此提出它，是因为我们想要搭建一个有用的框架，在本书的剩余章节中，我们将通过这个框架来组织对 soa 的讨论。

体系结构堆栈分成两半，左边的一半集中于体系结构的功能性方面，而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下：

功能性方面包括：

• 传输是一种机制，用于将来自服务使用者的服务请求传送给服务提供者，并且将来自服务提供者的响应传送给服务使用者。
• 服务通信协议是一种经过协商的机制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的内容进行沟通。
• 服务描述是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据。
• 服务描述实际可供使用的服务。
• 业务流程是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念。
• 服务注册中心是一个服务和数据描述的存储库，服务提供者可以通过服务注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。

服务质量方面包括：

• 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务质量两个区中都有策略功能。
• 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控制。
• 传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成。
• 管理是属性集，可以应用于管理提供的服务或使用的服务。

图 2-7 展示了面向服务的体系结构中的协作。这些协作遵循“查找、绑定和调用”范例，其中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在，注册中心就给使用者提供接口契约和服务的端点地址。下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。

面向服务的体系结构中的角色包括：

• 服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。
• 服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。
• 服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。

面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种（或多种）。面向服务的体系结构中的操作包括：

• 发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调用它。
• 发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
• 绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。

面向服务的体系结构中的构件包括：

• 服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。
• 服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量 (qos) 级别。

除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构还具有以下特征：

• 服务是自包含和模块化的。
• 凯发k8网页登录的服务支持互操作性。
• 服务是松散耦合的。
• 服务是位置透明的。
• 服务是由组件组成的组合模块。

这些特征也是满足电子商务按需操作环境的要求的主要特征，如第 301 页“e-business on demand and service-oriented architecture”所定义的。

最后，我们需要说明的是，面向服务的体系结构并不是一个新的概念。如图 2-8 所示，面向服务的体系结构所涉及的技术至少包括 corba、dcom 和 j2ee。面向服务的体系结构的早期采用者还曾成功地基于消息传递系统（如 ibm websphere mq）创建过他们自己的面向服务企业体系结构。最近，soa 的活动舞台已经扩展到包括 world wide web (www) 和 web 服务。

在面向服务的体系结构中，映射到业务功能的服务是在业务流程分析的过程中确定的。服务可以是细粒度的，也可以是粗粒度的，这取决于业务流程。每个服务都有定义良好的接口，通过该接口就可以发现、发布和调用服务。 企业可以选择将自己的服务向外发布到业务凯发k8网页登录的合作伙伴，也可以选择在组织内部发布服务。服务还可以由其他服务组合而成。

服务是粗粒度的处理单元，它使用和产生由值传送的对象集。它与编程语言术语中的对象不同。相反，它可能更接近于业务事务（如 cics 或 ims 事务）的概念而不是远程 corba 对象的概念。

服务是由一些组件组成的，这些组件一起工作，共同提供服务所请求的业务功能。因此，相比之下，组件比服务的粒度更细。另外，虽然服务映射到业务功能，但是组件通常映射到业务实体和操作它们的业务规则。作为一个示例，让我们看一看 ws-i 供应链管理（ws-i supply chain management）样本的定购单（purchaseorder）组件模型，如图 2-9 所示。

在基于组件的设计中，可以创建组件来严格匹配业务实体（如顾客（customer）、定购单（purchase order）、定购项（order item）），并且封装匹配这些实体所期望的行为的行为。

例如，定购单（purchase order）组件提供获取关于已定购的产品列表和定购的总额的信息的功能；定购项（order item）组件提供获取关于已定购的产品的数量和价格的信息的功能。每个组件的实现都封装在接口的后面。因此，定购单（purchase order）组件的用户不知道定购单（purchase order）表的模式、计算税金的算法、以及定单总额中的回扣和/或折扣。

在面向服务的设计中，不能基于业务实体设计服务。相反，每个服务都是管理一组业务实体中的操作的完整单元。例如，顾客服务将响应来自任何其他系统或需要访问顾客信息的服务的请求。顾客服务可以处理更新顾客信息的请求；添加、更新、删除投资组合；以及查询顾客的定单历史。顾客服务拥有所有与它管理的顾客有关的数据，并且能够代表调用方进行其他服务查询，以提供统一的顾客服务视图。这意味着服务是一个管理器对象，它创建和管理它的一组组件。

如前所述，企业正在处理两个问题：迅速地改变的能力和降低成本的要求。为了保持竞争力，企业必须快速地适应内部因素（如兼并和重组）或外部因素（如竞争能力和顾客要求）。需要经济而灵活的 it 基础设施来支持企业。

我们可以认识到，采用面向服务的体系结构将给我们带来几方面的好处，有助于我们在今天这个动荡的商业环境中取得成功：

soa 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在 it 方面的投资，方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值，而不必重新从头开始构建。

在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现透明性，并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易于管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得更加重要。

从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的组织提供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发生命周期（包括收集需求、进行设计、开发和测试）所需的时间。这使得可以快速地开发新的业务服务，并允许组织迅速地对改变做出响应和减少上市准备时间。

通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增加。

通过 soa，企业可以未雨绸缪，为未来做好充分的准备。soa 业务流程是由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不同时期的需要。

soa 提供了灵活性和响应能力，这对于企业的生存和发展来说是至关重要的。但是面向服务的体系结构决不是灵丹妙药，而迁移到 soa 也并非一件可以轻而易举就完成的事情。请别指望一个晚上就将整个企业系统迁移到面向服务的体系结构，我们推荐的方法是，在业务要求出现或露出苗头时迁移企业功能的适当部分。

原始 url:

这两天看到了一篇不错的关于 soa 的文章，不敢独享，只可惜是 e 文，所以抽空翻译了一下，跟大家分享。

以下为本博客使用说明

我们的 blogjava 博客特别为大家的方便阅读提供了以下快捷功能：

需要查找关键字―――――――――――――――――请按 ctrl ＋ f

想以后还能看（添加到收藏夹）――――――――――请按 ctrl ＋ d

想刷新一下网页内容―――――――――――――――请按 f5

（应该不需要的，因为 blogjava 已经完全实现了 ajax ）

想保存到硬盘上―――――――――――――――――请按 ctrl ＋ s

需要调用本地（ jini ）服务查看源代码――――――――在网页空白处点击鼠标右键＋ v

不想看了――――――――――――――――――――请按 alt ＋ f4

如果是标签页浏览器―――――――――――――――请按 ctrl ＋ w

实话说，我们比 google 的 gmail 还早实现方便的快捷方式，厉害吧。这里不需要对我表示敬意，只需要对博客的建设者 dudu 老兄留言表示一下感谢就好了。

在开始的时候先介绍一下 soa 的概念。

什么是 soa ？

soa 的全称是 service oriented architecture ，面向服务架构。

她是指为了解决在 internet 环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。这句话的意思就是 soa 不是一门语言或具体的技术，而是一种软件的系统架构，应该说更像一种模式，是一种为了解决复杂的 internet 业务应用而提出的一种体系结构（在我感觉里，这种架构的提出更像 mvc 模式的提出，不过我们总喜欢用模式啊，架构啊的话来体现自己是行业内专业的人，但其实无论说是模式还是架构，这都只是一些名词，如果组合现拥有的技术去实现自己的应用才是最有用的，就不用多谈所谓的架构还是模式了）。

译文 ( 翻译：陈朋奕，如果有错误请来我的博客指出 ) ：

在做软件开发的人，架构这个词经常被用在三种不同的场合中：应用体系架构（ application architecture ），基础体系架构 (infrastructure architecture) 以及企业架构体系 (enterprise architecture) 。而 soa 的概念横跨了这三种体系，然而很多人在谈到 soa 的时候总喜欢不自觉的把 soa 跟其中的一种混为一谈。

譬如开发者大多对如何建立 soa 应用感兴趣，因此他们关注的趋向更多是 soa 中的应用程序的体系架构方面。而 web serivces 管理工具的卖主一般认为 soa 主要是关于基础组件体系结构的，同样的，用户群体会认为 soa 是用于企业业务应用结构的。

这三种观点都是有意义的，因为这映射了 soa 的三个应用层面。下面是关于这三个方面的一些简单的讲解：

―――― soa 应用体系架构：是建立 soa 服务的指导、模式以及实现的方法。关注面向服务软件平台和个体应用的开发者会特别强调这个方面。如 microsoft’s windows communication foundation （ wcf 微软视窗通讯基础组件）以及最近提出的 service component architecture (sca 服务构件体系 ) 就是跟 soa 这个方面的应用实现。

―――― soa 基础体系架构：是管理和操作 soa 服务的指导、模式以及实现的方法。 soa 的大思想家们有时也会承认自己在这个方面有不足，但真正去实现这些功能的人却知道这些方面的重要性。一般来说，卖主会特别喜欢把关注点和行动实现集中在这里。

―――― soa 业务体系架构：利用 soa 并从 soa 中获得商业利益的指导、模式以及实现的方法。而关于技术的讨论仍然会在这里出现，但更多的关注点已经转移到了人的身上（以人为本？事实上，我对 soa 面临的最大挑战是人的观点——人通常比技术更多问题——有一些自己的看法）。不过，来自 zapthink 的分析家们通常对 soa 提出的建议都是在强调这个方面。

       我看到过很多人关于 soa 的意义（甚至是价值）的争论，其实他们的争论只是关于应用程序体系架构主导还是企业体系架构主导而已。这些专业术语仅仅是在我们都认同的情况下才会体现其价值的，因此当别人在讨论这个被过度使用的术语的时候我们应该保持清晰的思路，清楚我们到底讲的是什么才是我们应该把握的方向。

也许这正是 java 无奈现状的体现吧，本来是大户人家的宝贝，现在变成沦落荒野的野马，要跟荒原的狐狗抢食 …… 在桌面程序上面，出了 ibm 那么热心的开发了 eclipse 之外，似乎 java 毫无建树，而 web 上， java 更是被 .net 和其他带脚本性质的语言蚕食领地， .net 当然是没话说的，因为这可是大户人家的孩子，身上带着微软皇族的血统，背靠如此雄厚的资本，自然不会弱，而 php/python 等语言也以其灵活的结构和多年积累的成熟的多样的开发框架一步一步的侵食 java 的领地，我想让 java 世界最痛心的也许不是这些，而是由 ruby 语言引起的 java 世界的内讧 ……

对 ruby 这门语言，说实话，我真的不以为然，甚至觉得这不算语言。当初学习 java 的时候，是从 c 语言转过来的， java 给我的印象真的太美丽了，那么美妙的结构，竟然能如此完美的用程序语言去体现世界。而接触 ruby ，一点也没有接触 java 时候的那种感觉，但是我不得不承认 ruby on rails 真的是快捷而且方便的 web 开发平台。那么轻松的几百行代码就能够完成 java （ jsp servlet ）上千行代码（有个朋友跟我说，他尝试过将一个 java 的简单 web 程序，据说好像是网上商城，改到 ruby 平台，上 4 ～ 5 千行的 java 代码，仅仅用了 800 行 ruby 代码）。这样的结果难道还不够震撼吗？

java 语言的优美是大家公认的，但如果是为了仅有的优美而付出大量的劳动，真的必要吗？也许正如 lansa 公司的高级程序设计师 roc.chen 说的那样， java 更适合在学校里进行 oo 软件的教学，因为他真的很美丽。当年 smalltalk 也是很优美的语言，为什么还是没有流行呢？语言的流行程度也许真的跟优美有否没有直接关系，想来 vb 真的是一门很烂的语言，但如此流行，也不能不承认这个道理的正确性了。

也许改名是因为要将 java 这个重量级的语言从吃遍四方的笨重的老虎变成可以轻松跑跳的野马吧，现在 java 的世界太笨重了，有复杂的 ejb ，多种不互相兼容开发模式（ tomcat/sunj2ee 等下各有各的开发模式），多个巨头在做自己不同的ide（eclipse /net beans/ idea/ j builders/ workshop等），多个企业在做自己的j2ee服务器（geronimo /web sphere/ weblogic等）……意见经常不能统一，在这点上我真的认同微软的方式，这样至少使用的人能很快的上手，能更快更好的完善自己的开发模式和开发平台。

我觉得 java 已经在让自己变得轻量级，变得灵巧了，让自己在各个方面都能适应快速开发，就像现在的 ruby 一样，而 spring 的受欢迎程度和《 j2ee without ejb 》的热卖也说明了这点。也许 ruby 语言的出现对 java 来说是好事，因为至少这打击不是致命的，能让 java 的设计者痛定思痛，寻求变革。

这 java 6 mustang 的出现也许正是为了这个目的吧。那下面就说说 java 6 的特点吧：

l         支持 web service （ java web 的开发心头之痛啊，终于搞定了）

l         提高 jvm 性能，对比 java 5.0 ， mustang hotspot jvm 有 58 ％的性能提升（早该如此了， java 的诟病就是慢，但我还没尝试过）

l         直接嵌入 jsr-223 规定的脚本语言

l         增加对 javascript 的支持，嵌入了 rhino （即 javascript ）解释器（好东西来的，也许是因为 ruby 内置的 ajax 对其的影响吧）

l         支持 jdbc 4 规范

l         扩展 java.io.file ，充分利用磁盘空间

l         安全上新增了对 xml 数字签名的支持，整合 java generic security services 及 kerberos ，支持国际域名和资源标识符和网络参数标题访问

l         还有好多，不过就没前面的那么重要了

sun 已经提供了演示版本的下载，我已经下载了，同时也下载了 sun 的 net beans ide ，准备对这个新的 jdk 进行测试，测试结果会以最快的速度向同志们报告。
===============================================================================
/听了白痴兄弟的话，想说几句话/
上面只是我一个人的看法，也只是随便说说而已，犯不着大家这么生气的。况且这仅仅是晚上涂鸦写写，告诉大家一些消息，评论只是个人观点。 

股利信号传递理论的实证分析工作由林特（john lintner，1956）首先研究。林特通过对美国600家上市公司财务经理的问卷调查和实证分析，得出股利传递公司盈利信号内容的实证结果。他认为，在1946—1954年间，美国各上市公司一般都保持一个长期的目标股利支付率，公司的股利变化与长期可持续的净收益水平相一致；公司管理者特别注重股利水平的变化，除非管理者确信公司增长的收益足以支付长期增加的股利时，才会增发股利，并且，公司管理者不会轻易削减股利。

股利分配代理成本理论。该理论是由詹森、迈克林（jensen and meckling，1976）和伊斯特布鲁克（easterbrook，1984）创立的。詹森和迈克林以委托—代理理论为研究框架，通过研究公司股东、管理者和债权人三者的利益动机及分配关系，得出股利分配代理成本理论。他们认为，股东为避免自身利益损失，要监督和约束管理者的行为，势必导致代理成本的发生。但股东越保守，代理成本就越高，对债权人就越有利，对股东就越不利。因此，股东需要在这两者之间平衡利弊得失。伊斯特布鲁克认为，股利支付可以降低代理成本。股东可以通过保持一个稳定不变的股利支付水平，以避免权益资本的累积，同时，又促使企业向外部筹资。这就迫使管理者必须全力以赴经营企业，才能以优良的业绩在资本市场上筹集资金。结果，股东可以通过调节企业的负债比例来降低代理成本，以实现自身利益最大化。这就解释了为什么有些公司在发放股利的同时又对外筹资的现象。

股利顾客效应理论。该理论最先也是由米勒和莫迪格利安尼提出来的。他们注意到，有些股东偏好未来的资本利得，从而购买当期股利支付率低但成长性好的股票；有些股东则倾向于当期股利收入，因而喜欢股利支付高的股票，即所谓的股利顾客效应。mm认为，既然公司不可能同时满足所有股东的利益要求，公司就不必考虑股东对股利的具体意愿，而应根据自身的特点制定适合企业生产经营需要的股利政策，并且自然有一批投资者偏好公司的股票。