eclipse conference 3rd Day

朝一番で大きな講演がありました。

  1. Building Applications for the Cloud with Amazon

前日にプレス発表したらしいのですが、AmazonのCloudサービスをeclipse環境から操作できるようにしたという話です。AmazonとAmazonのCloudサービスを使い成功している会社の人による講演でした。日本でも翌日にアットマーク・アイティで

  1. アマゾン、Eclipseプラグインを公開:Eclipse中でAmazon EC2向けJava開発が完結

という記事が出ていました。もちろんデモをして見せてくれました。「後で遊んでみよう」と多くの人(何しろ聴衆はほぼ全員開発者です)が思ったと思います。

さて、この日はモデリング系の話題が多少少なめでした。ご紹介するのは:

  1. Agile Modernization using Automated PIM Extraction from non-OO legacy systems
  2. The Unbearable Stupidity of Modeling
  3. Testing for GUI, Embedded Systems, Systems Engineering and Distributed Products

の三つです。

一件目は、スポンサー講演の一つでレガシー再生製品の概要やアーキテクチャ的な話でした。認識を新たにしたのは想像以上にきちんとOMGのKDM仕様を実装しているだけでなく、その前後も本格的にアーキテクチャ設計されていることでした。構造がしっかりしているからソフトウェアがきちんと動くと言う保証は無いのですが、次の時間帯ではHands-onが予定されていて実際に体験させるようでしたので自信があるのでしょう。

二件目は、EMFでおなじみのEd Merks氏が話をするという予定だったので楽しみにしていたのですが、残念ながら彼は今回参加できず、Peter Friese氏が代役を務めました。モデリングに対する批判を一つずつつぶしてゆくという趣向です。面白かったのは「モデリングはLearning Curveが急なため習得が大変」という点について、「Learning Curveが緩いということは時間をかけても少ししか上に行けないということで、急だということは効果絶大ということ」という言い方をして大うけしていたことです。見方を変えると別の見解が生まれるものです。

三件目は、Short Talksと言うらしいのですが、短めの講演が3件、一定の時間内に話を終わらせないといけないルールになっていました。中身は:

  1. Using models to ease the start-up phase of automated GUI testing
  2. An Integrated Test Environment for Systems Engineering
  3. Automatic Unit Testing Toolset for Embedded Systems
  4. MOTODEV Studio for Testing: A platform testing based on Eclipse

で、3件目は日本からの方によるものでした。設計部門が行うテストは少し経験がありますが、専門的な活動はしたことが無かったため、このように集中的に話を聞くのは初めてのことでした。ということで内容についてのコメントは出来ません(上のリンク先をご覧下さい)。ただ、日本からの方は、例の成田空港の事故のせいで到着し即講演だったとのことで、本当にお疲れ様でした。

eclipse conference 3rd Day

Open Cloud Manifesto騒ぎについて

本来ならeclipse conference 3rd Dayについて書くところですが、先週末からこのOpen Cloud Manifestoが騒がれていて、何がどうなっているのか(帰国日程とも重なっていたため)良く把握できていませんでした。あちこち読み漁ってみたところ、ちょっと皮肉な書き方ですが、次の記事が良いポイントを突いているような気がしました。

  1. IBM’s ‘Stop Amazon’ Cloud Putsch Dissolves

以前から書いていますように、標準化には長年関与してきましたので、こういう政治的な争いはあって当然だと認識しています。ただ、現時点での本当の力関係というものは、メディア記事で判断してはいけなくて、やはり何らかの客観的事実に基づいて判断する必要があると思っています。この騒ぎが事実だとすると(どうもそのようですが)、AmazonがCloud時代の主要プレーヤになる(なっている)ことがほぼ確実だということになります。

まだ先が見えていない(雲がかかっている)部分があると思います。例えば、Private Gloud、Data、Security周り、などです。我々は騒ぎのことは忘れ、前向きに残された問題に取り組みましょう。

Open Cloud Manifesto騒ぎについて

eclipse conference 2nd Day

時差ボケとの戦いと夜に知り合いと会ったりすることがあるためライブ報告にならないのが残念ですが、少しずつ掲載してゆきます。このポストを書いているのは最終日(4日目)ですが、今回は2日目の分を掲載します。残りは日本に戻ってからになりそうです(言い訳)。

