Edited at

Mulesoftの日本初回 Meets up 参加レポート

More than 1 year has passed since last update.


はじめに

2018年初頭にSalesforceに買収された Mulesoftの日本での初回Meetsup (2018/7/11)に参加してきたので、そのレポートになります

(聴きながら書いているので多少乱文になります)


Session1 : AnyPoint Platform概要と日本市場での状況



  • MuleSoftの基本


    • APIドリブンのアプローチで、組織の変革を引き起こす、デジタルトランスフォーメンションを引き起こす、ことがゴール

    • その根幹となるのがAnypoint Platform

    • Enterprise Integration Platform as a Service (インフォマティカとか) + Full Life Cycle API Management (googleに買収されたApegeeとか)みたいなイメージ




  • API Management とは


    • 間にAPIプラットフォームを挟むことで、バックエンドのDBやフロントエンドのアプリ層が変更されても、柔軟に変更に対応できるとのこと


    • フルライサイクルAPIマネジメントについては詳細は下記のリンクを参照




フルライフサイクルAPI管理 api-lifecycle-management




  • Mulesoftの今後


    • 買収はされたが、SalesForceのものしか連携できない、とかは今後もない

    • MuleSoftにはまだ日本法人がなく、従業員は不在

    • 日本法人の設立時期は、未決定。(近いとはいうものの・・・)

    • AWSの東京リージョンにデプロイできるが、日本法人を介して購入はできない

    • 買いたい場合は北米に直接連携するか、SalesForceに買収される以前に販売チャネルを持っているオージス総研とかに連絡を取る




  • Anypoint Plaftorm


    • APIのDesign, Dev, Test, Deploy, Operate, Scaleまで一気通貫でできる

    • Control Plane で実装、モックアップ、監視、第三者の開発物を共有、とかできる模様


      • Design機能


        • API DesignerでAPIを作成、Mocでテスト、アプリケーションの実装

        • classloaderが入っているためゼロダウンタイムで開発できる



      • Engage機能

      • Manage機能



    • Runtime Plane で実行、横展開


      • Run機能

      • Scale機能






  • 各アプリケーションをAPI化し、APIネットワークにする


    • 新機能の開発や既存の変更に対して、Muleが処理の間に入ることで変更の波及を緩和する

    • APIネットワーク内で不具合が起きた場合、Muleの機能でバグ箇所を検知する

    • Application Networkの中でセキュリティもかけることができる




Session2 : MuleSoftの紹介と3レイヤーアーキテクチャ


  • MuleSoftの開発において重要となるアーキテクチャの説明

  • 一言でまとめると、画面系のフロントエンド層のAPI群とレガシーシステム系のバックエンド系のAPI群の間に、Process系のAPI群を置くことで、画面の変更やレガシーシステムの変更が、ダイレクトに相互に影響を与えないようにする考え方

  • 以下、英語のメモ。重要そうなところは日本語で補強。



  • Why Mulesoft


    • 4.4 bilioon integration transactions per month

    • 1000 + customers

    • 175,000 + developers

    • Engage customerws with various business channels like mobile, web, etc

    • collablolate with partners via new channels

    • accerlerate employee productivity with micro-apps




  • Point to Point Application Integration vs Micro-Service Integration


    • many point of systems with many point of mutual integration, which is impossible to be managed

    • SOA is nice and great idea, but when it comes to big, it'll be chaos

    • the goal of SOA is hard to be achieved




  • Buildding Blocks


    • interface


      • presentation



    • orchastration


      • logic



    • connectiviety


      • acccess to source data






  • Three layer architecture (3 types of API)


    • First Layer (Experience APIs)


      • purposeful APIs

      • Apps Development Team will be responsible for this layer



    • Second Layer (Process APIs)


      • orchestration

      • composable apis

      • micro-services

      • lob Dev Team will be respobsible for this layer



    • Third Layer (System APIs)


      • legacy modernization (connect to legacy system)

      • Central IT Team will be respobsible for this layer



    • 例として出ていたのが、銀行の融資審査


      • First Layerがログインとかの機能を提供

      • Second Layerが与信審査の機能を提供

      • Third LayerがDBから情報を返したりする機能を提供

      • 画面系が変更されても、DBのテーブルに変更があったとしても、それぞれ疎結合になっているため、変更のインパクトが相互にダイレクトには伝わらない






  • Business benefit


    • it as a platform for the business

    • increase developer productivity through re-use

    • more predicable change




  • Technical benefits


    • distributed and tailored approach

    • greater agility through loose coupling of sysetems

    • deeper operational visibility




Session3 : Mule Runtimeのアーキテクチャコンセプト ~EIP、Conversation Patterns、SEDA、Non-blocking~



  • システム間連携は考慮点が多く簡単ではない


    • 同期なのか非同期なのか、リアルタイムなのかバッチなのか、1:1, N:1, N:Nなのか

    • データサイズ

    • 連携頻度

    • プロトコル、データ形式

    • 経路の信頼性、エラー処理




  • EIP (enterprise integration patterns)


    • システム連携にパターンを65種類を網羅した本

    • Mule, Camel, Spring Integration

    • システム連携の共通言語、連携アーキテクチャの議論の出発点




  • システム関連系のパターン


    • fire and forget

    • asynchronous request-response

    • request-response with retry

    • polling

    • subscribe-notify

    • quick acknowledgment




  • 一貫性に関するパターン


    • ignore error

    • compensating action

    • tentative operation

    • coordinated areement




  • Mule3からMule4での大きな更新


    • セルフチューニング


      • システム間連携の時のチューニングをよしなにやってくれる模様






Session4 : Mule ESBを使ってデータベースへのRESTfulなWeb APIを作る

内容やソースはQiitaとGitで公開されているので、そちらを参照


Mule ESBを使ってデータベースへのRESTfulなWeb APIを作る