ICSOCとは「International Conference on Service Oriented Computing」の略で、サービスオリエンテッドコンピューティングと呼ばれる分野を取り扱う学会です。
http://cgi.cse.unsw.edu.au/~soc/icsoc08/

2002年から開催されている、比較的新しい学会のようです。

サービスオリエンテッドコンピューティングとは、

ソフトウェアアプリケーションの設計・構築・配布・消費の方法を変える分散コンピューティングのための、新しい学際的なパラダイム
（Service oriented computing is an emerging cross-disciplinary paradigm for distributed computing that is changing the way software applications are designed, architected, delivered and consumed.）

を指すみたい。（日本語訳まずくてごめんなさい）。

「Call for Research Papers」を読んでみたところ、以下の分野に関する研究発表・論文を募集しているようです。
（メモ代わりに書きましたが日本語訳まずいところたくさんです。ごめんなさい）

• サービス基盤（Service Foundations）
• サービスの概念の、形式的で明確な定義（Formal and precise definitions of the notion of service）
• サービスのためのモデル技術と規格（specification and modeling techniques for services）
• モデル駆動のサービス開発（model-driven service development）
• 機能的、非機能的な品質の側面（functional and non-functional quality aspects）
• 形式的な組織の関係（formal composition relations）
• リスク査定と品質保証（risk assessment and quality assurance）
• 改良とリファクタリング（refinement and refactoring）
• プログラミング・実行モデル（programming and runtime models）
• 互換性と適合性チェック（compatibility and conformance checking）
• セキュリティと信頼性（security and trust）
• 変更管理（change management）
• ビジネスサービスモデリング（Business Service Modeling）
• ビジネスゴールと要件のキャプチャリングのための方法とツール（Methods and tools for capturing business goals and requirements）
• ビジネスサービスへの分解（decomposition into business services）
• ビジネスプロセス（business processes）
• ビジネスポリシー（business policies）
• ビジネスモデリング（modeling）
• ビジネス解析（analysis）
• ビジネスシミュレーション（simulation）
• サービスを用いたシステムの統合システム（Integrating Systems of Systems using Services）
• 統合アーキテクチャのための解析・設計技術（Analysis and design techniques for integration architectures）
• サービスとSOAのためのアーキテクチャとデザインパターン（architectures and design patterns for services and SOAs）
• 連合した認証と権限（federated authentication and authorization）
• データとサービスの分散（data and service distribution）
• ストレージと計算の仮想化（virtualization of storage and computation）
• 分散SOAのポリシー管理と統治（policy management and governance in distributed SOAs）
• サービスのライフサイクル管理（service-lifecycle management）
• サービス統合オントロジー（service integration ontologies）
• 変更管理（change management）
• サービスのモビリティ（mobility of services）
• サービスエンジニアリング（Service Engineering）
• サービスの記述（service description）
• 発見（discovery）
• コンフィグレーション（configuration）
• サービスマイニング（service mining）
• サービス開発・管理・検査・検証のための手法・ツール（service mining, methods and tools for service development, governance, verification and validation）
• サービスに関する情報誘出（information elicitation about services）
• サービスの告知（service advertisement）
• 意味ベースのサービス発見（semantics-based service discovery）
• 組織化されたサービスの発見（orchestration discovery）
• 制約のある仕様・施行（constraint specification and enforcement）
• サービスの構築（Service Assembly）
• サービスの開発と発見（Service development and discovery）
• サービス構成アーキテクチャ（service composition architectures）
• サービス・リソースのレジストリと関連づけられたメタデータ（service and resource registries and associated metadata）
• サービスの起動・通知のための標準・技術（standards and technologies for service invocation and notification）
• 意味的なマッチング・契約・交渉（semantic matching, contracting and negotiation)
• 構築のための展開戦略（deployment strategies for assemblies）
• サービスの配布とインストールのための戦略とアーキテクチャ（strategies and architectures for service delivery and installation）
• 展開トポロジと関連づけられたメタデータ（deployment topologies and associated metadata）
• サービスのバージョニングとアップデート（service versioning and update）
• サービス管理（Service Management）
• サービスに関連したデータの集合（Instrumentation and service-related data aggregation）
• エンドツーエンドの測定・解析・キャパシティプランニング（end-to-end measurement, analysis, modeling and capacity planning）
• 展開トポロジの定義（definition of deployment topology）
• インフラのコンフィグレーション（infrastructure configuration）
• SOAのための問題測定（problem determination for SOAs）
• Information Technology Infrastructure Libraryのプロセス（ITIL processes）
• ライブシステムでの変更管理（change management in live systems）
• サービスの移動（service migration）
• サービスのモビリティ（service mobility）
• SOAのランタイム（SOA Runtime）
• 仲介・変形・ルーティングためのESB（Enterprise service bus for mediation, transformation and routing）
• 実行時の開発とサービスの登録（runtime development and service registries）
• レガシーアプリケーションの統合（integration of legacy applications）
• SOAアプリケーションと実行時の再コンフィグレーション（SOA adaptation and runtime reconfiguration）
• データアクセス・データ統合・スケーラビリティ・トポロジ・最適化のための情報サービス（information services for data access and data integration, scalability, topology and optimization）
• サービス指向のミドルウェア（service-oriented middleware）
• ポリシーベースの設定と計算負荷管理（policy based configuration and workload management）
• QoS（Quality of Service）
• 信頼性の高いサービス指向コンピューティング（Reliable service-oriented computing）
• サービス指向コンピューティングにおけるセキュリティとプライバシー（security and privacy in service-oriented computing）
• SLAとポリシー仕様と制定（SLA and policy specification and enactment）
• QoSネゴシエーション（QoS negotiation）
• サービスレベルの自律的な管理（autonomic management of service levels）
• 経験的な学習とQoSのベンチマーキング（empirical studies and benchmarking of QoS）
• SoAにおける性能と信頼性予測（performance and dependability prediction in SOA）
• サービスアプリケーション（Service Application (Grid, E-science, Government, etc.)）
• 下部構造資源の管理のためのサービス・アーキテクチャ（Services and architectures for management of infrastructural resources）
• データ・計算に集中したアプリケーション（data- and compute-intensive applications）
• ジョブスケジューリングのための実行と資源割り当てサービス（execution and resource allocation services for job scheduling）
• 複数資源管理の連携のためのプロトコル（protocols for coordination across multiple resource managers）
• ビジネス価値ベースの割り当て（business-value based allocation）
• センサーと作動装置情報の獲得と散布（acquisition and dissemination of sensor and actuator information）
• プロトタイプシステムとツールキット（prototype systems and toolkits）
• サービスのビジネス・経済的側面（Business and Economical Aspects of Services）
• サービスとその展望のためのビジネス価値の見積もり（business value estimation for services and service landscapes）
• サービスの移行に関して（in connection with service migration）
• サービスの切断操作（disconnected operation of services）
• モバイルサービスの発見とアクセス（discovery of and access to mobile services）
• サービスネットワークの社会的側面（social aspects of service networks）
• 仮想的な企業や組織の生成・管理のための革新的な戦略（innovative strategies for creation and management of virtual enterprises and organizations）

