博客园-大兵的网上家园

property.js

大兵 — Fri, 15 Aug 2008 06:50:00 GMT

摘要: CodeCode highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->***********************************************property.js实例详解(一)********************************* 阅读全文

[新闻]微软Office 14即将展开Alpha测试

XML与DataTable互转

大兵 — Tue, 12 Aug 2008 08:15:00 GMT

摘要: 今天项目组有人问我这个问题。简单实现了一下，有人需要，拿去。CodeCode highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->1classtest2{34publicstaticDataTableGetDataTable(stringxmlStr)5{6XmlD 阅读全文

[新闻]《星际争霸2》新图

实战之数据结构篇（线性表，堆栈与队列）

大兵 — Tue, 12 Aug 2008 02:25:00 GMT

摘要: 1：定义线性表（Linear List）是具有相同特性的数据元素的一个有限序列。该序列中所含元素的个数称作线性表的长度。堆实际上指的就是（满足堆性质的）优先队列的一种数据结构，第1个元素有最高的优先权栈实际上就是满足先进后出的性质的数学或数据结构。（虽然堆栈，堆栈的说法是连起来叫，但是他们还是有很大区别的，连着叫只是由于历史的原因。）队列　是一种特殊的线性表，它只允许在表的前端（fr 阅读全文

[新闻]《星际争霸2》新图

项目文档之（详细设计说明书）

大兵 — Mon, 11 Aug 2008 03:05:00 GMT

1：组成

A：引言

a：编写目的（文档使用的人员）

b：项目背景（项目相关信息）

c：定义（文档中出现的名词解释）

d：参考资料

B：模块1

描述

功能

性能

输入项

输出项

存储分配

流程逻辑

接口

算法

注释设计

限制条件

测试计划

尚未解决的问题

2：模板

详细设计说明书

[新闻]Google放出Android开发路线图

项目文档之需求说明书

大兵 — Mon, 11 Aug 2008 02:40:00 GMT

1：文档的构成

A：引言（文档信息）

a：编写目的（记录文档存在的意义和指出文档使用的人员）

b：范围（包含待开发系统的名称以及问题的提出和设计实现者）

c：定义（文档中个别名词的解释）

d：参考资料

B：项目概述（项目信息）

a：产品描述

b：产品功能（推荐列出产品功能模块列表）

c：用户特点（特别计算机能力，这回设计到软件的输入设计）

d：一般约束

e：假设和依据

C：具体需求

a：具体需求1

1：引言（模块描述）

2：用例模型（模块序列图）

3：用户角色（使用者）

4：事件流（模块操作流程）

5：数据加工（模块从输入到输出数据的转化过程）

6：前置条件（启动该模块需要满足的条件）

7：后置条件（模块结束对软件的影响）

8：UI设计（输入和输出界面）

2：模板

软件需求文档

[新闻]Google放出Android开发路线图

项目文档书写（序）

大兵 — Mon, 11 Aug 2008 02:19:00 GMT

写代码已经有5个年头了，刚进入这行的时候以为代码就是设计，用大量的时间和精力去实践程序的每个分支，头破血流之后完成了一个个令自己不满意的设计。每当静下心来的时候就想”为什么不提前想到这些那？“。

软件开发非常复杂，只经过一个流程显然是不够的。软件开发应该在宏观上有两套流程即设计和开发。开发的意义不言而喻而设计往往得不到应有的重视。在我以为设计拉近我们和问题的距离，强化问题的环境，让我们进入到软件的环境中去为以后的开发做一次探索。这种探索是很有必要的而这种探索的过程就是本文所有涉及的过程即文档书写。

软件开发过程中设计的文档很多，像"测试分析报告","操作手册","测试计划","概要设计说明书","软件配置管理计划","需求说明","软件质量保证计划","数据库设计","详细设计说明书","项目开发总结","用户手册"等这些文档多从不同角度对问题域的探索做个记录。当我们认真完成这些文档的时候。问题域的环境已经在我们的意识中建立起来，接下来就是我们利用我们的专业技能对这个环境给与实现了。但这些文档我们不必要面面具到，通常我们只会对几种文档重视起来。依据项目开发的过程列出这些文档并给与详细的描述。

1：可行性分析

2：开发计划

3：需求说明书

4：详细设计说明书

5：测试计划

6：部署

7：验收

[新闻]Google放出Android开发路线图

行列转换（Oracle）

大兵 — Tue, 05 Aug 2008 09:47:00 GMT

假如有如下表，其中各个i值对应的行数是不定的

SQL> select * from t;

   I A D
---------- ---------- -------------------
   1 b 2008-03-27 10:55:42
   1 a 2008-03-27 10:55:46
   1 d 2008-03-27 10:55:30
   2 z 2008-03-27 10:55:55
   2 t 2008-03-27 10:55:59

要获得如下结果，注意字符串需要按照D列的时间排序：

1 d,b,a
2 z,t

这是一个比较典型的行列转换，有好几种实现方法

1.自定义函数实现

create or replace function my_concat(n number)
return varchar2
is
type typ_cursor is ref cursor;
v_cursor typ_cursor;
v_temp varchar2(10);
v_result varchar2(4000):= '';
v_sql varchar2(200);
begin
v_sql := 'select a from t where i=' || n ||' order by d';
open v_cursor for v_sql;
loop
   fetch v_cursor into v_temp;
   exit when v_cursor%notfound;
   v_result := v_result ||',' || v_temp;
end loop;
return substr(v_result,2);
end;

SQL> select i,my_concat(i) from t group by i;

   I MY_CONCAT(I)
---------- --------------------
   1 d,b,a
   2 z,t

虽然这种方式可以实现需求，但是如果表t的数据量很大，i的值又很多的情况下，因为针对每个i值都要执行一句select，扫描和排序的次数和i的值成正比，性能会非常差。

2.使用sys_connect_by_path

select i,ltrim(max(sys_connect_by_path(a,',')),',') a
from
(
select i,a,d,min(d) over(partition by i) d_min,
(row_number() over(order by i,d))+(dense_rank() over (order by i)) numid
from t
)
start with d=d_min connect by numid-1=prior numid
group by i;

从执行计划上来看，这种方式只需要扫描两次表，比自定义函数的方法，效率要高很多，尤其是表中数据量较大的时候：

3.使用wm_sys.wm_concat

这个函数也可以实现类似的行列转换需求，但是似乎没有办法做到直接根据另外一列排序，所以需要先通过子查询或者临时表排好序

SQL> select i,wmsys.wm_concat(a) from t group by i;

   I WMSYS.WM_CONCAT(A)
---------- --------------------
   1 b,a,d
   2 z,t

SQL> select i,wmsys.wm_concat(a)
2 from
3 (select * from t order by i,d)
4 group by i;

   I WMSYS.WM_CONCAT(A)
---------- --------------------
   1 d,b,a
   2 z,t

执行计划上看，只需要做一次表扫描就可以了，但是这个函数是加密过的，执行计划并不能显示函数内部的操作。

不知道大家还有没有更加高效的实现方式，欢迎指教^_^

[新闻]番茄花园作者被警方逮捕

大牛的文章集锦

大兵 — Fri, 01 Aug 2008 08:02:00 GMT

[新闻]WordPress和Movable Type影响社交网站的未来

控制反转容器&依赖注入模式(转)

大兵 — Wed, 30 Jul 2008 09:43:00 GMT

摘要: 轻量级容器在Java社区近来可是风起云涌，这些容器能将来自不同项目的逐渐集结为一个内聚的应用程序。这些容器都是基于一个共同的模式，这个模式决定了容器如何完成组件装配，人们统称之为：“控制反转” "Inversion of Control"。本文将深入探讨这个模式的工作机制，并给它一个具体的名字：“依赖注入”Dependency Injection，并阅读全文

[新闻]谷歌平台手机获准上市

聪明人必做的 10 件事

大兵 — Wed, 30 Jul 2008 09:26:00 GMT

一、储蓄友谊

靠得住的友谊是今生最温暖的一件外套。它是靠你的人品和性情打造的，一定要好好地珍惜它，如果到目前为止，还没有几笔，那么，从现在用心去储存还来得及。

二、学会放手

这个年龄已经不允许不成熟，当你无力把握命运中的某种爱、某种缘、某种现实，就要学会放手。给自己一个全新的开始，只要信心在，勇气就在；努力在，成功就在。

三、播种善良

一定要极尽自己所能，让那些比你苦、比你难过的人感受到这世上的阳光和美丽。这样的善良常常是播种，在不经意间，就会开出最美丽的人性之花。

四、懂得音乐

一定要学会一种乐器，它会洗涤你的身心，打开你的记忆和想象，更会带来意想不到的宁静。另外还有摄影、收藏，它们都能让我们的生活增添滋味。

五、避开两种苦

尘世间有两苦，一是得不到之苦，二是钟情之苦。前者在你付诸努力的前提下，就把一切当作一场赌，胜之坦然，败之淡然，好在这年龄还有一定的资本得以卷土重来；至于后者可说是世间最苦，如果把这时还有这样的情愫，一定要像清除灰尘般，把它从心屋里扫出去。

六、学会承受

有些事情需要无声无息地忘记，经过一次，就长一次智慧；有些苦痛和烦恼得要默默地承受；历炼一次；就丰富一次。这个年龄不该再像小时候那样大喊大叫，痛哭流涕。

七、常怀感恩心

当我们参加完葬礼，总会涌起一些感慨；当我们大病初愈，总会有万般珍惜。

感恩的心一定要时时保留，它不仅让你怜惜身边事物，还能平抚欲望和争斗，甚至幸福的感觉也往往源自于此。

八、热爱工作

尽管它不像喝茶、聊天那般惬意，但它检验着我们的智慧和能力，得以让我们体现价值及获得成就。一定要全心爱它，毕竟它让你大半生有事做、有饭吃。

九、勤于学习

读书和学习都是在和智能聊天，每年至少要读五十本书，它不仅保证你的记忆力、感悟力，还能让你维持个性魅力，这可是练瑜珈做美容所不能达到的效果。

十、享受运动

善用时间运动、享受自然。你的体重就不会因懒惰而上涨，你的容貌也不会因岁月而减少生动，在某种程度上更能保存青春、快乐与健康。

[新闻]谷歌平台手机获准上市

少走弯路的10条忠告

大兵 — Wed, 30 Jul 2008 09:26:00 GMT

如何在涉世之初少走弯路，有一个好的开端，开始一番成功的事业？以下是一些先行者积累的10条有益的涉世忠告。好好地遵循、把握这些忠告和建议吧，比起所学的课堂课程来，它毫不逊色！

1. 买个闹钟，以便按时叫醒你。

贪睡和不守时，都将成为你工作和事业上的绊脚石，任何时候都一样。不仅要学会准时，更要学会提前。就如你坐车去某地，沿途的风景很美，你忍不住下车看一看，后来虽然你还是赶到了某地，却不是准时到达。“闹钟”只是一种简单的标志和提示，真正灵活、实用的时间，掌握在每个人的心中。

2. 如果你不喜欢现在的工作，要么辞职不干，要么就闭嘴不言。

初出茅庐，往往眼高手低，心高气傲，大事做不了，小事不愿做。不要养成挑三拣四的习惯。不要雨天烦打伞，不带伞又怕淋雨，处处表现出不满的情绪。记住，不做则已，要做就要做好。

3. 每个人都有孤独的时候。

要学会忍受孤独，这样才会成熟起来。年轻人嘻嘻哈哈、打打闹闹惯了，到了一个陌生的环境，面对形形色色的人和事，一下子不知所措起来，有时连一个可以倾心说话的地方也没有。这时，千万别浮躁，学会静心，学会忍受孤独。在孤独中思考，在思考中成熟，在成熟中升华。不要因为寂寞而乱了方寸，而去做无聊无益的事情，白白浪费了宝贵的时间。

4. 走运时要做好倒霉的准备。

有一天，一只狐狸走到一个葡萄园外，看见里面水灵灵的葡萄垂涎欲滴。可是外面有栅栏挡着，无法进去。于是它一狠心绝食三日，减肥之后，终于钻进葡萄园内饱餐一顿。当它心满意足地想离开葡萄园时，发觉自己吃得太饱，怎么也钻不出栅栏了。相信任何人都不愿做这样的狐狸。退路同样重要。饱带干粮，晴带雨伞，点滴积累，水到渠成。有的东西今天似乎一文不值，但有朝一日也许就会身价百倍。

5. 不要像玻璃那样脆弱。

有的人眼睛总盯着自己，所以长不高看不远；总是喜欢怨天尤人，也使别人无比厌烦。没有苦中苦，哪来甜中甜？不要像玻璃那样脆弱，而应像水晶一样透明，太阳一样辉煌，腊梅一样坚强。既然睁开眼睛享受风的清凉，就不要埋怨风中细小的沙粒。

6. 管住自己的嘴巴。

不要谈论自己，更不要议论别人。谈论自己往往会自大虚伪，在名不副实中失去自己。议论别人往往陷入鸡毛蒜皮的是非口舌中纠缠不清。每天下班后和你的那些同事朋友喝酒聊天可不是件好事，因为，这中间往往会把议论同事、朋友当做话题。背后议论人总是不好的，尤其是议论别人的短处，这些会降低你的人格。

7. 机会从不会“失掉”，你失掉了，自有别人会得到。

不要凡事在天，守株待兔，更不要寄希望于“机会”。机会只不过是相对于充分准备而又善于创造机会的人而言的。也许，你正为失去一个机会而懊悔、埋怨的时候，机会正被你对面那个同样的“倒霉鬼”给抓住了。没有机会，就要创造机会，有了机会，就要巧妙地抓住。

8. 若电话老是不响，你该打出去。

很多时候，电话会给你带来意想不到的收获，它不是花瓶，仅仅成为一种摆设。交了新朋友，别忘了老朋友，朋友多了路好走。交际的一大诀窍就是主动。好的人缘好的口碑，往往助你的事业更上一个台阶。

9. 千万不要因为自己已经到了结婚年龄而草率结婚。

想结婚，就要找一个能和你心心相印、相辅相携的伴侣。不要因为放纵和游戏而恋爱，不要因为恋爱而影响工作和事业，更不要因一桩草率而失败的婚姻而使人生受阻。感情用事往往会因小失大。

10. 写出你一生要做的事情，把单子放在皮夹里，经常拿出来看。

人生要有目标，要有计划，要有提醒，要有紧迫感。一个又一个小目标串起来，就成了你一生的大目标。生活富足了，环境改善了，不要忘了皮夹里那张看似薄薄的单子。

[新闻]谷歌平台手机获准上市

创建以Microsoft .NET Remoting为基础的分布式应用架构

大兵 — Wed, 30 Jul 2008 01:34:00 GMT

引言

在论坛里经常看见有人问：使用.NET Remoting如何从服务器主动发出事件通知客户端？的确，初接触.NET Remoting的人多半会有这样的疑问，因为大部分的文章和书籍在介绍.NET Remoting时都只介绍了通道，对象，激活和生存周期等等概念，在谈到如何进行远程通信的时候，都只告诉读者如何从客户端激活一个服务器对象然后传递参数调用其方法。所以很多读者都不太清楚如何从服务器向客户端广播信息，甚至有很多人认为跟WEB服务器不能主动发送信息到浏览器一样，.NET Remoting同样也不能这么做，只能采用"客户端发出请求->服务器回复响应"这种简单的通讯模式，以至于在需要服务器对客户端广播信息时设计出两端都放上Server和Client对象的复杂架构，既麻烦又容易出错。

其实.NET Remoting远程处理完全支持事件驱动的编程和使用同步和异步委托的回调函数。在.NET Remoting中你可以方便的采用事件注册远程回调函数，并方便的利用这种机制将服务器端信息广播到客户端。下面将向读者详细介绍这种分布式多点广播应用程序架构的编写方法。

网络物理结构图

上面便是网络结构示意图，之所以说它是一个典型的分布式应用架构是因为基于这种网络结构十分常见，在证券交易，期货行情，视频会议，远程教学等许多方面都能派上用场。

架构设计

为了形象化抽象的概念，我们先来了解一下电视广播的工作流程，再结合我们的程序理解架构设计的主要思想。

电视广播的流程是由以下四个主要机构参与其中：

1. 节目制作部门。负责制作电视节目。

2. 转播间。负责安排节目制作部门提供的节目的广播方式。

3. 电视塔。负责将电视信号转化为无线电波发送出去。

4. 电视机。负责接受无线电信号并转换成可视的图象。

在我们的程序中也是由四个主要的对象组成，它们的名称和用途分别是：

1. Announcer：信息发送对象。负责发送原始信息，相当于电视节目制作部门。

2. InfoCenter: 信息中心。负责管理信息广播机制。相当于转播间。

3. Server：服务器。管理传送通道，负责发送广播数据流。相当于电视塔。

4. Receiver：接受器。接受广播数据流，转换成我们可以理解的信息格式。相当于电视机。

对象结构如下图所示：

程序设计

首先我们来看一下信息中心InfoCenter对象的编写方法（InfoCenter.cs）：

using System;
using System.Runtime.Remoting;
namespace Distribution_Framework
{
//定义广播事件的参数类
[Serializable]
public class BroadcastEventArgs : EventArgs
{
private string msg = null;
public BroadcastEventArgs(string message)
{
msg = message;
}
public string Message
{
get
{
return msg;
}
}
}
public delegate void BroadcastEventHandler(object sender, BroadcastEventArgs submitArgs);
public class InfoCenter : MarshalByRefObject
{
public InfoCenter()
{
Console.WriteLine("InfoCenter created.");
}
public override object InitializeLifetimeService()
{
return null;
}
public event BroadcastEventHandler Broadcaster;
public void Broadcasting(string message)
{
BroadcastEventArgs e = new BroadcastEventArgs(message);
if (Broadcaster != null)
{
Broadcaster(this, e);//发出事件
Console.WriteLine("Broadcast:" + e.Message);
}
}
}
}

要点说明：

public delegate void BroadcastEventHandler(object sender, BroadcastEventArgs submitArgs);

定义了一个事件处理委托及其参数格式。

public event BroadcastEventHandler Broadcaster;

请注意，这一句定义了一个公共事件，需要接受广播信息的远程对象可以通过这个事件向InfoCenter注册使用BroadcastEventHandler委托的远程回调函数。这个机制有点类似有线受费电视，你如果需要收看电视台提供的电视节目请先来登记。

接下来看看Server对象的实现（Server.cs）：

using System;
using System.Runtime.Remoting;
namespace Distribution_Framework
{
class Server
{
public static void Main(string[] Args)
{
RemotingConfiguration.Configure("Server.exe.config");
Console.WriteLine("Server is running, Press Enter key to exit.");
Console.ReadLine();
}
}
}

呵呵，是不是跟电视塔一样简单？基本上除了"天线"就没别的了。：）

下面是它的配置文件（Server.exe.config）：

电视广播站已经架设好了，我们再来看看"电视机"是怎么做的（Receiver.cs）：

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
namespace Distribution_Framework
{
class Receiver : MarshalByRefObject
{
InfoCenter infoCenter;
public Receiver()
{
}
public override object InitializeLifetimeService()
{
return null;
}
public void Run()
{
RemotingConfiguration.Configure("Receiver.exe.config");
infoCenter = new InfoCenter();
//订阅信息
infoCenter.Broadcaster += new BroadcastEventHandler(this.BroadcastReceiver);
Console.WriteLine("Ready to Recieve Message...");
Console.ReadLine();
//取消订阅
infoCenter.Broadcaster -= new BroadcastEventHandler(this.BroadcastReceiver);
}
public void BroadcastReceiver(object sender, BroadcastEventArgs args)
{
Console.WriteLine("Received:" + args.Message);//打印接收信息
}
public static void Main()
{
Receiver receiver = new Receiver();
receiver.Run();
}
}
}

要点说明：

infoCenter.Broadcaster += new BroadcastEventHandler(this.BroadcastReceiver);

还记得我们在InfoCenter中定义的那个Broadcaster事件吗？这里就是如何向它注册一个远程回调函数，相当于登记收看电视节目了。不想看了的话记得要向它取消登记哦，infoCenter.Broadcaster -= new BroadcastEventHandler(this.BroadcastReceiver);不然多收了你的钱可别耍赖。：）

public void BroadcastReceiver(object sender, BroadcastEventArgs args)
{
Console.WriteLine("Received:" + args.Message);
}

这个就是被服务器端远程回调的函数。

另外要注意的是，这个客户对象也必须要从MarshalByRefObject继承，原因很简单，因为它相对于服务器来说也是一个需要进行序列化调用的远程对象。

下面是它的配置文件（Receiver.exe.config）：

请注意，port="0"表示由计算机自动选取一个最合适的端口。

我们现在电视机也有了，就差有人来送节目播放了，下面就是"电视节目制作部"的代码(Announcer.cs)：

using System;
using System.Timers;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
namespace Distribution_Framework
{
class Announcer
{
InfoCenter infoCenter;
public static void Main(string[] Args)
{
Announcer announcer = new Announcer();
announcer.Run();
Console.WriteLine("The announcer has been started.");
Console.ReadLine();
}
public void Run()
{
RemotingConfiguration.Configure("Announcer.exe.config");
infoCenter = new InfoCenter();
Timer timer = new Timer(1000);
timer.Elapsed += new System.Timers.ElapsedEventHandler(this.timer_Elapsed);
timer.Enabled = true;
}
private void timer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
string msg = "The Time is: " + DateTime.Now.ToString();
Console.WriteLine("Send Message:" + msg);
infoCenter.Broadcasting(msg);
}
}
}

在这里，我们定义了一个定时器，每隔一秒种便向服务器发送一个计算机本地时间字符串信息，我们终于有可以收到的节目了，虽然是简单了点。另外，请注意，就象我们可以接收很多电视频道一样，发送者并没有规定只能有一个，事实上我们的确可以添加许多发送者，不过要注意线程之间的同步问题。

下面是它的配置文件（Announcer.exe.config）：

眼明的读者一下就看出来了，这个跟Receiver的配置文件一模一样，其实它们本来就都是客户端，配置文件当然是一样的。

最后，我们用下列命令将它们编译成可执行文件：

csc /t:library infocenter.cs
csc /r:infocenter.dll server.cs
csc /r:infocenter.dll receiver.cs
csc /r:infocenter.dll announcer.cs

请先运行Server.exe然后再运行Announcer.exe，最后你可以多打开几个Receiver，观察它们的工作情况。注意，如果你需要在不同的计算机上向别人演示这个程序的话，请将配置文件中的localhost改成相应的计算机名称或者是IP地址，而无须重新编译。

总结

使用.NET编程总是这么简单和有趣，在上例中，你几乎看不到什么关于"远程"的特殊代码，它非常接近于普通的程序调用，事实上，如果没有进行对 RemotingConfiguration.Configure() 的调用，你根本就不需要进行任何修改即可在单个应用程序域中编译和运行整个应用程序。

[新闻]谷歌平台手机获准上市

几句话

大兵 — Mon, 28 Jul 2008 01:34:00 GMT

1、有些事，我们明知道是错的，也要去坚持，因为不甘心；有些人，我们明知道是爱的，也要去放弃，因为没结局；有时候，我们明知道没路了，却还在前行，因为习惯了。
2、以为蒙上了眼睛，就可以看不见这个世界；以为捂住了耳朵，就可以听不到所有的烦恼；以为脚步停了下来，心就可以不再远行；以为我需要的爱情，只是一个拥抱。
3、那些已经犯过的错误，有一些是因为来不及，有一些是因为刻意躲避，更多的时候是茫然地站到了一边。我们就这样错了一次又一次，却从不晓得从中汲取教训，做一些反省。
4、你不知道我在想你，是因为你不爱我，我明明知道你不想我，却还爱你，是因为我太傻。也许有时候，逃避不是因为害怕去面对什么，而是在等待什么。
5、天空没有翅膀的痕迹，但鸟儿已经飞过；心里没有被刀子割过，但疼痛却那么清晰。这些胸口里最柔软的地方，被爱人伤害过的伤口，远比那些肢体所受的伤害来得犀利，而且只有时间，才能够治愈。
6、很多人，因为寂寞而错爱了一人，但更多的人，因为错爱一人，而寂寞一生。我们可以彼此相爱，却注定了无法相守。不是我不够爱你，只是我不敢肯定，这爱，是不是最正确的。
7、如果背叛是一种勇气，那么接受背叛则需要一种更大的勇气。前者只需要有足够的勇敢就可以，又或许只是一时冲动，而后者考验的却是宽容的程度，绝非冲动那么简单，需要的唯有时间。
8、生命无法用来证明爱情，就像我们无法证明自己可以不再相信爱情。在这个城市里，诚如劳力士是物质的奢侈品，爱情则是精神上的奢侈品。可是生命脆弱无比，根本没办法承受那么多的奢侈。
9、人最大的困难是认识自己，最容易的也是认识自己。很多时候，我们认不清自己，只因为我们把自己放在了一个错误的位置，给了自己一个错觉。所以，不怕前路坎坷，只怕从一开始就走错了方向。
10、生活在一个城市里，或者爱一个人，又或者做某件事，时间久了，就会觉得厌倦，就会有一种想要逃离的冲动。也许不是厌倦了这个城市、爱的人、坚持的事，只是给不了自己坚持下去的勇气。
11、多少次又多少次，回忆把生活划成一个圈，而我们在原地转了无数次，无法解脱。总是希望回到最初相识的地点，如果能够再一次选择的话，以为可以爱得更单纯。
12、如果你明明知道这个故事的结局，你或者选择说出来，或者装作不知道，万不要欲言又止。有时候留给别人的伤害，选择沉默比选择坦白要痛多了。

[新闻]微软自称传媒公司强调搜索引擎三大趋势

SOA是什么

大兵 — Sun, 27 Jul 2008 02:49:00 GMT

摘要: 面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特阅读全文

[新闻]亚洲社交网站Friendster将兼容竞争对手窗件

ESB 在实际项目中的应用（WebSphere Message Broker ）

大兵 — Wed, 16 Jul 2008 08:38:00 GMT

提纲：

1、 WebSphere Message Broker Introduction

a) ESB Overview