この日がconferenceの正式な初日ということで、朝にIntroductionThe Social Mind: Designing Like Groups Matterという講演があり、各種セションが開幕となりました。顔を出したモデリング関連のセションは次のようなものでした。なお、講演資料はそのうち公開してくれるのではないかと期待しています(参加者に配布されるようなことはありませんでした)。

 [Designing an Android Domain Specific Modeling Language using EMF, GEF and GMF]

簡単に言うとEMF/GMFを使って(GEFをどこで使ったのかの説明はありませんでした)Android用のアプリケーションを作成するという講演です。手作業でサンプルアプリケーションを作成した後、EMF/GMFを使うとこんなに簡単に出来ますという話でした。日本のAndroid開発者の方々も関心を持たれるかも。

 [Executing BPMN]

jBossの持つjBPMの機能についての話でしたが、BPMN2.0にどう対応してゆくかというところが以前OMGBPM関連をみていた私としては興味深い話でした。

 [Next generation textual DSLs with Xtext]

現在のEMFを使ったモデリングは、特にecore用グラフィカルエディターが使えるようになってからは、どうしてもグラフィカル(ダイアグラム)の世界でメタモデル定義をするようになっていますが、抽象構文を定義している訳ですからテキストでも文法の定義が出来るはずで、それを実現しているプロジェクトの状況報告でした。

 [EMF Comparison, Editing, and Indexing]

EMFファイルの更新を何度も行ってゆくと、ソースコードとは違ってもう少し高度なCompare機能が欲しくなります。それがEMF Compareでした。他は省きますが、基本的にEMFデータを単なるテキストファイルとして従来の仕組みで扱うのではなく、構造まで踏み込んで少し高度な(楽なそしてロジカルな)取扱いをしたいということでいくつかのUtilityが作成されています。

 [EMF Repository, Workflow, and Model Execution]

Repositoryはドイツの大学の人による講演で、チームで同じEMFファイルを扱う場合に対応するため構築したメカニズムの説明。WorkflowExecutionも含め、Incubationの中にあるプロジェクトのようです。

 EMF周りは本当にいろいろなプロジェクトがあります。どうしてこんなにドイツ勢(そしてフランス勢)が多いのかミステリーです。

eclipse conference 2nd Day

eclipse conference初日

以前書きましたように、現在eclipse conferenceに来ています。場所はSanta Clara, CAですが、とても風が強く寒く感じる状況です。今回が実質的に最初の参加ですが、誰か知っている人が参加しているだろうという甘い期待はほぼ裏切られてしまいました(eclipseの親分には面識があったので挨拶しておきました)。

初日はチュートリアルの日となっており、顔を出したいセションが沢山あるのですが、モデリング系から選んで、午前はQVT Operationalの話、午後はDSLの話に参加しました。

午前のQVT Operationalでは、例題に基づいてecoreモデルのUMLモデルへの変換、UMLモデルのXHTML文書への変換、それらの複合変換、などを例に取って、何もない状態から変換スクリプトを書いて行く過程を見せながら説明してゆくというやり方で、とても分かり易いものでした。これなら自分でも書けそうだと思わせてくれました。

午後のDSLも同じようなアプローチでしたが、事前の調整がうまくできていなかったようで、詰まる場所もあってQVTほどスムーズな展開ではありませんでした。EMF/GMFでドメインモデルを作成するところは同じですが、最終的にコード生成レベルまで視野に入っているようです。コード生成にはXpandを使うとのことです。

この両者に共通するのはOCLの利用で、どちらも可能な限りOCLを使い、機能不足分は何らかの形で補うというアプローチのようでした。日本ではOCLは流行らないという話を聞いていますが、その考えを変えざるを得なくなる時期が近付いているのかもしれません。

eclipse conference初日

本の紹介(5)

Cloud Computing関連の書籍(主に日本語のもの)をいろいろ読みましたが、現在本屋に並んでいる次の本が良く書かれていると思いました。

  1. クラウド

著者は西海岸在住の方のようで、またソフトウェアやハードウェアと少し距離を置いて活動されているようなところから、冷静な見方が出来たのではないかと思います。

本の紹介(5)

商用版Hadoopについて

Cloud Computingに関心を持たれている方はMap/Reduceについてもご存じだと思いますし、そのオープンソース実装のHadoopについてもご存じだと思います。

