웹 서비스 개념 및 교육 내용

1. 웹 서비스 소개

/*웹 서비스를 소개하고 웹 서비스 기초를 알아보며 컴퓨터 패러다임 근간을 통해 웹 서비스의 등장배경을 살펴본다. 웹 서비스 구현을 위한 기본 기술요소와 웹 서비스 시스템의 다양한 컴포넌트들에 대한 윤곽을 이해한다.*/

웹 서비스는 표준 인터넷 기술을 이용하여 동적으로 상호작용 하는 소프트웨어 컴포넌트 들이다. 웹 서비스는 개발하는데 많은 노력을 요구하는 IT 시스템들 간의 연결 교량을 만드는 것을 가능하게 한다.(Gartner Group)

인터넷 프로토콜들과 포맷들을 통하여 다른 소프트웨어가 사용할 수 있도록 설계된 소프트웨어.(Forrester Research)

웹 서 비스에 필요한 기술들(HTTP, XML, SOAP, WSDL, UDDI)에 대하여 합의를 한다면, 웹 서비스를 일관성 (consistent)있고 메시지 지향의 전송 메커니즘을 사용한 서비스의 호출을 위한 투명한(transparent) API 등 을 제공하며 데이터의 표현과 변환을 위해서 XML을 사용함으로써 동적인 위치 파악과 연결이 가능한 소프트웨어 컴포넌트 이다.

언어나 플랫폼 그리고 운영체제에 관계없이 웹을 통해 애플리케이션들이 상호작용 가능한 시스템.

1.1. 웹 서비스 기초
언어, 개발독, 플랫폼에 독립적이며 산업계에서 용인된 공개 표준들에 기반하고 있다.
느슨히 결합된(loosely-coupled) 서비스 기반의 애플리케이션들로서, 확립된 프로토콜들을 이용하는 통신을 위한 API를 제공함으로써 연결성을 높이고 복잡성을 줄인다.
관여하는 시스템에 상관없이 기계 대 기계의 자동화된 직접적인 커뮤니케이션을 가능하게 한다.
서비스 검색과 공표(publishing)를 위한 공통의 메커니즘을 이용해서 공표된 웹 서비스들을 찾는 것을 가능하게 한다./*UDDI, JAX-R*/

웹 서비스 정의를 위한 단일 표준 명세서가 존재하지 않기 때문에 특정 애플리케이션의 웹 서비스 파단을 위해 사용되는 표준항목은 다음과 같다./*웹 서비스에 필요한 기술들*/

- Extensible Markup Language 또는 XML은 독립적인 방법으로 데이터를 표현하기 위한 표준으로 XML은 데이터 정의뿐만 아니라 다른 프로토콜들 내부의 모든 서술에도 사용된다./*SOAP*/
- HyperText Transfer Protocol 또는 HTTP는 인터넷상의 또는 인트라넷 내부에서의 운송을 위한 것이다. HTTP는 데이터 전송과 요청/응답 형태의 통신을 위한 메커니즘을 제공한다.
- Simple Object Access Protocol 또 는 SOAP은 요청/응답의 정의를 위한 메커니즘을 제공하며, 원격 프로시저 호출 (Remote Procedure Call, RPC) 형식의 대화를 가능하게 한다./*쉽게 SOAP은 클라이언트 애플리케이션이 실제 로 웹 서비스를 호출하게 해주며 클라이언트와 제공하는 애플리케이션이 구현된 언어에는 무관하다. SOAP 프로토콜의 순수한 자바 버 전은 JAX-RPC, 아파치에서 한것이 Axis. 자바환경에서는 둘중 하나 쓴다. 물론 벤더 제품군은 빼고…*/
- Universal Description, Discovery and Integration 또 는 UDDI는 공급자와 서비스의 공통 등록기(Registry)를 통하여 서비스의 위치를 찾는 방법을 제공한다. /*UDDI에 정통한 대부분의 사람들은 UDDI가 DNS와 같은 규모의 광역 등록기가 되지는 않을 것으로 보고 있다*/
- Web Services Description Language 또 는 WSDL은 특정 서비스를 호출하는데 필요한 자세한 정보를 제공한다./*CORBA 의 IDL(Interface Definistion Language) 또는 Deploy Description 이라고 보면 된다*/

1.2. 컴퓨터 패러다임
최근의 IT시장에서의 상황 은 또 하나의 큰 패러다임 전환기를 맞고 있다. 과거에 Main Frame에서 Client/Server로의 큰 변화가 있었고, 지금은 Java와 EJB, 어플리케이션 서버라는 용 어가 인터넷을 등에 업고 새로운 변화의 시작단계를 지났으며. 이러한 패러다임은 기능상의 추가나 변경이 있을 수는 있지만, 최소 한 이러한 기본 마인드와 골격은 향후 한동안 변하지 않을 것으로 예상된다.
근래에 와서 컴퓨터 패러다임은 사용자 입장이 아 닌 개발자 입장 위주로 변천 하고 있다. 즉 서비스를 제공하기위한 기반 시스템 구축 및 개발에 포커싱 되어 시장이 형성 되고 있다. 정보기술 및 컴퓨팅 관련 분야의 권위자 입장에서의 해석이 이러하며 관련 분야의 시장 구도 또한 다르지 않다.

1.2.1. Main Frame 시스템
서비스와 데이터를 중앙집중 방식으로 단일 관리하는 Main Frame 시스템

- Program + Data = Size 및 관리 문제 발생
- 고성능 Workstation 및 경량 Server의 등장
- C/S Network 구조기반으로 Protocol과 Request/Response가 긴밀한 Interface Module로 형성
- Process Panic(Concurrent Request Processing)으로 Thread 기법이 필요
- NASAPI, ISAPI가 지원되나 사용하기 어렵고 Platform Dependent 문제로 Independent가 고려됨

1.2.2. 분산환경 기술 및 분산기술 표준
EDI(Eletronic Data Interchange) 나 CORBA (Common Object Request Broker Architecture)와 EJB 같은 분산환경 기술 및 분산기술의 표준 에 대한 시도가 있었으나 이러한 분산 객체 기술들은 상호운용성(interoperability)을 돕는 대안으로 한계를 보이게 되 며 웹 서비스와 비교했을 때 몇 가지 결점을 나타낸다./*부분적인 성공만 성과로 평가됨*/

- EDI는 너무 많은 비용이 소요되며 구현하는 데 엄청난 노력이 필요/*기술의 난해성*/
- 클라이언트-서버의 형태로 내부의 애플리케이션에 접근하는 것을 배제하며, 결국 서로 작용하는

  시스템이 늘어날수록 서로다른 시스템을 사용하고 있을 가능성이 커지므로 여러 개의 터미널이

  필요하게 되어 데이터의 투명성이 보장되지 않음

