InfoQ: Why do Java developers hate BPM?

InfoQ: Why do Java developers hate BPM?

I have to admit that I'm indeed a BPM fan. It was 85% of my daily job during my BEA days. While I do acknowledge that no single BPM product in market is perfect, BPM software is the only middleware piece that, in my vision, still has tremendous amount of creativity potential.

Current hate for BPM can be categorized as follows:

1. Unclear positioning of what a BPM really is.
• Integration oriented BPM vendor would position BPM as an integration and "Service Orchestration" engine. Workflow Vendors position BPM as interaction between human, organization and systems, adding focus on BAM (Business Activity Monitoring) capabilities. For example, WebLogic Integration is integration oriented BPM; AquaLogic BPM on the other hand is derived from a workflow product.
2. Software Developers DO NOT think in terms of processes, but in terms of object models, frameworks and cute AJAX tricks.
• Project, instead of process, is the management term for everything software-related.
3. All above applies.

From point of view of any CIO, a software package makes sense when parts of its IT systems need to change constantly so that we do not re-invent the wheel every time. BPM software suites make perfect sense in corporate IT, it just needs to adjust it self to become more developer-friendly and deliver better quality.

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.

Funniest geeky analogy

It's always good to have a laugh once in a while....

Fred Daoud's Weblog : Weblog

I wonder why it missed GWT, but that already shows how many stuff java programmer have to deal with. God bless you, folks!

Speaking of which, I also spotted a similar fun article here.

Why do we ever bother ourselves with such things? ;-)


Technorati Tags: java

Powered by ScribeFire.

Deja vu: Open Handset Alliance

It happened before, and so it happens again.

Open Handset Alliance

I'm not saying that such an open ecosystem for smartphone existed before. I'm just saying that this alliance sounds very like Java Platform Enterprise Edition (Java EE). Perhaps it will also impact the industry like Java EE did. We shall see.

Being a developer-minded person, I would definitely look into it, even just for the notion "All applications are created equal".

That's where they nailed it. Symbian, UIQ, iPhone or Microsoft all suffer from not-so-decent built-in applications. The real tragedy about that is that developers are not allowed to modify core built-in applications such as address book and calendar. Yes, there are certain APIs here and there, but that's never enough. I hope that such kind of problem can be addressed by this alliance.

Well, congratulations to Google for another job/strategy well done. No matter who wins this war, software developers are going to benefit from it, I'm sure.

Powered by ScribeFire.

Technorati Tags: google, java

Java or .NET?

這個問題從我在唸書的時候就常常被問到。年輕的時候比較衝動，往往還會因為這種問題和別人在BBS上大打筆仗。進入職場之後，我理所當然的以Java Solution作為主要的職業選擇；當然，實際的工作之後，對於所謂的Java VS .NET的問題，我有了更寬廣的理解空間。

Java 和 .NET並不是天堂和地獄的差別。這主要是世界觀的差別。在Java的生態體系當中，你擁有的是選擇；在微軟的生態體系當中，你擁有的是統一的秩序。從企業IT架構的角度來看，選擇Java 或者 .NET的差異主要在於，你怎麼看待你企業IT所扮演的角色。IT對你的企業，到底是一種消耗品，還是一種競爭優勢？這其實是一個很Tricky，也很少人會老實作答的問題。一般來說，願意承認自己下班回家會看A片的人應該比願意承認自己是消耗品的人來得多；但事實上許多目前的IT不可諱言的是一種消耗。如果你維護的系統每天要改好幾次table schema, column name, source code... 你認為這是不是一種消耗性行為？

我想這是為什麼Google這種以技術優勢作為老本的公司會選擇C, C++, Java等技術來作為他們本身的技術架構。以Google來說，他們的競爭優勢是技術，所以需要的是能夠量身訂做的技術作為基礎；在這個部分，.NET的許多假設和限制會讓它無法被採用。但是.NET搭配上微軟的工具，的確讓小型AP的量產變成可能。在這方面，Java真是望塵莫及。

所以要想清楚到底要的是什麼，然後作相對應的選擇。

Powered by ScribeFire.

JRockit 參數速記

最近在幫一個客戶做效能調較的時候，發現JRockit有一個相當有趣的參數：-Xgcprio:throughput以及-Xgcprio:pausetime。

• Throughput: 以效能總輸出作為JVM GC演算法的指導原則
  
