HTTP를 통해 액세스되는 웹 서비스는 종종 서비스 지향 아키텍처(SOA)의 핵심에 있습니다. Service-Oriented Architecture and Java ME에 설명된 대로, HTTP를 일반 데이터 전송으로 사용하기 때문에 Java ME 애플리케이션은 웹 서비스를 사용하여 SOA 기반 분산 애플리케이션을 생성할 수 있습니다. 하지만 HTTP 자체는 웹 서비스를 수행하지 않으며 웹의 모든 사이트가 웹 서비스의 제공업체가 됩니다. 웹 서비스는 실제로 전송으로 HTTP를 사용하도록 동의한 서비스 공급업체와 해당 고객 사이의 실질적인 계약입니다. 그러나 HTTP를 전송으로 지정하는 것만으로는 부족합니다. 계약 당사자들은 데이터를 교환하기 위해 HTTP를 사용하는 방식에 대해 동의해야 합니다.
웹 서비스에 액세스하기 위한 가장 유명한 프로토콜은 SOAP(Simple Object Access Protocol)입니다. Microsoft에서 초기에 보급한 SOAP는 결국 XML 기반 데이터 교환의 W3C(World Wide Web Consortium) 표준이 되었습니다. (서비스 기반 클라이언트 애플리케이션의 다른 주요 기술인 AJAX의 XMLHttpRequest 개체도 Microsoft에서 보급했다는 점을 생각하면 아이러니합니다. 이것도 W3C에서 채택되었습니다.) SOAP 데이터 전송은 XML을 사용하므로 특정 프로그래밍 언어 또는 운영 체제에 매이지 않습니다. SOAP 기반 웹 서비스를 모두에게 개방하여 누구든지 액세스할 수 있게 합니다.
그러나 SOAP의 XML 의존성은 단점이 되기도 합니다. J2ME Web Services APIs(WSA)는 SOAP 1.1 표준의 하위 집합 및 XML을 구문 분석하기 위한 간단한 API를 지원하지만 WSA 지원은 널리 퍼져 있습니다. (WSA에 대한 자세한 내용은 Understanding the Web Services Subset API for Java ME를 참조하십시오.) 실용적인 Java ME 개발자들은 대체 접근 방법을 자주 모색해야 하는 이유를 이해하고 있습니다. SOAP가 Java ME 플랫폼 모두에서 지원되었지만 SOAP 사용에 포함된 부수적인 오버헤드 때문에 일부 개발자들은 다른 솔루션을 찾습니다. (SOAP가 필요하고 WSA를 사용할 수 없을 경우 kSOAP 2 오픈 소스 SOAP 라이브러리를 고려할 수 있습니다.)
"SOAP 없음" 접근 방법에서 우선 고려해야 할 사항은 다른 프로토콜을 통해 필요한 서비스에 액세스할 수 있는지 여부입니다. SOAP만 지원될 경우 SOAP를 사용하지 않으려면 장치 대신 서버 기반 프록시를 사용해야 합니다. (SOAP 이외의 서비스가 지원되는 경우에도 프록시를 사용할 수 있습니다. 아래 참조)
이상적인 웹 서비스로 간단한 REST 형식 인터페이스를 사용하는 서비스를 제안합니다. (REST는 Representational State Transfer를 의미합니다.) 기본 RESET 개념에 대한 요약은 Building Web Services the REST Way를 참조하십시오.) 즉, 서비스에는 쿼리 매개변수(GET 요청) 또는 요청 본문(POST 요청)을 사용할 때 전달된 입력 데이터로 HTTP GET 및 POST 메소드를 사용하는 것이 포함됩니다. 예를 들어, Amazon의 ECS(E-Commerce Service)는 Java ME 플랫폼에서 사용하기 쉬운 SOAP 인터페이스뿐만 아니라 REST 형식 인터페이스를 제공합니다. REST 형식 인터페이스를 사용할 수 없으면 프록시가 필요합니다.
일부 플랫폼에서는 HTTP 기반 통신을 지원하지 않으므로 간혹 이러한 인터페이스에서 암호화가 문제가 되기도 합니다. 데이터 보안이 걱정되면 오픈 소스 암호 기법 프로젝트인 Bouncy Castle Crytographic APIs의 코드를 사용하여 Data Encryption for J2ME Profiles에 설명된 대로 통신을 암호화하십시오. 그러나 이러한 솔루션에는 대부분 프록시 사용이 수반됩니다.
REST 형식 인터페이스는 데이터 교환에 다양한 형식을 사용할 수 있습니다. 이미 언급한 대로 대부분의 요청 데이터는 URL(쿼리 매개변수 사용)의 일부로, 또는 요청 본문에서 전달될 수 있습니다. 응답은 HTTP 상태 코드 및/또는 응답 본문을 통해 돌아옵니다. 데이터 교환을 위한 완벽한 단일 형식은 없습니다. 형식은 데이터 요구사항에 따라 다릅니다. XML은 SOAP 인터페이스가 반환하는 것보다 훨씬 간단하지만 일반 REST 형식 인터페이스는 일반적으로 데이터를 XML로 반환합니다. 이것이 바로 Amazon ECS에서 수행하는 방식입니다. 그러면 XML 구문 분석기는 데이터를 적절한 Java 데이터 구조로 매핑합니다. 사용 가능한 내장 구문 분석기가 없으면 kXML 2와 같이 메모리 효율성이 뛰어난 구문 분석기를 사용하는 것이 좋습니다.
종단간 Java가 사용되는 경우(웹 서비스 끝점 자체가 Java로 기록되는 경우) 종종 일련화된 데이터 구조가 클라이언트와 서버 간에 정보를 전달하는 가장 유효한 방법이 됩니다. 이 메소드는 Object Serialization in CLDC-based Profiles에 설명된 간단하고 사용자 정의된 일련화 기술을 사용합니다. 데이터 구조는 전송된 데이터 양을 최소화하기 위해 전송을 위한 압축된 바이너리 형식으로 전환됩니다. 일련화 및 일련화 해제는 상대적으로 빠르며 인터페이스를 정의할 때 조금만 주의하면 효율적으로 수행할 수 있습니다. (보너스로 이러한 데이터 구조는 종종 레코드 저장소나 다른 영구 저장소에 변경되지 않은 상태로 직접 저장될 수 있습니다.) 이 접근 방법도 결점은 있습니다. 특히 새로운 데이터 형식이나 업그레이드된 데이터 형식에서 결점이 있을 수 있습니다. 클라이언트 애플리케이션이 새로운 데이터 형식에서 점진적으로 실패하는지(또는 실패하지 않는지) 확인하려면 주의 깊게 코딩해야 합니다.
물론 서버 기반 프록시 접근 방법이 유일한 방법인 경우도 있습니다. 프록시는 빠른 요청-응답 주기를 위해 고유의 서비스 인터페이스를 정의할 수 있습니다. 프록시는 수많은 하위 레벨 작동을 단일 상위 레벨 트랜잭션으로 결합시켜 멀티플렉서/디멀티플렉서 역할도 수행합니다. 하지만 프록시도 유지관리해야 할 시스템과 다른 서버에 실패 지점을 추가하는 단점이 있습니다. 클라이언트 애플리케이션이 넓게 배포된 경우 프록시 확장성도 고려해야 합니다.
웹 서비스가 서비스 지향 아키텍처에 포함되는 방식에 대해서는 옳거나 그른 대답이 없습니다. Java ME 개발자는 SOAP 기반 클라이언트 구현이 대상 장치에서 사용하기에 효율적인지 여부를 주의 깊게 고려해야 합니다. 초고속 인터넷이 연결된 CDC 기반 셋톱 상자를 대상으로 하는 애플리케이션은 CLDC 기반 휴대폰의 애플리케이션보다 훨씬 많은 작업을 수행할 수 있으므로 웹 서비스 사용은 적절하게 조절해야 합니다.
저자 정보
Eric Giguere는 Java ME에 대해 광범위하게 저술해왔습니다. 자세한 팁과 정보를 보려면 Java ME 블로그를 읽어 보십시오. synclastic.com에서 Eric에 대한 자세한 내용을 볼 수 있습니다. Eric은 Sybase iAnywhere의 소프트웨어 개발자입니다..