비즈니스 서비스와 프로세스 중심의 통합

                                                                                                        김행열 | 한국오라클

 

오늘날 모든 기업은 기존 비즈니스의 운영 및 변화관리, 신규 비즈니스로의 확장, 기업 내/외부의 업무 프로세스의 통합 등 복잡한 문제를 적극적으로 해결하기 위해 비즈니스 프로세스 아키텍처를 구축해야 한 다. 비즈니스 프로세스 아키텍처의 개념을 정리하고, 이를 구현하는 데 필요한 기술들을 살펴본다.

 

비즈니스 프로세스 아키텍처의 필요성

오늘날 고객의 소비패턴은 점진적인 산업발전의 과도한 혜택과 타 문화와 의 교류로 인한 직접적인 영향을 받아 빠르고 편향된 변화를 일으키고 있 다. 이러한 변화는 기업의 경영전략과 영업활동에 흡수되어 서비스의 질적 변화와 경쟁력을 갖춘 신제품 생산으로 표출된다. 이에 대응력이 미흡한 기업이나 체질개선에 실패한 기업들은 시장에서 퇴출되거나M&A의 표적 이 되는 처지에 놓이게 된다.
모든 기업이나 공공기관은 그들의 고객 또는 거래 관련 파트너들을 통 해 끊임없이 서비스 개선에 대한 요구사항에 직면하게 되며, 신속하고 정확 한 업무처리를 지원하기 위해 미래지향적인 IT 서비스 체계를 구축해야 하 는 도전에 응할 수 밖에 없는 상황이다. 그러므로, 최고경영자나 CIO들은 기존 비즈니스의 운영 및 변화관리, 신규 비즈니스로의 확장, 기업 내/외부 의 업무 프로세스의 통합 등 복잡한 이슈에 능동적으로 대처할 수 있는 비즈 니스 프로세스 아키텍처(Business Processes Architecture)를 구축해야 하 며, 이를 직관적으로 지원할 수 있는 IT 인프라스트럭처를 갖추어야 한다.

 

Business Processes Architecture

일반적으로 전사적 아키텍처(EA : Enterprise Architecture)는 조직의 기 능 및 기술을 통합, 상호운용성에 의한 정보체계의 전사적인 통합을 달성 하기 위하여 도입된 개념이다. EA는 전사적 아키텍처 프레임워크를 개발 하기 위해 받아들인 개념적인 상위단계의 출발점으로, 업무구조(Business Architecture), 정보구조(Information Architecture), 정보체계 구조 (Information System Architecture), 데이타 구조(Data Architecture), 산출체계 구조(Delivery System Architecture)와 같이 다섯 개 층으로 구 성되어 있으며, 이 모델은 정보와 정보기술 구조의 통합된 집합을 조직하 고 계획/수립하는 데 사용된다. 다섯 개의 층은 개별적으로 정의되며 상호 연관성을 지닌다.
EA의 계층 중에서 조직의 임무, 비전 및 목표를 지원하기 위하여 조직 이 수행하는 업무의 상위 수준에서 분석된 프로세스에서 파생되는 비즈니 스 활동으로 분해하는 업무구조(Business Architecture)층은 Oracle Information Architecture의 4가지 구성요소 중 비즈니스 프로세스 아키텍처와 유사하게 대응된다<그림 1>.

비즈니스 프로세스 아키텍처는 다음의 3가지 주요 특징을 갖고 있다.

• Service Oriented Applications
애플리케이션은 웹 서비스화하여 보급되도록 설계된다. 이것은 기업 내의 모든 애플리케이션에 해당되는 것은 아니며, 내부 자원에 대한 타당성과 비용 효율 성을 고려하여 제한적이고 추적 가능한 범위에서 고객에게 충분히 IT 서비스가 되도록 설계할 수 있는 서비스 컴포넌트를 제공한다.

• Integrated Business Intelligence
기본적으로 자동화된 비즈니스 프로세스는 함축된 정보를 실시간으로 정확하 게 제공할 수 있다. 또한, 이와 관련된 서비스 기술과 표준을 수용한다. 여기에 의사결정자가 경쟁력이 내재된 기술을 사용하여 새로운 비즈니스 기회를 발굴 할 수 있는 비즈니스 인텔리전스를 프로세스의 연장선상에서 접근할 수 있어야 한다. 이와 같이 비즈니스 인텔리전스가 정형화된 컨텐츠 형태로 프로세스와 긴밀하게 통합될 수 있는 구조를 제공한다.

• Open Integration Services
정형화된 글로벌 비즈니스 프로세스는 대다수 레거시 시스템이나 개발된 애플 리케이션, 써드파티 솔루션, 웹 서비스 등과의 통합 요구에 접하게 된다. 이때 통합에 따른 복잡성이 발생하게 되며, 이를 해결하기 위한 표준 인터페이스와 관리체계가 필요하다. 확장성과 낮은 처리비용, 전문적인 기술이나 오랜 경험 이 필요 없는 표준 등의 요건들을 만족하는 패키지 형태의 개방형 표준 인터페 이스를 제공한다.

이 같은 특징이 반영된 비즈니스 프로세스 아키텍처는 상위 수준에서 애플리케이션 아키텍처와 통합 아키텍처 영역으로 구분하여 다루어진다.

 

애플리케이션 아키텍처

기업이 이전 시스템을 변경하거나 신규 시스템으로 확장을 시도할 때, 시스템간의 호환 기능이나 프로세스, 데 이타 등의 공유가 가능한 시스템이 요구된다. 새로운 시스템을 선택하게 되면, 시스템 내에 정보의 가치를 향 상시킬 수 있으며, 커스터마이징 작업을 줄일 수 있고, 실시간 데이타 활용 이 가능하게 된다. 이와 같이 조직에서 구현되는 애플리케이션은 크게 코어 애플리케이션(Core Application)과 산업 애플리케이션(Horizontal Application), 확장 애플리케이션(Extended Application) 세 가지 영역으로 나눌 수 있다<그림 2>.

