Mule esb architectural styles
0 likes298 views
This document discusses different architectural styles and patterns for integration including service-oriented architecture (SOA) and microservices. It describes SOA components like services, service bus, and service repository. It then explains how Mule ESB can be used to componentize microservices with API policies. The benefits are scalability, reusability and service independence while the downside is longer initial development time. Microservices architecture is described as taking a lightweight distributed approach compared to heavyweight monolithic systems, with minimal centralized management. Common integration patterns are also listed.
Mule esb architectural styles
- 1. MULE ESB: Architectural Styles & Patterns
- 2. Architectural styles Service oriented architecture (SOA) An architectural style that supports service-orientation. Service- orientation is a way of thinking in terms of services and service-based development and the outcomes of services. 2
- 4. Integration Style – MULE ESB 4 Componentize micro services with API policies Pro: • Scalability • Reusability • Promotes services Independence Con: • Longer time-to-value but even bigger ROI
- 5. Architectural styles Microservices Evolved from SOA, but takes a different approach to service design and management Lightweight, distributed model, rather than heavyweight, monolithic model -Often minimal or lightweight management tools 5
- 6. Microservices Based on the concept of lightweight, self contained services Services represent business capabilities Communicating with lightweight mechanisms -Often an HTTP resource API Independently deployable by fully automated deployment machinery Often just a bare minimum of centralized management of these services Lightweight, distributed model, rather than heavyweight, monolithic model Often minimal or lightweight management tools 6
- 7. Advantages Gives developers the freedom to independently develop and deploy services in small teams Code for different services could be in different languages and frameworks Easy integration and automatic deployment Easy to understand and modify for developers, thus can help a new team member become productive quickly The developers can make use of the latest technologies The code is organized around business capabilities 7
- 8. Integration Patterns Existing integration solutions are often modeled after either business processes/functionalities or data flows – A combination of both is not common and could be difficult to design and implement Most integration solutions’ architecture can be deducted into just a few common patterns – Migration – Broadcast – Aggregation – Bi-directional synchronization – Correlation 8
- 9. End
- 10. End