OpenID Tech Night Vol.6に出てきた

  • すいません。自分メモなので理解できておらずいい加減です。
  • Phill Wndley
  • Subject/Entity
  • Indentyty Attribute(自分情報)
    • 形式
      • 名前、男、日本
    • 属性
      • 所属、住所、アドレス
    • 関係性
      • 業務経歴
  • Web Identity Technology
    • インターネットで自分情報を安全に流通させ、サイト同士の連携を行う
  • OpenID OAuth
    • すぐ試せせる、Webと相性がいい
    • 2007 OpenID2.0
    • 2009 OAuth1.0
  • 認証と認可
    • 認証
      • あー誰
    • 認可
      • キミだったらいいよ
  • OpenID
    • 認証結果+属性情報を主にブラウザを介して安全に流通
  • OAuth
    • 認可

OpenID

  • Smart.fmの方
  • OpenIDでログイン
  • Atend
  • OpenID
    • ユーザーが使いたいIDを自由選択
    • 使いたいOpenID Providerを選んで認証
    • なんで使われてないOpenIDも使えるよ
  • OpenIDのフロー
    • OP選択
    • OP特定
      • 共通鍵でやり取り
  • Opを特定するDiscovery
    • 知らないIDだなー。
      • X-XRDS-Location指定
      • XRDSファイル
  • XRDSファイル
    • XMLでサイトのURLが入ってる。そこからOpenIDの認証を送る
  • RP Discovery
    • OpenIDログイン対応再ービスをWebブラウザが自動検出
    • サイトにアクセスしただけで特定できる
  • OpenID拡張仕様
    • 認証以外のことも拡張仕様を許可することで対応
    • OpenID Attribute Exchage
    • OpenID Oauth
  • OpenID AX
    • OP-RP間で属性情報を交換
    • RPがOPからユーザ属性を取得
      • RPは属性タイプ識別子(URL)を認証リクエスト内に列挙

AX

  • Yahooの方
    • 2008,1 リリース OpenID2.0対応
    • 2010 Attribute XChange
  • サーバ構成
    • フロントエンド(同意画面)サーバ
    • OpenIdサーバ
    • 属性情報 Y!プロフィールの専用DB
  • UA Rp OP
    • 同意画面
  • Attribute XExchange Flow
  • 提供している属性情報
    • 画像、表示名、姓、名
  • AX Request
    • 属性情報 requireで定義
  • AX UI
    • 同意画面
  • AX Response
    • 長すぎ
  • AX Spec
    • Assertion URLが長すぎる
      • 2000自以上だとPOSTに切り替え
  • Store Requsetいらない
  • UI Extension(POP)
  • UI Spece
    • ポップアップはなー
    • 450 500は厳しい
    • popup画面から導線に注意
    • 汎用的なUIが望ましい

Yahoo OpenIDランキング

  • Yahooの方
  • YOpenID利用ランキング
  • gameleom,smart.fm,fansaka.info,gilt
  • yahooだけのOpenIDに対応してるとランキング高い
  • 6.2%が外部ログイン
  • オープン化とプライバシー
    • ID連携&
      • AX(属性連携)、属性情報を提供
    • ID連携(OAUth)
      • 属性連携(Attribute API)
      • 決済連携
      • ポイント連携
      • OISIX
  • 課題
    • 大切な属性情報を渡す相手の外部サービスはどのように選ぶのか
    • ISMS、プライバシーマーク、とかね
    • 内部では独自ルールで判断してる
      • OIDF-Japanのつながりも期待
    • ログイン履歴、アラーととかあるんだよ

