Java SE의 웹 서비스, Part 1 : 도구 개요

Java Standard Edition (SE) 6에는 웹 서비스 지원이 포함되었습니다. 이 게시물은 웹 서비스가 무엇인지 설명하고 이에 대한 Java SE의 지원을 개괄하여 Java SE의 웹 서비스에 대한 4 부작 시리즈를 시작합니다. 향후 게시물에서는이 지원을 사용하여 SOAP 기반 및 RESTful 기반 웹 서비스를 구축하고 고급 웹 서비스 주제를 다룰 것입니다.

Java XML 및 JSON

이 시리즈에서는 여러분이 XML과 JSON을 이해하고 있다고 가정합니다. 그렇지 않다면 이 게시물의 끝에서 광고되는 내 Java XML 및 JSON 책 을 확인 하는 것이 좋습니다.

웹 서비스 란 무엇입니까?

Wikipedia는 웹 서비스 를 "네트워크를 통해 상호 운용 가능한 시스템 간 상호 작용을 지원하도록 설계된 소프트웨어 시스템"으로 정의 합니다. 이 용어의 부분을 먼저 정의하면 더 자세한 정의를 얻을 수 있습니다.

  • 웹 : 리소스 가 PDF 기반 문서, 비디오 스트림, 웹 페이지 또는 응용 프로그램과 같은 URI (Uniform Resource Identifier) ​​이름의 데이터 소스 인 상호 연결된 거대한 리소스 네트워크입니다 . 이러한 리소스는 HTTP (HyperText Transfer Protocol) 또는 SMTP (Simple Mail Transfer Protocol)와 같은 표준 인터넷 프로토콜을 사용하여 액세스 할 수 있습니다.
  • 서비스 : 메시지 교환 패턴 (MEP)에 따라 메시지 교환을 통해 클라이언트에 리소스를 노출하는 서버 기반 애플리케이션 또는 소프트웨어 구성 요소입니다. 요청-응답 MEP가 일반적입니다.

이러한 정의가 주어지면 웹 서비스 는 메시지 교환을 통해 웹 기반 리소스를 클라이언트에 노출하는 서버 기반 응용 프로그램 / 소프트웨어 구성 요소입니다. 이러한 메시지는 XML (Extensible Markup Language) 또는 JSON (JavaScript Object Notation)에 따라 형식이 지정 될 수 있습니다. 또한 이러한 메시지는 웹 서비스 기능을 호출하고 호출 결과를 수신하는 것으로 생각할 수 있습니다. 그림 1은이 메시지 교환을 보여줍니다.

그림 1. 클라이언트는 웹 서비스와 메시지를 교환하여 리소스에 액세스합니다.

기업 및 웹 서비스

기업은 웹 서비스를 사용합니다. 기존의 미들웨어 문제 (예 : 확보 및 유지 비용이 비싸고, 인터넷을 통해 백엔드 소프트웨어 및 클라이언트 응용 프로그램과 통신 할 수없고 유연성이 떨어짐)를 유지 관리 가능성에 따라 웹, 그리고 유연함. 또한 대기업이 레거시 소프트웨어에 대한 상당한 투자를 보존 할 수 있도록 지원합니다.

웹 서비스는 단순 또는 복합으로 분류 할 수 있습니다. 단순 웹 서비스는 다른 웹 서비스와 상호 작용하지 않습니다 (예 : 지정된 시간대의 현재 시간을 반환하는 단일 함수가있는 독립형 서버 기반 응용 프로그램). 반대로 복잡한 웹 서비스는 종종 다른 웹 서비스와 상호 작용합니다. 예를 들어, 일반화 된 소셜 네트워크 웹 서비스는 Twitter 및 Facebook 웹 서비스와 상호 작용하여 특정 개인에 대한 모든 Twitter 및 모든 Facebook 정보를 얻고 클라이언트에게 반환 할 수 있습니다. 복잡한 웹 서비스는 여러 웹 서비스의 데이터를 매시 (결합) 하기 때문에 매시업 이라고도 합니다.

서비스 지향 아키텍처

웹 서비스는 네트워크를 통한 통신 프로토콜을 통해 다양한 소프트웨어 구성 요소에 서비스가 제공되는 소프트웨어 디자인 스타일 인 SOA (Service-Oriented Architecture) 의 구현입니다 . SOA를 일련의 설계 원칙 또는 비즈니스 로직을 다양한 방식으로 결합하여 진화하는 비즈니스 요구 사항을 충족 할 수있는 재사용 가능한 서비스로 구현하기위한 프레임 워크라고 생각하십시오.