문서 표현의 한계(Low Level Protocol)
- CORBA와 EJB는 상당히 강건한 통신 메커니즘을 제공하지만 API가 복잡하거나(CORBA)

  특허권이 있는 상태(EJB)
- 기존 기술의 표준화 실패

산 업계에서는 EDI를 가지고 표준을 마련하려고 했던 적이 있으나 불행하게도 EDI는 그 수용력에서 명백한 한계를 가지고 있었다. EDI 트랜잭션은 보통 고정된 메시지 포맷을 명시한 구현 지침에 따라 작동한다. 그러나 급격히 변화하는 비즈니스 환경에서 EDI 의 비즈니스 규칙은 그런 식의 예측성을 포함할 수 없으므로 EDI 트랜잭션은 하나의 산업에서 다른 산업으로 심지어 같은 산업 내 의 다른 부문 간의 연결에도 어려움이 있다. 결국 EDI는 표준화 되었지만 융통성이 없다.

이에 반해 웹 서비스는 컴퓨터 환경에 상관없이 인터넷(또는 회사 내부에서라면 인트라넷) 접근이 가능한 환경에서 원하는 누구에게나 서비스 제공이 가능 하다.

1.2.3. 기업 애플리케이션 통합
기 업 애플리케이션 통합 또는 EAI(Enterprise Application Integration)은 분산환경 기술 및 분산기술 표 준 문제의 일부를 해결하기 위한 시도 이다. EAI는 기업 내에서 사용하던 기술들을 기업간에도 사용할 수 있게 해주며 표준 사용을 통한 간소화 와 비용 절감이라는 유례없는 방 법을 제공한다.
EAI는 허브(hub) 또는 버스(bus) 개념을 도입하여 각 시스템은 여러 개의 인터페이스가 아니라, 시스 템 별로 표준화 된 단 한 개의 인터페이스만 필요 하다. 비즈니스 관점에서 EAI는 여러 개의 시스템이 하나의 단일 복합 시스템으로 작동 가능하게 하므로 효율성을 제고하기 위한 것이다. 표준 인터페이스를 만들어서 시스템들의 상호운용에서 생기는 복잡성을 감소시킨다. 하 지만 EAI는 전매 특허권이 있으며 인터넷에 기반하고 있지 않으므로 회사의 경계에서는 효력이 없어진다. EAI 솔루션이 전매 특허 권이 있다는 것은 기업의 수준에서 본다면 하나의 간단한 인터페이스가 회사 간에 존재하지 않는다는 것을 의미한다. 다른 EAI 제품 솔루션간 여러 개의 인터페이스를 작성해야 하며 모든 회사들이 EAI를 사용하지 않기 때문에 또다른 인터페이스 들 또한 개발되어야 한다.

웹 서비스는 이러한 문제를 해결한다.
UDDI 등록기는 회사가 자신의 서비스를 모두에 게 선전하게 해준다. WSDL은 이렇게 선전한 서비스들을 제공하는 인터페이스를 기술 해준다. SOAP은 협업 파트너들 사이의 인터 페이스에 따르는 메시지의 전송을 가능하게 한다. 공개 표준에 기반한 기술이기 때문에 특허권이 있는 인터페이스에 대한 필요를 제거해 준다. 전매 특허권이 있는 솔루션을 사용하고 웹 서비스로 옮겨가기 위한 인터페이스나 중간 프로그램을 작성하는 것보다는 웹 서비스를 이용해 서 애플리케이션 교량을 건설하는 것이 언제라도 추가되는 파트너에 대한 빠른 서비스 전환이 가능하므로 시스템의 유연성을 보장 할 수 있다./*주요 EAI 판매자들은 이미 웹 서비스를 지원하고 있거나 근시일 내에 지원할 것임은 이러한 점에서 주목할만 하다* /

1.2.4. 서비스 지향 아키텍처
사용자 인터페이스에서 독립적인 서비스로서의 소프트웨어 설계 개념인 서비 스 지향 아키텍쳐(Service-Oriented Architecture, SOA) 개념이 소프트웨어 공학의 전망에 포함이 된 것 은 십년 이상 되었다. 기본적으로 SOA는 애플리케이션의 설계가 서비스의 집합이라는 것을 의미 하며 애플리케이션을 표현 코드 또는 서비스를 이용하는 다 른 코드로 생각 한다. 이러한 설계 유형을 이용해서 다른 클라이언트들을 만들 수 있고 그것들을 필요한 대로 HTML 페이지, 애플 리케이션, 무선 애플리케이션 등으로 분산 한다./*단지 MVC가 아니다. 별도 클라이언트라고 봐야 한다. 이 클라이언트에 서비스 를 제공할 수 있는 SOA로 작성한다*/

DCE(Distributed Computing Environment) 와 CORBA(Common Object Request Broker Architecture)같은 분산 컴퓨팅의 초기 시도들은 애플리 케이션의 비즈니스 논리(business logic)가 반드시 표현 논리(presentation logic)과 결합되어 있을 필요 가 없다는 것을 깨닫게 하였다. 비즈니스 논리는 완전히 분리될 수 있으며, 정의 된 API(Application Programming Interface)와 함계 제공될 수 있다.

논리를 서비스로 분리하면 사용자 인터페이스는 더 이상 비즈니스 논리와 같은 물리적 게층에서 운영할 필요가 없어지며, 둘 다 독립적으로 확장될 수 있다./*플랫폼 독립성의 기술적 논점에 대한 얘기 이다*/

서 비스를 강력하게 지원해 주는 몇몇 플랫폼들이 있는데, 자바와 닷넷이 대표적이다. 둘 다 트랜잭션 관리, 영속성 관리, 상태 관 리 등을 제공하며, 서비스 설계의 복잡성(예를 들면, 안전 쓰레드(thread-safe)의 다중 스레드 코드 작성)을 제거해 준 다.

서비스가 진정으로 중립적이고 플랫폼에 독립적이기 위해서는 클라이언트와 서비스 사이의 데이터 교환을 위한 중립적인 표현이 필요하다는 것이 인식 되었다.

/*즉 확장성 마크업 언어(XML)가 컴포넌트로서 필요하다는 것이 입증 된 것.

자 바만 사용되는 환경에서는 이 정도로 충분할 것이지만 대부분의 조직의 환경이 균질적이지(homogeneous)는 않다. 모든 프로그 램이 서버와 통신하는 데 JRMP 기반의 RMI를 이용할 수는 없으며, J2EE 서버가 서비스들을 위해 내놓은 인터페이스는 우리 가 필요로 하는 발견과(discovery)과 같은 일부 특정을 배제하고 있다.*/

