　概してAllJoyn Frameworkは非常に重い。特にStandardの方は、HLOS（High Level OS）の上で動作する事を前提にしており、現実問題としてはAndroidが乗ったマシンが最低要求になるだろう。またAllJoynのCore Libは、現在説明されている限りにおいてはOSの持つNetwork層には手を入れるつもりはないらしい。なのでTransport層は原則IPとBluetooth Stackをそのまま利用する形になり、その上でPhoto03に出てくるProximal Networkを構築する形になるから、オーバーヘッドは相応に大きい。

　ただしその反面、OSやドライバに手を入れずに実装できるというのは、開発期間の短縮につながる。最適化などはある意味後回しであって、まずはとにかく相互接続性を早く確保できるようにしよう、という強い意思がここからは感じられる。

　次の問題は何をどこまで標準化するか、という話だ。これはOpen Interconnect Consortium（OIC）の場合にも出てきた話だが、広範囲に渡る機器の相互接続を考えると、画一的なAPIではどうしても冗長な部分や足りない部分が出てくる。例えばオーディオ向けの接続に色調のAPIを用意しても仕方ないからだ。なので、用途別に特化したAPIを提供することになる。

　OCIの場合は、これをProfileという形で用意し、ProfileがFramework APIを叩くという形で吸収するわけだが、AllJoynではPhoto06で分かるように、必ずしも特定分野向けとは言いにくい構成になっている。しいて言えば「手段別」というべきか。で、この手段に合わせてそれぞれ別の「Service Framwork」を用意する形を取っている。

OICは用途別に「Profile」を用意し、それがFramework APIを叩く仕組みとしている

　このService Framework自体の追加や詳細の検討はAllseen Alliance内部のWorking Groupの仕事であり、勝手に特定のメーカーがFrameworkを追加するといったことは許されない。では各メーカーはどこで差別化するか、といえばその上位層ということになる（Photo07）。

Photo07 実際のアプリケーションはオープンソース化する必要が無い（別にしても構わないのだろうが）、というのは機器を開発しているメーカーにとってはありがたい話である

　ライセンス的にもここは完全に別になっており、AllJoynそのものはオープンソースであっても、それを使うアプリケーションはプロプライエタリで構わない、という方針は、実際に多くの機器メーカーを抱えているAllSeen Allianceとしては妥当なものだろう。ちなみにこのオープンソースのライセンスはICS Licenseを利用することが既に明らかにされている。