【IBM sMash】 マッシュアップはサーバでいいんですか。いいんですよ。

　先日、IBM@渋谷マークシティでsMashの話を伺う機会があった。sMashは、RESTful SOAということで、いわゆるWeb2.0的な今どきのコンテナである。sMashの主な特長は以下のとおりだ。（今回はsMashについて説明するが、私の主観がかなり入っており、IBMの戦略や意図とは異なる部分があることをご容赦願いたい。断定的な言い方にはすべて「～のような気がする」を追加して読むぐらいがちょうどよいだろう。）

* JVMで動作するGroovyとPHPをサポート
* 軽量(LightWeight)なコア
* RESTfulなSOA設計。
* サーバサイドMashup
* クライアントはDoJoだが強要するわけではない
* オープンプロセスで開発されている（オープンソースに近い)
* オープンレポジトリ　(by Ivy,Maven2）
* デュアルライセンス（大規模に利用するときに限り有償）

まず、RESTfulについて、URIの設計がリソース中心できれいに設計されている。とてもシンプルで分かりやすい。今流行りつつある、URItemplatesは提案してみたものの、意識すべきかどうか微妙だと思った。必要があればquery parameterを追加すれば十分かな。
クライアントでDoJoを強要するわけではないに同意。リソースから簡単にPDFを作成できる弊社のReflexiTextやクライアント設計モデル（JavaScript版Strutsのようなもの）と組み合わせるといいものができそうだと思った。ivy,maven2レポジトリの採用はとてもいい。
　それから目に付いたのは、JVMで動作するGroovyとPHPのサポート。そして、軽量であること。これには今のLL時代にどう対応するかというIBMの苦悩と戦略を感じる。Project ZEROといわれるように、Web開発のあり方を根本から見直すことで、重厚長大なJava文化を払拭して、スクリプト言語の高い生産性を取り入れる一方、これまで培ったJavaの資産を活用する戦略である。なかには、これまでのJava戦略を覆すとか、SCA・SDOの立場はどうなるとか、疑問・不信を感じられる方もいるかもしれないが、元IBMerである私は、これがとてもIBMらしい一貫した戦略であることが理解できた。なので、ちょっとここで説明させてもらいたい。
　IBMが十数年前から貫いているソフトウェア戦略の一つに、お客様のソフトウェア資産をマルチプラットフォームでサポートするということがある。小さなPCで始めた業務アプリがスケールアップしたときに、メインフレームほどの大きな環境を用意できるのはIBMだけだから、安心してIBMに任せなさいと。しかし、かつてのOS構想(OS/2、OS/400、OS/390)では、統一したAPIでそれを実現しようとしたがうまくいかなかった。ところがJavaはうまくいった。WebSphereとDB2により、すべてのプラットフォームで一度書いたアプリが動くようになった。
　お客様資産の活用とは、お客様自身のデータおよび既存アプリケーションの活用である。それをサクサクとインターネットなどへ適用できれば大きな価値を生み出せる。実際にY社の荷物追跡システムはそうだった。今でこそ一般的に使われているが、当時はお客様自身、その価値に気づいていなかった。これは、お客様資産の活用が困難で、時間やコストがかかっていたなら実現できなかっただろうと思える。
　そこで、さらに一歩すすんだことを考える。マルチプラットフォームでサポートすることがお客様へのコミットメントであるなら何もJavaにこだわる必要はないわけだ。要は、JVMを活用しながら他の言語でもサポートできるようにすることが、お客様資産を活用することにもなる。Javaが敬遠される理由には、納期が長い、融通がきかない（仕様に準拠しないと怒られる）、開発費が高いなどがあるが、LLで解決できるなら、それでよいのではないだろうか。

　また、GroovyとPHPが必要な理由と、サーバサイドWebアプリの否定ではないことを付け加えたい。ブラウザから直接サービスを実行するスタイルが主流になることは認めるが、この記事の後半でも触れているように、XMLを仲介する変換サービスや、ちょっとしたHTMLをサーバサイドで行う必要がどうしてもでてくる。このちょっとしたコーディングはスクリプト言語が最も得意とするところである。

　それから、sMashで最も重要だと思う点は、サーバサイドMashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの３つに依存した密結合開発であったものを、RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。分業のメリットがいかに大きいかは、この記事で説明したとおりである。
　また、Controlに位置するものは、今どきの言葉でMashupといったが、これには違和感を覚える方もいると思う。私は、Mashupをただの変換・編集とするのは間違いだと考えている。ビジネスロジックを含み、また、マッシュアップしたコンポーネントがさらにリソースと同等になるとさらによい。データ更新にはトランザクション管理を伴い難しいので、現在はまだ変換・編集が多いのも事実だが、今後はビジネスロジック中心に組み込まれていくのは明らかである。私は、Mashupが単なる変換・編集からビジネスロジックを含むControlに役割が変わったときに、本当の意味でオブジェクト指向設計の次の段階に進むことができると信じている。
　これまでにも、ワークフロー設計は、ESBやワークフロー製品で採用されてはきたが、往々にして重厚長大になり、コスト面で引き合わなかった。このような統一したアーキテクチャーのもとではどうしても重厚長大になってしまう。それがRESTful SOAにより疎結合開発が可能になろうとしている。これには統一したアーキテクチャーはいらない。リソースの設計において、コンベンション（規約）を重んじることでインターオペラビリティ向上が図れるからだ。リソースを積み木のように組み合わせて開発する。本当にそれが実現できれば、RESTful SOAは、進化ではなく革命に近いものになるだろう。
　
　最後に当面の課題について触れたい。
　まず、Webアプリ開発者にとっては、どうやってシステムを設計、実装していけばよいか、イメージが伝わりにくい。先に述べたように、Webアプリではそもそもワークフロー的に作る文化がなく、サービス志向、REST志向で作る文化もない。SOAPは古くからあるが少数だ。また、更新系の設計をどうするかも課題だ。コンポーネント間の2phaseコミットは大変かもしれないが、トランザクションスクリプトでシンプルな設計にすべきだと思う。とにかくシンプルにして多くの開発者に支持されないと、SCA、SDO、ESBといったManagedなアーキテクチャスタイルで陥ったように、シュリンクを経験するはめになる。

　Project ZEROは、Incubator Project（将来的に有効に活用できそうな新しいアイディアや技術を模索するプロジェクト）の一つで、Don Fergusonの発案らしい。
Managedなアーキテクチャスタイルに背を向け、IBMを全速力で飛び出してRESTを志向した私であるが、そこで書いた絵はsMashと瓜二つ。お釈迦様（Ferguson）の指に書いた孫悟空、といったところかな。

＜追記＞
こちらに提案を書きました。
ReflexとsMashによるソリューションの提案

【雑記】 くだらない妄想

ジョブズ氏引退後のアップルを考える

ジョブスのいないアップルは、たかた社長のいないジャパネットを想像すればよい。

ジャパネットたかたは日本のスティーブ・ジョブズか？

【本日の嵌り】 いざというときのMySQL関数

売上データ送信プログラムが動かない。原因は仕様漏れ。商品以外の送料やポイントを先方指定のJANに変換すべし、ということをついさっき言われた。先方の「お勝手JAN」に変換してあげないとエラーを起こすそうだ。本日から運用開始なのに、そんな大事なこと、もっとはやく言おうよ～。＞＜；

でも、こんなときに頼りになるのがMySQL。ロジックを修正するんじゃなくてSQLに関数を追加すればよい。

select
case when item_code = '送料' then '0000000000001' when ・・・ else jan_code end as jan_code
from table

これで解決。

【雑記】 iPhoneサービス価格発表！おもてなしで勝負あり？

本当に微妙なところを突いてくるなあ。うーん。
iPhone 3G向けサービスの詳細について

【EC開発体験記-Entity-】 自己完結したデータの集合

　Entityの設計はシステム設計の肝である。だが、構造をどうするかとか、外部参照や冗長をなくすとか、考えだすときりがないし、とにかく時間と労力がかかる。通常は、RDBのERモデル、オブジェクト志向のドメインモデルなどに則って設計することが多い。それぞれ設計ツールも豊富なので利用価値はある。しかし、概念や設計ツールの学習コスト、リレーショナルとオブジェクトの変換コスト、インピーダンスミスマッチは馬鹿にできない。そこで、ここは敢えて頭を空っぽにして、Entityの最低限必要な情報、すなわち、項目および属性とその構造だけに着目して、それらを洗い出すことから始めるとよい。とにかく、最初から難しく考えないで設計を進めていき、問題があればあとで修正する方法をとる。おすすめは、マインドマップの作成だ。（参考：テキストをマインドマップに変換するツール）　
　次に、自己完結した情報となるように項目を括る。とにかく外部参照のないものにするのがコツだ。例えば、カタログ巻末にあるFAX注文書は、受注に必要な情報がすべて記載されており、それだけで自己完結した情報となっている。システム化する際には、１枚の注文書が１インスタンスとなるように、さらには、1インスタンスが1レコードとなるように設計する。こうすれば、Entity＝Tableというイメージとなって都合がいい。そのことを、否定の２として挙げた。

否定の２
２．テーブルは第3正規形まで設計しない

　ここは正規化したい気持ちをぐっとこらえるのがポイントだ。また、Entityの階層を２階層とする一方、Tableの項目名をEntityと同一とする。このような規約で縛ることを、設定よりも規約（Convention over Configuration，CoC）という。こうすると、自由度は下がるが生産性は高まる。また、学習コストは少なく、インピーダンスミスマッチを解決できる。もしかしたら、「こんな設計ありえないだろ！」と正論をかざす頑固なRDBスペシャリストが出てくるかもしれないがスルーでよい。そもそも、設計にエネルギーと時間を使わないための規約なのだから、やらなくてもいい議論はやらない方がいい。ここは議論したい気持ちをぐっとこらえるのがポイントだ。

　話は戻り、ここで実際に、ECにおける「受注」について考えてみる。「受注」とは、「誰が何を注文して、いつどこに届けるか」という情報である。これを思いつくままに書くと、以下のようになる。

受注
　受注日時
　注文主
　　氏名
　　住所
　　電話番号
　　email
　　カード番号
　届け先
　　氏名
　　住所
　商品
　　JAN
　　売価
　お届け日時
　配送方法
　決済方法
　ステータス

以上が、とりあえずのEntity設計であるが、見ての通り、突っ込みどころ満載である。
まず、2階層といったくせに3階層になっている。（受注＞注文主＞氏名）このままではいかんので、規約に則って2階層に修正しなければならない（受注＞注文主氏名）
　それから、何気なく列挙している「ステータス」がある一方で、普通あるはずの「受注番号」などのキーがない。意味不明なものがあって、あるべきものがない、という中途半端なものになっている。また、１受注に複数の商品を購入される方もいるはずで、なんらかの「受注番号」で括る必要がある。さらに商品レコードを示すキーも必要になる。（商品レコードは一品一葉という概念で管理されている。これについては別の機会に説明したい）

　次にステータスを説明する。データが妥当（Valid）かどうかはステータスにより管理する。「ステータス」は、簡単にいうと、「受付られた」、「出荷された」等、データがどういう意味をもっているかということを示すためにある。いわゆる「判（ハンコ）」と同じものだ。
　まず、データがValidであれば、判を押された文書のように、それだけで意味を持つようになる。例えば、「ステータス＝受付」で、その商品が在庫にあり、指定した日に届けられる予定であることを意味し、「ステータス＝出荷」で、商品が出荷され、売上が計上されたことを意味する。

　また、判を押すためには、データの妥当（Valid）を判断するビジネスロジックが別途用意されなければならない。受注を受け付けるための条件は次の通りである。

１）注文主は実在するか
２）商品は存在するか
３）カードの与信はOKか
４）お届け日に配送できるか

　これらビジネスロジックは、サービスとして実装できるものばかりである。Entityを入力値としてサービスを実行し、データが妥当であればステータスを更新すればよい。これは、リソース志向に則った設計でもある。

　ビジネスロジックに関連して、プロジェクトでどうしてもやりたかったことで、否定の１、および１０がある。最後に、これについて説明したい。

１．受注番号等のキーを採番しない
１０．Web受注はブラウザからのプロバイダ通信だけで完結させる

　採番はシステムのあらゆる面でネックになるので、何とか頑張って無くしたかった。そのかわり、「誰がいつ注文したか」を示す、メアド＋受注日時(takezaki@mail.com-20081012010203012)をキーとした。そして、プロジェクトの第一フェーズまでは実際にこれで運用した。

しかし、これはやはり無謀であった。・・・動くものはなんとか作れたが、データ操作が非常に面倒くさくて、とても運用できるものではなかった。大反省（ ＞＜；した末、今では受注番号はキーとして必須であるという結論に至っている。
　採番はシステムのあらゆる面でネックになるといったが、特に心配だったのはスケーラビリティへの影響である。これは採番プロバイダとしてサービス化することでなんとか解決できたと思う。現在の採番プロバイダは受注番号以外にも配送伝票番号や生産番号などのキーを複数発行している。
　また、プロバイダ通信だけで完結させるという案１０は、採番プロバイダの例のように作ることで有効であるように思えた。実際にECシステムでは、商品マスタや受注機能のプロバイダ化ができており、AJAX（JavaScriptによるプロバイダ通信）を駆使すれば、ブラウザとプロバイダだけでECサイトが作れると思った。しかし、セキュリティとSEOの２つの理由で断念せざるを得なかった。まず、カードオーソリのために外部サービスを呼ぶ必要があり、これをクライアントのJavaScriptだけで実行することは不可能であったこと。それから、SEOにおいては、HTMLを出力できることが重要で、どうしても中間にXMLからHTMLを生成させるPHPを介在させる必要があった。
　このように、あまり面白くない結果になってしまったこのECサイトであるが、実はPHPから商品プロバイダや受注プロバイダを呼んでいるし、カート（Flex2）からも同様にプロバイダを呼んでいる。にもかかわらず、外部から見ると普通にDBを検索しているように見えてしまう。まあ、サービス志向でWeb2.0サイトであることを醸し出せないのはちょっと残念ではあるが、それなりに意味のある設計だとは思っている。
これからも無謀と思わずいろいろトライしていきたい。

【雑記】 Firefox3 圧倒的なパフォーマンスで勝負あり

この記事は信じがたいものだったが実際に入れてみたら嘘ではないことがわかった。ひゃ、はやっ！
“史上最速”のFirefox 3が登場へ、「IE7の9.3倍速い」
クライアントプラットフォームの安定化、高速化により、今後はJavaScriptの活用がさらに進むだろう。それを見越しているのか、すべての自社製品をSaaS化しようとしているAdobeもまたすごい。まあ、Adobeに関していえば、Flashを取り込んだ時点で方向性は決まっていたのかもしれないが、アプリがネットワークに依存することのリスクも覚悟しなければならないわけで、大きな決断だったとは思う。また、デスクトップインストール型に比べ、SaaSだと機能に多くの制約が出てくる。Photoshopなどは到底、SaaSにできないだろうとは思っていた。いずれにせよ、ブラウザだけで実現するネットワークコンピュータがより、現実的になった日であることは間違いない。Adobe AIR

【本日の嵌り】 SSHポートフォワードでMySQLにアクセスする

MySQLサーバポート(3306)に直接アクセスできない場合、sshでログインしてポートフォワードするとよい。

「Linuxがクライアントの場合」
ssh -N -f -L 3306:192.168.1.1:3306 work@192.168.1.1

「Windowsがクライアントの場合」
puttyでトンネル＝＞源ポート8081、送り先localhost:8081で追加する
L8081 localhost:8081

これで解決。

【おしらせ】 暮らしのデザイン取締役を退任しました

本日付けで、暮らしのデザイン取締役を任期満了により退任致しました。
プレスでも発表しておりますが、暮らしのデザインは、エディオンからニッセンホールディングスに移ります。暮らしのデザインのサービスは継続しますので、今後も引続きご愛顧賜りますよう、宜しくお願い申し上げます。

【本日の嵌り】 Tomcat common/lib/xxx.jarの内部ファイルを読みこむ

Tomcatのcommmon/lib配下にあるJarファイルの内部のリソースを読めるようにしたい。
それには、Jarファイルの場所を含むurl(以下jarurl）を作成する必要がある。
jarurlは、「jar:file:/C:/･･/common/lib/xxx.jar!/jp/reflexworks/sample.xml」という感じで、!の前がJarファイル名、後がパッケージ名となる。「.」は「/」に置き換わる。
これさえ作れれば、あとはnew URL(jarurl).openStream();とやれば読み込める。

Jarファイルの場所付きurlを作成するには、以下のように、log4jのLoader.getResource()を使うと便利。

URL url = Loader.getResource("jp/reflexworks/sample.xml");
String jarurl = "jar:file:/"+url.getFile().substring(5);

これで解決。

＜追記＞
以下のfile://のように、2回//があると読めなくなるので、ちょっと修正。

jar:file://C:/･･/common/lib/xxx.jar!/jp/reflexworks/sample.xml

URL url = Loader.getResource("jp/reflexworks/sample.xml");
String jarurl = "jar:"+url.getFile();

【雑記】 ソフトバンクがiPhoneを獲得した理由

これは分かりやすい　↓

、iPhone 3GでYahooにアクセスし、Yahoo!オークションやYahoo!ショッピングを利用してもらえれば結果として収益は上がる。すなわちiPhoneを携帯電話ではなくインターネット端末だと考えれば、ソフトバンクにとっては十分魅力的な製品である。これはインターネット全体でビジネスをしている同社の大きな強みだ。

ソフトバンクとiPhoneが日本の携帯を変える--ソフトバンクのiPhone獲得を考える

なるほど・・・。よく考えてみたら、ソフトバンクモバイルは携帯キャリアのひとつではあるが、ソフトバンク本体は通信サービスが本業ではないのだ。全社的な取り組みとしては、通信サービス、すなわち、電波や通信回線の利用料を徴収するビジネスモデルに拘らず、より付加価値の高いインターネットビジネスに誘導する。こんなことは、到底、Docomoには真似できないだろう。

しかし、本業のインターネットビジネスといっても、Yahooぐらいしか思いつかない。ソフトバンクオリジナルは何もないわけで・・・、昔からそうなんだけど、なんとなく気持ち悪い。

【本日の嵌り】 Google先生にエラーコードで聞く

ちょっと恥ずかしいが毎度のごとく嵌るネタをメモしていくことにする。
Googleにエラーコードそのものを入れて検索するとズバリ回答が出てくる。これは便利だ。

嵌り１）昨日、久しぶりにTomcat＋Eclipse環境を使ったのだが、Tomcatプラグインがちゃんと動かない。

java.lang.ClassNotFoundException: org.apache.catalina.loader.DevLoader

と出ているので、Google先生に「org.apache.catalina.loader.DevLoader」と入れて聞いてみた。そしたら、件名：EclipseでTomcatが動かない!!が見つかって、

プロジェクトのプロパティでTomcatを選択すると、
開発用クラスローダの設定がありますが、
「使用する」にチェックされていませんかね？
チェックされていたら、チェックを外してみてください。

それで無事Tomcatは動くようになったが、今度はアプリケーションが見つからないようだ。
maven2の環境だったので、server.xmlのContext docBaseに以下を追加

docBase="・・・・\src\main\webapp"

これで解決

嵌り２）Maven2でデプロイしようとしたら 「\65279 は不正な文字です」と出る。
エディタで見ても先頭には何も文字らしきものは入っていない。そこで、Google先生にコピペして聞いてみたら、\65279 は不正な文字です。が出てきた。
サクラエディタで開いても見れないが、ファイル－＞名前を付けて保存　とすると右下にＢＯＭがチェックされているので、これを外すとうまくいった。

これで解決

【雑記】 iPhoneは売れる？

この２つの記事を読んで売れるか売れないか考えてみた。

iPhoneがなぜそれほどまでに「革命的」なのか
iPhoneは売れない

見事なほど対照的な意見だ。

最近のAppleはたしかにすごい。何年か前に、MSから資本が入ったときは、「生かさず殺さず」などといわれたAppleが、よくもここまで盛り返したものだと思う。ソフトウェア以外にコアテクノロジーがないにもかかわらず、何かすごいものをもっているように感じさせるのはなぜだろう。「おもてなし」とか、後付けの理由はいろいろあるようだが、私の理由は、MSとSONYの自滅だ。その結果、相対的にブランド力が向上しただけじゃなかろうか。「おもてなし」と言い切ってしまうと、私のような鈍いものにとって説明が難しいと思う。（私はiPod nanoの掘り込み印字に気がつかないし、スタバに入ってもドトールと区別がつかない）

　かつてのソニーは技術力によりブランドイメージが作られた。トリニトロンとか、ウォークマンとか、ソニーの独自の技術力は、他社に追随を許さないように思えた。当時はCMもすばらしかったので購買意欲は増幅される。そして、その商品を手に入れたユーザの満足感は非常に満たされた。これがすなわち「おもてなし」。このような好循環になれば多少高くても買ってくれる。ブランド力が向上した結果、安いネタで高く売るというビジネスモデルを確立できる。

　また、MSはWin95,Win2000に尽きる。まるで一人の人間が作ったかのような、統一された出来栄えには非常に驚かされた。一方のOS2は、人が寄ってたかって作ったんだろうなという感じを受けた。OS2には操作に統一感がないので、使うときに「あれ？どうやるんだっけ？」と迷うことがよくあって、私はすぐ忘れるのでメモに残すことをしていた。一方のWin95は、たぶんこうやればできると直感的にすぐわかった。メモはもちろん必要ない。当時の北城社長は95を「ゲームのような、おもちゃOS」と酷評していたが、実は「おもてなしOS」だったというオチ。MSのすごいところは、たぶんこうやればできるという直感的な操作感を、Officeや、さらにはSQLServerにも継承させていること。MSのソフトであれば、いちいち操作を覚える必要はないと想像できた。これもブランド力ではなかろうか。
　（カミングアウト）まだ新人であった私は、非力なPCしか与えられなかったことを理由に95を社内で堂々と使っていた。（北城さんが何ていおうと、「だって僕のマシンではOS2動きませんから」と言い訳して、内心ニヤリ）同期で95ばかり使っていた社員は、たぶん私だけだったろうし、最もOS2が分からない自信があった。それから社内の冷たい視線に絶えること数年、OS2は使われなくなった。

最近は、SONY、MSに陰りが出てきた。一方、追いついたAppleが成長した。Macは私もたしかに欲しいが、その一番の理由はVistaを使いたくないから。現時点で最高なOSはもちろんWin2000。軽くて早くて使いやすい。たぶん、Macに乗り換えるのは時間の問題だろうが、ThinkPad X21のキーボードに慣れた私が乗り換えたときに苦労するのは明らかなのでまだ買っていない。なので、私はいまだにIBM社販で買ったThinkPad X21を愛用している。（2000年に社販購入して償却したところで退社した。）

話は戻る。
iPhone VS ワンセグお財布携帯、どっちが勝つのだろう？

今回の勝負は、「技術力＝ワンセグお財布」　VS　「おもてなし＝ブランド＋使いやすさ」だ。

でも、こんなふうに考えるとぜんぜん面白くないなあ。

私の予想はズバリ、今年に限って言えば、話題性はあるが大ヒット商品にはならない。少なくとも、今年年末のヒット商品の横綱にはならないだろう。でも。iPhoneの背景にある「革命的」なことを考えると、通信業界にとって「大インパクト商品」なんだろうなという気はする。「革命」の流れは止められないと思うので長期的に見るとiPhoneの勝ちだろう。通信業界の変な構造は変革させたい。ガラパゴス化がすすんでいる日本の技術。それを駆逐する「革命的」な技術という意味で、DOS/VがPC98を駆逐していった状況に似ていると思う。

iPhoneの背景にある「革命的」なことについては、こちらの本を参照してほしい。



最後に、電池の寿命は重要。W-ZERO3は電池がすぐ切れるから痛かった。

iPhone とおサイフケータイ

【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト

以前、Modelとはモデリングの成果物であるという説明をした。分かりにくかったかもしれないが、これは要するに「オブジェクト」であり、データおよび、それを操作するメソッドを含んだ「もの」ということだ。オブジェクト志向で何が嬉しいかというと、詳しくは、WEB+DB vol44を見ていただきたいが、一言でいうなら、

オブジェクト志向では、「もの」によって「できること（機能）」が連想できるのです。
　　　　　　　　　　　　　　　　　　　　　　　- WEB+DB vol44 p76 豆蔵 萩本氏 -

普通に作るとModel=Entity+Blogic(業務ロジック)となる。「もの」が持つデータはEntity、「できること（機能）」がBlogicである。これはこれで問題ないように思えるのだが、実際にBlogicを実装していくと多くの問題に突き当たる。その原因の一つが、自分以外のモデルを参照する外部参照である。外部のModelは参照するけれども、主な責務は自分にあるので内部にメソッドを定義している、といったケースはよくある。しかし、そのメソッドが返す値は自分自身のEntityとは関係なかったりする。こうなってくると何でもアリになってくる。そして、「Entity重要」から「Blogic重要」になり、しまいには「あれ？Modelって何だっけ？」という話になる。これではモデリングの意味がないし「Entity重要」を強調するためにも、一旦、Blogicのことは忘れてEntityだけを設計することに注力すべきである。これがオブジェクト設計といえないことは前述したとおりである。なお、Blogicの解決策については、後半部分で触れる（太字で記す）

ここで、「Entity重要」の設計について整理してみたい。

１．分析クラスのEntityをもとにデータの構造体を実装する(entity0)
２．entity0のCRUDを実装する

問題は外部参照だ。Entityは他のEntityとコミュニケートできないとされるので、うかつに関係線を引くとモデラーの先生に叱られることになる。であるなら、関係のない新たなEntityを作成すればよい。（ただし外部参照のEntityへは内包線が引かれることになるので注意する）



Entityを内包するためにControlを使う。

Controlの定義

１．CRUDメソッドの実装部分を受け持つ
２．Blogicや外部参照のEntityを複数呼べる
３．トランザクションを管理する(1UOW)
４．Model内からのみ使用できるメソッドである(private) (修正：2008/09/30)

具体的には、次のような、controlXを追加する形になる。

１．分析クラスのEntityをもとにデータの構造体を実装する(entityX)
２．外部のEntity(entity0,entity1)を参照して内部のEntity(entityX)にマッピングする(controlX)
３．entityXのCRUDを実装する
（省略）

サンプル

　// Entityクラス
　public class EntityX extends ControlX{

　　public String item0; // 要素０
　　public String item1; // 要素１

　}

　// Controlクラス
　public class ControlX {

　　　　private Blogic blogic = new Blogic(); // Blogicクラス(業務ロジック)
　　　　public EntityX retrieve(EntityX entityX) {

　　　　　　　　Entity0 entity0 = (new Entity0()).retrieve(entityX.item0);
　　　　　　　　Entity1 entity1 = (new Entity1()).retrieve(entityX.item1);

　　　　　　　　entityX = blogic.convert(entity0,entity1); // マッピング

　　　　　　　　return entityX;
　　　　}

　　　　public EntityX create(EntityX entityX) {
　　　　　　　・・・
　　　　}

　　　　public EntityX update(EntityX entityX) {
　　　　　　　・・・
　　　　}

　　　　public EntityX delete(EntityX entityX) {
　　　　　　　・・・
　　　　}
　}

また、例のように、外部参照のEntityは複数あっても構わないが、内部EntityのCRUDは1UOWとする必要がある。すなわち、複数の外部参照のEntityをトランザクションで括る必要がある。（この実装はちょっと難しい。内部APIのような密結合であれば、実質的にはSQLになるのでDBMSのトランザクション管理を利用すればよいが、サービスのような疎結合では2phase commitなどを考慮しないとうまく管理できない。いずれにしても、この実装では、ロングトランザクションではなく、Atomicなトランザクション管理が要求されることになる。）

また、convertというBlogicが登場している。これはentity0,1からentityXにマッピングするメソッドであり、entityXのModelに属するものだ。さらにいえば、controlXもentityXのModelに属する。Entityの中にControlが入ることになるが、これも内包として考える。（内包は再帰的に考える）
　そして、convertに限らず、BlogicはすべてEntityを入れてEntityを返すとしてよさそうである。ただし、BlogicにI/Oを持たせてしまうと外部参照となってしまうため基本的にNGである。ResourceへのアクセスはEntityのCRUDメソッドだけが許されるものとし、さらにBlogicからはそれを呼ぶこともできないとする。EntityのCRUDメソッドを呼べるのはControlからだけだ。
Blogicで可能なことは、Entityを元に計算や変換処理を行って、Entityに詰めなおして返すだけ。なんとも制約の多いものだが、これがカプセル化として働くため、非常に安定したシステムとなる。（後ほど説明するがテストも楽になる）
したがって、Blogicの定義は次のようにする。

１．entity = blogic(entity)
２．Blogicは揮発性である(ステートレスでありデータを保持しない。また、外部リソースへのI/Oはない）
３．Model内からのみ使用できるメソッドである(private) (修正：2008/09/30)

このように、「Entity重要」の設計を行っていくと、自然とBlogicが整理されてくる。
Blogicが追加されて最終的に出来上がったものがModelである。そして、そのModelがさらに他の参照元になりえるという再帰的なModelとなる。（Groovyコンファレンスデモの実装の例を記事に書いているので参考にしていただきたい。＝＞リソースの実装）

Controlは、Modelの中に内包されてEntityとしても振舞う。考え方としてMashupに近い。


以上が私の考える「Entity重要」のリソース志向設計である。
独自色が強いのでおすすめはあまりできないが、何か設計の参考になれば幸いである。

【EC開発体験記 -スキーマ開発-】 誂えスキーマを開発してはいけない理由

サービスのAPIを開発しない理由にもつながる話。

自身、TravalXMLとか、いくつかの誂えスキーマに携わったことがあるにもかかわらず、否定するのは筋が通らないかもしれないが、無駄なものは無駄である。まず、以下を読んでいただきたい。

お仕着せスキーマと誂えスキーマ

そして、Tim BrayのBigFiveは、それを強調した話となる。
Tim Bray 「もうXML言語を開発するな」 と、それに対するUche Ogbujiの反応

これらを読むと、XMLではないが、APIを（標準化を見据えて）開発することは無駄なことのように思えてくる。

では何が「お仕着せ」で何が「誂え」なのか。
産業界で普及しているという尺度には議論の余地があるものの重要な判断材料だとは思う。しかし、AtomPubといえども「お仕着せ」に見えて、結果的に不発で終わるかもしれない。
こうなってくると余計、分からなくなってくる。

一方、WikiPediaのタグ化に見られるような語彙は、地味ではあるが、着実に浸透すると思われる。
FavikiとタグとDBpedia

結論は、ユーザが開発するスキーマは野良で、それから、できればWikiPediaのタグを使おうということでＯＫ？