[펌]SOA와 웹서비스: 엔터프라이즈 애플리케이션 통합(EAI; Enterprise Application Integration)에 이르는 길

[플밍지기]

많은 기업들이 오랜 기간 동안 시스템 리소스에 많은 투자를 해오고 있다. 이런 기업들은 EIS(enterprise information systems) 레거시 (legacy) 에 엄청난 데이터를 저장하고 있기 때문에 기존 시스템을 폐기하고 새것으로 바꾼다는 것은 현실적으로 힘든 일이다 . EIS를 발전시키고 강화하는 것이 비용 대비 효과적인 방법일 것이다. SOA(Service Oriented Architecture)가 이런 해결책을 제공한다.

SOA는 새로운 개념이 아니다. Sun사는 1990년대 후반 지니(Jini)를 설명하면서 “SOA는 네트워크상의 서비스들을 동적으로 검색하고 사용하기 위한 환경”이라고 정의했다. 웹서비스는 Jini 테크놀로지의 서비스 개념을 수용하고 그 것을 XML 이나 WSDL(Web Services Description Language), SOAP(Simple Object Access Protocol), UDDI(Universal Description, Discovery, and Integration) 같은 기술을 이용하는 웹에 전달되는 서비스로써 구현 하였다. SOA 는 오늘날 복잡하고 다양한 컴퓨팅 환경에서 최고의 통합과 아키텍처 프레임워크로 알려지고 있다 . 이전의 시도들에서는 상호운용이 가능한 (interoperable) 솔루션이 가능하지 않아 개인 API에 의지하였고, 그룹들간에는 높은 수준의 공동작업이 필요했다. SOA는 소프트웨어를 서비스 개념으로 이용하여 조직이 좀 더 효율적인 비즈니스를 진행하고 변화하는 니즈와 경쟁에 적응할 수 있게 조직에 유선형(streamline)의 프로세스를 돕는다. eBay의 경우 온라인 경매 사이트의 웹 서비스 API를 공개했다. 이는 개발자들이 eBay 플랫폼을 이용해서 돈을 벌 수 있게 한다. 새로운 API를 통해서 개발자는 온라인 경매 사이트에 연결되는 고객 애플리케이션을 구축하고 이 애플리케이션으로 판매할 아이템을 제출할 수 있도록 한다. 이런 애플리케이션은 일반적으로 판매자를 겨냥한 것이므로 구매자가 물건에 입찰하기 위해서는 여전히 eBay.com을 방문해야하지만 이러한 전략은 eBay 고객을 증가시킬 것이다.

SOA와 웹 서비스는 서로 다르지만 웹 서비스는 SOA를 구현하기 위해 선호되는 표준 기반 방법이다. 이번 아티클에서는 SOA의 개요와 이를 실현하기 위한 웹 서비스의 역할에 대해 다룬다. 목차는 다음과 같다.

• 서비스로써의 소프트웨어 개요
• SOA 튜토리얼
• 웹 서비스를 구축하기 위한 Sun사의 플랫폼 개요
• 상호운용이 가능한 웹 서비스 디자인을 위한 가이드라
• SOA로 변경하는 데 드는 어려운 점
• 자바 비즈니스 통합(JSR 208)에 대한 개요
• 기업 어플리케이션 통합을 위한 웹 서비스 논의

SOA(Service-Oriented Architecture)

SOA는 웹과 같은 네트워크에서 가능한 서비스를 사용하는 소프트웨어 어플리케이션을 구축하기 위한 아키텍처 스타일이다. 이것은 재사용이 가능하도록 소프트웨어 컴포넌트 사이에 느슨한 연결(loosely coupled)을 활성화시킨다. SOA의 어플리케이션은 서비스를 기반으로 만들어진다. 서비스는 잘 정의된 비즈니스 기능의 구현이며, 이 서비스들은 그 후 다른 어플리케이션이나 비지니스 프로세스의 클라이언트에 의해 재사용될 수 있다.

SOA 는 새로운 서비스가 시스템의 기존 IT 인프라스트럭처로부터 생성될 수 있도록 기존의 자산을 재사용할 수 있도록 해준다 . 즉, 이에 따라 비즈니스가 기존 애플리케이션을 재사용할 수 있게 하여 기존 투자를 레버리지할 수 있으며, 서로 이질적인 애플리케이션과 기술들 간의 상호운용성을 보장하게 된다. SOA는 이전에는 가능하지 않던 수준의 유용성을 제공한다.