SOAP 기반 웹 서비스

SOAP 기반의 웹 서비스를 기반으로 널리 사용되는 웹 서비스 카테고리입니다 SOAP , 정의하는 XML 언어 메시지를 네트워크 연결의 양쪽 끝에서 이해 될 수있다 (추상 함수 호출 또는 응답을). SOAP 메시지의 교환을 오퍼레이션 이라고하며 이는 함수 호출 및 응답에 해당하며 그림 2에 설명되어 있습니다.

그림 2. 웹 서비스 작업에는 입력 및 출력 메시지가 포함됩니다.

관련 작업은 종종 개념적으로 Java 인터페이스와 유사한 인터페이스 로 그룹화됩니다 . 바인딩은 인터페이스가 와이어를 통해 명령, 오류 코드 및 기타 항목을 전달하는 메시징 프로토콜 (특히 SOAP)에 바인딩 방법에 대한 구체적인 세부 사항을 제공합니다. 바인딩 및 네트워크 주소 (IP 주소 및 포트) URI는 끝점 이라고하며 끝점 모음은 웹 서비스 입니다. 그림 3은이 아키텍처를 보여줍니다.

그림 3. 엔드 포인트를 통해 작업 인터페이스에 액세스 할 수 있습니다.

SOAP는 웹 서비스 작업을 정의하기위한 XML 언어 인 WSDL (Wiz-Dull이라고 발음) 과 함께 자주 사용 됩니다. WSDL 문서는 웹 서비스와 상호 작용에 대한 모든 세부 사항을 제공하는 SOAP 기반의 웹 서비스와 클라이언트 간의 공식적인 계약이다. 이 문서에서는 메시지를 작업으로 그룹화하고 작업을 인터페이스로 그룹화 할 수 있습니다. 또한 각 인터페이스에 대한 바인딩과 끝점 주소를 정의 할 수도 있습니다.

WSDL 문서를 지원할뿐만 아니라 SOAP 기반 웹 서비스에는 다음과 같은 속성이 있습니다.

  • 보안 및 트랜잭션과 같은 복잡한 비 기능적 요구 사항을 처리하는 능력 : 이러한 요구 사항은 다양한 사양을 통해 제공됩니다. 이러한 사양 간의 상호 운용성을 촉진하기 위해 WS-I (Web Services Interoperability Organization) (산업 컨소시엄)가 구성되었습니다. WS-I는 프로파일 세트를 설정했습니다. 여기서 프로파일 은 상호 운용 가능한 웹 서비스를 개발하기 위해 스펙을 사용할 수있는 방법을 권장하는 일련의 구현 및 상호 운용성 지침과 함께 특정 개정 수준에서 명명 된 웹 서비스 스펙 세트입니다. 예를 들어 첫 번째 프로필 인 WS-I Basic Profile 1.0 은 다음과 같은 비 독점 웹 서비스 사양 집합으로 구성됩니다.
  • SOAP 1.1
  • WSDL 1.1
  • UDDI (Universal Description Discovery and Integration) 2.0
  • XML 1.0 (제 2 판)
  • XML 스키마 1 부 : 구조
  • XML 스키마 2 부 : 데이터 유형
  • RFC2246 : 전송 계층 보안 프로토콜 버전 1.0
  • RFC2459 : 인터넷 X.509 공개 키 인프라 인증서 및 CRL 프로필
  • RFC2616 : 하이퍼 텍스트 전송 프로토콜 1.1
  • RFC2818 : TLS를 통한 HTTP
  • RFC2965 : HTTP 상태 관리 메커니즘
  • 보안 소켓 레이어 프로토콜 버전 3.0

추가 프로필 예에는 WS-I 기본 보안 프로필 및 단순 SOAP 바인딩 프로필이 포함됩니다. 이러한 프로필 및 기타 프로필에 대한 자세한 내용은 WS-I 웹 사이트를 방문하십시오. Java SE는 WS-I 기본 프로필을 지원합니다.

  • 웹 서비스와 비동기식으로 상호 작용하는 기능 : 웹 서비스 클라이언트는 비 차단, 비동기 방식으로 웹 서비스와 상호 작용할 수 있어야합니다. 웹 서비스 작업의 클라이언트 측 비동기 호출 지원은 Java SE에서 제공됩니다.