clouderaという会社がHadoopを比較的容易に利用できるサービスを開始したというニュースが飛び交いました。例えば

  1. Ex-Google, Yahoo staffers release Hadoop distribution
  2. クラウデラ、RPM提供でHadoop商用利用をサポート

そこでこの会社のホームページを見てみました。

  1. http://www.cloudera.com/
  2. http://www.cloudera.com/hadoop

かなり一般向けに使えるようにしたもののようです。といっても、これを使って何を実現するかということがイメージできている人でないと価値はないかもしれません。技術的には、このサイトのbasic trainingというところにあるビデオが有用だと思いました。

  1. http://www.cloudera.com/hadoop-training-basic

アクセスが多数あるようですので、我慢してみてみましょう。自分でハードを揃えられる個人はいないと思いますが、Amazonを利用したり、企業レベルでの利用ということは考えられます。

商用版Hadoopについて

QCon London 2009について

単なる紹介です。

QCon London 2009が3/9-10(チュートリアル)、3/11-13(カンファレンス)と開催され、そのスケジュール一覧が以下のページにあります。

  1. Schedule

このページは水曜日を表示していますが、上の方のリンクから他の曜日のスケジュールにも移動できます。公開されている資料も結構あるようです。

QCon Tokyo 2009が4月に予定されていますが、事前準備にみておくと良いのではないでしょうか? なお、4月は私も勉強のために参加予定です。

QCon London 2009について

標準化について(モデリング言語)

これまでの流れでモデリング言語の標準がUMLで対抗しそうなものがDSLだということがお分かりだと思います。

UMLは幾つも存在したモデリング言語・記法・方法論から標準化できる範囲を決めて合意を取ったものです。確かに標準ですが、例えばダイアグラムの種類の多さをみると、通信プロトコルやミドルウェア程には「標準にこう書かれているので、こういうデータしか受け付けられない」といったことが言えないところがあると思います。大体、同じ課題を与えてまったく同じクラス図が出来上るということがなかなか無いと思います。国際標準にもなっている標準記法ですが、Design by committeeと言う意味では通信やミドルウェアと変わりませんので、使い方において選択肢が結構あるということです。

DSLですが、こちらも結構歴史があります。UML対抗という意味では、最近の話に限定しても構わないと思います。以前も書いたと思いますが、DSLと大きなくくりをすれば同じですが、実際にはいろいろなキャンプがあります。ということは、ひょっとすると何らかのDSL標準が現れる直前の状況なのかもしれません。そういった標準が出来るとすると、OMGのモデリング標準(MOFも国際標準になっていたと思います)とどう調整を取るのか関心を持って眺めたいと思います。DSLで気になるのは、同じ種類のDSLでも異なる種類のDSLでも良いのですが、似たような分野に適用し似ているものの異なる種類のモデルを量産されることです。1種類でも問題なのに、沢山でこれをやられると、後でモデル変換を山ほどしないといけなくなる恐れがあります(これは容易ではありません)。本気で使うのであれば是非DSLも標準化して欲しいものです。

標準のReference Implementationという意味ではラッキーなことにeclipseがあります。以前eclipseのモデリングプロジェクトを紹介したことがありますが、オープンソースでUML2エディタあり、SCAエディタあり、BPMNエディタありですし、GMF他でDSL実践も可能です。このような環境で仕事が出来る最近の若い方は幸せですね。

元に戻って、結局オープンで多数の人に支持され使われるのが本当の標準だとすると、モデリング言語の標準化というのは実はまだ制定・発展途上(ひょっとするとまだ入り口に過ぎない?)なのかもしれません。

標準化について(モデリング言語)

標準化について(ミドルウェア編)

世の中でミドルウェアと呼ばれているソフトウェアのカバーする領域はかなり広く、ここでは分散処理基盤という意味で使うことにします。分散処理基盤というのは、地理的に離れた箇所に有るコンピュータシステムを、まるで一つのシステムであるかのように使えるようにする技術で、それを実現するためには多くの「縁の下の力持ち」的機能が必要になります。従って標準化するとかなり分厚い標準になってしまい、開発者でないと読まれなくなってしまうものです。