인터페이스의 표현이 비즈니스 논리 와 분리되고 비즈니스 논리가 다시 저장 논리와 분리되어 있을 때 각 부분은 분리된 하드웨어 플랫폼에서 운영할 수 있으며 별개의 업 무를 수행할 수 있다./*역시 같은 플랫폼 독립성의 기술적 논점에 대한 얘기 이다*/

비즈니스 논리를 이용하는 새로운 시스템을 추가하는 데 코드나 애플리케이션 구조를 변경할 필요가 없으며 웹 서비스는 이 SOA의 개념에 완벽하게 들어맞는다.

웹 서비스는 서비스 아키텍처의 다음 단계의 논리적 추상화(abstraction)이다./*추상화 이며 또한 구체화 되어 있고, 실제 표준화된 적용방향 제시라고 볼 수 있다.*/

웹 서비스는 어떤 기계, 언어, 플랫폼에서 운영되는 클라이언트에게나 서비스의 발견, 기술, 호출을 쉽고 투명하게 해준다./*JAX-R을 이용한 UDDI, WSDL, 투명하긴하나 정말 쉬운가…*/

결 국 분산환경에서의 컴퓨터 패러다임 은 Network Program(C/S:Socket, RMI) -> Distribute Envilopment(CORBA, EDI, .net /EJB) -> EAI -> Web Service 와 같은 흐름 이다.

/*

SOA는 가장 마지막에 설명 되었지만 근 10년 이상전부 터 고려된 개념임을 감안할 때 맨앞에 두어야 언급하는게 순서이다. 정확하게 소프트웨어 패러다임 발전형태의 흐름이므로 C/S부 터 Web Service까지 전체 Base Line이라고 봐야 할 듯 하다. RMI는 두고 두고 써먹을수 있는 보루가 되는 기술이고 분산 아키텍처의 기본 근간이 되므로 재미삼아 샘플을 구현해 보고 다음 3가 지 정도만 정확히 이해한다면 마스터 수준이다.

1. Call Back(동기/비동기)
2. 동적 클래스 로딩 : Dynamic Class Loading(Security Manager, Policy File)
3. 원격 객체 활성화 : Remote Object Activation
Java Network Programming 이런거 말고 한빛 미디어 Perfect EJB의 1~3장 까지 부분을 보는게 좋다.
*/

1.3. 웹 서비스 시스템 APIs
1.3.1. SOAP
XML 언어를 이용한 분산 환경에서의 정보 교환을 위한 프로토콜로 XML Messaging의 표준 이다.
SOAP 역 시 XML에 기반하고 있으며 각 SOAP 메시지는 XML 문서 이다. 클라이언트 애플리케이션이 실제로 웹 서비스를 호출하게 해주며 클라이언트와 제공하는 애플리케이션이 구현된 언어와는 무관하다. 2000년 5월 8일 W3C에 노트 되어 공식화(1.1 Spec Note) 되었으며 2003년 5월 7 일 1.2 Spec  Proposed Recommendation 되었다.

SOAP의 특징은 다음과 같다.
- 경량 프로토콜로 CORBA, RMI, DCOM과 같은 다른 분산 컴퓨팅 프로토콜의 내용보다 적기 때문에 프로토콜 자체가 복잡하지 않고 lightweight.
- Text- based XML 포멧 사용하므로 하드웨어 플랫폼, 운영체제, 프로그래밍 언어 전 영역에 걸쳐서 독립적인 프로토콜./*이전 분 산 컴퓨팅 프로토콜은 이진(binary) 포멧 메세지를 사용하기 때문에 특정 플랫폼, S/W에 종속적 이었다*/
- 기본적으로 HTTP 프로토콜로 전송 되므로 인터넷 연결 시스템과 추가 적인 구성없이 통신 가능. /*SOAP 메시지를 HTTP 전송 프로토콜에 바인딩하여 전송, FTP, EMAIL 등등 기타도 가능*/
- 방화벽에 제한되지 않으나 반대로 비허가 사용자도 SOAP 응용프로그램에 접근할 수 있게 되므로 보안을 고려해야 함.
- 자바는 XML RPC를 위한 자바 API(JAX-RPC)를 제공하여 원격 프로시저 호출(RPC)을 실행할 수 있게 한다./*JAX-RPC는 SOAP 프로토콜의 순수한 자바 버전을 구현한다.*/
- 서비스가 요구하는 정보를 포함하고 있는/*말이어렵지 호출 정보, 프로토콜 정보 등등과 파라메터 등이다*/ 문서를/*SOAP 메시지*/ 애플리케이션에서 서비스로/*웹 서비스*/ 건네주고 응답을 받는다

Information Models(Service Model)유형에 따라 XML-based, SOAP-based 웹 서비스로 구분된다.
- 정보 전달용 XML 메시지로 구성인 Document-Style Information Model
- 원격 프로시저 호출(Remote Procedure Call)을 하는 XML 메시지로 구성인 Parameter(RPC)-Style Information Model

SOAP-based 방식은 XML Vocabulary로 볼 수 있고, XML-based 방식은 XML Directly이며 REST(Representational State Transfer)라 부르기도 한다.

REST 방식은 SOAP-based 방식에 비해 단순 XML 문서의 전달 이므로 단순하며 보다 빠르게 개발이 가능하다.

1.3.2. WSDL
Web Service Definition Language 은 IBM, Microsoft 등의 회사들이 웹 서비스 시스템 기능을 명세화시키는 방법을 표준화하기 위해 만들어 졌으며 2001 년 3월 14일 W3C에서 WSDL 1.1 Note로 공식화 되었다.

웹 서비스 명세서로 표준 분산 컴퓨팅 기술인 CORBA의 IDL(Interface Definistion Language)에 해당 된다.

SOAP의 Service Model에 따라 Document-Style Service, RPC-Style Service로 구분된 정보를 포함한다.

실제 호출하는 원격 프로시저명, 인자, 반환형 및 SOAP 메시지를 전송하는 전송프로토콜의 종류를 기술하며 웹 서비스 시스템의 URL(endpoint) 정보도 포함한다.

- 웹 서비스의 기능을 구체적으로 명세화 하여 웹 서비스의 정보 및 사용법 알수 있다./*사람, 시스템*/
- 정확한 서비스 해석을 위한 웹 서비스를 명세화하는 공통적인 규약(스펙)의 역할
- 웹 서비스 소비자는 다양한 플랫폼에서 실행되는 응용프로그램임을 고려하여 플랫폼과 특정  S/W에 종속적이지 않는 포맷으로 작성 하기 위해 XML 사용
- WSDL 문서를 해석한 후 클라이언트 응용프로그램은 웹 서비스 시스템의 사용법을 알게되고 이후 SOAP 메시지를 생성하여, 전송