b) Message Broker Overview

c) Message Broker Performance Report

2、 ESB Project Sharing

内容：

1、 Message Broker是建立在MQ基础之上的。【说明消息中间件对于MB是何等的重要，可靠的传输是前提、是基础。】

2、 Business Integration Reference Architecture

上面是IBM的业务集成参考架构，而下面的图则用IBM的产品充满了整个架构。

3、 ESB所处的位置，作为连接层，组织服务请求方和服务提供方之间的信息

4、 ESB解决连接性问题

a) Decouple interfaces from application.【ESB可以从应用中解耦接口。注意：当前的项目中，总是在对付接口】

b) Enable all applications to communicate with each other regardless of

i. Programming languages

ii. System Platforms

iii. Programming models

iv. Protocols

v. Data formats

可以在以上5层无关性的前提下，应用程序互相通讯。

5、 What is Enterprise Service Bus (ESB)?

c) A flexible connectivity infrastructure for integrating applications and services.【一个柔性联通基础架构，用于集成应用程序和服务。】

d) Used to reduce the number, size, and complexity of interfaces.【用于减少接口的数量、大小、复杂性】

6、 ESB的功能

e) Matches & routes (message between services)【原来应用系统是直连的，相互之间是知道对方存在的，是依赖于接口的】

f) Converts (transport protocols between requestor and service)【协议转换】

