.NET用アプリケーション フレームワーク Open 棟梁 ＠ オープンソースカンファレンス 2015 Nagoya OSSコンソーシアム .NET開発基盤部会

1. .NET用アプリケーション フレームワーク Open 棟梁
＠ オープンソースカンファレンス 2015 Nagoya
OSSコンソーシアム .NET開発基盤部会

2. 1
1. 自己紹介
 経歴
date Content
・・・ 授業が退屈だったので、C/C++の習得がてら、VC++でゲームプログラミング。
2000年04月 某システムインテグレータ (企業) に入社する。
2000年08月 Windows DNAベースの大規模・基幹系Webアプリケーションの基盤開発に従事する。
2003年04月 某システムインテグレータ (企業) 生産技術部門へ異動する。
生産技術の一環としてMicrosoft系技術のサポート・エンジニアを担当する。
2007年09月 社内ツール、.NET用アプリケーション・フレームワーク“棟梁”のリリースする。
2014年04月 • Open棟梁をApacheLicense2.0のオープンソースとしてリリースする。
• OSSコンソーシアムに「.NET開発基盤部会」を立上げる。
 専門
Microsoft系技術のサポート
 .NET開発
 Windowsプラットフォーム構築
• AD, IIS, NLB,WSFC, SQL Server.
• 仮想化・クラウド （Hyper-V, Azure）
• パッケージ （Dynamics CRM, AX）
 主要プロジェクト
 金融業 保険代理店システム
 金融業 投資銀行営業支援用システム
 運輸・交通業 車両情報システム
 自動車・保険B2Bデータ交換システム
 各業種・業務向け自社パッケージ（金融・医療・自治体等）
 開発基盤ソリューション、有償サポート
 社内設備（クラウドを活用した検証環境高速デリバリ）開発
 Twitter ： @daisukenishino
 Facebook ： 西野 大介
西野 大介 ( にしの だいすけ )
生産技術 畑の出身です。

3. 2
2. Open棟梁の概要
Open棟梁は、.NET Framework 3.5 以上を前提とした、
フルスタックのアプリケーション・フレームワークです。
Web(ASP.NET, ASP.NET MVC)、C/S(WinForm, WPF)、
バッチ、RIA(Silverlight)、WebAPI、組込み等の各種方式に
対応し、高品質なアプリケーション開発を可能にします。
 ドキュメント
 利用ガイド、チュートリアル
 オフショア開発のための英語版マニュアル
 ライセンス
 source : Apache License, Version 2.0
 document : Creative Commons - CC BY 2.1 JP

4. 3
3. Open棟梁プロジェクトの精神姿勢
この「システム・インテグレーション」業界を良くしていこう！
• ノウハウ蓄積による、二度手間防止を行う。そして早く帰る。
ROR開発者（デイビッド・ハイネマイヤー・ハンソン氏）：
野心的になることは馬鹿げている。ロケットを月に送り出す必要はない。
世の中、出来の悪いものはあまりに多いし、改善すべき点というのはたくさんあ
るので、ほんの少し良くするだけでいい。
• 変化の無いSIerは、右肩下がり ですが・・・、
• ITゼネコン、受託によるシステム開発・構築
• ユーザープログラム開発 ＆ インフラ構築の支援
• 花型のアカウントSE、プロジェクト・マネージメント、その他、技術は所詮原価。
• 人月商売、多重下請け、受け身、御用聞き、デスマーチ
• ITテクノロジは大きく変化してもSIerの仕事はあまり変わらない。
• 何時迄経っても自助努力で生産性が上がらない
（Visual StudioやEclipseやOSSが生産性を上げている）。
• 昔ながらの問題が解決しない見積精度やリスク管理。
• 斜陽産業（単価下落、クラウド・SaaSの台頭）
• 技術者自身で、変わっていこう！（OSS化は、その一手段）
• 技術に依る価値の提案・提供（ユーザのビジネスへのメリットを訴求）
• QCD“F”向上、技術での差別化、事業への貢献、マネタイズの実現 .etc

