SpringSource Team Blog » Spring Integration: a new addition to the Spring portfolio

SpringSource Team Blog » Spring Integration: a new addition to the Spring portfolio

An application framework with built-in enterprise integration capability?

Coming from a middleware background, I have to disagree with such approach. Honestly.

I have been a Spring fan for 5 years. The elegant and relevant design of that framework fixed many of JavaEE's deficiencies, but it has gone a little too far this time.

Application Integration is a tough topic. People have used specialized middleware and interfaces to address it for realistic reasons:

1. Central control
• Can you imagine hundreds and thousands of applications doing integration of their own? That might be to outcome of over-relying Spring Integration capabilities
2. Enhanced monitoring, troubleshooting and management capabilities
• One central place to address message format, transaction issues, performance tuning and monitor your processes.
3. Business Process conformance
• Integration always follows the direction of Business Process. When Business Process changes, so should integration endpoints. A BPM oriented integration approach implements this requirement more efficiently.

InfoQ: Presentation: Transaction Management Strategies in Mission Critical Applications

InfoQ: Presentation: Transaction Management Strategies in Mission Critical Applications

Juergen Hoeller is one of most respected guru in Java programming landscape. Most of his reputation is duly earned: after all, he co-designed and is still heavily involved in the current Java programming standard framework, Spring Framework.

In Java society, a framework dictates thought leadership. An application framework is, actually, encapsulation of commonly defined best programming and design practices. An application framework like Spring greatly reduced the learning curve of commonly accepted Java programming practices and allowed software veterans to deliver software with increased productivity as well.

OK, now that I have done the praising part, let us begin with a little bashing. In this presentation, Juergen keeps mentioning different Transaction strategies, which is detailed and shows that he indeed knows his stuff, but one of Juergen's remark sounds a little alarming. Juergen seem to dismiss the importance of distributed transactions, saying that XA is needed in very few circumstances.

While I do agree partially on this part, an expert like him should be more careful in not misleading people. While you can certainly say that 90% of Java Web Applications don't need Distributed Transactions, you are misleading people. Because you forgot to mention that the rest 10% are composed of more high profile, and more profitable software projects.

Let me put it in another way. Are we Java Developers competing with PHP guys? PHP doesn't have XA as well, and they are doing just fine. If your software project can be safely implemented by using either Java or PHP, which 90% of time will be the case, then yes, you don't need EJB, and certainly don't need XA. But if you are lucky enough to climb to a strategic position like VP or CIO, you will regret that in your former career you haven't structured your IT systems so that distributed transaction propagation can be enabled.

And you, Juergen, should be fair when you try to dismiss the importance of EJB, XA and middleware. Because you are not ignorant.

專案控管：JavaEE還是Spring Framework?

這個題目其實我已經想了很久，不過最近看到的一個Case又讓我覺得不能不寫一下這方面的想法。一個完整的軟體專案必須考慮到的因素當然很多，除去掉PMP那些必然會提到的因素之外，我個人認為專案經理仍然必須將一些開發前、中、後的因素加以仔細的考量，並且以宏觀的技術角度來思考整個專案成敗的問題。

不管是PMP或者CMMI都相當強調風險的控管，殊不知風險的預估可不像是人壽保險那樣有客觀的統計數據作為依據。如果無法掌握手中的技術，風險這種無形的東西並不是能夠委外的。實際上要思考的方向應該是，如何動用手上所有的技術和工具來讓軟體專案的風險能夠降低。

以我的標題作為例子，目前Spring Framework是門顯學。我應該是在台灣使用Spring Framework的先驅吧！我當然可以理解這樣技術的便利性。不過便利性不代表不需要了解底層內容。以Connection Pool為例，目前Developer都有使用Apache DBCP的概念；不過許多Developer所忘記的是，Connection Pool仍然是一種基於TCP/IP Socket的一種技術。Socket並不是可靠的、永久存在的，所以完整的Connection Pool實作往往都會搭配一些測試參數以確保Connection要用的時候仍然是可用的。舉例來說，BEA WebLogic Server的Connection Pool能設定每一段時間就對資料庫進行測試查詢，讓資料庫的連線不至於因為idle而被防火牆移除。就以Apache DBCP來講，這樣的參數也是存在的。重點是，了解這些底層的細節其實是開發人員應該要能夠Handle的事情；而專案經理必須知道這種問題會發生。Code並不是只要Work就好；系統是必須經過時間的考驗的。既然已經使用了WebLogic，那開發的角度應該是要將Application Server的特性考慮進去；不然應該就要有把握能夠使用Framework之後不會有問題。

事實上，Springframework其中一個大好處就是它的ApplicationContext.xml。只要設定更改了，Code完全不動的情況下，就可以將DBCP Connction Pool改成WebLogic的Connection Pool。透過這樣的做法，Unit test的時候還是可以使用個人的資料庫在不啟動Application Server的狀況下進行資料查詢邏輯的測試，然後在上線測試的時候再改成WebLogic的Connection Pool。Springframework的一個宗旨就是要讓開發能夠Scale up and down easily。使用它而沒有參透它的精神那就太可惜了。要記住，Springframework只是拿來掩蓋掉JavaEE的複雜度；身為一個負責任的開發人員或者專案經理，你還是必須對底層的技術有所了解。你所不了解的，就會是你的風險；這是無庸置疑的。

Powered by ScribeFire.

Weblogic Server: Spring Console設定

自從去年(2005)BEA宣誓力挺Opensource應用程式框架以來，BEA和Spring Framework的Interface21就走的越來越近。除了和Interface21簽訂互相技術支援的合約外，Interface21和bea的工程師更是有許多技術底層的交流。Spring Console就是這樣的交流當中所衍生出來的一種產品。

首先，定位一下什麼是 Spring Console。Spring Console並不是開發時期的工具，而是應用程式部署在Weblogic平台上的一個JMX監控工具。大家都知道，從Spring 1.2以來，我們就可以透過MBeanExporter將任何一個POJO註冊在MBeanServer上成為一個JMX Standard MBean，然後就可以透過MC4J這樣的JMX監控工具來管理這樣的MBean。 Spring Console可以被當作是一個JMX的Web管理介面，只是這個管理介面可以直接內嵌在WebLogic Server 9.x的管理控制台裡頭。這樣的好處是，當管理人員登入到WebLogic Server管理控制台的時候，除了能夠管理一些WebLogic Server例行性的事務之外，還能夠管理跟Application邏輯相關的東西，比方說直接透過Web介面查詢目前的登入人數、工作排程、使用分析等等，如下圖：





講完這個東西的好處後，當然要講一下怎麼安裝。首先：



1. 到BEA網站下載Spring Kit。

2. 解開下載檔之後，可以看到裡頭有一個spring-wls-console-ext的目錄，開啟後可看到有兩個.jar檔：spring-ext-client.jar以及spring-ext-server.jar

3. 將spring-ext-server.jar放到你的DomainHome/console-ext下

4. 將spring-ext-client.jar放到你webapp的WEB-INF/lib下

5. 開發你的Web Application，然後參考這篇文章的applicationContext.xml設定

6. 將WebLogicHome/server/lib/consoleapp/APP-INF/lib中的commons-logging以及log4j的jar檔copy到你的DomainHome/lib下


這樣就搞定啦！

Powered by ScribeFire.