코어 애플리케이션은 회계, 인사, 구매 등과 같이 여러 기업에서 공통 으로 사용하는 애플리케이션을 의미한다. 이러한 애플리케이션들은 어느 기업에나 기본적으로 필요하고 기능상 큰 차이가 없는 일반적인 시스템이 다. 반면, 산업 애플리케이션은 특정 수직산업 내에서 소속 기업이 비즈니 스를 전개하기 위해 반드시 필요로 하는 시스템을 의미한다. 예를 들면, 금 융산업에서의 계정계 시스템, 증권업에서의 트레이드 시스템, 소비재/제 조업에서의 프로세스 생산관리시스템, 통신산업에서의 네트워크 관리 시스템 등이 해당 산업에 특화된 애플리 케이션들이다. 이러한 시스템들은 기업의 비즈니스 초기에 직접 자체 개발을 했거나, 전문 패키지 벤더로부터 도입하는 경우가 일반적이다. 마지막으로, 확장 애플리케이션은 고객관계 관리(Customer Relationship Management), 공급망관리(Supply Chain Management), 기업성과관리(Corporate Performance Management) 등이며, 기업의 비즈니스 전략에 따른 가치사슬의 목적을 달성하기 위해 코어 애플리케이션을 포함한 확장된 형태로 구성된다.
코어, 산업, 확장 애플리케이션 모두에 표준화된 프로세스를 구현함으로써, 기업의 업무 효율성과 운영의 유연 성을 극대화할 수 있다. 이와 같이 적응된 시스템은 데이타 중심의 마이그레이션, 서비스 공유, 짧은 시간 이 내에 이미 검증된 애플리케이션의 설치와 환경 구성이 가능한 전략적 구현 방법인 비즈니스 플로우 액셀러레이터(Business Flow Accelerator)를통 해 수요와 공급이 급격히 증가하고 있다<그림 3>.

애플리케이션의 통합과 함께 비즈니스 프로세스 아키텍처에서 중요한 요소가 비즈니스 프로세스이다. 비즈니스 프로세스는 초기에 이기종 시스 템간의 인위적인 업무 통합을 목적으로 도입되었으나, 현재는 프로세스의 모니터링, 자동화, 새로운 비즈니스 프로세스로의 확장 등으로 그 역할이 확대되고 있다. 기업의 프로세스를 좀 더 효과적으로 관리하기 위해서는, 기업 소유의 프로세스들이 여러 애플리케이션에 종속되거나 숨어 있어서 는 안 되며, 숨어 있는 프로세스를 가시화시켜야 한다.

 

통합 아키텍처

통합은 비즈니스 프로세스 아키텍처를 구성하는 또 하나의 특징이다. 오라클의 통합은 서비스 지향 컴퓨팅의 원 칙을 적용하여 총체적 비즈니스 통합 을 빠르게 획득할 수 있는 표준화된 컴포넌트들과 프레임워크를 제공한다 <그림 4>. 통합 아키텍처를 프로세스, 데이타, 이벤트, 애플리케이션 관점 에서 4가지 카테고리로 구분하여 살펴본다. 그리고 모든 통합을 위해 이기 종 환경의 시스템, 플랫폼, 애플리케이션 사이에 표준 인터페이스 역할을 수행하는 어댑터(Adapter)도 함께 알아본다.

• 프로세스 중심의 통합
프로세스 중심의 비즈니스 통합은 처리과정의 투명성과 신속한 결과를 기대할 수 있기 때문에 기업 경쟁력을 높이는 요소 중 하나이다. 프로세스를 올바르게 정의하고 정확하게 수행함으로써 더욱 경쟁력 있는 제품과 서비스를 제공할 수 있으며, 저비용 구조를 유지할 수 있다. 또한, 대 고객 서비스의 질적 향상과 시 장 상황의 변화에 신속하게 대응할 수 있게 된다.

• 기업간 협업 통합
거래 파트너와 협업 비즈니스를 완성하기 위해서는 공유 프로세스의 긴밀한 통 합이 전제되어야 한다. 예를 들어, 각 파트너들의 작성된 프로필을 웹 기반 인터 페이스를 통해 공유하고 자신들의 프로필을 거래 파트너들이 스스로 관리할 수 있게 함으로써 투자수익을 신속하게 회수할 수 있다. 또한 개방적이고 표준적 인 프로세스, 데이타 형식 및 교환 프로토콜을 통해 비즈니스 파트너들 사이에 완벽한 상호운용성이 제공된다. 거래 파트너와의 통신을 위한 프로토콜은 EDI, RosettaNet, UCCnet, HIPAA 등과 같은 주요 산업별 비즈니스 프로토콜에 필요한 메시지를 포장, 확인 및 생성하여 거래 파트너와의 상호작용을 자동화 한다. 또한, 웹 기반 메시징 기능을 통해 모든 B2B 관계를 감시하고 분석할 수 있게 함으로써 권한을 가진 사용자와 거래 파트너들이 거래를 조정하고 메시지 를 검색하는 등 오류를 확인할 수 있다.

• 애플리케이션 통합
동종 애플리케이션이나 이기종 애플리케이션간의 기능 통합은 종종 애플리케 이션 로직 통합이라고도 한다. 서로 다른 두 개 혹은 그 이상의 애플리케이션들 의 로직과 데이타를 통합하는 것이다. 기능 통합은 주로 커스터마이제이션을 통해 개발하는 패키지형 애플리케이션의 인터페이스를 주로 활용한다. J2EE 나 JDBC 또는 EJB와 같은 표준 기반 기술의 사용도 기능 통합의 범주에 포함 된다. 기능 통합은 통합해야 할 애플리케이션들의 데이타 형식과 의미를 해석 할 수 있어야만 가능하다.

• 데이타 통합
분산시스템이나이기종플랫폼들로부터하나의통합된데이타뷰를제공할필요 가있다. 데이타를 통합해야 한다는 의미는 축적된 데이타를 기반으로 정보를 추출하거나데이타웨어하우스를구 축하여분석과예측을통한기업의효율적인경 영을 위해 필요한 중요한 원천이란 인식에서 기인한다. 데이타 통합은 결국 기업 내의데이타에대한공통의이해를돕기위한것이다. 따라서, 대부분의경우데이 타통합은애플리케이션간의특정로직을통합하는것으로나타나게된다.

 

통합을 위한 연결 디딤돌 - 어댑터
어댑터는 거래파트너, 외부 애플리케이션, 이기종 컴퓨팅 기술에 연결성을 제공한다. 오라클은 이와 같은 연결 성을 기준으로 세 종류의 어댑터를 제공한다<그림 5>, <표 1>.

• 일반 어댑터와SDK
레거시 시스템이나 비즈니스 프로세스와 통합할 때, 사용자는 Oracle Application Server Integration Infrastructure에서 제공하는 일반 어댑터의 사용 허가를 획득한 후에 연결할 수 있게 된다. 이것은 표준 J2EE Connector Architecture(JCA) API와 같은 개발자 툴킷을 경유하여 시스템 인터페이스 포장 형식으로 획득할 수 있다.

• 사전 패키지화된 어댑터
Oracle Application Server Adapter는 메인프레임 같은 레거시 시스템이나 SAP, PeopleSoft 및 오라클 애플리케이션 같은 패키지 애플리케이션, 오라클 과 다른 데이타베이스, 다양한 메시징 시스템과 전송 프로토콜에 사전 패키지 화된(pre-packaged) 어댑터를 제공한다.

• B2B 메시징 기능
Oracle Application Server Adapter는역시보안과협업이요구되는B2B 표준 을 준수한다. 그리고 표준 전송 기술의 대역폭 내에서 공급망 시스템에 연결하거 나거래파트너에연결을위한산업별B2B 전용프로토콜에적합한어댑터를제 공한다. 또한, 교환문서의 특화된 형식을 위한B2B 메시징 기능을 제공한다.

 