g) Transforms (message format between requestor and service)【消息格式转换】

h) Distributes (business events from/to disparate sources)【分发事件】

7、 ESB提供的通讯服务

i) 传输（包括JMS消息和异步协议）

j) 事件

k) 中转

8、什么是Brokering ? （注意：数据的格式不一样）

Broker愿意是经纪人的意思，在这里可以理解为代理。

使用Message Broker之后，还可以很方便连接新的应用。

9、 Message Broker 产品家族

IBM划分基础产品和高端产品的方式可以学习。

10、 Message Broker核心概念

l) 消息处理（Message processing）

i. 处理消息中的独立项

ii. 物理和逻辑消息模型

m) 转换和路由（Transformation and Routing）

i. 消息操纵（Message Manipulation）【我理解为各种处理，类似于handle】

ii. 基于内容的路由（Content based routing）

n) 简单的，清晰的编程模式

i. 可视化编程模式：消息流

11、 Message Broker概况

从这个处理流程中，可以看出MB的基本功能：

1）收到并路由消息

2）转换消息到另一格式，或者到多个其他格式

3）给订阅者发布一个消息

4）访问外部数据库处理增量消息或存储

5）应答事件和错误

12、 MB的组件――部署时

Broker 有Domain的概念，另外Message sets和Message flow都运行在Broker之内，多个Broker部署在同一个Broker Domain内，在同一个Domain内通过Configuration来进行配置。

