BlackStone SOA Group

自从Michael Hammer和James Champy两位教授1991年在《哈佛商业评论》提出业务流程重组的概念后，业务流程与软件流程之间的平衡就成了企业信息化关注的一个焦点。

在此之前的IT应用模式基本属于使用者去适应系统。系统考虑的也大多是处理的准确性与速度，从某种程度上来说是把可以由计算机做的事由计算机来做，实现所谓的自动化。如何利用信息技术实现流程的最优化则是在后来才得到广泛关注。

根据Hammer的定义，业务流程重组是“对企业的业务流程作根本性的重新思考和彻底的重新设计，使企业在成本、质量、服务和速度等方面取得显著的改善”。业务流程重组的一般步聚为：
 确定企业战略，从战略的高度来对待业务流程重组
 业务流程重组项目启动
 现有流程诊断分析，对原有流程进行建模与分析
 新流程设计，并设计支持新流程的IT架构
 新流程实施
 流程评估
 流程持续改善
从Hammer对流程重组的定义及实施步骤来看，很明显流程重组是面向业务的，而IT则是服务于流程的；从信息系统在管理中扮演的角色来看，所有管理软件都应该是充当辅助角色的。毫无疑问，软件的流程应该服务于企业业务流程。
 
但是在现实情况中，情况却远远没有这么简单。
  
一些企业有着合理的业务流程，但却缺乏运用很好的IT架构来支撑的能力。这类企业可能经过了几十年甚至更长时间的发展，已形成了独有的业务流程。这套业务流程在企业内部运行相当顺利，但在信息化过程中往往找不到能与其业务流程相匹配的成熟的商业管理软件，所以其信息系统通常要采取定制的方式开发。这时企业驾驭IT技术使其服务于企业业务流程的能力就显得很重要。

一些企业的业务流程并不合理，而商业管理软件往往吸取了先进的管理思想。这在一些发展中的中小企业普遍存在。这些企业因为发展不久，企业流程并不像大型企业那样成熟。同时这些企业的信息化程度也有限。商业管理软件经过多年的发展，已经吸收了世界上大多数的先进管理理念，并将这些理念融合到软件流程中。对于上述类型的中小企业来说，信息化与其说是增强其管理自动化程度还不如说是通过信息化来学习引进商业管理软件所包含的管理思想。从这个角度来说，企业中的业务流程重组反而要借鉴管理软件的流程。

还有一些具有legacy系统的企业，其流程重组受到legacy系统的限制。企业业务流程与现存系统可能已经能较好的整合，但是如果需要上新系统，或者整合原有的系统，那么也将面临流程重组的问题。此时的流程重组不仅会带来新系统或系统整合引起的软件开发或实施费用，还会带来流程改造的间接成本。而且在这种情况下的流程重组最可能受到员工的抵触，因为他们已经习惯了原来的流程。在现实当中，企业一般都会采取折衷措施，循序渐进的流程改进方法。

从总体上来说，软件业务流程应该是服务于企业业务流程的，只是在实际运用中应考虑到具体情况而已。

下面这幅图包含了14个开源项目，你能一一找出来吗？

答案：
 1 小妖 FreeBSD  http://www.freebsd.org/
 2 羽毛 Apache  http://www.apache.org/
 3 企鹅 Linux  http://www.linux.org/
 4 咖啡豆 Java  http://java.sun.com/
 5 恐龙 Mozilla  http://www.mozilla.org/
 6 笔筒 GIMP  http://www.gimp.org/
 7 记事本 OpenOffice  http://www.openoffice.org/
 8 方块1 X.org  http://wiki.x.org/wiki/
 9 方块2 GTK  http://www.gtk.org/
10 桌布 GNOME http://www.gnome.org/
11 骆驼装饰 Perl  http://www.perl.com/
12 鱼缸里面的刺豚 OpenBSD http://www.openbsd.org/
13 牛羚头 GNU  http://www.gnu.org/
14 挂历 Evolution 
http://www.novell.com/zh-cn/products/desktop/features/evolution.html

