질문 10

서비스 인벤토리에는 송장 관련 데이터 액세스 기능을 제공하는 다음 세 가지 서비스가 포함되어 있습니다: Invoice, InvProc, Proclnv입니다. 이러한 서비스는 서로 다른 프로젝트 팀에 의해 서로 다른 시기에 만들어졌으며 설계 표준을 준수할 필요가 없었습니다. 따라서 이러한 각 서비스에는 인보이스 데이터를 표현하는 서로 다른 데이터 모델이 있습니다.
현재 이 세 가지 서비스에는 각각 다른 서비스 소비자가 있습니다: 서비스 소비자 A는 인보이스 서비스(1)에 액세스하고, 서비스 소비자 B(2)는 InvProc 서비스에 액세스하며, 서비스 소비자 C(3)는 Proclnv 서비스에 액세스합니다. 각 서비스 소비자는 송장 관련 서비스의 데이터 액세스 기능을 호출하여 해당 서비스가 모든 송장 관련 서비스(4, 5, 6)에서 사용하는 공유 계정 데이터베이스와 상호 작용하도록 요구합니다.
또한 서비스 소비자 D는 공유 회계 데이터베이스의 인보이스 데이터에 직접 액세스하도록 설계되었습니다(7). (이 아키텍처의 맥락에서 서비스 소비자 D는 예시된 서비스 아키텍처와 관련된 리소스에 액세스하기 때문에 서비스 소비자로 분류됩니다.) 인보이스 서비스, InvProc 서비스 및 Proclnv 서비스가 동일한 서비스 인벤토리의 일부라고 가정할 때, 공식 엔드포인트 패턴을 완전히 적용하려면 어떤 단계가 필요할까요?

질문 11

서비스 소비자 A가 서비스 A에 메시지를 전송합니다. 현재 서비스 A에는 세 개의 중복 구현(구현 1, 구현 2, 구현 3)이 있습니다. 서비스 소비자 A가 보낸 메시지는 서비스 에이전트 A(1)가 가로채고, 이 에이전트는 런타임에 메시지를 전달할 서비스 A의 구현을 결정합니다. 서비스 A의 세 가지 구현은 모두 동일한 물리적 서버에 상주합니다.
서비스 A의 중복 구현이 존재함에도 불구하고 때때로 성능이 여전히 좋지 않다는 말을 들었습니다. 또한 IT 기업의 다른 많은 클라이언트 및 애플리케이션에서 사용 중인 공유 데이터베이스에 액세스해야 하는 기능을 도입하기 위해 곧 서비스 A에 새로운 서비스 기능을 추가해야 한다는 안내를 받습니다. 이로 인해 서비스 A에 추가적인 성능 요구 사항이 추가될 것으로 예상됩니다.
새로운 서비스 기능 추가에 대비하여 성능을 개선하기 위해 이 서비스 아키텍처를 어떻게 변경할 수 있나요?

질문 12

서비스 A, B 및 C는 비독립적인 작업 서비스입니다. 서비스 A와 서비스 B는 동일한 공유 상태 데이터베이스를 사용하여 런타임에 상태 데이터를 지연시킵니다.
세 서비스를 평가한 결과, 각 서비스에는 불가지론적 로직이 일부 포함되어 있는데, 이는 불가지론적 로직과 함께 번들로 제공되기 때문에 재사용할 수 없는 것으로 나타났습니다.
또한 서비스 A, 서비스 B 및 공유 상태 데이터베이스가 각각 물리적으로 분리된 환경에 있기 때문에 서비스 A와 서비스 B가 공유 상태 데이터베이스와 상호 작용하는 데 필요한 원격 통신으로 인해 런타임 성능이 부당하게 저하되고 있다고 판단합니다.
오케스트레이션 패턴을 적용하면 이 아키텍처를 어떻게 개선할 수 있을까요?

질문 13
전시를 참조하십시오.

