tag:blogs.iona.com,2008:/essence//5 2008-02-21T04:18:33Z Movable Type 3.31 tag:blogs.iona.com,2008:/essence//5.558 2008-02-21T02:41:06Z 2008-02-21T04:18:33Z

日本のITユーザには「みんなオープンソースを使っていますよ」と言って促すことだということです。日本のITユーザは「みんなで渡れば怖くない」という前提があるように思います。

Kiyoshi Egawa http://blogs.iona.com/essence/ JUASというITのユーザ団体があって、よくセミナーのお知らせをいただくのですが、結構、費用がかかるので、参加したことはなったです。今回、3,000円と手頃だったので、OSS（オープンソース）の適用の阻害要因についてのお話を聞いてきました。 モチベーションとしては、我々もクローズソースのESBとオープンソースのESBの両方を影響するハイブリッドな戦略をとっているからですが、日本の事情はUSとも違うという考えを持っていたからです。ITの環境で日本とUSの違いはオープンソースに限ったことではないですが、昔からUSから18ヶ月遅れて日本は新技術が適用されるなどという通説もあります。 でも、話はそれほど単純ではないと思います。このセミナーに結論があるとしたら日本のITユーザには「みんなオープンソースを使っていますよ」と言って促すことだということです。日本のITユーザは「みんなで渡れば怖くない」という前提があるように思います。プロダクトアウトを前提にしている我々からするととても大きな壁です。最初の話から日本ので事例を聞きたがりますから。 USでも同じような傾向がありますが、日本ほど画一的ではないように思います。平成19年情報通信に関する現状報告　特集「ユビキタスエコノミーの進展とグローバル展開」の6ページや30ページに日本とUSの成長や投資の違いが表されています。やはり、なんらか先行するべきという気持ちがこの違いに現れているように思うの私だけではないと思います。 なんだか批判めいたことになってしまいましたが、我々ベンダーとしての責任はもちろんありますし、実際のビジネスとして生き残るためには、避けることはできない問題です。]]> tag:blogs.iona.com,2007:/essence//5.541 2007-10-16T03:33:31Z 2007-10-18T01:41:40Z

ガートナが発表した「戦略的テクノロジー」のトップに「グリーンIT」が挙げられました。テクノロジーが引き起こした地球温暖化問題をテクノロジーで制するという共通の意識が育ちつつあるのでしょうか。地球温暖化問題が地球上に紛争や格差を生じさせることは必至であり、政治やビジネスに大きな影響を及ぼすのでテクノロジーだけの問題ではないのですが、テクノロジーが貢献できる程度は非常に大きいと思います。

Kiyoshi Egawa http://blogs.iona.com/essence/ ガートナが発表した「戦略的テクノロジー」のトップに「グリーンIT」が挙げられました。テクノロジーが引き起こした地球温暖化問題をテクノロジーで制するという共通の意識が育ちつつあるのでしょうか。地球温暖化問題が地球上に紛争や格差を生じさせることは必至であり、政治やビジネスに大きな影響を及ぼすのでテクノロジーだけの問題ではないのですが、テクノロジーが貢献できる程度は非常に大きいと思います。 ITも同様に、以前のエントリで紹介したようなコンピュータのハードウェアの消費電力のセーブのテクノロジーだけでなく、ITテクノロジーが二酸化炭素の排出を制御するシステムを実現することでも貢献できます。エンタプライズだけでなく組み込みソフトの中には関連するシステムが少なからず開発されていくはずです。 これらのシステムは当然ソフトウェアで作られているわけですが、ソフトウェア自身の有り様も貢献することが必要でしょう。ハードウェアが急減な進歩を遂げたおかげソフトウェアも様々な創意工夫を実現できたのですが、CPUもメモリもジャバジャバ使えるということで進んできたシステム開発のイノベーションへの対応の仕方を変えなければならないと思います。それが今すぐ起きるのかどうかはわかりませんが、無駄なリソースを必要以上に消費することには変わりはないからです。 経済原理から言えば、そんな細かいことは気にしないで早く安く作ることが求められるのでしょうが、この地球規模の危機は、そのような概念を覆す必要があります。当然、科学的に証明された方法をとる必要があるわけで、具体的な方策がどうなるかはわかりませんが、同じことを実現するのに最小限のリソースで実現することが求められるということになるはずです。 マイクロソフトとインテルが、少しでもソフトウェアが消費するリソースを最適化できれば世界中にあるＰＣが貢献する度合いは大きいはずです。その他にも、一律JVMのオーバヘッドが消費するリソースを削減できれば結果は評価できるものになるでしょう。 ]]> 関連する記事が日経BPに出ていました。]]> tag:blogs.iona.com,2007:/essence//5.533 2007-10-01T05:10:46Z 2007-10-01T05:32:10Z

GoogleとIntelがデスクトップコンピュータの消費電力の浪費から生じる温暖化問題に対応する非営利団体を立ち上げています。

Kiyoshi Egawa http://blogs.iona.com/essence/ 非営利団体を立ち上げています。デスクトップのコンピュータの30％から40％の電力が浪費されているそうです。コンピュータの電力消費の調整機能は90％が無効にしていると言われています。 CPUのクロックも頭打ちであり、IT技術は新たな課題を背負わなければならなくなっていると思います。温暖化問題など地球上のあらゆる物事を正しく維持するための方法を考えることをSustainable Developmentといいます。非常に大きな課題であり、解決に近づけるためにはITの力が不可欠です。 そのIT自身もその技術の限界を試されていると思いますが、いかがでしょうか。]]> tag:blogs.iona.com,2007:/essence//5.532 2007-09-30T01:22:33Z 2007-09-30T02:15:02Z

2007年9月25日付けでアイオナのオープンソースSOAスイートのFUSEの新しいリリースが発表されました。

Kiyoshi Egawa http://blogs.iona.com/essence/ FUSEの新しいリリースが発表されました。FUSEの元になっているApache Software FoundationのServiceMixプロジェクトがインキュベータから30余りのトッププロジェクトのひとつに昇格したことをお知らせしました。その中でご説明したようにアイオナはLogicBlazeを買収して、アイオナのオープンソースESBのCeltixが、LogicBlazeのFUSE製品群と統合されました。 今回のリリースの目的は、このCeltix系のESBとFUSEのスウイートをより強固に統合することです。]]> tag:blogs.iona.com,2007:/essence//5.530 2007-09-21T02:52:57Z 2007-09-21T03:24:56Z