13、 MB的组件――运行时

1） Broker（消息代理）：是MB的消息处理引擎，它提供MB的所有运行时服务。

2） Configuration Manager（配置管理器）：CM是工作台，配置存储库和Broker之间的一个接口，它维护Broker Domain的配置信息，向Broker提供初始化配置信息以及之后的变化信息。配置管理器是MB用于管理那些组成Broker Domain的全部部件和资源的核心运行时部件。

3） Broker Domain（消息代理域）：共享相同配置的若干Broker组成一个消息代理域，每个消息代理域由一个唯一的配置管理器来控制，在一个消息代理域中，可以创建、启动一个或多个Broker，和一个可选的User Name Server。

4） Execution Group（执行组）：执行组是若干消息流的组合，是消息流运行引擎。每个执行组是一个独立的进程，这样，在同一个执行组中的消息流可以做到在运行时相互独立。在一个执行组内部，消息流在不同的线程池内运行，为了提高性能，我们可以通过设置每个消息流的运行实例的个数来指定每个消息流的线程池的大小。

5） User Name Server（用户名称服务器）：任何关键系统的一个重要的组成部分就是通过提供一个有效的安全机制来确保资产安全的能力。用户名称服务器是可选的运行时组件，它提供Publish/Subscribe操作相关的用户和组的安全控制。