서비스 A는 송장 관련 처리를 위한 기능적 컨텍스트가 있는 SOAP 기반 웹 서비스입니다. 서비스 B는 데이터베이스에 대한 일반 데이터 액세스를 제공하는 REST 기반 유틸리티 서비스입니다.
이 서비스 구성 아키텍처에서 서비스 소비자 A는 송장 XML 문서가 포함된 SOAP 메시지를 서비스 A로 보냅니다(1). 그런 다음 서비스 A는 인보이스 XML 문서를 서비스 B로 보내고(2), 서비스 B는 인보이스 문서를 데이터베이스에 기록합니다(3).
서비스 소비자 A가 송장 문서를 표현하는 데 사용하는 데이터 모델은 XML 스키마 A를 기반으로 합니다.
서비스 A의 서비스 계약은 XML 스키마 B를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B의 서비스 계약은 XML 스키마 A를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B가 송장 기록을 작성해야 하는 데이터베이스는 독점적인 쉼표로 구분된 값(CSV) 형식의 전체 비즈니스 문서만 수락합니다.
서비스에서 사용하는 XML 스키마의 비호환성으로 인해 현재 존재하는 서비스를 사용하여 서비스 소비자 A에서 서비스 소비자 B로 송장 문서를 전송할 수 없습니다. 계약 중앙 집중화 패턴이 적용되고 있고 논리 중앙 집중화 패턴이 적용되지 않는다고 가정할 때 런타임 성능 요구 사항을 증가시키는 로직을 추가하지 않고 서비스 소비자 A에서 데이터베이스에 송장 문서를 전송할 수 있도록 하려면 어떤 조치를 취할 수 있나요?

질문 14
전시를 참조하십시오.

서비스 A는 서비스 B에 메시지(2)를 보내 서비스 B가 응답 메시지(3)로 서비스 A에 데이터를 반환하도록 요청하는 작업 서비스입니다. 수신된 응답에 따라 서비스 A는 응답이 필요 없는 서비스 C에 메시지를 보내야 할 수도 있습니다(4).
서비스 A는 서비스 B에 접속하기 전에 먼저 자체 데이터베이스에서 코드 값 목록을 검색한 다음(1) 이 데이터를 자체 메모리에 저장해야 합니다. 서비스 C에 메시지를 보내야 하는 경우 서비스 A는 서비스 B로부터 받은 데이터와 코드 값 목록의 데이터를 결합하여 서비스 C에 보낼 메시지를 만들어야 합니다. 서비스 A가 서비스 C를 호출할 필요가 없는 경우 코드 값을 버림으로써 작업을 완료할 수 있습니다.
서비스 A와 서비스 C는 서비스 인벤토리 A에, 서비스 B는 서비스 인벤토리 B에 상주합니다.
서비스 인벤토리 A의 서비스는 서비스 인벤토리 B의 서비스와 다른 설계 표준 및 기술을 기반으로 하는 서비스 계약으로 설계되었다고 들었습니다. 그 결과 서비스 A는 SOAP 기반 웹 서비스이고 서비스 B는 JSON 형식의 메시지를 교환하는 REST 서비스입니다. 따라서 서비스 A와 서비스 B는 현재 통신할 수 없습니다. 또한 서비스 C는 많은 동시 서비스 소비자가 많이 액세스하는 애그노스틱 서비스입니다. 서비스 C는 사용 임계값에 자주 도달하며, 그 동안에는 서비스를 사용할 수 없고 전송된 메시지가 수신되지 않습니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있나요?

질문 15
전시를 참조하십시오.

서비스 소비자 A와 서비스 A는 서비스 인벤토리 A에 상주합니다. 서비스 B와 서비스 C는 서비스 인벤토리 B에 상주합니다. 서비스 D는 월드와이드웹을 통해 공개적으로 액세스할 수 있는 퍼블릭 서비스입니다. 이 서비스는 IT 기업 내에서 독립적으로 배포할 수 있도록 구매도 가능합니다. 서비스 인벤토리 B에는 서비스 추상화 원칙이 엄격하게 적용되기 때문에 서비스 B와 서비스 C에 대해 제공되는 유일한 정보는 공개된 서비스 계약서뿐입니다. 서비스 D의 경우 서비스 계약과 서비스 수준 계약(SLA)이 제공됩니다. SLA에 따르면 서비스 D는 매일 밤 11시부터 자정까지 계획된 중단이 있습니다.
귀하는 서비스 인벤토리 A에 대한 서비스를 구축하는 프로젝트 팀의 아키텍트로서 서비스 인벤토리 A와 서비스 인벤토리 B의 소유자가 일반적으로 협조적이거나 의사소통이 원활하지 않다는 말을 들었습니다. 교차 인벤토리 서비스 구성은 허용되지만 직접 지원되지는 않습니다. 따라서 서비스 B 및 서비스 C에 대한 SLA를 사용할 수 없으며 이러한 서비스의 사용 가능 여부에 대한 지식이 없습니다. 서비스 계약에 따르면 서비스 인벤토리 B의 서비스는 서비스 인벤토리 A의 서비스와 다른 데이터 모델과 다른 전송 프로토콜을 사용한다는 것을 확인할 수 있습니다. 또한 최근 테스트 결과에 따르면 서비스 D의 성능은 다른 조직의 서비스 소비자로부터 받는 동시 접속량이 많아 예측하기 어렵다는 것을 알 수 있습니다. 또한 서비스 소비자 A가 서비스 인벤토리 A의 응답을 기다리는 동안 얼마나 오랫동안 상태를 유지해야 하는지에 대한 우려가 있다고 들었습니다.
이러한 문제를 해결하기 위해 어떤 조치를 취할 수 있나요?

