SOA 서비스 구성은 실제로 실제로 작동합니까?

주요 SOA 서비스 디자인 원칙 중 하나는 서비스 구성 원칙 ( https://en.wikipedia.org/wiki/Service_composability_principle )입니다.

아이디어는 기존 서비스를 빌딩 블록으로 사용하여 새로운 서비스를 구성함으로써 새로운 서비스를 신속하게 개발할 수 있다는 것입니다. 새로운 메소드를 구현할 때 객체의 exising 메소드를 호출하는 방식과 유사합니다. 여기에서 SOA의 생산성 향상이 많이 발생합니다.

실제로 실제로 이것을하는 사람이 있습니까? 나는 이것이 글로 끝없이 반복되는 것을 보았지만 실제 구현을 직접 경험하지는 못했습니다. 대부분의 텍스트는 트랜잭션 처리에 대한 언급을 생략했으며 , 이는 컴포저 블 서비스를 실현하는 데 가장 큰 장애물 인 것 같습니다.

먼저, 사소한 서비스를 작성하기 전에 트랜잭션 문제를 해결해야합니다. 예를 들어 서비스에 "findCurrentTime ()"및 "writeLogMessage ()"서비스가있는 경우 트랜잭션에 대해 걱정하기 쉽지만 "depositMoney ()"및 "withdrawMoney ()"와 같은 실제 예제는 없을 수 있습니다.

두 가지 옵션을 알고 있습니다.

1. WS-Atomic Transaction 등으로 실제 트랜잭션 구현
2. "cancelA ()"를 사용하여 A에 대한 호출을 보상하거나 B에 대한 호출이 실패하는 경우를 보상하는 보상 기반 솔루션 구현

이 두 가지 모두 나에게 매우 문제가 있거나 거의 사용할 수없는 것 같습니다.

• WS- 원자 거래
  • 많은 복잡성, 내가 발견 한 대부분의 조언은 단지 경고 "엉덩이에 통증을, 그나마 그것을 할"
  • 지원이 제한되어 있습니다 (예 : 오픈 소스 ESB를 사용하는 경우 주요 대안 ServiceMix, Mule 또는 WSO2는이를 지원하지 않습니다)
• 보상
  • 보상 처리를 구현하는 것은 매우 복잡해 보입니다. 서비스 A가 성공하고 서비스 B로부터 응답을 얻지 못하고 실패했는지 또는 성공했는지 모른다면 어떻게해야합니까? 이러한 합성을 수동으로 처리하면 (컴 포지 팅 서비스의 구현 자로서) 손목이 찢어 지길 원합니다. 이것은 어떤 도구가 나를 위해해야 ​​할 일입니다!.
  • 나는 또한 당신이 사소한 서비스에서 보상 방법을 가질 수있는 방법을 보지 못했습니다. 서비스 A가 "depositMoney ()"이고 성공하면 다른 조치로 다른 곳으로 돈을 빨리 이체 한 다음 "compensateDepositMoney ()"를 받으면 어떻게해야합니까? 큰 벌레 캔처럼 보입니다.

나에게 서비스 구성은 서비스를 (편리하게) 작성할 수 없다면 SOA의 이점을 얻지 못하는 근본적인 SOA 원칙 인 것 같습니다 . 현실은 무엇입니까? SOA 사용자의 90 %가 실제 서비스 구성없이 "편리한 SOA"를 사용하고 있습니까? 아니면 대부분의 사용자가 실제로 서비스 구성을 사용하는데 어려움을 과장하고 있습니까?

짧은 대답은 예입니다!

나는 이것이 여러 대규모 금융 기관에서 이루어졌으며 잘 작동했습니다.

트랜잭션 문제는 복잡하지만 일반적으로 Oracles WebLogic EAI 또는 IBMs Websphere ESB와 같은 (비싼) 미들웨어에 의해 처리됩니다.

예, 실제로 작동하도록 만들 수 있습니다. 그러나이 방법이 최선의 방법이 아닐 수 있으며 기본 옵션으로 사용해야 할 수도 있습니다. 제 생각에 SOA는 레거시 시스템을 통합하는 방법으로 널리 보급되었습니다. 조직이 IT를 발전시켜 더 큰 작업을 자동화함에 따라 레거시 시스템을 재사용 할 수 있다면 매우 지저분하지만 그만한 가치가 있습니다. 그린 필드 프로젝트를 시작하기에 운이 좋으면 가장 좋은 방법이라고 가정하기 전에 다른 접근법을 고려해야합니다.

좀 더 구체적인 문제에 답하기 위해 ...

트랜잭션을 사용할 수 있습니다.

1. WS-TX는 PITA이므로 피할 것입니다.
2. 모든 서비스가 단일 애플리케이션 서버에서 실행 중일 수 있으며,이 경우 모든 서비스를 XA 트랜잭션으로 확장 할 수 있습니다. 이것이 응용 프로그램 서버와 같은 것들이 발명 된 이유입니다.

보상 기반 접근법을 고려할 때 :

보상 조치는 장애가 발생한 경우에만 고려해야합니다. 서비스 컴포지션 도구에는 워크 플로 단계를 처음 실행할 때 지워지지 만 후속 호출에서 설정되는 제어 할 수있는 플래그가 있습니까? JMS에서 가능한 재전송 플래그와 같습니다. 그런 다음 1.5 단계 커밋이라는 것을 사용할 수 있습니다.이 플래그는 기본적으로 플래그가 지워지면 계속 진행되지만 플래그가 설정된 경우 먼저 상태가 이미 업데이트되어 두 번째로 작성되어야하는지 확인하기 위해 호출합니다. . 여기에는 여전히 수동 오류 처리가 필요하며 지적한대로 복잡하거나 불가능할 수 있습니다.

어떤 상황에서는 중요하지 않습니다.

이것이 궁극적으로 일관된 접근 방식입니다. 한 서비스가 이메일을 보낸다고 가정합니다. 서비스 구성이 실패하고 다시 시작되면 이메일이 다시 전송됩니다. 받는 사람에게는 약간 성가신 일이지만 복제본을 알고 아마도 많은 문제없이 계속할 수 있습니다.

또한 전송 된 이메일 로그를 보관하고 플래그가 설정 될 때 중복 제거에이를 사용하여 이메일을 한 번만 보낼 수 있습니다.

비동기 메시징을 사용하여 트랜잭션을 더 작은 조각으로 나눌 수 있습니다.

트랜잭션 인 JMS 큐를 고려하십시오. 서비스 조정자는 상태를 업데이트하고 단일 Tx에서 큐에 메시지를 게시 할 수 있습니다. 다운 스트림 서비스는 단일 Tx에서 메시지를 해제하고 상태를 업데이트 할 수 있습니다. 이제 여러 작업 단위로 서비스를 조정하고 있지만 각각은 원자 적입니다. 문제가 발생하여 다시 시작해야하는 경우 아무런 문제가 없습니다.

이것은 여전히 ​​데이터베이스와 JMS 큐를 통해 XA 트랜잭션을 수행하고 있음을 의미하지만 XA의 전체 오버 헤드를 피하기 위해 마지막 리소스 bit 비트를 사용하는 것이 여전히 효율적일 수 있습니다.

또는이 패턴을 사용할 수 있지만 데이터베이스 및 JMS에 대한 1.5 단계 커밋이 있습니다. 또는 트랜잭션없이 JMS를 실행할 수 있지만 클러스터링을 통해보다 안정적으로 만들 수 있습니다.

또한 비동기 메시징은 생산자와 소비자가 더 독립적이되어 전체 시스템의 커플 링 양을 줄이고보다 유연하게 만들 수 있으므로 시스템 분리에 도움이 될 수 있습니다. 이러한 종류의 분리는 다양한 서비스가 많은 대기업에있어 매우 중요합니다.

아니요, 신화입니다. 이것은 서비스 아키텍처를 설계 할 때 의도가 잘못되었습니다. 많은 문제가 있습니다.

1. 매우 타이트한 커플 링. 하나의 서비스가 변경된 경우 전체 시스템을 테스트해야합니다.
2. 이러한 서비스는 매우 세분화되어 내부 커뮤니케이션이 많이 있습니다.
3. 세분화 된 결과 많은 서비스가 있습니다. 시스템이 이해하기 어려워지고 쿼리를 추적하기가 점점 어려워지고 있습니다.
4. 엔터티 서비스 가 제대로 캡슐화되지 않았습니다. 비즈니스 규칙이 확인되지 않았으며이 논리는 운영 서비스에 있습니다. 따라서 모든 서비스는 모든 엔티티 서비스를 호출하고 인터페이스에있는 공통 업데이트 쿼리로 데이터를 업데이트 할 수 있습니다. 이러한 종류의 엔티티 서비스는 종종 프로세스 중심의 행동 중심 서비스와 달리 데이터 중심이라고합니다.
5. 이 서비스들 간의 의사 소통의 본질은 동 기적입니다. 따라서 선택한 전송이 http 일 가능성이 있습니다. 따라서 나중에 이야기 할 모든 단점이 있습니다.

서비스 아키텍처에 접근하는 더 잘못된 방법이 있습니다 . 그러니 조심하십시오.