Apache Camel-소개
인도의 Bigbasket과 같은 마을의 대형 온라인 식료품 점에서 IT 솔루션을 설계하도록 초대하는 상황을 생각해보십시오. 안정적이고 확장 가능한 솔루션은 오늘날 직면하고있는 소프트웨어 유지 관리 문제를 극복하는 데 도움이됩니다. 이 온라인 상점은 지난 10 년 동안 사업을 운영해 왔습니다. 상점은 고객으로부터 다양한 범주의 제품에 대한 온라인 주문을 수락하고이를 각 공급 업체에 배포합니다. 예를 들어 비누, 기름, 우유를 주문한다고 가정 해 보겠습니다. 이 세 가지 품목은 각각의 공급자에게 배포됩니다. 그런 다음 세 공급 업체는 전체 주문이 배송 센터에서 처리되는 공통 배포 지점으로 소모품을 보냅니다. 이제 그들이 현재 직면하고있는 문제를 살펴 보겠습니다.
이 상점이 사업을 시작했을 때 쉼표로 구분 된 일반 텍스트 파일로 주문을 받고있었습니다. 일정 기간 동안 상점은 메시지 기반 주문 배치로 전환되었습니다. 나중에 일부 소프트웨어 개발자는 XML 기반 주문 배치를 제안했습니다. 결국 상점은 웹 서비스 인터페이스까지 적용했습니다. 이제 진짜 문제가 있습니다. 주문은 이제 다른 형식으로 제공됩니다. 분명히 회사가 주문 수락 형식을 업그레이드 할 때마다 고객의 마음에 혼란을 일으키지 않도록 이전에 배포 된 인터페이스를 깨고 싶지 않았습니다.
동시에 비즈니스가 계속 성장함에 따라 매장은 정기적으로 새로운 공급 업체를 레퍼토리에 추가했습니다. 그러한 각 공급자는 주문을 수락하기위한 자체 프로토콜을 가지고 있습니다. 다시 한 번 통합 문제에 직면 해 있습니다. 당사의 애플리케이션 아키텍처는 고유 한 주문 배치 메커니즘으로 새로운 공급 업체를 수용 할 수 있도록 확장 가능해야합니다.
전체 상황은 다음 그림에 나와 있습니다.
이제 Apache Camel이 설명 된 시나리오에 대해 우아하고 유지 관리 가능하며 확장 가능한 솔루션 아키텍처를 제공하기 위해 어떻게 구출 할 수 있는지 살펴 보겠습니다.
솔루션을 진행하기 전에 작은 가정을해야합니다. 이 튜토리얼의 모든 논의를 위해 온라인 주문이 XML 형식으로 이루어 졌다고 가정합니다. 토론 전체에서 사용할 주문 파일의 일반적인 형식은 다음과 같습니다.
<?xml version = "1.0" encoding = "UTF-8"?>
<OrderID Order = "001">
<order product = "soaps">
<items>
<item>
<Brand>Cinthol</Brand>
<Type>Original</Type>
<Quantity>4</Quantity>
<Price>25</Price>
</item>
<item>
<Brand>Cinthol</Brand>
<Type>Lime</Type>
<Quantity>6</Quantity>
<Price>30</Price>
</item>
</items>
</order>
<order product = "Oil">
<items>
<item>
<Brand>Saffola</Brand>
<Type>Gold</Type>
<Quantity>2</Quantity>
<Price>649</Price>
</item>
<item>
<Brand>Fortune</Brand>
<Type>Sunlite</Type>
<Quantity>1</Quantity>
<Price>525</Price>
</item>
</items>
</order>
<order product = "Milk">
<items>
<item>
<Product>Milk</Product>
<Brand>Amul</Brand>
<Type>Pure</Type>
<Quantity>2</Quantity>
<Price>60</Price>
</item>
</items>
</order>
</OrderID>
이 튜토리얼의 Camel 예제를 설명하기 위해 위의 XML 템플릿을 사용할 것입니다.