例えば、JEP 463は、大規模なプログラム用に設計された言語機能を理解することなく、学習者が最初のプログラムを記述できるように、Java プログラミングへのスムーズなオンランプを提供するもの。これにより、学習者は単一クラス・プログラムの合理化された宣言を記述できる。
オラクル、Java 22発表 - 注目機能はJavaプログラミングへのスムーズなオンランプの提供 | TECH+（テックプラス）
⇧ スムーズにJavaのプログラミングに入れたとして、その後のことが考慮されてると信じて良いのだろうか？
実際の現場では～、みたいに梯子を外されることが無いのであれば、問題ないですけど...
つまり、入門のプログラミングと実際の開発現場でのプログラミングに乖離が無いのかどうか、だって、あまりにもかけ離れているとしたら学習者にとって大いに弊害が出てきてしまいますからな。
Javaの機能の本質的な仕組みを解説してくれるのが一番良い気がするんですが、『初学者には理解できないから端折ります』って言って煙に巻く悪しき習慣が多過ぎるので、何とかして欲しいですな。
学習者の障壁になっているのは、そのあたりの「ブラックボックス」にされている部分だと思うので、
『例えば、JEP 463は、大規模なプログラム用に設計された言語機能を理解することなく、学習者が最初のプログラムを記述できるように、Java プログラミングへのスムーズなオンランプを提供するもの。』
の対応って全く的外れと言うか、そもそも、何の解決にもなってないんよな...
『大規模なプログラム用に設計された言語機能を理解することなく』という状態で、大規模開発のプロジェクトに放り出された時に、漏れなく対応できずに潰されるという事例を量産するだけの結果にしかならない気がするんだが...
そして、何と言うか、
⇧ リリースのサイクルを短くするのであれば、バージョン移行ガイド的なものも考慮して欲しいところですな...
せっかく、機能を追加してもらったとして、バージョン移行できなくてという話になると新たに開発された機能が利用されることが無いという結果になって、宝の持ち腐れになりますしな...
Javaからブラウザにpush通知を送る仕組みを整理してみる
ネットを漁っていたところ、
⇧ とあるので、
- Web Server
→Browserで表示するフロントエンドのソースコードを配置 - Application Server
→Serverで処理するバックエンドのソースコードを配置 - Push Server
→ブラウザに通知を送る処理
の3つのサーバーがあれば良いようなのだけど、Browserで外部からの通知を受け取れるように、「Service Worker」を稼働しておく必要があるっぽい。
「Service Worker」はと言うと、
A progressive web application (PWA), or progressive web app, is a type of application software delivered through the web, built using common web technologies including HTML, CSS, JavaScript, and WebAssembly. It is intended to work on any platform with a standards-compliant browser, including desktop and mobile devices.
Technologies
There are many technologies commonly used to create progressive web apps. A web application is considered a PWA if it satisfies the installation criteria, thus can work offline and can be added to the device's home screen. To meet this definition, all PWAs require at minimum a service worker and a manifest.
Service Worker
A service worker is a web worker that implements a programmable network proxy that can respond to web/HTTP requests from the main document. It is able to check the availability of a remote server, cache content when that server is available, and serve that content later to the document. Service workers, like any other web workers, work separately from the main document context. Service workers can handle push notifications and synchronize data in the background, cache or retrieve resource requests, intercept network requests and receive centralized updates independently of the document that registered them, even when that document is not loaded.
https://en.wikipedia.org/wiki/Progressive_web_app#Service_workers
Service workers go through a three-step lifecycle of Registration, Installation and Activation. Registration involves telling the browser the location of the service worker in preparation for installation. Installation occurs when there is no service worker installed in the browser for the web app, or if there is an update to the service worker. Activation occurs when all of the PWA's pages are closed, so that there is no conflict between the previous version and the updated one. The lifecycle also helps maintain consistency when switching among versions of a service worker since only a single service worker can be active for a domain.
https://en.wikipedia.org/wiki/Progressive_web_app#Service_workers
⇧「PWA (Progressive Web Application)」というWebの技術を実現するのに必要な要素の1つであると。
一応、
⇧ 2014年8月が初出ということらしい。今が、2024年3月20（水）なので、およそ、10年ほど経過しているわけですと。
で、「Service Worker」の機能はいろいろあるようなのですが、Webでの「push通知」については、
⇧ 上図のようなアーキテクト図があり、「Service Worker」はブラウザの構成の一部という扱いっぽい。
ちなみに、
⇧ 脆弱性が存在するらしいのだけど、既に対応されているんかね？
「Service Worker」を利用する側として、気を付けないといけないことが残っているのかどうか状況を知りたいんですけどね...
話が脱線しましたが、Webで「push通知」を実装するための仕様については、
Web Push
Web Pushは、ブラウザの種類によらず、同じJavaScript APIを用いてブラウザにプッシュ通知を設定し、受信できるようにする仕組みです。ブラウザAPIはW3C、プロトコルとデータフォーマット等はIETFで標準化が進められています。
プロトコルとデータフォーマット関連の技術仕様は次の3種類に分かれています。
特に、メッセージ付きプッシュ通知を送信する場合は、メッセージの暗号化が必須になることに注意が必要です。
⇧ 上記サイト様によりますと、RFCで仕様が定義されてる模様。
2. Overview
A general model for push services includes three basic actors: a user agent, a push service, and an application (server).
1. Introduction
The Web Push protocol [RFC8030] is an intermediated protocol by necessity. Messages from an application server are delivered to a user agent (UA) via a push service, as shown in Figure 1.
⇧ シーケンス図からだと読み取れないのですが、「Push Message」の暗号化が必要らしい。
2. Push Message Encryption Overview
Encrypting a push message uses Elliptic Curve Diffie-Hellman (ECDH) [ECDH] on the P-256 curve [FIPS186] to establish a shared secret (see Section 3.1) and a symmetric secret for authentication (see Section 3.2). A user agent generates an ECDH key pair and authentication secret that it associates with each subscription it creates. The ECDH public key and the authentication secret are sent to the application server with other details of the push subscription. When sending a message, an application server generates an ECDH key pair and a random salt. The ECDH public key is encoded into the "keyid" parameter of the encrypted content coding header, and the salt is encoded into the "salt" parameter of that same header (see Section 2.1 of [RFC8188]). The ECDH key pair can be discarded after encrypting the message.
⇧ なるほど、
| RFC 8291 | アプリ | サーバー |
|---|---|---|
| UA（user agent） | ブラウザ （クライアントアプリケーション） |
Web Server |
| Application | サーバーサイドアプリケーション | Application Server |
⇧ 「Web Server」と「Application Server」の両方で秘密鍵・公開鍵を作成しておく必要があると。
で、実際には、「Service Worker」が必要らしいので、登場人物としては、
⇧ 上図のような感じになるんかな？
登場人物としては、
| No | actor | 出典 | アプリ | サーバー |
|---|---|---|---|---|
| 1 | web page | W3C | JavaScript | Web Server |
| 2 | service worker | W3C | Web API | ‐ |
| 3 | user agent | W3C | ブラウザ | ‐ |
| UA（user agent） | RFC 8030 | ブラウザ | ‐ | |
| UA（user agent） | RFC 8291 | ブラウザ | ‐ | |
| 4 | push service | W3C | ※1 | Push Server |
| Push Service | RFC 8030 | ※1 | Push Server | |
| Push Service | RFC 8291 | ※1 | Push Server | |
| 5 | application server | W3C | Java | Application Server |
| Application Server | RFC 8030 | Java | Application Server | |
| Application | RFC 8291 | Java | Application Server |
※1 ServerSide JavaScript、または、Java（勿論、Java以外のサーバーサイド言語でも実現可能）
⇧ 上記のような感じになると。
つまり、actorで表記ゆれとかあるのだけど、全て同じものを指していると見なして、登場人物としては、5つになると。
「Push Service」をどう実装するかが悩ましいところですが、ネットの情報だと「Node.js」とかで「ServerSide JavaScript」の実装としてる例が多いのですが、Javaとかでも実装できるかと。
まぁ、「Push Service」の部分については、「Firebase」などのクラウドのサービスを利用する例が多かったのだけど...
「web page」からの
- register()
- subscribe()
については、「Service Worker」の登録のために、一度だけ実施される感じかと。
おそらく、プッシュ通知のパターンとしては、
- フロントエンド → サーバーサイド → プッシュサーバー → フロントエンド
- サーバーサイド → プッシュサーバー → フロントエンド
の2つになる感じかな。
一応、
⇧ 上記サイト様によりますと、フロントエンドからのリクエストが起点であれば、フロントエンドからユーザーの情報をサーバーサイドに渡せて、ユーザー毎にメッセージを変えることもできるらしい。
ブラウザとService Workerの整合性を調整したりが難しそうですな...
ちなみに、
2023年3月末にiOS 16.4がリリースされたことで、ついにすべてのモダンブラウザユーザーに対してWeb Pushを送れるようになりました。
⇧ 上記サイト様によりますと、ネイティブアプリのpushの機能ではなく、Web Pushの機能が適用できるようになったようです。
Web Pushの機能の充実度が分からないのですが、
| No | PC | スマホ |
|---|---|---|
| 1 | Webアプリ | ネイティブアプリ |
| 2 | Webアプリ | Webアプリ |
⇧ 両方ともWebアプリという構成も採用できる可能性が出てきたのかしら？
「OAuth 2.0」と「OpenID Connect」の時も思ったのだけど、仕様書にあるシーケンス図から必要なものが読み取れるようにしておいて欲しいですかね...
結局のところ、仕様書を読むだけでは機能を実装するのに必要な情報の整理が完結できないのよね...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