/*
마치 EJB 개발시 자동으로 만들어주는 Deploy Discriptor와도 같다
DD 는 EJB IDE가 만들어 주고(? Deploy tool이…) Container에서 사용하기 위한 용도 이지만 명세로써의 역할 을 충분히 수행할 수 있고 EJB Client(다른 EJB) 작성 시 참조 할 수 있다.물론 API Doc도 있지만..
WSDL도 자동 생성하지만 해당 서비스를 용도에 맞게 식별하고 논리적으로 이해하기 위해서는 인위적인 식별이 가능할 정도로 이해할 수 있어야 한다.
웹서비스의 정형화된 시작은 UDDI 레지스트리에 Publish 하고 Find 함으로 시작 된다.
*/

IBM 웹 서비스 툴킷의 일부인 Java2WSDL 툴은 자바 클래스로 부터 WSDL을 생성하게 해주며 WSDL2Java 툴은 개발자가 WSDL 문서로부터 자바 클래스 스텁(stub)을 생성 해 준다.

Java 표준 API에 포함된 wscompile도 WSDL로 부터 자바 클래스 스텁(stub)및 서버 타이(tie)를 자동 생성 해준다.

1.3.3. UDDI
Universal Description, Discovery, and Integration 레지스트리(Registry)는 각종 정보들을 생성, 저장, 검색할 수 있는 XML 기반의 자료 저장 장치(소프트웨어+하드웨어) 이다.

웹 서비스를 공표하는 수단으로 공적 UDDI 레지스트리는 IBM, MS, Systinet, xMethods와 같은 소프트웨어 회사들이 제공하고 있다.

웹 서비스는 현재 뉴스 배급회사와 같은 거대한 시스템을 비롯하여 날씨, 주식정보, 배송추적과 같은 세부적인 시스템까지 운영되고 있다./*JNDI 또는 LDAP과 같다고 이해하자*/

UDDI를 사용하기위한 주요항목과 흐름은 다음과 같다
- UDDI 레지스트리의 클라이언트가 UDDI 레지스트리에 접근해서 정보를 저장하고 찾기 위해서 SOAP 메세지를 이용
- SOAP 메시지의 전송용 프로토콜로 HTTP 프로토콜을 사용하여 플랫폼과 구현 언어에 독립적으로 사용 가능
- UDDI 레지스트리 클라이언트는 UDDI 레지스트리 프로바이더(드라이버)를 통해서 SOAP 메시지를 생성하고 전송한다.
- UDDI 레지스트리가 XML 기반의 자료 저장 장치이기 때문에 UDDI 레지스트리 간의 데이터 교환이 자유로움/*XML 문서 포맷으로 데이터 교환*/
- 클라이언트 프로그램이 UDDI 레지스트리에 비즈니스 정보를 게시하거나 찾기 위해서는 클라이언트 요청을 XML 문서로 작성후 다시 요청 SOAP으로 포장하여 전송/*SOAP!!! 원격 프로시저 호출이 가능!!!*/

UDDI API Spec에 UDDI 클라이언트가 UDDI 레지스트리에 작업을 수행하기 휘한 클라이언트에서 사용할 수 있는 XML 엘리먼트를 정의 한다.

이러한 엘리먼트들은 클라이언트 요청 SOAP 메시지에 포함되어 원격 프로시저 호출로 사용된다.

Publish API 엘리먼트 비즈니스 정보를 생성, 수정, 삭제 용도로 사용되며 Inquiry API 엘리먼트는 웹 서비스 클라이언트의 비즈니스 정보 검색으로 사용된다.

UDDI 레지스트리에서 SOAP 해석후 API 엘리먼트 추출후 처리하고, 처리 결과는 다시 SOAP 메시지로 클라이언트에 전송 한다.

UDDI API 엘리먼트 생성후 SOAP 메시지로 포장하고 HTTP 프로토콜로 전송까지 전담하는 Tool로 IBM의 UDDI4J 과 표준 Java API인 JAXR 프로바이더가 있다.

1.3.4. JAXR
Java API for XML Registries는 ebXML이나 UDDI와 같은 XML 레지스트리에 일관되게 접근하여 UDDI 레지스트리에 정보를 저장하거나 검색 할 수 있는 표준 Java API 이다.

JDBC 와 유사한 개념으로 이해할 수 있으나,  JDBC 는 각각의 드라이버를 설치 하고 구현하는것에 비해 UDDI 프로바이더 프로토콜은 SOAP 메세지 기반의 표준 접속 프로토콜이라는 차이점이 있다.

JAXR 프로바이더는 JAXR 인터페이스를 구현해서 벤더들이 만든 UDDI 레지스트리 접속용 프로그램으로 javax.xml.registry 패키지에 있는 인터페이스 메소드를 구현 한다.

JAXR의 인터페이스를 준수하여 프로바이더(UDDI 레지스트리 접속용 프로그램) 개발되므로 JAXR 사용시  UDDI 인터페이스의 표준화 및 일관된 인터페이스 유지가 가능하다.

1.3.5. JAXB
Java API for XML Biniding(JAXB)은 XML과 Java Code 사이를 매핑하는 표준 방법을 제공 한다.

Java Class를 XML 문서로 바꿔주는 Marshalling 기능과 XML 문서를 Java class로 바꿔주는 Unmarshalling 기능이 가능하다.

XML Schema문서 정보로 에서 XJC Compiler를 사용해서 class로 생성할 수 있다.

1.3.6. SAAJ
SOAP with Attachments API for Java은 JAX-RPC, JAXR 이 실행되기 위해 반드시 필요한 API.

javax.xml.soap API를 사용하여 XML Message(SOAP)으로 작성하는 방법과 별도로 JAXM으로 Client Stub 객체 및 Server Tie를 직접 구현할 수 있다.

Stub, Tie 직접구현 이외에도 자바 언어로 웹 서비스 구현시 JAX-RPC를 사용하는 대신에 직접적으로 SAAJ를 이용해서 프로그래밍하면 다음과 같은 처리가 가능하다.

- SOAP 클라이언트 직접구현
- SOAP 메시지 작성
- 데이터 첨부(바이너리)
- SOAP 메시지를 생성
- 웹 서비스 시스템과 웹 서비스 클라이언트 간의 point-to-point 연결을 이용해서 SOAP 메시지를 전송

살펴본바와 같이 Direct Connect 방식이며 코딩량이 증가하나 자유롭게 구성이 가능한 장점이 있다.

서비스 해석를 해석하기 위한 인터페이스가 정의 되어 있지 않다면 요청 서비스해석 또는 요청 결과 수신 처리시 로직 및 코드가 많아진다.

과거에는 SAAJ와 JAXM이 분리되어 구분 되었으나 현재는 SAAJ가 JAXM을 포함하고 있다./*그러나 패키지는 여전히 javax.xml.soap과 javax.xml.messaging로 분리되어 있다.*/