애플리케이션에서 프로세스 중심으로

기업을 이끄는 경영진들은 기업 활동에 대한 비즈니스 목표, 경영전략, 그리고 기업의 가시성(Visibility) 확보에 맞추어 비즈니스 프로세스를 재조정할 수 있는 유연성을 필요로 한다. 이러한 능력을 향상시킴으로써, 기업은 제품과 서비스의 타임 투 마켓, 고객 대응력, 고객 만족도 등에 관련한 경쟁력을 확보할 수 있다.

 

프로세스 중심으로 전환

과거에는 기업 전산실이나 IT 관련 조직의 개발자들이 메인프레임 시절부 터 클라이언트/서버, 인터넷 컴퓨팅 환경에 이르기까지 현업 실무자들의 업무지원 요청을 충족시키기 위해 애플리케이션을 개발하여 제공하거나 전문 패키지 벤더의 애플리케이션을 도입하여 지원했다. 그러나 최근 글로 벌 경영 환경에서 사베인-옥슬리 법안, 바젤 II 협약, 6시그마 활동 등으로 인해 기업경영의 투명성 제고가 가장 시급한 경영과제로 부상하고 있으며, 이의 영향으로 기업 내부의 사업확장이나 조직변경, 경영변화에 따른 IT 요구사항도 지속적으로 증가하고 있는 상황이다. 따라서 이런 변화 요인에 탄력적으로 대응해야 하는 기업의 요구를 만족할 수 있는 대안으로 프로세 스 중심적인 BPM(Business Process Management)이 부각되고 있다.
BPM은 프로세스간의 비효율성을 제거하여 정보의 흐름이 단절되지 않도록 STP(Straight Through Processing)라는 RTE(Real-Time Enter prise)의 원칙을 실현할 수 있는 도구로 여겨지고 있다. 즉, RTE 환경에서 비즈니스 프로세스가 투명하게 관리되고, 급격히 변화하는 비즈니스 사이 클에 맞춰 유연하고 민첩하게 변화관리를 수행하는 것이 BPM의 가장 핵 심적인 역할이다<그림 6>.

비즈니스 프로세스 정의와 구성요소

Gartner에서는 일반적으로 BPM을‘인적자원 및 애플리케이션 수준의 상호작용을 포함한 명확한 프로세스 관리 , 즉, 프로세스 분석, 정의, 실행, 모니터링 및 관리를 할 수 있는 도구 및 서비스’라고 설명한다. BPM은 프로세스를 중심으로 시스템과 시스템, 인간과 시스템, 인간과 인간의 상호작용과 명시적인 프로세스 관리를 지원하는 도구와 서비스라 할 수 있다.
BPM 구성요소는 프로세스 모델링 도구와 프로세스 실행 엔진, 모니터링 툴과 분석도구 그리고 관리자 도구 등 으로 구성된다.

 

• 프로세스 모델링 도구
기존 및 신규 비즈니스에 대한 프로세스 흐름을 도출하여 모델링하고 프로세스 설계를 수행할 수 있도록 지원해 주는 비주얼 도구를 제공해야 한다.

• 프로세스 실행 엔진
사전에 정의된 프로세스 흐름을 단계별로 정의된 규칙에 따라 수행할 수 있도록 제어해 주고, 각 단계에서 업무수행을 위해 필요로 하는 애플리케이션을 호출하여 프로세스가 실행되도록 전용 엔진을 제공해야 한다.

• 모니터링 툴과 분석도구
프로세스 엔진이 제어하는 정보를 추적하여 진행 중인 각 각의 프로세스들에 대한 진행단계와 인스턴트 상태, 업무담당자, 업무수행 시간 등의 정보를 실시 간으로 모니터링할 수 있도록 해야 한다. 그리고 프로세스에 대한 처리 이력을 추적할 수 있으며, 처리 이력을 중심으로 프로세스에 대한 다양한 방식의 분석 을 수행할 수 있도록 분석 기능도 제공해야 한다.

• 관리자 도구
관리자가 프로세스 흐름의 상태를 모니터링하고, 문제가 발생할 경우 예외처 리 및 복구, 강제종료, 재시작 등의 비상조치를 수행할 수 있는 콘솔을 제공해 야 한다.

서비스를 표현하는 언어, BPEL

 

최근에 비즈니스 애플리케이션은 독립적으로 작동되는 것이 부분적이며, 점점 더 애플리케이션간의 연결성이 요구되고 있다. 영업사원이 고객을 설 득하는 시점부터 비용이 지불되고 주문이 완료되는 시점에 이르기까지 그 배후에서 수많은 이기종 애플리케이션과 서비스가 혼합되어 비즈니스 프 로세스가 생성된다.
오늘날의 이기종 애플리케이션과 작업, 이벤트 및 서비스를 이러한 엔드투엔드(End-to-End)비즈니스 프로세 스로 통합하는 일은 대단히 어려운 과제이다. 이러한 통합 과제를 해결하기 위한 주요 관건은 공통 표준의 제공이다. 트랜잭션 비즈니스 프로세스 에 대해 공통 표준을 설정하기 위해서 는 트랜잭션이 어떻게 그리고 어떤 순서로 일어나는지 살펴볼 필요가 있다.
BPEL(Business Process Execution Language)은 비즈니스 애플리케이션 및 서비스를 위한 공용 언어를 제 공한다. BPEL은 이기종 애플리케이션 및 서비스를 트랜잭션 비즈니스 프로세스로 통합하기 위한 새로운 표준 이다.

 

BPEL 탄생 배경 및 지원
2000년 12월 Microsoft는XLANG를 공개했는데, 이것은 애플리케이션과 XML 웹 서비스를 조정하기 위해 Microsoft BizTalk 서버에서 사용되는 XML 비즈니스 프로세스 언어였다. 3개월 후IBM은 비즈니스 프로세스 정의의 일부로서 웹 서비스를 기술하기 위한 XML 언어인 WSFL(Web Services Flow Language)을 발표하였고, IBM은 SOAP, UDDI, WSDL, XMLP 등 기존의 표준 사양을 이용하여 웹 서비스 기술 프레임워크의 일부가 될 수 있도록WSFL을 설계하였다.
2002년 8월에는 IBM과 Microsoft, BEA가 BPEL4WS(Business Process Execution Language for Web Service)의 공개 초안을 처음으로 발표했는데, 이것은 WSFL과 XLANG 사양을 조합한 것이었다. 이후 2003 년4월에 정보 표준화 기구인 OASIS(Organization for the Advancement of Structured Information Standards)가BPEL 기술위원회의 참여를 촉구 했으며, 2003년 5월에 Sun과 오라클이 BPEL 지원을 발표하였다.
OASIS의 WSBPEL(Web Services Business Process Execution Language) 기술 위원회는 BPEL 향상을 위해 노력하고 있으며, 이 작업에 는 Oracle, BEA Systems, Commerce one, EDS, IBM, Microsoft, NEC, Novell, SAP, Siebel Systems, Sybase, Tibco, Vignette 등이 참여하고 있다.
OASIS가 고려 중인 현재의 BPEL 사양은 1.1이며, 2004년 말에 완료 될 예정이다.

 