• 서비스는 잘 정의된 독립적 구현 인터페이스와 함께하는 소프트웨어 컴포넌트이다. SOA의 중요한 면은 구현(how)과 서비스 인터페이스(what)의 분리이다. 요청사항의 처리 방법에 대해 상관하지 않는 클라이언트들이 이런 서비스들을 사용한다 .
• 서비스는 자체 포함(미리 결정된 태스크를 수행)하며 느슨한 연결(loosely coupled)을 한다.
• 서비스는 동적으로 다뤄질 수 있다.
• 복합 서비스는 다른 서비스의 집합으로부터 구축될 수 있다.

SOA는 그림 1에서 보이는 것처럼 find-bind-execute 패러다임이다. 패러다임에서 서비스 제공자는 공유 레지스트리에 서비스를 등록한다. 특정 표준에 일치하는 서비스를 찾는 소비자들이 이 레지스트리를 사용한다. 그 레지스트리에 소비자가 찾고 있는 서비스가 있다면, 그 소비자에게 계약서 및 그 서비스의 종점 주소를 제공하게 된다.

그림 1: SOA의 Find-Bind-Execute(검색-바인딩-실행) 패러다임

SOA 기반의 어플리케이션은 프리젠테이션, 비지니스 로직, 영속 레이어(persistence layer)를 가지는 멀티 티어(multi-tier) 어플리케이션으로 배포된다. 서비스는 SOA 어플리케이션의 블록으로 구축된다. 어떤 기능이 서비스에 구축되던 간에 올바른 레벨의 추상화로 서비스 인터페이스가 정의 되는 것이 제일 중요하다. 서비스는 정확하게 다듬어진 기능을 제공해야 한다.

웹 서비스를 이용한 SOA 실현

웹 서비스는 네트워크 상에서 상호운용 가능한 기계와 기계 사이의 상호 작용을 지원하기 위해 설계된 소프트웨어 시스템이다. 이런 상호운용성(interoperability)은 WSDL, SOAP, UDDI같은 XML 기반의 공개 표준을 통해서 얻어진다. 이러한 표준들은 웹 서비스를 정의, 발표, 사용하기 위한 일반적인 접근을 제공한다.

Sun사의 Java WSDP 1.5(Java Web Services Developer Pack 1.5)와 J2EE 1.4는 SOA를 구현하는데 있어 최상의 기술을 제공한다. J2EE 1.4 플랫폼은 사용자의 어플리케이션 상의 IT 인프라스트럭처에 웹서비스를 구축하고 배치할 수 있게 해준다. 그리고 빠르게 웹서비스를 구축, 테스트, 배치할 수 있는 툴과 자바 또는 자바 기반이 아닌 플랫폼에서 운용되는 클라이언트와 웹 서비스간의 상호 운영을 할 수 있는 툴을 제공한다. 또한, 비즈니스에서 기존 J2EE 애플리케이션을 웹 서비스로 드러내는 것을 가능하게 한다. Servlets과 EJB는 자바 기반이거나 자바 기반이 아닌 웹 서비스 클라이언트로 액세스될 수 있는 웹서비스로 드러낼 수 있을 것이다. J2EE 애플리케이션은 웹 서비스 클라이언트 자체의 역할을 할 수 있으며, 다른 웹서비스와 어떤 환경에서 구현 되던지에 상관없이 연계될 수 있다.

웹 서비스 API

표1은 The Java WSDP 1.5와J2EE 1.4 platforms에서 제공되어지는 XML(JAX)을 위한 Java APIs이다.

표 1: J2EE 1.4에서 제공하는 JAX(Java API for XML)

API	설명
Java API for XML Processing (JAXP) 1.2	이 API는 SAX나 DOM 파서를 사용자의 애플리케이션에 활성화시켜 XML 문서를 프로세싱할 수 있게한다. JAXP 1.2는 W3C XML Schema를 지원한다.
Java API for XML-based RPC (JAX-RPC) 1.1	SOAP+WSDL 웹 서비스 클라이언트와 엔드 포인트를 구축하고 배치하는 API이다.
Java APIs for XML Registries (JAXR) 1.0.4	이는 다른 종류의 XML 레지스트르리에 접근하는 Java API이다. 단일 API 세트를 제공하여 다양한 XML 레지스트리(UDDL, ebXML 레지스트리 포함)에 접근할 수 있게한다. 각 레지스트리 정보 모델의 자세한 기본사항에 대해서는 염려하지 않아도 된다.
SOAP with Attachments API for Java (SAAJ) 1.2	이 API는 사용자가 SOAP 1.1 스팩과 SOAP에 형성되는 메세지, 첨부 노트를 생성, 소비할 수 있게 한다.
JSR 109: Web services for J2EE 1.0	JSR 109는 JAX-RPC 프로그래밍 모델을 레버리지함으로써 웹서비스 클라이언트와 엔드포인트에 대한 배치 요구사항을 정의한다. 덧붙여, XML 스키마를 이용하여 표준 배치 기술어를 정의하며, 그러므로써 웹서비스를 여러 범위의 툴을 통해 애플리케이션 서버에 배치하는 데 있어 동일 표준 방식을 제공하게된다.

 