5. 4
製品名
開発環境 • Microsoft Visual Studio 2010 以上
• Microsoft Visual C# 2010 以上
• Microsoft Visual Basic 2010 以上
実
行
環
境
Run
Time
• .NET Framework 3.5 以上
• ASP.NET2.0 以上
• ASP.NET MVC 4 以上, ASP.NET MVC SPA
• Windows Azure SDK for .NET
• Silverlight、Windows ストアアプリ
Data
Provider
• .NET Framework Data Provider for SQL Server
• OLEDB.NET Data Provider
• ODBC.NET Data Provider
• Oracle Data Provider for .NET
• IBM DB2.NET Data Provider
• HiRDB.NET データ プロバイダ
• MySQL Connector/NET
• PostgreSQL Npgsql.NET データプロバイダ
WWW
Browser
• Internet Explorer Version 6.0 以上
ダイアログ表示機能を使用しなければ他のブラウザでも利用可能（携帯電話向
けのCHTMLもサポート）。
4. 前提環境
C/S、RIAなど、殆どの案件でOpen棟梁を適用可能です。
今後も.NET、Visual Studioバージョンアップに追随予定です。

6. 5
5. 標準化されていないアプリケーションUI
テ
ク
ノ
ロ
ジ
ログ ファイル
DBMS
？？？
パートナー依存（丸投げ）
• どのような実装になっているか？
• 開発者毎に実装がばらばら？？
• 問題多発
「品質、性能が出ない」、
「デグレード多発」、「問題の分析ができない」
極端な例ですが、標準化をしない場合、
上記のように、内部の実装の共通化の具合、
実装のバラツキなどが把握できません。

7. 6
課 題 影 響
・ 共通処理方式（基準）が遵守されない
・ プログラム構造がバラバラになる
保守性 低下
同じ処理を重複して開発してしまう 生産性 低下
各種チェック処理、排他処理などの
処理の実装漏れや、実装ミスなど
品質 低下
不慣れな、難易度の高い処理の実装 信頼性 低下
・ SQLの組み立て実装ミス
・ 入力値サニタイジング等の処置漏れ
セキュリティ
脆弱性
アプリケーション開発には様々な課題がありますが、
.NET用アプリケーション フレームワーク、Open棟梁を
導入することで、これらの課題を解決できます。
6. アプリケーション開発における課題

8. 7
大規模プロジェクトを成功させるための要素として、アプリケーション フ
レームワーク（開発基盤）は、半ば必須です。フレームワーク開発には高
いコストがかかりますが、ノウハウが凝縮された実績のあるOpen棟梁
をベースとし、高品質の開発基盤を安価に構築可能です。
7. Open棟梁 適用の効果
提供機能の例 効果
Ｐ/Ｂ/Ｄ層に渡る、全レイヤ
のアーキテクチャの標準化
保守性の向上
ベースクラスのフロー制御に
基づいた共通処理の実装
生産性の向上
実績のある部品の再利用 品質の向上
・ SQLとプログラムの分離
・ パラメタライズド クエリ
信頼性の向上
自動生成（楽観排他を含む） 脆弱性の排除

9. 8
Open棟梁によるアプリケーション アーキテクチャの標準化
1. P / B / D層に渡る、全レイヤの標準化が可能です。
2. 基盤処理の実装がベースクラス1、2に分割されます。
・ ベースクラス1 : 共通処理（実行エンジン）
・ ベースクラス2 : プロジェクト毎にカスタム
3. これにより、開発者は、サブクラスへの
業務ロジック実装に専念することができます。
B（F）層
ベースクラス１
サブクラス
ベースクラス２
P層
ベースクラス１
サブクラス
ベースクラス２
D層
ベースクラス１
ASP.NET
サブクラス
ベースクラス２
8. Open棟梁 による標準化
プロジェクト毎に処理をカスタマイズ可能
共通処理を標準提供
開発者毎に業務ロジックを実装

10. 9
9. プロジェクト・テンプレートとS/Wスタック
特定プロジェクトのアーキテクチャに合わせてカスタマイズされたオンライン処理や
バッチ処理のテンプレートを『プロジェクト・テンプレート』と呼ぶ。
このプロジェクト・テンプレートを事前に準備し、プロジェクトに展開することで、開発
プロジェクトの迅速な立ち上げを実現する。
この準備作業を容易にする『テンプレート・ベース』を公開している。
活用方法は、『Tutorial_Template_development.doc』参照のこと。
案件毎のアーキテクチャを反映した
『プロジェクト・テンプレート』
カスタマイズ可能レイヤのカスタマイズ
カスタマイズ可能な標準化フレームワーク
（ P / F / D層 の構造と実装箇所の規定）
共通部品 / 開発ツール
（通信制御、動的パラメタライズド・クエリ）
各種ドキュメント
・ 利用ガイド
・ チュートリアル
・ サンプル.etc
日本語/英語版
を完備しており、
海外ベンダが
利用可能である。
ランタイム フレームワーク
（e.g. ASP.NET, WPF, WCF, ADO.NET)
ランタイム （ .NET CLR ）
上位スタック