アイオナのオープンソース製品の中核になるFUSE ESBのプロジェクトであるApache Software FoundationのServiceMixがインキュベータからトップ・レベルのプロジェクトに昇格しました。

Kiyoshi Egawa http://blogs.iona.com/essence/ アイオナのオープンソース製品の中核になるFUSE ESBのプロジェクトであるApache Software FoundationのServiceMixがインキュベータからトップ・レベルのプロジェクトに昇格しました。 アイオナのオープンソース戦略はヨーロッパのコミュニティのObjectWebのCeltixプロジェクトから始まりました。その後、CeltixはApache Software Foundationへ移行するとともにXfireプロジェクトと統合し、Apache Software FoundationのCXFプロジェクトとなっています。 さらに、2007年4月にServiceMixやActiveMQを提供していたLogicBlazeを買収し、新たなFUSE製品群を発表することでオープンソース戦略をアップデートしています。 ServiceMixのトップ・レベル・プロジェクトへの昇格についてはアイオナのプリンシパル・エンジニアのGuillaume Nodet のブログをご参照ください。]]> tag:blogs.iona.com,2007:/essence//5.527 2007-09-16T14:21:23Z 2007-09-21T02:48:41Z

COE（Center Of Excellence）はインド系のインテグレータなどで聞く部門の名前です。各社が出しているソフトウェア製品のノウハウを集めた部門で数千人の要員がいる場合は多いです。場所はインドのバンガロールであったりますが、グローバルな製品であればあらゆる製品に対応できる可能性を持っています。実際にはポリティカルな関係から製品を選択することもあるかと思いますが、彼らの強みは、COEを背景として、ユーザにソフトウェアベンダーの製品から独立していることを納得させられることです。

Kiyoshi Egawa http://blogs.iona.com/essence/ COE（Center Of Excellence）はインド系のインテグレータなどで聞く部門の名前です。各社が出しているソフトウェア製品のノウハウを集めた部門で数千人の要員がいる場合は多いです。場所はインドのバンガロールであったりますが、グローバルな製品であればあらゆる製品に対応できる可能性を持っています。実際にはポリティカルな関係から製品を選択することもあるかと思いますが、彼らの強みは、COEを背景として、ユーザにソフトウェアベンダーの製品から独立していることを納得させられることです。 日本のインテグレータは数千人におよぶ製品担当者を擁することはできません。ある製品のスキルを身につけるために若い担当者を割り当てたとしても、その担当者のコストと本来あるべき売り上げは付いて回るわけで、担当する製品の売り上げでそれらを達成しなければなりません。そのために、インド系のインテグレータのように何でも製品に対応できるということにはなりません。 ユーザによってはCOEをもつようなインテグレータに製品選択のコンサルティングを依頼することがあるようです。純粋に製品を比較検討するというモチベーションから出てくる依頼であると思いますが、実際の製品選択は製品そのものの比較だけで決められるわけではなく、SIerを選択して、SIerが扱う製品をそのまま導入してしまうというのが、傾向として目立つのではないかと思います。 資本主義の行く末として仕方がないかと思いますが、各業界では大規模は統合が行われています。ソフトウェア、特に、ミドルウェアを提供するベンダーの数も大幅に減っており、製品の選択の意味自体が変わってきてしまうのではないかと危惧します。 イノベーションは、結果として「小」が「大」を食うことで象徴的に扱われてきましたが、今は、「小」が「大」を食う前に「巨大」に食われてしまうことが当たり前になりました。このことが、イノベーションを生むために良い方向になるのか、あるいは、そうではないのか、意見は分かれると思いますが、本質的には豊かな社会は多様な社会であるので淘汰によって選択肢が減ることは、豊かな社会へは向かっていないことになると思います。 そのような中でCOEのような存在は重要な意味をもつものではないしょうか。 tag:blogs.iona.com,2007:/essence//5.526 2007-09-11T04:30:35Z 2007-09-11T04:46:37Z

TMFのTokyo Symposium 2007が東大の工学部の講義室で行われたので資料としてのカタログ詰めとともに参加してきました。

Kiyoshi Egawa http://blogs.iona.com/essence/ TMFのTokyo Symposium 2007が東大の工学部の講義室で行われたので資料としてのカタログ詰めとともに参加してきました。 学部の講堂としては立派なものですが、資料を袋に詰めるのは人海戦術で各社のカタログを一枚ずつ束ねていく作業をやっていました。200名弱くらいは参加されたのでしょうか。TMFというテレコムのOSS開発に特化した内容ですので中身は濃いものとなります。展示も数社あったのですが、狭いところ活発なコミュニケーションができていたようです。 その中で、ソフトバンクテレコム株式会社の研究所の米田　進様の講演でオーバーレイ・ネットワークという話題がありました。Web2.0の発想を元にして、XMLのメッセージのネットワークのプラットフォームを構築しようというもので、実験を行っておられるようです。インターネット上を検索してみると、NGN+S 2007での講演やソフトバンクテレコムの広報サイトでも同様のお話しをされています。 アプローチの仕方が違うので、同じものであるとは言えないのですが、以前のエントリのインターネット上のESBの考え方と位置は同じです。 米田様はRFIDに代表されるようなID管理をこのプラットフォーム上で実現することを想定されていますが、同様にこのプラットフォームを利用して実現するアプリケーションを考えていくことはなかなかおもしろうそうではないでしょうか。そこにはアーキテクチャの重要性が含まれていると思います。]]> tag:blogs.iona.com,2007:/essence//5.524 2007-09-02T01:28:45Z 2007-09-02T01:49:09Z

IDG主催のITアーキテクトのセミナでの講演がどん引きではないかと心配したエントリでは、大丈夫ではないかと思ったのですが、やはり結果は最悪でした。本人は本質的な問題だと思っているのですが、マーケットの皆さんは違うことに関心がおありのようです。

