.NET用アプリケーション フレームワーク Open 棟梁 ＠ オープンソースカンファレンス 2015 Nagoya

OSSコンソーシアム .NET開発基盤部会

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 ： 西野 大介

西野 大介 ( にしの だいすけ ) 生産技術 畑の出身です。

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

3

3. Open棟梁プロジェクトの精神姿勢

この「システム・インテグレーション」業界を良くしていこう！

• ノウハウ蓄積による、二度手間防止を行う。そして早く帰る。 ROR開発者（デイビッド・ハイネマイヤー・ハンソン氏）：

野心的になることは馬鹿げている。ロケットを月に送り出す必要はない。 世の中、出来の悪いものはあまりに多いし、改善すべき点というのはたくさんあ

るので、ほんの少し良くするだけでいい。

•変化の無いSIerは、右肩下がり ですが・・・、 • ITゼネコン、受託によるシステム開発・構築

• ユーザープログラム開発 ＆ インフラ構築の支援 • 花型のアカウントSE、プロジェクト・マネージメント、その他、技術は所詮原価。 • 人月商売、多重下請け、受け身、御用聞き、デスマーチ

• ITテクノロジは大きく変化してもSIerの仕事はあまり変わらない。 • 何時迄経っても自助努力で生産性が上がらない （Visual StudioやEclipseやOSSが生産性を上げている）。

• 昔ながらの問題が解決しない見積精度やリスク管理。 • 斜陽産業（単価下落、クラウド・SaaSの台頭）

•技術者自身で、変わっていこう！（OSS化は、その一手段） • 技術に依る価値の提案・提供（ユーザのビジネスへのメリットを訴求） • QCD“F”向上、技術での差別化、事業への貢献、マネタイズの実現 .etc

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バージョンアップに追随予定です。

5

5. 標準化されていないアプリケーション

UI

テクノロジ

ログ ファイル

DBMS

？？？ パートナー依存（丸投げ）

• どのような実装になっているか？

• 開発者毎に実装がばらばら？？

• 問題多発

「品質、性能が出ない」、

「デグレード多発」、「問題の分析ができない」

極端な例ですが、標準化をしない場合、 上記のように、内部の実装の共通化の具合、実装のバラツキなどが把握できません。

6

課 題 影 響

・ 共通処理方式（基準）が遵守されない ・ プログラム構造がバラバラになる

保守性 低下

同じ処理を重複して開発してしまう 生産性 低下

各種チェック処理、排他処理などの 処理の実装漏れや、実装ミスなど

品質 低下

不慣れな、難易度の高い処理の実装 信頼性 低下

・ SQLの組み立て実装ミス ・ 入力値サニタイジング等の処置漏れ

セキュリティ 脆弱性

アプリケーション開発には様々な課題がありますが、

.NET用アプリケーション フレームワーク、Open棟梁を導入することで、これらの課題を解決できます。

6. アプリケーション開発における課題

7

大規模プロジェクトを成功させるための要素として、アプリケーション フレームワーク（開発基盤）は、半ば必須です。フレームワーク開発には高

いコストがかかりますが、ノウハウが凝縮された実績のあるOpen棟梁をベースとし、高品質の開発基盤を安価に構築可能です。

7. Open棟梁 適用の効果

提供機能の例 効果

Ｐ/Ｂ/Ｄ層に渡る、全レイヤ のアーキテクチャの標準化

保守性の向上

ベースクラスのフロー制御に 基づいた共通処理の実装

生産性の向上

実績のある部品の再利用 品質の向上

・ SQLとプログラムの分離 ・ パラメタライズド クエリ

信頼性の向上

自動生成（楽観排他を含む） 脆弱性の排除

8

Open棟梁によるアプリケーション アーキテクチャの標準化

1. P / B / D層に渡る、全レイヤの標準化が可能です。 2. 基盤処理の実装がベースクラス1、2に分割されます。 ・ ベースクラス1 : 共通処理（実行エンジン） ・ ベースクラス2 : プロジェクト毎にカスタム 3. これにより、開発者は、サブクラスへの 業務ロジック実装に専念することができます。

B（F）層

ベースクラス１

サブクラス

ベースクラス２

P層

ベースクラス１

サブクラス

ベースクラス２

D層

ベースクラス１

AS

P.N

ET

サブクラス

ベースクラス２

8. Open棟梁 による標準化

プロジェクト毎に処理をカスタマイズ可能

共通処理を標準提供

開発者毎に業務ロジックを実装

9

9. プロジェクト・テンプレートとS/Wスタック

