本来のSOA
そろそろ本当のSOA（サービス思考アーキテクチャ）を実現するころに。
Twitterで「SOA」を検索したら、結果に米テレビドラマの「Sons of Anarchy」ばかりが表示された。以前に「SOAは死んだのか？（http://enterprisezine.jp/article/detail/1760）という記事を書いたが、そのときからSOAは流行語から姿を消すようになった。しかしSOAを本当に失敗で終わったしまったのでしょうか？
先日、Steve YeggeのGoogle+メモが流出した事件があった。その内容はGoogle+は公開しているAPIが限定され過ぎているので魅力がないっと言うことだ。（https://plus.google.com/112678702228711889851/posts/eVeouesvaVX#112678702228711889851/posts/eVeouesvaVX）。このメモで注目するのはAmazonのJeff Bezosが正しくやったことだ。今のAmazonは短時間で多くの商品を扱っている。更に新しい商品も短時間で扱えるようになっている。その理由はJeff Bezosが要求した以下の点であると思う。これがSOAである。項目4に書いてあるようにWeb Serviceを使うことは要求していない。
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
残念なことに、多くの企業はSOAはWeb ServiceやESBを使うことだと勘違いしてしまっていた。そんなことをしてもビジネスが柔軟になるはずがない。もっと言うと、ビジネスプロセスを定義しただけでも何も変わることはない。ビデオ（http://www.youtube.com/watch?v=5EPct3qikg8）の最後の質問のように、実現できなければ何も効果を得ることはできない。
先日、社内で簡単なWebシステムを作成する話があった。単純にCGIでプログラムを作成することもできるが、これではSOAではない。このシステムの資源を他システムから利用することができない。インターフェースを作成するにはまた開発工数が掛かってしまう。
正しいSOAは、エンティティをすべてサービス化することだ。多くのシステムはログインである。そのためにはApache、Tomcat、JBossのようなWebサーバを利用するよりもLiferayのようなユーザ、組織、認証がデフォルトで基盤で提供されているものを利用した方が、その部分を再開発する必要がないので、便利である。なお、それらのエンティティは内部及び外部からサービスとして利用できなければSOAにはならない。
今回のシステムはExcelからデータを読み込み、ユーザがWebブラウザからデータを処理し、結果をExcelに提供する単純のシステムであった。以下の手順で実際のこのシステムをLiferayで作成することができた：
1.Liferay－Eclipseプラグインからエンティティを定義。ユーザ、組織、認証などはデフォルトでLiferayが提供しているので、業務に必要なエンティティのみを定義した。
2.エンティティ定義からインターフェースを生成。GUIで定義したエンティティからローカル／リモートJavaコード、WSDLなどのCRUDインターフェイスを生成することができる。ここで重要なので、WSDLなどインターフェースを最初に定義するのではなく、エンティティを先ず定義して、そこからインターフェースを生成することだ。
3.追加必要なインターフェースを追加する。インターフェースの具象に他エンティティサービスなどを組み立てたインターフェースを定義する。再びサービス定義を生成して、Java InterfaceやWSDLインターフェースなにインターフェースを登録する。
4.CSV処理パターンを利用して、固有情報を定義する。
例：
CandidateInfo itemInfo = new CandidateInfo(); <- CSV項目クラス
List<String> list = null;
ICsvListReader reader = new CsvListReader(new InputStreamReader(new FileInputStream(filename),encoding), CsvPreference.EXCEL_PREFERENCE);
while ((list = reader.read()) != null){ <- CSVファイルの読み込み
itemInfo.setAdd(list); <-CSV列をエンティティモデルに設定。エンティティモデルは生成されている
Candidate createdCandidate = CandidateLocalServiceUtil.addCandidate( <-サービスの呼び出し
itemInfo.getCandidateId(),
itemInfo.getCompanyId(),
itemInfo.getGroupId(),
itemInfo.getPositionId(),
itemInfo.getBranchId(),
itemInfo.getConfidence(),
itemInfo.getNoconfidence()
);
}
5.ポートレットをwarファイルとしてアプリケーションサーバにデプロイする。
既にお分かりだと思いますが、CGIでスクラッチ開発するよりも生産性がよいです。このようにSOAは本来、既存の開発よりも生産効率をよくして、開発コストを下げる仕組みです。Web Serviceなどを導入して開発コストを高くするのは本来のSOAとは全く関係ありません。ただ従来の開発技法で開発効率を悪化させているだけです。
Liferayはすべての要素をサービス化しているため、ローカル及びリモートから処理を利用することができます。また、サービス単位に機能を置き換えることができます。サービスのインターフェースが変わらない場合は、サービスを利用している処理のコードを修正する必要はありません。
SOAを行うにはLiferayに拘る必要はありません。ただし、効率よくサービスを定義するプラットフォームが必要なことは言うまでもありません。
最後に、Liferay及びLiferay IDEは無償で入手して利用できます。