Apache Camel의 잘못된 사용 사례일까요?

Question

우리는 Java 메소드를 호출하는 많은 (20-50) "직접"경로가있는 Apache Camel을 사용하여 웹 서비스를 구현하고 있습니다. 모든 방법에는 기본적으로 비즈니스 규칙 처리 또는 DAO 액세스 방법을위한 경로가 있습니다. 모든 경로는 from("direct:").to("direct")을 사용하지만 다른 구성 요소에는 사용하지 않습니다.

표준 Controller-> bo-> dao 레이어에서 시스템을 분리하는 것처럼 보일 수도 있지만 불필요한 Camel 루트의 책 보관이 추가됩니다.

보다 나은 대안은 Business Objects 및 Dao 계층에 대한 Java 인터페이스를 정의하고 내부에 종속성이있는 다른 서비스 (시스템 외부의 것, 예 : file:// 또는 http://)에 대한 추가 인터페이스를 정의하는 것일뿐입니다. 비즈니스 개체 또는 컨트롤러. 이 추가 인터페이스 구현은 Apache Camel을 사용하여 외부 서비스와 통신합니다.

나는 현재 동료에게 내 요점을 알도록 설득하는 방법에 대해 생각하고 있습니다.

생각하십니까?

tldr; 응용 프로그램이 1 ~ 2 개 밖에없는 곳에 Apache Camel을 사용해야합니까?

Answer 1

저는 다양한 복잡성, 프로토콜 및 패턴에 20 개의 시스템이 관련된 응용 프로그램을 사용했습니다. 50 개 이상의 시스템이 관련된 다른 장소를 알고 있습니다. 유일한 제한은 디자인, 성능 등에 있습니다.

Apache Camel은 미들웨어 프레임 워크입니다. 본질적으로 비즈니스 로직은 데이터가 전달되는 방식 또는 전달 대상, 전달해야하는 대상 만 알면 안됩니다. 낙타는 나머지를 돌봐야합니다.

그런데 미들웨어가 외부 세계와 이야기하지 않습니까? direct 만 사용하고 다른 구성 요소는 사용하지 않는 이유는 무엇입니까?

또한 bean 통합을 사용하여 미들웨어를 숨길 수 있습니다. 그것은 당신에게 더 많은 디커플링을 제공합니다. 여기를 참조하십시오 : http://camel.apache.org/bean-integration.html

실제로 달성하고자하는 것과 요구 사항에 따라 다릅니다.

Answer 2

특정 사용 사례에 대해 필자는 Camel이 시스템과 외부 세계 사이의 접착제로 사용되는 일반적인 Java 구현으로 더 나아 졌을 것이라고 생각합니다. Souciance explains in his answer처럼 Camel은 여러 시스템과 통합해야 할 때 정말 빛을 발합니다. 따라서 적어도 외부 세계와 의사 소통을해야합니다.

그러나 이미 Camel을 사용하여 시스템의 내부 구조를 구현 한 결과, 현재 Java 구현을 사용하면 순수 Java로 대체하는 데 많은 노력을 기울이는 것이 적절하지 않다고 말할 수 있습니다. 예를 들어, direct 경로를 대체하는 고성능 MQ를 사용하여 시스템을보다 견고하게 만들면 시스템이 장애에 대한 내성을 높이고 나중에 DAO 객체 주위의 경로를 사용하는 것이 아니라 쉽게 분리 될 수 있습니다. 시스템로드가 증가 할 때 DB 업데이트의 일괄 처리를 구현하는 것이 훨씬 쉽습니다.