特定プロジェクトのアーキテクチャに合わせてカスタマイズされたオンライン処理やバッチ処理のテンプレートを『プロジェクト・テンプレート』と呼ぶ。 このプロジェクト・テンプレートを事前に準備し、プロジェクトに展開することで、開発プロジェクトの迅速な立ち上げを実現する。 この準備作業を容易にする『テンプレート・ベース』を公開している。 活用方法は、『Tutorial_Template_development.doc』参照のこと。

案件毎のアーキテクチャを反映した 『プロジェクト・テンプレート』

カスタマイズ可能レイヤのカスタマイズ

カスタマイズ可能な標準化フレームワーク （ P / F / D層 の構造と実装箇所の規定）

共通部品 / 開発ツール （通信制御、動的パラメタライズド・クエリ）

各種ドキュメント ・ 利用ガイド ・ チュートリアル ・ サンプル.etc

日本語/英語版 を完備しており、 海外ベンダが

利用可能である。

ランタイム フレームワーク （e.g. ASP.NET, WPF, WCF, ADO.NET)

ランタイム （ .NET CLR ）

上位スタック

10

プロジェクト固有の実装をする （方式設計書に従う）

プロジェクト の 共通 Framework

認証

セッション管理

トランザクション管理 ログ出力 例外処理

権限 セキュリティ メッセージ取得

ベースクラス２

業務固有の実装をする （実装基準書に従う）

アプリケーションA （ベンダーA開発）

アプリケーションB （ベンダーB開発）

アプリケーションC （ベンダーC開発）

アプリケーションD （ベンダーD開発）

サブクラス

B（F）層

ベースクラス１

サブクラス

ベースクラス２

P層

ベースクラス１

サブクラス

ベースクラス２

D層

ベースクラス１

AS

P.N

ET

ベースクラス２

サブクラス

10. クロスベンダ開発の統制

11

Access TraceLog

B（F）層

ベースクラス１

サブクラス

ベースクラス２

P層

ベースクラス１

サブクラス

ベースクラス２

D層

ベースクラス１

AS

P.N

ET

ベースクラス２

サブクラス

11. 標準化/共通化されたアプリケーション

Operation TraceLog

SQL TraceLog

• アクセス制御 • 表示・非表示 • 活性・不活性

• 閉塞処理 • コネクション制御 • トランザクション制御 • 例外処理

アクセス制御

Database

SQL インジェクション

防止

LDAP

認証

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

構築後に引き渡し

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

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. グローバル社会インフラ・システムの構成例

15 様々なスマート・デバイス

.NET リッチクライアント クライアント・プリンタ印刷

WWWブラウザ PDFダウンロード + 印刷

DBMS (フェイルオーバー・クラスタ)

Webファーム （負荷分散クラスタ）

サブシステム間連携方式未定 （ FTP, DB .etc ）

HTML

WebAPI （バイナリ転送）

WebAPI （REST）

HTTP プロトコル

Data Center

14. システム & アプリケーション・アーキテクチャ

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. 様々なクライアント・デバイスのサポート方式

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

コミュニティ・メンバー

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年度)・・・若干遅延中

19

18. 非同期実行基盤 （非同期処理サービス）

「Async および Await を使用したC#の非同期プログラミング」では不足がある。

非同期処理サービスは、（１） タスクのキューイングや、（２） 同時実行制御、（３） エラー発生時のリトライ、（４） 処理状況の確認を可能にする。これは、大規模な基幹システム開発で必要とされる非同期処理基盤である。

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

21

20. 様々な他社製品・SaaSとの連携を調査

アプリケーション

Office 365

Salesforce

SAP

.etc .etc

• 各種コネクタ（SOAP、REST、Odata、LINQ to X） • 認証連携（IDフェデレーション） WS-Federation、OpenID

ピュア・デベロップメントは減少傾向。 今後は他社製品・SaaSとの連携が重要になる

Dynamics

22

Dao クラス

SQL ファイル

DBMS

参照系SQL 定義ファイル

H ITACHI Net Bank

一覧

データ編集画面 （カスタマイズ可能）

詳細 一覧更新

TableAdapterと、実行エンジン

スキーマ情報や、参照系SQLから、一覧、詳細、一覧更新の各種データ編集画面を自動生成します（Excel設計書は不要）。

21. データ編集画面を自動生成（→EUCツール化

H ITACHI Net Bank

一覧

テーブル編集画面 （カスタマイズ可能）

詳細 一覧更新 全自 動 生 成

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. ご参考

24

END

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

1

始めに私の経歴を申し上げます。

（０） 入社前にゲーム・プログラミング等をかじっておりました。

（１） 入社後すぐに、Windows DNAベースの大規模・基幹系Webアプリケーション（VBS+VB6）の開発基盤の開発と、開発支援に従事し、

（２） その後、生産技術という世界で、.NET開発やWindowsプラットフォームのサポート・エンジニアを担当してきました。