当然这幅图中还包含了其他与开源密切相关的东西，如咖啡杯Java、墙上的头像：自由软件之“父”——Richard. M. Stallman。

在开源业界内，Firefox一经出现就吸引了众人的目光，开源软件已不再是超级黑客手里的玩物，Wiki在内容管理领域的崛起代表了一种趋势，这就是开源向高端应用的渗透。于是，在ERP、CRM、BI等领域，甚至新兴的RFID领域，我们都不难发现开源的身影。

        近日，和队友一起对IBM的SOA大赛的命题思索，感触良多。
        需求是软件开发的起点，更是开发成败的关键。我们一拿到题目不禁产生了如下疑问：没有一个真实的，可以调查、访问、咨询的客户，不能与之讨论、协商以明确需求，我们的设计和开发会不会就是一场游戏一场梦呢？如果仅仅是虚幻的南柯一梦，那么大赛是否能够真正地考量出参赛者的架构设计能力呢？没有详尽的需求，这是我们面临最大的挑战。
          硬币是两面的，大赛也是。讨论和思索中，我们发现了一些有价值的线索，或许这才是对大赛题目的正确解读。
“或许你并不需要完整的需求，最起码在开始设计的时候”。对于软件开发来说，开发模型的选择或许是至关重要的，是MSF，RUP还是FDD，XP。就本项目而言，项目的规模不应该超过15人月（５名队员，３个月），显而易见我们应当选用某些轻量级的模型，例如：XP。另一面，大赛初赛要求提交的制品显然只是设计而不包括代码实现，考虑到IBM主推的RUP过程，我们有理由认为初赛、复赛就是RUP的Inception和Elaboration两个阶段，而决赛则是Construction和Transition两个阶段。对于RUP来说在Inception和Elaboration的早期我们并不需要完整的需求，更不需要Frozen Requirements。
       “做一只骑在大象身上的猴子”，Barry Boehm的话或许是我们在选择本项目的开发模型问题上最好的指导，我们不用纯粹的RUP，也不用某一种固定的XP方法，我们将有针对的来制定本项目的SDP。
         最近，EMC的“秘书门”事件网上炒得沸沸扬扬，我并无太多兴趣，倒是记住了EMC的motto，“与客户,合作伙伴和同事建立长久关系的核心要求是做正确的事,永远是”。如果不希望SOA大赛对于我们只是“春梦了无痕”，或许我们需要在这场游戏中从选择正确的开发模型开始。
       “做正确的事,永远是”。

        第一次参加这种正规的比赛，自然会有无限憧憬，但心里难免又有点忐忑。当朋友把我介绍入队时，我最先想到的是我能给这个团队带来什么。因为我知道能跟一帮这么优秀的人一起合作，不管最后结局如何，我都可以向他们学到不少知识，这一点是毋庸置疑的。也正是这 样，我才会去考虑能给我们的团队带来什么价值。
         说来也惭愧，学了一堆所谓管理与技术结合的课程，却从来没有真正去实践过。学过系统开发方面的内容，只学到了RUP，XP之类的名词，其内涵于我来说却显虚无飘渺；学过项目管理，可最终也只是停留在画画甘特图之类的，始终没有领会到项目管理的精髓。
        以前所学之虚浮，让我在面对真正有挑战性的任务时充满压力，但也激起我挑战的欲望。前面要走的路还很长。

        为了完成西天取经任务，组成取经团队，成员有唐僧、孙悟空、猪八戒、沙和尚。其中唐僧是项目经理，孙悟空是技术核心，猪八戒和沙和尚是普通团员。这个团队的高层领导是观音。
         团队的组成很有意思，唐僧作为项目经理，有很坚韧的品性和极高的原则性，不达目的不罢休，又有很得上司支持和赏识（直接得到唐太宗的任命，既给袈裟，又给 金碗；又得到以观音为首的各路神仙的广泛支持和帮助）。沙和尚言语不多，任劳任怨，承担了项目中挑担这种粗笨无聊的工作。猪八戒这个成员，看起来好吃懒 做，贪财好色，又不肯干活，最多牵牵马，好像留在团队里没有什么用处，其实他的存在还是有很大用处的，因为他性格开朗，能够接受任何批评而毫无负担压力， 在项目组中承担了润滑油的作用。最关键的还是孙悟空，由于孙悟空是这个取经团队里的核心，但是他的性格极为放荡，回想他那大闹天空的历史，恐怕作为普通人来说没有人会让这种人呆在团队 里，但是取经项目要想成功实在缺不了这个人，只好采用些手腕来收复他。
         这些手段是，首先把他给弄得很惨（压在五指山下500年，整天喝铜汁铁水）；在他绝望的时候，又让项目经理去解救他于水火之中以使他心存感激；当然光收买人心是不够的，还要给他许诺美好的愿景（取完经后高升为正牌仙人）；当然最主要的是为了让项目经理可以直接控制好他，给他戴个紧箍，不听话就念咒惩罚他。孙悟空毕竟是牛人，承担了取经项目中的赶妖除魔的绝大多数重要任务，虽然是个难于管束的主，不能只用手段来约束他。
        此时猪八戒的作用就出来了，在孙悟空苦恼的时候，上司不能得罪，沙和尚这种老实人又不好伤害，只好通过戏弄猪八戒来排除心 中的郁闷，反正猪八戒是个乐天派，任何的指责都不会放在心上。
        在取经的项目实施的过程中，除了自己的艰辛劳动外，这个团队非常善于利用外部的资源，只要有问题搞不定，马上向领导汇报（主要是直接领导观音），或者通过各种关系，找来各路神仙帮忙（从哪咤到如来佛），以搞定各种难题。
         西游记里特别强调得到高层支持的重要性，有没有靠山真的很不同，君不见象白骨精这种没有靠山的妖魔都会死得很惨。
        上面这则来源于网上的故事，告诉我们团队组建对于项目成败的关键作用。在我们的组队过程中给了我们很多启示。幸运的是我们的运气不错，小组里既有了拥有各种必要技能的成员，大家的性格和处事风格竟然也是比较匹配的，这或许就是成功的前兆吧！
         今后的Blog中我们会详细的来介绍我们团队的每一个成员，相信我们的组合一定会勇往直前，争取胜利的！

        从blog，Google Map, Wiki的应用开始，Web 2.0这个名词开始进入网民的视野。但是何谓Web 2.0呢？首先从Web 1.0开始吧。Web是将互联网上的资源在一个网页里直观的表现出来，而且在资源之间，在网页上可以进行链接，是以数据为核心的网。但是互联网上的内容是分散的，而且是机器无法理解的。所以就诞生了搜索工具这个服务，才让人们有机会很快地找到自己所需要的信息。Google就是其中的佼佼者。Google的成功来自其精确的搜索结果，而其采用的是Page Rank技术，分析网页之间互相链接的关系，用来做结果排序的依据，变相利用了网页制作人的判断力。假如我们利用的是所有网民的力量呢？这就是Web 2.0了。
         Web 2.0是以人为出发点的互联网，发动全体网民的力量，更像我们所追求的共产主义，让我们每个人成为信息的发布者，而不是在Web1.0的时候仅仅作为信息接受者。全民织网，然后通过软件和机器将信息发布出来，让人们更快地搜索并浏览到。

