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之路吧。?