上午到oracle公司就平台公升級方案建議進行初步交流，對上地不太熟悉，雖然位址是上地西街6號，我們還是想通過看建築物上的標誌去找，因為我們確信，oracle工作大廈一定會有醒目的oracle標誌,當我們看到有標誌時，就毫不猶豫的向它走去，大廈正門前面很特別，有乙個長方形的水池，水不深好象也不流動，水池上蜿蜒著幾個原形的石台，通過石台才能到達樓門，走在上面有一種別樣的感覺，完全沒有了"it"的壓力，而是一種小橋流水的感覺，可走進去就頓感壓抑，裡面一片沉靜，透者禁閉的玻璃門看到了oracle標誌，但是我們進不去，走錯了，這是研發中心，而我們要去的是產品部門，他們在馬路的對面，上面沒有標誌。
接待我們有三個人，乙個管銷售的，乙個是資料庫專家，乙個是中間套件專家。主要是聽他們的介紹。了解了oracle 10g的新特性：採用了網格技術，優點是資源呼叫隨需應變，持續可用，實現0宕機時間。10g是個自我管理的資料庫，全新的web管理介面，增加一些方便使用的功能：效能診斷（需要單獨購買選件），sql調整，sga記憶體管理等極大的減輕dba工作，支援新的備份恢復方式回滾式恢復，以前只能是前滾式恢復，還有security backup備份資料能用密碼保護等。年底會推出11g。
oracle融合中介軟體體系架構（f m w)的介紹：
一、對我們公司存在問題的總結概括
1、多個應用系統，2、不同技術，不同平台，3、關聯困難，統計分析困難，4、多使用者名稱和密碼，5、許可權管理和統計，6、全文檢索，7、流程審批
我認為很到位
二、electricsstore 演示， 統一的登陸介面，後台多處理系統，不同角色的人看到不同的個性化介面，內部完善的訊息互動，很強的bi功能等
三、soa的系統建設思想，即面向服務的思想，通過流程引擎把多個服務串起來就完成乙個特定的業務。
四、soa suite包含的產品：
流程整合工具：bpel
安全,統一登陸： idm
介面整合: oracle portal
企業級報表： 基於xml， 用word畫報表模板bi
oracle還有esb電子商務套件，由於時間問題沒有介紹。
總體感覺oracle的產品還是挺強的。
相反下午接待了sun的來訪，也是討論同樣的問題，但卻是截然不同的切入點，沒有介紹產品，而是談**的設計原則，倡導軟體即是服務的理念saas，強調把公司的運營和多年的沉澱，用自己獨特的方式展現出來，應該通過自主開發來保障**的靈活性和擴充套件性，我本人比較認同。產品和技術哪個更好，沒有定論，以最小的代價實現我們的需求就是最好。
通過兩個公司的交流可以歸納為，oeacle推薦soa方式搭建系統，sun則強調saas。soa和saas之間到底有什麼關係呢，幸好我在網上看到類似的文章，摘錄幾段文字提供參考，其實這個問題就是仁者見仁，智者見智。
soa和saas兩者之間存在著怎樣的聯絡？乙個是服務基礎架構(service-oriented architecture)，乙個是軟體即服務(software as a service)。soa不太可能也不具備作為企業內部saas執行的能力， 但它能夠在很多方面為saas鋪平道路；而無論內部基礎架構有多麼soa化，都沒有與市場驅動的saas相抗衡的靈敏度。但至少，他們都是關於「服務」的。
隨著saas的愈發火熱，加之soa的繼續深入，這兩種概念開始引出了一些新的混淆，市場上越來越多的人在談論soa產品在saas方面的能力。最近的一篇由物件管理組織(omg)soa聯盟所完成的，針對首席資訊官和首席技術官的調查指出，市場上存在著這樣一種期待，那就是soa改變了軟體廠商的市場，因此重要的軟體可以通過saas使用soa的方法提供給大家。
「我確實是把saas看作乙個傳遞機制，這個傳遞機制指出單個例項/多個承租的應用軟體程式，」他說。「而且我將soa視為開發鬆散的耦合的軟體的哲學框架。因此，soa包括了一切關於軟體是如何被架構起來的東西，而saas是一切關於軟體是如何被應用的。」
談談專案部署交流會的體會
今天早上給同事培訓了專案部署的一些實踐經驗，並且邀請了上個星期進行系統部署的專案組給大家介紹案例。經過培訓，我發現來參加培訓的同事其實都還沒有讀過或者仔細讀過我的寫過的關於部署的blog，我今天的培訓都圍繞這兩個帖子展開。我看到有不少部門經理來詢問下週什麼時候再培訓，他們還會再安排人員來參加，其實，...
專案需求和客戶交流的心得體會
從畢業到現在，做過好幾個不同的專案，不想談論技術相關的話題，我更多的是談論與客戶的交流和溝通。眾所周知，客戶往往都是不懂系統開發技術的客戶群體。所以，對於需求管理人員，既要弄懂客戶所描述的系統功能，還要用最通俗的語言，將自己所理解的需求告知客戶，待雙方達成一致，方可算作好的需求調研。做好需求溝通，其...
專案需求和客戶交流的心得體會
從畢業到現在，做過好幾個不同的專案，不想談論技術相關的話題，我更多的是談論與客戶的交流和溝通。眾所周知，客戶往往都是不懂系統開發技術的客戶群體。所以，對於需求管理人員，既要弄懂客戶所描述的系統功能，還要用最通俗的語言，將自己所理解的需求告知客戶，待雙方達成一致，方可算作好的需求調研。做好需求溝通，其...