|
SOA는 웹과 같은 네트워크에서 가능한 서비스를 사용하는 소프트웨어 어플리케이션을 구축하기 위한 아키텍처 스타일이다. 이것은 재사용이 가능하도록 소프트웨어 컴포넌트 사이에 느슨한 연결(loosely coupled)을 활성화시킨다. SOA의 어플리케이션은 서비스를 기반으로 만들어진다. 서비스는 잘 정의된 비즈니스 기능의 구현이며, 이 서비스들은 그 후 다른 어플리케이션이나 비지니스 프로세스의 클라이언트에 의해 재사용될 수 있다.
SOA 는 새로운 서비스가 시스템의 기존 IT 인프라스트럭처로부터 생성될 수 있도록 기존의 자산을 재사용할 수 있도록 해준다 . 즉, 이에 따라 비즈니스가 기존 애플리케이션을 재사용할 수 있게 하여 기존 투자를 레버리지할 수 있으며, 서로 이질적인 애플리케이션과 기술들 간의 상호운용성을 보장하게 된다. SOA는 이전에는 가능하지 않던 수준의 유용성을 제공한다.
SOA는 그림 1에서 보이는 것처럼 find-bind-execute 패러다임이다. 패러다임에서 서비스 제공자는 공유 레지스트리에 서비스를 등록한다. 특정 표준에 일치하는 서비스를 찾는 소비자들이 이 레지스트리를 사용한다. 그 레지스트리에 소비자가 찾고 있는 서비스가 있다면, 그 소비자에게 계약서 및 그 서비스의 종점 주소를 제공하게 된다.
|
SOA 기반의 어플리케이션은 프리젠테이션, 비지니스 로직, 영속 레이어(persistence layer)를 가지는 멀티 티어(multi-tier) 어플리케이션으로 배포된다. 서비스는 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 애플리케이션은 웹 서비스 클라이언트 자체의 역할을 할 수 있으며, 다른 웹서비스와 어떤 환경에서 구현 되던지에 상관없이 연계될 수 있다.
표1은 The Java WSDP 1.5와J2EE 1.4 platforms에서 제공되어지는 XML(JAX)을 위한 Java APIs이다.
API |
설명 |
---|---|
이 API는 SAX나 DOM 파서를 사용자의 애플리케이션에 활성화시켜 XML 문서를 프로세싱할 수 있게한다. JAXP 1.2는 W3C XML Schema를 지원한다. | |
SOAP+WSDL 웹 서비스 클라이언트와 엔드 포인트를 구축하고 배치하는 API이다. | |
이는 다른 종류의 XML 레지스트르리에 접근하는 Java API이다. 단일 API 세트를 제공하여 다양한 XML 레지스트리(UDDL, ebXML 레지스트리 포함)에 접근할 수 있게한다. 각 레지스트리 정보 모델의 자세한 기본사항에 대해서는 염려하지 않아도 된다. | |
이 API는 사용자가 SOAP 1.1 스팩과 SOAP에 형성되는 메세지, 첨부 노트를 생성, 소비할 수 있게 한다. | |
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를 사용하는지에 대해 보여준다.
|
J2EE 1.4 플랫폼은 서블릿(servlet)과 웹 서비스 같은 EJB를 표현하는 표준 매커니즘을 제공한다. 각 서비스들은 웹서비스의 엔드포인트(또는 웹 서비스 포트)로 여겨지게 되며 WSDL을 이용하여 묘사하거나 UDDI 레지스트리에 기술 되어서 웹서비스 클라이언트들에게 접근이 가능하게 된다.
웹 서비스가 발견되면 클라이언트는 웹서비스에 요청을 한다. 웹 서비스는 클라이언트의 요구와 답을 보내는 것을 처리한다. 정확하게 어떤 일이 벌어지는지 알기를 원하면 J2EE1.4 플랫폼에서 어떻게 자바 클라이언트가 자바 웹 서비스와 통신하는지를 보여주는 그림 2를 참고하라. 한가지 알아야 될 사항은 J2EE 어플리케이션은 다른 서비스 제공자가 어떻게 구현했는지에 대해 전혀 상관없이 웹 서비스를 이용할 수 있다는 것이다. 그러나 , 자바 기반이 아닌 클라이언트와 서비스의 경우 방식이 약간 다르다 . 전에 언급된 봐와 같이 발생하는 일의 요청과 응답 사이에 모든 세부사항은 보이지 않는 곳에서 일어난다 . 사용자는 단순히 자바 메소드 호출 , 자바 데이터 타입과 등과 같은 전형적인 자바 프로그래밍 언어 시맨틱만을 다루면 된다 . 사용자는 XML 으로의 자바 매핑 또는 그 반대 , 또는 SOAP 메시지 구조에 대한 걱정이 필요 없다 . 모든 하위 레벨 작업은 보이지 않는 곳에서 일어나며 , 사용자가 상위 레벨의 이슈에만 신경을 쓸 수 있도록 한다 .
주의: J2EE 1.4와 Java WSDP 1.5는 RPC기반과 문서 지향(document-oriented) 웹 서비스를 모두 지원한다. 즉 서비스가 발견되면, 클라이언트는 그 서비스에 의해 제공된 메소드에 원격 프로시저 호출을 활성화 하거나, 진행될 웹서비스에 XML 문서를 보낼 수 있다.
SOA는 일반적으로 웹 서비스를 통해 실현된다. 웹 서비스 스펙은 비즈니스 문제를 해결하기 위해 최선으로 SOA 를 유틸라이즈하는 데 있어 혼란을 더할지도 모른다 . SOA로의 자연스러운 변화를 위해서는 조직 내의 매니저와 개발자가 다음을 알아야 한다.
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 섹션도 확인해보기 바란다.
기업들은 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은 다음 과 같은 비즈니스 장점을 가진다.
그림 4는 JSR 2008 아키텍처 예제이다.
보이는 대로 JBI 는 플러그인 컴포넌트가 있는 환경을 제공한다 . 플러그인 컴포넌트 사이의 상호작용은 메시지 기반의 서비스 호출에 의한 것이다 . 플러그인 컴포넌트에 의해 생산되고 소비되는 서비스들은 WSDS(버전 2.0) 를 사용해 설계된다 . 표준화된 메시지는 추상 XML 메시지와 메시지 메타데이타(또는 메시지 컨텍스트 데이타) 라는 두가지 부분으로 구성되며, 이는 추가 정보가 플러그인과 시스템 컴포넌트로 진행됨에 따라 특정 메시지와의 조합을 가능하게한다.
JSR 2008 아키텍처를 기반으로 하는 Sun 사의 Shasta 프로젝트는 차세대 통합 솔루션 구축을 목표로 한다 . 이 프로젝트는 Sun 사의 J2EE 애플리케이션 서버에 구현되며 , JMS(Java Message Service), JCA(J2EE Connector Architecture), 페일오버 (failover), 높은 가용성 같은 J2EE 서비스와 레버리지된다 . 이것은 웹 서비스 (e.g. 웹 서비스 알림 , 협력 , 트랜잭션 관리 ) 와 통합 스페이스 상에 나타난 많은 표준의 특징이 될 것이다 . 이 프로젝트는 웹 서비스와 , 이를 이용해 SOA 의 생성을 가능하게 하는 것에 초점을 맞출 것이다. 그림 5 는 완전히 구현되어진 제품에 대해 보여주고 있다.
다른 발달한 분산 환경 (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), 엔터프라이즈 소프트웨어 개발자들에게 변화하는 시장에 유동성을 가진 통합 솔루션을 합작할 수 있는 방법을 제공함으로써 혁명을 일으킬 수 있는 가능성을 가지고 있다 .