「サービス」という単語が頻繁に登場しています。
SOAにおけるサービス（人間にとって意味のある処理の最小単位）と同義でしょうか？

今までの自分の研究分野とは少し違った学会なので、こんな研究もあるのか！と少しびっくりした感じです。
自分にとって新しい分野に積極的に出て行くことができたらな、と思います。

BPEL4Peopleとは

BPEL4Peopleとは、「BPEL for People」、つまり人間のためのBPELのことを指します。

BPELは本来、SOAの概念を実現するためにWebサービスを連携させて一つのシステムを構築する際の、Webサービスの連携フローを記述するために用いられるXMLベースの言語です。

しかし、多くのシステムの稼働時では、人が参加して作業を実行したり確認したりすることが多くなっており、Webサービス同士の連携のみ記述できるBPELではシステムの動作・仕様を正確に表現することが難しくなってきたようです。

そこで、人の行動・アクティビティもWebサービスと同じようにサービスとして統一的に記述することができる、BPEL4Peopleが開発されました。
人の行動をサービスとみなし、それらを含めたWebサービス同士の連携を記述可能とすることで、より詳細、正確なSOAに基づいたシステムが構築可能になるようです。

まとめ

人の行動もサービスとして統一的に記述するというBPEL4Peopleのアイデアに非常に関心を持ちました。

イレギュラーな行動をする可能性がある人をサービスとみなすことをは、非常に難しいことだと思います。
しかし、これが実現されると、世界でもっとも知的なサービス（人をサービスとみなしたもの）を既に存在するWebサービスと連携して利用することが出来るようになります。

これはすごい。
実用化例はあるんでしょうか？気になるところです。

自分の研究でも利用したいと思うので、下記の仕様書をより詳しく読んでみたいと思います。

• WS-BPEL Extension for People

参考文献

• ITベンダーら6社、SOA環境でのBPMを拡張する「BPEL4People」仕様発表 | エンタープライズ | マイコミジャーナル
• dev2dev： BPEL4People
• InfoQ: OASIS入りを目指すBPEL4PeopleとWS-HumanTask

SOAとは

SOAとは、システム全体を「サービス」と呼ばれる部品を組み合わせることによって構築しようという手法、およびシステムアーキテクチャのことを指します。

部品を組み合わせてシステムを構築する手法は、オブジェクト指向などが従来にも存在していました。
それらの従来手法とSOAの違いは、組み合わせる部品（SOAにおけるサービス）の定義にあります。

SOAにおけるサービスは、実際に人間にとって意味のある単位を最小単位としています。
「人間にとって意味のある」というのは曖昧な表現ですが、しばしば業務上の処理単位を示しているようです。
（注文受付、在庫確認、発注処理など）

つまりSOAとは、人間にとって意味のある業務上の処理を単位としてサービスを定義し、それらを組み合わせることで一つの大きなシステムを作り上げることのことを指すのでしょうか。

SOAにおけるサービスは、グローバルに公開され、組織外における利用も想定されているため、標準的な技術によって実現、呼び出し可能であることが必要です。
サービスの呼び出し方法・インタフェースとして、しばしばWebサービスが利用されるみたい。
Webサービスは、XML、SOAP、WSDL、UDDIなどの標準的な技術によって構成されるので、SOAのサービスが満たすべき条件はクリアしていますね。
サービスの処理部分は何で実装されていても（Java or .Net or その他）いいようです。