Kiyoshi Egawa http://blogs.iona.com/essence/ エントリでは、大丈夫ではないかと思ったのですが、やはり結果は最悪でした。本人は本質的な問題だと思っているのですが、マーケットの皆さんは違うことに関心がおありのようです。 セミナの後のアンケートの集計の結果が悪かったので、当分、セミナーの講師はやらなくても済みそうです。それはそれでもいいのですが、細かいテクノロジーの議論をいくらやっても大きな違いはないと思うのも間違いではないと思います。重要なのは”何をしたいか”ではなく、”何をしなければならない”かです。 使いやすい機能やきれいなGUIがITの目的ではないということです。SOAのインフラとは何であるべきかということを問いたかったのですが、マーケットは本当に反応しないです。多くのユーザは大きなベンダーのスウィート製品を導入することに魅力を感じています。アプリケーションプラットフォームとBPMを合わせて使えるときにESBがおまけで付いてくるという感覚です。現実的に複数のベンダーの製品を組み合わせるようなベスト・オブ・ブリードの考え方に反して、自らの選択肢を狭めることで安心感を得るというものです。 この先もSOAのような考え方が繰り返し登場して消えていくのかもしれませんが、システムを動かすことばかりに囚われて、システムを生かすことを考えない、つまり、システムを作り、動かすためのリスクばかりを考えて、本来のシステムのあり方を思考の外としてしまう。この傾向は非常に強いと感じます。学習を避けるということでしょうか。 このままだと格差が広がり、その先にあるのはリセッション以外にありえないはずです。格差のある社会が豊かな社会ではありません。豊かな社会は多様なものでなければならないと思います。]]> tag:blogs.iona.com,2007:/essence//5.523 2007-08-30T02:04:36Z 2007-08-30T02:25:53Z

サンマイクロシステムズのホームページを眺めていたら今年は会社が誕生して25周年ということでCEOをはじめとして3名のマネージメントのビデオが見ることができました。私もIT業界に入って（昔はIT業界とは言いませんでしたが）、28年目ですからちょうどサンマイクロシステムズの軌跡と重複するところがあるように思ってながらビデオを聞いていました。

Kiyoshi Egawa http://blogs.iona.com/essence/ サンマイクロシステムズのホームページを眺めていたら今年は会社が誕生して25周年ということでCEOをはじめとして3名のマネージメントのビデオが見ることができました。私もIT業界に入って（昔はIT業界とは言いませんでしたが）、28年目ですからちょうどサンマイクロシステムズの軌跡と重複するところがあるように思ってながらビデオを聞いていました。 最初はメインフレームでしたのでUNIXに関わりはじめたのが、20年くらい前ですが、本格的にUNIXを売る立場になったのが、DECでDIGITAL UNIXを扱ったときからでした。AlphaというCPUもDIGITAL UNIXも後発であったためになかなか悩ましいセールス活動でしたが、ベンダー各社のUNIXの勢力争いの中で統一UNIX仕様とか、茶番に似た活動があったことが思い出されます。 これからOSが大きく変化して革新的な機能を提供するようなこともないのでしょうから機能を求めるのではなく、いわば”サービス”を追及することが重要なのではないでしょうか。ただ、一挙にサービスを実現することが難しく、様々な条件やリソースが整った上で実現できるものでしょう。そのための地道な努力が必要だと思いますが、そのためにも必要なのが、市場の認知です。 市場が有効であると認識しなければ”サービス”は市場に出ないわけですからエンドユーザに何を理解していただけるのかは本当に大きな課題です。エンドユーザによって、それはすべて異なるでしょうし、深さも、サービスの内容もアプローチも違うでしょう。 でも、サンマイクロシステムズのホームページのビデオでは参加に開発者に感謝するということを表明していました。そうではなくてエンドユーザに感謝できるような接点が必要なのではないかととのとき感じた次第です。弊社のようなミドルウェアを提供している場合でも大変難しい課題ではあると思いますが、常に学ぶ気持ちを持ってお客様のお話が聞けたら何かいいことができるように思います。 tag:blogs.iona.com,2007:/essence//5.521 2007-08-24T02:37:12Z 2007-08-24T03:36:36Z

Artixは、C++をベースに製造されており、JavaのAPIからC++で作られたコアの機能を利用することになります。以前であればJava自体が重くて遅いので、このJavaとC++の間のオーバヘッドも気にならなかったのですが、Javaのコンパイラの技術やCPU自体が向上することでJavaの性能が上がってきて、オーバヘッドが目立つようになってきました。

Kiyoshi Egawa http://blogs.iona.com/essence/ IDGのITアーキテクトサミット 2007 Summerのセッションの中で出してしまったのですが、ArtixはVersion5をリリースして、Javaインタフェースの作り方が大幅に変わりました。 Artixは、C++をベースに製造されており、JavaのAPIからC++で作られたコアの機能を利用することになります。以前であればJava自体が重くて遅いので、このJavaとC++の間のオーバヘッドも気にならなかったのですが、Javaのコンパイラの技術やCPU自体が向上することでJavaの性能が上がってきて、オーバヘッドが目立つようになってきました。 以下の図にあるようにArtix5_jaxwsは、Artix5であらたにCXFをベースにして、JAX_WS（JSR224)でのアノテーションを利用したAPIに替わったのですが、その変化のひとつの要因が性能です。下図のArix5_JNIは従来のJava APIであるJAX_RPC（JSR101）をサポートし、HTTPやSOAPなどのエンジンはC++側の機能を呼び出すためにJNI（Java Native Interface）を経由して実現しているものです。 ご覧のように性能上の違いは明らかであり、PureなJavaで実現するようにJAX_WSへ移行したものです。もちろん、従来のJAX_RPCのAPIも互換性を提供するために残りますが、コアの製造が、JavaとC++に分かれていくことは明らかになったことになります。 これは”テクノロジーの格差”を意味しています。以前のエントリにあるようにJavaのテクノロジーは決してSOAインフラを構築するにも適した技術ではないにも関わらずアプリケーション開発のプラットフォームとして広まってきたというだけでマジョリティとなり、そこにメガベンダーの思惑が重なってJava技術へ偏重していると思います。 JVMの上と外とでは世界がまったく異なってしまいます。JVMの上ではネイティブなC++のWebサービスさえも提供できないのです。このテクノロジーの格差をなんとか平準化する必要があります。Artix5は従来のC++で構築したアーキテクチャを踏襲してJavaによるコンテナを同時に実現することで利用者に対しては正しいインフラの姿を提供することができる製品です。 ]]> tag:blogs.iona.com,2007:/essence//5.519 2007-08-16T05:49:03Z 2007-08-16T07:37:18Z

