OO 변경 될 통신 방법에 대한 설계

Question

저는 독립 실행 형 시스템 (API를 통해)과 데이터베이스의 "외관"역할을하는 웹 서비스를 만드는 프로젝트를 진행하고 있습니다. 웹 서비스는 별도의 웹 응용 프로그램이 이러한 외부 리소스와 통신하는 데 사용할 유일한 방법입니다.

웹 서비스가 통신해야하는 API 중 하나의 통신 방법론이 미래의 일부 미정의 지점에서 변경된다는 사실을 알고 있습니다.

나는 웹 서비스 자체가 웹 애플리케이션과 외부 API 사이의 통신 방법론 변경의 세부 사항을 추상화 할 것으로 기대한다. 나의 주요 관심사는 웹 서비스의 내부를 디자인하는 방법이다. OO 설계를 사용하여 의사 소통 방법의 변경 사항을 깨끗하게 처리 할 수 ​​있도록 적절한 수준의 추상화를 만드는 데 필요한 몇 가지 규정 된 방법은 무엇입니까? 권장되는 디자인 패턴이 있습니까?

Answer 1

앞에서 설명한 것처럼 외관 패턴을 이미 사용하고있는 것처럼 들립니다. 웹 서비스는 실제로 다른 서비스의 외관입니다. 웹 서비스와 외부 리소스 중 하나 사이의 API가 변경되면 핵심은 웹 서비스 자체의 API에 영향을주지 않도록하는 것입니다. 웹 서비스 사용자는 웹 서비스가 외부 리소스와 통신하는 방법을 내부적으로 알 필요가 없습니다.

예를 들어 웹 서비스에 doX 및 doY 메소드가있는 경우 doX 및 doY 호출자 중 어떤 것도 후드에서 처리하지 않아야합니다. 따라서 웹 서비스 클라이언트와 웹 서비스간에 API를 유지하는 한 설정해야합니다.

Answer 2

필자는 종종 새로운 외관 (일반적으로 Java 클래스)을 가지고 비슷한 문제를 겪었고 결국 다른 곳에있는 서비스와 통신 할 수있는 새로운 "미들웨어"를 접하게되었습니다.

나는 인 - 프로세스 (in-process)를 포함하여 네트워크를 통해 (종종 암호화를 사용하여) 다양한 통신 매체를 지원해야합니다.

내 일반적인 솔루션은 특정 형식의 데이터 (예 : 특정 응답, 특정 요청) 등을 포함하는 하위 유형이있는 데이터 패킷의 개념을 정의하는 것입니다. 중요한 것은 모든 패킷이 어떤 형식으로 Serializable (자바에는 이것에 대한 개념이있다. C++에 대해서는 잘 모르겠다.)

다음 상담원과 제공 업체가 있습니다. 에이전트는 프로그램 도메인 요청을 받아서 packats를 만듭니다. 의사 소통을 담당하는 스텁 - 스켈레톤으로 이동시킵니다. 원격 스텁은 패킷을 가져 와서 공급자에게 제공합니다. 공급자는이를 도메인 개체로 다시 변환하여 실제 서비스에 제공합니다. 응답을 받거나 스켈레톤 스텁 등을 통해 에이전트로 다시 보냅니다.

이 접근법의 장점은 몇 가지 추상화 계층을 생성한다는 것입니다. 에이전트/제공자는 도메인 수준과 패킷으로의 변환 및 역 집중에 초점을 맞 춥니 다. skeleton-stub 쌍은 패킷을 앞뒤로 marhsalling하고 보내는 역할을합니다. 하위 유형과 내 스켈레톤 스텁 쌍을 서로 바꿈으로써 동일한 프로그램이 다른 방법으로 통신하도록 할 수 있습니다 (예 : JMS와 같은 것을 통해 같은 JVM에 임베드 됨, 소켓을 통해 직접 연결됨)

Answer 3

사용자가 만든 서비스 (사용자 입장에서). 서비스는 계약과 관련되어 있습니다. 서비스는 사용자와 계약을 맺을 것이고 특정 요청을 보내고 특정 응답을 되돌려 보낼 것입니다. 또한이 다른 API와 계약을 맺습니다. 의사 소통 방식을 변경하면 내부적으로 처리 할 수 ​​있지만 사용자와의 계약이 바뀌지 않는 한 사물을 눈치 채지 못할 것입니다.

이 작업을 수행하는 한 가지 방법은 단순히 "실제"API에서 가져온 정확한 개체를 전달하는 것이 아닙니다. 당신은 응답으로 되돌려 보내는 자신 만의 객체를 생성 할 수 있습니다. 그런 다음 개체를 개체로 변환합니다. 그런 식으로 "실제"API가 사물을 변경하면 끝까지 보낼 방법을 선택할 수 있습니다.

중간 사용자는 최종 사용자가 원래 API에 대해 알 필요가 없도록 설정해야합니다.