BPEL의 특징 및 주요 기능
BPEL은 웹 서비스를 기반으로 하는 비즈니스 프로세스의 작동을 구체적으로 지정한다. BPEL 프로세스는 웹 서 비스 인터페이스만을 이용하여 기능을 내보내고 가져오며, SOAP, UDDI, WSDL, XML 및 XML 스키마를 토대로 구축된 핵심 웹 서비스 아키텍처에 적합하다. 또한, BPEL은 웹 서비스와 XML 및 서로 다른 구성요소 빌 딩블록의 최상위 계층에 위치한다.
BPEL은 구조상 기본 작업과 구조화된 작업을 제공한다. 기본 작업은 서비스와 상호작용하는 개별 단계로 이루어지며, 교환된 데이타를 조작하거나 실행 동안에 발생한 예외를 처리 하게 된다. 구조화된 작업은 BPEL이 수행하는 작업을 구조화함으로써 실행 순서를 정의하며 프로세스 생성을 기술한다. 이러한 구조에는 데이타 흐름, 제어 패턴, 외부 이벤트 처리, 오류 처리, 메시지 조정 등이 있다. BPEL의 주요 기능을 수행하기 위한 대표적인 요소로는 비동기 (Asynchrony), 흐름 조정(Flow Coordination), 예외 관리(Exception Management)를 들 수 있다. 이 모든 것들은 통합 조정의 임무를 맡은 개발자들이 직면하는 문제와 관련된다.

 

• 비동기
비동기는 비동기 상호작용, 메시지 상관관계 및 신뢰성의 문제를 처리한다. 비동기 지원은 통합 시나리오에서 웹 서비스 사용을 위한 필수적인 기능이며, 업무 흐름 과정 동안 또는 보다 효과적인 분산 처리를 위해 지연된 일괄처리 동안 사용자 개입을 허용함으로써 처리 시간을 가장 효율적으로 사용하기 위해 반드시 필요한 사항이다. 비동기는 서 비스 요청과 그에 대한 응답을 분리하여 확장성을 향상시키고 애플리케이션 실행의 병목현상을 방지해 준다. 또 한 일시적으로 서비스가 중단되거나 클라이언트가 오프라인 상태 또는 연결이 끊어진 상태 가 되더라도 중단없는 실행을 보장한다.

• 흐름 조정
흐름 조정에는 병렬적 실행 흐름, 결합 패턴(Join Pattern), 동적 흐름이 있다.
실제 사용되는 애플리케이션에서의 업무 흐름은 동기 및 비동기 서비스가 모두 실행되는 복잡한 상호 작용 패턴이 포함될 수 있다. 흐름 조정에는WSDL 인터페이스, 흐름 작업, XML 변수 및 보정(Compensation) 처리 작업 등이 이에 해당되며, BPEL은WSDL을 이용하여 교환된 메시지, 호출된 작업 및 포트 유형 등을 참조하게 된다. 흐름 작업 은 XLM 변수를 공유하므로 보정 처리기는 처리기가 사용할 수 있는 데이타 스냅샷을 저장해야 한다. 더욱이 보정 처리기는 이미 완료된 단계를 실행취소 할 수 있다.

• 예외 관리
예외관리는동기오류, 비동기 예외 관리 및 비즈니스 트랜잭션 보정 등을 처리 한다. 현재 비즈니스 프로세스 자동화를 위해 예외 관리에 많은 노력이 집중되고 있는 가운데, BPEL은 웹 서비 스의 예외 관리를 단순화시킨다. 예외가 발생하면 웹 서비스와 연결된 로컬 오류 처리기가 호출되며 비동기 서 비스에 예외 발생을 통지하게 된다.

 

완벽하게 소화된 Oracle BPEL Process Manager

Oracle BPEL Process Manager는 기업의 비즈니스 전략을 즉시 수용하고 업무 프로세스의 변화에 능동적으로 대처할 수 있는 프로세스 중심의BPM 제품이다. 이 제품은 모델링, 연결, 배포 및 관리를 위한 확장 가능한 BPEL 기반 조정 서버로서, 독립형 제품으로도 이용할 수 있고 Oracle Application Server 10g Enterprise Edition용 옵션으로도 이용할 수 있다.
Oracle BPEL Process Manager는OASIS의 BPEL 1.1 사양을 완벽히 지원하며, 100% 프로세스 호환성을 보장하는 업계 최초의 네이티브 BPEL 엔진을 탑재한 유일한 제품이다. 더욱이 Oracle APS(Application Platform Suite)인 Oracle Application Server 10g에서 SOAP, WSDL, WS-Coordination, WS-Transaction 및 XML, XPath, XQuery 등을 지원하며, 이들을 통해 각 애플리케이션들 이 유연한 방식으로 서로 찾고 플랫폼 독립적 모델에서 원활하게 상호작용할 수 있다<그림 7>, <그림 8>.

BPM 구축 시 고려사항

BPM 구축 시 고려해야 할 점을 정리하면, 다음과 같다.

• 비즈니스 관점에서 목표 수립
BPM 구축은 프로세스 사고 중심의 비즈니스 프로세스를 개선하는 것이 주된 목표인 만큼 비즈니스 관점에서 기업의 가치를 중심으로 준비하고 기획한다.

• 상세한 프로세스 모델링과 검증
명확하고 정교한 프로세스를 정의하여 비즈니스 모델링을 구체화해야 한다. 전체 프로세스에 매핑될 애플리케 이션과 인적요소, 거래 파트너 업체와의 연결 패턴과 비즈니스 규칙 등을 파악하고 예상되는 예외사항을 수집한다. 그리고 핵심 프로세스를 선정하여 PoC(Proof of Concept)를 통해 검증한 후 전체적으로 확산한다.

• 서비스 지향적인BPM 제품 선택
웹 서비스 전환이 가능한 SOA 기반의 인프라스트럭처를 공급하는 제품을 고려해야 한다. 기업내의 목표와 비즈 니스 전략, 정보시스템 환경 등을 고려하여 기업의 상황에 적합한 제품을 선택해야 한다. 이미 검증된 제품인지, 표준 사양 을 충족하는지, 자신의 기업에 바로 적용할 수 있고 활용할 수 있는 기능이 제공 되는지도 확인할 필요가 있다.

비즈니스 서비스 표준과 기술 참조