IDG主催のITアーキテクト・サミット　2007 Summerでセッションをひとつやってきました。相変わらずSOAをテーマにしているので、工夫が必要なのですが…工夫というか、結果的には奇をてらうということになってしまったかもしれません。

Kiyoshi Egawa http://blogs.iona.com/essence/ IDG主催のITアーキテクト・サミット　2007 Summerでセッションをひとつやってきました。相変わらずSOAをテーマにしているので、工夫が必要なのですが…工夫というか、結果的には奇をてらうということになってしまったかもしれません。 SOAのインフラについてもっと考えましょうというのが、率直なテーマです。アイオナとしては至極当然のことでインフラ（ここでいうインフラとはミドルウェアのレベルのこと）を充実していただかないと商売にならなりません。まったく、当たり前に考えても”基礎”が大事であることに何の異論もないと思います。 しかし、市場は、これに関心がない。上水道などのいわゆる社会インフラとITインフラをかけて説明したりもするのですが、社会インフラは、どちらかというと公共性の高い資源であり、公共団体が投資をしていることを思うと一般の企業にITインフラに投資を考えて欲しいといっても、投資の対象に対する意識に無理があるのかもしれません。インフラは国がやってくれることと自分の責任範囲外と思うのでしょうか。 それでも、インフラが必要であるという本質は変わらないわけで、では、その本質とはなんであろうかということになります。SOAの話を考えているとビジネスの変化に対応するというITにとってもっとも本質的な課題にぶつかります。簡単なことではありません。それでもIT側の立場としても主題となっています。 考えてみればある固定したものの上でなにかを変化させること自体が難しいです。柔軟なアーキテクチャや良く考えられた設計というものが変化を許容できるかもしれませんが、限界があります。経験的に言えば、工学的な方法論も十分でない中でそのような設計は期待しない方いいということではないでしょうか。となると結果的には固定できるものはないということになります。 友人で、人生でいろいろなことがあるときに、心安らかに、あらゆる物事を受け入れるために仏様の教えに従うという考えを持った人がいます。私なんかより、とても深くて真面目な考えで仏教の本質を捉えようとしているのですが、その友人の話を参考にすると世の中はすべて無常、つまり、諸行無常でなにも決まったものはないのではないかと思い当たりました。 でも、そうなるといったい何が私たちの実際の生活を律しているのかが理解できませんでしたが、それには縁起という説があるのが、Wikipediaを見ていてわかりました。縁起が悪いの縁起とは少々違うそうなのですが、難しい内容はとても理解できず、ただ、理解できたのは、現象（物と心）の関係を決めるルールがあって、それが縁起というもので、仏説の本質的な課題であるということでした。 これを無理やり、ITインフラにリンクさせたのが、次のスライドです。友人にプレゼンで諸行無常に縁起を使うと言ったら、そんなプレゼンには聞いている人は”どん引き”だと言われました。どんな絵を付けてたらいいかわからなくて、友人に聞いたのですが、教えてくれませんでした。天国の絵でもつけるかと思ったのですが、結局、ありきたりのものになりました。 実際には”どん引き”ではなかったようですが、皆さんがどう思われたかはわかりません。システム要件はもちろんのこと、テクノロジーも、アーキテクチャさえも、変化しなければならないのであり、それらを律するルールは、ビジネスデシジョンのルールでもあり、セキュリティポリシーのような決まりでもあり、ガバナンスの中で決めたルールやシステム開発のプロセスでもあるわけです。 これらのルールが使いまわすことができ、ブラッシュアップされていくことで、あらゆる変化に対しても対応できるシステム構築のアプローチができるようになると思っているのですが、”どん引き”でしょうか。ここのルールを構成するのがインフラです。どのような形なのか、まだ、はっきりとはわかりませんが、SOAの本質も、このようなところにあると思います。SOAスイート製品は本質ではないですね。 今の日本の豊かは社会インフラもすべての人と法人が税金を払ったからできたものであって、ITインフラに投資をしなくてもいいということにはならないと思います。 ]]> tag:blogs.iona.com,2007:/essence//5.490 2007-05-04T06:25:21Z 2007-05-04T07:04:19Z

2006年6月にAMQP（Advanced Message Queuing Protocol）の標準化のグループの発表がありました。その際に内容を発表していますが、AMQPのサイトにFAQがありましたので、翻訳をしました。もちろん、正式な翻訳ではありません。内容については原文を確認してください。

Kiyoshi Egawa http://blogs.iona.com/essence/ 発表がありました。その際に内容を発表していますが、AMQPのサイトにFAQがありましたので、翻訳をしました。もちろん、正式な翻訳ではありません。内容については原文を確認してください。 Q:AMQPとは、どのようなことをやられているのでしょうか？ トランザクションの自動化のために各企業ではオープンな標準を規定しようとしますが、時として、プロトコルスタックの中のメッセージング・レイヤでの独自のソリューションとの連携が必要となり、そのような努力が妨げられてしまうということがあります。このような機能不全やオープンなトランスポートがないことは、標準化への意欲を崩してしまい、Eコマース、分散化システム、電子マーケットプレースや究極には自由な取引自身にも不必要な障害を負わなければならないものとなります。 未だに統一された標準メッセージング・ミドルウェアの提供に成功していない市場の中でもメッセージング・ミドルウェアは、多くのアプリケーションのコンポーネントの中で重要な位置に居続けています。 この問題を解決するソリューションを開発しようとワーキンググループのメンバーは、ビジネス上のメッセージングへの共通の要件に対応しようとするどのようなソースからの実装でも可能なようにAMQPをラインセスフリーなプロトコルの仕様として設計することを決めました。 Q:AMQPはどのようにラインセスされていますでしょうか？ AMQPワーキンググループは、正式にリリースするバージョンの仕様を効率的に利用し、実装してもらうために、ただちに、そして、無条件に、使用許可を出します。AMQPは、関連する権利関係は一切発生しません。詳しくはラインセスについての記述をご覧ください。 最初のバージョン（0.8）は、公開仕様としてグループからリリースされました。2006年12月には、V0-9を公開仕様としてリリースしました。（注：このバージョンは0-9のようにダッシュを伴っていますので、次のリリースは0-10となります。） ラインセス項目にしたがって、このグループから許可をもらわなくても、誰でも自由にソフトウェアやハードウェアの公開仕様バージョンを実装することができます。ただし、その実装がどのバージョンをサポートしているかを明示しなければなりません。 AMQPバージョン1-0の前にも、更改を続けますが、バージョン間の互換性は保証しません。ただし、互換性をあっさり諦めることがないようにすることも目標のひとつとしてあります。 注意：仕様が変更作業中で、実装の間に重大な非互換の問題を発生させるような未熟な実装には未完成のドラフトの仕様のラインセスを供与しません。 Q:どのアプリケーションのユースケースをAMQPはサポートしますか？ ストアード/フォワード・トランザクションのメッセージングと高性能なパブリッシュ/サブスクライブによるイベント通知、バッチによるファイル転送型のメッセージングの基本的な機能と利用方法を統合しました。 標準的なユースケースは次のとおりです。

