XMLHTTP 및 SOAP:
XML은 웹 서비스의 핵심 기본기술 이며 SOAP 구현의 핵심입니다. XMLHTTP는 XML을 기반으로 설계되었습니다. 구현 측면에서 보면 XMLHTTP는 브라우저를 기반으로 하며 IE가 있는 한 XML 문자열을 서버로 전송할 수 있으며 이는 매우 다양합니다. 그러나 브라우저는 XMLHTTP에 사용되지 않습니다. XML을 사용하여 다양한 작업을 완료할 수 있다면 필연적으로 사용자에게 영향을 미칠 것입니다. 예를 들어 이전 버전의 msxml에 해당하는 브라우저는 클라이언트 XML 문서(처음에는 XMLHTTP용으로 설계됨)에 액세스할 수 있습니다. 이는 XMLHTTP 기술을 통해 로컬 파일 시스템에 액세스할 수 있음을 의미합니다. 나중에 Microsoft는 이를 취약점으로 정의했지만 이제는 더 이상 가능하지 않습니다. 물론 클라이언트 프로그램을 작성할 수도 있지만 msxml에서 API를 호출할 수 있는 Visual 시리즈 프로그램으로 제한됩니다. 그러나 서버는 xml 문자열을 xml 문서객체 로 변환하는 asp, jsp/servlet일 수 있습니다.
SOAP는 다음을 포함하는 XML 형식의 통신 프로토콜입니다. SOAP 봉투는 메시지 처리 방법을 암시하는 메시지 내용을 설명하기 위한 규칙을 정의합니다. 프로토콜 바인딩은 하위 수준 프로토콜을 통해 SOAP 봉투를 전송하기 위한 일반적인 메커니즘 집합을 제공합니다. 다양한 애플리케이션 데이터 유형을 태그 기반 XML표현 으로 매핑하는 규칙은 원격 프로시저 호출과 해당 반환 값을 나타내는 방법을 제공합니다. 그의 영역은 다른 계약과 명확한 관계가 없습니다. http.stmp, tcp 및 기타 프로토콜에 바인딩될 수 있습니다. SOAP 메시지는 XML 문서이며 W3C에서 정의한 API를 기반으로 SOAP 메시지를 생성할 수도 있습니다. 물론 Microsoft의 .net 플랫폼도 SOAP를 지원합니다. SOAP+HTTP는 분산 협업 통신에서 더 우수하고 강력한 구현 기능, 확장성 및 다양성을 제공한다는 점에서 XMLHTTP와 유사합니다. 더 중요한 것은 웹 서비스 및 회선 통신을 위한 핵심 기술이 되었다는 점입니다.
SOAP 및 RMI, CORBA, COM
RMI 및 COM은 모두 분산 애플리케이션의 구현이며 구성 요소 간의 통신을 정의합니다. 이는 시스템(예: Java 로 작성된 일련의 프로그램) 간의 통신 규칙일 뿐이며 통신에는 특정 플랫폼 지원이 필요하지만 이 시스템 내 통신이 효율적이라는 점을 제외하면 다른 시스템과 함께 사용할 수 없습니다.
이러한 통신 문제를 해결하기 위해 CORBA는 서로 통신할 수 있도록 프록시 요청 모델(IDL 언어 사용)을 설계했습니다. 그러나 이는 패치인 것으로 보이며 시스템이 점점 더 복잡해집니다. , CORBA의 사용은 기존 시스템의 가치를 복원하는 데에만 효과적입니다. 그 중 어느 것도 방화벽을 통과할 수 없습니다. SOAP+HTTP는 방화벽 친화적인 프로토콜이며 방화벽을 통과할 수 있습니다.
SOAP는 특정 구현과 관련이 없는 프로토콜이며 XML 형식을 기반으로 하며 데이터를 XML 형식으로 전송하므로 시스템이 느슨해집니다. 이런 방식으로 애플리케이션에서 XML의 가독성을 활용하여 XML 문서를 구문 분석하여 애플리케이션을 구현함으로써 시스템의 상호 운용성(다른 시스템과의 통신)이 크게 향상됩니다. 또한, 시스템 내 각 단위의 비즈니스 로직이 명확하여 이식성과 재사용성이 뛰어납니다.
UDDI 및 JNDI
UDDI는 서비스를 등록하는 데 사용되는 프로토콜입니다. 사용자는 UDDI 등록 센터에서 서비스를 검색하여 WSDL 문서를 얻고 WSDL을 기반으로 액세스할 수 있습니다. 문서. SOAP를 사용하여 서비스와 통신하는 서비스 방법입니다. 데이터베이스를 통해 구현할 수도 있고,오픈소스 나 기업( IBM 등) XML을 이용해 표현할 수도 있다. 사용자가 쿼리하면 해당 세부 정보가 XML 형식의 정보로 반환될 수 있습니다. 액세스 절차는 계층적 검색 프로세스에 지나지 않습니다. 등록하는 서비스는 범용적이고 플랫폼 독립적이며 등록 방법은 범용 XML 형식입니다. 다양한 사용자에게 다양한 서비스를 제공하기 위해 인터넷 기반일 수도 있고 인터넷 기반일 수도 있습니다.
JNDI는 Java 서비스 이름 지정 디렉터리로, EJB 및 DataSource의 액세스 디렉터리를 트리 형식으로 기록합니다. 프로그램은 JDNI 및 RMI를 통해 서비스를 찾을 수 있습니다. 특히 배포 파일을 통해 서버가 시작되면 배포 파일을 기반으로 JNDI를 자동으로 설정하고 RMI 및 이름 지정 서비스 쿼리(서버 자체에서 구현)를 지원합니다. 그런 다음 RNI는 이러한 구성 요소에 액세스할 수 있습니다. 그 아이디어는 기본적으로 UDDI와 유사하지만 특정 시스템 플랫폼에 바인딩되어 있고 서비스(프로그램 관련, 엄밀히 말하면 서비스라고 부르지는 않지만 컴포넌트)에 완전히 바인딩되어 있으며 구현이 간단합니다. 따라서 UDDI는 JNDI보다 더 동적이고 조작하기 쉽습니다.
WSDD 및 EJB의 구성 파일은
CMP 엔터티 Bean과 유사하지만 데이터와 데이터베이스 간의 매핑을 설명하며 메소드를 포함하지 않습니다. . 서버 시스템에는 기본 구현 액세스 방법이 있습니다. WSDD는 서비스의 액세스 인터페이스를 정의하며, 웹 서비스를 지원하는 기본 시스템은 인터페이스를 식별하고 데이터를 전송하는 등의 작업을 수행합니다.