1.3.7. JAXM
Java API for XML Messaging  비동기적인 웹 서비스 구현을 위한 API 이다.

1.3.8. JAXP
Java API for XML Processing - javax.xml.parsers

DOM 또는 SAX의 표준 처리를 위해 Sun에서 제안한 표준으로 개발 환경에 종속적이지 않은 표준처리가 가능하게 해준다./*코드레벨 변경 발생하지 않음*/

DOM(Document Object Model) 및 SAX(Simple API for XML) 파서를 생성하여 XML 문서를 해석하고 처리한다.

디폴트 파서로 Apache Group 의 Xerces 2 파서를 사용한다

XSLT(XML Stylesheet Language Transformations) 관련 API도 포함하고 있기 때문에 Apache Group의 Xalan 엔진을 사용해서 XSL문서를 이용해서 XML 문서를 변환

웹 서비스 응용프로그램 개발할 때 직접적으로 개발자가 JAXP로 프로그래밍을 하지 않지만 내부적으로 다른 API들이 XML 문서를 해 석할 때 때 JAXP를 이용한다./*웹서비스 시스템 및 웹서비스 틀라이언트 프로그램 쪽에 반드시 있어야 할 API*/

1.3.9. JAX-RPC
웹 서비스 시스템 및 웹 서비스 클라이언트를 개발하기 위한 Java API로 JAX-RPC API 또는 JAX-RPC Runtime 라고 한다.

XML RPC를 위한 자바 API(JAX-RPC)를 제공하여 원격 프로시저 호출(RPC)을 실행할 수 있게 한다.

JAX-RPC는 SOAP 프로토콜의 순수한 자바 버전을 구현 이며 XML-based protocol인 SOAP을 사용 한다.

JAX- RPC는 클라이언트 측의 플랫폼과 프로그래밍 언어에 구애받지 않는 웹 서비스 구현이 가능하고, 자바 언어 이외의 프로그래밍 언어 로 작성된 웹 서비스 시스템의 원격 프로시저를 호출 할 수 있으므로 상호 운용(interoperability)을 보장한다.

요청과 응답에 기반한 SOAP 메시징 방식으로 비동기적인(asynchoronous) SOAP 메세징 방식은 지원하지 않는다./*말그대로 RPC 이다*/

원격 클라이언트에 의해 호출될 수 있는 원격 프로시저의 기능을 포함한 서블릿(Servlet)으로 작성된 웹 응용프로그램(WAR) 이다.

J2EE 1.4 스펙에서 JAX-RPC를 지원하고 일반적으로 무상태 세션빈(Stateless Session Bean)을 이용해서 웹 서비스를 구현할 수 있다.

wsdeploy 기능으로 서버측 Tie 클래스및 WSDL을 생성하며 WAR 모듈에 자동 추가 한다./*타이 클래스 생성을 위해서는 RMI interface 배치 기술자인 jaxrpc-ri.xml을 작성 해야한다*/

wscompile 기 능으로 WSDL을 참조(해석)하여 웹 서비스 시스템의 인터페이스 및 구현 클래스를 생성 한다./*stub 클래스 생성 (config.xml 문서 필요). 당연한 얘기지만 stub의 java 코드생성 포 함 wscompile -gen:client  -keep -d . config.xml */

다음과 같은 3가지의 클라이언트 호출 모델 적용 가능

- 정적 스텁 호출 모델은 WSDL 문서를 이용해서 수동으로 생성된 스텁 클래스를 이용해서 원격 프로시저 호출
- 동적 프록시 호출 모델은 수동으로 스텁 클래스를 생성하지 않고 실행 도중에 스텁 객체가 생성/*인터페이스는 생성되어 있음!!!*/
- 동 적 호출 인터페이스(Dynamic Invocation Interface:DII)은 원격 인터페이스를 알지 못해도 Call 객체 이 용하여 동적으로 원격 메소드를 호출 할 수 있다./*당연히 원격 프로시저명과 인자에 대한 정보는 알아야 하며 이는 RMI DCL 과 동일한 메커니즘 이다*/

내부적으로 JAXP, SAAJ를 이용하여 SOAP 메세지를 생성, 전송, 해석하는 역할 수행 한다.

1.3.10. JWSDP
Java Web Services Developer Pack 은 Sun사에서 배포 하는 XML 응용프로그램과 웹 서비스 시스템 및 웹서비스 클라이언트 개발 지원 하는 API를 포함하는 통 합 개발 툴킷 이다./*1.1 버전에서는 메시지 기반의 비동기적인 웹 서비스 시스템을 개발할 수 있는 JAXM이 포함되어 있으 나 JWSDP 1.2 부터는 JAXM이 포함되지 않는다.*/

JWSDP는 다음 API들을 포함한다.
- Java API for XML Biniding(JAXB)
- Java API for XML Messaging(JAXM)
- SOAP with Attachments API for Java(SAAJ)
- Java API for XML Processing(JAXP)
- Java API for XML Registries(JAXR)
- Java API for XML-based RPC(JAX-RPC)
- JavaServer Pages Standard Tag Library(JSTL)
- Tomcat
- ANT
- Registry Server(Java WSDP Registry Server는 Java로 만든 테스트용 UDDI 레지스트리. 테스트 버전이므로 UDDI 스펙을 전부 만족하지 못함)

JWSDP는 SOAP 엔진 부분에서 다시한번 다룬다.

2. XML
XML은 확장성 마크업 언어(Extensible Markup Language)를 뜻하며, 플랫폼에 얽매이지 않는 간단한 텍스트 문서 이다.

XML은 인간과 컴퓨터가 모두 같은 정도로 용이하게 XMl 문서로 표현된 데이터를 읽거나 사용하는 것을 가능하게 하는 자체 기술적인 언어이다.

SGML(Standard Generalized Markup Language)에 기초를 두며 SGML의 강력했으나 복잡한 언어였던 문제점을 단순화 하여 문서를 작성하는데 강력한 방법을 제공한다.

태 그 내에 추가 정보를 끼워 넣고, 유효성을 검사할 수 있는 메커니즘을 제공한다./* 주민등록증이나 신용카드, 또는 요즘 주로 사용 되는 온라인 증명발급에서의 진위확인 및 유효성 확인 정도로 이해해 보면 효용가치가 얼마나 높은지 알 수 있다 */

Well- Formed XML Document는 XML 1.0 권고안에 언급되어 있는 문법을 지켜서 작서된 문서 이 며, Valid Document는 Wel-Formed 이면서 XML로 개발된 특정 마크업 언어에 맞게 작성된 문서 이다.