・	価値の高いメッセージを転送する高い信頼性（fire and forgetではなく、一旦、トランスポートでACKを受信したら確実にメッセージが転送されていると完全に信頼することができます）
・	規模の大きなコミュニティでの高い性能の状態イベントの通知（パブリシュ/サブスクライブ・イベント通知）
・	ファイル転送（セキュアで、割り込みが可能で、ファイアウォールに親和性が高く、そして、安心して使える）

多くのビジネス・アプリケーションは、次のような特徴に大きく依存しています。AMQPは、それらをひとつにして提供します。AMQPベースのミドルウェア・ソリューションについては、典型的なエンタープライズ・ビジネス・システムでのメッセージングだけのミドルウェアをイメージされるかもしれません。

i)	グローバルなネットワークを通じて、価格や在庫の情報を数百のクライアントへ配信
ii)	これらのクライアントやプロセスからの要求を冗長化したトランザクション処理エンジンを通じて受付
iii)	内部の台帳、刷り合わせなどのためにバッチファイルを作成し、転送
iv)	バックオフィース処理で必要な情報を転送するためにインターネットを通じて取引先のパートナと接続
v)	監査にパスするように、これらのすべての機能はセキュアに実行、運用者がシステムをモニタし、制御し、さらに、既存のバックアップ体制との統合を実施
vi)	ビジネス活動のリアルタイムな状況を表示するためにアプリケーション・トラヒックをモニタ

