プラットフォームについて
クラウドサービスのすべての開発者と消費者を大規模なサービスプロバイダー（通信およびホスティングサービスプロバイダー）のインフラストラクチャを介して接続し、エンドユーザーにエントリポイントを提供するプラットフォームを構築しています：コントロールパネルまたはポータルを使用して、Webサイトの作成、メールの構成、クラウドでウイルス対策または仮想マシンを購入します。
Odin Automationは、次のコンポーネントで構成されています。
- Microsoft Office 365やDropbox for Businessなどの製品の購入に関心のある中小企業だけでなく、エンドユーザーを引き付けることを目的としたオンラインストア 。 システムは、最適なソリューションを選択し、その機能とバージョンをナビゲートするのに役立ちます。
- 購入したサービスのコントロールパネル（コントロールパネル/自己管理コントロールパネル）。そのタスクは、購入者にサービスを管理、購入（アップセル）、クロスセル（クロスセル）する機能を提供することです。
- 作業プロセスを管理するビジネスサポートシステム（BSS）は 、支払い、プロビジョニング、請求などのプロセスを開始します。
- 運用サポートのシステム（OSS、運用サポートシステム） 、会計、計画、およびサービスの提供を扱います。
OSSは、サービスの作成とその消費の会計処理を管理します。 クラウドサービスの場合、各サービスには独自のAPIがあるため、これは重要なタスクになります。 この問題を解決するには、APSが必要です。APSは、クラウドサービスの管理とアカウンティングのための単一のAPIを備えた運用サポートシステムを提供します。
APSにより、さまざまな企業が、いわゆるAPSコネクタを使用してサービスをプラットフォームに統合できます。 プラットフォーム自体との対話に加えて、サービスはAPSバス内の標準化されたRESTful APIを介して相互に対話できます。
APSバスは、すべての参加者がプラットフォームリソースを含む互いのリソースにアクセスできるようにするプロトコルです。
バスの機能は、いわゆるAPSコントローラーによって提供され、次の機能を実行します。
- アクセス制御（ポリシーシステム-ユーザーとアプリケーションの各カテゴリには、独自の特権と制限のセットがあります）;
- サービスリソースのライフサイクル管理。
- 必要なデータの検索と保存（ある意味では、UIのレンダリングなどのために、サービスから毎回データを要求することを許可しないキャッシュ。実際、Post NoSQLデータベースを作成しましたが、これについては次の記事で詳しく説明します）。
このテクノロジーはポリシーのシステムをサポートしています。ユーザーの各カテゴリには、独自の特権と制限があります。 とりわけ、コントロールパネルのユーザーインターフェイスへの深い統合をサポートしています。
- ナビゲーションツリー全体の一部となる画面を紹介します
- 1つのアプリケーションの画面を別のアプリケーションに配置します（たとえば、ユーザー作成ウィザード）。
- ユーザーインターフェイスの一部をウィジェットの形式で提供します（たとえば、メインページのタイルとして）。
プラットフォームサービス自体（ユーザー管理、DNS管理、アカウント管理）は、APSバスを介して相互にやり取りします。 この意味で、私たちはドッグフードに従事しています-APSを使用して独自のモジュールを分離します。
クラウドサービスの開発者がOdin AutomationとAPSを使用するのはなぜですか？
マーケティングには4Pルールがあります： 製品、価格、プロモーション、場所 。 製品を「撮影」するには、「キャンディ」を作るだけでは不十分です。価格（価格）を正しく決定し、宣伝（プロモーション）し、販売する場所（場所）を理解する必要があります。 これはすべてソフトウェア製品に当てはまり、その多くは今日、さまざまなプラットフォーム（アプリケーションストア）を通じて配布されています。 同時に、プラットフォームでできることは、最後の3つの「P」の問題からあなたを救うことです。最小限の開発者の努力ですべての潜在的な消費者にアプリケーションを見せることです。
上記のすべてはクラウドサービスに適用されます-クラウドサービスの販売、ねじれの解消、および配信するサイトの選択も必要です。 サービスプロバイダーは、そのようなプラットフォームとして機能できます。通信およびホスティングサービスプロバイダーは、巨大なユーザーベースを持っています。 開発者にとって、このようなベースへのアクセスは、サービスを開発するための重要な機会です。 より多くの新しい市場を探しているMicrosoft Office 365、Symantec、Trend Micro、Dropboxなどの大規模なプレーヤーと、進路の初めにある小さな市場の両方がこれに興味を持ち、サービスを作成しましたが、販売方法はまだわからず独自の請求があります。
その結果、サービス開発者は、製品のプロモーション（市場分析、販売計画の作成と設定）、支払い、または販売の地域について考える必要はありません。大規模プロバイダーにはいわゆるリセラーがいる場合があります。 たとえば、O2（はい、ヨーロッパでのローミングの同じ事業者）は、最大の通信プロバイダーTelefónicaの再販業者の子会社です。
消費者がサービスプロバイダーからクラウドサービスを購入するのはなぜですか？
最近、さまざまなサービスの消費モデルが、特に中小企業のセグメントで変化しています。 ソフトウェアとハードウェアの消費の古典的なモデル（「箱入り」ソフトウェア、サーバーの購入、およびそれらのインストールとサポート）は死にかけています。 配信モデル（ますます-クラウドからのサービス）と購入方法（サブスクリプションによる）の両方が変化しています。
たとえば、ユーザーが以前にMicrosoft Officeの再販業者から標準のMicrosoft流通チャネルを通じてCDで購入したとします。 新しい消費モデルでは、媒体を物理的に転送する会社はもう存在しません。 消費者は、ベンダー開発者から直接、またはOdin Automationなどのプラットフォームに接続されたサービスプロバイダーを通じて、Microsoft Office 365のクラウドベースのライセンスを受け取ります。
個人が直接購入することはすべて明らかですが、会社がさまざまなサービスを多数使用している場合はどうでしょうか？ Microsoft Office 365、Adobe Creative Cloud、Azure、Dropbox、My Warehouseなど 多くの点在する契約を持ち、サブスクリプションを管理して従業員に配布し、使用権を監視し、異なる通貨で各サービスに別々に時間どおりに支払い、各開発者と会計文書を作成する必要があります。 これらのすべての機能を引き受けることができるアグリゲーターが必要です。 これがOdin Automationプラットフォームの本質です。
特に、消費モデルが変更されました。一度購入した従来の製品とは対照的に、ユーザーはサブスクリプションの一部として一定の頻度でクラウドサービスの料金を支払います。
Odinは、サービスプロバイダーのインフラストラクチャに展開されるクラウドサービスの販売と消費のために、b2b2bプラットフォーム（企業間、企業間ビジネス）を作成しました。 同時に、購入者（b2b2bチェーンのビジネスオーナー）は、取得したサービスを単一のコントロールパネルから管理できます。
たとえば、当社のプラットフォームを使用する中小企業の所有者は、メールとウイルス対策を複数の従業員に一度に提供し、個人アカウントですべてのサービスの残高を表示し、現地通貨で単一アカウントですべてのサブスクリプションの支払いを行い、高度な技術サポートを受けることもできます。 クライアントの成功は、プロバイダーが提供するさまざまなサービスの数に依存します。この傾向は、数年にわたってアメリカとヨーロッパで広く発展しています。
そして、統合のために何をする必要がありますか？
APSコネクタ、APSパッケージを作成し、APSパッケージをディレクトリに配置します。
APSコネクタは、サービス統合における重要なリンクです。
2つの部分で構成されます。
1）APSコネクタバックエンド、
2）APSコネクタフロントエンド。
APSコネクタバックエンドは、APS APIをサービス固有のAPIに変換します。 APSコネクタフロントエンドは、Odin Automationコントロールパネルと統合するインターフェイスを提供します。
APSコネクタバックエンドは、APIが特定の規則に従うHTTPエンドポイントです。 たとえば、サービスを作成するために、プラットフォームはAPSコネクタバックエンドのリソース表現を使用してHTTP POSTを送信します。 表現内のデータ（たとえば、サービスの潜在的な消費者であるユーザーへのリンク）に基づいて、APSコネクタバックエンドは、サービス側にリソース（たとえば、ユーザー）を作成することを決定できます。
リソース自体は、APSパッケージに配置されたjsonダイアグラムに記述されています。 この図により、Odin Automationはリソースを管理および販売する方法を理解できます。
つまり、たとえば、サービスプロバイダーを介してMicrosoft Officeサブスクリプションを購入すると、APSコネクタバックエンドに実装されたロジックを使用してMicrosoft Officeサーバーのライセンスが作成されます。
開発者は、APSコネクタフロントエンドを開発できます。特定のプレゼンテーションロジック（ユーザーインターフェイス）を有効にします。
- 購入したサービスのステータス（たとえば、残りのMicrosoft Officeライセンス）をユーザーに通知する。
- サービス内でサービスを購入する可能性（たとえば、クラウドストレージの追加ディスクスペース）。
- アプリケーションリソースへのアクセスを容易にします（たとえば、Dropboxやドキュメントにアクセスするためにクライアントをダウンロードするためのリンク）。
サービスプロバイダーのインフラストラクチャにAPSコネクタパッケージを展開すると、販売の準備が整います。 同時に、APSコネクタバックエンドをクラウドでホストし、たとえば、Google App EngineやMicrosoft Azure WebAppなどのPaaSサービスにデプロイできます。
とりわけ、Google PlayMarketおよびApple AppStoreとの類推により、APSコネクタパッケージを認定しています。 認定後、アプリケーションはAPSディレクトリに分類され、そこからサービスプロバイダーのインフラストラクチャにインストールできます。
したがって、Odin Automationプラットフォームには、Microsoft Office 365、Dropbox、Symantec、Acronis、Autodesk、Autocad、Trend Microなど、500以上のアプリケーションが既にパッケージ化されています。
例によるAPSコネクタバックエンドの作成
ここでは、APSコネクタバックエンドの作成のみを考慮します。APSコネクタフロントエンドの作成は別の記事のトピックです。さらに、APSコネクタを迅速に作成し、かなり高度なユーザーインターフェイスを自動的に生成できる技術に取り組んでいます。
ユーザーと組織にクラウドストレージを提供するサービスがあるとします。 フォールボールと呼びましょう。
Fallballの最も単純なバージョンには、次のモデルがあります。
ファイルがあなたの部屋のコンピューターのディスクのフォルダー/ <accountId> / <userId>に保存され、WebDavを介してユーザーにアクセスが提供されると仮定します。
最初に、APSの観点からサービスモデルを表現します。
サービスをサブスクリプションで販売し、購入時に、ビジネスオーナーが従業員全員が利用できる合計金額を制限できます。 プロバイダーは、たとえばBasic（10 GB）やAdvanced（100 GB）などのプラットフォームを使用して、関連する販売計画を構成します。 ユーザーに割り当てられたスペースのサイズは、diskspaceフィールドに保存されます。
APSコネクタパッケージに記述されるリソースのAPSスキームは、青色でマークされています。
次に、HTTPエンドポイントAPSコネクタバックエンドを作成する必要があります。 好みのテクノロジーを選択します。家の中にフラスコがある小さなPythonアプリケーションから、Google App EngineにデプロイされたJava webappまで。
簡単にするために、アカウントまたはユーザーを作成するときに、サービス内の対応するアカウントとユーザーが削除されると想定しています。 非常に粗雑な形式では、シーケンス図は次のようになります。
ディスクスペースフィールドに注意してください。これは、構造である「APSカウンター」の標準タイプです。 制限フィールドでは、Odin Automationは請求で指定された制限を渡します。 サービスは、この情報を使用して、消費者がこの値を超えないようにすることができます。 この場合、ストレージスペースを10 GBに制限します。
json-schemaの形式でタイプを記述し、URLルーティングを宣言します（この場合、サブスクリプションを作成するときに、POST /アカウントを実行する必要があることを示します）。 これでAPSコネクタバックエンドの準備が整いました！
最後に
この記事は、APSテクノロジーの非常に短い紹介です。 標準の背後にあるテクノロジーをまったく取り上げませんでしたが、実際には、プロバイダーによる販売とユーザーによる単一のコントロールパネルでの消費を目的として、サードパーティの開発者によって作成されたさまざまなクラウドサービスをシームレスに統合するためのプラットフォームを作成しました。
簡単に使用するテクノロジーの中で最も興味深いものは次のとおりです。
- 異種サービスのデータ（リソース）を保存し、それらの間の接続をサポートするための独自のPost NoSQLデータベース （用語「オントロジーベース」がよく使用されます）。
- 継承をサポートするタイプ。 記述形式としてのjsonスキーマ。
- 構造化データと非構造化データの両方を保存し、サポートをサポートするタイプのインスタンスとしてのリソース。
- 接続（明示的および暗黙的の両方）;
- HTTPルーティングをサポートするリソースメソッド。
- RESTオブジェクトにアクセスするための特別な言語を使用して、エンティティ、コレクション、関係にアクセスする方法-RQL;
- リソースへのアクセスの差別化。任意のリソースがセキュリティプリンシパル（ユーザーだけでなく、アプリケーションなど）としても機能します。
- バージョニング
- 認証メカニズム（SSLクライアント証明書、OAuth）;
- リソースのライフサイクルの作成と管理。
- 画面とデータサービスを単一のユーザーコントロールパネルに結合する独自の技術 。
- 共通データバスに基づく一般的な宣言的ナビゲーション。
- アプリケーションの相互分離。
- Unified UXガイドライン。
- 一般的なjsフレームワーク。
- コンポーネント間APIとしてのRESTfulインターフェイスのみ。
- APIの標準化
- PaaSの積極的な使用（Google、App Engine標準、Compute Engine、Cloud SQL、Amazon DynamoDB、Azure、Azure App Service、SQL Azure Database）;
- それが意味するすべてのパブリックAPI：
- バージョニング
- 100％のテストカバレッジ。
- 論理的整合性、表現力、主題領域の抽象化レベルの遵守の継続的な監視。
- 自己文書化。
興味深い場合は、以下の投稿で、これらすべてがどのように機能するかについて詳しく説明します。
はい、ここに公式のOdin Automation SDKドキュメントへのリンクがあります。その主な部分はAPS標準です： doc.apsstandard.org/7.1
よろしくお願いします！