두 프레임 워크는 모두 동일한 목표를 공유합니다.
중재, 라우팅, 프로토콜 적응과 같은 일반적인 통합 작업을 구현하기위한 사용하기 쉬운 메커니즘을 제공합니다. 작은 설치 공간과 오버 헤드로 눈에 띄지 않는 방식으로 기존에 임베딩 할 수 있습니다. 애플리케이션 인프라. 기본적으로 JMX를 통한 기본 관리 지원뿐만 아니라 상당한 양의 전송 어댑터등의 구현.
기능적 관점에서 볼 때 두 프레임 워크는 상당히 동일합니다.
Apache Camel은 2007 년에 버전 1.0으로 출시되었습니다. 버전 1.0부터 Java XML뿐만 아니라 Java DSL과 Spring XML을 기반으로 만들어진 XML DSL이 함께 제공됩니다. 현재 버전 까지 다양한 언어로 추가 DSL이 있습니다.
Spring Integration은 2 년 후, 2009 년에 버전 1.0.0에서 발표되었습니다. Spring 계열의 일부이기 때문에 XML 기반 구성이 처음에는 유일한 선택 이었지만 최근부터 Spring Integration은 Java DSL을 제공합니다.
하나의 특정 구문이 다른 구문보다 우수하다고 주장 할 수 있지만, 이는 개인적인 취향의 문제 일뿐입니다. 더 흥미로운 것은 의미론적 차이입니다. 여기 미묘하면서도 Apache Camel과 Spring Integration의 중요한 차이점이 있습니다. 표현력은 거의 같지만 Spring Integration DSL은 채널, 게이트웨이 등 하위 수준의 EIP를 노출합니다. Camel DSL은 통합의 의도에 더 중점을 두는 것처럼 보입니다 . 통합 코드는 일반적으로 작성된 것보다 더 자주 읽혀 지기 때문에 의사를 명확하고 간결하게 전달할 수있는 능력이 핵심적인 차별 요소입니다.
Spring Integration과 Apache Camel 샘플 코드를 살펴보면
Spring Integration은 다음과 같습니다 :
@MessagingGateway
public interface Cafe {
@Gateway(requestChannel = "orders.input")
void placeOrder(Order order);
}
private AtomicInteger hotDrinkCounter = new AtomicInteger();
private AtomicInteger coldDrinkCounter = new AtomicInteger();
@Bean(name = PollerMetadata.DEFAULT_POLLER)
public PollerMetadata poller() {
return Pollers.fixedDelay(1000).get();
}
@Bean
public IntegrationFlow orders() {
return f -> f
.split(Order.class, Order::getItems)
.channel(c -> c.executor(Executors.newCachedThreadPool()))
.<OrderItem, Boolean>route(OrderItem::isIced, mapping -> mapping
.subFlowMapping("true", sf -> sf
.channel(c -> c.queue(10))
.publishSubscribeChannel(c -> c
.subscribe(s ->
s.handle(m -> sleepUninterruptibly(1, TimeUnit.SECONDS)))
.subscribe(sub -> sub
.<OrderItem, String>transform(item ->
Thread.currentThread().getName()
+ " prepared cold drink #"
+ this.coldDrinkCounter.incrementAndGet()
+ " for order #" + item.getOrderNumber()
+ ": " + item)
.handle(m -> System.out.println(m.getPayload())))))
.subFlowMapping("false", sf -> sf
.channel(c -> c.queue(10))
.publishSubscribeChannel(c -> c
.subscribe(s ->
s.handle(m -> sleepUninterruptibly(5, TimeUnit.SECONDS)))
.subscribe(sub -> sub
.<OrderItem, String>transform(item ->
Thread.currentThread().getName()
+ " prepared hot drink #"
+ this.hotDrinkCounter.incrementAndGet()
+ " for order #" + item.getOrderNumber()
+ ": " + item)
.handle(m -> System.out.println(m.getPayload()))))))
.<OrderItem, Drink>transform(orderItem ->
new Drink(orderItem.getOrderNumber(),
orderItem.getDrinkType(),
orderItem.isIced(),
orderItem.getShots()))
.aggregate(aggregator -> aggregator
.outputProcessor(group ->
new Delivery(group.getMessages()
.stream()
.map(message -> (Drink) message.getPayload())
.collect(Collectors.toList())))
.correlationStrategy(m ->
((Drink) m.getPayload()).getOrderNumber()), null)
.handle(CharacterStreamWritingMessageHandler.stdout());
}
}
여기에는 꽤 많은 세부 사항이 있습니다. 하지만 요점은 게이트웨이 및 채널을 상위 레벨 EIP를 구현하는 데 사용하는 것입니다.
반대로Apache Camel은 기술 도메인보다 "비즈니스"에 더 가까운 어휘를 사용하여 상위 EIP에 중점을 둡니다.
public void configure() {
from("direct:cafe")
.split().method("orderSplitter")
.to("direct:drink");
from("direct:drink").recipientList().method("drinkRouter");
from("seda:coldDrinks?concurrentConsumers=2")
.to("bean:barista?method=prepareColdDrink")
.to("direct:deliveries");
from("seda:hotDrinks?concurrentConsumers=3")
.to("bean:barista?method=prepareHotDrink")
.to("direct:deliveries");
from("direct:deliveries")
.aggregate(new CafeAggregationStrategy())
.method("waiter", "checkOrder").completionTimeout(5 * 1000L)
.to("bean:waiter?method=prepareDelivery")
.to("bean:waiter?method=deliverCafes");
}
합의한 두 예제는 직접 비교할 수 없습니다.
하지만 접근 방식의 근본적인 차이가 분명히 드러났습니다.
Spring Integration과 Apache Camel은 잘 설계되고 매우 능력있는 경량 통합 프레임 워크입니다. 기능 측면에서 보았을 때, 그들은 어느 정도 평등합니다. 그 중 어떤 것도 제가 현재 일하고있는 과제에서 탁월한 선택이 될 것입니다. 그러나 저처럼 선택의 여지가있는 사람이라면 Apache Camel DSL의 의미 론적 표현력, 특정 통합 흐름의 의도를 명확하게 전달할 수있는 능력이 중요한 경쟁력이라고 생각합니다.
원문
http://callistaenterprise.se/blogg/teknik/2015/10/12/apache-camel-vs-spring-integration/