AMQPのソリューションは、高性能なクラスタリングやグリッド・コンピューティングの課題に対応することができます。ただし、AMQPの本来のゴールはビジネスプロセスでのコミュニケーションの実現にあります。 Q:“ワイヤーレベル”のプロトコルはなんでしょうか？ ワイヤーレベルのプロトコルは、あるAPIを補完するものと考えられます。機能を定義して、ライブラリを作る代わりに、何かを起こすためにネットワーク上を転送するバイトのシーケンスを定義します。 ワイヤーレベルのプロトコルが定義され、公開されると、ほとんどのテクノロジーでそれらを利用することが可能であり、また、ときには、これらを利用することが要件となります。この方法とAPIと比べるとプラットフォームを特定した実際の実装が明らかになります。 JMSはAPIです。HTTPはプロトコルです。AMQPはHTTPに相当するミドルウェアを提供しますが、別の実装を適用することも可能です。 Q:“標準プロトコル”とはどのような意味でしょうか？ AMQPを正式な標準化団体によって準拠できる標準とするようにしたいと考えています。 これについては、AMQPワーキンググループが実際の作業を通じてAMQPを開発することで対応していきます。たとえば、IETF RFCでは、相互運用可能であると実証されている仕様に基づいて最低2つの独立した実装が検証のために必要となります。 ワーキンググループの多くのメンバーが、AMQPの実装に参加しており、このグループの方針として仕様を標準化団体へ委譲することを目標としています。 Q:Java Messaging Service（JMS）とはどのように違うのでしょうか？ JMSはJavaにおけるストアード/フォワードとパブリッシュ/サブスクライブのデファクトAPIの標準です。 JMSは、実装やワイヤーレベルのプロトコルを規定していません。JMSは、テクノロジー中立ではなく、ラインセスの規定によってJavaプラットフォームのみをサポートするのが正規のものです。 AMQPは、JMSを実装するための必要な要件のスーパーセットであり、Linux、Solaris、Windows、Z/OSなどの上のC、C++、Python、C#、あるいは、他の言語のAPIも提供可能です。 Q:APIも規定されますか？ AMQPワーキンググループは、基本的にはAMQPの実装のためのAPIを標準化することは考えていません。 プログラミング環境が、スムースに適合できるようなAMQPのAPIを作り出すことが自然なことです。Java用のAPIはJMSのようになりますが、PythonやCOBOLは、まったく違うものになります。 異なるAPIを定義することにもまして、AMQPに従った実装はシームレスに相互運用可能となります。たとえば、Javaのプログラムは、異なるAPIを使っている.NETプログラムと通信するのにAMQP準拠のJMSを使うことができます。これが、ワイヤーレベル・プロトコルの利点です。 Q:IBM MQSerieseやTibco Rendezvousとはどのような関係になりますか？ MQSeriesやTibco Rendezvousは、その独自のプロトコルと機能で商用のミドルウェア製品をリードしています。しかし、MQSeriesとRVは、お互いに、あるいは、他のミドルウェアとの間でネイティブに相互運用することはできません。 AMQPは、異なるインテグレーション・ブローカの実装の間でも相互運用が可能な仕様です（製品ではありません）。AMQPは、もっとも一般的に使われるミドルウェアの機能を完全に仕様化したプロトコルであり、公平な仕様です。 AMQPベースのソリューションによって、うまく運用されているその他のテクノロジーの利用を止めてしまうことは期待していません。しかし、企業の皆さんが、AMQPを、高い可能性を持つミドルウェアの戦略であると捉えていただきたいと思っています。 どのベンダーでも、もし、そのようにしたければ、それぞれのテクノロジーで自由にAMQP互換の実装を行うことができます。詳しくはラインセス関する記述をご覧ください。 Q:Webサービスとはどのように関係していくのでしょうか？ AMQPは、Webサービスの到達保証のあるトランスポートとして利用できます。AMQPは、ペイロードを定義せずにトランスポート・レイヤーを定義します。つまり、SOAP、WS-Security、WS-Transactions、WS-MetaData Exchangeなど、それ以降の仕様も、すべて、JMSで利用するのと同様にAMQPで実装することが可能です。ただし、AMQPは、トランスポート・リンクの最下位のレベルのベンダー中立な相互運用性を提供します。 Q:AMQPの実装はどこで参照できますか？ AMQPは、製品ではなく仕様です。製品は、ワーキンググループのメンバーか、メンバーでなくても3rdパーティがどこかで開発します。 AMQP製品の記述をご参照ください。 Q:AMQPは実証されていますか？AMQPの利用事例はありますか？ 異なるプログラミング言語、複数のプラットフォーム、さらに、仕様が最初にリリースされる以前からある既存のシステムとの相互運用可能な実装を開発するためにプロトコルを規定することはワーキンググループが意識している目的です。 異なる関係者がいっしょに検討を行いながら実際の要件に対して仕様をテストし、改訂していくことだけが、仕様を迅速に成熟させていきます。AMQPは、いくつかの企業の多くの人々からインプットをいただきながら2年間以上開発を続けてきました。 JPMorganでは、ワーキンググループのほかのメンバーと緊密な関係を保つことで、AMQPの異なる実装を利用してアプリケーションを構築することができています。 ひとつは、Javaと.NETクライアントで実現しています。もうひとつは、C/C++クライアントとメッセージ・ブローカー機能をLinux、SolarisとWindows上に実現しています。JPMorganのアプリケーションは、世界の3つの地域データセンターに配置したクラスター化したAMQPブローカーを通じて、数百の同時利用ユーザが情報の参照とトランザクション処理のために利用します。 このAMQPの実装は、移行をスムーズにするために、いくつかのレガシーな独自のミドルウェア製品とのブリッジ機能を提供しています。 注意：JPMorganは、AMQPを実装しているどの製品の性能についてもクレームを表明していません。詳しくは、ラインセス同意規定をご参照ください。 Q:AMQPを自社でどのように適用すればいいでしょうか？ 既存の稼動中のミドルウェアをビジネス上の判断もなしにAMQPベースのソリューションへ移行するということは期待していません。仮にビジネス上の判断に反しないとしても満足の行くものとはなりません。 標準ベースのミドルウェアへ移行するという熟慮の末の戦略の一部として機会があるたびに、ビジネス上の通常の手順として、自然な方法で企業がAMQPを適用することを期待しています。このアプローチでは、競合力のある価格やオープンソースの利点を享受することができ、それらを実現する共通の規約や製品の経験を積むことができます。2から3年の経過とともに多くの要求は、このようなアプローチからAMQPとして実現していきます。また、既存のミドルウェアの供給元がAMQPを実装することも可能であり、標準ベースのモデルへの移行することができます。結果的にAMQPがネットワーク・インフラの中核となるサービスとなることを希望します。 一方、企業がサービス指向アーキテクチャ（あるいは、バス・ベース・アーキテクチャ）へ投資するならば、SOAのバックボーンとしてAMQPを一括して配置することを勧めます。そのようにするとAMQP互換のミドルウェアのサプライヤー同士の競争から利点を得ることができるでしょう。そのために、適切なサプライヤーから要件にあったサポートのレベルやサービスの品質を達成することができるかもしれません。AMQPの適用によって、企業のSOAで重要なバス・コンポーネントへの長期投資に対するベンダー・ロックインやサプライヤーの倒産などの心配事に対応することができます。同様のことが、インターネットや専用線を介した取引パートナとの間で適用しているeビジネスのオープンなプロトコルについても当てはまります。 注意：AMQPワーキンググループは、AMQPを実装しているどの製品の性能についてもクレームを表明しません。詳しくは、ラインセス同意規定をご参照ください。 Q:どのプラットフォームがサポートされますか？ このプロトコルは、プラットフォームとプロトコルに中立であるように設計されています。 ワーキンググループのいくつかの企業が、様々なプラットフォーム上にAMQPベースの製品をリリースすることを期待しています。 Q:某社はなぜAMQPのワーキンググループに参加していないのでしょうか？ ほとんどのミドルウェア・サプライヤーはAMQPプロジェクトを意識しています。さらに、いくつかは、この活動に参加していただいています。しかし、すべての関係者にアプローチすることができません。そして、すべての企業が今参加する必要があると思えるわけでもありません。 もし、あなたが、ベンダーの方であり、この活動に参加したいと思われるのであれば、ご連絡を御願いします。さらに、ミドルウェアのエンドユーザの方で、もっとも、気に入っている製品がAMQPをサポートしてほしいのであれば、そのサプライヤーに要求をあげてください。 Q:マルチキャストはAMQPでどのように扱われますか？ クラスタやグリッドで分散化したサブネットの最適化のためにマルチキャストを仕様化する作業を進めています。 AMQPは、サブネット間の信頼性の高いマルチキャスト・メッセージ転送の明確な方法を定義しています。PGMのようなトランスポートでは、サブネット内のパブ/サブのAMQPメッセージの最適化を実現するでしょう。 検討の完成を目指して作業中ですが、できれば、PGMからAMQPへ、および、AMQPからPGMへの双方向で適正な相互運用性が得られることを期待している。 Q:AMQPはメイルとどのように違いますか？ 裸の王様の話のように考えるとミドルウェアとメイルは同じことです。 AMQPはメイルに似ていますが、サービス品質（QoS）の実現を明示的に制御します。 メイルでは不明確なこともAMQPは定義します。たとえば、メッセージのサイズ、信頼性、セキュリティ、廃棄するためのポリシー、TTL、高速なグループ配信、1対Nの配信など。 重要なのは、メイルにはない、メッセージを転送する先のAMQPシステムの認証を行うことです。それによって、ビジネス上のメッセージングで重要な迷惑メッセージを無くすことができます。 Q:Spread、ICE、Elvin、TAO、Muscleなどとはどう違うのでしょうか？ 多くのミドルウェア・ソフトウェア・パッケージがあり、それぞれ、異なる用件に対応しています。 しかし、AMQPはソフトウェア製品ではありません。メッセージング・ミドルウェアのための文書化したプロトコルの定義です。 プロトコルとしてのAMQPは、このFAQの中にもあるように、ビジネス上の信頼性の高いメッセージングに必要なメッセージ交換機能に重点的にフォーカスした大変ユニークなものです。 Q:CORBA/IIOP、DCEやONC RPCとはどのように違いますか？ CORBA/IIOPは、リモートのオブジェクトを引用するワイヤーレベルのプロトコルです。オブジェクトを操作して、メソッドを呼び出します。これは、“インタフェース”（繊細な）を操作するDCOMやプロセスを操作するONC/RPC、DCEとも異なります。 すべてがネットワーク上の呼び出しで同期されて、メッセージの保証やキューイングの考え方はありませんが、QoSについて若干考慮しています。このようなプロトコルは、それぞれの位置づけをもっていますが、完成はしていません。IIOPも、実際のアプリケーションのシナリオで問題となっているファイアウォールへの対応はよくありません。 AMQPは、概念的にはCORBA Notification ServiceとCORBA Event Serviceと似ています。しかし、実際には仕様の複雑さや完全なORBが必要となることからNotificationとEvent Serviceの部分的な実装でも多くは存在しません。このような複雑さによって適用を広げる際に敏感に反応することができなくなります。 結局、メッセージングは、オブジェクトのトランスポートレイヤーの上ではなく下に組み込まなければなりません。つまり、メッセージングは、オブジェクト・メソッドの呼び出しより一般的な位置づけです。 Q:仕様（あるいは、メイリングリストのアーカイブ）はどこにありますか？ 開発のためのアーカイブや開発者のメイリングリストへのリンクは、まもなく公開されます。 ]]> tag:blogs.iona.com,2007:/essence//5.489 2007-05-04T05:24:38Z 2007-05-04T06:20:24Z