참고: JAX-RPC 1.1와 SAAJ 1.2는 WS-I(Web Services Interoperability)와 WSI-BP(Web Services Interoperability Basic Profile)을 포함한다. 일반적으로 http://www.ws-i.org에서 제공하는 어떻게 정보 상호 운용이 가능한 웹 서비스를 개발하는지에 대한 가이드라인을 참고하여 개발한다.

표 1에서 기술된 API 를 이용해 XML 과 웹 서비스의 하위 레벨보다는 상위 레벨의 프로그래밍에 초점을 맞출 수 있다 . XML 과 웹서비스 표준에 대해서 많이 알지 못해도 Java WSDP 1.5 와 J2EE 1.4 웹 서비스를 사용하여 개발을 시작할 수 있다는 말이다 . 사용자는 단지 메소드 요청과 데이터 타입 같은 자바 시맨틱만 다루면 된다 . 복잡한 작업은 알아서 처리된다 . 이에 대해서는 다음 섹션에서 다루겠다 .

그림 2는 실제 SOA와 웹 서비스를 배포하고, 다루고 사용하는 규칙에서 어떻게 JAXR과 JAX-RPC API를 사용하는지에 대해 보여준다.

그림 2: Web services Publish-Discover-Invoke model

J2EE 1.4의 웹 서비스 엔드포인트(Endpoint)

J2EE 1.4 플랫폼은 서블릿(servlet)과 웹 서비스 같은 EJB를 표현하는 표준 매커니즘을 제공한다. 각 서비스들은 웹서비스의 엔드포인트(또는 웹 서비스 포트)로 여겨지게 되며 WSDL을 이용하여 묘사하거나 UDDI 레지스트리에 기술 되어서 웹서비스 클라이언트들에게 접근이 가능하게 된다.

웹 서비스가 발견되면 클라이언트는 웹서비스에 요청을 한다. 웹 서비스는 클라이언트의 요구와 답을 보내는 것을 처리한다. 정확하게 어떤 일이 벌어지는지 알기를 원하면 J2EE1.4 플랫폼에서 어떻게 자바 클라이언트가 자바 웹 서비스와 통신하는지를 보여주는 그림 2를 참고하라. 한가지 알아야 될 사항은 J2EE 어플리케이션은 다른 서비스 제공자가 어떻게 구현했는지에 대해 전혀 상관없이 웹 서비스를 이용할 수 있다는 것이다. 그러나 , 자바 기반이 아닌 클라이언트와 서비스의 경우 방식이 약간 다르다 . 전에 언급된 봐와 같이 발생하는 일의 요청과 응답 사이에 모든 세부사항은 보이지 않는 곳에서 일어난다 . 사용자는 단순히 자바 메소드 호출 , 자바 데이터 타입과 등과 같은 전형적인 자바 프로그래밍 언어 시맨틱만을 다루면 된다 . 사용자는 XML 으로의 자바 매핑 또는 그 반대 , 또는 SOAP 메시지 구조에 대한 걱정이 필요 없다 . 모든 하위 레벨 작업은 보이지 않는 곳에서 일어나며 , 사용자가 상위 레벨의 이슈에만 신경을 쓸 수 있도록 한다 .

그림 3: J2EE 웹서비스를 호출하는 자바 클라이언트 (클릭시 이미지 확대)

주의: J2EE 1.4와 Java WSDP 1.5는 RPC기반과 문서 지향(document-oriented) 웹 서비스를 모두 지원한다. 즉 서비스가 발견되면, 클라이언트는 그 서비스에 의해 제공된 메소드에 원격 프로시저 호출을 활성화 하거나, 진행될 웹서비스에 XML 문서를 보낼 수 있다.

SOA로의 변화

SOA는 일반적으로 웹 서비스를 통해 실현된다. 웹 서비스 스펙은 비즈니스 문제를 해결하기 위해 최선으로 SOA 를 유틸라이즈하는 데 있어 혼란을 더할지도 모른다 . SOA로의 자연스러운 변화를 위해서는 조직 내의 매니저와 개발자가 다음을 알아야 한다.