질문 16

서비스 A는 송장 관련 처리를 위한 기능적 컨텍스트가 있는 SOAP 기반 웹 서비스입니다.
서비스 B는 데이터베이스에 대한 일반 데이터 액세스를 제공하는 REST 기반 유틸리티 서비스입니다.
이 서비스 구성 아키텍처에서 서비스 소비자 A는 송장 XML 문서가 포함된 SOAP 메시지를 서비스 A로 보냅니다(1). 그런 다음 서비스 A는 인보이스 XML 문서를 서비스 B로 보내고(2), 서비스 B는 인보이스 문서를 데이터베이스에 기록합니다(3).
서비스 소비자 A가 송장 문서를 표현하는 데 사용하는 데이터 모델은 XML 스키마 A를 기반으로 합니다.
서비스 A의 서비스 계약은 XML 스키마 B를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B의 서비스 계약은 XML 스키마 A를 기반으로 송장 문서를 수락하도록 설계되었습니다. 서비스 B가 송장 기록을 작성해야 하는 데이터베이스는 독점적인 쉼표로 구분된 값(CSV) 형식의 전체 비즈니스 문서만 수락합니다.
서비스에서 사용하는 XML 스키마의 비호환성으로 인해 현재 존재하는 서비스를 사용하여 서비스 소비자 A에서 서비스 소비자 B로 송장 문서를 전송할 수 없습니다. 계약 중앙 집중화 패턴이 적용되고 있고 논리 중앙 집중화 패턴이 적용되지 않는다고 가정할 때 런타임 성능 요구 사항을 증가시키는 로직을 추가하지 않고 서비스 소비자 A에서 데이터베이스에 송장 문서를 전송할 수 있도록 하려면 어떤 조치를 취할 수 있나요?

질문 17

서비스 A가 서비스 소비자 A(1)로부터 메시지를 받으면 컴포넌트 A가 메시지를 처리합니다. 이 컴포넌트는 먼저 메시지 값을 사용하여 데이터베이스 A를 쿼리하여 추가 데이터를 검색하는 컴포넌트 B(2)를 호출합니다. 그런 다음 컴포넌트 B는 추가 데이터를 컴포넌트 A에 반환하고, 컴포넌트 A는 레거시 시스템의 API와 상호 작용하여 새 데이터 값을 검색하는 컴포넌트 C(3)를 호출합니다.
그런 다음 컴포넌트 C는 데이터 값을 컴포넌트 A로 다시 반환합니다.
다음으로 컴포넌트 A는 축적된 데이터 중 일부를 컴포넌트 D(4)로 전송하고, 컴포넌트 D는 특정 폴더에 있는 텍스트 파일에 데이터를 씁니다. 그런 다음 컴포넌트 D는 정기적으로 예약된 일괄 가져오기를 통해 이 파일을 다른 시스템으로 가져올 때까지 기다립니다. 가져오기가 완료되면 컴포넌트 D는 성공 또는 실패 코드를 컴포넌트 A에 반환합니다. 컴포넌트 A는 마지막으로 지금까지 수집한 모든 데이터가 포함된 응답을 서비스 소비자 A(5)에 보내고 서비스 소비자 A는 모든 데이터를 데이터베이스 B에 씁니다(6).
구성 요소 A, B, C, D는 서비스 A 서비스 아키텍처에 속합니다. 데이터베이스 A, 레거시 시스템 및 파일 폴더는 IT 기업 내에서 공유 리소스입니다.
서비스 A는 지난 몇 년 동안 성장한 서비스 아키텍처를 가진 엔티티 서비스입니다. 서비스 인벤토리 전반의 재설계 프로젝트의 결과로 서비스 소비자 A와 관련된 서비스 A의 동작을 방해하지 않으면서 컴포넌트 B, C, D가 제공하는 로직을 세 가지 유틸리티 서비스로 분리하기 위해 서비스 A 서비스 아키텍처를 다시 검토하라는 요청을 받게 됩니다.
이러한 요구 사항을 충족하기 위해 어떤 조치를 취할 수 있나요?