（３） そして、2007年頃、ある案件で開発されたフレームワークを他の案件にヨコ展開する支援の延長で社内リリースしました。

（４） そして、時は流れて去年の2014年4月にOSS化を達成しました。現在、約1年程、OSSコンソーシアムの方でコミュニティ活動を継続しています。

2

Open棟梁は、.NET3.5以上を前提とし、種々のアプリケーション・アーキテクチャに対応した（画面とDBMSを結ぶ）業務アプリケーション開発をターゲットとしたOSSのアプリケーション・フレームワークです。

実績については、現在、産業/金融/公共と業種を問わず、2.0MStepの

大規模案件から2.0K Step程度の小規模案件まで、様々な案件に対して100案件程度の導入実績があります。

3

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

4

前提環境は、このようになっており、

特別な要件がなければ、ほぼ全ての開発案件に対応できます。

5

そもそもOpen棟梁が開発された背景はどのようなものだったのか ・・・ と言う話ですが、100画面以上あるエンタープライズの大規模な基幹システム開発では、統制 / 標準化が重要になりますので、 Open棟梁は、この統制 / 標準化を目的としていました。

以下は、統制/標準化がとれていないアプリケーション開発プロジェクトの「あるある」です。

• どのような方式で実装されているか？何処にも書かれていない。

• また、その実装の方法が開発者単位にバラバラである。

• 故に、品質性・性能、デグレードの問題が発生し易く、

問題の分析も難しくなるため、なかなかリカバリが効かない。

・・・と、“Welcome To The Death March” って感じですが、現在でも、殆どの企業やサイトで、このような問題の解決が十分ではありません（幾つもの企業やサイトで個別の自助努力はあるものの、集約しなければ、成熟期を過ぎて久しいエンタープライズ・アプリケーション開発において十分と言える効果は既に得られなくなっています）。

6

このような話は、優れたプログラマーによる少数精鋭チームにとっては退屈な話かもしれませんが、レベルのバラつきのある大勢のプログラマーを指揮し、統制を執った状態で開発を遂行するということも、大規模システム開発ならではの基礎的なエンジニアリングの一つです。

（開発者の中には、この統制にフラストレーションを感じる方もいらっしゃるかと思いますが、後で文句を言われたくないので、処理方式を提示して欲しいと感じる方もいらっしゃると思います。

また、反対に納品を受けるお客様の立場としては、このように統制がとれており、開発方法がガイド・チュートリアル等により明確となっているアプリケーションの納入を希望すると思います。色々な意見があります。）

なお、このような問題を放置すると、様々な要因が重なることで問題が噴出し、且つそれらをリカバリすることが困難になって行き、最終的には皆さんが良くご存知の“デス・マーチ”という状態に陥って行きます（ただし、詳しく分析すると、技術要素だけではなく、契約や、要件定義、プロジェクトマネジメントなどの取り纏め能力などに依る所が大きい）。

7

Open棟梁では、フレームワークの持つ各機能を活用して、統制/標準化を執り、生産性/保守性、品質/信頼性、脆弱性の問題を解決することが可能です。

また、後程ご説明しますが、 Open棟梁はカスタマイズ可能レイヤを持っており、色々な案件にフィッティングさせていくことができます。これにより、ユーザ専用フレームワークのカスタム・ベースとして活用して頂くことも可能となっています。

8

この図が、Open棟梁による標準化の図になります。

図中の横：P/B/D層の論理3階層アーキテクチャを採用しております。また、特徴的な図中の縦：ベースクラス１・２、サブクラスの継承を使用した3層の継承構成を採用しています。

ベースクラス１は実行エンジンであり、ベースクラス２はカスタマイズ可能レイヤとなっています。このベースクラス１・２に、認証、セッション・トランザクション管理、ログ出力、例外処理などの共通処理の実装を固定することで、フレームワーク上で適切に共通化が成され、開発者はサブクラスへの業務ロジック実装に専念することができるようになります。

これにより、前述の統制/標準化を執り、生産性/保守性、品質/信頼性、脆弱性の問題を解決することが可能です。

9

また、Open棟梁は、ただのアプリケーション開発フレームワークではなく、この図のようなスタックから構成された、テンプレートやドキュメント類のセットになっています（前項の図はOpen棟梁をアーキテクチャの視点から見た図になりますが、コチラの図はOpen棟梁の提供物一式を別の視点から見た図になります）。

• 簡単に言って、フレームワークを中心とした、ノウハウ蓄積による、

二度手間防止の全体的な仕掛と言うことになるかと思います。

• この図にあるように、共通部品、開発ツールから、フレームワーク、利用ガイド、チュートリアル、サンプルプログラム、そして、これらを一式に纒めた『プロジェクト・テンプレート』から成り立っています。