• Pause Time: 以降低每次GC所花的時間作為GC演算法的原則。甚至可以在參數後面Append以微秒為單位的整數作為每次GC所花的時間的參考依據，只是這個數字沒辦法保證；如果需要強制很低的GC時間可以考慮使用WebLogic Realtime。
  

預設來說JRockit的Heap只有一個區域，強行加入 -Xns 會加入 Nursery 的 Heap (也就是New Generation)。JRockit的Tuning方法看來和 Sun JVM 有些許的出入，但看來-Xgcprio:throughput配合大於512m的記憶體有最佳的整體效能。

不過說到這邊還是要解釋一下，合謂最佳的整體效能。

就以一般的Web Site，在一般使用者網頁Loading可以接受的時間範圍之內，假設是30秒。那只要Response Time不大於30秒，或者95%的Response Time小於30秒，以這樣的範圍去計算所調整出來的Throughput效能是最佳的整體效能。這主要是因為一般的網頁瀏覽並不需要去定義非常嚴格的SLA。

如果應用程式有非常嚴謹的SLA，比方說1秒之內沒回應就當作是交易失敗，那應用程式的調整就要以pausetime作為調整的依據，並以這種依據來期待所謂的最佳效能。

因為工作的關係，我發現非常多人都很Care效能；這基本上是非常正確的。不過就和所有的事情一樣：想要得到你要的結果，你必須知道自己要什麼。如果對效能的期待沒有一個準確的定義，往往會得到和自己所需要的不太一樣。

powered by performancing firefox

推薦使用的Eclipse Plugin

• KeepResident: 大部分的Java開發人員都使用Eclipse。大部分的Eclipse使用者都使用Windows作為開發平台。但是很少人知道可以使用這樣的Plugin來強迫Windows將Eclipse的JVM配置在實體記憶體當中。現在你知道了，但是用了之後當機別怪我XD

用跑步來解釋JVM的Garbage Collection

用生活化的例子來解釋技術上的細節通常效果都很好，即使是一點都不懂技術的人都能夠很快的明白。

最近跟客戶在解釋所謂的Garbage Collection的時候忽然福至心靈，想到以下的解釋。

JVM和人的心肺運作其實相當類似。我們透過吸氣將氧氣吸收，呼氣將身體內的二氧化碳排出，像這樣的道理，人人都明白。但是有時候身體的運動太激烈，會造成心肺活動趕不上氧氣的消耗；舉例來說，假設我快跑一分鐘，可能只要休息一分鐘，我的呼吸和心跳就可以恢復正常。但是如果我將快跑的時間延長到兩分鐘，那在一樣的體力狀態下，我可能需要休息兩分半鐘才能夠將呼吸調回正常狀態。這其實都是因為在快速的跑步下，身體對氧氣的需求是大於我們心肺能力所能夠提供的量，所以需要更久的休息時間才能將身體恢復程正常的狀態。

JVM也有類似的狀況。所謂的Garbage Collection，就是JVM的休息時間(雖然就技術上來說，這反而可能是JVM最繁忙的時候)。如果一開啟JVM的時候就將Heap開到很大，這就好比我們將快跑的時間延長一樣，需要更多的時間來休息/Garbage Collection。但是如果開得太小，又會造成太過於頻繁的休息/Garbage Collection。所謂的JVM Performance Tuning，正是考慮到上述各種因素之後的Tradeoff。

WebLogic Server: 交易的迷思

一般的程式設計師對於單一資料源的交易處理機制都有一定的了解。所謂的交易控管，用白話文來說，就是只要我需要一次更動多筆資料，而這個更動的行為在邏輯

上是一個具有業務價值的單一行為，我就需要交易的處理機制。但是比較少人花心思去了解的是J2EE裡頭規範Application
Server必須Follow的XA Transaction Protocol以及更具有價值的Transaction Recovery機制。

接下來我想要點出的是一般人的迷思：

1. 迷思：只有在多重資料庫的資料更新場合才需要2PC。事實上只要你有兩個以上的DataSource想要同時參與一個Transaction，你就需要2PC。除非你自行處理所有的交易補償邏輯，否則兩個以上的Local Transaction，是不會有相互關連，資料的正確性也就大大的有問題了。
2. 迷思：只要依賴資料庫的交易機制，我的資料正確性就無懈可擊！
   假設Application Server正在處理一個交易，一個Batch
   update好了。你從DataSource1把資料傾倒到DataSource2，一邊將DataSource1的資料清除掉。這時候，不知道什麼原
   因，網路斷了，或者電源線被踢到了....源源不絕的客服電話把你灌爆。你以為你把電源插上就沒事了，可是.....咦，資料好像不太對？這時候如果你用
   得是WebLogic Server Advantage以上的版本，你可以透過Transaction Log自我恢復的機制，來讓WebLogic
   Server幫你Rollback資料庫裡頭的資料，維護你資料的Consistency。當然，你可以自己花錢花時間寫這個機制....但是你的客戶是
   否可以接受哪怕是幾分鐘的資料不正確？

