약 3 개월 전, 최신 Eclipse 버전 (네온)이 BPEL 프로젝트를 더 이상 지원하지 않기 때문에 SOA 컴포지션을 설명하는 프리젠 테이션 및 데모를 수행해야했습니다. Eclipse Luna 및 이 상황에서 연장이 도움이되었습니다. 그때부터 내 마음 속에 떠돌아 다니는 몇 가지 질문이 있습니다. 왜 SOA 구성에 관한 새로운 튜토리얼이 없습니까? 이러한 아키텍처는 사용되지 않습니다. 그렇다면 왜 그럴까요?SOA의 오케스트레이션 및 Choregraphie는 사용되지 않는 아키텍처입니까?
나는 SOAP/SOA/ESB/BPEL이 RESTful 아키텍처에 의해 폐기되고 인계 받았다고 생각한다. RESTful은 원시 JSON + HTTP API가있는 것을 의미하지는 않지만 엔드 포인트가 멍청하지는 않지만 실제 워크 플로우의 일부를 정의하는 실제 분산 애플리케이션을 의미한다.
그래서 충돌하는 개념적인 두 가지 사항은 다음과 같습니다. ESB, 순수 BPEL 서비스와 같은 중앙 "스마트"구성 요소와 SOAP 엔드 포인트와 같은 바보 같은 구성 요소를 원합니다. 아니면 중앙 구성 요소와 똑똑한 "끝점"(REST 리소스와 같은)이 없습니까?
저는 개념적으로 후자가 많은 경우에 확실한 승자라고 생각합니다 (틀림없이 모두). 그러나 실용적인 문제가 있습니다. 회사는 항상 중앙 집중화하는 것을 좋아합니다. 중앙 집중화는 특히 "깔끔하고"깔끔하게 보입니다. 특히 엔터프라이즈 설계자에게 적합합니다. 중앙 구성 요소가 비율에서 벗어날 때까지
내 고객 중 한 명만 작년에 ESB를 도입 했으므로 확실히 끝나지 않았습니다. 그러나 나는 우리가 이미 중앙 집중화 된 아키텍처와 단일체를 시도했다고 생각한다. 그들은 항상 "레거시 시스템"저장소에서 끝납니다. 저장소는 모든 것을 수행하기 때문에 바꿀 수 없습니다. 그래서 우리는 그들이 어디로 인도하는지 알기 때문에 다른 것을 시도해야합니다. :)
스마트 엔드 포인트가 혼란에 빠지기 때문에 ESB가 도입되었습니다. ESB는 점차 복잡해지면서 값 비싼 짐승으로 성장했습니다. 우리는 ESB에 질려서 REST로 구현 된 스마트 엔드 포인트로 돌아온다. 간단하고 효율적입니다. 그동안 REST API 게이트웨이 및 스펙이 등장합니다. 우리는 다시 중앙화 추세에 올 수 있습니다. 나는 최선을 다하는 것이 중앙 집중화되어야하며 분배를 떠나기에 더 좋은 선택을하는 것이라고 믿습니다. – KarelHusa