NTT IDログインサービス紹介

  • NTTコミュの方
  • 5/14から開始
  • NTTDocomo, れぞなんと、こみゅIDを束ねる
    • のべ7000万
  • セキュリティ面もケア
    • OpenIDのRPごとだしわけ
    • RP Discovery必須
      • RPごとの出し分けまでしてる
      • 名寄せ回避
      • RP Discoveryは必須
      • RPがないと警告出る
    • SSL必須
  • gooとかは対応してるよ
    • NTT IDでログインってボタンで画面遷移
    • 束ね画面で束ねる
  • インターフェイス仕様書(tech.html)
    • ロゴもいっぱいあるよ
  • RP Discoveryをできるようにしてね
  • RP毎にOpenIDの出しわけしてるからrealm変えないでね
今後
  • 対応サイト増やす
  • エンドユーザ増やす
    • 携帯対応

楽天事例

  • 楽天の方
  • パートナー向けの認証機能は楽天オリジナル
  • OpenID仕様だから導入の敷居は下がった
  • まだ非公開よ。。
  • 2008.10 あんしん支払いサービス OpenID
  • 2009,5 携帯も対応
  • 2010.4 OAuth Hybrid
  • OnGen
  • AXを利用してnickname渡しあってる
  • 携帯向け
    • シーケンスはOpenIDと同じ
  • Hybrid
    • 属性情報を取得
  • 利便性と導入のしやすい

Smart.fm

  • 70万ユーザの中で18万人がOpenID
  • OAuthにも対応
  • yahoo51 google24 mixi11 twitter6% facebook5%
  • 外部29%
  • OpenID使う理由
    • ユーザ登録をシンプルにしたい
  • OPenID拡張仕様も活用
    • Attribute Exchange
      • Gravater メアドにアバタくくりつけるサービス
    • Oauth Hybrid
      • ユーザレコメンド
      • Gmailのアドレスから友達をリコメンドしてる
      • twitter, facebookでもできるんだよ

OAuth

  • レゾナントの方
  • SocialWeb Japan
  • Google API Expert
  • マッシュアップ
    • はやってたよね
  • 認証を要するマッシュアップ
  • ベーシック認証だとセキュリティリスクあるよ
  • Twitpic
  • 間のサービスに渡すことがなく、サーバーにいける
  • クライアントにクレデンシャルを渡す必要がない
  • 連携してるクライアントを把握してるからサーバ側で停止できる
  • OAuthの危険
    • 認可の意味を把握せず利用される危険
    • 認可を行うことで、Twitterフォロアー全員にスパム
  • 署名が取れると安全だとみなされて認識される
OpenID/OAuth HyBrid
  • メリット
    • OpenIDを使ったログイン後にAPI連携簡単
  • デメリット
    • OAth/OpenIDバージョン変わるとまずい
    • 標準ライブラリでサポートないよ
OAuth Proxy, Open Social
OAuth Consumer Requset
  • ユーザ抜きで
xAuth

Auth Next

  • authentication,ax,page,outh hybrid
  • Artifact Binding
    • 携帯電話サポート
    • セキュリティ強化
    • 実装が容易
    • OP RPステートレス化
  • OAuth2.0
    • rapかな

ソーシャルアプリとは

  • mixi、モバゲー、GREEなどのSNSと連携するアプリ
  • ソーシャル性を生かして
  • インバイト、バイラルで人を呼べる
  • Google Open Socialにみんなのっとってる

開発会社にとってのSAP

  • 全く新しい、かつ巨大なマーケット
  • SNSの登録者数は1500万
  • それぞれのサイトに対してマーケットがある
  • Mobile,PCにもある

アプリへの集客

  • 広告など使って、普通に集客
  • 集客はアプリの設計次第

どのアプローチを選択するかでアプリの内容が決まる

  • 友達といっしょにやると楽しい、ソーシャル性を考えて作るのが大事

エンジニアにとってのソーシャルアプリ

PC
  • RailのViewは使用不可、フレームワークのViewは不可
    • Gadget API上でしかない。あくまでjs, flashを置くのがいい。
Mobile
  • RailsのViewは使える
  • JpMobile URLの書き換え使えばいいだけ

必要なこと

不要なこと

  • ユーザ認証
    • サイトのIDはわたってくる