簡單的結論：除非你的AP只提供簡單的查詢介面，否則你幾乎一定會需要用到2PC以及
Transaction
Recovery的功能。Transaction的問題很難Debug，已經看到太多英才死在這邊了，拜託大家緬懷先列的犧牲，不要再為了這種問題而強制
性失眠了，請愛用XA，謝謝！

Powered by ScribeFire.

Google Web Toolkit (Oh My God)

Google終於推出Java Web Application Framework了！(地震！)

從網頁上的解釋看來，本質上比較像是一個Java- Map那樣酷炫的Web AP。

挺有趣的Concept！不過目前為止我所看到的新一代Rich Internet Application Framework都有一個共同的問題：Java←→Javascript Type Mapping。不曉得Google Web Toolkit有沒有類似的問題。

或許是所有RPC導向的設計方式都有這樣的限制吧？目前Web Service的發展也是遇到類似的問題。Complex Java Object Type是比較難以正確的對應到javascript物件的；只是就Web Service來說，我們可以透過像是AquaLogic Service Bus內建的XQuery Transformation來做Object→XML的對應，但是在Browser裡頭的javascript→java RPC如果也要這樣做也太Heavy Weight了吧？

不過不管怎樣，對於技術狂熱者來說，最近這一年真的太棒了。為了方便以後追蹤，我把一些我認為有機會成為主流的RIA技術列在下面，順便讓大家參考一下：

• http://code.google.com/webtoolkit/
• http://getahead.ltd.uk/dwr/
• http://www.openlaszlo.org/

妙文推薦：Real-World Experiences With Hibernate - Shine Technologies

Real-World Experiences With Hibernate - Shine Technologies

這篇文章寫得挺不錯的，值得一讀。作者主要的重點是在於討論該怎麼使用Hibernate，以及怎樣讓Hibernate幫助你節省開發時間、增進效能而不會成為你專案成功的絆腳石。

OR-Mapping的概念在Java的世界當中是由Hibernate發揚光大的，但是看來任何屬於"Layer of indirection"的中間層技術都會有些黑暗面。當然為了效能、為了交易正確性，我們還是有必要去知道很多RDBMS的細節，不過我慢慢的覺得，OR-Mapping的概念似乎已經不夠用了。

以企業作為單位來說，比OR-Mapping要來得更實際的，應該是整個企業的Domain Model，以及環繞著這個Domain Model的Data Service。

IT的歷史又翻過了一頁....

Generic DAO Pattern

Java 5.0的Generics為Java Programming帶來許多新的可能性。

在正式接觸Generics之前，看一些Sun所提供的Sample Code，還以為Generics唯一的好處就只是能夠針對Collection類型的資料結構宣告內容物的型別，像是這樣：

ArrayList<Person> anArrayList = new ArrayList();
anArrayList.add( new Person() );
Person aInstanceHolder = anArrayList.get(0);

但是最近看到Hibernate的始作俑者─Gavin King─在他的Blog裡頭提到一種Generic Hibernate DAO的想法，才驚覺其實Generics擁有更大的用途。正確的使用Generics能夠減少很多必要的程式碼，而最顯而可見的地方，就是我們經常用到的Data Access Object(DAO Pattern)。

一般在使用DAO的時候，其實是必須針對每個Domain Object進行DAO相關的介面制定以及實作；坦白說有時候真的會覺得自己真是白痴，明明寫的CRUD Operation大同小異，但是就是沒辦法將這些程式碼整理成可重複利用的單位。

在Gavin King的Blog裡頭，我找到了能夠將DAO程式碼大幅減少的解決方案：Generic Hibernate DAO Pattern。但是由於Gavin King所提供的Sample Code所使用的API是Hibernate 3的Session API，所以我把這個Pattern的Code稍微潤飾一下，改成適合和Spring Framework可以一起搭配使用的Code。以下就是安東尼版本的「Generic DAO Pattern」。

