apk zipalign

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/autocloseable_jms_2_resources

---

Java EE 7のリリース日が近づくにつれ、新機能を扱うブログや記事が出てき始めています。以下のエントリでは、John Amentという、JMS 2.0専門家グループの主要な独立メンバーが、自動的にリソースをクローズ（AutoCloseable）するJMS 2.0リソースについて説明しています。

What's New in JMS 2 (Part 1)
http://john-ament.blogspot.se/2013/03/whats-new-in-jms-2-part-1.html

この機能はJava SE 7のtry-with-resourcesを利用しており、JMSリソース（接続、セッション、メッセージコンシューマやメッセージプロデューサ）のクリーンナップが非常に簡単になっています。

The try-with-resources Statement
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

@Injectを使って新しいJMS Context APIを利用していない非Java EE環境ではこの機能は特に重要です。先ほどのエントリにはJMS 2.0のコードサンプルも含まれています。JohnはJMS 2.0に関するブログエントリを今後たくさん書く予定なので、期待してお待ち下さい。
JMS 2.0って何？という方のために、JMS 2.0は現時点でｈは最終ドラフトが提示された段階にあります。ドラフト仕様を自由にダウンロードしてご覧頂くことができます。ドキュメントの最初の部分で「What is new in JMS 2.0?」というセクションがあり、そこで非常に簡潔にJMS 2.0についてまとめられています。

JSR-000343 Java(tm) Message Service 2.0 Proposed Final Draft
http://download.oracle.com/otndocs/jcp/jms-2_0-pfd-spec/index.html

原文はこちら。
https://blogs.oracle.com/binkyscave/entry/javase_7_try_with_resources

---

最近、Oracle Technical Network Java Developer Daysで実施するJava SE 7のHands-onコンテンツのアップグレードを完了しました。このHands-onの目的の一つとして、Project CoinとNIO2といったJava SE 7の新機能を参加者に伝えることがあります。その他の目的は（これはちょっと微妙な目的ではありますが）、NetBeans IDEとそのリファクタリング機能をお伝えするというものです。さらに、アップデートの発表の最近のJavaSE 6のアップデート終了の発表に伴い、Java SE 7にアップグレードするのに併せてご自身のコードをアップグレードすることを考えてらっしゃる方に対し、リファクタリングのヒントをご案内するよい機会というのもあります。

まずはじめに

Java SE 7以前のHands-onの元々の課題は以下のようでした。

private static void tryWithResource6c() {
        System.out.println("TESTING TRY WITH RESOURCES 6c");
        UglyCloser closer1 =  new UglyCloser("First closer");
        UglyCloser closer2 =  new UglyCloser("Second closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
            closer1.close();
            closer2.close();
        } catch (Exception ex) {
            // quietly ignore
        }
        fakeAssert(closer1.isClosed(), "Closer1 should be closed");
        fakeAssert(closer2.isClosed(), "Closer1 should be closed");
    }

「try-with-resourcesの形式に変換」する候補であることを示すリファクタリングのヒント（黄色の三角形”！”のアイコンを持つ小さな電球）が、コードの行番号の隣に出てくるものと思っていましたが、そのようなアイコンが現れませんでした。リファクタリングが推奨されるコードの種々のパターンを試す必要があるようなので、上記コードのいくつかのバリエーションでリファクタリングする方法の○と×を確認してみました。

例1:
以下のコードでは、リファクタリングのヒントが現れます。

private static void tryWithResource2a() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
         } catch (Exception ex) {
             // quietly ignore
         } finally {
             closer1.close();
         }

      }

期待通りに、以下のようにリファクタリングされます。

private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        try (UglyCloser closer1 = new UglyCloser("First closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }

    }

例2:
しかし、try-finallyブロック外でオブジェクト参照している場合はリファクタリングされません。まぁ、わからなくもないです。

private static void tryWithResource2() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
         } catch (Exception ex) {
             // quietly ignore
         } finally {
             closer1.close();
         }
         fakeAssert(closer1.isClosed(), "Closer1 should be closed");
      }

ここで重要なのは、現在のtry-with-resourceの形式では新しいリソース変数を使うということです。try-finallyの外部で変数への参照がある場合、こうした参照はスコープ外になります。この例は、実世界のコードで存在する可能性は低いのですが、コード変換時にスコープ外のリソース変数を探すことを考慮すべきでしょう。

例3:
奇妙なことに、finally節を削除するとリファクタリングされません。closer1を永久に閉じていないので、これはおそらくまずいコードだと思うのですが…

private static void tryWithResource2b() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
         } catch (Exception ex) {
             // quietly ignore
         }
      }