11. 10
プロジェクト固有の実装をする （方式設計書に従う）
プロジェクト の 共通 Framework
認証
セッション管理
トランザクション管理 ログ出力 例外処理
権限 セキュリティメッセージ取得
ベースクラス２
業務固有の実装をする （実装基準書に従う）
アプリケーションA
（ベンダーA開発）
アプリケーションB
（ベンダーB開発）
アプリケーションC
（ベンダーC開発）
アプリケーションD
（ベンダーD開発）
サブクラス
B（F）層
ベースクラス１
サブクラス
ベースクラス２
P層
ベースクラス１
サブクラス
ベースクラス２
D層
ベースクラス１
ASP.NET
ベースクラス２
サブクラス
10. クロスベンダ開発の統制

12. 11
Access
TraceLog
B（F）層
ベースクラス１
サブクラス
ベースクラス２
P層
ベースクラス１
サブクラス
ベースクラス２
D層
ベースクラス１
ASP.NET
ベースクラス２
サブクラス
11. 標準化/共通化されたアプリケーション
Operation
TraceLog
SQL
TraceLog
• アクセス制御
• 表示・非表示
• 活性・不活性
• 閉塞処理
• コネクション制御
• トランザクション制御
• 例外処理
アクセス制御
Database
SQL
インジェクション
防止
LDAP
認証

13. 12
12. グローバル社会インフラ・プロジェクトの体制例
海外クライアント
海外
ITベンダB
海外
ITベンダA
海外
ITベンダC
： 技術の供給先
引き渡し後の運用保守を担当
発注/取り纏め
未定
Proposal and negotiation
国内コーディネータ
メーカーA
ハード
メーカーB
IT
メーカーC
その他
国内
ﾊﾟｰﾄﾅｰA
国内
ITﾊﾟｰﾄﾅｰC
海外
ITベンダB
海外
ITベンダA
海外
ITベンダC
国内
ベンダ
国内
ﾊﾟｰﾄﾅｰB
構築後に引き渡し

14. 13
Data Center/Cloud
13. グローバル社会インフラ・システムの構成例
Internet
Authority (In a different location)
Branch office
Overseas
system
owners
office
work1
administrative agency
office
work1
office
work1
Private companies
company1 company2 company3 company4
Intranet
Authority
Dept1 Dept2 Dept3 Dept4 Dept5
Branch office

15. 14
Data Center/Cloud
Internet
Authority (In a different location)
Branch office
Overseas
system
owners
office
work1
administrative agency
office
work1
office
work1
Private companies
company1 company2 company3 company4
Intranet
Authority
Dept1 Dept2 Dept3 Dept4 Dept5
Branch officeから行う業務は複雑であり、要求される“操作性に関する要件”も高い。
故に、HTML + JavaScriptでは実装困難な画面が多いためリッチクライアントを採用すべきである。
（ また、Internet Explorer限定ではないため、ActiveXは使用不可能。 ）
リッチクライアント & WebAPI (SOAP or REST)の3層C/Sならクラウド化も容易
通常のWebアプリケーションは、ASP.NET（HTML + jQuery）で開発する。
ASP.NETMVCの採用を検討しても良い。（ ブラウザ : Chrome & Firefoxをサポート）
Branch office
ASP.NET、WebAPI (SOAP or REST)
で開発されたServerアプリケーション。
13. グローバル社会インフラ・システムの構成例

16. 15
様々なスマート・デバイス
.NET リッチクライアント
クライアント・プリンタ印刷
WWWブラウザ
PDFダウンロード + 印刷
DBMS
(フェイルオーバー・クラスタ)
Webファーム
（負荷分散クラスタ）
サブシステム間連携方式未定 （ FTP, DB .etc ）
HTML
WebAPI
（バイナリ転送）
WebAPI
（REST）
HTTPプロトコル
Data Center
14. システム & アプリケーション・アーキテクチャ

