웹 서비스는 웹을 통한 데이터 교환을 위해 정의된 표준입니다. 이는 웹 서비스가 인터넷에 노출된다는 의미가 아니라, 단지 많은 제품이 지원하는 합의된 "웹 표준" 세트가 있다는 의미입니다. 채택할 표준을 결정할 때 고려해야 할 가장 중요한 사항은 종종 기술 직원의 조언입니다.
그들은 구현하기 가장 쉽고, 제품에 대한 기술 지원이 가장 광범위하며, 귀하의 환경에서 가장 잘 작동할 가능성이 가장 높은 표준을 귀하에게 추천할 수 있습니다. 시간의 시험을 견디고 앞으로도 지속적으로 확장할 수 있는 성공적인 SOA 구현을 위해서는 이 세 가지 요소가 모두 매우 중요합니다.
WS-I
WS-I(Web Services Interoperability Organization)는 다양한 운영 체제, 플랫폼 또는 프로그래밍 언어 간의 상호 운용성을 보장하기 위해 웹 표준에 대한 모범 사례를 전문적으로 개발합니다. WS-I는 웹 서비스 보안 및 웹 서비스 처리 기술 사양과 같은 모범 사례 문서를 정의하는 일을 담당합니다. 이 문서는 개발자와 기업이 사용자 조작성을 보장하기 위해 다른 사람들이 사용하는 방식을 준수하는 데 도움이 됩니다.
WS-I는 또한 이러한 프로토콜을 배포하는 방법에 대한 기술 사양, 테스트 모음 및 샘플을 게시합니다. 실제로 WS-I는 Microsoft, IBM 등 많은 조직이 구성한 관리 기관이며, 그 임무는 상호 운용 가능한 웹 서비스를 촉진하는 것입니다.
이용계약
웹 서비스는 통신이 의미가 있는지 확인하기 위해 프로토콜을 사용합니다. 서비스 간에 전송되는 데이터의 내용은 양 당사자가 어떤 내용을 수신하는지 알 수 있도록 사전에 합의되어야 합니다. SOAP는 데이터를 교환할 때 가장 널리 사용되는 프로토콜의 예입니다. SOAP는 XML 프로그래밍 언어를 사용하므로 양 당사자가 전송되는 내용을 디코딩하고 주고받는 정보의 형식을 지정할 수 있습니다.
설명하다
곧 일부 아키텍처에 대해 다루고 일부 웹 서비스 프로토콜도 참조할 것입니다. 이 두 가지를 혼동하지 않는 것이 중요합니다. 그럼 아래에서 간단히 소개하겠습니다.
REST 및 RPC와 같은 소프트웨어 아키텍처는 프로토콜이 아닙니다. 이는 계약 이행 방법을 지정하는 방법입니다.
WSDL(Web Services Description Language)은 애플리케이션이 서비스를 구문 분석할 수 있도록 형식화된 방식으로 특정 웹 서비스를 설명하는 데 사용되는 언어입니다. WSDL 자체는 웹 서비스 상호 작용 형태의 기능을 제공하지 않습니다.
SOAP, XML-RPC 또는 DCOM과 같은 프로토콜 자체는 메시지가 전달되는 방식과 프로그램이 수신하는 데이터를 이해하는 방식을 정확하게 정의합니다.
SOA에는 RPC 프로토콜 제품군과 REST(Representational State Transfer) 접근 방식이라는 두 가지 주요 아키텍처 유형이 있습니다.
RPC
RPC(원격 프로시저 호출) 방법을 사용하면 프로그래머는 시스템에서 프로그래밍할 때 로컬 리소스를 "호출"하는 것처럼 원격 시스템의 리소스를 호출할 수 있습니다. RPC 스타일 서비스의 단점은 사람들이 특정 플랫폼의 프로그래밍 언어에 익숙한 것처럼 사용하는 경향이 있다는 것입니다. 로컬 프로시저와 동일하면 원격 프로시저를 호출하는 것도 쉽습니다.
이 논리는 "느슨한 결합" 개념을 위반합니다. 느슨한 결합의 개념은 실제로 원격 프로세스가 특정 운영 체제나 프로그래밍 언어에 의존해서는 안 된다는 것을 의미합니다.
SOAP는 XML-RPC의 후속 프로토콜이며 해당 정보를 XML로 포함하는 원격 프로시저 호출일 뿐입니다. SOAP는 HTTP 프로토콜을 사용하여 데이터를 전송하는데 이는 훌륭하고 간단하지만 몇 가지 단점이 있습니다. 그럼에도 불구하고 오늘날 대부분의 웹 서비스는 SOAP 프로토콜을 사용하여 구축되었으므로 통신에 여전히 HTTP 프로토콜을 사용합니다.
나머지
REST(Representational State Transfer) 접근 방식은 다른 수준에서 작동한다는 점에서 원격 프로시저 호출과 근본적으로 다릅니다. REST 호출은 HTTP 프로토콜을 통한 다른 웹 요청처럼 보이지만 RPC 호출은 표준 함수 호출처럼 보입니다. REST의 초점은 개별 메시지가 아닌 안정적인 리소스로 작동하여 HTTP 프로토콜 자체와 마찬가지로 보다 표준적이고 널리 이해되는 상호 작용 방식을 만드는 것입니다. REST는 간단한 데이터의 전송을 처리하는 반면 RPC는 복잡한 프로세스를 전송합니다.
REST 또는 RPC를 사용해야 합니까?
REST를 사용할지 여부에 대한 질문은 확실히 좋은 질문입니다. 미래의 길인 것 같습니다. 그러나 SOA는 현재 사용하는 모든 소프트웨어에 통합되어야 합니다. 주로 웹 서비스 지원으로 인해 REST 채택이 느려졌습니다. REST 시스템은 WSDL을 사용하여 HTTP를 통해 SOAP 메시지를 설명할 수 있지만 실제로 사용할 수 있는 지원은 충분하지 않습니다. 예를 들어 Apache는 플러그인 모듈을 설치하지 않고 REST를 사용하는 데 필요한 방법조차 지원하지 않습니다.
웹 서비스 제품군에 속하지 않는 다른 표준이 있습니다. 그러나 예상할 수 있듯이 이러한 표준은 널리 지원되지 않습니다. Jini, WCF, CORBA 등이 그 예입니다. 공급업체가 위 기술 중 하나만 지원하는 제품을 제공하면 도망가는 것이 아니라 도망가고 싶어합니다. 이제 웹 서비스가 널리 지원됩니다. 웹 서비스의 사용은 계속 증가할 것입니다. SOA 자체는 새롭고 불안정하며 위험하다고 알려져 있습니다. 그러나 광범위한 기술 지원이 포함된 적절한 웹 서비스 표준을 선택하면 이러한 위험을 크게 완화할 수 있습니다.
마지막으로, 일부 유형의 RPC 스타일 시스템 대신 구식 SOAP를 고수하는 것은 현재 웹 서비스를 사용하여 SOA를 구축하기 위한 실행 가능한 메커니즘입니다. 이렇게 하면 공급업체에 종속될 가능성이 크게 줄어듭니다.