질문 18

서비스 A는 공유 데이터베이스에서 주기적으로 복제되는 데이터가 포함된 데이터베이스에 일반 데이터 액세스 로직을 제공하는 유틸리티 서비스입니다(1). 서비스 A의 설계에 표준화된 서비스 계약 원칙이 적용되었기 때문에 서비스 계약은 완전히 표준화되었습니다.
서비스 A의 서비스 아키텍처는 세 명의 서비스 소비자가 액세스하고 있습니다. 서비스 소비자 A는 서비스 A 구현의 일부인 컴포넌트를 직접 호출하여 액세스합니다(2). 서비스 소비자 B는 서비스 계약에 액세스하여 서비스 A를 호출합니다(3). 서비스 소비자 C는 서비스 A 구현의 일부인 복제된 데이터베이스에 직접 액세스합니다(4).
서비스 소비자 A와 C가 게시된 서비스 A 서비스 계약을 우회하는 이유는 보안상의 이유로 서비스 A 서비스 계약을 구성하는 API의 기능 하위 집합에 액세스할 수 없기 때문이라고 들었습니다. 부정적인 형태의 결합을 피하면서 이러한 보안 제한을 적용하기 위해 서비스 A 아키텍처를 어떻게 변경할 수 있을까요?

질문 19
전시를 참조하십시오.

서비스 A가 서비스 소비자 A(1)로부터 메시지를 받으면 컴포넌트 A가 메시지를 처리합니다.
이 컴포넌트는 먼저 컴포넌트 B(2)를 호출하여 메시지의 값을 사용하여 데이터베이스 A를 쿼리하여 추가 데이터를 검색합니다. 그런 다음 컴포넌트 B는 추가 데이터를 컴포넌트 A에 반환하고, 컴포넌트 A는 레거시 시스템의 API와 상호 작용하여 새 데이터 값을 검색하는 컴포넌트 C(3)를 호출합니다. 그런 다음 컴포넌트 C는 데이터 값을 다시 컴포넌트 A로 반환합니다.
다음으로 컴포넌트 A는 축적된 데이터 중 일부를 컴포넌트 D(4)로 전송하고, 컴포넌트 D는 특정 폴더에 있는 텍스트 파일에 데이터를 씁니다. 그런 다음 컴포넌트 D는 정기적으로 예약된 일괄 가져오기를 통해 이 파일을 다른 시스템으로 가져올 때까지 기다립니다. 가져오기가 완료되면 컴포넌트 D는 성공 또는 실패 코드를 컴포넌트 A에 반환합니다. 컴포넌트 A는 마지막으로 지금까지 수집한 모든 데이터가 포함된 응답을 서비스 소비자 A(5)에 보내고 서비스 소비자 A는 모든 데이터를 데이터베이스 B에 씁니다(6).
구성 요소 A, B, C, D는 서비스 A 서비스 아키텍처에 속합니다. 데이터베이스 A, 레거시 시스템 및 파일 폴더는 IT 기업 내에서 공유 리소스입니다.
서비스 A는 지난 몇 년 동안 성장한 서비스 아키텍처를 가진 엔티티 서비스입니다. 서비스 인벤토리 전반의 재설계 프로젝트의 결과로 서비스 소비자 A와 관련된 서비스 A의 동작을 방해하지 않으면서 컴포넌트 B, C, D가 제공하는 로직을 세 가지 유틸리티 서비스로 분리하기 위해 서비스 A 서비스 아키텍처를 다시 검토하라는 요청을 받게 됩니다.
이러한 요구 사항을 충족하기 위해 어떤 조치를 취할 수 있나요?

질문 20
전시를 참조하십시오.