6） Message Flow（消息流）：在MB中对消息的运算处理、格式转换和路由等功能是通过消息流实现的，每个消息从输入MB到从MB中输出，都将被一个消息流处理，然后发往目的应用系统。消息流由各种消息处理节点（Message Processing Node）组成，消息处理节点可对消息进行各种处理操作，节点与节点相连，便组成了一个消息流。

7） Message Processing Node（消息处理节点）：在MB中，对消息的所有计算和处理是通过消息节点实现的，消息节点实际上是被Broker运行环境调用的动态链接库（DLL），通过ESQL语句对消息进行操作，通过对消息节点属性的客户华处理，将使节点能够对流经自己的消息执行特定的功能。

8） ESQL：在MB中，消息流开发使用的使ESQL语言。ESQL是对SQL V3的扩展，除了用于数据库的操作之外，它还可以操作消息数据，包括Generic XML和MRM格式的消息。

14、 Message Flows【简直就是针对消息的工作流】

15、 Message Processing Nodes （6.0在此基础上又有增加）

从我的观点来分析，最重要的节点：

a) MQInput & MQOutput

b) HttpInput 可以做WS服务，HttpRequest可以去访问WS

c) Publication 用于发布

d) ESQL语句节点，可以用于手工写ESQL，属于万能的节点。

e) Mapping，消息到消息和消息到DB的映射

f) Filter，实现if-else。返回4种状态：failer，true，false，unknow。

g) RouteToLaber配合Label，相当与case语句。

h) TryCatch 和Throw

i) Trace，用于打印调试信息。MB也提供命令行调试方式。

j) Aggregate Request、Reply、Control，聚合

新版本中增加了

a) Timer节点

b) JMS节点

16、 MB Toolkit

17、 ESQL editor

18、 Message Set Development

19、 Mapping editor

20、 Deployment

MB需要打包成bar包，这具有更强的灵活性，更高的性能，当然要稍微麻烦一些。自己开发的产品，打包、部署一定要简单，最好能支持热部署。

21、 mqsideploy 命令行部署工具，较大型的项目，需要做开发环境、测试环境、联调环境、生产环境等。生成脚本可以多次执行。这就是大型软件和一般软件的区别之一。

22、 MB性能报告

4160 个 1KB的包/秒，建议交易用的包在1—2K。

MQ消息持久，是指写文件，保证服务宕机的情况下消息的完整性。而非持久性能更高。

比如：银行ATM最大等待时间60妙，超时后消息本身就没有意义，可以选择非持久。

23、 MQInput/MQOutput消息流的基准值

24、 Parallel Processing Option

MB可以通过多instance或者多执行组来并行，具体哪个效果更好，看具体应用的情况。

[新闻]百度宣布服务器全面换装闪存替代硬盘

面向服务架构（SOA）和企业服务总线（ESB）

大兵 — Wed, 16 Jul 2008 08:30:00 GMT

学习和研究在企业中实施面向服务架构(SOA),简单回顾SOA和ESB，重点关注微软在SOA领域的相关指导和.NET社区的相关开源的解决方案，和大家一起来探讨如何在企业里实现SOA，期望有实施SOA经验的同学发表意见。
一、SOA的历史

1996年，Gartner最早提出SOA。2002年12月，Gartner提出SOA是"现代应用开发领域最重要的课题"，SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业(Real-Time Enterprise，这是Gartner为SOA描述的愿景目标)。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。

　　SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法(例如消息机制)，通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。

　　SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

　　SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的(各种)需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。

　　企业流程(enterprise process)是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。

二、SOA 的描述所适用的原则

利用显式的与实现无关的接口来定义服务。
利用强调位置透明性和可互操作性的通信协议。
封装可重用业务功能的服务的定义。

图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。

图 1: SOA 的原则

为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。

三、ESB是什么？

根据维基百科的ESB定义，ESB有如下特性：

它是面向服务架构的实现。
它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）。
它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含标准安全模型，用于ESB的认证、授权和审计。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它包含基于模式（schema）的验证，用于发送和接收消息。
它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它可监视不同SLA（服务级别合约）的消息响应门限，以及在SLA中定义的其它特性。
它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
它支持队列，在应用临时不可用时用来保存消息。
它由（地理）分布式环境中的选择性部署应用适配器组成

对于其中一些厂商（IBM、微软）来说，ESB是将一系列能力联结在一起的一种模式，而其他厂商认为ESB是一种产品。在2005年，微软Identity Platform的产品经理Rich Turner写道：

ESB[产品]是一根聪明的管子，用来连接各个愚笨的节点。[……]Web Service的途径让节点本身也变得聪明，减少了对底下聪明管道的需要，并确保了跨越任何平台与设备的开放的通讯。

四、如何用.NET技术建立完整的SOA环境

微软发布了一个名为“真实世界里的面向服务架构（SOA）”的电子书。这本书表达了微软对面向服务架构的观点，并包括了数个展示如何用微软产品和技术实现SOA的真实案例。书中解释到，SOA的功能型架构本身是松散的，即每个服务本身可以作为企业的IT资产存在、也可以作为生产流程中的处理环节存在，但总体上他们提供了一个完整的视图，而且与独立应用不同，这个视图的内容不是分层的、而是平的，借助这个视图可以提供如下可重用能力：

消息机制服务
工作处理流程服务
数据服务
用户体验服务
主体身份的识别、认证、授权服务
还有通盘的管理能力

所有这些能力用微软的产品描述就是下图：

与强调SCA、SDO等公共标准的Java平台不同，微软平台相应的封装也不是通过商用服务器平台完成，而是更多地借助WCF实现；其中最为重要的ESB角色重则由BizTalk担当，轻则由用户通过扩展WCF + WF完成；至于服务的治理，相对更为统一，与Windows平台其他产品无异，向下借助统一的WMI体系，配合MOM和System Center对SOA的基础平台部分进行治理，向上借助WS_Management协议对服务进行集中管理。

实施SOA集成在所难免，各企业集成的方式大概主要有3种：

购买某厂商的SOA套件，这样无论是组成上的兼容性还是技术支持都有保证，代价就是花费不菲；
集成多种开源的服务器产品和开发框架，显性成本上很划算，但技术实施的成败的风险比较大；
更多依赖操作系统自带的产品，根据IT范围的大小，选择少量的商业产品或开源服务器产品，兼容性风险比全部开源产品要小，成本上也比全盘采购商业套件廉价。《SOA in the Real World》里更多倡导的就是这第三条道路。

微软还赞助了一个针对北美500家拥有1000名员工，或超过这个数字的企业的综合应用平台的研究。其目的旨在确定哪种软件平台被用于构建关键任务的应用，以及什么是首选供应商的关键组件平台等。

五、开源的.NET ESB项目介绍

ESB.NET企业级服务总线:ESB.NET是开源的企业级服务总线，采用的协议是MS-PL。ESB.NET主要包含了MSMQ消息队列机智,SOAP消息收发,ROUTER服务路由,WCF,WSE消息扩展(消息加解密,压缩),还有WF工作流。