让我们看看现有的Web 2.0的应用如何以人为本：
1． Blog
网络日志，用户自己织网，发表新的知识，并与其他信息进行链接，自然地组织网络的内容结构。
2． RSS
将不同的内容聚合起来，并将用户产生的内容自动订阅发布。
3． Wiki
网虫自己创造的百科全书，糅合网络所有人的智慧。
4． Podcasting
个人声频/视频的发布与订阅，网民个性表现场所，传统媒体传播模式的改变者。
5． SNS
社会网络。基于六度原则，将互联网上的每个用户联系起来。其目标是帮助现有的互联网设备（包括PC和服务器）、3G网络设备（包括手机和移动网络后台设备）建立起高效的连接，而且设备之间的连接完全摆脱现有的服务器。
        互联网的创始人Tim Berners-Lee曾经提出了语义网(Semantic Web)的概念，目的是为了数据的规整及可重复被机器调用，提出使用语义化的内容发布工具， 试图从规则和技术标准上使互联网更加有序。而现有的Web 2.0的技术则是鼓励用户用最方便的办法发布内容（blog/podcasting），通过用户自发的（blog）或者系统自动以人为核心（SNS）的互相链接给这些看似凌乱的内容提供索引。互联网的目的就是为人服务，而这些线索是用户自己提供，则会更加符合用户使用感受。