• SOA는 수년간에 걸친 아키텍처 스타일이다. 웹 서비스는 SOA를 실현하는 좋은 방법이다.
• SOA는 디플로이 소프트웨어 그 이상이다. 조직은 디자인 기술과 개발 방법론 그리고 파트너/고객/공급자 관계를 분석할 필요가 있다.
• SOA로 좀 더 많이 변경되어야하고, 이를 위해서는 기존 IT 최대 투자 동안 서버기반의 어플리케이션을 어떻게 구성할지 방향을 바꾸는 것이 요구된다.

Sun사에서는 고객들이 SOA로 변경하는 데 겪는 어려움을 알고 있으며, 이에 따라 다년간의 경험으로 SOA 기회평가 서비스를 개발하여 각 고객의 요구에 맞출 수 있는 기술 솔루션을 제공하고있다. Sun사의 SOA 기회평가표는 고객에게 고객의 조직이 SOA로 변환할 준비가 되어있는지 분석하고 이 서비스를 보완하는 일련의 베스트 프랙티스를 제공하며, 설계의 베스트 프랙티스와 재사용 가능한 디자인 패턴을 이용해 그들의 서비스 기반 애플리케이션을 구축하는 데 있어 비지니스 관련 기회를 감정하도록한다. Sun의SOA 서비스에 대한 추가 정보는 Assessing your SOA Readiness (pdf)를 참고하기 바란다.

덧붙여, Sun의 자바 블루프린트(Java BluePrints)는 개발자를 위해 가이드라인, 패턴, 어플리케이션 예제를 제공한다. 자바 블루프린트의 Designing Web Services with J2EE 1.4에서는 J2EE 1.4을 사용해 엔터프라이즈 레벨의 웹 서비스를 디자인하고 통합하는 베스트 프랙티스에 대한 검증된 가이드를 제시한다. 가이드라인, 패턴 실제 예제 아키텍처를 재공하며 개발자들은 빠르게 학습하여 견고하고 확장가능하며 이식 가능한 솔루션들을 구축할 수 있을 것이다.

또한 Java BluePrints Solutions Catalog의 SOA with web services 섹션도 확인해보기 바란다.

Java 비지니스 통합

기업들은 ERP(enterprise resource planning), SCM(supply chain management), CRM(customer relationship management) 등 그들의 비즈니스를 구현하는데 필요한 대형 규모의 패키지 어플리케이션 소프트웨어에 많은 투자를 해오고 있다. IT 매니저들은 새로운 기능을 보유하면서도 기존 IT 투자와 레버리지할 수 있는 차세대 소프트웨어를 제공하도록 요구되어지고 있다. 이를 위한 솔루션은 통합 기술이지만, 이용 가능한 통합 기술 솔루션은 사유 (proprietary) 이며 , 서로간에 상호 운용되지 않는다. 웹 서비스와 SOA의 출현은 낮은 통합 비용과 큰 유연성의 가능성을 제공한다.

JSR 208 JBI(Java Business Integration)은 통합 서버 소프트웨어를 구축하는 데 SOA 를 가능하게 하는 시스템 소프트웨어를 위한 플러그인 기술을 설명하는 표준 스펙이다. JBI 는 SOA 를 채택하여 컴포넌트 간의 분리를 최대화하고 표준 메세징에 기반한 잘 정의된 상호운용 시맨틱을 생성한다. JSR 208 은 서비스 엔진과 바인딩을 플러그인 할 수 있는 SPI(service provider interface) 뿐만 아니라 서로간 의사 소통하는 데 사용하는 표준화된 메시지 서비스를 설명한다. JSR 208 은 엔진이나 툴 자체에 대해 정의하지 않고 있다는 것을 알아두어야 한다. JSR208은 다음 과 같은 비즈니스 장점을 가진다.

• 그 자체가 강한 유연성 , 확장성을 가진 SOA 이다 .
• 서비스 엔진은 JSR 208 관련 시스템에 의해 구현되는 SPI 가 정의한 어떤 언어로도 구현 할 수 있다 .
• 새 엔진은 , 이를 표준 SPI 에 플러그인하고 시스템의 나머지 부분과 상호작용하는 데 사용할 메시지를 정의함으로써 컨테이너에 추가될 수 있다 .
• 컴포넌트 중 하나를 전문화한 ISVs는 산업기반의 표준 솔루션의 특별한 목적의 엔진으로 플러그 할 수 있다.
• 오픈 인터페이스를 통해 이런 엔진들의 구현에 대해 자유롭고 열려있는 경쟁이 가능하다 . 이는 고객들이 가장 적절한 솔루션을 선택하는 데 자유롭고 , 통합 코드를 각 구현 간에 변경할 수 있다는 뜻이다 .