2006年6月にAMQP（Advanced Message Queuing Protocol）の標準化のグループの発表がありました。その際に内容を発表していますが、AMQPのサイトに概要の説明がありましたので、翻訳をしました。

Kiyoshi Egawa http://blogs.iona.com/essence/ 発表がありました。その際に内容を発表していますが、AMQPのサイトに概要の説明がありましたので、翻訳をしました。もちろん、正式な翻訳ではありません。内容については原文を確認してください。AMQPは非常にユニークなアプローチだと思います。また、アイオナでは、AMQPを実装したオプションをCeltix Advanced Messagingとして発表しています。 AMQPとは？ AMQPはメッセージング・ミドルウェアのオーブンな標準です。 ミドルウェアとは、他のソフトウェアに接続するためのソフトウェアです。また、企業内と企業の外部のシステムの両方に対して、システム化された孤島同士を連携するものです。 AMQPの標準に従えば、異なるプラットフォームの異なる言語で書かれたミドルウェア製品は、その他のミドルウェア製品との間でメッセージを送ることができなければなりません。AMQPは、企業内、および、企業間でメッセージとビジネス上の価値を迅速に転送しなければならないという要件に対応するものです。 どうして注目に値するのでしょうか？ メッセージングとインテグレーションはすべての企業システムの一部として必要なものです。

・	ITによるシステム化の著しい努力には、すべて、メッセージングとインテグレーションを伴います。（プロジェクト費用の10％から30％）
・	ベンダー独自のミドルウェア製品は、ミドルウェアの選択上の品質とコストの両面の競争を阻害するロックインの根本原因となります。
・	相互運用性は必要です。しかし、簡単には実現できません。

通常のオープンなビジネス標準は理論的にはベンダー独自のテクノロジーを基にしないで、オープンな情報とビジネスのプロセスモデルとオープンなメッセージのフォーマットを利用しています。しかし、メッセージングのための適切なオープン・テクノロジーは実際には存在しません。 AMQPは、メッセージング・ミドルウェアのデファクトとなるオープン標準になることを目指しています。 AMQPはどのように他のミドルウェアの標準と異なるのでしょうか？ AMQPが他のミドルウェアの標準と異なる点は：

・	単純明快で、かつ、完成度の高いビジネス・メッセージングのソリューション
・	完全にオープン
・	ユーザとベンダーなどの技術担当者の共同作業の結果
・	現実の要件に対応
・	ひとつの仕様で、1対1のメッセージ転送とパブリッシュ／サブスクライブの型の両方を規定

AMQPは、ビジネス・アプリケーションが共有することのできる基本的なメッセージング・ミドルウェアを規定することを目指します。 どのようなAMQPの仕様が規定されていますか？ メッセージング・ミドルウェアの完全な相互運用を実現するために、AMQPではネットワーク・プロトコルとブローカーのサービスの動作の両方を規定しています。 AMQPは次のように構成されます。

・	“AMQPモデル”と呼ばれるメッセージング機能を定義。AMQPモデルは、ブローカーのサービス内のメッセージのルーティングや蓄積についての詳細な仕様で定義されたコンポーネントから構成されており、コンポーネント同士を結びつけるシンプルなルールを規定
・	ネットワークのワイヤーレベルのフォーマットによりクライントがブローカーと接続し、AMQPモデルにしたがった実装との通信が可能

これは、AMQP仕様によってサーバのセマンティクスの一部をそのまま実現することができることを意味しています。ただし、実際には明示的に実装することでプロトコルの理解を進めることができます。 なぜ、AMQPは開発されたのでしょうか？ ほとんどのネットワーク・プロトコルの方式では対応が可能とされていますが、メッセージを保証することが可能な共通に利用できるミドルウェアを考えると現実との隔たりがあります。ミドルウェアは利用価値の高いユーティリティです。中堅企業や大企業でのミッションクリティカルなITシステムをサポートし、ビジネスプロセスの自動化を支えるキーとなる役割を果たしています。 しかし、現在、JMSは解決策として一部しか対応していません。Javaの信頼性に制約があり、ワイヤーレベルの相互運用を規定することができません。どのようなソリューションが、この問題に対応するとしても、プラットフォームや言語に囚われずにオープンな方針の下で実現できることが重要です。 Advanced Message Queuing Protocol（AMQP）は、既存のシステムとのインテグレーションを行う新たな製品の基盤となり、さらに、JMSなどのAPIの相互運用を改善していくために利用できます。 AMQPは、JMS、SOAP、WS-Security、WS-Transactionなどのほとんどの既存のメッセージングやWebサービスの仕様を補完しながらいっしょに利用することができます。AMQPは、ネットワークを最適な状態で使えるため、あるいは、グリッド型の配置を可能とするためにマルチキャストによる双方向のルーティング機能を提供します。 AMQPモデル 相互運用のためには同じセマンティクスが必要であるので、AMQPモデルは、サーバのセマンティクスを明示的に定義します。また、コンポーネントのモジュールを特定し、これらのコンポーネントへの接続のための標準的なルールを規定します。 このモデルは次のような3つの主要なコンポーネントのタイプがあります。これらのコンポーネントは必要な機能を提供するプロセスの連鎖に組み込まれます。