서비스 A가 서비스 B에 메시지를 보냅니다(1). 서비스 B가 메시지 내용을 데이터베이스 A에 쓴 후(2), 서비스 A에 응답 메시지를 다시 보냅니다(3). 그런 다음 서비스 A는 서비스 C로 메시지를 보냅니다(4). 이 메시지를 수신한 서비스 C는 서비스 D로 메시지를 보내고(5), 서비스 D는 메시지 내용을 데이터베이스 B에 쓰고(6) 다시 서비스 C로 응답 메시지를 발행합니다(7).
서비스 A 및 서비스 D는 서비스 인벤토리 A에, 서비스 B 및 서비스 C는 서비스 인벤토리 B에 있습니다.
이 서비스 구성 아키텍처에서 네 가지 서비스 모두 송장 관련 데이터를 XML 형식으로 교환하고 있다고 합니다. 그러나 서비스 인벤토리 A의 서비스는 인보이스 데이터에 서비스 인벤토리 B의 서비스와 다른 XML 스키마를 사용하도록 표준화되어 있습니다. 또한 데이터베이스 A는 CSV(쉼표로 구분된 값) 형식의 데이터만 받아들일 수 있으므로 XML 형식의 데이터는 받아들일 수 없습니다. 데이터베이스 B는 XML 형식의 데이터만 허용합니다. 그러나 이 데이터베이스는 서비스 인벤토리 A 또는 서비스 인벤토리 B의 서비스에서 사용하는 XML 스키마와 다른 독점적인 XML 스키마를 사용하여 송장 데이터를 나타내는 레거시 데이터베이스입니다.
이 네 가지 서비스 간에 계획된 데이터 교환을 활성화하려면 어떤 조치를 취할 수 있나요?

질문 21
전시를 참조하십시오.

서비스 A, B 및 C는 비독립적인 작업 서비스입니다. 서비스 A와 서비스 B는 동일한 공유 상태 데이터베이스를 사용하여 런타임에 상태 데이터를 지연시킵니다.
세 서비스를 평가한 결과, 각 서비스에는 불가지론적 로직이 일부 포함되어 있는데, 이는 불가지론적 로직과 함께 번들로 제공되기 때문에 재사용할 수 없는 것으로 나타났습니다.
또한 서비스 A, 서비스 B 및 공유 상태 데이터베이스가 각각 물리적으로 분리된 환경에 있기 때문에 서비스 A와 서비스 B가 공유 상태 데이터베이스와 상호 작용하는 데 필요한 원격 통신으로 인해 런타임 성능이 부당하게 저하되고 있다고 판단합니다.
오케스트레이션 패턴을 적용하면 이 아키텍처를 어떻게 개선할 수 있을까요?

질문 22

클라이언트 및 벤더 서비스는 현재 여러 서비스 구성의 일부인 애그노스틱 서비스입니다. 따라서 이러한 서비스는 때때로 여러 서비스 소비자가 동시에 액세스할 수 있습니다.
클라이언트 서비스는 주로 클라이언트 데이터베이스에 데이터 액세스 로직을 제공하지만 다른 서비스와 협력하여 고객의 신용 등급을 결정하기도 합니다. 벤더 서비스는 일부 데이터 액세스 로직을 제공하지만 특수한 비즈니스 요구 사항에 따라 다양한 동적 보고서를 생성할 수도 있습니다.
두 서비스의 런타임 활동에 대한 과거 통계를 검토한 결과, 클라이언트 서비스가 점점 더 많은 수의 서비스 소비자에게 서비스를 제공하고 있는 것으로 나타났습니다. 이 서비스는 정기적으로 시간이 초과되고 있으며, 이로 인해 서비스 소비자들이 요청을 재시도함에 따라 호출률이 증가합니다. 공급업체 서비스는 때때로 서비스 수준 계약(SLA)을 충족하는 데 어려움을 겪으며, 이러한 상황이 발생하면 페널티가 부과됩니다.
최근 고객 서비스의 관리자는 서비스 인벤토리 외부의 새로운 서비스 소비자에게 고객 서비스를 제공할 것이라는 통지를 받았습니다. 클라이언트 서비스는 인터넷을 통해 서비스에 연결하는 모든 서비스 소비자에게 무료 신용 평가 점수를 제공할 것입니다. 벤더 서비스는 서비스 인벤토리 내부에 유지되며 외부 액세스에 노출되지 않습니다.
다음 중 이러한 문제와 요구 사항을 해결하는 솔루션을 설명하는 문장은 어느 것입니까?