그림 4는 JSR 2008 아키텍처 예제이다.

그림 4: JSR 208 기반의 아키텍처 예제 (클릭시 이미지 확대)

보이는 대로 JBI 는 플러그인 컴포넌트가 있는 환경을 제공한다 . 플러그인 컴포넌트 사이의 상호작용은 메시지 기반의 서비스 호출에 의한 것이다 . 플러그인 컴포넌트에 의해 생산되고 소비되는 서비스들은 WSDS(버전 2.0) 를 사용해 설계된다 . 표준화된 메시지는 추상 XML 메시지와 메시지 메타데이타(또는 메시지 컨텍스트 데이타) 라는 두가지 부분으로 구성되며, 이는 추가 정보가 플러그인과 시스템 컴포넌트로 진행됨에 따라 특정 메시지와의 조합을 가능하게한다.

Shasta 프로젝트

JSR 2008 아키텍처를 기반으로 하는 Sun 사의 Shasta 프로젝트는 차세대 통합 솔루션 구축을 목표로 한다 . 이 프로젝트는 Sun 사의 J2EE 애플리케이션 서버에 구현되며 , JMS(Java Message Service), JCA(J2EE Connector Architecture), 페일오버 (failover), 높은 가용성 같은 J2EE 서비스와 레버리지된다 . 이것은 웹 서비스 (e.g. 웹 서비스 알림 , 협력 , 트랜잭션 관리 ) 와 통합 스페이스 상에 나타난 많은 표준의 특징이 될 것이다 . 이 프로젝트는 웹 서비스와 , 이를 이용해 SOA 의 생성을 가능하게 하는 것에 초점을 맞출 것이다. 그림 5 는 완전히 구현되어진 제품에 대해 보여주고 있다.

그림 5: JSR 208 기반의 아키텍처 예제 (클릭시 이미지 확대)

기업 어플리케이션 통합을 위한 웹 서비스와 J2EE 1.4

다른 발달한 분산 환경 (e.g. CORBA, RMI) 으로부터 얻어지는 지식을 기반해 구축되는 웹서비스는 어플리케이션 간의 커뮤니케이션과 상호운용에 대한 표준적인 접근을 제공하며 , 언어나 플랫폼에 상관없이 애플리케이션의 기능이 웹에서 동작할 수 있는 방법을 제공한다 . 즉 , 애플리케이션 개발자들이 EIS 의 이질성을 숙달하고 관리할 수 있게 한다 .

웹서비스는 미들 티어(middle-tier)와 백엔드(back-end) 서비스에 접근하여 이들을 다른 애플리케이션과 통합하는 표준 방법을 제공함으로써 개발자들이 기존 정보 자산을 재사용할 수 있게 한다.

웹서비스가 기존 백엔드 서버로의 게이트웨이를 나타냄에 따라 , 백엔드 통합에 대한 강력한 지원이 요구된다 . 여기가 J2EE 플랫폼의 활약이 나타나는 곳이다 . J2EE 플랫폼은 레거시 정보 시스템에 접근하는데 산업 표준 API(e.g. J2EE 커넥터 아키텍처 , JDBC API, JMS(Java Message Service) 등 ) 를 제공한다. J2EE 1.4(웹 서비스 지원)은 레거시 EIS 를 통합하여 그 기능을 상호 운용 웹 서비스로 나타내서 , 레거시 데이터가 이질적인 플랫폼 환경에서 가능하도록하는 훌륭한 매커니즘을 제공한다 .

결론

웹 서비스와 SOA 의 출현은 통합 (integration) 비용을 낮추고 융통성을 늘릴 수 있다는 잠재력을 제공한다 . SOA 의 핵심은 서비스 인터페이스 (what) 와 실제 구현 (how) 이 분리 된다는 것이다 . . 이런 서비스는 요청사항을 실행시키는 방법에 상관 없는 클라이언트에 의해 사용되어진다. 웹서비스는 , 인터넷을 통한 B2B 관계를 자동화하는 기반시설과 툴을 약속함에 따라 웹 발달의 다음 단계가 되고 있다 .

JSR 208( 자바 비즈니스 통합 ) 은 플랫폼 벤더 , 시스템 통합 사업자 (integrator), 엔터프라이즈 소프트웨어 개발자들에게 변화하는 시장에 유동성을 가진 통합 솔루션을 합작할 수 있는 방법을 제공함으로써 혁명을 일으킬 수 있는 가능성을 가지고 있다 .