・	“exchange”はパブリッシャであるアプリケーションからのメッセージを受信し、メッセージのプロパティや内容そのものから得られる排他制御の設定にしたがって、それらのメッセージを“message queue”へ転送します。
・	“message queue”は、利用者側のクライアント・アプリケーション（あるいは、複数のアプリケーション）が確実に処理できるまでメッセージを蓄積しています。
・	“binding”はmessage queueとexchangeとの間の関係を定義し、メッセージをルーティングする基準を規定します。

このモデルでは、ストアード／フォワード・キューやトピック購読の従来のミドルウェアの概念をエミュレートします。また、コンテンツ・ベース・ルーティング、メッセージ・キューの生成、随時利用のメッセージ・キューなどのちょっとした概念についても指定します。 大雑把な言い方をするとAMQPサーバはメイルサーバに類似しています。つまり、exchangeはメッセージ転送エイジェント（MTA）に、メッセージ・キューはメイルボックスということになります。bingingは転送エイジェントの中にルーティング・テーブルを定義します。パブリッシャは、それぞれの転送エイジェントにメッセージを転送し、メッセージはメイルボックスへルーティングされます。利用者はメッセージをメイルボックスから取り出します。これによって、強力で柔軟なモデルをシンプルに定義できます。 AMQPワイヤー・フォーマット AMQPのワイヤー・フォーマットは、最新の特徴を備えたバイナリによるフレームです。これは、マルチ・チャネル対応可能、すでに協議済み、非同期対応、セキュリティ対応、移植可能、中立であり、効率的であるなどの特徴を備えています。 AMQPワイヤー・フォーマットは二つのレイヤに分かれます。機能レイヤとトランスポート・レイヤです。機能レイヤは、アプリケーションに代わって、その役目を果たすコマンド（各機能を論理的なクラスにグループ化したもの）の組み合わせとして定義されます。トランスポート・レイヤは、このようなメソッドをアプリケーションからサーバへ双方向で転送し、多重なチャネルの制御、フレームの構成、内容のエンコード、ハートビート、データ表示やエラーハンドリングなど行います。トランスポート・レイヤと機能レイヤの両方とも、プラグイン構成でプラグインによるカスタマイズが可能です。これによってプロトコルの刷新や新たなテクノロジーの適応に対応できます。 AMQP仕様のダウンロード 仕様はAMQPユーザのページからダウンロードできます。 AMQP製品の検索 AMQP製品のページをご参照ください。 ]]> tag:blogs.iona.com,2007:/essence//5.453 2007-02-02T03:31:27Z 2007-02-05T00:57:43Z

TMF（TeleManagement Forum）の今年の活動の目玉にProssperoがあります。Prossperoの名前の由来はNTTコムウェアの野本様のブログにあるようにシュークスピアの戯曲に出てくる人物で、混沌とした社会の秩序を取り戻した功績があるそうです。TMFはフォーラムの活動の結果として標準化に順ずるOSS/BSSの仕組みの共通化を行ってきましたが、実際のアウトプットをマーケットで有効な存在とするための効果が上がっていませんでした。

Kiyoshi Egawa http://blogs.iona.com/essence/ TMF（TeleManagement Forum）の今年の活動の目玉にProssperoがあります。Prossperoの名前の由来はNTTコムウェアの野本様のブログにあるようにシュークスピアの戯曲に出てくる人物で、混沌とした社会の秩序を取り戻した功績があるそうです。TMFはフォーラムの活動の結果として標準化に順ずるOSS/BSSの仕組みの共通化を行ってきましたが、実際のアウトプットをマーケットで有効な存在とするための効果が上がっていませんでした。 いわば、OSS/BSSに関する先進の技術のキャズム（新しい技術が先進的な利用者の閉じた利用からマーケットへ出ていくことをいいます。）を超えることができていなかったということです。Prossperoは、このキャズムを超えるためにいろいろな場面で製造されたソフトウェアのアプトプットをパッケージ化することで利用を促進することを狙っているようです。 これは、Celtix Enpterpriseで複数のオープンソースを統合して製品化したのに似ています。個々の技術をインテグレーションして使えるものにしていくことが重要性に着目してみてはいかがでしょうか。技術を開発して世の中に出していくのは時間と労力がかかります。しかも、時間をかけて開発した技術がマーケットに受け入れられなければ消えていく運命となるのです。このような、いわば無駄を回避するのがインテグレーションです。 SOAのひとつの側面にアッセンブル（組み合わせ）の考え方があります。サービスを組み上げてコンポジットなサービスを作ることです。Web2.0ではマッシュアップです。そんな中でProssperoという考え方が出てきたのは、ITの世の中の流れを示しているのではないでしょうか。 江川]]> tag:blogs.iona.com,2007:/essence//5.437 2007-01-01T07:59:41Z 2007-01-01T08:37:43Z

Steve VinoskiのIEEE Internet Computingのコラムを翻訳して、ThinkITに掲載されました。前回のRubyをエンタープライズで使うにはどうしたらいいかという話題に引き続き、Rubyをレガシーが技術と連携する場合のケーススタディをテーマとしています。

Kiyoshi Egawa http://blogs.iona.com/essence/ Steve VinoskiのIEEE Internet Computingのコラムを翻訳して、ThinkITに掲載されました。前回のRubyをエンタープライズで使うにはどうしたらいいかという話題に引き続き、Rubyをレガシーが技術と連携する場合のケーススタディをテーマとしています。 1993年に生まれたRubyも10年以上、経過しています。その間に多くの拡張が加えられて、現在のような話題の中心にあるのですが、”銀の弾丸”にはならないにしても、ブレークスルーを起こすには、既成の考え方の枠を超える必要があります。Rubyはエンタープライズでは使えないという意見もあると思いますが、Steveはアグレッシブに取り組んでいます。もちろん、Steveは、生粋のエンジニアですので、現実と現実でないことの見分けをつけることができます。 できて当たり前のことができてもお金をいただくことはできません。ソフトウェアの業界は、どんどん、そんな方向へ向うと思います。オープンソースやSaaSなどの流れでしょうか。テクノロジーは、正しかろうが、間違っていようが、選択と積み重ねです。まずは、選択することが重要だと思います。 江川]]>