그러면, 비즈니스 프로세스 아키텍쳐 구축과 관련해 숙지해야 할 서비스 표준과 기술들을 살펴보기로 하자.

 

프로세스 통합의 연결고리, 서비스지향 아키텍처

모든 기업은 고객 만족도 향상, 경쟁력 강화, 지속적인 대응능력, 비용 절감, 그리고 비즈니스 신속성의 확보 등 을 목적으로 데이타, 애플리케이션 및 프로세스의 통합을 진지하게 고려하고 있다. 비즈니스 자산과 프로세스 를 통합하기 위한 접근 방법이 다양하게 존재하지만, 그 중에서도 서비스 지향 아키텍처(SOA : Service-Oriented Architecture)는 표준 통합 방법론으로 주목받고 있다.
Gartner는SOA를“잘 정의된 인터페이스들을 가진, 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술구조 방식이다.”라고 언급한다. 구체 적으로 SOA는 네트워크상에서 서로 통신하는 일련의 서비스들을 들 수 있다. 그 서비스들은 느슨하게 연결되어 있고(다시 말해 한 애플리케이션이 다른 애플리케이션과 대화하기 위해 그 애플리케이션의 기술적 세부사 항을 알 필요는 없다는 의미), 잘 정의된 플랫폼 독립적 인터페이스들을 보유하고 있으며, 재사용이 가능하다.
업계의 주요 벤더들은 XML, Web Services와 같은 기본적인 표준안에 합의하였으며, 이렇게 합의된 표준은 SOA 구현을 위한 토대로 활용되고 있다. 이미 통합, 애플리케이션, 데이타베이스 업계의 벤더들이 SOA 전략 을 구현하고 있으며, SOA에 기반한 제품을 오라클은 이미 출시하고 있는 상태이다. 통합의 효과 이외에도, SOA는 RFID(Radio Frequency Identification)와 같은 기술을 이용한 복합형 이벤트 기반 애플리케이션의 개발 속도를 향상시켜 주는 혜택을 제공한다.

 

협업 패턴의BPM을위한SOA 지원
협업 패턴의 비즈니스 프로세스 관리(Collaborative Business Process Management)는 순환적인 라이프사이클을 포함하고 있으며, 그 기반으로 서SOA 인프라스트럭처를 요구한다. 깊이 있는 프로그래밍 경험이나 지식 이 없는 기획실무자나 관리자 및 비즈니스 분석가들도 사용하기 쉬운 모델 링 툴을 이용하여 프로세스상의 효과적인 협업 파트너로서 참여할 수 있다. 거래 파트너의 비즈니스 분석가에 의해 생성된 모델을 이용하여 BPEL 기반의 비즈니스 프로세스를 설계하고, 웹 서비스 또는 그 밖의 형태로 SOA 아키텍처내에 배포된 기존 서비스들을 호출하여 협업과 같은 새로운 비즈니스 서비스를 조정한다(Orchestration). 이와 같은 신규 비즈니스 프로세스는 프로세스의 조율과 실행을 관할하는 프로세스 마스터 서버 상에서 구현되 고 비즈니스 프로세스 실행에 필 요한 리소스들을 호출한다. 이때 비즈니스 프로세스를 효과적으로 관리하기 위해서는 비즈니스 룰 엔진을 적용 한 비즈니스 플로우의 최적화, 프로세스의 히스토리 데이타 및 변화관리 등 핵심기능이 필요하게 된다.
현장 실무자나 비즈니스 분석가들은 대시보드 형태의 BAM(Business Activity Monitoring) 툴을 사용하여 생성되는 이벤트들을 추적하고 필요한 상황에는 실시간으로 사전조치 (Pre-emptive Action) 또는 후속조치 (Corrective-Action)를 수행한다. BAM은 프로세스, 이벤트 및 실행에 관련된 모든 메타데이타 정보를 관리하는 비즈니스 액티비티 모니터링 리포지토리를 기반으로 구현된다. 비즈니스 소비자는 모니터링 대상 또는 특정 그룹에 전달할 정보라든지 개별 프로세스 및 이벤트에 관련된 정보 등을 정의하고 관리할 수 있다. 이러한 기능을 이용하여 비즈니스 소비자는 비즈니스 프로세스를 사전 예방적으로 관 찰하고 최적화할 수 있게 된다. 예를 들어, 고객관리부서의 관리자는 고객문의에 관련한 상담시간을 3분 이내에 완료하도록 목표를 설정했고, 관리자는 프로세스를 실시간으로 모니터링하면서 콜센터 직원의 평균 상담시간이 3분을 초과하는 경우가 발생할 경우 통보를 발송하게 한다. 이와 같이 비즈니스 흐름의 단절이나 지연 요소를 제거하여 비즈니스 신속성을 달성할 수 있게 된다.

 

SOA 플랫폼
SOA 플랫폼은 비즈니스 프로세스의 요구사항에 민첩한 대응을 위해 서비스의 설계에서부터 구현, 운영, 보안 및 통합을 위한 다양하고 풍부한 기능들을 제공한다. 서비스는 메인프레임 환경의 레거시 애플리케이션, 커스텀 애플리케이션, 패키지 솔루션 및 데이타베이스 등을 J2EE 코어 기반으로 표준 웹 서비스 기능과 융합되어 구현된다. 이렇게 구현된 서비스들은 JAX-RPC, JSR 109와 EJB 2.1 등 웹 서비스를 위한 J2EE 1.4 표준을 준수 하여 클라이언트의 다양한 접속 장치 및 인터페이스를 통해 사용자에게 직 접 그 결과를 제출하게 된다. 또한 Oracle Application Server 10g 플랫폼 이 보유한 엔터프라이즈 서비스 관련 고급 기능들이 함께 지원되며, J2EE 를 기반으로 한 웹 서비스 표준을 모두 지원한다.

 

서비스 보안 및 관리
SOA에 의존하는 환경에서 비즈니스 프로세스의 실행은 포괄적인 SOA 라 이프사이클의 관리와 보안정책의 수반을 매우 중요한 이슈로 다루게 된다. IT 조직은 서비스에 관한 개방성, 호환성, 표준 준수, 보안 등의 조건을 모 두 만족하는 툴을 필요로 한다. SOA 기반 애플리케이션 서비스의 로깅, 빌 링 및 미러링을 위한 모니터링 툴도 함께 필요로 한다. 이러한 환경에서 가 용성과 비즈니스 연속성은 더욱 강조되는데, 이는 비즈니스 프로세스의 전 체적인 안정성이 가장 취약한 개별 구성요소에 의해 결정되기 때문이다. 그러므로 가장 취약한 구성요소라 하더라도 최소한의 비즈니스 서비스 품 질을 보증할 수 있도록 서비스 컴포넌트들을 체계화해야 하며, 라이프사이 클의 효과적인 순환을 위해서는 플랫폼 상의 서비스 지원 요소들이 효율적 으로 업그레이드 가능하도록 해야 한다.
Oracle Application Server 10g 플랫폼이 지원하는 라이프사이클은 기본적으로 프로비저닝(Provisioning)을 제공한다. 프로비저닝은 서비스 의 생성 및 구성, 복제, 구축, UDDI를 준수한 디렉토리 서비스에 서비스를 등록하는 과정을 포함하고 있다. 또한, 싱글 사인 온(Single Sign on) 환경 을 이용한 표준 기반 보안 프레임워크를 제공한다. 클라이언트 요청의 보 안을 보장하기 위해 Oracle Application Server 10g 컴포넌트가 사용하는 공유 사용자 리파지토리와 인증 관련 공유 리소스를 구성하며, 사용자 정 보와 인증 데이타는 Oracle Application Server 10g의 일부로서 제공되는 표준 LDAP 디렉토리 저장소에 보관된다.

 