开源的通信框架NServiceBus :NServiceBus 是一个用于构建企业级 .NET系统的开源通讯框架。它在消息发布/订阅支持、工作流集成和高度可扩展性等方面表现优异，因此是很多分布式系统基础平台的理想选择。，它能够帮助开发人员在搭建企业.NET系统时避免很多典型的常见问题。同时，该框架也提供了一些可伸缩的关键特征，比如对发布/订阅的支持、集成的长时间工作流及深入的扩展能力等。据作者说，其本意是为构建分布式应用软件创建一个理想的基础设施。

Mass Transit -- .Net Service Bus:Mass Transit是一个.NET平台上的用于构建松耦合应用程序的服务总线框架,这个服务总线支持YAGNI原则(YAGNI原则，就是通过重构提取公因式当出现一次时，不分层，以后业务复杂了，马上抽象出一个层次来，分层是依赖倒置原则和模版方法模式的应用。)。通过一套严密的关注点,Mass Transit和应用程序之间的接触最小化和清晰的接口.

使用UML服务组件表示SOA体系结构模式

大兵 — Wed, 16 Jul 2008 08:18:00 GMT

作为一位架构师，您常常面临来自客户企业架构师和 IT 利益相关者的询问，他们要求您用非专有的、与产品无关的方式，清楚地说明面向服务的体系结构 (SOA) 模式和服务组件。在本文中，使用统一建模语言(Unified Modeling Language，UML)模型来描述 SOA 体系结构模式及其相关的服务组件。您还将在行业标准的 UML 格式上下文中，了解有关 SOA 模式服务组件的内容，以帮助利益相关者更好地了解组成 SOA 的服务组件。

　　引言

　　如果您需要以一种逻辑格式来表示面向服务的体系结构 (SOA)，以便利益相关者可以更好地使用各种构件，在他们的体系结构和设计工作中利用 SOA 统一建模语言 (UML) 组件，那么本文可以为您提供相应的帮助。了解如何利用 SOA 体系结构模式的服务组件(采用 UML 节点的形式)以创建 SOA 场景。以一种与产品无关*的方式了解 SOA 模式及其相关联的服务，其中使用 UML 表示 SOA 的组件、连接以及与 SOA 体系结构模式的交互。

　　逻辑 SOA 参考体系结构

　　在图 1 中，采用一种与 UML 产品无关的方式表示 SOA 模式。在它最简单的形式中，SOA 模式由分离的企业服务总线(Enterprise Service Bus，ESB)组成，该总线可以连接请求者和提供者，并在它们之间提供交互的服务。

　　图 1. 逻辑 SOA 参考体系结构

　　这个 SOA 模式由 ESB 基础结构、服务交互点 (SIP) 或端点组成，如表 1 所示。

　
ESB 用作 SOA 模型的连接入口点，并且提供了下列服务：

　　• 请求和响应服务

　　• 转换

　　• 基于内容的路由

　　• 自定义的日志记录

　　• 优化

　　• 监视

　　ESB 还提供了各种服务的通用连接和虚拟化。为了满足最新业务应用程序的需求，ESB 充分利用了服务组件体系结构 (SCA) 编程模型。

　　在图 2 中，您可以看到，ESB 支持最新的 SCA 编程模型，并提供了一个缺省的消息传递引擎，该引擎构建于 Java™ Message Service (JMS) 规范的基础之上。这个 ESB 使用了一个中介组件(模块)，该组件基于 SCA 模块，以便为服务请求者和服务提供者之间的消息提供中介。从而可以定制 ESB 中的中介服务，以形成复杂的中介模式，这种中介模式采用与具体位置和标识无关的方式来实现虚拟化。它们还可以提高服务质量 (QoS) 需求，如性能、消息的加密/解密，以及可靠且安全的内容交付及事务。

　　图 2. 企业服务总线

　　这个中介组件由以下三个组件组成：

　　消息模型

　　以正在考虑的消息的元模型为基础(ESB 应该能够支持服务提供者和服务请求者之间的、不同类型的消息模型流，从而创建一个与消息-模型无关的交换。)

　包含一些接口，用以调用中介流，以便在服务请求者和服务提供者之间执行中介，并提供对外部服务的引用(中介流支持以下几种中介模式：监视器、修改器、验证器、缓存、路由器、发现克隆等等。)

　　通信协议

　　提供对不同通信协议的支持，如 MQ、Java Message Service (JMS)、HTTP 和远程方法调用 (RMI)，以连接服务提供者和服务使用者(这些通信协议支持多种交互模式，如请求/响应、发布/订阅、同步/异步。)

　　ESB 使用服务注册中心和存储库组件作为动态查找机制，以提供关于服务端点的信息。因此，注册中心和存储库服务可以优化对服务元数据的访问，以及服务交互和策略的管理。它还支持其他标准的注册中心和存储库的集成和联合。在其最基础的状态下，它是由服务元数据构件文档组成的，如 XML 模式定义语言 (XSD) 或者 Web 服务描述语言 (WSDL) 文件。通过服务存储库存储并管理这些服务元数据文件。交互服务

　　这些交互服务节点可以作为用户的 SOA 入口点。这些交互服务为 SOA 提供表示层，其中对相关的接口进行

　　了抽象，并聚合了最终用户和 SOA 应用程序之间的各个信息源。
交互服务可以分为三类主要的服务：

　　用户接口服务

　　由使用仪表板进行决策制定和可视化操作的门户应用程序组成。

　　用户交互服务

　　由可视化、协作、组合应用程序、警报和表格组成。

　　部署服务

　　包含移动设备、浏览器和富客户端。

　　交互服务使用支持的模板组件以简单地创建组合应用程序。这些组合应用程序：

　　• 为外包的或者内部的服务应用程序提供基础。

　　• 支持富客户端和移动设备最终用户客户端。

　　• 提供高度自定义和动态的数据，这将提供实时的可见性，以便将结果与基础业务流程度量关联起来。

　　• 作为仪表板进行使用，为用户提供该项目的关键性能指标 (KPI) 的实时视图。

　　图 3. 交互服务

　　组合应用程序中的每个部分都可能包含预先构建的、具有特定功能和相关联的工作流的 Portlet。交互服务还可以具有内置的筛选功能、基于浏览器的配置向导、交互的 Web 窗体、搜索、Web 2.0 技术和协作。例如，协作服务组件是一个完全集成的、基于门户的协作环境，该环境包括电子邮件、日历和日程安排、即时消息传递、Web 会议、文档以及 Web 内容管理。
流程服务

　　图 4 显示了用于在 SOA 域内执行其功能的流程服务和组件。流程服务使用业务流程和中介模块来实现它的业务流需求。流程服务使用 SCA 编程模型对使用和产生业务数据的业务服务进行建模。

　　图 4. 流程服务

　　可以使用业务流程执行语言 (BPEL) 来定义业务流程。业务流程是在预定义的序列中调用以实现业务目标的一组业务相关的活动、规则和条件。业务规则是一种通过业务功能的外部化来实现和实施业务策略的手段。外部化支持从应用程序的其他方面独立地管理业务规则。这种独立性支持动态业务规则更新功能，从而提供了更加灵活的业务。