17. 16
B（F）層
ベースクラス１
サブクラス
D層
ベースクラス１
サブクラス
ベースクラス２
ベースクラス２
通信制御機能
.NET サービスインターフェイス
バイナリ・オブジェクト転送
個別サービスインターフェイス
SOAP, REST (JSON, XML)
ASP.NET WS, WCF
Web API
ASP.NET WS, WCF
バイナリ・オブジェクト転送
.NET
クライアント
その他
クライアント
B（F）層、D層の実装はそのままでOK！！
WWW
ブラウザ
P層 ： ASP .NET
Web Form or MVC
15. 様々なクライアント・デバイスのサポート方式

18. 17
GitHub （米国）
OpenTouryoProject
/OpenTouryo
XXXX
/OpenTouryo
Git Git
Repository Repository
Repository Repository
Fork/Pull(Fetch/Marge)
Pull Request
16. 開発環境（皆さんのPRお待ちしております）
Pull/Push
Fetch/Marge
新機能や
フィードバック
プロジェクト・オーナー
Pull/Push
Fetch/Marge
コミュニティ・メンバー

19. 18
• 非同期実行基盤（非同期処理サービス）
DBMSをキューとして使用し非同期処理を実現するWindowsサービス。
• テンプレート拡充
• SignalRリアルタイム・ウェブ・テンプレート
• Microsoft.AspNet.SignalR.WebSockets
• SignalR Scaleout with Redis.
• サーバーの土管化 （JSONを吐く機械化）
Entity Framework & WebAPI
• Jenkinsを使用したCIサイトの構築、各種Plug-inを活用する。
• Inspection (FxCop / StyleCop) -> Violations plug-in
• Coverage (Opencover) -> HTML Publisher plugin
• Document generation (Doxygen) -> Doxygen plugin
• GitHub access -> GitHub plug-in
• Azure関係
• IDフェデレーション対応
WIF(Windows Identity Foundation)を使用し
IDフェデレーション対応のアプリケーション開発を可能にする。
• vhd デリ on Azure
• Azure Packで使用する従量課金システムの開発。
• Azure Storageのコピーなど、 Azure SDKを使用した
各種REST API処理を代行できるAzure Web Siteの開発。
17. 開発計画(2015年度)・・・若干遅延中

20. 19
18. 非同期実行基盤 （非同期処理サービス）
「Async および Await を使用したC#の非同期プログラミング」では不足がある。
非同期処理サービスは、（１） タスクのキューイングや、（２） 同時実行制御、（３）
エラー発生時のリトライ、（４） 処理状況の確認を可能にする。これは、大規模な基
幹システム開発で必要とされる非同期処理基盤である。

21. 20
19. 認証連携 （ID Federation） のサポート
これからのクラウド・アプリケーション （SaaS） は、認証連携 （ID Federation）
をサポートする必要がある。
さらに最近は、Azure ADなどのIDMaaS
を使用したHybrid-Idp構成のサポートが要
求され初めている。
引用元：http://www.agileit.com/single-sign-on-sso-for-office-365-and-other-cloud-services/
http://blogs.technet.com/b/junichia/archive/2013/03/07/3557111.aspx

22. 21
20. 様々な他社製品・SaaSとの連携を調査
ア
プ
リ
ケ
ー
シ
ョ
ン
Office 365
Salesforce
SAP
.etc .etc
• 各種コネクタ（SOAP、REST、Odata、LINQ to X）
• 認証連携（IDフェデレーション） WS-Federation、OpenID
ピュア・デベロップメントは減少傾向。
今後は他社製品・SaaSとの連携が重要になる
Dynamics

23. 22
Dao
クラス
SQL
ファイル
DBMS
参照系SQL
定義ファイル
HITACHI Net Bank
一覧
データ編集画面
（カスタマイズ可能）
詳細 一覧更新
TableAdapterと、実行エンジン
スキーマ情報や、参照系SQLから、一覧、
詳細、一覧更新の各種データ編集画面を
自動生成します（Excel設計書は不要）。
21. データ編集画面を自動生成（→EUCツール化
HITACHI Net Bank
一覧
テーブル編集画面
（カスタマイズ可能）
詳細 一覧更新全
自
動
生
成

24. 23
• オープンソース・プロジェクト
 OpenTouryoProject
https://github.com/OpenTouryoProject
 OpenTouryo, Documents, Templates リポジトリ
 CloudOS リポジトリ、SampleProgram リポジトリ
