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](https://www.mulesoft.com/lp/ebook/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を作る](https://qiita.com/rsogo/items/38d3eb3dd5d2f52c432d)