MuleSoft-Mule 프로젝트

Mule 프로젝트의 동기는 다음과 같습니다.

  • 프로그래머를 위해 일을 더 간단하게 만들기 위해

  • 애플리케이션 수준 메시징 프레임 워크에서 전사적으로 분산 가능한 프레임 워크로 확장 할 수있는 경량 및 모듈 식 솔루션의 필요성.

Mule ESB는 이벤트 기반 및 프로그래밍 프레임 워크로 설계되었습니다. 메시지의 통합 표현과 결합되고 플러그 형 모듈로 확장 할 수 있기 때문에 이벤트 기반입니다. 프로그래머가 특정 메시지 처리 또는 사용자 지정 데이터 변환과 같은 일부 추가 동작을 쉽게 이식 할 수 있기 때문에 프로그래밍 방식입니다.

역사

Mule 프로젝트의 역사적 관점은 다음과 같습니다.

SourceForge 프로젝트

Mule 프로젝트는 2003 년 4 월 SourceForge 프로젝트로 시작되었으며 2 년 후 첫 번째 버전이 출시되어 CodeHaus로 옮겨졌습니다. UMO (Universal Message Object) API는 아키텍처의 핵심이었습니다. UMO API이면의 아이디어는 로직을 통합하면서 기본 전송에서 격리하는 것이 었습니다.

버전 1.0

2005 년 4 월에 수많은 수송을 포함하여 출시되었습니다. 그 뒤를 잇는 다른 많은 버전의 주요 초점은 디버깅 및 새로운 기능 추가였습니다.

버전 2.0 (Spring 2 채택)

구성 및 배선 프레임 워크로서 Spring 2가 Mule 2에서 채택되었지만 필요한 XML 구성의 표현력이 부족하기 때문에 대대적 인 점검이되었습니다. 이 문제는 Spring 2에서 XML Schema 기반 구성이 도입되었을 때 해결되었습니다.

Maven으로 빌드

개발 및 배포시 Mule 사용을 단순화 한 가장 큰 개선 사항은 Maven을 사용하는 것입니다. 버전 1.3부터 ​​Maven으로 구성되기 시작했습니다.

MuleSource

2006 년 MuleSource는 "미션 크리티컬 엔터프라이즈 애플리케이션에서 Mule을 사용하여 빠르게 성장하는 커뮤니티를 지원하고 활성화하기 위해"통합되었습니다. 그것은 Mule Project의 핵심 이정표임을 입증했습니다.

Mule ESB의 경쟁자

다음은 Mule ESB의 주요 경쟁 업체입니다.

  • WSO2 ESB
  • Oracle 서비스 버스
  • WebSphere 메시지 브로커
  • Aurea CX 플랫폼
  • Fiorano ESB
  • WebSphere DataPower 게이트웨이
  • Workday 비즈니스 프로세스 프레임 워크
  • Talend 엔터프라이즈 서비스 버스
  • JBoss 엔터프라이즈 서비스 버스
  • iWay 서비스 관리자

뮬의 핵심 개념

논의한 바와 같이 Mule ESB는 가볍고 확장 성이 뛰어난 Java 기반 ESB (Enterprise Service Bus) 및 통합 플랫폼입니다. 응용 프로그램에서 사용하는 다양한 기술에 관계없이 Mule ESB를 사용하면 응용 프로그램을 쉽게 통합하여 데이터를 교환 할 수 있습니다. 이 섹션에서는 이러한 통합이 이루어 지도록하는 Mule의 핵심 개념에 대해 논의합니다.

이를 위해서는 아키텍처와 빌딩 블록을 이해해야합니다.

건축물

Mule ESB의 아키텍처는 다음 다이어그램과 같이 전송 계층, 통합 계층 및 응용 프로그램 계층의 세 계층으로 구성됩니다.

일반적으로 Mule 배포를 구성하고 사용자 지정하기 위해 수행 할 수있는 세 가지 유형의 작업이 있습니다.

서비스 구성 요소 개발

이 작업에는 기존 POJO 또는 Spring Bean을 개발하거나 재사용하는 작업이 포함됩니다. POJO는 get 및 set 메서드, 클라우드 커넥터를 생성하는 속성이있는 클래스입니다. 반면 Spring Beans에는 메시지를 풍부하게하는 비즈니스 로직이 포함되어 있습니다.

서비스 오케스트레이션

이 태스크는 기본적으로 메시지 프로세서, 라우터, 변환기 및 필터 구성과 관련된 서비스 중개를 제공합니다.

완성

Mule ESB의 가장 중요한 작업은 사용중인 프로토콜에 관계없이 다양한 응용 프로그램을 통합하는 것입니다. 이를 위해 Mule은 다양한 프로토콜 커넥터에서 메시지를 수신하고 발송할 수있는 전송 방법을 제공합니다. Mule은 기존의 많은 전송 방법을 지원하거나 사용자 지정 전송 방법을 사용할 수도 있습니다.

빌딩 블록

노새 구성에는 다음과 같은 구성 요소가 있습니다.