• . NET 開発基盤部会 - Blog - OSSコンソーシアム
http://www.osscons.jp/dotNetDevelopmentInfrastructure/Blog/
 Open棟梁 Wiki
http://opentouryo.osscons.jp/
 マイクロソフト系技術情報 Wiki
http://techinfoofmicrosofttech.osscons.jp/
• 2014年10月22日 : Open 棟梁 01-50 リリース
http://www.osscons.jp/joi94ey46-537/
 Open棟梁概要説明 01-50
http://www.slideshare.net/daisukenishino/open-01-50-
40474003
 Open棟梁機能紹介 01-50
http://www.slideshare.net/daisukenishino/open-0150
22. ご参考

25. 24
END
※ Windows、.NET Framework、Silverlight、Azureは、Microsoft Corporationの米国およびその他の国における商標もしくは登録商標です。
※ その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

27. 1
始めに私の経歴を申し上げます。
（０） 入社前にゲーム・プログラミング等をかじっておりました。
（１） 入社後すぐに、Windows DNAベースの大規模・基幹系Webアプリケー
ション（VBS+VB6）の開発基盤の開発と、開発支援に従事し、
（２） その後、生産技術という世界で、.NET開発やWindowsプラットフォーム
のサポート・エンジニアを担当してきました。
（３） そして、2007年頃、ある案件で開発されたフレームワークを他の案件に
ヨコ展開する支援の延長で社内リリースしました。
（４） そして、時は流れて去年の2014年4月にOSS化を達成しました。現在、
約1年程、OSSコンソーシアムの方でコミュニティ活動を継続しています。

28. 2
Open棟梁は、.NET3.5以上を前提とし、種々のアプリケーション・アーキテ
クチャに対応した（画面とDBMSを結ぶ）業務アプリケーション開発をター
ゲットとしたOSSのアプリケーション・フレームワークです。
実績については、現在、産業/金融/公共と業種を問わず、2.0MStepの
大規模案件から2.0K Step程度の小規模案件まで、様々な案件に対して
100案件程度の導入実績があります。

29. 3
OSS化後一年が経ち、ようやく自分が何をしたいのか？が解って来ました。
ということで、コチラが「Open棟梁プロジェクト」の精神姿勢になります。

30. 4
前提環境は、このようになっており、
特別な要件がなければ、ほぼ全ての開発案件に対応できます。

31. 5
そもそもOpen棟梁が開発された背景はどのようなものだったのか ・・・ と言
う話ですが、100画面以上あるエンタープライズの大規模な基幹システム開
発では、統制 / 標準化が重要になりますので、 Open棟梁は、この統制 / 標
準化を目的としていました。
以下は、統制/標準化がとれていないアプリケーション開発プロジェクトの
「あるある」です。
• どのような方式で実装されているか？何処にも書かれていない。
• また、その実装の方法が開発者単位にバラバラである。
• 故に、品質性・性能、デグレードの問題が発生し易く、
問題の分析も難しくなるため、なかなかリカバリが効かない。
・・・と、“Welcome To The Death March” って感じですが、現在でも、殆どの
企業やサイトで、このような問題の解決が十分ではありません（幾つもの企
業やサイトで個別の自助努力はあるものの、集約しなければ、成熟期を過
ぎて久しいエンタープライズ・アプリケーション開発において十分と言える
効果は既に得られなくなっています）。

32. 6
このような話は、優れたプログラマーによる少数精鋭チームにとっては退
屈な話かもしれませんが、レベルのバラつきのある大勢のプログラマーを指
揮し、統制を執った状態で開発を遂行するということも、大規模システム開
発ならではの基礎的なエンジニアリングの一つです。
（開発者の中には、この統制にフラストレーションを感じる方もいらっしゃる
かと思いますが、後で文句を言われたくないので、処理方式を提示して欲
しいと感じる方もいらっしゃると思います。
また、反対に納品を受けるお客様の立場としては、このように統制がとれ
ており、開発方法がガイド・チュートリアル等により明確となっているアプリ
ケーションの納入を希望すると思います。色々な意見があります。）
なお、このような問題を放置すると、様々な要因が重なることで問題が噴
出し、且つそれらをリカバリすることが困難になって行き、最終的には皆さ
んが良くご存知の“デス・マーチ”という状態に陥って行きます（ただし、詳し
く分析すると、技術要素だけではなく、契約や、要件定義、プロジェクトマネ
ジメントなどの取り纏め能力などに依る所が大きい）。