　　SCA 组件由接口、引用和实现组成。服务组件可以包含使用 Java 编写的接口或者 WSDL 端口类型。业务流程类型组件由流程实现类型组成，这个流程实现类型可以通过 Java 接口或者 WSDL 端口类型接口实现一个或者多个 SCA 接口。流程运行的时间可能很长，也可能很短;运行时间很短的流程称为微流。运行时间很长的业务流程可以与多个合作伙伴进行交互，并且通过执行标准的、无状态的 Web 服务调用来进行交互。

　　可以通过 Web 服务接口与各个合作伙伴发生交互。BPEL 基于 WSDL 和 XML 模式构建。可以按 BPEL 规范定义的那样，使用一个用于语法扩展的 XML 模式，以及应用于语义约束的一组全面的规则，来完成对流程模型的验证。
信息服务

　　在图 5 中，您可以看到 ESB 的信息服务栈。

　　图 5. 信息服务

　　它包含下面这些组件：

　　元数据管理

　　提供关于数据的信息(元数据是关于数据结构和含义的信息。元数据管理组件可以管理元数据、元模型和元-元模型。)

　　元模型(也称为元-元数据)定义了元数据的结构和语义。标准化的元模型示例包括 UML 和公共仓库元模型(Common Warehouse Metamodel，CWM)。元-元模型层由结构的描述和元-元数据的语义组成。它试图提供一种公共语言，以描述信息的所有其他模型。MetaObject Facility (MOF) 是一种用于元-元模型的标准。(有关更多信息，请参阅参考资料部分。)

　　提取、转换和加载 (ETL)

　　从一个或者多个数据源提取、转换和加载数据到一个或者多个目标(ETL 支持数据整合、迁移和传播，并且它与数据仓库和业务智能功能紧密结合。)

　　联合

　　使用数据和内容类以联合异类内容源的数据(这些分散的方法可以减少数据和内容的冗余、带宽、存储、所需进行的同步，以及与使用集中方法相关的附加管理成本。对分布式信息源的实时访问也为业务智能带来了新的功能。)

　　联合减少了为各种数据源开发和维护自定义应用程序编程接口 (API) 的需要。通过缓存频繁使用的数据，以及使用物化查询表 (MQT) 和分布式查询优化与执行，联合还可以改善性能。为了提高性能，联合的服务器还可以缓存并创建 MQT 表以提高性能，这些表可以是来自目标的联合数据源的行的子集。
数据布置(复制和缓存)

　　从一个位置复制数据到另一个位置(目标位置可以是一个中央位置，如数据仓库，也可以是网络上的另一个分布式位置。在网格环境中，复制和缓存服务用于创建布置管理服务以满足 QoS 的目标。根据访问模式和消费应用程序位置的不同，布置管理服务通过创建缓存或副本来改善响应时间以及信息的可用性。分阶段数据治理使得组织能够更好地控制信息流的生命周期。)

　　数据建模

　　提供了逻辑、物理和元数据模型的聚合，用于存储企业各自的模型(这些数据模型采用数据结构和数据使用的形式，对业务和业务应用程序有着直接的影响)。

　　对数据模型进行仔细地设计同样可以提高整体事务性能。在事务类型方面存在以下依赖关系：联机事务处理 (OLTP) 事务使用 E/R 模型;数据仓库事务使用多维建模技术。

　　搜索

　　主要使用它自己的搜索机制(最通用的搜索功能是通过一种查询语言，如 SQL 和 XQuery。数据库搜索对于检索结构化的和精确匹配的数据来说是非常合适的，但是需要熟悉数据模型结构以构造相应的查询。)

　　数据库搜索在范围上具有一定的局限;它不适合相关性排序、模糊搜索，或者多个关键字搜索。为了使搜索引擎实现更高的性能、灵活性或者相关性排序，引擎有时直接连接到数据库，以便从数据库提取数据并生成索引。

　　分析方法

　　帮助更好地进行决策制定、数据挖掘，以及跨部门的报告(传统的分析方法包括报告、数据挖掘、仪表板、记分卡、业务性能管理。各个组织都希望能够实时地访问异类数据源，以确保对相关规定的遵从、更好地对客户进行响应、预测市场趋势、提高操作效率。)

　　分析组件与交互服务的组合应用程序的功能和特性紧密地结合在一起，并为业务应用程序提供实时的 KPI 视图。将来，分析将构建增强的智能，以访问和关联来自异类信息源的信息，以便为更好地制定业务决策提供新的见解。

　　合作伙伴服务

　　合作伙伴服务用作 SOA 的重用入口点，如图 6 所示。这意味着，遗留系统和电子数据交换 (EDI) 系统在自定义适配器的帮助下，可以连接到 SOA 企业体系结构，并与 ESB 联系在一起，从而提高操作效率和 QoS。适配器提供了 EIS 和集成代理之间的通信。每个后端系统或者业务应用程序都需要一个特定的适配器。

　　业务集成适配器由一组软件 API 组成，提供了与后端企业信息系统 (EIS) 的本地通信，以及配置业务对象和适配器的工具。

图 6. 合作伙伴服务

　　图 7 显示了业务集成中所使用的一种常见模式，这个模式需要在各种后端业务应用程序系统之间对语义上类似的数据进行同步。该场景显示了两个不同的后端系统，通过使用业务集成适配器，它们都与运行在流程服务器上的业务集成应用程序进行了集成。通过利用相同的 SCA 编程模型和其他集成应用程序所使用的组件，可以实现适配器的集成。

　　图 7. 业务集成适配器服务

　　图 7 的中心部分显示了使用业务集成应用程序的流程服务器。这个业务集成应用程序可以由 SCA 模块之外的其他服务通过 JMS 导出来调用。通过使用 JMS 导入，这个业务集成应用程序可以在 SCA 模块之外调用其他服务。适配器使用应用程序特定的数据结构或者业务对象与后端系统进行通信，并且使用连接器配置文件进行配置。

　　当通过导出将一个业务对象入站传递给流程服务器时，使用数据绑定(该导出中的一部分)将其转换为流程服务器可以理解的格式。在将一个业务对象出站传递给适配器时，使用数据绑定(该导入中的一部分)将其转换为适配器可以理解的格式。这种数据同步模式还可以从应用程序特定的格式到通用格式合并业务对象的映射。

　　一些供应商提供应用程序适配器组件，包括 Ariba Buyer、Clarify、MatrixOne (eMatrix)、JD Edwards、mySAP.com、Oracle Applications、PeopleSoft Portal Intranet、QAD MFG/PRO、Retek、SAP Exchange Infrastructure、Siebel、WebSphere Process Server 和 WebSphere Enterprise Service Bus (ESB)。

　　以下是一些技术适配器组件：ACORD XML、Microsoft® COM、CORBA、电子邮件、EJB、Microsoft Exchange、FIX 协议、IBM iSeries®、WebSphere Business Integration iSoft Peer-to-Peer Agent、Java Database Connectivity (JDBC)(SQL 和存储过程访问)、JMS、JText、IBM Lotus® Domino®、Society for Worldwide Interbank Financial Telecommunication (SWIFT)、WebSphere MQ、WebSphere Business Integration Message Broker、WebSphere MQ Workflow、Web 服务和 XML。

　　有些技术适配器可以使用数据处理程序，包括用于 EDI、SOAP、XML 和各种文本格式的数据处理程序。

　　这些适配器使用一种通用的适配器框架进行构建，并且是：

　　• 双向的，它们能够进行事件处理和请求处理。

　　• 可配置的(通过元数据)，并且能够处理多线程业务对象。

　　业务集成协作组件与其他一些组件(如客户关系管理 (CRM)、Health Insurance Portability and Accountability Act (HIPAA)、卫生保健、订单管理、采购、无线通讯、人身保险等等)相互协作。使用预先构建的模板对与各个组件相关的信息和数据进行简化和同步，可以实现业务集成协作。