この例ではfinally節にcloseがなく、実際にコード・セマンティクスの変更があります。Java SE 6以前では、自動クローズ機能がないということを忘れないで下さい。おそらく、オリジナルコードのプログラマーは間違えてcloseを呼び出さなかったか、もしくは意図的にcloseを使わずに脱出していたのでしょう。いずれの場合においても、さらなる分析が必要です。

例4:
同様に、try文でオブジェクトをcloseすると、closeされません。

private static void tryWithResource2b() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
             closer1.close();
         } catch (Exception ex) {
             // quietly ignore
         }
      }

この例では、プログラマが何を考えているのかわかりません。プログラマー側でcloseを呼び出そうとして失敗したのかもしれないし、tryの中にcloseがあることが重要なのかもしれません。この時点では選択の余地がありませんが、リファクタリングの際には、プログラマがどうしたかったのかを考慮する必要があります。

例5:
最後に、try-catchブロック内で複数のオブジェクトを取り扱う場合、一つだけがリファクタリングされますが、これはおそらくNetBeansのバグでしょう。もちろん、上記のすべての単一バリアントの中断も適用されます。

private static void tryWithResource1a() {
         System.out.println("TESTING TRY WITH RESOURCES");
         UglyCloser closer1 =  new UglyCloser("First closer");
         UglyCloser closer2 =  new UglyCloser("Second closer");
         try {
             fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
             fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
         } catch (Exception ex) {
             // quietly ignore
         } finally {
             closer1.close();
             closer2.close();
         }
     }

以下のようにリファクタリングします。

private static void tryWithResource6b() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6a");
        UglyCloser closer1 =  new UglyCloser("First closer");
        try (UglyCloser closer2 = new UglyCloser("Second closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
        } catch (Exception ex) {
            // quietly ignore
        } finally {
            closer1.close();
        }
    }

これはcloser1がリファクタリングされておらず、部分的なリファクタリングです。おそらくNetBeansのバグではないかと思いますが、もしtry-with-resourcesを最大限に活用したい場合には、手作業でのリファクタリングを追加する必要があります。

新しいHands-onでは…

Hands-onのコンテンツのために、try-catchブロックのリファクタリングで予想される3種類のリファクタリング体験をご紹介しましょう。

1. 完全なリファクタリング

private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        UglyCloser closer1 =  new UglyCloser("First closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        } finally {
            closer1.close();
        }
     } 

以下のようにリファクタリングされます。

private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        try (UglyCloser closer1 = new UglyCloser("First closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
    }

2. 部分的なリファクタリング

private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        UglyCloser closer1 =  new UglyCloser("First closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        } finally {
            closer1.close();
        }
     } 

以下のような不完全なリファクタリングではなく

