雖然Indigo是先前產品代號，現今已正式命名為"Windows Communication Foundation"，它的作用是系統之間的Communications and Connect，甚至是微軟實現SOA技術藍圖的主角，然而.NET 2.0、VS 2005、SQL Server 2005新一代技術才剛推出，現在談.NET 3.0的東西會不會太早？不趕緊就此打住這個話題，寫了也沒幾個人要看，嗯～是太早了點！談Indigo程式如何寫及如何運作是不會有幾個人要看，也無助於日常民生改善，那為何祭司還談？因為我想了很久的一個問題，也困惑我很久的問題...就是微軟的元件技術未來怎麼走？因為我公司內.NET技術學習的RoadMap要如何走，我現在要有一個明確策略，而目前有那麼多新東西要學，不希望浪費時間在"過眼黃花"的東西，押錯寶投資就白費，要把學時間與精力花在刀口，什麼樣的刀口？就是現在學習2年後剛好神功大成的刀口技術！
那什麼樣的技術會符合我的"刀口"定義？而什麼樣的技術又會是"昨日黃花"，在這祭司很坦白地告訴各位，未來刀口技術是"Indigo"，而昨日黃花是"COM、DCOM、COM+、.NET Enterprise Service、MSMQ等等"，唉呀！相信一堆人看了可能要狂罵，老子是COM+、.NET Enterprise Service的高手，您咀咒我呀！在那滿嘴信口雌黃，說什我的技術是"昨日黃花"...
很對不起各位因為我太老實了，老實到許多人沒法接受，忽視未來潮流只會有一個下場，就是抱著老舊技術而希望愈來愈小，或者是難以融入下一代技術主流，沒辦法IT是玩新不玩舊，比誰技術強不比誰年資老，而我寫這篇主題就是為了說明這一切，不只是寫給各位看，也是幫我自己洗洗腦，要早些接受現實，不要花費大把時間儘學些舊東西，學習的投資將來可能效益不大。
各位請別誤會我在鼓吹COM+、.NET Enterprise Service大家應現在趕快丟棄，相反的這些東西很多專案及企業仍在運作，不可以丟棄也丟棄不了的，我針對的是"不懂想學"、"只懂一點"、"公司將來有打算導入"這些技術的朋友，你們可以考慮是否策略性地暫時Hold住，因為學習新東西是會有"時間與精力"排擠效應的，學了這些蠻深澀的東西，相對的學.NET 2.0、VS 2005、SQL Server 2005新一代技術時間就會少許多，並且投資報酬率及折舊是逐年大增，一點也沒有保值；那已學的朋友就沒有這層顧忌，相信你們對於這些技術的投資在轉換學習Indigo技術會相對容易上手與理解。
OK讓我們的立即來檢驗祭司是吹牛還是微軟真的策略如此，首先我要引證的文章是微軟"Introducing Indigo: An Early Look"這篇，裡面有一段文字與圖片：
The initial releases of the .NET Framework included several different technologies for creating distributed applications. The figure below lists each one, along with the primary reason why a developer would typically use that technology. To build basic interoperable Web services, for example, the best choice was ASP.NET Web services, more commonly referred to as ASMX. To connect two .NET Framework-based applications, .NET Remoting was sometimes the right approach. If an application required distributed transactions and other more advanced services, its creator was likely to use Enterprise Services, the .NET Framework's successor to COM+. To exploit the latest Web services specifications, such as WS-Addressing and WS-Security, a developer could build applications that used Web Services Enhancements (WSE), Microsoft's initial implementation of these emerging specifications. And to create queued, message-based applications, a Windows-based developer would use Microsoft Message Queuing (MSMQ).
（點圖放大）
OK....各位可以清楚地在上表中看見Indigo將會集所有功能之大成，印證祭司不是在那吹牛；那為何微軟必須推出一個功能超強的Indigo，純粹為了展現其無所不能的技術水準嗎？並不是的，坦白說現今上面的這些技術的確必須有人好好管理管理，因為多年來各自為政各成山頭，該是將它們大一統的時機了，那位領軍的大將正是Indigo，接著讓我們來看看上面那段英文是如何陳述現有這些通訊技術的缺失，您就會瞭解Indigo對程式設計師及企業的重大意義，說明如下：
在.NET Framework發行之初包含了數種建立分散式應用系統的技術（上表列出這這些技術），並說明為何需要使用這些技術的主要理由，例如：
*建立具基本交互操作的Web Services，最佳的選擇就是ASP.NET Web Service(.ASMX)
*連結兩個以.NET Framework為基礎的應用程式，有時.NET Remoting是正確的途徑
*如果必須建立分散式Transaction及進階服務，必須使用Enterprise Services，它是COM+在.NET下的繼任者
*若要開發最新的Web Services規格如WS-Addressing and WS-Security，開發人員可使用Web Services Enhancements (WSE)
*若要建立queue及Message-based的Windows應用程式會使用MSMQ
各位看到上面幾種技術之所以存在是因為有著獨特而無法取代的優點，這意謂著全部都會的人很少，想全部都精也不太可能，意謂著如選了Web Services要做分散式Transaction就辦不到，對程式設計師而言這是一個互斥的選擇，必須從一堆不完美的技術中挑一個，全挑也可以，但除非你日常工作只需寫這部分，其他工作都不必做的話您才有可能全部精通；因此Indigo開創一個美麗新局面，讓大家不必在零碎不全的技術中掙扎，讓大家學一套通吃的贏家全拿的局面！不好嗎？我認為很好，除此之外Indigo還有一個重責大任，也就是SOA的使命，但今天並不談SOA，主要是讓大家瞭解未來的元件技術會如何走。
因為這陣子我一直在想微軟的元件技術未來會怎麼走，我該押寶哪個？.NET 2.0有沒什麼重大改進？看來好像沒有看到文件有特別說明！也有的人說微軟根本不重視COM+或Enterprise Services，主推Web Services，真的是這樣嗎？事實不然，因為Indigo大將正在建立百萬雄師，調兵遣將，請大家多給它一點支持，多一點掌聲，希望它能成功，而程式設計師也可以輕鬆點了！
註：
(1)我今天還在Google輸入COM+ 2.0、COM+ Next、Com+ future等等字眼，無論如何就是找不到，原因無它，Indigo就是解答，我也認為微軟不必再浪費力氣推一些過渡技術，因為沒有意義，我希望Indigo一次搞定！
(2)我可以暫時Hold住深入學習上述諸多技術的時間，因為目前VS 2005、SQL Server 2005及.NET 2.0才是我當下優先順位，因為Indigo讓我對未來有了信心.
看完之後別忘了留言和大家分享您專業的心得與意見，畢竟DotNet開發聖殿是因為各位精英到訪而顥得光榮有價值！
Indigo參考資料：
Introducing Indigo: An Early Look
Introduction to Building Windows Communication Foundation Services
Windows Communication Foundation
A Guide to Developing and Running Connected Systems with Indigo
摘自:http://blog.sina.com.tw/4907/article.php?pbgid=4907&entryid=11935
MS 的Indigo介绍:http://www.microsoft.com/china/MSDN/library/windev/longhorn/introindigov1.mspx
摘自:http://blog.sina.com.tw/4907/article.php?pbgid=4907&entryid=11935
MS 的Indigo介绍:http://www.microsoft.com/china/MSDN/library/windev/longhorn/introindigov1.mspx