SOAP 기반 웹 서비스는 서비스 요청자 (클라이언트), 서비스 공급자 및 서비스 브로커를 포함하는 환경에서 실행됩니다. 이 환경은 그림 4에 나와 있습니다.

그림 4. SOAP 기반 웹 서비스에는 서비스 요청자, 서비스 공급자 및 서비스 브로커 (예 : UDDI)가 포함됩니다.

일반적으로 클라이언트 애플리케이션 (예 : 웹 브라우저) 또는 다른 웹 서비스 인 서비스 요청자는 먼저 어떤 방식 으로든 서비스 제공자를 찾습니다. 예를 들어 서비스 요청자는 서비스 제공자의 위치를 ​​식별하는 다른 WSDL 문서로 응답하는 서비스 브로커에 WSDL 문서를 보낼 수 있습니다. 그런 다음 서비스 요청자는 SOAP 메시지를 통해 서비스 공급자와 통신합니다.

다른 사람이 찾아서 사용할 수 있도록 서비스 공급자를 게시해야합니다. 2000 년 8 월, UDDI (Universal Description, Discovery, and Integration) 로 알려진 개방형 산업 이니셔티브 가 시작되어 기업이 서비스 목록을 게시하고 서로를 발견하고 서비스 또는 소프트웨어 응용 프로그램이 인터넷을 통해 상호 작용하는 방식을 정의 할 수 있습니다. 그러나이 플랫폼 독립적 인 XML 기반 레지스트리는 널리 채택되지 않았으며 현재 사용되지도 않습니다. 많은 개발자들은 UDDI가 지나치게 복잡하고 기능이 부족하다는 것을 알게되었고 웹 사이트에 정보를 게시하는 것과 같은 대안을 선택했습니다. 예를 들어 Google은 //code.google.com/more/에서 공개 웹 서비스 (예 : Google지도)를 사용할 수 있도록 한 적이 있습니다.

서비스 요청자와 서비스 공급자간에 흐르는 SOAP 메시지는 종종 보이지 않으며 웹 서비스 프로토콜 스택의 SOAP 라이브러리간에 요청 및 응답으로 전달됩니다. 그러나이 시리즈의 뒷부분에서 확인할 수 있듯이 이러한 메시지에 직접 액세스 할 수 있습니다.

빅 웹 서비스

SOAP 기반 웹 서비스는 앞서 언급 한 WS-I 프로파일과 같은 많은 사양을 기반으로하기 때문에 빅 웹 서비스 라고도 합니다.

RESTful 웹 서비스

SOAP 기반 웹 서비스는 HTTP, SMTP, FTP 및 BEEP (Blocks Extensible Exchange Protocol)와 같은 프로토콜을 통해 제공 될 수 있습니다. HTTP를 통해 SOAP 메시지를 전달하는 것은 특별한 종류의 RESTful 웹 서비스로 볼 수 있습니다.

RESTful 웹 서비스를 기반으로 널리 사용되는 웹 서비스 카테고리입니다 Representational State Transfer (REST)와 분산을위한 소프트웨어 아키텍처 스타일 하이퍼 미디어 시스템 (이미지, 텍스트 및 기타 리소스가 네트워크를 주변에 위치하며, 하이퍼 링크를 통해 액세스되는 시스템) . 웹 서비스 컨텍스트에서 관심있는 하이퍼 미디어 시스템은 World Wide Web입니다.

REST 역사

Roy Fielding (HTTP 사양 버전 1.0 및 1.1의 주요 저자이자 Apache Software Foundation의 공동 창립자)은 2000 년에 박사 학위 논문에서 REST를 도입하고 정의했습니다. Fielding은 REST를 웹의 아키텍처 스타일로 구상했습니다. 웹이 계속 관심사가 된 지 오래되었습니다. REST는 증가하는 SOAP 기반 웹 서비스의 복잡성에 대한 해결책으로 널리 알려져 있습니다.