private static void tryWithResource6a() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6A");
        try (UglyCloser closer1 = new UglyCloser("First closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
     } 

手作業で以下のように変更する必要があります。

private static void tryWithResource6b() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6b");
        try (UglyCloser closer1 = new UglyCloser("First closer");
                UglyCloser closer2 = new UglyCloser("Second closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
    }

3. リファクタリングしない

private static void tryWithResource6c() {
        System.out.println("TESTING TRY WITH RESOURCES 6c");
        UglyCloser closer1 =  new UglyCloser("First closer");
        UglyCloser closer2 =  new UglyCloser("Second closer");
        try {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
            closer1.close();
            closer2.close();
        } catch (Exception ex) {
            // quietly ignore
        }
        fakeAssert(closer1.isClosed(), "Closer1 should be closed");
        fakeAssert(closer2.isClosed(), "Closer1 should be closed");
    }

手作業で以下のようにリファクタリングする必要があります。

private static void tryWithResource6b() throws Exception {
        System.out.println("TESTING TRY WITH RESOURCES 6b");
        try (UglyCloser closer1 = new UglyCloser("First closer");
                UglyCloser closer2 = new UglyCloser("Second closer")) {
            fakeAssert(!closer1.isClosed(), "Closer 1 should be open");
            fakeAssert(!closer2.isClosed(), "Closer 2 should be open");
        } catch (Exception ex) {
            // quietly ignore
        }
    }

まとめ

このHands-onで使われない部分ですが、ご自身のコードのtry-catchブロックをJava SE 7用にリファクタリングする必要が出てきた場合、結果を確認する必要があります。あなたは幸運にも完全なリファクタリングを実施しているかもしれません。リソースを1個だけ使用している場合は一般的に正しくリファクタリングされているでしょうが、複数のリソースを使用している場合、ツールによるリファクタリングに対し、手作業の追加が必要になるでしょう。try-catchブロックのスコープ外のリソースの場合は、手作業でのリファクタリングが必要になるでしょう。

原文はこちら。
https://blogs.oracle.com/soacommunity/entry/smart_meter_oracle_event_processing

---

［訳注］
以下のコンテンツをご利用になるにはOracle Partner Networkのアカウントが必要です。

Oracleデモシステムにアクセスするには、OPN（Oracle Partner Network）もしくはパートナーのエキスパートにお尋ね下さい。

Access Oracle Demonstration Services (Oracle Partner Network)
http://www.oracle.com/partners/secure/sales/sales-kits/gse-029986.htm
Oracle Partner Business Center (Oracle Partner Network)
http://www.oracle.com/partners/en/opn-program/membership-resources/business-center/partner-business-center-041039.html

このデモはOracle Event Processing（OEP）と公共セクターの"スマートメーター"を組み合わせて利用し、過剰なエネルギー消費を管理したり、停電を防止したり、プリエンプティブな損傷回避プロセスを開始したりする、というものです。

このデモでは以下の内容を紹介しています。

• 流通ネットワークの変電所の電圧、電流、容量のようなイベントストリームをキャプチャするダッシュボード
• 複数のイベントストリーム間で閾値条件を検出
• キャッシュを使い動的に閾値を設定することが可能で、コンテクストデータを追加して集約をサポート
• 2種類のパターンマッチングを使い、持続的なイベントデータの入力ストリームフローを発見
• 予想される応答を監視するための"行方不明イベント"のパターンや状態、状態遷移を表すための関係を使い、アラートを生成
• 無関係なアラームイベントを除去するパターンマッチングを使ったアラームの管理
• OEP Visualizerで典型的なCQL Rulesを編集および観察

このOEPスマートメーターのデモはDSSですでにご利用いただける状態になっています。詳しくはOPNのページでご案内しています。

Announcement #375: OEP Smart Meter Demo Now Available
https://kix.oraclecorp.com/KIX/display.php?labelId=7014&articleId=350956
Access Oracle Demonstration Services (Oracle Partner Network)
http://www.oracle.com/partners/secure/sales/sales-kits/gse-029986.htm

原文はこちら。
https://blogs.oracle.com/soaproactive/entry/authorization_model_in_soa_suite

---

SOA Suite 11gでどのように認可が行われるのかをWebLogic Server管理コンソールとEnterprise Managerの間で解き明かすことは困難かと思います。このエントリでは、どのように2つが協調して動作するのかを説明し、うまくいけば思ったよりも簡単であることを示すことを目的としています。

SOA Suite 11gでは、一つの認証スタックと2つの認可スタックがあります。

1. 認証（Authentication）はWebLogic Serverが担当します。セキュリティレルムの認証プロバイダーの順番と、それらに設定された制御フラグに基づいて認証します。
2. 認可（Authorization）はWebLogic Serverのグローバル・ロール定義とEnterprise Manager Fusion Middleware ControlのSOAアプリケーション・ロールに分かれています。WebLogic ServerのロールはWeblogic Server管理コンソールでのやりとりを管理し、SOAロールはSOAリソースやアクティビティの権限を管理します。ほとんどの場合、ユーザーは両方にアクセスする必要があります。

では、認可スタックを説明していきます。

WebLogic Serverでは、グローバル・ロールを標準で定義しており、WebLogic Server管理コンソールで設定します。今回の目的では、「Admin」グローバル・ロールを取り上げます。これはEnterprise Managerにも同等のものがあり、こちらも他のロールを代表するものです。標準のドメインでは、このロールには、事前設定された'Administrators'グループをメンバーシップ条件だけがあります。これは、 "Administrators"と呼ばれるグループのメンバーであるすべてのユーザーが、WebLogic Serverの'Admin'グローバル・ロールの権限が付与されることを意味します。ユーザーがWebLogic Server管理コンソールやEnterprise Managerにログインするためには、グループもしくは個々のユーザーに関連付けられる形でWebLogic Serverのグローバル・ロールの少なくとも一つの権限を持っている必要があるので、これは重要です。

WebLogic Serverロールにアクセスするには

1. WebLogic Server管理コンソールにログイン(http://host:port/console)
2. 左のドメイン構造から［セキュリティ・レルム］を選択
3. デフォルトでは、"myrealm"と呼ばれる一つのレルムがあるので、それを選択
4. ［ロールとポリシー］タブを選択
5. リストの［グローバル・ロール］を展開
6. ［Roles］を展開
7. 'Admin'ロールが先頭行にあるので、［ロール条件の表示］をクリックして内容を確認

デフォルト構成では、条件は以下のようになっています。

SOA SuiteのEnterprise Manager Fusion Middleware Controlでは、アプリケーション・ロールをsoa-infraアプリケーションのために利用できますが、そのうちの一つが"SOAAdmin"です。標準でこのロールは一つのメンバー（WebLogic ServerからのAdministratorsグループ）を有しています。このロールが提供する権限にはコンポジットのデプロイやEnterprise Managerでのインスタンス管理などが含まれています。ユーザーとグループだけをEnterprise Managerのアプリケーション・ロールに関連づけることができます。これはつまり、WebLogic Serverの"Admin"グローバル・ロールが明示的にユーザーに付与されますが、WebLogic Serverの"Administrators"グループもしくは明示的にEnterprise Managerで"SOAAdmin"ロールにユーザーを追加しない場合には、自動的にコンポジットのデプロイの権限が付与されません。

Enterprise Managerのsoa-infraロールにアクセスするには

1. Enterprise Manager Fusion Middleware Controlにログイン (http://host:port/em)
2. 左ペインのSOAを展開
3. 'soa-infra'を右クリック
4. ［セキュリティ］を選択し、［アプリケーション・ロール］を選択
5. テキストボックスを空白にしたまま、検索の右矢印アイコンをクリック
6. soa-infraアプリケーションのためのアプリケーション・ロールの全リストが出てくる。先頭に'SOAAdmin'がある。
7. 'SOAAdmin'を選択し、［編集...］ボタンをクリック
8. ロールメンバーを確認できる。デフォルトではWebLogic Serverの'Administrators'グループのみが含まれている。

以下のような感じになっているはずです。

2つの認可スタックの間をつなぐのは、system-jazn-data.xmlファイルで、これは<domain_home>/config/fmwconfig にあります。デフォルトでは、このファイルにはアプリケーションデプロイメントや関連するEnterprise Managerのロールのすべてに対する参照が格納されています。以下はsoa-infraのエントリを抜粋したものです。

   soa-infra
      
         
            SOAAdmin
            SOA Admin Role
            SOA application admin role, has full privilege for performing any
            operations including security related
            88293480FE7711E08F7531B0B4CEDB15
            oracle.security.jps.service.policystore.ApplicationRole
            
               
                  weblogic.security.principal.WLSGroupImpl
                  Administrators
               
         
       
   
 

ここでは、唯一のsoa-infraアプリケーションと関連づけられている最初のロール、'SOAAdmin'だけに着目します。また、WebLogicの'Administrators'グループが関連付けられていることを指定するmembers'要素も参照します。'class'エントリは、オブジェクト'Administrators'の一種であることを示しており、EMのロールにユーザーを追加した場合、Userクラスタイプを持つ追加の'member'エントリを参照します。
ご注意いただきたいのですが、クラスタ環境では、この情報をOIDを使い、データベースもしくはLDAPに永続化することを強く推奨します。設定された永続性のタイプの変更に関する詳細は以下のリンクからどうぞ。

Using the Oracle Database as a Policy Store for SOA11
http://blogs.oracle.com/soaproactive/resource/SOA_Authorization_Model/DB_as_Policy_Store.pdf.

これらは、デフォルトの認証プロバイダ（組み込みLDAP）を使っている標準の尾メインでは問題なく動作します。'Administrators'グループはすでに存在し、WebLogic Serverの'Admin'グローバル・ロールに関連付けられていて、Enterprise Managerの'SOAAdmin'アプリケーションロールに追加されています。しかし、別の認証プロバイダを使用している場合は、これらの接続を自分で設定する必要があります。一般的な例としてActive Directoryを使用した場合でより詳細にみていきましょう。

Active Directory認証プロバイダがWebLogic Serverで構成されていると仮定しましょう​​。認証プロバイダリストの最上位にあり、制御フラグは"REQUIRED"に設定されています。WebLogic Server管理コンソールでユーザーを参照できますが、誰もWebLogic Server管理コンソールやEnterprise Managerにログインすることはできません。これはWebLogic Serverのグローバル・ロールに関連付けられていないためで、関連付けるためには2方法あります。

1. ADにグループを作成し、これらのユーザーを追加して、このグループをWebLogic Server管理コンソールでWebLogic Serverの'Admin'グローバル・ロールに追加する。ADのグループを'Administrators'とした場合、すでにAdministratorsが条件に含まれているため、グローバル・ロールの条件に追加する必要はない。
2. ユーザーを個別のWebLogic Serverの'Admin'グローバル・ロールにWebLogic Server管理コンソールで追加する。

このやり方で、ADの'admin'ユーザーに対しWebLogic Server管理コンソールやEnterprise Manager Fusion Middleware Controlへのログイン権限を付与します。

それでは、こうしたユーザーがJDeveloperやEnterprise Managerからコンポジットをデプロイしようとした場合、'SOAAdmin'もしくは'SOAOperator'の権限が必要とのエラーを受け取ります。これは、Enterprise Managerのデフォルトロールもしくはカスタムのロールを通じて、ユーザーにsoa-infraアプリケーションの権限が付与されていないためです。'SOAAdmin'と'SOAOperator'はすぐに利用可能なデフォルトロールの例です。複数の方法があります。

1. Enterprise Managerの既存の'SOAAdmin'もしくは'SOAOperator'アプリケーション・ロールにADのグループを追加する。ADのグループを'Administrators'とした場合、サポートしている構成では標準で'Administrators'グループを使用しているため、エラーメッセージが現れることはない。
2. ADのユーザーを個別にSOAAdminやSOAOperatorといったEnterprise Managerのアプリケーション・ロールに追加する。

このアクションにより、2つの認可スタック間のギャップが埋まり、全範囲の期待される権限が許可されます。理解を助けるために2つの認可スタック間の関係を図示しました（下図）。
11.1.1.6より前のリリースでは、標準的な'Administrators'や'Operators'グループ（それぞれAdminロール、Operatorロール）と共に、WebLogic Serverのグローバル・ロールに関連づけられている限り、Enterprise Managerのアプリケーション・ロールにグループやユーザーを明示的に追加する必要はありません。11.1.1.6で挙動が変わっているため、その方法はおすすめしません。このエントリで記載したように、グループやユーザーを明示的にEnterprise Managerのロールに追加する必要があります。

原文はこちら。
https://blogs.oracle.com/optimizer/entry/oracle_open_world_2013_call

---

信じようと信じまいと、Oracle OpenWorldについて考え始める時期がやってきました。Oracle OpenWorld 2013のCall for papersの受付が3月13日に始まりました。

Oracle OpenWorld 2013
http://www.oracle.com/openworld/index.html

Oracleのお客様やパートナーの方々は是非Oracle OpenWorldでのプレゼンテーションの提案をお願いします。Oracle OpenWorld 2013は2013年9月22日から26日までサンフランシスコのMoscone Centerで開催されます。詳細やCall for papers提出のガイドはOracle OpenWorld Call for PapersのWebページからご覧頂けます。

Calling All Oracle OpenWorld, Java, and MySQL Experts
http://www.oracle.com/openworld/call-for-papers/information/index.html

提出締め切りは2012年4月12日午後11時59分（アメリカ太平洋夏時間）です。Optimizer、SQL Plan Management、統計情報などのみなさんのセッションをチェックするのを楽しみにしています。
これはまたOptimizerバンパーステッカーの新しいスローガンを考え始めなければならない、ということでもあります。詳細は以下のブログエントリで近日中にご紹介する予定です。

Maria Colgan (Google+)
https://plus.google.com/115225673827938473361

原文はこちら。
https://blogs.oracle.com/archbeat/entry/soa_made_simple_author_interview

---

このブログやOracle MagazineのArchitect Communityコラムの読者の方、OTN ArchBeat Podcastを聞いてらっしゃる方であれば、Lonneke DikmansとRonald van Luttikhuizenという名前をご存知かもしれません。

Oracle Magazine Architect Columns
http://www.oracle.com/technetwork/issue-archive/index-092378.html
OTN ArchBeat - syndicated content powered by FeedBurner
http://feeds2.feedburner.com/OtnArch2Arch

Vennsterでマネージングパートナーを務めるLonnekeとRonaldはOracle ACE Directorsであり、SOAおよびミドルウェアのスペシャリストとしてすばらしいスキルの持ち主ですが、時間の都合でPodcastのパネリストや記事のソースとして彼らのナレッジを貸し出すという要求を断ってきたことはありません。こうした優れたITプロフェッショナルにとってハードスケジュールであるにも関わらず、LonnekeとRonaldは執筆の時間をやりくりしてくれました。その結果、"SOA Made Simple"という書籍がPackt Publishingから2012年12月に発行されました。

SOA Made Simple (Lonneke Dikmans , Ronald van Luttikhuizen)
http://www.packtpub.com/service-oriented-architecture-made-simple/book

昨日テレビチャットでLonnekeとRonaldにこの新著に関して尋ねることができました。

第4章の抜粋版はこちら。

Chapter 4: Classification of Services
http://www.oracle.com//technetwork/articles/soa/soa-made-simple-chap-4-1918442.pdf
(サンプルを提供くださったPackt Publishingに感謝します）