Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

特許庁アーキテクチャ標準仕様書適合確認チェックリストを読む

現在、自治体向けシステムの標準化の動きが進んでおり、先日も以下のような標準仕様書適合確認が公表されています。

  • 住民記録システム標準仕様書 第2.0版*1
  • 税務システム標準仕様書 第1.0版*2
  • 介護保険システム標準仕様書 第1.0版*3

一方、以前から標準仕様書としてまとめられているものもあり、たとえば以下のような標準仕様書は、現在の議論が始まる前から整備されていました。

この中でも、特許庁アーキテクチャ標準仕様書は適合確認チェックリストが作られている*6ので、その内容を見てみました。

  • 項番8 No.1(2)⑤「セッションを使用しないこと」とあります。これはHTTPセッションに限らず「ある定まった期間に行われる一連の通信をひとまとまりのものとして扱う仕組み全般を指す」とのことです*7一方でユーザ認証の観点からはアプリケーションのどこかで状態を持たせる必要があるはずです*8。とすると、ここでは認証以外のビジネスロジックに関する要件から「ひとまとまりのものとして扱う」必要がないようにせよ、と解釈するのが自然でしょうか。これってもしかして、ユーザ情報をクライアント側と共有しておいて、それに対して認証時 or 更新時にサーバ側で署名をすることで認証済みであることを担保するJWT的な仕組みのことを意図している?

  • 項番8(2)⑥⑦ 通信内容はXMLで、バイナリデータはBase64エンコードして送ることになっています。DIMEもMTOMもSwAも使わないということですね。単純にSOAPは使わないという話なのか、それともDIMEもMTOMもSwAも相互運用性に難ありと見て使わない*9という話なのかは分かりません。

  • 項番10 No.1(2)エラーの返却方法はHTTPステータスコード以外に定められていません。RFC 7807*10の5.に記載のあるように、HTTPステータスコードは経路上で書き換えられる可能性があるから、構内システムだけならともかく一般公開されるシステムではRFC 7807のような内容が必要だと思うんですが……

  • 項番30 No.3 (5) 画面がGETメソッドで起動(画面の表示開始)をするということは、トランザクション処理と画面表示を分離できるようPRGパターンで実装するか、クライアントサイドをSPAにする必要があると読めます。

  • 項番45 No.2(2) ストプロやトリガが禁止とのこと。ユーザ定義関数はOKなんでしょうかね? 元々のDBMSOracleで、PostgreSQLへ移行する場合など、OracleにあってPostgreSQLにない関数を補うためにユーザ定義関数を作る場合があります*11が、そういった手立ては使えないということでしょうか。

  • 項番46 No.1(2)① 共有データベースへのアクセスはJDBC APIを使うよう記載があります。ただ、ここではJDBC APIかというより、クライアントとDBとの通信方法(JDBC Type1~Type4のどれか)を決めた方がいいように思います。また、APIに関して言うのであればJDBC APIのバージョン(2.0か4.0かなど)が欲しいところです。

  • 項番46 No.1(2)③ SQL99への準拠が求められています。各種DBMSSQL標準への準拠状況としてはWikipediaの記事*12がまとまっています。このうちSQL99相当ってどの範囲なんですかね? SUBSTRINGはSQL99で定義されているよう*13なので、SUBSTRINGに対応していないOracleSQL Serverはその時点で脱落?

  • 項番51 No.1(1) HTTP/1.1を使うとのことです。HTTP Request Smugglingを考える*14と、HTTP/2を混ぜずにHTTP/1.1で統一しているのは良いと思います。

  • 項番61 No.1(1)文字セット、エンコード、アプリケーションで使う文字セットの範囲をそれぞれ定めています。これが分けて定義されていないシステムってどれくらいあるんでしょうね?

  • 項番64 No.1(1) 業務キーは、業務キー区分コードと業務キー主部の組で1つのコードを定めています。このことから、業務キーを管理するテーブルはいわゆるOTLTを想定しているものと思われます。

*1:https://www.soumu.go.jp/menu_news/s-news/01gyosei04_02000097.html

*2:https://www.soumu.go.jp/main_sosiki/kenkyu/zeimu_hyojunka/02zeimu02_04000350.html

*3:https://www.mhlw.go.jp/stf/newpage_20794.html

*4:https://www.moj.go.jp/kaikei/bunsho/kaikei03_00024.html からリンクされている、 https://www.moj.go.jp/content/001321623.pdfhttps://www.moj.go.jp/content/001321624.pdf

*5:https://www.jpo.go.jp/system/laws/sesaku/gyomu/system_kaihatsukanren.html

*6:横道にそれますが、このチェックリストは第1.2版で追加されたようで、確実にシステム開発で使用されていることがうかがえます。チェックリストにすべての要件を盛り込むことはできないので、チェックリストがあるからといって検討漏れを防ぐことはできません。一方で、特にウォーターフォール型のシステム開発には、開発標準に従うための訓練が必要な人員も割り当てられるので、設計品質限界に近付けるための底上げを目的にチェックリストを要求するというのは自然な考えと思われます。ウォーターフォール型のシステム開発における開発標準に従うことのできる人員の割合についてはBarry Boehm, Richard Turner, "Balancing Agility and Discipline: A Guide for the Perplexed", Addison-Wesley Professional, 2003, p.48およびp.58を参照。設計品質限界についてはIPA 平成30年度春期プロジェクトマネージャ試験(PM)午後I 問2を参照。

*7:特許庁アーキテクチャ標準仕様書 本冊p.18

*8:認証を行ったユーザと現在通信を行っているユーザが同一であることをシステムが認識する必要があるため。さもなくば、特許庁アーキテクチャ標準仕様書 本冊p.73に従いLDAPのクレデンシャルをクライアントから通信毎に送ることになります

*9:参考: http://itdoc.hitachi.co.jp/manuals/link/cosmi_v0970/03Y2360D/EY230176.HTM に「標準仕様の性質から~SwA仕様でもまだあいまいな部分が残ります」との記載あり。

*10:https://datatracker.ietf.org/doc/html/rfc7807

*11:https://www.postgresql.jp/document/7.4/html/plpgsql-porting.html

*12:https://en.wikipedia.org/wiki/SQL_compliance

*13:これはSQL-99 Complete, Really https://web.archive.org/web/20151031013800/https://mariadb.com/kb/en/sql-99/ から記載を見つけられませんでした

*14:https://www.blackhat.com/us-21/briefings/schedule/#http2-the-sequel-is-always-worse-22668