誰でもわかるMuleSoft API-led Connectivityについて

みなさんこんにちは。
初アドベントカレンダー！ということでライトな内容を書こうと思います。

2018年5月2日にSalesforceによってMuleSoft社が買収され、日本国内においてもMuleSoftを導入しようと検討する企業様も増えてきたかと思います。MuleSoft盛り上がってるね！いいね！という声もちらほら聴きますので、MuleSoftを始めよう！と思っている方へMuleSoftとは何か？従来のEAI・ETLとはどこが違うのか？という疑問を解消すべく「誰にでもわかる記事」を目標としMuleSoftに関わろうと思っている方の敷居を下げられればと思います。

今回はMuleSoftの代表的な設計思想である「API-led Connectivity」について私なりの理解を記載します。

API-led Connectivityとは何か？

API-led Connectivityは、APIを用途に応じた3つの層（Experience、Process、System）に分類し、データとアプリケーションを接続することでAPIの再利用性を高める手法です。

なんとなくは理解したが、具体的なイメージが分かない・・・という方もいらっしゃるでしょう。それでは「誰にでもわかる」ように「ピザの宅配」を例に挙げて3層APIの役割を紐解いていきます。

Experience APIの役割

みなさんは、ピザの宅配を注文したいと思った場合、どのようなアクションを起こしますか？宅配サービスに「電話」をかける。それとも「Webページ」から注文を登録する。または「専用アプリ」から注文リクエストをする。このように色々な手段で注文を実施することとなります。仮にピザの注文システムを構築する場合、色々な手段から注文を受けられる機能を配置する必要があります。
上記の機能をMuleSoftで実現する場合、様々なデバイス・アプリ（システム）から注文を受注できるような役割を担うAPIがExperience APIとなります。

Process APIの役割

Experience APIを配置することで、ひとまず注文を受け付けることはできそうです。
さて、みなさんはピザを注文する際に、クーポンを利用したことはありますか？クーポンによって割引ができたり、サービスで商品を追加することができたという経験はありますよね。このような条件によって注文結果（金額）を変更するようなビジネスロジックをMuleSoftで実現する場合、Process APIの出番となります。

また、Process APIにはビジネスロジックにもとづきSystem APIの実行を制御する役割があります。
今回の例で言うと、注文の内容（何のピザを頼むのか？ドリンク等は必要か？）によってSystem APIの実行内容が変動することとなります。Process APIではクーポンによる割引だけでなく、System APIの制御など注文に関する様々な機能を実装する必要があるため、以下のように「注文API」という様々な機能を持つAPIを準備し、割引機能もまとめます。

System APIの役割

Process APIを配置することによって、様々な要件に対応するビジネスロジックを実装できそうです。
それではSystem APIはどのような役割を持つのでしょうか。注文サービスの例でいうと、まだ登場していない「商品（商品データ）」の取得ですね。System APIはシステムへの接続とデータ処理が役割となります。
例として「ピザ」を管理するデータベースと「ドリンク」を管理するデータベースが別で存在していた場合、以下のようなAPI構成となります。

さて、このままのシステム構成ではどうやって宅配するんだろう？と疑問に思った方もいるかもしれません。
そこで宅配を管理するシステムと接続する「宅配システムAPI」を配置し、「注文API」と接続してみましょう。すると以下のような構成となります。

3層構造のメリット（APIの再利用性）

ここまでで各層のAPIの役割についてイメージはできたかと思います。しかし、ここまで役割を細分化する必要はあるのか？と疑問を持った方もいらっしゃるかもしれません。また、MuleSoftはわざわざ役割を分割しないと実装できない仕組みになっているの？面倒くさい！と思った方もいるかもしれません。
まず、後者の疑問について、MuleSoftは役割を分割しないと実装できないような仕組み・制約は設けていないのでやろうと思えばすべての機能を1つのAPIに集約することは可能です。例えば以下のような構成です。

では、なぜ役割を細分化する必要があるのか？
システムとは導入したらおしまいではなく、日々変化する顧客ニーズに対応するため、頻繁に改修・拡張が実施され変化していくものだからです。例えば、ピザ宅配サービスが好調なので、新サービスを立ち上げたいという要望が出てきたとします。そうですね、例えば「そばの出前」を実施したいという要件が出てきたとします。ピザの注文と同じく電話・Webから受付可能としましょう。するとどうでしょう、以下のようにほとんどのAPIが再利用可能となります。

みなさんもご存知の通り、１からシステムを構築するのは膨大なお金・時間がかかります。しかし、MuleSoftの提唱するAPI-led Connectivityに沿ってきちんとシステム設計を行えばより手軽でスピーディにサービスの拡張を実現することができます。

まとめ

• API-led Connectivityとは
  • APIを用途に応じた3つの層（Experience、Process、System）に分類し設計するMuleSoftが推奨するAPI設計思想。APIの再利用性を高めシステムの拡張性を高め、サービス追加・機能拡張におけるデリバリーコスト/タイムの削減に貢献する。
• Experience APIの役割
  • 様々なデバイス・システムからのアクセスを担うAPI
• Process APIの役割
  • ビジネスロジックおよびSystem APIの実行を制御するAPI
• System APIの役割
  • 各システムおよびデータへの接続、処理を実行するAPI

本記事によって、MuleSoftにチャレンジしてみようという人の増加に貢献できれば幸いです。
今回はアドベントカレンダーの企画（初日）ということで大まかな内容でしたが、今後もMuleSoftにおける様々なトピックを「誰でもわかる」をモットーに発信していければと思います。

以上