봄 콩

Spring Bean의 주요 용도는 서비스 컴포넌트를 구성하는 것입니다. 스프링 서비스 컴포넌트를 구축 한 후, 설정 파일이없는 경우 설정 파일을 통해 또는 수동으로 정의 할 수 있습니다.

자치령 대표

기본적으로 Mule Studio 이전에 Anypoint Studio에서 만든 서비스입니다. 에이전트는 서버를 시작하면 생성되고 서버를 중지하면 삭제됩니다.

커넥터

프로토콜에 특정한 매개 변수로 구성된 소프트웨어 구성 요소입니다. 주로 프로토콜 사용을 제어하는 ​​데 사용됩니다. 예를 들어 JMS 커넥터는Connection 그리고이 커넥터는 실제 통신을 담당하는 다양한 주체간에 공유됩니다.

글로벌 구성

이름에서 알 수 있듯이이 빌딩 블록은 전역 속성 및 설정을 지정하는 데 사용됩니다.

글로벌 엔드 포인트

한 흐름에서 여러 번 사용할 수있는 글로벌 요소 탭에서 사용할 수 있습니다.

글로벌 메시지 프로세서

이름에서 알 수 있듯이 메시지 또는 메시지 흐름을 관찰하거나 수정합니다. 변환기 및 필터는 글로벌 메시지 프로세서의 예입니다.

Transformers− 변환기의 주요 작업은 데이터를 한 형식에서 다른 형식으로 변환하는 것입니다. 전역 적으로 정의 할 수 있으며 여러 흐름에서 사용할 수 있습니다.

Filters− 어떤 Mule 메시지를 처리해야하는지 결정하는 필터입니다. 필터는 기본적으로 메시지를 처리하고 서비스로 라우팅하기 위해 충족해야하는 조건을 지정합니다.

모델

에이전트와 달리 스튜디오에서 생성되는 서비스의 논리적 그룹입니다. 특정 모델 내에서 모든 서비스를 시작하고 중지 할 수있는 자유가 있습니다.

Services− 서비스는 비즈니스 로직 또는 구성 요소를 감싸는 서비스입니다. 또한 해당 서비스에 대해 특별히 라우터, 엔드 포인트, 변환기 및 필터를 구성합니다.

Endpoints− 서비스가 메시지를 인바운드 (수신) 및 아웃 바운드 (송신)하는 객체로 정의 할 수 있습니다. 서비스는 끝점을 통해 연결됩니다.

흐름

메시지 프로세서는 흐름을 사용하여 소스와 대상 간의 메시지 흐름을 정의합니다.

뮬 메시지 구조

Mule Message Object 아래에 완전히 래핑 된 Mule 메시지는 Mule 흐름을 통해 애플리케이션을 통과하는 데이터입니다. 구조 Mule의 메시지는 다음 다이어그램에 표시됩니다.

위의 다이어그램에서 볼 수 있듯이 Mule Message는 두 가지 주요 부분으로 구성됩니다.

머리글

다음 두 가지 속성으로 더 표현되는 메시지의 메타 데이터 일뿐입니다.

Inbound Properties− 메시지 소스에 의해 자동으로 설정되는 속성입니다. 사용자가 조작하거나 설정할 수 없습니다. 본질적으로 인바운드 속성은 변경할 수 없습니다.

Outbound Properties− 인바운드 속성과 같은 메타 데이터를 포함하는 속성이며 흐름 과정에서 설정할 수 있습니다. Mule이 자동으로 설정하거나 사용자가 수동으로 설정할 수 있습니다. 본질적으로 아웃 바운드 속성은 변경 가능합니다.

아웃 바운드 속성은 메시지가 한 흐름의 아웃 바운드 끝점에서 전송을 통해 다른 흐름의 인바운드 끝점으로 전달 될 때 인바운드 속성이됩니다.

아웃 바운드 속성은 메시지가 커넥터가 아닌 flow-ref를 통해 새 흐름으로 전달 될 때 아웃 바운드 속성으로 유지됩니다.

유효 탑재량

메시지 객체가 전달하는 실제 비즈니스 메시지를 페이로드라고합니다.

변수

메시지에 대한 사용자 정의 메타 데이터로 정의 할 수 있습니다. 기본적으로 변수는 메시지를 처리하는 응용 프로그램에서 사용하는 메시지에 대한 임시 정보입니다. 메시지와 함께 대상으로 전달되는 것은 아닙니다. 아래에 주어진 세 가지 유형이 있습니다.

Flow variables − 이러한 변수는 해당 변수가 존재하는 흐름에만 적용됩니다.

Session variables − 이러한 변수는 동일한 응용 프로그램 내의 모든 흐름에 적용됩니다.

Record variables − 이러한 변수는 배치의 일부로 처리 된 레코드에만 적용됩니다.

첨부 파일 및 추가 페이로드

이는 메시지 객체에 매번 나타날 필요는없는 메시지 페이로드에 대한 추가 메타 데이터입니다.