オブジェクト保持構造における各社アプローチ

一般的な業務アプリケーションと比べてIdM製品のデータの持ち方（構造）で一番特徴的なのが「データを縦に持つ」という点だと思います。

意味がよくわからないと思いますので具体的な例を挙げますが、通常データベースのテーブルを設計する際は、

ID	displayName	telephoneNumber
001	Scott McNealy	123-456-789

という様にデータを横に並べて1レコードが1エントリという構造にします。
これは視覚的にもわかりやすいですし、昔からアプリケーションはレコード単位で処理を行うことが容易な形でライブラリなどが作られてきたためです。

しかし、このデータ構造の弱点としてレコードへの属性（列）の追加／削除／変更という作業が発生した場合、アプリケーションそのものへの影響がとても大きい、という点でした。
そのため、設計段階での仕様固めが非常に大切でした。

しかし、IdMやディレクトリ分野においては割と気軽に属性の追廃改が行われがちですし、製品としてあらかじめハンドリング可能な属性を固定的に決めてしまうことはできません。
特にIDライフサイクル管理という意味でのIdMに関しては接続先システムの増減により必要となる属性が変化するのは日常的な話と言えるでしょう。

その点、LDAPのデータ構造は理にかなっていて、objectClassの追加により割と自由に属性を持つことができます。ゆえにNovellやExgenなどのIdM製品はレポジトリにLDAPを選択しているのだと思います。
ただ、やはりビジネスロジックを実装する上でLDAPだと限界があるのも確かなので、RDBにこだわるベンダもいて、インテックの結人／束人やSAP（旧MaXware）はパフォーマンスに問題が出るのを承知で無理やり縦構造のテーブルを作ったりしています。

ID	属性	値
001	displayName	Scott McNealy
001	telephoneNumber	123-456-789

マイクロソフトのFIM（ILM）に関してMetaverseの構造は別の機会に解説するとして、FIMが新しく利用するようになったWebサービスにおいても同様の思想が継承されており、WS-TransferでハンドリングされるResourceも以下のような拡張がされています。

■一般的な形
<Person>
<displayName>Scott McNealy</displayName>
<telephoneNumber>123-456-789</telephoneNumber>
</Person>

■拡張形（Transfer Extension for Identity Management Operations/TEIMO）

<PartialAttribute>
　<AttributeType>displayName</AttributeType>
　<AttributeValue><rm:displayName>Scott McNealy</rm:displayName></AttributeValue>
　<AttributeType>telephoneNumber</AttributeType>
　<AttributeValue><rm:telephoneNumber>123-456-789</rm:telephoneNumber></AttributeValue>
</PartialAttribute>


このように各社さまざまなアプローチで製品としてはどんなデータが入るかわからない器の実装をしているようです。

さて、最近はなかなか時間がとれなくて実験らしいことができていませんので、そろそろ久しぶりにFIMを触ってみようかと思います。Webサービス周りのアーキテクチャの整理もまだできていないので、そのあたりの整理もかねて。。。