SOA, SOAP 란 무엇입니까?
SOA 는 도대체 무엇입니까?
SOA (service-oriented architecture) 는 서비스 지향 아키텍처로 정의됩니다. 즉, 소프트웨어를 표준 방식으로 인터페이스를 정의하고 표준 프로토콜을 통해 호출하는 서비스로 설계합니다. SOA 가 정의하는 인터페이스 및 호출 방법은 프로그래밍 언어 및 실행 플랫폼과 독립적이며, 일반적으로 SOA 는 CORBA 및 웹 서비스와 같은 다양한 기본 기술을 기반으로 구현할 수 있습니다. 그러나 CORBA 는 너무 복잡하고 비대해서 거의 사용되지 않기 때문에 현재 말하는 SOA 의 대다수는 웹 서비스 기술을 기반으로 합니다. 웹 서비스 구현에서 SOA 서비스의 인터페이스는 XML 로 정의됩니다.
SOA 아키텍처에서 소프트웨어 개발은 비즈니스 프로세스 분석부터 다양한 비즈니스 모델을 식별 및 분석하고, 다양한 사례를 통합하고, 이를 바탕으로 사용 사례를 구축하고, 사용 사례는 BPEL 을 직접 생성하며, 이러한 BPEL 은 다양한 서비스에 대한 정보를 설명하는 서비스 통합 프레임워크에 통합될 수 있습니다. 따라서 ESB 의 각 모듈을 통합할 수 있습니다.
중간 계층을 다시 분리하여 중간 계층에 기술 아키텍처 간 메타데이터 및 비즈니스 논리를 만들어 기술 아키텍처 전반에 걸쳐 장기적으로 상속되고 축적될 수 있는 엔터프라이즈 비즈니스 라이브러리와 가장 귀중한 정보 자산, 즉 서비스 지향 구성 요소 라이브러리를 만듭니다. 이 서비스 구성 요소 라이브러리는 다른 기업에서 재사용할 수 있으며 어떤 기술 아키텍처에도 의존하지 않습니다. 모든 소프트웨어 기업이 SOA 아키텍처를 사용한다면 세계 소프트웨어 업계는 완전히 바뀔 것이라고 과장했다. 분명히, 그러한 틀은 제품이 아니며, 단지 기술일 뿐만 아니라, 문제를 해결하는 방법론이다.
SOA 는 두 가지 시나리오에 적용될 수 있습니다. 첫 번째는 비즈니스 상호 연결입니다. 두 번째는 폐쇄 거래 시스템, 즉 메타데이터와 비즈니스 논리를 분리하여 재사용 가능합니다. 예를 들어, 첫 번째 시나리오에서는 서로 다른 기업 간의 비즈니스 호출이 필요할 때 SOA 기술을 사용할 수 있습니다. 두 번째 시나리오에서는 기업 내에서 시스템을 마이그레이션해야 할 때 SOA 기술로 정의된 기존 데이터와 비즈니스 프로세스를 활용하여 신속하게 완료할 수 있습니다.
SOA 는 새로운 것이 아닙니다. IT 조직은 수년 동안 SOA 앱을 성공적으로 구축하고 구현해 왔으며, BEA, IBM 및 기타 업체들은 그 가치를 보고 후속 조치를 취하고 있습니다. SOA 의 목표는 IT 를 더욱 유연하게 만들어 비즈니스 단위의 요구에 더 빠르게 대응하고 실시간 엔터프라이즈 (Real-Time Enterprise, Gartner 가 SOA 에 대해 설명하는 비전 목표) 를 달성하는 것입니다. 반면 BEA 의 CIO Rhonda 는 2001 년 6 월 BEA 의 IT 인프라를 SOA 로 전환하겠다고 제안한 바 있으며, 전체 엔터프라이즈 아키텍처에 대한 통제 능력, 개발 효율성 향상, 개발 속도 향상, 맞춤형 및 인력 기술 투자 감소 등 좋은 성과를 거두었습니다.
SOA 는 컴퓨팅 환경에서 분산된 논리 (서비스) 단위를 설계, 개발, 적용 및 관리하는 사양입니다. 이 정의는 SOA 의 광범위성을 결정한다. SOA 는 개발자가 서비스 통합의 관점에서 응용 프로그램 소프트웨어를 설계해야 합니다. 설령 그렇게 하는 이익이 즉시 나타나지 않더라도 말입니다. SOA 는 개발자가 앱을 뛰어넘어 생각하도록 요구하고, 기존 서비스를 재사용하거나, 서비스를 어떻게 재사용할 수 있는지 점검할 것을 요구한다. SOA 는 새로운 코드를 작성하지 않고 서비스를 연결함으로써 대체 기술 및 방법 (예: 메시지 메커니즘) 사용을 권장합니다.
적절한 프레임워크를 거친 후, 이러한 메시지 메커니즘의 응용 프로그램을 통해 기업은 대규모 새로운 응용 프로그램 코드 개발이 아닌 기존 서비스 모델을 조정함으로써 비즈니스 환경 라이선스 기간 동안 변화하는 시장 조건에 신속하게 대응할 수 있습니다.
SOA 는 단지 개발 방법론이 아니라 관리도 포함하고 있다. 예를 들어, SOA 를 적용한 후 관리자는 단일 애플리케이션 모듈을 관리하는 대신 서비스 플랫폼에 구축된 엔터프라이즈 애플리케이션을 쉽게 관리할 수 있습니다. SOA 는 서비스 간의 상호 호출을 분석하여 회사 경영진이 언제, 어떤 이유, 어떤 비즈니스 논리가 실행되는지에 대한 데이터 정보를 쉽게 얻을 수 있도록 함으로써 기업 관리자 또는 애플리케이션 설계자가 반복적으로 엔터프라이즈 비즈니스 프로세스와 애플리케이션 시스템을 최적화할 수 있도록 하는 것입니다.
SOA 의 핵심 아이디어 중 하나는 엔터프라이즈 애플리케이션을 기술 지향 솔루션의 속박에서 벗어나 엔터프라이즈 비즈니스 서비스의 변화와 발전에 쉽게 대처할 수 있도록 하는 것입니다. 기업 환경에서 단일 응용 프로그램은 비즈니스 사용자의 (다양한) 요구를 수용할 수 없습니다. 대규모 ERP 솔루션이라도 지속적으로 확장되고 변화하는 격차를 충족시킬 수 없습니다. 시장에 신속하게 대응할 수 있습니다. 비즈니스 사용자는 새로운 응용 프로그램을 지속적으로 개발하고 기존 응용 프로그램을 확장함으로써 기존 비즈니스 요구 사항을 지원하기가 어렵습니다. 서비스에 초점을 맞추면 애플리케이션은 더욱 풍부하고 목적이 높은 비즈니스 프로세스를 제공하는 데 집중할 수 있습니다. 결과적으로 SOA 기반 엔터프라이즈 애플리케이션 시스템은 일반적으로 비즈니스 모델과의 결합을 보다 사실적으로 반영합니다. 서비스는 비즈니스 프로세스의 관점에서 기술을 바라보는 것입니다. 이는 위에서 아래로 보는 것입니다. 이 각도는 사용 가능한 기술에 의해 구동되는 일반적인 비즈니스 관점과는 반대입니다. 서비스의 장점은 비즈니스 프로세스와 결합되어 비즈니스 모델을 보다 정확하게 표현하고 비즈니스 프로세스를 더 잘 지원할 수 있다는 것입니다. 대신 응용 프로그램 중심의 엔터프라이즈 응용 프로그램 모델을 통해 비즈니스 사용자가 해당 기능을 응용 프로그램으로 제한할 수 있는 기능을 확인할 수 있습니다.
엔터프라이즈 프로세스 (enterprise process) 는 비즈니스 모델의 구성 요소에 생명을 부여하고 그 관계를 보다 명확하게 정의하는 엔터프라이즈 프레임워크를 통과하는 공기입니다. 프로세스는 비즈니스 모델과 상호 작용하는 특수한 방법을 정의합니다. 예를 들어, 회계는 엔터프라이즈 서비스 시스템의 구성 요소일 수 있지만 고객에게 송장을 보내는 것은 업무 프로세스입니다. 서비스는 업무 프로세스를 지원하도록 정의되므로 프로세스 전반에 걸쳐 다양한 서비스 구성 요소가 프로세스 및 논리 구현 중 조립됩니다. 비즈니스 프로세스를 이해하는 것이 맞춤형 서비스의 핵심입니다.
엔터프라이즈 비즈니스를 위한 통합 기존 애플리케이션 통합 방법 (포인트 투 포인트 통합, 엔터프라이즈 메시지 버스 또는 미들웨어 통합 (EAI), 비즈니스 프로세스 기반 통합) 은 복잡하고 비싸며 유연성이 없습니다. 이러한 통합 접근 방식은 기업의 현대 비즈니스 변화에 따라 끊임없이 발생하는 요구에 신속하게 적응하기가 어렵습니다. 서비스 지향 아키텍처 (SOA) 기반 애플리케이션 개발 및 통합은 이러한 많은 문제를 잘 해결할 수 있습니다.
SOA 는 클라이언트 응용 프로그램이 서비스에 연결하는 데 도움이 되는 정교한 개발 모델을 설명합니다. 이러한 모드는 서비스, 알림 및 검색 서비스를 설명하고 서비스와 통신하는 데 사용되는 일련의 메커니즘을 사용자 정의합니다.
기존의 애플리케이션 통합 방법과 달리 SOA 에서는 서비스를 둘러싼 모든 모델이 표준 기반 기술로 구현됩니다. RPC, CORBA, DCOM, EJB 및 RMI 와 같은 대부분의 통신 미들웨어 시스템도 마찬가지입니다. 그러나 이들의 구현은 완벽하지 않으며 상호 작용성과 표준 맞춤형 수용성을 가늠하는 데 문제가 있다. SOA 는 이러한 결함을 제거하려고 합니다. 거의 모든 통신 미들웨어 시스템에는 RPC 기능, CORBA 개체 등과 같은 고정 처리 모드가 있기 때문입니다. 그러나 서비스는 기능이나 객체, 응용 프로그램 등으로 동시에 정의할 수 있습니다.
이를 통해 SOA 는 기존 시스템에 적응할 수 있으며 통합 시 특별한 사용자 정의를 따를 필요가 없습니다.
SOA 는 엔터프라이즈 정보 시스템을 "leave-and-layer" 아키텍처로 마이그레이션하는 데 도움을 줍니다. 즉, 기존 엔터프라이즈 시스템을 수정하지 않고도 웹 서비스 인터페이스를 외부에 제공할 수 있습니다. 이는 이미 웹 서비스 인터페이스를 제공할 수 있는 애플리케이션 계층에 의해 캡슐화되어 있으므로 기존 시스템 아키텍처를 수정하지 않고도 SOA 가 다음을 수행할 수 있기 때문입니다. SOA 는 패키지 응용 프로그램, 사용자 정의 응용 프로그램 및 레거시 시스템의 정보뿐만 아니라 보안, 컨텐츠 관리, 검색 등의 IT 스키마의 기능 및 데이터도 포괄합니다. SOA 기반 애플리케이션은 이러한 인프라 서비스 인프라에서 기능을 쉽게 추가할 수 있기 때문에 SOA 기반 애플리케이션은 시장 변화에 더 빠르게 대응하고 엔터프라이즈 비즈니스 부서 설계를 위한 새로운 기능 애플리케이션을 개발할 수 있습니다.
비누 란 무엇입니까?
SOAP 는 단순 객체 액세스 프로토콜 (Simple Object Access Protocol) 의 약어입니다.
SOAP 는 분산 환경을 위한 경량 XML 기반 정보 교환을 위한 통신 프로토콜입니다.
비누 이해:
첫 번째 단계는 비누 = http+XML
입니다두 번째 단계는 SOAP 가 XML 의 사용을 요청 및 응답 매개 변수 인코딩 모드로 코드화하고 HTTP 를 전송한다는 것입니다.
SOAP 는 성숙한 HTTP 기반 웹 기술과 XML 의 유연성과 확장성을 결합한 것입니다.
세 번째 이해: 특히 SOAP 구현은 SOAP 인코딩 규칙을 따르는 HTTP 요청 및 응답으로 간단히 볼 수 있습니다.
참고: SOAP 는 프로그래밍 언어와 무관한 프로토콜입니다. 실제로 Java, C, C++및 JavaScript 와 같은 많은 언어들이 SOAP 를 지원하기 시작했습니다.
비누 기원? 비누 문제 해결?
SOAP 는 처음에 Microsoft 가 MTS/COM 자원 소비, 가벼움 등의 문제를 해결하기 위해 연구를 시작했으며, 이후 IBM 과 같은 거물들에 의해 받아들여지고 연구에 합류하여 W3C 를 제출하여 웹 서비스 응용 프로그램 전송 표준이 되었습니다. SOAP 기술은 주로 다양한 이기종 프로그램과 플랫폼 간의 상호 운용성을 실현하는 데 사용되므로 광범위한 사용자가 기존 애플리케이션에 액세스할 수 있습니다.
SOAP 는 단순 객체 액세스 프로토콜 (Simple Object Access Protocol) 을 의미합니다. 확실히 그 이름처럼, SOAP 은 매우 간단하다. 프로그램 구성 요소와 응용 프로그램이 서로 표준 인터넷 프로토콜 (HTTP) 을 사용하여 통신할 수 있도록 하는 XML 기반 프로토콜입니다. SOAP 는 프로그램 언어에 의존하지 않는 독립 플랫폼이며 간단하고 유연하며 쉽게 확장할 수 있습니다. 현재 응용 프로그램은 DCOM 및 CORBA 기술 기반 RPC (원격 프로시저 호출) 를 사용하여 서로 통신할 수 있지만 HTTP 는 이러한 용도로 설계되지 않았습니다. 인터넷에서 block 를 적용하는 것은 매우 어렵습니다. 방화벽과 프록시 서버는 일반적으로 이러한 유형의 트래픽을 차단하기 때문에 많은 호환성 및 보안 문제가 발생할 수 있습니다. 응용 프로그램 간 가장 좋은 통신 방법은 HTTP 프로토콜을 통한 것입니다. HTTP 는 모든 인터넷 브라우저와 서버를 지원하기 때문입니다. 이를 위해 비누 프로토콜이 만들어졌습니다.
SOAP (simple object access protocol) simple object access protocol 은 분산 또는 분산 환경에서 정보를 교환하는 간단한 프로토콜로, soap 캡슐화 (envelop) 의 네 부분으로 구성된 XML 기반 프로토콜입니다. 캡슐화는 메시지의 내용을 설명합니다 응용 프로그램에서 사용해야 하는 데이터 유형의 인스턴스를 나타내는 SOAP 인코딩 규칙 (encoding rules); SOAP RPC 표현 (RPC representation) 은 원격 프로시저 호출 및 응답을 나타내는 프로토콜입니다. 기본 프로토콜을 사용하여 정보를 교환하는 비누 바인딩 (binding).
이 네 부분은 모두 SOAP 의 일부로 전체적으로 정의되지만 기능적으로 교차하고 서로 독립적입니다. 특히 봉투와 인코딩 규칙은 서로 다른 XML 네임스페이스 (namespace) 에 정의되어 있어 정의를 쉽게 할 수 있습니다.
CXF 란 무엇입니까?
Apache CXF = Celtix+XFire, Apache CXF 의 이전 명칭인 Apache CeltiXfire 는 이제 공식적으로 Apache CXF (이하 CXF) 로 이름이 변경되었습니다. CXF 는 Celtix 와 XFire 의 두 가지 주요 오픈 소스 프로젝트의 본질을 계승하고, JAX-WS 에 대한 포괄적인 지원을 제공하며, 다양한 Binding, DataBinding, Transport 및 다양한 Format 지원을 제공하며, 실제 프로젝트의 필요에 따라 코드 우선 순위를 적용할 수 있습니다 ( 현재 그것은 여전히 Apache 의 부화 프로젝트일 뿐이다.
Apache CXF 는 Frontend 프로그래밍 API 를 활용하여 JAX-WS 와 같은 서비스를 구축하고 개발하는 데 도움이 되는 오픈 소스 서비스 프레임워크입니다. 이러한 서비스는 SOAP, XML/HTTP, RESTful HTTP 또는 CORBA 와 같은 다양한 프로토콜을 지원할 수 있으며 HTTP, JMS 또는 JBI 와 같은 다양한 전송 프로토콜에서 실행할 수 있습니다. CXF 는 서비스를 크게 단순화합니다
CXF 에는 다양한 기능 기능이 포함되어 있지만 주로
에 초점을 맞추고 있습니다웹 서비스 표준 지원: CXF 는 SOAP, Basic Profile, WS-Addressing, WS-Policy, WS-ReliableMessaging 등 다양한 웹 서비스 표준을 지원합니다
Frontends：CXF 는 다양한' Frontend' 프로그래밍 모델을 지원하며, CXF 는 JAX-WS API (JAX-WS 2.0 TCK 버전 준수) 를 구현하고' simple frontend' 를 통해 클라이언트와 CXF 는 WSDL 우선 개발과 Java 의 코드 우선 개발 모델을 모두 지원합니다.
사용 편의성: CXF 는 보다 직관적이고 사용하기 쉽도록 설계되었습니다. 코드 우선 순위 서비스를 신속하게 구축하는 데 사용되는 간단한 API 가 많이 있으며, 다양한 Maven 의 플러그인으로 통합이 쉬워지고, JAX-WS API 지원, Spring 2.0 을 지원하는 간단한 XML 구성 방법 등이 있습니다.
이진 및 레거시 프로토콜 지원: CXF 는 XML 및 비 XML 유형 바인딩 (예: JSON 및 CORBA) 을 모두 지원하는 플러그 가능한 아키텍처로 설계되었습니다.
Cxf 를 이용하여 간단한 웹 서비스를 만들어 봅시다.
먼저 cxf 에 필요한 패키지: 웹 사이트에서는 다음 패키지가 모두 필요하지만 실제 프로젝트에서는 빨간색 부분의 패키지가 사용되지 않는다고 설명합니다.
누구나 자신의 필요에 따라 적응한 가방을 추가할 수 있다.
Cxf.jar
Commons-logging.jar
Geronimo-activation.jar (또는 sun equivalent)//
Geronimo-annotation.jar (또는 sun equivalent)//
Geronimo-javamail.jar (또는 sun equivalent)//
Neethi.jar
Jaxb-api.jar
Jaxb-impl.jar
Stax-api.jar//
XmlSchema.jar
Wstx-asl.jar
Xml-resolver.jar
분산 애플리케이션 및 브라우저
현재의 어플리케이션 개발을 살펴보면 사람들이 브라우저 기반 씬 클라이언트 어플리케이션을 선호하기 시작한다는 절대적인 경향을 발견할 수 있습니다. 이는 씬 고객이 더 나은 사용자 인터페이스를 제공할 수 있기 때문이 아니라 데스크탑 어플리케이션 출시에 많은 비용을 들이지 않기 때문입니다. 데스크탑 어플리케이션을 게시하는 데 드는 비용은 어플리케이션 설치 및 구성 문제 때문이며, 나머지 절반은 고객과 서버 간의 통신 문제 때문입니다.
기존의 Windows 리치 고객 어플리케이션은 DCOM 을 사용하여 서버와 통신하고 원격 개체를 호출합니다. 하나의 대규모 네트워크에서 작동하도록 DCOM 을 구성하는 것은 매우 어려운 작업이며 많은 IT 엔지니어의 악몽이기도 합니다. 실제로 많은 IT 엔지니어들은 LAN 에서 DCOM 을 실행하는 것보다 브라우저에서 발생하는 기능 제한을 견디는 것을 선호합니다. 제 생각에는 게시가 쉽지만 개발이 어렵고 사용자 인터페이스가 매우 제한적인 응용 프로그램입니다. 극단적으로 말하자면, 더 많은 자금과 시간을 보냈지만, 사용자의 관점에서 볼 때 기능이 약한 앱을 개발했다는 것이다. (윌리엄 셰익스피어, 윈스턴, 시간명언) 안 믿어? 회계사에게 새로운 브라우저 기반 회계 소프트웨어에 대해 어떻게 생각하는지 물어보십시오. 대부분의 상용 프로그램 사용자는 보다 친숙한 Windows 사용자 인터페이스를 사용하기를 원합니다.
클라이언트와 서버 간의 통신 문제에 대한 완벽한 해결책은 HTTP 프로토콜을 사용하여 통신하는 것입니다. 이는 웹 브라우저를 실행하는 모든 시스템에서 HTTP 프로토콜을 사용하고 있기 때문입니다. 또한 현재 많은 방화벽이 HTTP 접속만 허용하도록 구성되어 있습니다.
많은 상용 프로그램은 또 다른 문제, 즉 다른 프로그램과의 상호 운용성에 직면해 있다. 모든 앱이 COM 또는. NET 언어로 쓰여지고 모두 Windows 플랫폼에서 실행된다면 천하가 태평할 것이다. 그러나 실제로 대부분의 비즈니스 데이터는 여전히 메인프레임 호스트에 VSAM (비관계형 파일) 으로 보관되어 있으며 COBOL 언어로 작성된 메인프레임 프로그램에서 액세스할 수 있습니다. 또한 현재 C++, Java, Visual Basic 및 기타 다양한 언어로 계속 작성된 상용 프로그램이 많이 있습니다. 이제 가장 간단한 프로그램을 제외한 모든 애플리케이션은 다른 이기종 플랫폼에서 실행되는 애플리케이션과 통합되고 데이터를 교환해야 합니다. 이러한 작업은 일반적으로 파일 전송 및 분석, 메시지 대기열, IBM 의 "고급 프로그램 대 프로그램 통신 (APPC)" 과 같은 특정 상황에만 적용되는 API 와 같은 특수한 방법으로 수행됩니다. 이전에는 응용 프로그램 통신 표준이 없었고 플랫폼, 모델링 및 프로그래밍 언어와 독립적이었습니다. 웹 서비스를 통해서만 클라이언트와 서버는 두 프로그램의 플랫폼과 프로그래밍 언어에 관계없이 HTTP 로 자유롭게 통신할 수 있습니다.
웹 서비스란 무엇입니까?
웹 서비스는 상호 운용 가능한 분산 응용 프로그램을 구축하는 새로운 플랫폼입니다. Windows 프로그래머로서 COM 또는 DCOM 을 사용하여 구성 요소 기반 분산 응용 프로그램을 구축했을 수 있습니다. COM 은 매우 좋은 구성 요소 기술이지만 COM 이 요구 사항을 충족하지 못하는 상황도 쉽게 제시할 수 있습니다.
웹 서비스 플랫폼은 응용 프로그램이 웹에서 상호 운용되는 방식을 정의하는 표준 집합입니다. 원하는 언어로 원하는 플랫폼에 웹 서비스를 쓸 수 있습니다. 웹 서비스 표준을 통해 이러한 서비스를 조회하고 액세스할 수 있는 한 가능합니다.
웹 서비스 플랫폼은 분산 응용 프로그램 생성을 위한 프로토콜 세트가 필요합니다. 모든 플랫폼에는 데이터 표시 방법 및 유형 시스템이 있습니다. 상호 운용성을 위해 웹 서비스 플랫폼은 다양한 플랫폼, 프로그래밍 언어 및 구성 요소 모델 내에서 다양한 유형의 시스템을 전달할 수 있는 표준 유형 시스템을 제공해야 합니다. 전통적인 분산 시스템에서 인터페이스 기반 플랫폼은 인터페이스, 방법 및 매개변수 (예: COM 및 COBAR 의 IDL 언어) 를 설명하는 몇 가지 방법을 제공합니다. 마찬가지로 웹 서비스 플랫폼은 고객이 웹 서비스를 호출할 수 있는 충분한 정보를 얻을 수 있도록 웹 서비스를 설명하는 표준을 제공해야 합니다. 마지막으로 이 웹 서비스를 원격으로 호출할 수 있는 방법도 있어야 합니다. 이 방법은 실제로 원격 프로시저 호출 프로토콜 (RPC) 입니다. 상호 운용성을 위해 이 RPC 프로토콜은 플랫폼 및 프로그래밍 언어와도 무관해야 합니다.
웹 서비스는 자체 포함, 자체 설명, 모듈식 응용 프로그램으로 게시, 위치 지정, 웹을 통해 호출할 수 있는 새로운 웹 응용 프로그램 분기입니다. 웹 서비스는 간단한 요청에서 복잡한 비즈니스 처리에 이르는 모든 기능을 수행할 수 있습니다. 일단 배포되면 다른 웹 서비스 응용 프로그램은 배포된 서비스를 찾아 호출할 수 있습니다.
웹 서비스는 HTTP (hypertext transfer protocol) 및 XML 과 같은 표준 인터넷 프로토콜을 사용하여 인터넷과 인트라넷에 기능강령을 구현하는 응용 프로그램입니다. 웹 서비스는 웹에서 구성 요소 프로그래밍으로 간주할 수 있습니다.
1 내역
웹에서 널리 사용되는 기술:
◆TCP/IP: 다양한 장비에 사용되는 범용 네트워크 프로토콜
◆HTML: HTML 태그를 사용하여 데이터를 표시할 수 있는 범용 사용자 인터페이스
◆ 자바: 어디서나 실행할 수 있는 범용 프로그래밍 언어 쓰기
◆XML: 웹에서 조직 된 데이터를 전송하는 쉬운 방법
그들의 특징은 개방성, 플랫폼 간, 개방성이 바로 웹 서비스의 기초라는 것이다.
2 웹 개발 동향
보다 동적인 콘텐츠
◆ 대역폭 Bandwidth 더 싸고 쉽게 구할 수 있음
◆ 메모리 스토리지보다 저렴하고 쉽게 구할 수 있음
◆ 범용 컴퓨팅이 더욱 중요해졌습니다. 휴대폰, 페이지, 컴퓨터, PC 와 같은 많은 장비가 인터넷에서 보편화되고 플랫폼이 다양해지고 있습니다. XML 과 같은 크로스 플랫폼 기술이 더욱 중요해졌습니다.
3 웹 서비스는 어떤 역할을 합니까?
이러한 추세는 보다 지능적인 처리, 운영 및 요약 컨텐츠가 매우 중요하다는 것을 의미합니다. 웹 서비스 관점으로 예측된 네 가지 트렌드
를 살펴보겠습니다◆ 내용이 더 동적이다: 웹 서비스는 주식, 날씨, 뉴스 등 여러 가지 다른 출처의 콘텐츠를 통합할 수 있어야 하며, 재고 수준, 쇼핑 주문 또는 카탈로그 정보 등 기존 환경의 내용은 백엔드 시스템에서
온다◆ 대역폭이 더 싸다: 웹 서비스는 다양한 유형의 콘텐츠 (오디오, 비디오 스트리밍 등)
를 배포할 수 있다◆ 저장이 저렴하다: 웹 서비스는 대량의 데이터를 지능적으로 처리할 수 있어야 한다. 즉 데이터베이스, LDAP 디렉터리, 버퍼, 로드 밸런싱 소프트웨어 등의 기술을 사용하여 확장성을 유지해야 한다는 의미다.
◆ 유니버설 컴퓨팅이 더 중요하다: 웹 서비스는 고객에게 특정 버전의 windows 의 기존 브라우저를 사용하도록 요구할 수 없으며 다양한 장치, 플랫폼, 브라우저 유형, 다양한 콘텐츠 유형을 지원해야 한다.
4 두 가지 중요한 기술
이러한 목표를 달성하기 위해 웹 서비스는
의 두 가지 기술을 사용합니다◆XML XML 은 웹에서 구조화된 데이터를 전송하는 위대한 방법입니다. 웹 서비스는 HTML 이 요구 사항을 충족하지 못하는 신뢰할 수 있는 자동 방식으로 데이터를 조작해야 합니다. XML 은 웹 서비스가 쉽게 데이터를 처리할 수 있도록 합니다. 그 내용과 표현의 분리가 이상적입니다.
◆SOAP SOAP 는 XML 메시지를 사용하여 원격 메서드를 호출하므로 웹 서비스는 HTTP 프로토콜의 post 및 get 방법을 통해 원격 시스템과 상호 작용할 수 있으며 SOAP 는 더욱 견고하고 유연하며 사용하기 쉽습니다.
기타 UDDI 및 WSDL 기술은 XML 및 SOAP 기술과 긴밀하게 결합되어 서비스 검색에 사용됩니다. Lt; /spangt;
웹 서비스 플랫폼을 구성하는 세 가지 기술입니다.
XML 과 XSD
Extensible markup language (XML) 는 웹 서비스 플랫폼에서 데이터를 나타내는 기본 형식입니다.
쉽게 구축하고 분석할 수 있을 뿐만 아니라 XML 의 주요 장점은 플랫폼 독립적 및 공급업체 종속적이라는 것입니다. 무관성은 기술적 우월성보다 더 중요하다. 소프트웨어 제조업체는 경쟁사가 발명한 기술을 선택하지 않을 것이다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 예술명언)
XML 은 데이터 표현 문제를 해결했지만 표준 데이터 유형을 정의하지 않았으며, 이 데이터 유형을 확장하는 방법은 말할 것도 없었습니다. 예를 들어, 성형 번호는 무엇을 의미합니까? 16 비트, 32 비트 또는 64 비트? 이러한 세부 사항은 상호 운용성을 달성하는 데 중요합니다. W3C 에서 개발한 XSD (XML 스키마) 는 이 문제를 전문적으로 해결하는 표준입니다. 표준 데이터 유형 세트를 정의하고 이 데이터 유형을 확장할 수 있는 언어를 제공합니다. 웹 서비스 플랫폼은 XSD 를 데이터 유형 시스템으로 사용합니다. VB.NET 또는 C# 과 같은 언어로 웹 서비스를 구성할 때 웹 서비스 표준을 준수하려면 사용하는 모든 데이터 유형을 XSD 유형으로 변환해야 합니다. 사용하는 도구가 자동으로 이 전환을 완료했을 수도 있지만 필요에 따라 변환 프로세스를 수정할 수 있습니다.
WSDL
웹 서비스의 기능 및 각 함수 호출 시 매개 변수를 다른 사람에게 어떻게 소개할 수 있습니까? 스스로 문서 한 세트를 쓸 수도 있고, 웹 서비스를 사용해야 하는 사람에게 구두로 말할 수도 있다. (조지 버나드 쇼, 자기관리명언) 이러한 비공식적인 방법에는 적어도 한 가지 심각한 문제가 있습니다. 프로그래머가 컴퓨터 앞에 앉아서 웹 서비스를 사용하려고 할 때, Visual Studio 와 같은 그들의 도구는 웹 서비스를 전혀 이해하지 못하기 때문에 도움을 줄 수 없습니다. (데이비드 아셀 Studio, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마), 컴퓨터명언) 해결책은 기계가 읽을 수 있는 방식으로 공식적인 설명 문서를 제공하는 것이다. WSDL (Web service description language) 은 웹 서비스와 해당 함수, 매개 변수 및 반환 값을 설명하는 XML 기반 언어입니다. XML 을 기반으로 하기 때문에 WSDL 은 기계가 읽을 수 있는 동시에 읽을 수 있는 것이기 때문에 큰 장점이 될 것입니다. 일부 최신 개발 도구는 웹 서비스에서 WSDL 문서와 WSDL 문서를 모두 생성하여 해당 웹 서비스를 호출하는 코드를 생성합니다.