• 通常OSSフレームワークというと、Struts、Spring、などのフレームワークを想像するかと思いますが、そのスタックには、マイクロソフト社純正のASP.NET等のフレームワークを使用していますので、我々の方では主に、その上位スタックのライブラリやツール、（MyBatis に相当する）永続化フレームワーク、上位の枠組み、ドキュメント類の開発に注力しています。

• そして特に、この最上位スタックの『プロジェクト・テンプレート』を整備することで、開発プロジェクトの迅速な立ち上げを可能にしている所が大きなポイントになります。

10

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

11

開発されたアプリケーションは、このような統制のとれた状態になります。

・標準化（全体構造）

・共通化（吹き出しの中の処理）

12

例えば、この図は、グローバル社会インフラ案件の体制例です。

このような案件では、今後、開発を国内クロスベンダで、保守/運用を海外ベンダで。という形態も出てくるものと思われます。

Open棟梁は、このような体制の案件に対しても、迅速にプロジェクトを立ち上げ、遂行することができます。

13

また、技術面について、社会インフラとなると、基本的にはベンダ・ロックインされないJava-Webでの提案が一般的かと思います。

しかし昨今のシステムの複雑化に伴い、一部リッチクライアントが必要になるケースがあることや、REST WebAPIを使用してクライアント・サイドで（スマート・デバイスを含む）様々なクライアント・デバイスのサポートが必要になることを考えると・・・、

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 も開発中ということで、

現時点ではまだ、実用には耐えないようです。

----- ----- ----- ----- -----

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

15

それは、このように通信制御機能を使用して実現します。

.NETクライアントの場合は.NETオブジェクトのバイナリ転送が可能であるので、メソッドシグネチャが固定の汎用的な.NETサービス・インターフェイスを利用できます（SOAP上の１つのパラメタを.NETオブジェクトのバイナリ転送用のバイナリ・フィールドとして使用している）。このため、3層C/Sアプリケーションも、2層C/Sアプリケーションと略同じエクスペリエンス（＝生産性）で開発することができます。

コレに対し、異なる様々なクライアント・デバイスのランタイムの場合は、Web標準のSOAP、REST（JSON、XML）などのデータ記述形式を使用して、個別のサービス・インターフェイスを定義します。

このクライアント・デバイスをサポートする場合、追加実装が必要になるのは、個別のサービス・インターフェイスの追加実装だけで、B層やD層はそのまま再利用することができるのがポイントになります。

16

Open棟梁プロジェクトの開発について。

Open棟梁プロジェクトでは、Githubを使用して開発を行っています。

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

皆様からのPullRequestやプロジェクトへの参画をお待ちしております。

17

今後の開発計画は、こんな感じで考えています。現在、バージョン01-50

が最新版になっていますが、2015年6月末頃にバージョン01-70をリリースする予定です。

このリリースで、従来のエンタープライズ・アプリケーションの開発基盤としての機能拡充は、ほぼ完了するため、

次のターゲットとしては、

・ 新技術サポート

• EntityFramework, SignalR

• ID-Federation, OpenID Connect.ets

・ クラウド・サポート

・ SaaS開発基盤

・ 内製支援ツール、EUCツール化

などを考えています。

18

非同期実行基盤（非同期処理サービス）のサポート

これは、「Async および Await を使用したC#の非同期プログラミング」では不足がある場合に使用する、大規模な基幹システム開発で必要とされる非同期処理基盤です。

https://github.com/OpenTouryoProject/OpenTouryoDocuments/blob/master/

documents/1_User_Guide/en/AsyncProcessingService/AsyncProcessingServ

ice_EN.xlsx

非同期処理サービスは、

（１） タスクのキューイング

（２） 同時実行制御

（３） エラー発生時のリトライ

（４） 処理状況の確認

等を可能にします。

この機能の実装を完了したことで、エンタープライズ・アプリケーションの開発基盤機能はほぼ実装し尽くしてしまいましたので、Open棟梁プロジェクトは、次のステージに歩みを進めようと考えています。

19

SaaS開発基盤としては、認証連携（ID-Federation）によるクレームベース認証のサポート。

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

20

また、各種SaaSとの連携方法などについても知見を増やしていきたいと考えています。まだ何をやったら良くなるか？等は良く解っていない所もありますが、パッケージには色々な連携方法があるので、その連携方法を理解して、案件毎にベターな連携方法を選択できるようにするのがスタートであるように思います。

例えば、Dynamics CRMでは、「FetchXML」を使用するのか？「フィルターされたビュー」を使用するのか？など。またSaaS間の認証等の方式についても考えていく必要があると思います。

21

そして、内製支援ツール、EUCツール化のための画面自動生成について。

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

22

当部会の成果物です。

是非ともご覧ください。

23

24