OAuthを使用したAPIとの通信

  • RubyGemのoauth
    • 0.4.0
  • customer key
    • サイトが発行
  • endpoint
    • SNSごとに持ってるURL
  • Auth Tokenを取得する
  • ユーザのリクエスト中にアクセスする場合OAuth::TOkenが必要

注意

  • APIから取得したデータは24時間以内に消す
  • NicknameなどもAPIデータ扱い
  • ランキング表示などもニックネームがあると消さないといけないの
  • アプリ内のニックネーム別に持てば24時間以上持てるよ

URLの書き換え(URLエンコード)しないとね

  • Viewにハードコーディングしてらんない
  • シンプルに書くならhelperかなー

Gadget XMLの設置

  • サーバに設置
  • modulPrefsタグ
  • PCとMobile(endpoint書く)で違う

その他

  • バイナリデータダウンロードは不可
    • 着せかえ、着うた
  • 外部リンクは制限される
    • 結構SNSごとにうるさい
Mixi
  • SAPはじめてやったのはmixi
  • ソーシャル性重視
    • カテゴリその他になっちゃう
  • 全ユーザランキング、マイミク以外へのアクセスはmixiが望んでない。
    • ソーシャル性をマイミク内にしないと
  • すでにマーケットが成熟気味
  • CDNを使える
  • 個人でもアプリ出せる
  • 今は箱庭ゲーが多い
  • 課金APIは他サイトと仕様が異なる
  • モバイルは外部リンク禁止
モバゲー
  • ゲーム性重視
  • インパクト効果もあるが、広告による集客すごい
  • ロワイヤル系はもういらない
  • 収益手段が豊富(広告、アフィリエイト、アバター)
  • アバターは狙ったいったほうがいい
  • テキストはキャッシュとして保存可
  • API多すぎ
  • 勢いある
GREE
  • モバゲーと似ている
  • テキストデータは自サーバ保存できない、GREEから取るしかない
  • 初期ディベロッパ数をかなり絞ってる

全体的に

  • パートナーが違反したら、規約を変えることもある
  • そもそも公開できないこともある
  • やりたくなーい
    • アプリ内でのコミュニティ

各サイト比較

  • mixi
    • 個人OK
    • 外部リンク×
    • 課金：Atom形式、API独特の実装
    • テキスト：自サーバ保存
    • CDNあり
  • モバゲー
    • 法人のみ
    • 外部リンク制限つき○
    • 課金：JSON形式、他のAPI同様に使える
    • テキスト：自サーバにキャッシュ可能、24hで消去
    • アバター大きい
  • Gree
    • 法人のみ
    • 外部リンク制限×
    • 課金：JSON形式、他のAPI同様に使える
    • テキスト：むり
API
  • Peple
  • Activity
    • ユーザ行動に対して
  • Message
    • ユーザーからユーザへメッセージ
  • アプリ内データ
    • Persistence, Appdata
  • Payment
    • 全部ある
  • テキスト制限
    • 不要、textData,NGWord,Inspection
  • Black List
  • その他
  • ミログのサーバ
    • AWS EC2を使用
      • SAPの急激なユーザ数増加に対応
  • サーバへのデプロイ

サーバエンジニアにとってのSAP

  • 最初の一週間かなり大変！
  • ユーザ数が読めないとさらにそう
  • 予想外にユーザ増えると速攻で対応可能

質問

  • Railsいい？
    • 拡張のオーバーライドより、Rubyはそのまま使える。サブクラスいらないよ。
    • フレームワークの元に手を入れやすいんだよなー。
    • Rubyの拡張性
    • 各SNSの仕様の差分には対応しやすい
  • SAPでのRailsのプラグインある？
  • コンテナいて、テストが難しいよね。どーやってるの？
    • テストは確かにやりずらいよ
    • FireMobileSulmilter
    • ローカルでテスト駆動は絶対できないよー
    • テストっていうより動作確認かなー
  • パフォーマンス、Railsはボトルネックにならない
    • Railsは重い
    • 目的は開発速度、柔軟性、拡張性
    • アジャイル的な開発、全体作って、細かくアプローチ
    • クラウドだからサーバ増やしちゃうよ
    • キャッシュを使っちゃう
  • 開発分担は？
    • 1プロジェクト、デザイナー、flash、アプリ、サーバ
      • 2人(D, P)