SOA 도입에 따른 혜택
SOA는 기존의 IT 자원에 대한 포트폴리오를 활용할 수 있게 해주며, IT 환 경을 통합하는 일을 더 쉽고 신속하게 지원한다. 이것이 SOA가 제시하는 가장 큰 가치 가운데 하나이다. 다시 말해SOA는 이기종 환경에서 아주 잘 동작한다. SOA를 통해 개발자들은 애플리케이션들을 연결하는 새로운 코 드를 작성하기 위해 과도한 시간을 낭비할 필요가 없어지고 대신 개발자들 은 웹서비스 같은 표준 프로토콜을 사용할 수 있다. 그리고 SOA 코드의 상 당 부분은 재사용이 가능하기 때문에 개발 비용도 줄어든다.
SOA 도입을 고려하는 CIO들은 기존 시스템을 제거하고 새로운 시스템으로 대체할 필요가 없어진다. 기존 시스 템의 기능들을 파악한 후 활용함으로써, CIO는 위험을 최소화하고 기존 IT 투자의 가치를 극대화할 수 있다. 예를 들면, SOAP와 WSDL을 구축하면, 내부 프로세스가 웹 서비스 가능 상태로 활성화되며, 고객 및 거래 파트너들과는 회사의 방화벽을 넘 어서 더 쉽게 정보를 공유할 수 있게 된다.
SOA의 또 다른 혜택은, IT 스탭들이 기술 아키텍처가 아니라 비즈니스 아키텍처 측면에서 생각하도록 강요하기 때문에 CIO와 비즈니스 중역들 사이의 대화를 더 매끄럽게 해 줄 수 있다는 것이다. 예를 들어, 만약 개선된 주 문관리 시스템을 구축하고자 한다면, 비즈니스 측의 실무진은 비즈 니스 흐름에 기반하여 그것을 설계하는 최고의 방법과 비즈니스의 요구를 만족시키는 최선의 방안에 대해 IT 설계사들과 이야기할 수 있다. 그리고 그 디자인을 실제로 구현하는 일도 훨씬 수월해진다.
기존의 사일로(Silos) 애플리케이션들을 넘어서 정보를 전달하고 공유 함으로써, 기업은 실시간으로 더 많은 업무성과 데이타를 추출할 수 있고 비즈니스 수준을 높일 수 있다. 기업은 비즈니스에서 일어나고 있는 일에 대한 정보(이전에는 갖지 못했던 정보)를 갖게 된다. SOA가 완벽하게 구 축된다면, 변화하는 비즈니스 요구와 매순간 바뀌는 시장 변화에 대한 기업의 적응력은 크게 향상될 것이다.
마지막으로 통합이 쉬워지고 민첩성이 높아짐으로써 ROI가 높아진다는 부수적 이익도 맛볼 수 있다. 해외 사례 를 예로 들면, 부스카드는 SOA 투자에 대해 200%의 ROI를 달성했다고 말한다. AXA 파이낸셜의 가장 인 기있는 SOA 기반 서비스 가운데 하나는 Get Client로, 이를 통해 고객대 면의 전방처리 애플리케이션은 모두 명령어를 발행할 수 있는데, 그러면 그 명령어는 레거시 시스템들을 모두 훑어본 후 특정 고객의 투자에 대한 완벽한 그림을 창출해 낸다. 다시 말해 개발자들은 모든 종류의 전방처리 시스템들과 작동하기에 충분할 만큼의 일반적인 형태의 서비스를 디자인 할 수 있으며, 이로 인해 개발시간이 단축되고 개발자들은 비즈니스 솔루 션에 더 많은 시간을 쏟을 수 있게 된다. 여기에 IT 실무자들은 새 기술을 SOA에 쉽게 결합할 수 있게 되어 위험과 비용을 줄이는 대신 신규 애플리 케이션의 개발 속도를 높일 수 있다.

 

상호운영성 및 이식성의 필수 - 표준화

SOA를 위한 플랫폼이라면, BPEL4WS, WSDL, XSD, UML 등이 있었다.
이들 중 실행 환경에 관련된 것들은 대부분 웹 서비스와 관련된 표준들이 며, 이를 위한 실행 및 개발 환경을 제공하는 것은 SOA 플랫폼의 기본적인 요구사항이라 할 수 있다. 오히려 이들에 대한 도입 시기와, 전망, 그리고 적절한 표준 프로파일을 설정하는 것이 더 중요하다고 할 수 있다. 따라서 웹 서비스에 관한 표준들과 이들의 향후 로드맵을 간단하게 소개하도록 하 겠다<그림 9>.

웹 서비스 표준 지원
가장 기본적인 웹 서비스 표준은 이미 잘 알려져 있다시피, SOAP(Simple Object Access Protocol), WSDL(Web Services Description Language), UDDI(Universal Discovery, Description, Integration) 등이 있으며, 이들 모두는 이제 사실상 표준으로 자리잡았다. 그러나 이 표준들은 보안, 안정성, 트랜잭션 등에 대한 부문들은 언급 하고 있지 않기에 이들만으로는 복잡한 비즈니스 시나리오를 충족하기에는 부족함이 있다.
W3C(World Wide Web Consortium), WS-I(Web Service Interoperability Organization), OASIS(Organization for the Advancement of Structured Information Standards), JCP(Java Community Process) 등에 서 활동하고 있는 웹 서비스 관련 표준화 워킹그룹 또는 기술위원회에서 작업된 표준 스펙들을 정리한 내용은< 표2>와같다.

다음은 웹 서비스 표준을 사용하여 서비스의 질적 향상(Quality of Services)을 달성할 수 있는 중요한 몇 가지 표준 스펙들과 최근에 다루어 지고 있는 비즈니스 통합에 관련된 표준을 살펴보도록 하자.