首先，我們先定義一個Generic DAO Interface。既然是Interface，那麼顧名思義，是不會對任何Persistence API擁有Binding關係的：

public interface GenericDao<T, ID extends Serializable>{

T findById( ID id, boolean lock );

List<T> findAll();

List<T> findByExample( T exampleInstance );

T makePersistent( T entity );

void makeTransient( T entity );
}

在上面的介面定義當中，我們可以看到大量Generics的影子；而這段Code當中使用Generics最關鍵的地方就在於Interface宣告搭配Generics。我們待會會看到這樣的宣告方式搭配了物件導向的繼承/實作之後所發揮的驚人能力；在那之前，我們再定一一個GenericHibernateDao的抽象類別：

public abstract class GenericHibernateDao<T, ID extends Serializable> extends
HibernateDaoSupport implements GenericDao<T,ID> {

private Class persistentClass;

public GenericHibernateDao() {
this.persistentClass = (Class) ((ParameterizedType) getClass()
.getGenericSuperclass()).getActualTypeArguments()[0];
}

public Class getPersistentClass() {
return persistentClass;
}

@SuppressWarnings("unchecked")
public T findById( ID id ) {
T entity;

entity = (T) getHibernateTemplate().load( getPersistentClass(), id );


return entity;
}

@SuppressWarnings("unchecked")
public List<T> findAll() {
return getHibernateTemplate().loadAll( getPersistentClass() );
}

@SuppressWarnings("unchecked")
public List<T> findByExample( T exampleInstance ) {


return findByCriteria(Example.create( exampleInstance ));
}

@SuppressWarnings("unchecked")
public T makePersistent( T entity ) {
getHibernateTemplate().saveOrUpdate( entity );
return entity;
}

public void makeTransient( T entity ) {
getHibernateTemplate().delete( entity );
}

/**
* Use this inside subclasses as a convenience method.
*/
@SuppressWarnings("unchecked")
protected List<T> findByCriteria( Criterion... criterion ) {

DetachedCriteria crit = DetachedCriteria
.forClass( getPersistentClass() );

for (Criterion c : criterion) {
crit.add( c );
}

return getHibernateTemplate().findByCriteria( crit );
}

}

OK，我們又看到了大量的Generics，以及對Spring Framework Hibernate Support API的一些呼叫。可能有些人已經開始發現一些端倪了：在這個抽象類別當中所定義的CRUD操作，任何繼承的Class都能夠在幾乎不需要寫Code的情晃下「免費」使用：

public interface AuthorDao extends GenericDao<Author,Integer> {

}

public class AuthorDaoHibernateImpl extends GenericHibernateDao<Author,Integer> implements AuthorDao<Author, Integer> {

}

你並沒有看錯，就只要寫這些宣告，你就可以免費使用剛剛在GenericHibernateDao所定義的所有CRUD Operation。

這是怎麼做到的？

讀者只要注意一下Sample Code當中用藍色以及紅色的部分所加強部分就可以猜出來了：我們把「T,ID」的實際型別透過繼承宣告「丟」進去，讓Concrete Class在借用GenericHibernateDao的操作時，JVM能夠分辨的出來到底實體的Class Instance是什麼。很神奇吧！
Technorati Tags: java, hibernate, generics

Maven 2.0出爐！

Maven 2.0終於Release了。

雖然大多數的人都還是用Ant來作為標準的Java Build工具，我卻對Maven一直情有獨鍾。

Maven 1.0被證明在某種程度上是一種失敗。在Maven 1.0有許多好的概念和想法，卻因為缺乏一些關鍵功能以及一些技術細節的繁瑣而導致Java眾高手的群起攻伐。

以下是我覺得Maven 1.0時代的優點：

• 具備Dependency Management的能力
• Project Model的概念比起Ant要先進的太多….Ant的build.xml本身就是一種程式語言，而不是以專案的資料結構來看待這些需要建構的Artifact，以至於一些常用的task往往還是要重新寫一次，重用性非常差。

以下是缺點：

• 雖然說有Dependency Management，但是會導致對於Repository的依賴；而且缺乏Transitive Dependency Management，這個功能的好處就少了一大半。
• 雖然有Project Model的概念，但是客製化變得相當困難；主要是因為Plugin架構採用Jelly─一種畸形的XML程式語法─所導致。

令人振奮的是，從Release Announcement來看，剛剛提到的兩大缺點似乎都解決了。大家一起上Maven的網站 下載來玩吧！