Spring Integration

Java

EIP

    • 企業内システム統合パターンカタログ化
    • MOM(Message Oriented)
    • SOAの考え

EIP基本の考え

    • チャンネル
      • メッセージ交換先の抽象化、キューイング
    • メッセージ
      • ルールベース、メッセージ経路、抽象化
      • 様々なルールをサポート
    • ルーター
      • 束ねて、どのサーバに振ろうかという設定
    • トランスフォーマー
  • この４つによって成り立つ
    • 中央に集めて分配する

EIPのメリット

サンプル

    1. URL組み立て
    2. URLリクエスト、XML取得
    3. XML変換
    4. データをJavaオブジェクトへ詰める
      • これらをXMLでマッピングし、Springで標準化されたXMLメソッドで設定してセット

まとめ、メリット

Spring Batch

Java
  • ミッションクリティカルなバッチ向けフレームワーク
  • バッチプロセス管理(XMLによるプロセス管理、実行結果メタデータ管理)
  • スケーラビリティ(マルチスレッド、マルチプロセス)
  • 再利用機能提供(リソース管理、複数バッチランタイム環境サポート)
  • 開発者はビジネスロジックに注力できる

モジュール構成

  • Core
  • Infra

バッチ構成、ドメインモデル

  • 基本ドメインモデル
    • Job
      • ひとつのバッチ
    • Step
      • バッチプロセス単位、StepがまとまったのがJob
  • バッチプロセスUnitインターフェース
    • ItemReader
      • データ読む
    • ItemProcessor
      • データ変換
    • ItemWriter
      • 実行、ほとんどがこれだけ書けば間に合う
  • Batch コアインターフェース
    • Job Luncher
      • Job実行のためのランチャ
    • Job Repository
  • バッチ処理パターン

開発ポイント

    • Job/Step構成をXML定義ファイルに記載

導入時の考慮点

  • バッチプロセスの立ち上がりが遅い
  • ロードライブラリを最小化し、必要なライブラリだけロードする

まとめ、一番の成果

  • もともとのSpringフレームワークでつかっていたオンラインとビジネスロジックを共有化できる
  • バッチに必要なログ書き出しや、プロセス管理などのライブラリは揃っている
  • ただし、使う前に結構覚えること多いよ

Grails

Java
  • 山本さん
  • Grails徹底入門
  • JVMを前提としたGroovy、Springの混合。50% Java 50% Groovy

Grails哲学

  • 信頼された技術の上に構築する
  • 設定より、規約
  • Groovy DSLでDDDで開発
  • 柔軟さを犠牲にせずシンプルなアーカイブ
  • Springがラップされてよりシンプルになっている

GrailsはSpring

  • 形を変えたSpringMVC
  • プライグインの仕組みでSpringフレームワーク定義自動化
  • Spring Beanビルダー

Grailsはフルスタックフレームワーク

    • Hibernate, O/Rマップ
    • 表現豊かなView
    • Spring MVC
    • リロード可能なJava

Grails仕組み

Grailsプラグイン

  • コマンドでできるインストール
  • 活発なプラグインコミュニティ 400種類のプラグイン
  • 簡単開発
  • チーム開発向け

Grails機能

最新のGrails1.2

  • Spring3.0に対応
  • GSP(Groovy Server pages)
  • メソッド単位のTR
  • アノテーションエンティティ
  • パフォーマンス向上
  • 1.3もすぐでるよ。しかもかなりパフォーマンス改善してる