REST의 핵심 부분은 URI 식별 가능한 리소스입니다. REST는 MIME (Multipurpose Internet Mail Extensions) 유형 (예 : text / xml)으로 리소스를 식별합니다. 또한 리소스에는 표현으로 캡처 된 상태가 있습니다. 클라이언트가 RESTful 웹 서비스에서 리소스를 요청하면 서비스는 리소스의 MIME 형식 표현을 클라이언트에 보냅니다.

클라이언트는 HTTP의 POST, GET, PUT 및 DELETE 동사를 사용하여 리소스 표현을 검색하고 리소스를 조작합니다. REST는 이러한 동사를 다음과 같이 데이터베이스 CRUD (Create, Read, Update, and Delete) 작업에 매핑합니다.

  • POST : 요청 데이터를 기반으로 새 리소스를 만듭니다.
  • GET : 부작용을 일으키지 않고 기존 리소스를 읽습니다 (리소스를 수정하지 마십시오).
  • PUT : 요청 데이터로 기존 리소스를 업데이트합니다.
  • DELETE : 기존 리소스를 삭제합니다.

각 동사 뒤에는 리소스를 식별하는 URI가옵니다. (이 엄청나게 간단한 접근 방식은 인코딩 된 메시지를 단일 리소스로 전송하는 SOAP의 접근 방식과 근본적으로 호환되지 않습니다.) URI는과 같은 컬렉션 //javajeff.ca/library또는 컬렉션의 요소를 참조 할 수 있습니다. //javajeff.ca/library/9781484219157이러한 URI는 단지 그림 일뿐입니다.

POST 및 PUT 요청의 경우 XML 기반 리소스 데이터가 요청 본문으로 전달됩니다. 예를 들어, POST //javajeff.ca/library HTTP/ 1.1( HTTP/ 1.1요청자의 HTTP 버전을 설명하는) POST의 XML 데이터를 //javajeff.ca/library컬렉션 리소스 에 삽입하라는 요청으로 해석 할 수 있습니다.

GET 및 DELETE 요청의 경우 데이터는 일반적으로 쿼리 문자열로 전달됩니다. 여기서 쿼리 문자열?문자로 시작하는 URI 부분입니다 . 예를 들어 리소스의 GET //javajeff.ca/library모든 도서에 대한 식별자 목록을 반환 할 수 있는 위치 는 쿼리 문자열이 ISBN (International Standard Book Number)을 식별하는 도서 리소스의 표현을 반환 할 수 있습니다.libraryGET //javajeff.ca/library?isbn=97814842191579781484219157

HTTP-CRUD 매핑에 대해 자세히 알아보기

HTTP 동사와 해당 CRUD 대응 물 간의 매핑에 대한 전체 설명은 Wikipedia의 Representational State Transfer 항목에있는 "RESTful 웹 서비스 HTTP 메서드"표를 확인하십시오.

REST는 또한 MIME 유형 (리소스 표현이 검색 될 때)과 함께 404 (요청 된 리소스를 찾을 수 없음) 및 200 (리소스 작업 성공)과 같은 HTTP의 표준 응답 코드에 의존합니다.

RESTful 대 대형 웹 서비스

SOAP 또는 REST를 사용하여 웹 서비스를 개발할 것인지 궁금하다면 RESTful 웹 서비스 대 "대형"웹 서비스 : 올바른 아키텍처 결정을 내리십시오.

Java SE의 웹 서비스 지원

Java SE 6 이전에는 Java 기반 웹 서비스가 Java Enterprise Edition (EE) SDK로 독점적으로 개발되었습니다. 프로덕션 관점에서 웹 서비스를 개발하는 데 Java EE가 선호되지만 Java EE 기반 서버는 매우 높은 수준의 확장 성, 보안 인프라, 모니터링 기능 등을 제공하기 때문에 웹 서비스를 Java EE에 반복적으로 배포합니다. 컨테이너는 종종 시간이 많이 걸리고 개발 속도가 느려졌습니다. Java SE 6은 API, 주석, 도구 및 경량 HTTP 서버 (웹 서비스를 간단한 웹 서버에 배포하고이 환경에서 테스트하기위한)를 핵심에 추가하여 웹 서비스 개발을 단순화하고 가속화했습니다.

아피스

Java SE는 웹 서비스를 지원하는 여러 API를 제공합니다. Java XML 및 JSON 에서 논의한 다양한 JAXP API (SAX, DOM, StAX 등)와 함께 Java SE는 JAX-WS, JAXB 및 SAAJ API를 제공합니다.