Apache Well- formed Validate Pack(Xerces Parser), IEXMLTLS(Explorer용 XML 검증기 플러그인)등 을 통해 처리할 수 있다./*SPY, Validation.bat(이게 어디API 구분인지 확인할 것), 기타 IDE로도 수행…*/

XML은 텍스트에 기반하고 있으므로 HTTP상으로 전송될 수 있으며 방화벽과 프록시 서버도 쉽게 통과 할 수 있다.

자체 정의가 가능하므로 프로그래밍 언어에 독립적으로 데이터를 교환(상호 운용성) 할 수 있다. XML 1.0 권고에 의해 공식 문법을 간단한 EBNF(Extended Backus-Naur Form) 표기법을 사용 한다.

/*XML 스터디 자료로는 SUN 교육 XML with Java KR-SL-024  강의자료가 가장 좋다.*/

2.1. XML 문서 처리
XML 문서를 만들어내고 사용하기 위한 문서 객체 모델(Document Object Model, DOM)과 SAX(Simple API for XML) Parser가 있다.

JAXP(Java API for XML Processing)는 XML 파서 밴더들에 종속적이지 않은 XML 응용프로그램을 위한 API 이다.

DOM과 SAX는 모두 인터페이스와 예외라는 API를 정의 한다. DOM과 SAX를 사용하기 위해서는 각각의 인터페이스를 구현 클래스들이 필요하다./*이미 구현해서 제공되는 Xerces 파서와 같이 성능좋은 파서들이 있다*/

2.1.1. DOM
DOM은 XML 문서를 트리 객체로 다루는 API로 W3C의 추천을 받은 것이다. DOM은 XML 문서를 통째로 메모리상에 올린 다음 엘리먼트나 속성들을 추가, 삭제, 수정할 때 XML 문서 구조를 다룰 수 있다.

초기 DOM 스펙은 HTML의 다양한 엘리먼트들을 트리 객체의 일부로 다룰수 있도록  하며 HTML 문서에 간편성을 제공하기 위한 것이었다./*IEDEVToolbar 의 DOM 기능 보여줄 것*/

DOM 레 벨1이 1998년 중반에 W3C의 추천을 받았으며 2000년 후반에 XML 네임스페이스를 위한 중요한 보완이 이루어진 DOM 레 벨 2가 추천된다. DOM 레벨 3가 현재 작업중 이다./*Xerces는 레벨2 모듈을 모두 지원하며 시험적으로 레벨 3를 지원한 다*/

2.1.2. SAX
xml-dev 메일링 리스트 회원들이 1998년 중반에 SAX 1.0 API를 정의한 이후 현재 2.0까지 발전해 왔으며 2.0에서 네임스페이스를 포함하여 발전되었다.

JDK에서는 rt.jar에 lib를 제공하고 v1.4 이후 부터는 Crimson(SAX Parser)으로 제공한다.

Xerces Parser는 Crimson Parser를 Sun 에서 Apache에 의뢰 하여 Open Source로 개발된 Parser 이다.

초기에는 Crimson 성능이 좋았으나 Xerces의 버전업이 빠르고 성능이 좋아졌다.

Crimson 1.4와 1.5 버전에서 한글문제를 처리하고 버전이 다르나 1.5 에서는 Xerces 패치본으로 Crimson을 제공(1.5이후 버전은 Crimson과 Xerces는 동일하다)

SAX는 XML문서를 파싱하는데 있어서 이벤트가 발생하면 접근하는 것을 제공한다.

DOM방식과 달리 문서 전체를 메모리에 올리지 않으나 XML 문서를 순서대로 파싱하며, 파싱중 이벤트를 전달 하므로 응용프로그램은 파서에서 SAX API를 이용해 제공되는 콜벡 인터페이스의 구현을 등록할 수 있다.

SAX 2.0 파 서 클래스는 org.xml.sax.XMLReader 인터페이스의 구현이 필요하나 역시 일반적으로 파서 제작사들이 제작한 이 인터페 이스를 구현한 클래스들을 확장해서 사용한다./*Xerces org.xml.sax.helpers.DefaultHandler, 파 서 제작사의 의존성을 줄이기 위해 일반적으로 SAX 지원 패키 지 org.xml.parser.helper.XMLReaderFactory를 사용해서 팩토리 기반으로 파서를 생성한다*/

커다란 문서의 처리에 적합하며 DOM에 비해 처리속도가 빠르다.

2.1.3. SAX vs DOM
DOM은 사용하기 쉬운 인터페이스를 제공하며 데이터 조작이 가능하나 속도가 비교적 느리고 전체 문서가 메모리에 적재되어야 하는 단점이 있다. 반면에 큰 문서를 다루는데 더 좋은 방법은 SAX를 이용하는 것이다.

SAX와 DOM간의 Parsing 절차는 다음과 같다.

SAX 방식
1. JAXP를 활용하여 JAXP가
  1.1 SAXParserFactory를 생성
  1.2 SAXParserFactory로 SAXParser를 얻음

2. SAX 사용
  2.1 EventHandler를 작성
  2.2 Parsing

3 XML Document Processing/*SAX Parser의 Event During Parse에 의해서 Handler가 XML Document Processing*/

DOM 방식
1. JAXP를 활용하여 JAXP가
  1.1 DocumentBuilderFactory
  1.2 DocumentBuilder/*Parser라 하지 않고 Builder라 칭한다*/
  1.3 Builder가 XML Document Processing

2.1.4. JAXP
JAXP(The Java AI for XML Processing)는 SAX나 DOM 응용프로그램을 쓰는데 있어서 제작 회사에 독립적으로 사용가능하게 표준 인터페이스를 정의한 것으로 파서 변경과 작업에 있어서 독립성을 보장한다.

DOM 과 SAX 파서를 각각 감추는 포장 역할을 수행하며 XML 변환도 지원한다./*SAXParserFactory 클래스 는 SAXParser 인스턴스를 만드는데 필요한 메소드를 제공하며 SAXParser 클래스는 SAX XMLReader 인터페이스 를 감싸는 역할을 한다*/

2.2. NameSpace
하나의 XML 문서가 하나 이상의 소스에서 온 마크업을 포함할 때 발생하는 이름이 충돌하는 문제를 해결한다.

웹 서비스를 기술하는 웹 서비스 기술 언어(WSDL) 문서와 웹 서비스의 요청과 수락을 나타내는 SOAP 봉투에 광범위하게 사용된다.

네임스페이스는 이름에 유일한 URI로 부여된 접두사를 붙임으로 엘리먼트와 속성의 이름의 모허성 문제를 해결한다.

2.3. Contents Type
2.3.1. DTD
Document Type Definitions./*가장 좋은 샘플인 web.xml에 사용된 DTD 한번 분석해보고 외운다 생각하고 1시간 공들여 보면 도움도 많이되고 DTD 득도한다.*/

