はじめに
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機能
- Design機能
-
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
- interface
-
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で公開されているので、そちらを参照