MuleSoft

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

はじめに

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を作る