ODCでは、Appが提供するPublicな要素は全て弱い参照であり、URL経由のアクセスになるはず。
そこで、Appが提供するPublicな要素がどのようなURLでアクセスされるのか、またそもそも本当にURL経由になるのかを確認してみる。
環境情報
ODC Studio(Version 1.3.4)
ドキュメント
強い依存関係と弱い依存関係について理解するの「弱い依存関係」から
アプリ間の依存関係は、マイクロサービスアーキテクチャパターンであるため常に弱い依存関係となります。コンシューマアプリはビルド時にプロデューサのコードを必要としません。
と、App間の依存関係は常に弱い参照であることが明記されている。
URLアクセスであることは明記まではされていないが、「マイクロサービスアーキテクチャパターン」であること、実行時に「コンシューマアプリはビルド時にプロデューサのコードを必要としません」とあることから、弱い参照関係にある要素へのアクセスは通信によって行われると考えられる（注：この後出てくるが、EntityはどうもHTTPS通信ではなく、バックエンドへの直接SQL発行でアクセスしていそう）。
AppがPublicにできる要素
Reuse elements across apps - PublicElementsに記載がある。
Appは、以下の要素をPublicにできる
- Entity
- Screen
- Service Action
- Static Entity
- Structure
Structureは他の要素のInput/Output Parameterの型としてPublicになるので、他の要素を見ていく。
あるAppがPublicにした要素を別のAppで参照し、検証する。
Entity/Static Entity
結論：EntityはConsumerからSQLで読みに行っていそう（ドキュメントで裏付けが取れないので確証無し）
（この項は中身無し）
Screen Aggregateの場合
Entity側で呼び出しに使われたURLを取得することはおそらくできない。
そこで、一応開発者ツール（ブラウザ）のネットワークタブでURLを確認すると、以下の形式。
https://<hostname>/<Consumer App名>/screenservices/<Consumer App名>/MainFlow/<Screen名>/ScreenDataSet<Aggregate名>
これは、呼び出し側（Consumer）の画面配下のURLへリクエストが飛んでいることを示す。
ただし、ODC Portalで画面のTraceログを確認してみると、Screen AggregateのTraceが直接SQLを記録している。これは、PublicなEntityへのリクエストがApp間のHTTPS通信ではなく、バックエンドのDBへの直接のSQL発行で行われていることを示しているのかもしれない。
今のところ、それを示すドキュメントが見つかっていないが、実はConsumer AppのEntityとProducer AppのEntityをジョインしたとき、Traceにはジョインを行うSQLが記録されることがこの見解を（弱めにだが）裏付けている。
Consumerのサーバー側処理でAggregate呼び出しをした場合
試しにData ActionにAggregateを配置し、動作確認してみると、TraceにはSQLが記録される。
つまり、この場合も、Producer AppのEntityへのリクエストはバックエンドのSQLリクエストで行われていそう。
Service Action
確認方法
Consumer側からProducer側のService Action呼び出し後、ODC PortalのTraceを確認し、URL欄を見る
結果：httpスキーマのApp毎に決まったURLへの通信でアクセス
Consumer側のClient Action、Data Action、Timer、Expose REST APIからProducerのService Actionを呼び出し、URLを確認してみると、全て
http://svc-<GUID?>:8080/serviceapi/<ServiceAction Name>
このGUIDの部分は、ODC PortalでそのAppを開いたときの、idパラメータの値と一致している。
Screen
これは確認するまでもなく、Producer側のScreenのURL（一応確認した）。