現在OASIS、W3C、WS-IなどでWeb Servicesの標準化が進められていますが、振り返ってみると、Apollo DomainやSunのワークステーションなどの時代に使われたRPCという技術から、それまでの通信プロトコルを直接操作するようなAPIから分散透過性の一部を実現し始めたのではなかったかと思います。

その後、前回書きましたOSIの世界でもMHSといわれたメッセージング標準やOSI RPCなどの標準の策定が行われました。

その次に現れたのはOSFのDCE(分散コンピューティング環境)でした。この仕様は確かX/OpenでAPI標準の形で標準となったと思います。この頃は業界が二つの陣営(OSFとUnix International)に分かれていましたので、業界全体での標準化推進にはなかなか向かいませんでした。

そしてOMGのCORBAが現れます。アーキテクチャから始めて、何年もかけて広い機能範囲を供えた標準となりました。個人的にはこれでこのレイヤーの標準化は終わるのかと思っていたのですが、Firewallを通過できない、IDLが分りにくい(?)、など良く分らない理由により、より手軽にFirewallを通過できるHTML/HTTPベースのWeb Servicesが出てきました。機能的にはCORBAで標準化したものを改めてWeb Services用に作成する必要があるため、何度も同じことを繰り返しているような感覚を憶えました。それが今日の基盤などにも引き継がれてきていると思います。

分散処理基盤としては、上記以外にもメッセージキューイングのシステム、イベントベースのシステム、組み込み・リアルタイムシステム用、など別のものも存在します。このような代替わりや多様性を見ると、今後を考えてもこのレイヤーで真の意味での標準が現れる可能性は低そうですし、OMGがMDA(モデル駆動アーキテクチャ)を言い出したのは自然なことだったのだろうと思います。

整理すると

  1. 分散処理基盤(ミドルウェア)領域の標準化は何時までも続く可能性が高い
  2. そのうちの幾つか(の標準化)を経験すると、Platform独立な世界の価値も理解できるようになる

クラウドの世界になっても、各クラウド上で用いられるミドルウェアがあり、それが進歩する可能性が常にありますし、Intercloudを実現する機能もミドルウェアの一部になるのでしょう。

どうも「ミドルウェアの世界の標準には(他の技術分野より短い)賞味期限がある」という気がします。それを承知で取り組めばいい勉強が出来ると思います。

標準化について(ミドルウェア編)

標準化について(通信編)

標準化について、3回くらいに分けて感想を書きます。1回目は通信編で、OSIとTCPの話です。2回目は分散処理基盤(ミドルウェア)関連の話、3回目はモデリング言語の話、を予定しています。

最近の方はご存知無いと思いますが、昔は通信の標準化活動といえばISOとCCITTが推進していたOSIだったのです。例によってWikipediaを参照します。

  1. 開放型システム間相互接続
  2. Open Systems Interconnection

このWikipediaのエントリで批判的コメントが書かれていますが、最終的には通信の標準はIETFで推進していたTCP/IPのスタックになりました。OSI側に参加した一人として、このあたりにコメントするなら

  1. ISO/CCITTの標準は権威を持っていますが、標準策定の参加者が限定的であったこと、開発速度が遅かったこと、種々の提案を取り入れたためにオプションを多く含む規格となり実装が困難になり(その結果、オプションを絞り込んだ機能標準という別の標準を作ることになりました)、また実装が出来た場合でも一般向けというより大企業向けのものとなることが多かったと思います。また、グローバル企業が世界各国からの代表にその企業の人を送り込むなどの良くない事例もありました。
  2. 一方IETFのTCP/IP関連標準化は、(実は企業がスポンサーだったとしても)個人レベルで参加でき、メーリングリストを活用して日々オープンな形で議論を進めたため、RFC開発の速度はかなり早いものでした。また(多少品質に問題があっても)実装例にアクセスも可能なことが多かったように記憶しています。TCP/IP関連標準化でスポンサー企業が付くケースでも、そうであることが比較的簡単に分るため、多くのその他の参加者にとって対処しやすかったのではと思います。

オープンな議論は発散する危険性も含んでいるものの、実際にやってみると、本当の専門家たちが集まることや運営方法に気をつけることで、機能することが証明されたのだと思います。現在のオープンソース、オープンプロセスそしてオープンイノベーションなどの流れの源流(一部?)はこのあたりにあるような気がしています。

標準化について(通信編)