Web 2.0的世界将会是网民的世界。

What is SOA?


open source soa solutions
Mule
An ESB messaging framework. It is a scalable object broker that can handle interactions with services and applications using disparate transport and messaging technologies.

ESB / In Production

ServiceMix
An open source ESB and SOA toolkit built on the semantics and APIs of the Java Business Integration (JBI) specification JSR 208.

ESB / In Production

Celtix
A Java ESB runtime and set of extensible APIs to simplify the construction, integration and reuse of business components using a standards-based SOA. IONA Technologies is a contributor.

ESB / In Development

open-esb
open-esb.dev.java.net Sponsored by SUN, this will be an ESB runtime based on JSR-208, Java Business Integration technology.

ESB / In Development

JEMS
JBoss Enterprise Middleware System (JEMS) is an extensible and scalable suite of products for creating and deploying e-business applications.

Suite of SOA tools / In Production

ActiveMQ
A fast Java Message Service (JMS) provider supporting clustering, peer networks, discovery, TCP, SSL, multicast, persistence, XA and integrates seamlessly into Java and J2EE containers.

Message Queue / In Production

JORAM
An implementation of JMS. It provides access to a MOM (Message Oriented Middleware), built on top of the ScalAgent platform.

Message Queue / In Production

AMQ
A financial industry focused open-source alternative to proprietary message queuing technology using web services. Sponsored by JPMorgan Chase & Co.

Message Queue / A Proposal

OSMQ
Open Source Message Queue (OSMQ) is a pure Java asynchronous messaging middleware framework with an interface that is less complex than JMS.

Message Queue / In Production

JBoss Messaging/ JBossMQ
JBoss Messaging is a re-implementation of JBossMQ. JBossMQ, which evolved from SpyderMQ, is the current production-ready JBoss JMS provider.

Message Queue / In Production

Axis
A reliable and stable base on which to implement Java Web Services.

Web Services Connector / In Production

Synapse
A service mediation framework built on web services specifications. Contributed to by IONA Technologies Sonic Software, Infravio, Blue Titan, and will be supported by WS02.

Web Services Connector / A Proposal

Sandesha
Allows a reliable communication between web services and clients. An implementation adhering to the WS-ReliableMessaging specification authored by BEA, IBM, Microsoft and TIBCO.

Web Services Reliable Messaging Connector / In Production

RM4GS
RM4GS (Reliable Messaging for Grid Services) provides reliable messaging for web services following the Web Services-Reliability specification supported by Fujitsu Limited, Hitachi Ltd., and NEC Corporation.

Web Services Reliability Connector / In Production

openadaptor
A Java/XML-based software platform which allows for rapid business system integration with little or no custom programming.

Services Connector / In Production

jUDDI
jUDDI (pronounced "Judy") is an open source Java implementation of the Universal Description, Discovery, and Integration (UDDI) specification for Web Services.

Discovery Service/ Pre Production

UDDI4J
UDDI4J is a Java class library that provides an API to interact with a UDDI registry contributed by IBM

Discovery Service Client / In Production

more detail:
http://www.optaros.com/wp/wp_2_soa_oss.shtml

                                                         

        五一长假，感谢庄老师的支持,我可以专心去准备SOA的比赛了。一个人在宿舍看东西也挺闷的，找个人聊聊才好。还好下午有些收获，且听一一道来。
        在SOA中，使用旧有的OOAD，EA，BPM这些建模方法已经不足以囊括SOA所涉及的所有部分，而集以上建模方法其中优点从其中改进而来的SOAD(Service-Oriented Analysis and Design)就成了SOA建模的首选了。