33. 7
Open棟梁では、フレームワークの持つ各機能を活用して、統制/標準化を
執り、生産性/保守性、品質/信頼性、脆弱性の問題を解決することが可能
です。
また、後程ご説明しますが、 Open棟梁はカスタマイズ可能レイヤを持って
おり、色々な案件にフィッティングさせていくことができます。これにより、
ユーザ専用フレームワークのカスタム・ベースとして活用して頂くことも可能
となっています。

34. 8
この図が、Open棟梁による標準化の図になります。
図中の横：P/B/D層の論理3階層アーキテクチャを採用しております。また、
特徴的な図中の縦：ベースクラス１・２、サブクラスの継承を使用した3層の
継承構成を採用しています。
ベースクラス１は実行エンジンであり、ベースクラス２はカスタマイズ可能レ
イヤとなっています。このベースクラス１・２に、認証、セッション・トランザク
ション管理、ログ出力、例外処理などの共通処理の実装を固定することで、
フレームワーク上で適切に共通化が成され、開発者はサブクラスへの業務
ロジック実装に専念することができるようになります。
これにより、前述の統制/標準化を執り、生産性/保守性、品質/信頼性、脆
弱性の問題を解決することが可能です。

35. 9
また、Open棟梁は、ただのアプリケーション開発フレームワークではなく、
この図のようなスタックから構成された、テンプレートやドキュメント類のセッ
トになっています（前項の図はOpen棟梁をアーキテクチャの視点から見た
図になりますが、コチラの図はOpen棟梁の提供物一式を別の視点から見た
図になります）。
• 簡単に言って、フレームワークを中心とした、ノウハウ蓄積による、
二度手間防止の全体的な仕掛と言うことになるかと思います。
• この図にあるように、共通部品、開発ツールから、フレームワーク、利用
ガイド、チュートリアル、サンプルプログラム、そして、これらを一式に纒
めた『プロジェクト・テンプレート』から成り立っています。
• 通常OSSフレームワークというと、Struts、Spring、などのフレームワークを
想像するかと思いますが、そのスタックには、マイクロソフト社純正の
ASP.NET等のフレームワークを使用していますので、我々の方では主に、
その上位スタックのライブラリやツール、（MyBatis に相当する）永続化フ
レームワーク、上位の枠組み、ドキュメント類の開発に注力しています。
• そして特に、この最上位スタックの『プロジェクト・テンプレート』を整備す
ることで、開発プロジェクトの迅速な立ち上げを可能にしている所が大き
なポイントになります。

36. 10
このような仕組みにより大規模な基幹系アプリケーションのクロスベンダ開
発も実現します。

37. 11
開発されたアプリケーションは、このような統制のとれた状態になります。
・標準化（全体構造）
・共通化（吹き出しの中の処理）

38. 12
例えば、この図は、グローバル社会インフラ案件の体制例です。
このような案件では、今後、開発を国内クロスベンダで、保守/運用を海外
ベンダで。という形態も出てくるものと思われます。
Open棟梁は、このような体制の案件に対しても、迅速にプロジェクトを立
ち上げ、遂行することができます。

39. 13
また、技術面について、社会インフラとなると、基本的にはベンダ・ロックイ
ンされないJava-Webでの提案が一般的かと思います。
しかし昨今のシステムの複雑化に伴い、一部リッチクライアントが必要にな
るケースがあることや、REST WebAPIを使用してクライアント・サイドで（ス
マート・デバイスを含む）様々なクライアント・デバイスのサポートが必要にな
ることを考えると・・・、

40. 14
このように、.NETで開発を一本化するという選択岐も魅力的なものになっ
てくると思います。また、.NET Core 5が本格的に使用可能になれば、クライ
アント・サイドだけでなく、サーバ・サイドもクロスプラットフォーム化できる可
能性があります。
----- 引用 ----- ----- -----
dotNetConf 2015 Japan 参加レポート【前編】 - MODD TECH BLOG
http://blog.modd.com/entry/2015/04/17/103615
Core 5 も DNX も ASP.NET 5 も開発中ということで、
現時点ではまだ、実用には耐えないようです。
----- ----- ----- ----- -----

