오늘날과 같이 비즈니스 요구사항이 숨가쁘게 변화하는 환경에서, 기업은 비즈니스 프로세스를 보다 신속하고 효율적으로 설계하고, 구축하고 변경할 수 있기를 원합니다.
BPEL(Business Process Execution Language)은 프로세스 통합을 위한 검증된 업계 표준이며, Oracle BPEL Process Manager는 이 표준 구현의 선두에 서 있는 솔루션입니다.
| BPEL과 J2EE: 두 언어의 장점의 조합 | 조회 24 | 추천 | 스크랩 |
| java | 2004-11-26 20:16:26 |    |
| BPEL과 J2EE: 두 언어의 장점의 조합 by Mike Lehmann J2EE 1.4가 발표되면서, J2EE 개발자와 BPEL 개발자가 함께 협력하여 다수의 서비스를 하나의 비즈니스 프로세스로 통합하는 것이 가능하게 되었습니다.
BPEL(Business Process Execution Language)는 느슨한 형태로 연계된 여러 개의 웹 서비스들을 조합하여 롱-러닝 워크플로우(long running workflow)를 생성하고 이를 하나의 비즈니스 애플리케이션으로 통합하는 것을 주된 목적으로 합니다. J2EE 및 .NET 진영의 주요 벤더들이 적극적으로 BPEL을 지원하고 있는 것도, BPEL의 성숙도가 과거 플로우 랭귀지들의 그것을 훨씬 능가할 뿐만 아니라 XML 및 웹 서비스를 통한 언어 중립성의 제공에 초점을 맞추고 있기 때문입니다.
반면 J2EE는 퍼시스턴스(persistence), 엔터프라이즈 시스템 통합, 비즈니스 로직, 사용자 인터페이스 등을 위해 각각 개별적인 프로그래밍 접근법을 취하고, 이를 활용하여 객체 지향형 비즈니스 애플리케이션을 구축하는 것을 그 목적으로 합니다. J2EE의 대중성은 엔터프라이즈 애플리케이션을 구축하는 데 필요한 다양한 아키텍처와 스타일에 쉽게 적응할 수 있는 호환성에 기인한 바가 큽니다.
BPEL이 상위 레벨의 오브젝트를 대상으로 하고 데이타 조작 및 프로세스 플로우를 위한 기본적인 언어 요소들만을 가지고 있는데 반해, J2EE는 자바를 기반으로 하며 가장 낮은 수준의 오브젝트의 생성/조작을 가능하게 하는 요소들을 모두 포함하고 있습니다. 그렇다면 이 두 프로그래밍 접근법이 만나는 지점은 어디일까요? BPEL 개발자가 J2EE 애플리케이션을 어떻게 이용할 수 있을까요? 또 J2EE 개발자가 BPEL 프로세스를 어떻게 이용할 수 있을까요?
웹 서비스
J2EE는 Java Connector Architecture(JCA), Java Messaging Service, Message Driven Beans 등 통합을 목적으로 개발된 다양한 프로그래밍 API를 보유하고 있습니다. JCA에 기반한 통합은 이제 성숙된 시장을 형성하고 있으며 Oracle, Siebel, SAP, PeopleSoft와 같은 벤더들이 ERP, CRM 등의 시스템을 위한 어댑터를 제공하고 있습니다.
그러던 중 약 6개월 전 J2EE 1.4가 발표되었고, 웹 서비스는 이제 J2EE의 통합 프로그래밍 API의 한 부분으로서 자리잡게 되었습니다. 이제 웹 서비스를 구현하는 J2EE 개발자가 백엔드 애플리케이션 로직을 공개하고, BPEL 개발자가 이를 이용하여 다양한 서비스를 하나의 비즈니스 프로세스로 통합하는 것이 가능하게 된 것입니다.
WSDL을 통해 정보를 제공받은 BPEL 프로세스는, <partnerLink>라 불리는 개념을 이용하여 웹 서비스를 호출합니다. <partnerLink>는 웹 서비스(WSDL) 내부의 오퍼레이션을 기술하는 BPEL 추상화의 한 종류입니다. 여기서 웹 서비스 오퍼레이션은, SOAP 메시지의 marshalling/unmarshalling을 지원하는 자바 클래스 또는 EJB 컴포넌트의 퍼블릭 오퍼레이션(public operation)을 의미합니다.
BPEL과 J2EE의 연계
웹 서비스가 대부분의 자바 플랫폼에 반영된 지 이미 오랜 시간이 지났고 앞에서 설명한 것처럼 웹 서비스 지원 기능이 J2EE 1.4 플랫폼에 구현되었지만, 많은 기업이 비즈니스적인, 기술적인 이유로 기존 애플리케이션 또는 애플리케이션 인프라스트럭처를 웹 서비스의 형태로 노출하는 것을 꺼리고 있습니다.
그 이유로, 정상적으로 운영되고 있는 미션 크리티컬 시스템을 변경하는 데 따르는 위험부담, 기술 인프라의 업그레이드를 위한 비용부담, 웹 서비스 레이어를 추가하는 데 따르는 성능저하의 위험 등이 언급되곤 합니다. 하지만 이러한 문제들로 인해 (BPEL의 존재 목적인) “통합”의 필요성 자체가 부인될 수는 없습니다. 다만 통합을 구현하는 방법이 달라질 수 있을 뿐입니다.
이러한 문제에 대해 BPEL 언어 자체가 해답을 제시할 수는 없지만, 대부분의 BPEL 프로세스 엔진이 두 가지 방법을 통해 문제 해결을 시도하고 있습니다. 그 하나가 자바에 대한 직접 호출(direct call-out)이고, 또 하나가 WSIF(Web Services Invocation Framework)라 불리는 프레임워크입니다.
자바에 대한 직접 호출(Direct Call-Outs to Java)
BPEL 프로세스 내부에 자바 코드를 실행하기 위한 특수 BPEL 태그를 삽입하는 방법입니다. 일반적으로 EJB를 호출하거나 JMS 큐 (또는 토픽)에 메시지를 올림으로써, EJB 또는 JMS 큐/토픽을 BPEL 프로세스의 통합 포인트로서 활용하는 방법이 사용됩니다.
이러한 방법이 성공하려면 먼저 선결되어야 할 두 가지 문제가 있습니다:
<variables>
<!-- input of this process -->
<variable name="input"
messageType="tns:LoanFlowPlusRequestMessage"/
<variable name="loanApplication"
messageType="services:LoanServiceRequestMessage"/>
</variables>
<!--BPEL receive from a Web service call in-->
<receive name="receiveInput" partnerLink="client" portType="tns:LoanFlowPlus"
operation="initiate" variable="input" createInstance="yes"/>
<!-- retrieve SSN using call out to session bean -->
<bpelx:exec name="RetrieveSSN" language="java" version="1.4">
<![CDATA[
try {
// Retrieve element from scope
Element element = (Element)getVariableData("input","payload","/loanApplication");
// Create an XMLFacade for the LoanApplication Document
LoanApplication xmlLoanApp =
LoanApplicationFactory.createFacade(element);
// Manipulate XML document through typed facade
String email = xmlLoanApp.getEmail();
// Use session bean to access external data source and lookup
// the SSN of the customer based on his email.
CustomerHome cHome = (CustomerHome) lookup("ejb/entities/Customer");
Customer customer = (Customer) cHome.findByPrimaryKey( email );
xmlLoanApp.setSSN(customer.getSSN());
. . .
]]>
</bpelx:exec>
<!-Continue BPEL process -->
. . .
Web services Invocation Framework (WSIF)
기존 시스템에 영향을 주지 않는 두 번째 문제 해결 방법으로 WSIF가 있습니다. WSIF는 Apache에 의해 제안된 오픈 소스 프레임워크입니다. WSIF는 Oracle BPEL Process Manager에 이미 내장되어 있으며 향후 Oracle Containers for J2EE의 10.0.3 릴리즈에 포함되어 Oracle Application Server와의 호환성을 제공할 예정입니다. WSIF는 EJB, JCA 어댑터, JMS 큐/토픽의 백엔드 리소스에 대해 WSDL를 사용한 기술(description)을 가능하게 하는 한편, 이러한 리소스가 네이티브 프로토콜을 사용하여 호출되는 것을 방해 받지 않도록 보장하는 것을 목적으로 합니다.
WSIF를 사용하는 경우, BPEL 프로세스에 의해 호출되는 리소스가 (WSDL로 기술된) 일반적인 웹 서비스처럼 보이게 된다는 장점이 있습니다. 별도로 자바 프로그래밍을 수행할 필요가 없으며, 네이티브 BPEL 언어를 사용하여 마치 BPEL 런타임이 하부 리소스와 네이티브 바인딩을 수행하는 것처럼 구성할 수 있습니다. 이러한 접근법을 사용하는 경우, 네이티브 프로토콜의 성능을 보장하는 동시에 웹 서비스의 추상화 혜택을 누릴 수 있게 됩니다. 이러한 접근법의 효과를 가장 극명하게 보여주는 것이 BPEL Process Manager 환경에 포함된 JCA 어댑터입니다. 대부분의 ERP 및 CRM 벤더들은 WSIF를 이용한 바인딩과 BPEL 프로세스와의 통합을 지원하는 JCA 어댑터를 출시하고 있으며, 이로 인해 표준에 기반한 비즈니스 프로세스 통합의 실현이 한층 가까운 현실로 다가오고 있습니다.
J2EE와 BPEL
BPEL이 Java를 호출하고, Java가 다시 BPEL을 호출하는 관계를 이해하기 위해서는, 모든 BPEL 프로세스가 웹 서비스의 형태로 구현되며, 따라서 다른 웹 서비스와 마찬가지로 WSDL에 의해 기술된다는 사실을 명심할 필요가 있습니다. 그러므로 BPEL 프로세스를 호출해야 하는 J2EE 프로그램은 해당 플랫폼의 WSDL을 실행하여 웹 서비스 클라이언트를 먼저 구현해야 합니다. 앞에서 설명한 것처럼 J2EE 1.4에서 WSDL을 표준 Java API로 구현하고 있으므로, 조만간 모든 기업 환경에서 활용이 가능하게 될 것입니다.
Oracle BPEL Process Manager는 JSP(JavaServer Page) 개발자의 작업 편의성을 한층 향상시킵니다. BPEL 또는 웹 서비스의 개념에 익숙하지 않은 JSP 개발자도, BPEL 프로세스 호출을 위해 설계된 JSP 태그 라이브러리들을 이용하여 쉽게 BPEL 프로세스를 호출할 수 있습니다. 태그 라이브러리 인식기능을 갖춘 Oracle JDeveloper와 같은 툴을 이용하면 몇 번의 클릭만으로 태그 라이브러리를 추가하고 Oracle BPEL Process Manager와의 통합을 수행할 수 있습니다.
결론
이 문서를 통해, BPEL과 J2EE를 이용한 애플리케이션 구축과정에서 개발자가 고려해야 하는 통합 포인트에 대해 설명하였습니다. BPEL과 J2EE는 전혀 다른 설계 목적을 가지고 개발된 언어이지만, 상호보완적이며 함께 사용되는 경우 이전에는 가능하지 않았던 새로운 형태의 애플리케이션을 개발할 수 있는 잠재력을 내포하고 있습니다.
마이크 레만(Mike Lehmann, (mike.lehmann@oracle.com) 은 Oracle Application Server Containers for J2EE 담당 수석 프로덕트 매니저입니다 |
BPEL(Business Process Execution Language)
및 Oracle BPEL Process Manager
업데이트 : 2004년 6월 26일
1. BPEL이란 무엇이며, 웹 서비스 및 서비스 지향 아키텍처(SOA)와는 어떤 관련이 있습니까??
기업들은 각 애플리케이션을 상호 연결하는 것에 대해 언제나 큰 부담을 안고 있습니다. 이러한 이유 때문에 통합 이니셔티브의 비용과 복잡성을 줄이기 위한 기업의 청사진으로서 웹 서비스 및 SOA의 채택을 추진하게 되는 것입니다. 웹 서비스 작업은 게시(publish)와 조정(orchestration)의 2단계 작업 과정으로 이루어집니다. 여기서 게시란 기존 시스템의 일부를 이용하여 그 시스템을 서비스로 노출하는 것을 의미하고, 조정이란 개별적인 여러 서비스를 엔드-투-엔드 프로세스 흐름으로 구성하는 것을 의미합니다. BPEL은 조정을 위한 업계 표준입니다.
2. BPEL을 지지하는 배경 동기는 무엇입니까? BPEL은 통합 비즈니스 프로세스 문제에 초점을 맞춘 과거의 시도 및 기술과는 어떻게 다릅니까? BPEL의 발전에 대해 간략하게 설명해 주십시오.
일련의 서비스를 엔드-투-엔드 프로세스 흐름으로 조정하는 일에는 여러 새로운 기술 요구 사항들(이기종 시스템으로의 바인딩, 비동기식 및 동기식 메시지 교환 패턴, 데이타 조작, 흐름 조정, 예외 관리, 비결정적(undeterministic) 이벤트, 트랜잭션 보상, 병렬 버전 확인, 진행중인 인스턴스 관리 및 감사 등)이 수반됩니다. BPEL의 목표는 이러한 요구 사항들을 해결하기 위해 더욱 다양하면서도 간단한 추상화/표준을 제공하는 것입니다. BPEL이 상당히 새로운 표준이긴 하지만 여기에는 Microsoft와 IBM이 XLANG 및 WSFL에 투자한 10년 이상의 연구 및 개발 경험이 활용되고 있습니다.
3. 조정(orchestration)이란 무엇입니까? 이것은 혼합 애플리케이션을 구축하는 데 있어 어떤 의미가 있습니까? 그리고 조정이 필요한 이유는 무엇입니까?
기존 시스템이 점차 사라져 가고 있지만 기업은 이러한 기존 시스템에 포함된 기능을 활용할 수 있는 새로운 애플리케이션을 구축할 필요가 있습니다. 혼합 애플리케이션의 개념은 기존의 빌딩 블록을 함께 연결지어 새로운 애플리케이션을 구축한다는 개념을 바탕으로 합니다. 조정은 개별적인 각 서비스의 실행을 조화롭게 통합하는 접착제라 할 수 있으므로 이러한 기본 개념에 있어 그 역할이 대단히 매우 중요합니다. 따라서 적절한 조정 서버는 안정적이고 확장 가능해야 하며 BPEL 프로세스 로직을 충실하게 렌더링할 수 있어야 합니다.
4. Oracle BPEL Process Manager란 정확히 무엇이며 무엇으로 구성되어 있습니까? 그리고 BPEL Process Manager가 나머지 스택과는 어떤 관련이 있습니까?
Oracle BPEL Process Manager는 오라클 제품 포트폴리오에 새롭게 추가된 사항으로서, 이를 사용하여 기업들은 BPEL 프로세스를 모델링, 배포 및 관리할 수 있습니다. Oracle BPEL Process Manager는 사용이 간편한 BPEL 모델러, 확장 가능한 BPEL 엔진, 확장 가능한 WSDL 바인딩 프레임워크, 모니터링 콘솔 및 일련의 내장된 통합 서비스(변형, 사용자 작업, java 임베딩)로 구성되어 있습니다. 뿐만 아니라 Oracle BPEL Process Manager는 BPEL/웹 서비스 조정을 Java 플랫폼의 일류 구성 요소로 만들어 줍니다.
5. BPEL Process Manager는 다른 프로세스 통합 제품과 어떻게 다릅니까?
BPEL Process Manager는 다음과 같은 4가지 측면에서 다른 제품과 차별화됩니다.
- 기본 및 종합적인 BPEL 지원
- 확장 가능한 바인딩 프레임워크(웹 서비스는 물론 JCA, JMS 등을 조정할 수 있음)
- 사용 편의성(15분 내로 구동 및 실행 가능)
- 플랫폼 지원(Oracle Application Server를 비롯한 WebLogic, WebSphere 등)
6. 개방성, 이식성, 상호 운용성이 고객에게 중요한 이유는 무엇입니까?
상호 운용성이 중요한 이유는 그 가치 제안의 핵심이 기존 시스템의 일부를 활용하여 이를 보다 높은 수준의 비즈니스 흐름으로 구성하기 때문입니다. 이식성은 비즈니스 프로세스가 기업의 주요 IP 자산이고 고객들이 특정 솔루션에만 고정되기를 원하지 않기 때문에 중요합니다. 마지막으로, 개방성이 중요한 이유는 대기업들이 WebLogic, WebSphere 및 Oracle Application Server를 사용하고 있고 오라클은 기존 애플리케이션 서버에 대한 투자가 무엇이든 상관 없이 어디에서나 잘 운용되는 솔루션을 제공하고 있기 때문입니다.
7. 고유의 BPEL은 왜 중요합니까? BPEL을 단지 가져오고 내보내기만 하는 제품들을 사용할 경우 어떠한 단점이이 있습니까?
역사적으로 어느 때나 표준이 채택되어왔지만(SQL, J2EE, LDAP, SMTP/POP/IMAP, HTML 등) 고유의 솔루션이 항상 승리하였습니다. 이것은 고유의 솔루션이 덜 복잡하고 더 빠르며 더 풍부한 기능을 제공하기 때문입니다. 특히 유지 관리 및 발전이 동시에 이루어져야 하는 기존의 설치 기반을 갖고 있는 경우, 새로운 추상화 개념을 중심으로 엔진을 다시 설계하는 것은 매우 어렵기 때문입니다.
8. Oracle Business Integration은 계속해서 향상되고 있는 BPEL 및 BPEL Process Manager의 이점을 어떻게 활용합니까?
SOA, BPEL 및 혼합 애플리케이션은 기업들이 “실시간 엔터프라이즈”로 한 걸음 더 가까이 다가갈 수 있게 해줍니다. 오라클은 다양한 비즈니스 활동 모니터링 기능이 그 다음 단계라고 생각합니다. 그 이유는 이러한 풍부한 비즈니스 활동 모니터링을 통해 교차 기능 프로세스의 실행과 비즈니스 프로세스 최적화 플랫폼을 상세히 볼 수 있기 때문입니다. 계속해서 향상되고 있는 솔루션의 이러한 측면에서 앞으로 고객들은 오라클을 통해 더 많은 이점을 누리게 될 것입니다.
9. 오라클은 BPEL 규격의 발전 및 표준화에 대해 어떻게 참여해 왔습니까? 또한 이것은 오라클의 다른 통합 및 웹 서비스 관련 표준 노력과 어떻게 관련되어 있습니까? 오라클은 OASIS BPEL 위원회에서 매우 활동적으로 참여하고 있는 회원입니다. BPEL Process Manager를 사용하는 6,500명 이상의 개발자들과 함께 오라클은 BPEL 채택의 선두 위치에 있으며 OASIS BPEL 위원회를 통해 수집한 피드백을 적용하고 있습니다. 오라클은 또한 기타 관련 규격(WS-신뢰성, WS-메시지 전송, WS-컨텍스트, WS-보안, JSR-208/Java 비즈니스 통합)에 대해서도 적극적으로 참여하고 있습니다. 이러한 모든 표준은 인터넷을 메시징/통합 백본으로 변환하기 위해 함께 사용되고 있습니다. 따라서 이러한 표준들은 BPEL 채택에 있어 매우 중요한 역할을 하게 될 것입니다.
10. BPEL Process Manager를 비롯하여 JDev, ADF, TopLink 등은 모든 J2EE 서버에서 실행됩니다. 이처럼 오라클이 개방형 표준과 개방형 인터페이스에 전념하는 이유는 무엇입니까?
확장 가능하고 신뢰성 있는 컨테이너 구축에 투자한 수많은 노동력과 시간을 개방형 표준과 개방형 인터페이스를 통해 활용할 수 있기 때문에 오라클은 이 분야의 개발에 노력을 기울이고 있습니다. 또한 개방형 표준과 개방형 인터페이스를 이용하면 특정 솔루션에만 얽매이지 않을 수 있다는 점에서 오라클 고객들에게도 유익합니다.
11. .NET 호환성은 왜 중요합니까? 어떤 범위까지 BPEL Process Manager가 .NET 호환성을 지원합니까?
.NET은 고객들이 통합하기를 원하는 시스템 목록 중에서 네 번째 또는 다섯 번째 항목에 속하므로 상당히 중요하다고 할 수 있습니다. 따라서 BPEL Process Manager는 BPEL 프로세스가 .NET 서비스를 호출하는 방법과 .NET 클라이언트가 BPEL 프로세스를 초기화하는 방법을 보여주는 예제와 함께 제공됩니다. 현재 오라클은 안전하고 신뢰할 수 있는 메시지를 보여주는 이러한 예제들을 더 확장할 것을 검토하고 있습니다.
12. BPEL은 교차 플랫폼입니다. 그러나 J2EE 플랫폼에서 기본 서비스를 구축할 수 있는 이점이 있습니까? 그렇다면 이러한 서비스에는 어떤 것들이 있습니까?
J2EE 플랫폼은 클러스터링, 가상화 및 모니터링 지원이 점차 향상되고 있습니다. 오라클은 BPEL Process Manager를 J2EE 구성 요소로 설계함으로써 이러한 기능들을 투명하게 활용할 것입니다. 가상화, 자동 배포, 필요시 확장 가능성 및 자가 치유 능력 등은 비즈니스 프로세스와 아주 밀접하게 결합되는 개념으로서 이러한 개발이 함께 이루어지는 것을 살펴보는 일은 대단히 흥미로울 것입
니다.
|
 |
|
(33 ratings) 
B2BiㆍEAI 등 하나의 플랫폼서
기업용 통합 솔루션 전문업체인 비투비인터넷(www.b2binternet.co.kr 대표 이한주)의 BPM 솔루션인 `지코비피엠(XicoBPM)'은 기업간통합(B2Bi)과 EAI, 워크플로의 기능을 하나의 플랫폼에서 수행하도록 설계된 솔루션이다.
지코비피엠은 그동안 통합 솔루션 분야에서 한우물을 파온 비투비인터넷의 경험과 기술력이 녹아든 제품으로, 웹서비스와 BPM 표준언어인 BPEL을 기반으로 서비스 지향 아키텍처(SOA)를 근간으로 하며, 기업 내ㆍ외부 시스템간 유연한 연계 및 과업 기반의 모델링 툴을 제공하는 것이 특징이다.
각종 국제표준을 기반으로 개발된 이 제품은 지난해 연말 대한주택공사의 재무통합시스템 구축에 적용돼 기술력을 인정받은 바 있다. 주택공사는 지코비피엠으로 내부 업무절차 간소화는 물론 업무처리 시간을 대폭 줄이는 성과를 거뒀다.
또 연초에는 삼성전자 해외법인의 업무 프로세스 통합에 핵심 엔진으로 공급되기도 했다. 삼성전자는 현재 80여 해외법인의 분절되어 있던 시스템간 업무를 4개 권역으로 나눠 BPM 엔진으로 통합하는 것을 목표로 하는 프로젝트를 진행중이며, 동남아 6개 법인의 프로젝트를 완료했다.
비투비인터넷은 삼성전자에 지코비피엠을 구축한 것을 계기로 전사적자원관리(ERP)ㆍ고객관계관리(CRM)ㆍ그룹웨어ㆍ데이터웨어하우스ㆍ전자상거래 시스템 등 다양한 시스템의 관리와 운영에 어려움을 겪고 있는 기업들을 대상으로 영업을 확대할 계획이다. 특히 미국 시장 진출을 위해 내년 상반기께 이 회사의 조나단 리 회장이 투자한 컨설팅업체인 모요(MOYO)사와 공동으로 미국 합작법인을 설립할 예정이다. 그 가능성을 타진하기 위해 9일 미국 샌프란시스코에서 열리는 `BPM 콘퍼런스'에 솔루션을 출품한다.
특히 ‘비즈마스터’는 BPEL(Business Process Execution Language for Web Services) 기반의 프로세스 관리기능과 편리한 사용자인터페이스를 적용한 BPM솔루션이다. 기존 데이터 중심 통합은 물론 다양한 어댑터·B2Bi 채널·GUI기반 통합 개발 등의 기능을 장착하고 있다
요약
구매자들은 프로세스 모델링, 조정(Orchestration), 실행 그리고 상호운용성을 수행하는 BPM 표준의 과잉에 직면해 있다. 개방성과 미래투자 대비(future-proofing)가 BPM 표준에서 중요한 요소인 반면, 실재 시장 판매상황은, 신규 표준들에 대한 벤더들의 지원에 따라, 극적으로 변화한다. 현재, 가장 중요한 BPM 표준은 BPEL과 바로 뒤의 BPMN이다. 기업은 실용적인 견지에서, 즉 자신들의 특정 용도를 파악하고, 그리고 그 상황에 적합한 표준을 찾는 접근방식을 취해야 한다.
(역자 주) : Future-proofing ; 미래투자대비 (시스템의 효율적인 설계 및 구축을 통해 시스템 폐기시점을 최대한 늦추고, 효용을 극대화시키기 위한 기획)
통합솔루션인가, 아니면 바벨탑인가?
BPM에 관련된 표준은 아주 많이 존재하며, 이들로 인해 기업들은 어떤 표준이 자신들에게 최선인지 의문을 갖게 된다. 즉, BPEL 기반의 제품을 사용해야 할지, 아니면 Wf-XML 기반이어야 할 지 등. BPEL이 과연 BPML보다 포괄적일까? 그리고 BPML은 더욱 중요해질까? BPMN과 XPDL은 어떤 상황에서 매치가 될까? 이러한 표준들 모두가, 의미있는 BPM 표준의 개발을 진 일보 시키는데 나름대로의 역할을 수행한 반면, 실재로는 몇몇 BPM 표준들이 여타 표준보다 더 중요하며, 몇몇 표준들만이 BPM 벤더들의 지원을 받고 있다. 아래는 BPM 시장에서의 점유율 확보를 위해 경합하고 있는 표준들이다.
BPEL(비즈니스 프로세스 실행 언어): 웹서비스를 사용해, 비즈니스 프로세스를 조정하는 실행언어이다. BPEL은 IBM, Microsoft 및 BEA에 의해 최초로 제안되었으며, 현재는 대다수의 BPM 벤더들에 의해 최고의 BPM 표준으로 인정받고 있다. BPEL은 향후 스펙이 확장됨에 따라 더욱 광범위한 지원을 받게 될 것으로 예상된다.
BPML (비즈니스 프로세스 모델링 언어): Intalio가 도입하고, BPMI.org가 후원한 비즈니스 프로세스 모델링용 메타언어로써, BPEL과 정면으로 경쟁하고 있다. BPML을 지원하는 벤더들이 있긴 하지만, BPEL의 효과적인 차단으로 인해 빛을 보지 못하고 있다.
BPMN (비즈니스 프로세스 관리 표기법): 비즈니스 프로세스 모델링을 위한 표준 표기법.(아이콘과 그래픽 세트 등). BPMN은, 비즈니스 프로세스 모델링 툴들과 BPM 제품내의 모델링 기능을 통틀어, 공통의 모델링 그래픽을 사용하자는데 취지를 두고 있다. 이에 따라, BPMN은 여타 BPM 표준들과 보완적인 관계에 있다.
Wf-XML: OASIS ASAP 기반으로, 워크플로우 관리연합 (WfMC)이 개발한 표준. Wf-XML은 BPM 엔진간 상호운용성을 제공하여, 다수의 엔진에 걸쳐 장기간 실행되는 비즈니스 프로세스의 실행을 가능케 해준다. 수년간 워크플로우 관리연합에서 활동해온 워크플로우 벤더들과 BPM 신규 벤더들 모두 Wf-XML이 BPEL에 의해 대체되어 왔으며, 따라서 향후 주도적인 표준으로는 부적합하다고 믿고 있다.
XPDL: 전체 프로세스를 설명하는 비즈니스 프로세스 정의 언어로써, 모델링 툴들과 BPM 시스템들간의 상호교환 표준으로 개발되었다. 제품 내의 프로세스 모델링, 실행 및 제어에 사용되는 BPM 컴포넌트들을 통합할 때, XPDL을 사용하는 벤더가 다수 있다. XPDL은 현재 WfMC에서 지원하고 있으며, 몇몇 BPM 벤더들이 채택하고 있지만, 향후 BPEL로 대체될 것으로 보인다.
BPM 벤더들은 어떤 표준이 가장 중요하고, 그리고 표준들이 언제 제품에서 지원되어야 하는지에 대해 상이한 시각을 갖고 있다. 몇몇 BPM 벤더들과의 토론을 통해, BPEL이 가장 중요한 BPM 표준으로 인정받고 있으며, 그 뒤를 BPMN과 XPDL이 추격하고 있음을 확인할 수 있었다. (그림 1).
그림1 BPM 표준을 지원하는 벤더
BPM 상에서 특정한 주목을 받고 있지는 않지만, BPM 시스템 구현에 있어 아래 두 표준의 중요성이 점점 커지고 있다.
JSR-94: 비즈니스규칙엔진(BREs)을 위한 자바 런타임 API를 정의하는 Java의 한 규격. 점점 많은 수의 BPM 제품들이 외부 규칙 엔진과 통합되고 있는 점을 감안할때, BPM 벤더들은 JSP-94를 사용하여 자사 제품을 제 3자 BRE들과 통합할 수 있다. JSR-94는 여타 BPM 표준들과 경쟁관계가 아닌 상호보완적인 관계에 있다.
JSR-168: 집합, 개별화, 표시 및 보안을 위한 표준 포탈 API 집합을 제공하는 자바의 한 규격. 점차 많은 수의 포탈벤더들이 이 표준을 지원하고 있으며, 포탈과 BPM 시스템을 통합하는데 사용할 수 있다. 예를 들어, 포탈 사용자들은 JSR-168이 제공하는 통합을 통해 프로세스를 모니터하고 워크플로우 인박스에 접근할 수 있다. JSR-168은 여타 모든 BPM 표준들과 직접적인 경쟁관계에 있지 않다.
대부분의 BPM 벤더들은, 위의 두 표준 중, JSR-168이 훨씬 중요하며, 기업이 BPM 솔루션을 구현할 때 적용할 만 하다고 믿고 있다(그림 2 참고).
현실세계 속에서 BPM 표준에 대한 필요성
BPM 표준들이 벤더들이 주장하는 광고 이상의 의미를 가지기 위해서는, 기업들이 각 표준들에 대한 사용사례를 개발하고, 그리고 특정 표준이 개발된 시나리오에 어떻게, 그리고 왜 적용되는지를 이해되어야 한다. 그렇지 않으면, BPM 표준들은 벤더들간의 주제가 될 위험이 있으며, 이해 부족으로 인해 제안요청서에서 누락되는 항목이 될 수도 있다.
BPM 표준들의 혜택을 볼 수 있는 현실속에서의 4가지 비즈니스 문제는 아래와 같다.
다중 모델링 툴들과 BPM 시스템에서 프로세스를 모델링하는 회사들 각 모델링 툴과 BPM 모델링 컴포넌트는 그 벤더에 고유한 그래픽 아이콘을 사용한다. 다수의 모델링 환경을 사용하는 회사들은 학습곡선(learning curve)이 가파르고, 따라서 모델링 표기법 표준이 도움이 된다는 것을 알게 된다. 이러한 상황에서, 그래픽 모델링에 사용되는 공동의 아이콘이, 각기 다른 모델링 표기법을 익히는데 사용되는 시간을 줄이고, IT 및 비즈니스 사용자들간 의사소통 증진에 중요하다. BPMN은 이 문제 해결을 위해 고안되었으나, BPMN 표기법은 아직 직관적이지 못하고, 오히려 다른 모델링 그래픽이 더 이해하기 쉽다는 것에 주목해야 한다.
그림2 자바 API 표준을 지원하는 BPM 벤더
다수 BPM 시스템에 의해 실행될 필요가 있는 비즈니스 프로세스 미래의 비즈니스 프로세스는 하위프로세스들이 다수의 BPM 시스템에 의해 실행되는 형태일 것이다. 예를 들어, 비즈니스 프로세스 아웃소싱 벤더에 아웃소싱되어, BPM 제품에서 자동화된 한 프로세스는 하나의 독립된, 사내(in-house) BPM 시스템의 중요한 하위프로세스일 수 있다. 바꿔 말하면, 다수의 비즈니스 파트너에 걸쳐있는 한 프로세스가 각기 다른 시스템들에서 자동화될 수 있다는 것이다. 이러한 타입의 시나리오를 처리토록 고안된 것이 바로 BPEL과 Wf-XML이다. 그러나, 현재 대부분의 회사에서 이러한 상황은 발생하지 않고 있는데, 그것은 이들의 프로세스 자동화가 다수의 비즈니스 파터너가 운영하는 BPM 시스템을 수반할 수 있는 단계에까지 도달하지 못했거나, 또는 심지어 다수의 부서에서 하위프로세스를 조정하는 단계에도 이르지 못한 때문이다.
비즈니스 애플리케이션과 통합 할 필요가 있는 비즈니스 프로세스들 BPM 시스템에서 실행되는 비즈니스 프로세스가 기존의 애플리케이션들과 통합될 필요가 있다는 것에 대해 대부분이 수긍하고 있다. 예를 들어, 모기지론(주택담보 대출) 허가 프로세스는 담보물을 사전심사하기 위한 커스텀(맞춤) 또는 패키지 애플리케이션과 통합될 필요가 있다. 이런 상황에서, BPEL을 실행하는 BPM 엔진은 사전심사 애플리케이션 용 웹서비스를 활용함으로써 프로세스를 조정할 수 있다. 이것이 기업이 단기간에 BPEL을 사용할 수 있는 가능한 시나리오이다.
BPM 시스템 속으로 이식 되어질 필요가 있는 비즈니스 프로세스 모델 많은 기업들이, 자사 내의 비즈니스 프로세스에 관한 지식을 끌어낼 수 있는 비즈니스 프로세스 모델을 개발하기 위해 엄청난 시간과 노력, 그리고 비용을 투자해왔다. 그런데 이 모델이 종종 BPM 시스템 외부의 툴에서 개발되기도 하는데, 이들은 반드시 BPM 시스템 속으로 이식 되어져야 한다. XPDL은 이러한 용도로 개발되어, 유사한 문제를 갖고 있는 기업들이 사용할 수 있다. 그러나, BPM 구매자들은 XPDL이 프로세스 모델과 BPM 시스템간 통합에 사용되는 가장 인기없는 표준이라는 점을 인식해야 하며, 따라서, 벤더들간에 개발된 독점 통합 솔루션이 좀 더 다양한 기능을 제공할 것이다.
BPM 표준은 중요성과 함께, 한계도 있다.
BPM 시장이 성숙해감에 따라, BPEL, BPMN, XPDL, 및 Wf-XML 등은 현실세계속에서 수행해야 할 중요한 역할을 가지게 되었지만, 이 표준들은 동시에 한계도 보여주고 있다.
모든 프로세스가 지원되는 것은 아니다. BPEL은 웹서비스에 초점을 맞춤으로써, 성공 가능성이 매우 높은 편이다. 하지만, BPEL이 가지는 한계는 인간 기반의 프로세스에 대한 지원이 부족하다는 것이다. 즉, 인간기반의 프로세스에서 핵심적인 “큐잉(queuing)”과 “인박스” 기능을 지원하지 않는다. BPEL에서 “큐잉(queuing)”과 “인박스” 기능이 지원되려면, custom extension(맞춤 추가기능)으로 추가 개발되어야 한다.
표준이 현실세계에서 상업적으로 활용될 수 있을 것이라는 보장은 없다. 10년 이상의 기간동안, WfMC는 워크플로우 엔진의 상호운용성을 위한 스펙을 지원 및 개발해왔다. 상호운영성에 관련된 수많은 시연들이 벤더들의 적극적인 참여속에서 컨퍼런스, 전시회, 그리고 인터넷 상에서 이루어졌다. 하지만, WfMC의 다양한 스펙을 지원한 제품은 거의 없는 것이 지금의 현실이다. 많은 벤더들이 한 표준에 관심이 보인다는 것과, 그들이 그 표준을 자신들의 제품속에 채택하는 것은 별개의 문제인 것이다.
인증서 심사 및 허가를 위한 인증기관이 필요하다. 벤더가 한 표준에 대한 지지를 공언한다고 해서, 그것이 실현되는 것은 아니다. 우리는 이것을 Sun과 J2EE의 사례에서 실재 경험할 수 있었다. 예를 들어, WfMC의 경우, 한 제품이 표준 스펙을 충족하는 지 여부를 인증할, 독립적인 제3자(third party) 기관의 부족이 중대한 한계로 지적되어 왔다.
표준에 대한 지원은 실재 아주 미약하다. BPEL을 지원한다고 공언한 벤더들이 몇몇 있지만, 실재 제한적인 1.1 스펙을 제외하면, 완전한 스펙은 아직도 준비가 되어 있지 않다. 유저들이 BPEL의 혜택을 받기 위해서는, 2004년 후반기에 발표될 것으로 예상되는 스펙의 차기 버전이 마무리되어야 할 것이다. 하지만, 발표 시기는 2005년 중반 정도로 더 지체될 것 같다.
RECOMMENDATIONS
표준이 정말 중요한지를 이해하기 위해서는 현란한 광고문구를 무시하라.
BPM 표준에 대한 현실적 니즈를 발견하라. 표준들이 특정 문제들을 해결하기 위해 개발된 점을 인식하고, 자사가 가진 문제점을 파악하라. 예를 들어, 회사가 다양한 벤더들로부터 받은 다중 프로세스 맵을 가지고 있지 않다면, BPMN 지원을 고집해서는 안된다. 특정 BPM 표준에 대한 지원 여부를 벤더들에게 묻기전에, 그 표준이 자사에 왜 중요하며, BPM 구현에서 어떻게 사용될 지를 먼저 파악하라.
표준이 기능적 니즈보다 앞서게 하지 마라. 성공적인 BPM 구현을 위해서는, 비즈니스의 기능적 요구사항을 충족시키는 것이 가장 중요하다. 표준이 BPM 아키텍쳐의 중요한 부분인 것은 사실이지만, 비즈니스에 필요한 기능 이상의 벤더를 선정할 필요는 없다. 만일, 한 BPM 솔루션이 비즈니스에 필요한 요구사항을 충분히 충족시키기만 한다면, 관련 표준을 지원하지 않는다 해도, 그 제품을 배제해서는 안된다. 핵심 목표는 비즈니스의 니즈(needs)의 충족이라는 점을 항상 인식해야 한다.
프로세스가 다수엔진을 필요로 할 경후 BPEL의 필요성을 인정하라. 프로세스 전체를 지원하기 위해 다수의 BPM 엔진을 필요로 하는 BPM 구현 프로젝트는 현재로선 극소수에 불과하다. 그러나, 회사가 다수의 BPM 엔진이 실행하는 기능횡단적(cross-functional) 프로세스나, 다수의 기업에 걸쳐있는 프로세스를 가질 경우, 핵심 표준으로써 BPEL에 초점을 맞추어야 한다.
모델링 프로세스가 결정적인 중요성을 띌 경우, BPMN에 대한 벤더의 지원을 모니터하라. 비즈니스 프로세스 개선을 위한 비즈니스 프로세스 모델링이나 프로세스 지식을 정리하는 것을 중요시해야 한다. 이 경우, BPMN이 핵심 표준이 되어야 한다.
XPDL을 지원하기 위해서는 오픈소스 벤더를 찾아라. 오픈소스 벤더들은 개발시간을 단축하기 위해서, XPDL에 기반하여 제품을 개발한다. 오픈소스 벤더를 평가할 경우에는, 모델링, 실행, 그리고 제어 컴포넌트를 통합하기 위해 내부적으로 XPDL을 사용한 제품을 참고하라.
댓글 없음:
댓글 쓰기