2.3.2. XML Schema
문서 원형 정의(Document Type Definitions, DTD)의 단점들을 보완한 것으로 XML 문서 내용을 표현하는 규범을 정한 구조 정의 언어(스키마 언어) 이다.

2001년 5월 XML Schema 1.1 W3C 권고안 채택 되었다.

스키마 문서에 정의된 구조대로 작성된 XML 문서를 스키마 인스턴스(Schema Instance)라 한다

DTD 는 문자 데이터(#PCDATA)형만 지정 가능했던 것에 비해 스키마에 built-in(미리 정의된) 심플 타입을 사용 할 수도 있고 사용자가 정의한 심플 타입을 사용할수 있다.

EBNF 표기법 숙지하고 있으면 DTD에서 확장 이해하는데 크게 무리가 없다.

/*
minOccurs, maxOccurs 생략되면 디폴트 각각 1,  unbounded 는 무한대
엘리먼트는 자식 엘리먼트 및 속성을 가지는 엘리먼트 데이터 타입으로 사용
엘리먼트는 자식 엘리먼트들이 선언된 순서 지시
엘리먼트는 데이터 타입을 기술하면서 속성을 정의할때 과 같이 상용되며 extension의 base 데이터 타입을 기술한다.

사용자 정의 심플 타입
요정도로만 생소한 엘리먼트 살펴보자.
*/

2.4. XML Protocol
원격 프로시저의 요청과 응답을 나타내는 XML을 사용하기 위한 XML RPC 와 SOAP 프로토콜 사용할 수 있다.

2.4.1. XML-RPC
XML-RPC는 원격의 프로시저 호출을 나타내는 스펙이다. XML-RPC는 국제표준은 아니나 HTTP 터널을 통해서 원격 프로시저 호출을 구현하는 표준에 버금가는 수준으로 볼 수 있다.

HTTP를 타고 가기 때문에 방화벽을 통과할 수 있다./*JRMP나 IIOP 같은 바이너리 프로토콜은 방화벽을 뚫을 수가 없다*/

XML-RPC를 구현한 http://xml.apache.org/xmlrpc는 XML-RPC를 사용하는 클라이언트와 서버 코드를 위한 프레임워크를 제공한다.

2.4.2. SOAP
SOAP은 텍스트 기반 프로토콜로 XML을 이용하여 환경에 의존적이지 않다.

3. 웹 서비스 구현

3.1. SOAP 엔진
웹 서비스 구현을 위한 서버 쪽과 클라이언트 쪽의 SOAP 애플리케이션의 개발을 도와주는 자바 클래스들의 집합이다.

실제로 SOAP 엔진은 다음과 같은 기능을 수행한다.
- 메소드 호출을 SOAP 패킷으로 직렬화
- SOAP패킷을 자바 호출로 역직렬화
- XML 문서를 SOAP 패킷으로 포장
- XML 문서를 SOAP 패킷에서 추출
- SOAP 요청을 보내고 응답을 다룸
- SOAP 요청을 받아들이고 응답을 보냄

Java 웹 서비스 개발시 주로 사용되는 SOAP 엔진은 다음과 같다.
- Apache SOAP 2.2

아파치 SOAP 엔진으로 WSDL과 같은 최근의 기술을 지원하지 않는다.
- Apache SOAP 3.0

Apache SOAP 3.0 엔진은 AXIS(Apache eXtensible Interaction System)로 알려져 있기도 하다.

이 엔진은 완전히 새로 작성되었기 때문에 실제로는 아파치 SOAP 엔진의 다음 버전이 이니다.
- Web Services Developer Pack

웹 서비스와 관련된 여러 가지 기술들의 묶음으로 예를들면, JAX-RPC를 사용할 수 있고 문서 스타일의 soap에 대해서는 JAXP를 사용할 수도 있다
- IBM Web Services Toolkit(WSTK)

IBM에서 제공되는 웹 서비스와 관련된 여러 가지 기술들의 묶음이라는 면에서 WSDP와 비슷하다. 이 툴킷은 AXIS를 SOAP엔진으로 사용한다.
- IBM WebSphere SDK for Web Services(WSDK)

IBM의 더 ‘공식적인’ 웹 서비스 꾸러미 이다. 역시 AXIS와 함께 사용하며 Xerces/*Xerces Parser*/, 사설 UDDI 등록기, 테스트 데이터베이스, WebSphere 웹 서버 등의 많은 컴포넌트들과 묶여있다.

.1.1. AXIS
Axis는 XML RPC를 구현한 API로 W3C의 SOAP 제안을 아파치(apache)에서 구현한 것이다.

다음은 Axis의 주요 항목 이다.

- Axis는 벤더 중립적(vendor-neutral)으로 제공된다
- Axis는 여러 벤더들이 채택해 왔다. IBM의 WSTK, Macromdeia의 JRun등의 일부로 Axis 구현을 사용한다.
- Axis는 JAX-RPC의 구현을 제공한다.
- Axis 는 맞춤화에 있어서 유연성을 제공하는 확장 가능한 구현을 제공한다./*예를 들어 웹 서비스 제공시 서비스가 아닌 클래스로 웹 서비 스 제공. 클래스를 웹 서비스로 변형하기 위해서는 아무것도 특별한 것이 필요하지 않다는 점*/

참고로 Axis에는 tcpmon(TCP 모니터)이라는 유용한 유틸리티가 있다. 웹 서비스 클라이언트와 웹 서비스 간의 TCP 터널(tunnel)을 확인할 수 있다.

3.1.2. JWSDP
Java Web Services Developer Pack
http://java.sun.com/webservices/downloads/webservicespack.html /*JBuilder에서 대충 찍찍 끌어 샘플 웹서비스 작성해서 보여줄 것*/

4. 웹 서비스 데이터 전송
웹 서비스 클라이언트와 서버 사이에 XML ans서 형식의 데이터가 교환되었다는 사실은 별로 중요하지 않다. 사실 RPC 모델 기준으로 JRMP와 같은 다른 프로토콜을 사용하여 구현할 수도 있다.

4.1. RPC-SOAP vs Document-SOAP
RPC 스타일의 SOAP 개발에서 클라이언트가 원격 메소드를 호출해서 웹 서비스가 서버에 하나 생성되게 한다. 클라이언트는 하나의 SOAP 요청을 전달하고 SOAP 응답을 받아 처리한다.

문서 스타일 SOAP 개발에서는 클라이언트가 XML 문서를 서버에게(웹 서비스가 인스턴스화된) 전달된다. 마찬가지로 하나의 SOAP 요청을 전달하고 SOAP 응답을 받아 처리한다.

그 러나 내부적인 관점에서 보면, 직열화와 역직열화(Serialization and De-serialization)의 차이가 있 다. 문서 스타일의 SOAP 개발에서 클라이언트는 자바 호출을 직열화할 필요가 없고, 인자로 XML 문서를 주면 된다. 거꾸로 서 버는 XML 문서를 자바 호출이나 데이터 타입으로 역직렬화할 필요가 없다.

RPC 스타일의 SOAP 개발에서는 클라이 언트는 인자를 가지는 메소드를 호출하고 서버는 응답으로 하나의 값을 반환하는 방식이므로 클라이언트와 서버가 잘 정의된 프로그래 밍 모델로 만들어져야 한다./*당연한 얘기지만 C/S간 구체적인 인터페이스 프토토콜이 정의되고 구현해야 한다.*/

문서 스타일의 SOAP 개발에서는 XML 문서가 교환되고 각각의 엘리먼트의 의미는 서버와 클라이언트가 해석 한다./*처리 모듈을 작성해야 하나 요청과 응답을 위한 복합적인 문서 꾸러미로 묶을수 있다.*/

- 문서 스타일의 모델은 SOAP 엔진에 대한 의존도가 낮다.
- 직렬화/역직렬화 단계가 없기 때문에 개발이 단순해지고 RPC 방식을 사용할 때 보다 처리 시간이 단축된다.
- XML 문서는 RPC 보다 표현력이 다양하다.
- 두 개 이상의 데이터를 상호간에 교환할 때 적절하다.
- 응용프로그램에서 다른 응용프로그램에 데이터를 전달할 때 사용한다 문서 스타일 사용.
- XSLT가 자동으로 문서를 변환하므로 XML 문서를 XSLT로 다루는 응용프로그램의 경우 사

RPC 모델에서 클라이언트는 원격 호출 프로시저에 패러다 임을 한정하지만, 문서 스타일의 모델에서 클라이언트는 XML 문서를 통해서 표현될 수 있는 것에 한정하므로 보다 표현력이 다양 해 진다. 그러나 이러한 자유는 요청과 응답의 의미를 정의하는 것을 필요로 한다.

문서 스타일 방식에서 직렬화는 개발자에게 그 책임이 남게되고 XML 문서의 크기가 간단한 요청-응답 유형보다 훨씬 큰 문서일 경우를 고려할 때 빠르다고 볼수 없다.

5. 웹 서비스 호출

5.1. 웹 서비스 호출 모델
웹 서비스는 의사 소통의 프로토콜로 SOAP을 지원하는데 배타적으로 만들어지지 않았다.

이 것은 실제 작성대상인 클라이언트 코드가 웹 서비스의 인터페이스 정의에 기반을 두고 있다는 것을 의미하지, 실행 시에 기반해 있다 는 것을 의미하지 않는다. 반대로 해석하면 만약 클라이언트가 실행되는 같은 주소에 서비스가 존재 한다면 데이터를 모아서 정렬할 이 유가 없다.

그러나 다른 경우에서 SOAP은 서비스를 접근하는 유일한 방법일 수도 있다. 예로 단넷 플랫폼에서는 의 사 소통 프로토콜로 HTTP 위의 SOAP만을 지원한다. 그러므로 닷넨을 이용한 인트라넷 또는 인터넷에서 구현된 서비스의 장접 을 원한다면 SOAP이 유일한 선택이 된다.

웹 서비스 의사 소통을 위한 프로토콜은 SOAP을 활용하는 정적인 호출 모델, 동적인 호출 모델 이 으며(웹 서비스 호출 모델) SOAP을 사용여부를 포함한 JAX-RPC 방식과 비 SOAP 웹 서비스 방식이 있다.

5.1.1. 정적인 호출 모델
WSDL을 참조하여 클라이언트 프록시/스텁(클라이언트 쪽의 객체)을 직접 미리 생성 하는 방식으로 지금까지 살펴봐왔는 내용들이다.

5.1.2. 동적인 호출 모델
서비스 호출 시점에 WSDL을 참조하여 클라이언트 프록시/스텁을 생성 하는 방식 클라이언트 프로그래머는 서비스를 사용하는 데 SOAP에 대한 자세한 정보를 알 필요가 없다는 것을 의미한다.

5.2. JAX-RPC
/*앞서 JAX-RPC에 대해 자세하게 살표 보았지만 이장에서는 웹 서비스 호출 관점에서 좀더 살펴 본다*/

JAX-RPC의 주 목적을 한 문장으로 표현한다면 WSDL port-type 정보를 자바나 다른 것들로 바꾸는 규칙을 정의한 API라고 할 수 있다.

JAX-RPC는 웹 서비스를 호출하는데 사용되는 프로토콜을 독립적으로 사용하는 방법을 정의 한다.

앞 서 살펴본대로 SOAP을 통해 웹 서비스와 상호작용시 RPC 스타일(방식)과 문서 스타일(방식) 방법이 존재 한다. 호출 스타일 (방식) 맨 위에는 데이터를 SOAP 메시지로 인코딩/*의미 그대로 인코딩이 아닌, XML 묶음을 SOAP, 몸체에 추가 하는 것 을 인코딩이라 한다.*/ 하는 두 개의 주요한 방법이 있다. 하나는 문자 그대로 XML(literal XML)을 사용하는 것이다.

대부분의 경우에, 이 두 개의 조합으로 사용된다. 웹 서비스는 기본 SOAP 인코딩을 가지는 RPC 스타일 호출을 지원하거나 문자 그대로의 XML 인코딩을 가지는 문서 스타일의 호출을 지원한다.

JAX-RPC 스펙은 API의 구현시 두 개의 조합을 지원하라고 요구한다.

JAX- RPC 스펙에서는 두 스타일 사이간 인터페이스가 변하지 않는다고 정의 한다. WSDL  문서에서 정의한 스타일이 RPC스타일 또 는 문서스타일 이건간에 웹 서비스를 위한 RPC스타일로 만들어진 인터페이스, 웹 서비스를 위한 문서스타일로 만들어진 인터페이스 라 고 말할수 없다는 것이다./*물론 스타일의 차이는 실행시에는 엄격하게 다뤄진다*/

5.3. 비 SOAP 웹 서비스
서비스 호출하는 비 SOAP의 예로 RMI/IIOP나 JMS와 같이 다양한 프로토콜에 의해 이루어질수 있다. 지원되는 프로토콜은 WSDL의  엘리먼트에 서술한다.

6. 웹 서비스 공표
6.1. UDDI
6.2. WSIL
6.3. JAXR
7. 비동기적인 웹 서비스
7.1. JAXM(Java API for XML-based Messaging)
7.2. JMS(Java Message Service)

http://blog.naver.com/i1j1jsy/70013031234