また、複数のサービスを連携して一つのシステムを作り上げる必要があるため、それらの連携を記述する方法も標準化されている必要があります。
連携手順の記述言語としては、BPELと呼ばれるXMLベースの言語が用いられるみたい。
BPELは、BPMNという表記法によって図として作成することができ、視覚的に簡単に作成可能だとか。

まとめ

少し勉強した感じですが、すごく便利そうな概念ですね。
実際に世の中にSOAの考え方で構築されたシステムってどのくらい稼働しているんだろう。

あと、業務システムだけじゃなく、たとえば家電機器の連携に使ったりしても面白いんじゃないかと思いました。
既に研究されているような気もしますが。

新しいことを勉強するのってすごく楽しいですね。
これからも色々勉強したことをメモしていきまーす。

参考文献

• サービス指向アーキテクチャ – Wikipedia
• ＠IT情報マネジメント用語事典 [SOA (service-oriented architecture)]
• IT用語辞典 e-Words ： SOAとは 【サービス指向アーキテクチャ】 (Service Oriented Architecture) ─ 意味・解説
• IBM WSDD | SOA入門 - Japan

参考書として指定されているのは以下の2冊です。

やさしいコンピュータ科学 (Ascii books)
	Alan W. Biermann 和田 英一 ASCII 1993-06 売り上げランキング : 93388 おすすめ平均 やさしくて面白い プログラミングの入門に やさしい？？コンピューター科学 Amazonで詳しく見る by G-Tools

情報科学の基礎理論 (21世紀を指向した電子・通信・情報カリキュラムシリーズ)
	上林 弥彦 昭晃堂 1997-05 売り上げランキング : 465044 Amazonで詳しく見る by G-Tools

「やさしいコンピュータ科学」のプログラミング言語入門の項で使用されている言語は「Pascal」です。
実際にさわったことはないので、少し勉強する必要があるかもしれません。

勉強がんばるぞー！

ソフトウェアエージェントとは、ユーザとユーザ、ユーザとソフトウェア、ソフトウェアとソフトウェアの間で仲介的な役割を果たすソフトウェアを示す言葉だそうです。

ソフトウェアエージェントの定義は人によってまちまちみたいなのですが、その中でも共通する要素として、以下が挙げられるみたい。

• 永続性

  ソフトウェアエージェントは常に起動された状態で、何かの処理を行う時期を自分自身で判断します。

• 自律性

  ソフトウェアエージェントは、種々の判断・行動を人間の手を借りることなく実行することができます。

• 社会性

  ソフトウェアエージェントは、ほかのエージェントやソフトウェアと協力し、一つのタスクを協調して遂行することができます。

• 反応性

  ソフトウェアエージェントは、自分の周りの環境を検知することが可能で、環境の変化にも柔軟に対応可能です。

上の4項目をみると、永続性・自律性を満たすソフトウェアは結構ありふれた存在のように感じます。
一方、社会性・反応性を十分に満たしているソフトウェアはあまり無い感じがするので、ソフトウェアエージェントという概念を説明するために重要な概念かもしれません。

ソフトウェアエージェントから派生する概念がいくつかあるみたいなんですが、ここでは4つだけ紹介します。

• 知的エージェント

  タスクの実行結果をよりよいものにするために、個々のエージェントが学習したり推論したりします。
  要は人工知能のようなものを備えたエージェントのことを指すのでしょうか？
  

• 自律エージェント

  ある目標を達成するための方法を、自分で考え出し、さらにその方法を実際に利用できるエージェントを指すみたいです（人間の手助けなしで）。
  エージェントが学習できる必要はあるはずなので、知的エージェントと重複する部分があるのかもしれません。

• マルチエージェント

  エージェント単体では目的を達成できないのですが、ほかのエージェントと協調することで目的を達成可能とするエージェントを指すみたいです。
  実装しようとすれば、サーバクライアントシステムではなくて、P2Pシステムになる感じ？
  マルチエージェントシステムを実現するためのフレームワークとしてGNUBrainというものがあるそうです（リンク先は現在PHPのエラーが出ているため閲覧不可orz）。

• モバイルエージェント

  実行環境（コンテキスト？）とともにコンピュータからコンピュータへと移動し、移動先のコンピュータでも動作することができるエージェントを指すみたいです。
  まさに移動するソフトウェア。
  モバイルエージェントを利用したP2PプラットフォームとしてPIAXがあります。

個人的には、マルチエージェントとモバイルエージェント、あるいはそれらを組み合わせたようなシステムに非常に興味があります。
どうやら「マルチモバイルエージェント」という言葉があるみたい。
今度調べます。

今回は完全にWikipedia情報を鵜呑みにしてしまいましたが、今後は論文も少しずつ読んでいって、エージェントに関する理解を深めていきたいと思います。
自分の知らないことを調べたり勉強したりするのっておもしろいですね！

僕は現在、利用可能なネットワーク・コンピュータ環境が異なる地域間においてWebコミュニケーションを行う場合の問題を解決するための研究を行っています。

利用可能なネットワークの帯域幅が狭い地域の人々は、インターネットからファイルを取得するのに比較的時間がかかってしまいます。
その問題をP2Pネットワーク技術により解決したいと考えています。