• WS-Security
WS-Security 규격은 Microsoft와 IBM이 지금까지 따로 개발해 온 두 개의 서로 다른 보안 규격을 VeriSign의 협력을 얻어 통합한 것이다. Microsoft는 WS-Security라는 이름을 가지는 다른 규격을 작년 10월에 발표했지만, 이 규 격은 타사의 협력없이 독자적으로 개발된 것이다. IBM과 Microsoft, VeriSign의 결과물을 통합한 새로운 WS-Security 규격은 SOAP 메시지의 일부로 사용된다. 이 규격은 기존의W3C의 규격인XML 서명과XML 암호화 를 어떻게 사용하는지를 나타내고 있다

<그림 10>.

• WS-Reliability

SOA 기반 애플리케이션의 도전 중의 하나는 모든 엔드포인트가 언제든지 동 시에 유용하다는 것을 가정할 수 없다는 것이다. 그렇기 때문에B2B 기업간 교 차되는 웹 메시지의 진위에 대한 신뢰성 확보는 매우 중요한 사안이다. 예를 들 어, 주문이나 배송에 관련된 메시지를 상호 교환할 때 물리적으로 메시지를 분 실할 수 있고, 어느 한쪽에서 메시지의 내용에 대한 부인을 할 경우도 발생할 것 이다. 이미 보낸 메시지에 대해 잘 전송이 되었는지 확인이 안된 상황에서 반복 적으로 재발송될 경우도 발생할 것이다. 따라서 이와 같은 상황을 방지하기 위 한 상호 규약과 메커니즘을 개발하여 표준화한 서비스가 WS-Reliability이다.

• WS-Management
WS-Management는 IT 시스템 전반에 걸쳐 관리 정보에 접근하고 교환하는 공통 방법을 제공함으로써 IT 관리와 관련된 비용과 복잡성을 해결할 수 있도 록 개발된 웹 서비스 사양이다. WS-Management는 동적인 비즈니스 요구 및 IT 요구사항에 따라 최적화된 비즈니스 서비스 및 인프라를 제공하도록 지 원한다.
또한, Java 와J2EE 서버기반의애플리케이션개발이증가함에따라개발된애 플리케이션을 관리할 방안으로 관리 표준이 필요하게 되었다. 이러한 애플리케 이션관리에대한요구에따라JMX(Java Management eXtension)가탄생되 었다. JMX는 아키텍처, 패턴, API를 제공하는 표준 관리 인터페이스로서 다양 한 프로토콜, 즉, SOAP, HTTP, RMI, CORBA, SNMP, AMI 와JMS를지원 하며, Oracle Application Server와 같은 다양한 매니저 플랫폼에서 사용된다.

• Java Business Integration
JSR(Java Specification Request) 208은 비즈니스 프로세스 엔진, 그리고 워크플로우나 문서 전송 엔진을 자바 플래폼으로 전송하는 것과 같은 부가 컴포넌트의 인터페이스와 아키텍처 를 정의한다. 사용자는 JBI(Java Business Integration)를 이용해 레거시 시스템이나 웹 서비스 같은 백엔드 시스템을 활 용할수있다.
다양한 시스템을 통합하는 능력을 이용해 SOA 구현을 가능하게 하는 기술이 다. SOA 인프라 구조에 SOA 통합 구성품을 결합함으로써, JSR-208은 ESB(Enterprise Service Bus) 구현을 위한 중요한 빌딩블럭을 제공한다.
JBI의 초기 제안 리뷰(early draft review)는 Jboss, 아파치 그룹, 그리고 Iona를 새롭게 지원하는 것이 특징이다. 이를 지지하는 벤더들은 Oracle, Novell, SAP 등이다. IBM은 다른 통합노력에 초점을 맞출 것이라며 참가하지 않았고, BEA는 요청에 답하지 않았었다.
JBI의 개발은 18개월 동안 이루어지고 있으며, 공공의 리뷰를 받은 후 최종 채 택은 내년쯤으로 예상된다<그림 11>.

 

통합을 위한 요소 기술, Java와XML

XML이 제공하는 데이타 통합 기능과 Java API 기능이 조합하여 웹 서비 스 개발을 원활하게 지원한다. 비즈니스 통합에 필수적인 요소기술들을 살 펴본다.

 

Java APIs for XML
웹 서비스 개발에 있어서 직면하는 난관은 메시징 교환, 분산 트랜잭션 처 리, 보안, 세션관리 및 커넥션 풀(Connection Pool)과 같은 인프라스트럭 처 수준의 서비스 기능을 개발하는 것이다. 웹 서비스는 수많은 사용자의 동시 다발적 접속을 지원해야 하기 때문에 상대적으로 애플리케이션이 높 은 확장성을 가져야 한다는 기대를 충족시키기는 쉽지 않다. 이의 대안으 로 제시된 J2EE 프레임워크는 다수의 벤더들이 공급하는 호환성 제품을 통해 이미 검증된 기술로 인정받고 있으며, 웹 서비스를 운용함에 있어서 J2EE가 최상의 프레임워크임을 의심할 여지는 없다.
특히, 내부 조직간의 데이타 공유나 외부 거래기업과의 데이타 교환 및 공유 등 데이타 통합을 위해 기업들이 고민해 온 메시지 형식이나 거래 문서의 표준으로 XML이 정착된 상태이다. 더욱이 메시징 교환 표준으로 사용되는 XML 문서 포맷을 웹 서비스상에서도 적용되도록 JAX(Java APIs for XML) 표준 인터페이스가 제공되어 개발자들이 보다 쉽고 원활하 게 웹 서비스를 구현할 수 있게 되었다.
W3C나 OASIS와 같은 표준화 기구들은 인터넷상의 상호운영성을 위 한 표준 인터페이스 방식을 규정하고, 이 표준을 따르는 기업들의 프로세 스 엔드투엔드에서 상호작용이 교류될 수 있도록 확장된 개발자 API를 제 공한다. 결국 호환성 아래 구현된 결과물은 표준 기능을 준수하게 되며, 동 시에 개발자들도 벤더 종속적인 특수성에 맞춰 구현해야 하는 제약조건에 서 벗어날 수 있다<표 3>.

• Java API for XML-based RPC
JAX-RPC(Java API for XML-based RPC)는 메시징 프로토콜로서SOAP를 사용하여 원격지의 거래 상대방 프로세스를 원격 프로시저 호출을 통해 호출하 고 그 결과를 수신하게 된다. 이를 위해 XML 기반 웹 서비스를 개발하는 모든 개발자에게 표준 Java APIs를 제공하여 이미 작성된 코드와 이식된 플랫폼에 상관없이 웹 서비스에 상호 호환성을 유지할 수 있도록 한다.
JAX-RPC는 이전의 Java IDL, RMI(Remote Method Invocation) 방식과 같이 모두 프로시저 호출을 송수신하기 위한 마샬링(Marshalling)과 언마샬링 (Un-marshalling) 인수의 API를가진다.

