orca次期fw開発の現状
Post on 02-Jul-2015
837 Views
Preview:
DESCRIPTION
TRANSCRIPT
ORCA次期フレームワーク開発の現状
株式会社ネットワーク応用通信研究所
2014年10月11日
自己紹介
前田 修吾
株式会社ネットワーク応用通信研究所取締役
一般財団法人Rubyアソシエーション事務局長
Rubyコミッタ
島根県松江市在住
1
現在のORCAの問題点
クラウドに適したアーキテクチャ・ライセンスになっていない
• Webに対応していない
• クライアントソフトウェアが必要
• 独自プロトコルによる通信のため、ネットワーク構成に制限
• マルチテナントに対応していない
• 診療所ごとに独立した環境を用意する必要がありコストが高い
• ライセンスがクラウドに対応していない
• 第三者が改変したものをクラウドで提供してもソースコードの提供義務がない
2
解決策(当初の案)
クラウド対応のためのアーキテクチャの刷新及びライセンス変更
• Web対応
• ブラウザがあれば専用のクライアントは不要
• 標準的なプロトコルの利用で様々なネットワークに対応
• マルチテナント対応
• 運用コストの低減
• ライセンスのクラウド対応
• 改変物をクラウドで提供した場合もソースコード提供義務を
3
Web対応
業務ロジックDB処理 画面定義
次世代フレームワーク
WebサーバDBサーバ
フレームワークで従来互換のインタフェースを提供しアプリケーションコードは従来のものを流用
サーバ
Webブラウザ
HTTPS通信
クライアント
クライアントライブラリ
サーバからJavaScript
クライアントライブラリを配布するため
専用クライアントは不要
4
マルチテナント対応
1台のサーバで複数のテナントに対応する
ことにより運用コストを低減
Webサーバ
DBサーバ
テナント毎に独立したDBを用意し
認証結果によって適切なDBに接続することでセキュリティを確保
DB
5
ライセンスのクラウド対応
従来のライセンスの問題点
• GPLの場合、第三者がソースコードを改変しても、クラウドサービスを提供するだけならソースコードの提供義務がない
クラウドに適したライセンスの採用
• AGPLを採用することで、第三者が改変したソフトウェアをクラウドサービスで提供した場合、ソースコードの提供を義務付けられる
6
ORCA次世代フレームワークの特徴
Rubyの採用
• Webアプリケーション開発に実績のあるRubyを採用
• サーバ増強によるスケールアウトが容易
• プログラム言語Rubyは国際規格(ISO/IEC 30170)
• (一財)Rubyアソシエーションによる保守体制
• 将来に渡って安心して利用できる環境
過去の資産の有効活用
• COBOLによる業務ロジック・SQL・画面定義データなどの過去の資産の有効活用で移行コストを低減
7
Ruby on Railsとの比較
Ruby on Rails ORCA次世代フレームワーク
汎用性高い
(Web全般に対応)低い
(業務システムに特化)
移行コスト高い
(全面的な作り直し)低い
(既存コードの流用)
性能要検討
(DB設計の方針から思想が異なるため)
高い(現在の性能特性+Rubyのスケールアウト技術)
8
と考えていましたが…
9
Web(HTML)化の問題点
操作性の違い
• キーボード主体 → マウス主体
先行入力の対応が難しい
10
方針の変更
クライアントは現在と同等のものを提供
• Webアプリケーション化は将来検討
ただし、プロトコルはHTTPベースに(クラウドとの親和性)
マルチテナントにも対応
11
サーバ構成
アプリケーションサーバ
DBサーバ
アプリケーションサーバ
アプリケーションサーバ
DBサーバ
クライアント
セッション管理サーバ
12
サーバ構成
セッション管理サーバ
• クライアントからの認証要求を処理し、セッションの管理を行う。
• テナント情報・ユーザ情報などのマスタ情報とセッション情報を保持する。
アプリケーションサーバ
• クライアントからの画面要求・イベント処理要求を処理する。
• クライアントはセッション管理サーバから指定されたアプリケーションサーバに毎回接続する。
DBサーバ
• アプリケーションのデータをテナント毎に別々のDBに保持する。
13
コードネーム
ginbee
• montsuqi(紋付)→ginbee(甚平)
14
開発方針
一般的なRubyのWebシステムと同じミドルウェア構成
• Passenger、Unicorn、Rackなど
既存資産を活用する
• MONTSUQIのライブラリ
• アプリケーションコード
• 画面定義
• 帳票定義
15
開発状況
2013年度
• フレームワークの基本部分の開発を完了
2014年度
• 認証の強化
• 印刷機能
• 日レセAPI対応
• 管理機能
• プログラム更新・マスタ更新
• カスタマイズ対応
16
認証の強化
セキュリティデバイスの利用を検討中
• USBトークン・ICカードなど
懸念事項
• 接続不良
• USBトークンが奥まで差さっていない
• デバイスロックの多発
• PINの誤入力が連続するとロックされる
• 導入費用
• 運用コスト
17
印刷機能
従来の日レセではサーバ側での印刷が多い
サーバ側で出力された印刷データを自動的にクライアントにダウンロードして印刷
18
日レセAPI対応
従来の日レセAPIと互換性のあるAPIを提供
認証などは変更の可能性
他のアプリケーション(クラウドサービス含む)から連携可能
19
管理機能
ベンダ・テナントなどの情報の管理
ベンダ向けの管理機能も提供
20
プログラム更新・マスタ更新
クラウド上で一括してプログラム更新・マスタ更新を行う
ベンダの負担を軽減
21
カスタマイズ対応
マルチテナント対応を考えるとできれば避けたい
NaClがサポートしている医院のカスタマイズ状況
• ほとんどの医院で何らかのカスタマイズをしている
ベンダ毎にカスタマイズした環境を用意し、特定のテナントのアプリケーションはその環境で動作させる対応
22
デモ
23
まとめ
ORCA次期フレームワークginbeeは
• クラウドに適したプロトコル設計
• マルチテナントへの対応
• クラウドに適したライセンスの採用
によって、クラウド環境におけるORCAの利用を促進します
24
top related