回線速度が遅い地域のファイル取得時間を、できるだけ速い地域の取得時間に近づける「インフラ」（と呼んでいいのかは微妙だけど・・）を作ることを修士論文研究の目標としています。

博士課程は、異文化コラボレーションを研究している、石田・松原研究室に進学したいと考えています。

「コラボレーション」とは「コミュニケーション」とは別のことを指している言葉で、コミュニケーションによって何かを生み出すための協調作業を行うことです。
石田・松原研究室では、異なる文化を持つ人々がコラボレーションを行う場合に生じる種々の問題を明らかにして解決する取り組みが行われているようです。

もし進学できたら、僕は（「異文化」の本質からは少し離れてしまうかもしれませんが）異文化コラボレーションを行う際のネットワークにおける問題点を明らか、解決するような研究に携わりたいと思っています。
インターネットガバナンスや情報格差などの問題点が存在する中で、どのようにすれば異文化・異地域間コラボレーションを上手く行えるのか、について考えていきたいです。

自分が好きなネットワークの技術を使って、異文化間・異地域間のコミュニケーション・コラボレーション問題を解決するための仕組み・システム作りに携われたら、すごく楽しそうですよね。

非常に大まかではありますが、現時点で考えている博士課程での研究内容はこんな感じです。
もっともっと具体的にする必要がありますし、もしかしたら根本からひっくり返る可能性もあります。

例えば、複数のエージェントが協調して回線速度の遅い地域に全力でできる限り速くファイルを送り届けてくれるエージェントシステムを作るとか、そんなことが今日ボケッとしていたときに思い浮かんだんですが、研究としてはどうなんだろう・・・--;

それでも、今考えていることをどこかにアウトプットしておきたかったので書いてみました。
もっと研究頑張らないと・・！

基本的な方針は以下の通り。

• 家の外にあるPC（外部PC）から自宅のVPNサーバに接続
• 外部PCは自宅LANの仮装的なハブに接続する感じ
• 外部PCは自宅LANと同じネットワークアドレスをもらえる
• 「外部PC→自宅LAN内PC」アクセス可能
• 「自宅LAN内PC→外部PC」アクセス可能
• 別々に接続した外部PC同士も通信可能

これが実現できたら凄く便利そうですよね。

それでは自分用メモということで、作業内容を書いていきたいと思います。
今回はサーバ編ということで、サーバの設定作業が完了するまでの記録です。
クライアント編はまた後日、別エントリーとして作成したいと思います。

以下のページを参考にさせていただきました。ありがとうございました。

• VPNサーバー構築(OpenVPN) - Fedoraで自宅サーバー構築
  
• OpenVPN - KUeda's Wiki @ NIS Lab.

1. 必要なものをaptでインストール

まず、以下のファイルがサーバ上に存在するかどうか確認します。

/dev/net/tun

無事見つかったらaptによりopenvpnをインストールします。（ついでにopensslもインストール。）

# apt-get install openvpn openssl

次に、サーバにブリッジ用の仮想的なネットワークインタフェースを作るためのbridge-utilsをインストールします。

# apt-gtet install bridge-utils

2. ブリッジの作成

ブリッジを作成することで、VPN接続した外部PCを、あたかも自宅LANのスイッチングハブに繋いだかのように扱うことができるみたいです。

ブリッジを作成する前に、一旦サーバのネットワークを落としておきます。

# /etc/init.d/networking stop

次に、/etc/network/interfacesを以下のように書き換えます。（アドレス関係は各自読み替えてください）
この設定により、br0（ブリッジインタフェース）で、eth0（実際に自宅LANと繋がっているインタフェース）とtan0（VPNで外部PCが接続するインタフェース）をブリッジすることができるようです。

auto lo
iface lo inet loopback
allow-hotplug eth0
auto eth0
iface eth0 inet static
auto br0
iface br0 inet static
       address 192.168.3.210
       netmask 255.255.255.0
       network 192.168.3.0
       broadcast 192.168.3.255
       gateway 192.168.3.1
       bridge_ports eth0 tap0
       pre-up /usr/sbin/openvpn --mktun --dev tap0
       pre-up /sbin/ifconfig tap0 0.0.0.0 promisc up
       pre-up /sbin/ifconfig eth0 0.0.0.0 promisc up
       pre-up /usr/sbin/brctl addbr br0
       pre-up /usr/sbin/brctl addif br0 eth0
       pre-up /usr/sbin/brctl addif br0 tap0
       post-down /usr/sbin/brctl delif br0 tap0
       post-down /usr/sbin/brctl delbr br0
       post-down /usr/sbin/openvpn --rmtun --dev tap0
       post-down /sbin/ifconfig eth0 down

設定が終わったらサーバのネットワークを起動します。

# /etc/init.d/networking start

ifconfigを実行し、br0に自宅LANのアドレスが割り当てられ、eth0とtan0に関する情報が表示されれば、一応ここまでは設定成功です

3. IPフォワードの設定

ブリッジを正常に機能させるためには、あるネットワークインタフェースで受信したパケットを別のネットワークインタフェースから送信できるようにしなければなりません（IPフォワード）。

有効にするため、/etc/sysctl.confに以下を追記します。

net.ipv4.ip_forward=1

さらに以下のコマンドを実行し、設定を有効にします。

# sysctl -p /etc/sysctl.conf