• Java API for XML Processing
JAXP(Java API for XML Processing)는 Java로 작성된 애플리케이션을 이용하여XML 형식의 데이타를 쉽게 처리해 준다. 이 패키지는 변환을 수행하는 XSLT(XML Stylesheet Language Transformation) 변환기에 접속할 수 있는 기능을 제공한다. 서브패키지는 SAX-(Simple API for XML Parsing)와 DOM-(Document Object Model), 지정된 스트림 API를갖게되며, 이를 통 해 DOM 트리나 SAX 이벤트로부터 직접 변환이 가능하다. 이는 파서 표준 SAX와DOM의 기능을 더욱 강화시켜서 사용자들이 데이타를 이벤트 스트림 으로 파싱할 지 혹은 객체 형태로 파싱할 지에 대한 선택이 가능하다. JAXP 1.1버전은 javax.xml.transform 패키지를 이용해 XSLT를 지원한다. 또한 XSLT 표준을 지원하기 때문에 사용자들은 데이타를 표현하는 방법을 마 음대로 컨트롤할 수 있을 뿐만 아니라 데이타를 다른XML 문서나HTML과같 은 다른 문서 형태로 변환시킬 수도 있다. JAXP는 네임스페이스를 지원하기 때문에 네이밍 충돌이 발생하는 경우에도 DTD를 이용한 작업을 진행할 수 있 게한다.

• Java Architecture for XML Binding
JAXB(Java Architecture for XML Binding)는XML 문서와 Java 객체 간에 양방향 매핑을 생성하기 위한 신속하고 편리한 방법을 제공한다. DTD가 주어 지면 JAXB 컴파일러는 XML스키마에 의해 XML 문서를 파싱하는 코드를 포 함한 Java 클래스 집합을 생성한다. 개발자는 생성된 클래스를 이용해XML 문 서를 표현하는 Java 객체 트리를 구축할 수 있고, 트리의 컨텐츠를 다룰 수 있 으며 트리에서XML 문서를 재생성할 수 있다.
JAXB 애플리케이션을 사용할 때 요구되는 것은 JAXB의 현재 버전을 위한 DTD용 스키마가 전부다. 사용자는 스스로 DTD를 작성하거나 JAXR을 통해 접근할수있는표준DTD 리포지토리와 같은 곳에서DTD를구할수있다.

• Java API for XML Messaging
JAXM(Java API for XML Messaging)은XML 문서를J2EE 기반 플랫폼에 서 인터넷으로 전송하기 위한 표준 전송방식을 제공한다. 이것은 첨부 사양을 포함한 SOAP 1.1이나 ebXML 같이 잘 정의된 메시징 프로토콜과 함께 동작 할수있도록확장될수있다.
비즈니스는 전형적으로 메시징 프로바이더 서비스를 이용하지만 실제로 메시 징 프로바이더 서비스는 메시지를 전송하고 라우팅하는 데 요구되는 작업을 수 행한다. 메시징 프로바이더를 이용하면 모든 JAXM 메시지는 이를 통해 전송 되므로, 사업자가 메시지를 전송하면 메시지는 우선 발송자의 메시징 프로바이더로 전송된 다음 다시 수신자의 메시징 프로바이더로 전송된 후에 최종적으로 수신자에게 전달된다. 메시지가 최종 목적지로 보내지기 전에 중간 수신지를 경유하도록 할 수도 있으며, 메시지의 신원 확인이나 저장, 전달 여부 등 모든 세세한 사항까지 신경을 써야만 한다. 게다가 제대로 전달되지 않은 메시지는 반드시 재전송해야 한다.
JAXM 메시지는 두 개의 파트로 구성되는데, 하나는 반드시 필요한 SOAP 파 트이고 또 하나는 선택적인 첨부 파트이다. SOAP 파트는SOAPHeader 객체 와 SOAPBody 객체가 포함된 SOAPEnvelop 객체로 구성되어 있다.
SOAPBody 객체는 전송될 메시지의 내용과 같은XML 문서를 갖는다.
이러한 메시징 프로바이더의 장점은 바로JAXM 기술을 사용하는 고객은 프로 바이더가 뒤에서 무엇을 하는지 전혀 알 필요가 없다는 점이다. 또한, 단지 JAXM 메소드만 호출하면 메시징 인프라와 연결된 메시징 프로바이더가 모든 일을 처리하게 된다.

• Java API for XML Registries
JAXR(Java API for XML Registries)은 인터넷을 통해 표준 비즈니스 레지스 트리에 접근할 수 있는 방법을 제공한다. 표준 비즈니스 레지스트리는 사업체 목록과 각 업체가 제공하는 제품 및 서비스 목록 등이 포함되어 있기 때문에 전 자 카탈로그라고 일컬어지곤 한다. 레지스트리는 점차 웹 서비스의 가장 중요 한 컴포넌트로 인식되고 있다. 이것은 가벼운 결합 형태만으로도 비즈니스 간 협력 관계를 동적으로 맺어주기 때문이다.
이것은 Java를 이용해 애플리케이션을 작성하는 개발자들이 ebXML과 같은 개방형 표준이나UDDI와 같은 산업 컨소시엄이 주도하는 사양에 기반을 둔 비 즈니스 레지스트리를 사용하는 데에 필요한 유일한 방법을 제공한다. 각 기업 들은 레지스트리를 이용해 자사 사업체를 등록하거나 자사가 하고자 하는 비즈 니스를 이미 수행하고 있는 다른 기업을 찾아볼 수 있으며, 기업 간에 공유해야 할 자료를 전송하거나 다른 기업에서 보내온 자료들을 검색할 수도 있다.
따라서 기업이 Java를 이용해 표준 비즈니스 레지스트리에 접근할 수 있도록 해주는JAXR의 요구는 더욱 더 증가하고 있는 추세다.
표준화 그룹들은 특정한 종류의 XML 문서를 위한 DTD를 개발해 왔다. 예를 들어두회사가자사의산업표준구매요구양식을위해DTD를 이용하기로 합의할 수도 있다. 왜냐하면 DTD는 표준 비즈니스 레지스트리 내에 저장되므로 양사는JAXR을 이용하여 레지스트리에 접근할 수 있기 때문이다.

이상 위에서 설명된 요소 기술을 제공하는 Oracle Application Platform Suite는 J2EE 프레임워크 기반의 인프라스트럭처로서 공급업체 의 소프트웨어가 어떤 유형이든지 관계없이 애플리케이션간의 웹 서비스 호환성을 증진시키는 Java API for XML을 지원한다. 또한, Java API for XML 개발 툴킷을 제공하여 Oracle JDeveloper와 같은 Java 개발도구를 통해 쉽게 애플리케이션을 개발할 수 있도록 하며, BPLE Process Manager, Database Server 등과 연결된 응용 서비스도 단순하고 유연하 게 지원한다. 

 

자료원 :  한국오라클