41. では、Open棟梁では、このような（スマート・デバイスを含む）様々なクライ
アント・デバイスをサポートをどのように実現するのか？と言う話ですが、
15

42. それは、このように通信制御機能を使用して実現します。
.NETクライアントの場合は.NETオブジェクトのバイナリ転送が可能である
ので、メソッドシグネチャが固定の汎用的な.NETサービス・インターフェイス
を利用できます（SOAP上の１つのパラメタを.NETオブジェクトのバイナリ転
送用のバイナリ・フィールドとして使用している）。このため、3層C/Sアプリケ
ーションも、2層C/Sアプリケーションと略同じエクスペリエンス（＝生産性）で
開発することができます。
コレに対し、異なる様々なクライアント・デバイスのランタイムの場合は、
Web標準のSOAP、REST（JSON、XML）などのデータ記述形式を使用して
、個別のサービス・インターフェイスを定義します。
このクライアント・デバイスをサポートする場合、追加実装が必要になるの
は、個別のサービス・インターフェイスの追加実装だけで、B層やD層はそ
のまま再利用することができるのがポイントになります。
16

43. Open棟梁プロジェクトの開発について。
Open棟梁プロジェクトでは、Githubを使用して開発を行っています。
コミュニティ・メンバーには様々なユーザの方の参画を期待しています。
現在、主な開発、維持・保守は我々と、インドIP発注で行っています。この
プロジェクトの運営状況は、OSSコンソーシアムのブログなどでも報告して
行きたいと考えています。
皆様からのPullRequestやプロジェクトへの参画をお待ちしております。
17

44. 今後の開発計画は、こんな感じで考えています。現在、バージョン01-50
が最新版になっていますが、2015年6月末頃にバージョン01-70をリリース
する予定です。
このリリースで、従来のエンタープライズ・アプリケーションの開発基盤とし
ての機能拡充は、ほぼ完了するため、
次のターゲットとしては、
・ 新技術サポート
• EntityFramework, SignalR
• ID-Federation, OpenID Connect.ets
・ クラウド・サポート
・ SaaS開発基盤
・ 内製支援ツール、EUCツール化
などを考えています。
18

45. 非同期実行基盤（非同期処理サービス）のサポート
これは、「Async および Await を使用したC#の非同期プログラミング」では
不足がある場合に使用する、大規模な基幹システム開発で必要とされる非
同期処理基盤です。
https://github.com/OpenTouryoProject/OpenTouryoDocuments/blob/master/
documents/1_User_Guide/en/AsyncProcessingService/AsyncProcessingServ
ice_EN.xlsx
非同期処理サービスは、
（１） タスクのキューイング
（２） 同時実行制御
（３） エラー発生時のリトライ
（４） 処理状況の確認
等を可能にします。
この機能の実装を完了したことで、エンタープライズ・アプリケーションの
開発基盤機能はほぼ実装し尽くしてしまいましたので、Open棟梁プロジェ
クトは、次のステージに歩みを進めようと考えています。
19

46. SaaS開発基盤としては、認証連携（ID-Federation）によるクレームベース
認証のサポート。
クレームベース認証は、クラウド・アプリケーション（SaaS）等の開発の浸透
から徐々に重要になってくると思います。将来的には、企業の認証基盤とし
て標準的なものになるかもしれません。また、 OpenID Connectなどの認証
技術についても今後、サポートする必要がでてくるかもしれません。
20

47. また、各種SaaSとの連携方法などについても知見を増やしていきたいと考
えています。まだ何をやったら良くなるか？等は良く解っていない所もあり
ますが、パッケージには色々な連携方法があるので、その連携方法を理解
して、案件毎にベターな連携方法を選択できるようにするのがスタートであ
るように思います。
例えば、Dynamics CRMでは、「FetchXML」を使用するのか？「フィルタ
ーされたビュー」を使用するのか？など。またSaaS間の認証等の方式につ
いても考えていく必要があると思います。
21

48. そして、内製支援ツール、EUCツール化のための画面自動生成について
。
現在は、D層とテーブル・メンテナンス画面の自動生成をサポートしていま
すが、将来的には、自由SQLからデータ・メンテナンス画面の自動生成を
サポート（ Currently, Early Implementation of Supplemental ）し、内製支援
ツール、EUCツールとしての提案をユーザに行っていきたいと考えていま
す。
22

49. 当部会の成果物です。
是非ともご覧ください。
23

50. 24