一旦サーバを再起動し、以下のコマンドを入力して「１」と表示されれば設定完了です。

4. 証明書の作成

次に、VPNサーバ構築・VPN接続に必要な証明書群を作成します。

まずはじめに、簡単に鍵・証明書が作成できるツール群をわかりやすい場所にコピーします。

# cp -r /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn/
# cd /etc/openvpn/easy-rsa/

次に、鍵生成用の環境設定ファイルを編集します。（設定内容は各自読み替えてください）

# vi vars
export KEY_COUNTRY="JP"
export KEY_PROVINCE="OSAKA"
export KEY_CITY="HIRAKATA"
export KEY_ORG="hoge.com"
export KEY_EMAIL="hogehoge@hoge.com"

編集が済んだら、以下のコマンドを実行し、設定を反映させます。
さらに証明書作成ツールの初期化も行っておきます。

# source vars
# ./clean-all

下準備が終わったので、まずCAの証明書、および秘密鍵を作成します。
以下のコマンドを入力し、生成ツールを起動します。
何度か入力を求められますが、全て空ENTERで結構です。

# ./build-ca

作成が完了したら、以下のコマンドを実行し、作成した証明書を適切な場所に移動させます。

# cp keys/ca.crt /etc/openvpn/

次は、サーバの証明書および秘密鍵の作成です
以下のコマンドを入力し、生成ツールを起動します。
こちらも基本的に全て空ENTERでよいのですが、何カ所か入力すべき場所があるようなので要注意です。

