서비스 지향 아키텍처 (SOA)는 금세기 초 분산 컴퓨팅의 진화로 등장했습니다. SOA 이전에는 서비스가 애플리케이션 개발 프로세스의 최종 결과로 이해되었습니다. SOA에서 애플리케이션 자체는 서비스로 구성됩니다. 서비스는 개별적으로 제공되거나 더 큰 복합 서비스의 구성 요소로 결합 될 수 있습니다.
서비스는 REST 또는 SOAP (Simple Object Access Protocol)와 같은 프로토콜을 사용하여 유선으로 상호 작용합니다. 서비스는 느슨하게 결합되어 있으므로 서비스 인터페이스는 기본 구현과 독립적입니다. 개발자 또는 시스템 통합자는 각 서비스가 어떻게 구현되는지 알 필요없이 하나 이상의 서비스를 애플리케이션으로 구성 할 수 있습니다.
이 기사는 Java SOA의 개요와 a. SOAP 기반 웹 서비스를 사용하여 구현 된 서비스 지향 아키텍처. 또한 SOA와 마이크로 서비스를 간략하게 비교하고 Java에서 RESTful과 SOAP 기반 웹 서비스의 차이점에 대해 논의 할 것입니다.
서비스 지향 아키텍처가 필요한 이유는 무엇입니까?
SOA는 세 가지 일반적인 기업 과제를 해결합니다. :
- 비즈니스 변화에 신속하게 대응합니다.
- 기존 인프라 투자를 활용합니다.
- 고객, 파트너 및 공급 업체와의 새로운 상호 작용 채널을 지원합니다.
엔터프라이즈 인프라는 운영 체제, 애플리케이션, 시스템 소프트웨어 및 애플리케이션 인프라 전반에 걸쳐 이기종입니다. 결과적으로 많은 엔터프라이즈 시스템은 복잡하고 일관성없는 애플리케이션으로 구성되어 다양한 상호 의존적 서비스. 현재 비즈니스 프로세스를 실행하는 기존 애플리케이션이 중요하므로 처음부터 시작하거나 수정하는 것은 섬세한 제안입니다. 그러나 기업은 비즈니스 요구 사항을 충족하기 위해 기술 인프라를 수정하고 확장 할 수 있어야합니다.
As 모 놀리 식 아키텍처와 비교 구조, SOA의 느슨하게 결합 된 특성은 새로운 서비스를 연결하거나 새로운 비즈니스 요구 사항을 위해 기존 서비스를 업그레이드하는 것을 비교적 원활하게 만듭니다. 또한 다양한 채널에서 서비스를 사용할 수있게 만들고 레거시 애플리케이션을 서비스로 노출하여 인프라 투자를 보호하는 옵션을 제공합니다.
느슨하게 결합되어 있기 때문에 SOA 구성 요소는 다른 구성 요소에 미치는 영향을 최소화하면서 변경할 수 있습니다. . 구성 요소는 표준화 된 방식으로 아키텍처에 추가 할 수 있으며 부하를 처리하도록 확장 할 수 있습니다.
예를 들어, 기업이 기존 애플리케이션 세트를 사용하여 새 애플리케이션을 생성하는 방법을 고려하십시오. 복합 공급망 애플리케이션. 기존 애플리케이션은 이기종이고 다양한 시스템에 분산되어 있지만 해당 기능은 표준 인터페이스를 사용하여 노출되고 액세스됩니다.
그림 1. 서비스 지향 아키텍처의 공급망 애플리케이션
SOA의 주요 특성
SOA는 다른 구성 요소에서 제공하는 서비스를 사용하는 단일 구성 요소처럼 간단 할 수도 있고 MuleSoft의 ESB와 같은 엔터프라이즈 서비스 버스를 통해 상호 작용하는 다양한 구성 요소처럼 정교 할 수도 있습니다. 규모에 관계없이 성공적인 SOA 구현의 핵심은 다음과 같습니다. 목표를 달성하기 위해 가능한 한 적은 복잡성을 사용합니다. 첫 번째와 마지막 질문은 항상 다음과 같습니다.이 디자인이 비즈니스 요구 사항을 충족합니까?
규모 나 복잡성에 관계없이 서비스 지향 아키텍처의 패턴 거의 동일합니다.
- 서비스 제공 업체는 엔드 포인트를 노출하고 각 엔드 포인트에서 사용 가능한 작업.
- 서비스 소비자는 요청을 발행하고 응답을 소비합니다.
- 서비스 공급자는 요청을 처리하기 위해 메시지를 생성합니다.
서비스 구현- 지향 아키텍처
SOA를 구현하려면 기본 서비스 아키텍처부터 시작한 다음 통신 및 상호 운용성을 가능하게하는 프로토콜 및 기타 도구를 의미하는 인프라를 제공합니다. 그림 2는 일반적인 서비스 아키텍처의 다이어그램을 보여줍니다.
그림 2. 샘플 서비스 아키텍처
이 다이어그램에서 세 소비자는 메시지를 적절한 서비스 구현으로 변환하고 라우팅하는 엔터프라이즈 서비스 버스로 메시지를 보내 서비스를 호출합니다. . 비즈니스 규칙 엔진은 서비스 또는 서비스 전반에 비즈니스 규칙을 통합합니다. 서비스 관리 계층은 감사, 청구 및 로깅과 같은 활동을 관리합니다.
이 아키텍처의 구성 요소는 느슨하게 결합되어 있으므로 전체 애플리케이션에 미치는 영향을 상대적으로 최소화하면서 전환하거나 업데이트 할 수 있습니다. 따라서 기업은 필요에 따라 비즈니스 프로세스를 추가하거나 업데이트 할 수있는 유연성을 제공합니다. 대부분의 경우 개별 서비스의 변경은 다른 서비스에 큰 영향을주지 않습니다.
SOAP 기반 웹 서비스
SOAP를 사용하여 구현 된 웹 서비스는 RESTful 웹 서비스 또는 마이크로 서비스 구현보다 여전히 더 견고하지만 SOA 초기보다 훨씬 더 유연합니다. 여기서는 SOAP 기반 웹 서비스에 필요한 고급 프로토콜을 살펴 보겠습니다.
SOAP, WSDL 및 XSD
SOAP, WSDL 및 XSD는 기본 인프라입니다. WSDL은 서비스를 설명하는 데 사용되며 SOAP는 서비스 소비자와 공급자간에 메시지를 전송하기위한 전송 계층입니다. 서비스는 XSD (XML Schema)를 사용하여 공식적으로 정의 된 메시지와 통신합니다. WSDL을 생각할 수 있습니다. 서비스의 인터페이스로 (Java 인터페이스와 거의 유사 함). 구현은 Java 클래스에서 이루어지며 네트워크를 통한 통신은 SOAP를 통해 이루어집니다. 기능적으로 소비자는 서비스를 찾고 해당 서비스에 대한 WSDL을 가져온 다음 SOAP를 사용하여 서비스를 호출합니다.
웹 서비스 보안
WS -I Basic Profile 2.0 사양은 메시지 보안을 다룹니다. 이 사양은 자격 증명 교환, 메시지 무결성 및 메시지 기밀성에 중점을 둡니다.
웹 서비스 검색
웹 서비스 검색의 초석이 된 후 UDDI (Universal Description, Definition and Integration)는 사라졌습니다. 역사에. 오늘날에는 엔드 포인트 URL을 통해 다른 서비스처럼 SOAP 기반 웹 서비스를 노출하는 것이 일반적입니다. 예를 들어 JAX-WS 서비스 엔드 포인트 인터페이스와 해당 @WebService 및 @WebMethod 주석.
웹 서비스 빌드 및 배포
Java 개발자는 SOAP 기반의 빌드 및 배포를위한 몇 가지 옵션이 있습니다. Apache Axis2 및 Spring-WS를 포함한 웹 서비스. 그러나 Java 표준은 XML 웹 서비스 용 Java API 인 JAX-WS입니다. JAX-WS의 핵심 아이디어는 Java 클래스를 만들고 주석을 달아 필요한 아티팩트를 만드는 것입니다. 내부적으로 JAX-WS는 Java 클래스를 XML에 바인딩하기위한 범용 라이브러리 인 JAXB를 포함하여 여러 Java 패키지를 사용합니다.
JAX-WS는 개발자의 기본 복잡성과 프로토콜을 숨겨 프로세스를 간소화합니다. Java 기반 SOAP 서비스를 정의하고 배포하는 방법 Eclipse와 같은 최신 Java IDE에는 JAX-WS 웹 서비스 개발을위한 완전한 지원이 포함됩니다. WS 사양은 또한 Jakarta EE의 지속적인 개발을 위해 선택되었습니다.
결론
SOAP 기반 웹 서비스로 구현 된 서비스 지향 아키텍처는 더 엄격하고 RESTful 웹 서비스 또는 마이크로 서비스보다 공식적인 서비스 정의. 그러나 일부 대규모 조직은 SOAP에 의해 시행되는보다 형식적인 스타일을 계속 선호합니다. 많은 대규모 레거시 시스템도 SOAP를 기반으로 구축되며 일부 B2B 및 내부 시스템은보다 공식적으로 정의 된 API 계약을 위해 SOAP 기반 웹 서비스를 선택합니다. 대규모 엔터프라이즈 시스템을 개발하든 유지 관리하든 SOA 패턴을 이해하고이를 구현하기위한 옵션을 평가할 수 있으면 프로그래밍 경력에 도움이 될 것입니다.