如何确认并定义服务呢？
       有顶至下的，商业层次的建模技术（如CBM等）可以作为SOA建模活动的开始。但是SOA的实施并不是从无到有的过程，创建一个SOA的解决方案是通过拆分现有的遗留系统成服务，操作，商业流程和商业规则并整合他们。


直接和间接的商业分析
BPM和通过对股东的谈话和CBM的直接商业分析是确定候选服务的合适的方法。
过往的经验表明需要间接的技术来补足这种方法。当挖掘候选服务时，必须与产品经理和其他商业经理谈话。比如，什么是计划中的支付模型？正在建立中的系统和所有已有的非SOA的案例都会作为建议分析。在建中的商业表示的术语是另一个操作候选分析的主要来源。
领域拆分
领域拆分，子系统分析，目的模型创建和相关技术是最先的商业架构方法或服务概念框架的方案。
服务粒度
选择合适层次的仇隙那个是服务建模的关键。应该将模型拆解到保证其完整性，一致性的越粗粒度越好。由于SOA不等同于Web service和SOAP不同的协议绑定可以用于在不同的抽象层次来访问服务。另一个选择是利用Façade 模式来将数个相关的服务绑定成粗粒度的服务定义。
命名约定
企业范围的命名规范（比如XML命名空间，Java包名，网络域）需要被确定。比如可以用服务的以一个名词和他的操作这个动词来命名。这个建议是来自OOAD的名字空间。

以下是结合了OOAD,BPM和EA的SOAD重要的概念：
Service categorization and aggregation 服务分类与聚合
服务有不同的用处和目的，SOAD中可以通过executable models（如BPEL）来简化其服务的组合。
Policies and aspects 策略与方面
在建模过程中服务是具有语法，语义和Qos特性的。正式的接口合约将不单单包括WSDL(Web Services Description Language)，还将包括Ws-Policy等等。同时还须定义些非技术的领域专家也可以理解的语言来描述系统的结构。
Process: meet-in-the-middle 流程:上下双管齐下
在处理真实世界的系统（包括遗留系统）用上下双管齐下的方法将会比单纯的自顶向下或者由下向上的方法更有优势。由下至上的方法会导致不良的商业服务抽象，使其设计更多是听从于现有系统，而不是去实现现有系统或者未来需要的需求。而有顶向下将会脱离现有的系统而产生不适合的需求。
Semantic brokering 语义代理
调用语法和语义是在接口定义中十分重要的。
Service harvesting and knowledge brokering 收集服务和知识代理
所有服务都是被定义用于重用的。所有服务的是被设计成超过1位用户所使用的。

这些将会是我们在以后设计所需注意的原则。

经过了前后10多天的筹备，今天我们这个团队终于开始了IBM SOA大赛的历程。在Kick Off会议上，我们探讨了小组的章程，组员的义务以及大致的分工。 
                                BlackStone小组章程

宗旨
“团结，求实，创新”是我们的座右铭，我们将通过参加2006“IBM杯”中国高校SOA应用大赛体验团队合作的工作方式，锻炼解决实际问题的能力。
原则
通过讨论我们达成以下共识作为小组的原则：
掌握知识固然重要，运用知识更为关键。
过程控制固然重要，完善的团队合作关系，良好的个人工作状态更为关键.。
任何的创新来自于对现实的深入分析，没有商业价值分析和流程分析的创新只是空想。
承诺
作为小组的成员，我承诺以下事项：
遵守行业规范和准则以及大赛组委会的安排，不做侵犯他人合法权益的事情。
充分意识到对团队和其他队友的责任，不做危害到团队利益的事情永远将与队友的关系和睦放在所有考虑事项的首位。
勤奋工作，每日至少将两小时的时间用于本项目组的工作。

        虽然我们第一道关卡是短短的不到两个月的初赛，和千里之行还相差甚远；但是我们都认为竞赛不是我们的全部，而只不过是我们在SOA的技术道路上的一个起步。就让我们从这里开始我们千里的SOA之路吧。