# ./build-key-server server
Common Name (eg, your name or your server's hostname) [server] 【「server」と入力】
Sign the certificate? [y/n]: 【「y」と入力】
1 out of 1 certificate requests certified, commit? [y/n] 【「y」と入力】

作成が完了したら、以下のコマンドを実行し、作成した証明書を適切な場所に移動させます。

# cp keys/server.crt /etc/openvpn/
# cp keys/server.key /etc/openvpn/

次に、Diffie Hellmanパラメータというのを作成します。
作成が完了したら（時間が掛かる）、先ほどと同じように適切な場所に移動させます。

# ./build-dh
# cp keys/dh1024.pem /etc/openvpn/

最後に、以下のコマンドを実行し、TLS認証鍵を生成します。

openvpn --genkey --secret /etc/openvpn/ta.key

5. OpenVPNの設定

ようやくOpenVPN自体の設定に移ります。

以下のコマンドを実行し、設定ファイルの作成・編集を行います。

# vi /etc/openvpn/server.conf
port 1194 # 使用するポート

proto udp # 使用するプロトコル

dev tap0 # 使用するデバイス。今回はLayer2をエミュレート

ca ca.crt # 使用する証明書 
cert server.crt
key server.key 
dh dh1024.pem

ifconfig-pool-persist ipp.txt # クライアントに割り当てられたIPアドレスを管理するファイル

server-bridge 192.168.3.210 255.255.255.0 192.168.3.220 192.168.3.230 # 超重要、[サーバのIPアドレス] [サブネットマスク] [クライアントに割り当てるIPアドレスの範囲（開始）] [範囲（終了）]

client-to-client # クライアント同士の接続を許可

keepalive 10 120 # タイムアウト対策

tls-auth ta.key 0 # tls認証を有効化

cipher BF-CBC        # Blowfish (default)

comp-lzo

user nobody # OpenVPN実行権限を下げる
group nogroup
persist-key
persist-tun

status openvpn-status.log # ログの出力先
log         /var/log/openvpn.log
log-append  /var/log/openvpn.log

verb 3 # ログの出力レベル

udp-mtu 1400 # mtuの設定

6. OpenVPNの起動、仕上げ

上記の設定がすべて終わったら、ようやくOpenVPNの起動を行うことができます。
以下のコマンドを実行し、OpenVPNを起動します。

# /etc/init.d/openvpn start

無事起動したらとりあえずサーバの設定は完了です。

最後に忘れずに自宅のルータのポートフォワーディングの設定をします。
僕の環境だと、1194番ポート宛のUDPパケットを192.168.3.210に転送するように設定しました。
みなさんの環境にあわせて設定してみください。

7. まとめ

なんとかOpenVPNの稼働までこぎ着けました。
少し長くなってしまいましたね・・・。

もしかしたら誤った記述などあるかもしれません。
発見された方は、ここぞとばかりにコメントしていただけると、こちらとしても嬉しいです。

次回は、実際に外部のPCがVPN接続するまでを書きたいと思っています。

よろしくお願いしまーす。

大会の概要は以下の通り。

(１) 参加チームは、本委員会の監視チーム、および審査委員のもとで本コンテストを実施します。
(２) 参加チームは、各仮想企業の情報セキュリティ担当部署を演じていただき、提供されたインシデントの発生したシステム環境を調査し、かっこよく対応していただきます。
(３) 当該システム環境には、あらかじめ監視チームにより、インシデントあるいはこれを発生させるためのセキュリティホールが内包されています。
(４) 参加チームには、事前に当該システム環境と運用のフレームワーク概要をお知らせします。
(５) Bot系ツール、フィッシング、DoS（サービス不能攻撃）、パスワード走査と侵入、SQLインジェクション等、経路アナウンスの妨害など、さまざまなインシデントを想定してください。
(６) 監視チームは、ネットワーク上のトラフィック監視を中心に参加チームの対応状況を把握するとともに、顧客あるいは外部ユーザーを演じて適宜問い合わせや苦情のメールを送信します。
http://www.sccs-jp.org/SCCS2008/sccs03.html

五つの教育機関から五つのチームが出場し、それぞれが一つのブース（ネットワークやサーバが設置されている）を担当します。

一体何を競い合うのかというと、

• 復旧までの時間
• インシデントの対応手法
• 上司への報告・提案

の３つが主な評価指標だったと思います。
これらを総合的に判断し、どのチームが一番かっこよく対応できたかを決める大会です。

僕が参加した同志社大学チームは、過去2大会で最優秀賞を頂いているチームです。（僕は昨年度の大会から参加）
今年はやはり、3連覇という気持ちの良い数字がかかっていることと、僕は今年で卒業してしまうこともあってか、「絶対に最優秀賞を頂いてみせるぞ！」と意気込んで、それなりにたくさん準備をして大会に臨みました。
結果、苦しみながらもなんとか最優秀賞（Best Award 賞）を頂くことができました。

表彰式で講評を頂いたのですが、その中で最も嬉しかったのが、前回課題とされいたことが克服できていたと評価していただいたことです。

前回は、

• ネットワークに弱い（実はそうでもなかったのですが、実力を発揮できずorz）
• トラブルチケット（上司への報告）が最悪（前々回も同じ評価）

という評価を頂いていました。
この2点（特にトラブルチケット）を改善するのがチームの一員としての僕のテーマであったので、感無量になってしまいました。
ありがとうございます。

このような手の掛かる大会を主催されている方々は、本当に大変だっただろうなと思います。
主催者の皆様の血のにじむような準備のおかげで、僕たち参加者は素晴らしい経験をコンテストを通して得ることができました。
この場をお借りして、感謝の言葉を述べさせていただきます。
ありがとうございました。

もう少し時間があるので、僕たちのチームはどのようなことを考えて準備をしたか、について差し支えない程度に一部だけ紹介したいと思います。
（まずかったらすぐ消します）

１．トラブルチケットをできるだけ詳しく

トラブルチケットはできるだけ詳しく、詳しすぎるほど詳しく書いた方が良いみたいです。
（実社会においてはどうなのかわかりませんが、少なくともコンテストにおいては）

駄目なトラブルチケットの例を挙げますと（実際に一昨年の第1回コンテストで作成したチケット）、

Open Date: 2006/05/27 14:59
Close Date: 2006/05/27 15:11
報告者：hoge
担当者：hoge
内容：hogehoge（有）トップページにて、再び改竄を確認
対応：
調査したところWebDAVが有効になっていることを確認
http.confで阻止

こんな感じになります。
これだと、

• トラブルの具体的な内容がわからない。事細かに書くべき。
• 「調査したところ」でとあるが、担当者がいつ・何を考え・どのように調査したのかわからない。
• WebDAVが有効になっていることが何故問題なのかがわからない。
• 「http.confで阻止」とあるが、何をどう対処したのか全くわからない。
• 今後同じトラブルが起こらないようにするにはどのようにすればいいのかがわからない。

が問題になってしまうと思います。
これらの点をきちんとカバーできるチケットを書けるようになるためのトレーニングが必要だと考えます。

2. メンバー間における情報共有のためのインフラを作る

上で紹介したようなチケットしかかけなかった最大の理由は、「メンバー間の情報共有が上手くできていなかった」ことだと考えます。
そのため、メンバー間の情報共有をシームレスに行うためのインフラ・仕組みを構築して持って行くことが重要です。

具体的には、次のような情報の共有をメンバー間で行う必要があると思います。

• 時系列に並んだ各メンバーの詳細な作業履歴
• 各メンバーの状態
• 各メンバーの考えていること

これらの情報を、時を遡ってメンバー全員が閲覧することができたとしたら、トラブルチケットを書く人もかなり楽になります。

問題は、どうやってこれらの情報を共有するためのインフラを作るか、なのですが、実現するための手段としては数え切れないくらいあると思います。

もちろん、メンバー全員が常に詳細な情報をコンテスト中に発信し続ける必要がありますが、その手間を上回る効果があると考えます。

3. まとめ

上に挙げたのは、チームとして準備したことのほんの一部です。
他にいろいろと準備しなければならないことがたくさんあると思います。

そもそも、トラブルを解決できるだけの技術力がないと、情報を共有できたってらちがあかないですし・・・・orz

情報危機管理コンテストは、普段の大学・大学院生活ではほとんどの人が考えないようなことを真剣に考えることができる、素晴らしい大会だと思います。

僕は今年の大会で卒業してしまいますが、次回があれば、我こそはという人はエントリーしてみてはどうでしょうか？
貴重な体験が待っていると思います。

なお、「人気度」は単純にページビューの数で判断しています。

2008年5月の人気記事ランキング

1. [Java]ArrayListの中身をソートする（3回目：↑）
2. Mac OS X（Leopard）にXcodeをインストール（5回目：↓）
3. Mac OS X(Leopard)にTomcatをインストール（5回目：↑）
4. NS2をWindowsXP（Cygwin）にインストール（5回目：→）
5. [Struts]ArrayListオブジェクトの各要素をJSPで扱う（4回目：↑）
6. EclipseでStrutsの開発環境を構築する（4回目：→）
7. GSViewをWindowsXPにインストール（3回目：→）
8. Mac OS X Leopard + Proxy環境内でMacPortsを利用する（4回目：→）
9. Mac OS XにMySQL（5.0.51）をソースからインストール（5回目：→）
10. Mac OS X(Leopard)にphpMyAdmin 2.11 をインストール（3回目：↑）

まとめ

初登場のエントリーなし！
なんという動きのないエントリー。

最近のエントリーはアクセス数稼いでないです。
稼げるようなエントリーを書いていないんですが・・・。

集計開始以来、ずっと一位を保っていた「Mac OS X (Leopard)にXcodeをインストール」という記事が、要約一位から陥落しました。
いいことです。

６月の目標はこのランキングをごっそり変えてやることですね。
がんばるぞー！

最近ふと思ったのですが、大学（または大学院）の研究室の役割って何でしょう？

研究としての成果を出すこと？
学生を教育すること？
その両方？

答えとしては「両方」というのが適切なのでしょうか？

でも、両方っていうのはもしかしたらなかなかしんどいことかもしれません。
そうなったときに、どっちを優先するものなんでしょう。

僕個人の意見としては、大学や大学院はあくまでも教育機関であると思うので、やっぱり「教育すること」が最大の目的なんじゃないのかな？と思ったりします。
もちろん、社会に最も近い教育機関として、社会で最も必要とされる「成果」を求めることも重要なんだとは思いますが、「過程」も同じくらい、あるいはそれ以上に重要だと思います。

少し色々なことの効率が落ちたとしても、長い目でみればよかった、というようにするのが良いんじゃないかなぁ？？
現段階でもっとも効率のよいことをするよりも、色々な人に活躍の場を与えて将来的に効率が良くなるようにするのが良いと思います。

話は少しずれてしまいますが、最近小学校の先生で、生徒に「お前はどうしようもないくらい絵が下手だなぁ」と言う先生がいるようです。
ほんと、何を考えて教師をしているんだろうと思います。
子どもの芽を摘むようなことを教師がして、どうするんだろう。

小学生と大学生（院生）の違いはあれど、教育機関で学ぶ身としては基本的には同じような気がするんです。
できないからといって切り捨てるんじゃなくて、できないならできるようになるために一緒に頑張って考えることが必要なのではないでしょうか？

でも、やっぱり僕自身の経験が浅すぎるので何が正しいのかわからないです。
何も知らないのに、いろいろ書いても説得力ないですよね。

でも、今回はとりあえず今思ったことを書き留める意味で書いてみました。

教育の分野についても勉強してみたいと思います。

それと時期を同じくして、自宅サーバから毎日送られてくるはずのログファイルが突然送られてこなくなってしまいました。
結果として、当ブログに頂いたコメント・トラックバックに対するレスポンスが遅れてしまったりしました。
ごめんなさい・・

問題の原因は「OP25B」をeo光が導入していたことです。

OP25B　【Outbound Port 25 Blocking】
ネットワークの境界にあるルータなどの機器で、ネットワーク内から外部のコンピュータのTCPポート25番への通信を禁止すること。インターネットサービスプロバイダ(ISP)などが会員のパソコンからスパムメールが送信されるのをブロックするために行なっている。
OP25Bとは 【Outbound Port 25 Blocking】 - 意味・解説 ： IT用語辞典

このままでは色々まずいと思い、今日対策を施しました。
サーバの環境はFedora 6 + Postfixです。
メールサーバは稼働させていないのですが、sendmailの設定は複雑そうだったので、サーバのrootからのメールを送信するためだけにPostfixを導入しました。

OP25B環境でサーバがメールを送信するためには、eo光のSMTPサーバにプロバイダから与えられたID、パスワードを使ってログインした後、メールをそのSMTPサーバに転送する必要があります。

設定には以下のページを参考にさせて頂きました。
OP25B(Outbound Port 25 Blocking)対策 - Fedoraで自宅サーバー構築

以下、eo光に特化した（といってもほとんど変わりありませんが）設定方法を紹介します。

(1)Postfixの設定
スーパーユーザになって、以下のコマンドを入力し、Postfixの設定ファイルを開きます。

# vi /etc/postfix/main.cf

ファイルを開けたら、末尾に以下を追記します。

relayhost = [smtpauth.eonet.ne.jp]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/authinfo
smtp_sasl_security_options = noanonymous

(2)SMTP認証情報の設定
以下のコマンドを入力し、 SMTPサーバの認証情報を設定します。
ユーザ名とパスワードはプロバイダと契約したときの書類に書かれていると思います。
（メールアドレスをデフォルトのものから変更した場合、ユーザ名も変更されるので注意）

# echo [smtpauth.eonet.ne.jp]:587 ユーザー名:パスワード > /etc/postfix/authinfo
# chmod 604 /etc/postfix/authinfo
# postmap /etc/postfix/authinfo

(3)Postfix再起動
以下のコマンドを入力し、Postfixを再起動して設定を反映させます。

# /etc/init.d/postfix restart

(4)動作確認
以下のコマンドを入力し、rootからのテストメールが自分のメールアドレスに届いているかを確認します。

# echo test | mail root

まとめ

ようやく、サーバからのメールが自分宛に届くようになりました。

OP25Bはスパムメールが増える昨今、必要な技術だとは思います。
が、自宅サーバを稼働させている人にとっては少し設定が面倒だなぁ、と思いました。

何はともあれ、メールが届くようになってよかった！
めでたしめでたしです。

どうやら「評価」項目の書き方にもいくつかのパターンがあるみたいなのでまとめてみます。

1. 従来方式（システム）と提案方式の評価結果を比較し、良くなったこと、あるいは、悪くなったことについて述べる
2. 比較すべき従来方式が無い場合は、何らかのしっかりとした根拠により達成したい数値目標を定め、その値と提案方式のデータを比較する
3. 達成したい数値目標を論理的に導き出せない場合は、提案方式を使おうかなと考えている人が、データを見て使うか否かを判断できるように書く
4. 具体的なデータを取得できない場合は、考えられる複数の状況に従来方式と提案システムを適用した時に、どちらの方式の方が適しているのか、ということについて論理的に述べる
5. 比較すべき従来方式もなく、データも取れない場合は・・・・・わかんないです

こんな感じでしょうか？

評価の書き方について悩んでしまった場合、いったん落ち着いて上のパターンのどれかに当てはめて書くことはできないか、考えてみるのも良いかもしれません。

先ほどスパム以外のすべてのコメント・トラックバックを有効にさせていただきました。

コメント・トラックバックをしてくださった皆さん、申し訳ありませんでした。

なぜ、保留のまま放置してしまったかと言いますと、2月中旬頃にインターネットプロバイダをeo光に変えてからサーバから送られてくるはずのメールが届かなくなったことが原因だと思います。

完全に僕の管理ミスです。

今後はこのようなことが無いように楽しくブログを運営していきたいと思います。

本当に申し訳ありませんでした。

この間、「機器連携」という言葉は実際にはどういうことを指しているのか、ということについて考えたのでエントリーとして書こうと思います。

僕は、未定義機器（現在は世の中に存在していない、仕様が未知の機器）が、既存機器のみで構築されたネットワークに新たに接続された場合においても、機器連携を実現可能にするミドルウェアを、Jiniというミドルウェア技術を拡張することで提案しました。

僕が提案したミドルウェアは、機器の利用者は必ずGUIを利用してネットワークを介して機器を操作する、という制約を課すことで、既存機器が未定義機器に対応できるようにするものです。

でもゆくゆく考えると、GUIを利用して機器を操作することは「機器連携」とは呼ばないんじゃないか、そんな気がしてきました。

僕の考える「機器連携」は、人を介さない機器同士のインタラクションです。
少し例を挙げます。

ある家に、複数の音楽提供機器（オーディオコンポやPC、Musicサーバ）と複数のスピーカが存在し、それらがネットワーク（家庭内LANなど）で接続されていたとします。
そこの家の住人が、スピーカから出力される音の音質が気に入らず、ネットワークに繋げるだけで家中のスピーカの音質を向上させる小さな機器を買ってきました。
家について、買ってきた小さな機器を家のネットワークに接続するとあら不思議。
何の設定作業をすることなく、家中のスピーカから出力される音の音質が向上されました。

本当は、上に挙げたようなことが「機器連携」なのではないかと思うのです。

僕の提案したミドルウェアは、人がGUIを利用して操作するためコマンドを機器に対して送信しなければならない、という点で「機器連携」を実現できているとは言えず、あくまで「機器操作」のためのミドルウェアなのだと思います。

言葉の定義の問題なのかもしれませんが、これはホームネットワークに用いるミドルウェアを考える上でとても重要なことだと思います。

あー、もっと早く気づいていればよかったなーorz

僕にとっては初めての国際学会。
英語で上手く発表できるかどうか不安でしたが、今の自分の英語能力を考えるとベストを尽くせたと思います。
質問にもなんとか答えることが出来ました。

発表内容は以下のページで見ることが出来ます。
CNSR2008 — NISLab HOME

卒業研究として行っていた研究の内容について発表させていただきました。

質問では、
「あなたの提案システムと、W3Cで標準化が行われているWebサービスの発見方式は同じもの？」
という質問をチェアの先生にしていただきました。

僕はその質問に対して、
「私はW3CのWebサービス発見方式についてはよく知りません。ですが、それと私の提案方式は違うものです」
と答えました。
（実際はこんなに綺麗には答えられなかったけど・・）

頂いた質問は暗に、
「個々のミドルウェアでサービスの発見方式や未定義サービスへの対応方法などを考えるよりも、すでに標準化が行われているWebサービスの技術を使った仕組みを考えた方がいいんじゃない？」
という意味を含んでいるのかなと思いました。

このことについては、後日改めてエントリーとして書きたいと考えています。

英語を使ったプレゼンテーションを通して、度胸がついたのはもちろんのこと、英語を勉強することの必要性を実感できたなど、様々なためになる経験をすることが出来ました。
まだ、国際学会での発表を経験していない大学院生・学部生は、積極的に研究室の外の世界に飛び出して、色々なことを学んでいけたらいいのではないかと思います。

今回の発表で、卒業研究から大分引っ張っていたテーマも一段落。

あとは、修論のテーマを進めるべく突っ走ります！