　　例如，与 HIPAA 事务的协作可以使得与所需的规范和标准保持一致，并确保所有的事务和交互能够实现跨多个应用程序和跨企业的互连。代理插件组件提供了创建用户插件节点所需的一些类。微代理插件组件提供了所需的、与访问相关的信息，如代理名称、队列名称、数据源等等。业务应用程序服务

　　业务应用程序服务构成了 SOA 的重用入口点。业务应用程序是松散耦合的，以便通过使用 Web 服务为企业带来业务价值。
Web 服务减少了构建昂

　　贵的业务应用程序的成本，并且支持在企业结构中部署新的业务模型。对于大多数组织，在快速部署到主流的过程中，主要的问题是安全性。业务应用程序服务合并了一些业务安全特性，以确保业务事务执行期间的安全。

　　图 8 显示了使用业务流程和策略管理组件为企业的业务应用程序提供业务安全服务的业务应用程序服务。

　　图 8. 业务应用程序服务

　　业务流程和策略管理组件使用了下面的安全组件，以实现它对业务应用程序的安全职责。

　　安全治理框架

　　处理对企业内部的有效治理结构和决策权的需求(这一框架用于建立一系列命令、职责和权力，以确保从安全的角度对企业业务应用程序进行有效控制)。

　　信任管理

　　在任何两个将要一起执行安全业务事务的企业或者组织之间建立信任(信任建立在这两个实体都同意遵守一组关系和责任管理规则以执行相应业务的基础上)。

　　从技术的角度来看，还可以使用各种加密方法来建立信任，包括加密密钥、私钥或公钥、数字签名，或者协议。

　　标识和访问管理

　　提供了必要的 ID 管理和跨企业的访问权限。这个组件使用了下面的附加组件来实现它的服务：

　　• HR 标识供给，以便通知管理人员有关 ID 状态更改的情况，并触发合适的工作流初始化工作。

　　• 审批组件，以获得进行标识或信息访问的修改或更新所需的管理批准。

　　• 用户自助组件，使得最终用户能够执行某些安全管理任务，而无需管理监督，如周期性地更改密码。

　　• 委托组件，以提供将 IT 安全管理功能委派给其他人的能力。

　　• 重新验证组件，以提供对需要定期进行审批的系统的访问。
确保系统和网络的安全

　　提供安全服务，如防火墙、入侵检测系统、病毒检测、补丁管理以及操作和网络安全(业务应用程序服务组件使用一个联合组件来管理企业中许多不同的服务环境。)

　　数据保护

　　在业务信息内容传输期间或者在它的目的地，负责业务信息内容的安全(通过管理私有策略、获得关于敏感信息的详细报告、发布用户检查的策略，以及捕获并实施用户首选项，数据保护组件可以建立信任)。

　　风险管理

　　在企业 IT 系统中确定相关的风险级别，并确定需要采取有效措施来根据成本优势分析评估它对整体安全操作的影响，以及对系统的影响。

　　遵从性管理

　　确保遵从外部联邦的或者国家/地区的法律法规，并在内部遵从 IT 组织的业务安全策略。

　　审核跟踪和记录

　　调解和评估如何在日常操作中实际应用 IT 系统中引入的不同 IT 安全策略，以确保对内部和外部策略的遵从性。(这有助于管理和技术团队在背离策略的情况下迅速地采取纠正措施。)

　　应用程序和数据访问服务

　　应用程序和数据访问服务组件用作信息和 SOA 的重用入口点，如图 9 所示。跨异类技术的服务之间的连通性是 SOA 的基础。图 9 显示了一个带有应用程序和数据访问服务组件的企业应用程序场景，它支持各种交互协议和 QoS。当大多数组织决定将应用程序公开为 SOA 环境中的服务时，他们的业务应用程序必须能够处理各种不同的数据表示形式。

　　处理各种数据表示形式已成为一项挑战;对于一般通用的 API 来说，迫切地需要具有处理各种数据源的能力。SCA 编程模型可以公开与基础数据层进行交互的服务。有一种称为关系数据库数据访问服务 (RDB DAS) 的可靠数据访问实用工具，它在基于 SCA 的应用程序中提供了与服务数据对象 (SDO) 的紧密集成。

　　图 9. 应用程序和数据访问服务

　　总结

　　架构师和利益相关者常常发现，对于清楚地说明 SOA 的体系结构模式，并确定选择哪一个入口点，这是一项颇具挑战性的工作。因此，他们可能希望选择多个 SOA 入口点，以便解决企业所面临的最紧迫和最具挑战性的问题。在阅读完本文之后，通过在各个入口点所标识的各种节点上进行深入研究，架构师和其他重要的参与者可以帮助他们的组织更好地满足其需求，并开始他们的 SOA 体系结构之旅。

　　在本文中，您从逻辑的角度了解了 SOA，以及如何创建节点和相关的 UML 组件，它们可以以一种非专有的、与产品无关的方式来表示 SOA 的参考体系结构。

[新闻]百度宣布服务器全面换装闪存替代硬盘

SOA架构师注意的问题

大兵 — Wed, 16 Jul 2008 08:01:00 GMT

什么是SOA架构设计师的职责?

　　那什么是企业级SOA架构设计师的具体角色呢?什么是SOA架构设计师与设计和开发人员之间的差别呢?相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生?也就是说架构设计师关注的应该是一些商业需求和服务级别(service-level)需求。所有的架构设计师的角色都包含了在构建一个系统的一开始就应该尽量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未经证明的或未经测试所带来的风险。这些风险通常与服务级别(service-level)需求相关，偶尔也会与企业具体的业务需求相关。无论是哪种类型的风险，在项目初期设计整体系统架构的过程中更易于发掘这些风险，如果等到架构实施时再发觉这些风险，那么很可能会致使大量的开发人员等在那里，直到这些风险被妥善解决。如果进一步的细化，我们可以看到SOA架构设计师的主要任务包括对整个系统解决方案轮廓的构建，需求分析，对体系结构的整体决策，相关组件建模，相关操作建模，系统组件的逻辑和物理布局设计。

　　作为SOA架构设计师必须要能够领导整个开发团队，这样才能保证设计和开发人员是按照构建好的系统架构来开发整个系统的，这一点十分的重要。这就要求一名架构设计师不仅要有很好的技术洞察力，同时还要具有一定的项目管理和项目实施的能力。在系统开发的过程中，架构设计师必须要有良好的沟通和表达能力，这就体现在由架构设计师构建的系统模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系统模型不是很清晰的话，就可能会影响设计和开发人员对于整个系统架构的理解。为了避免这种情况的出现，定期由架构设计师主持的开发团队内部讨论是十分重要的。

　　构建SOA架构时应该注意的问题

　　原有系统架构中的集成需求

　　当架构师基于SOA来构建一个企业级的系统架构的时候，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。我们都知道，面向服务的体系结构是当前及未来应用程序系统开发的重点，面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统;SOA可以通过利用当前系统已有的资源(开发人员、软件语言、硬件平台、数据库和应用程序)来重复利用系统中现有的系统和资源。SOA是一种可适应的、灵活的体系结构类型，基于SOA构建的系统架构可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。因此，当SOA架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统，因为如果考虑到有限的预算，整体系统替换的成本是十分高昂的。

　　当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面:应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI(Electronic Data Interchange 电子数据交换)系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。

[新闻]百度宣布服务器全面换装闪存替代硬盘