posted by 방랑군 2012. 1. 21. 14:49
ebXML [e-business Extensible Markup Language]
ebXML 정의
-      전자상거래 데이터 교환 표준을 마련하고자 하는 전세계적 프로젝트
-      XML 기반으로 e-business 가능하게 하고자 하는 목적의 표준안
-      OASIS/CEFACT 주도하여 기업의 규모나 지역적 위치에 관련 없이 인터넷을 통해 거래할  있도록 하는 규약들의모음
 
ebXML 필요성
-      전자상거래를 위한 단일 표준이 없음
-      XML 실제 전자 상거래의 표준적인 기반으로 인식하고 사용되고 있으나 구체적인 전자 상거래에서의 표준규약은 마련되어 있지 않음
 
ebXML 구성요소
1.     BP(Business Process)
-       다른 기업이 비즈니스 서비스 제공자의 비즈니스를 이용할  있도록 명세화 .
-       업무 프로세스업무절차를 정의한 부분임
-       기업간 거래에 있어서 공유하는 역할(Role), 관계(Relationship), 의무사항(Responsible) 등을 어떻게 수행(처리) 것인가를 상세히 정의하는 
-       비즈니스 프로세스와 이와 연관된 정보 모델 등의 일관된 모델링 방법 제공
-       업무 프로세스를 정의하는 과정에서 문서의 검토가 자연스럽게 이루어지므로 기존 문서 수준의 표준화에서 업무수준의 표준화로 확대가 가능한 것이 EDI 다름.
2.     CC(Core Components)
-       비즈니스 서비스에 사용되는 기능객체를 의미하며 이를 추출하여 이용할  있는 명세를 제공함
-        세계 개념과 비즈니스 개념과의 관계를 구문 독립적이고 명확하게 공통의 핵심 컴포넌트로서 구분하고 새로운확장이 가능하도록 정의한 객체
-       비즈니스 프로세스를 기반으로 재사용성확장성상속성을 지닌 의미 중립적인 비즈니스 객체
3.     RR(Registry/Repository)
-       Registry : 서비스의 메타데이터등 색인정보를 보관
-       Repository : 거래 상대자가 제출한 정보를 안전하게 보관
-       ebXML 구현 인프라의 핵심요소
4.     TP(Trading Partner)
-       거래상대자의 프로파일(TPP) 작성  거래협약(TPA) 작성
-       ebXML 핵심 컨텐츠 부분임
-       CPP(Collaboration Protocol Profile)
-       CPA(Collaboration Protocol Agreement)
5.     MS(Message Service)
-       각각의 요소 사이에 메시지 전송  보안성을 규정
-       ebXML 거래 당사자들간의 비즈니스 메시지들을 교환하기 위한 표준 방법을 제공
 
ebXML 운영 시나리오

 
 
 
 
     기업A ebXML등록기를 인지하고 있으며, ebXML 준수하는 거래를 하기 위하여 등록기에 ebXML규격서를 요청한다.
     등록기는 ebXML BP 규격서를 기업A에게 제공한다.
     기업A 규격서를 받아서 검토한  규격서에 따라서 자신의 시스템을 구축한다.
     기업A 자신의 구현내역참조링크거래 파트너 프로필 (TPP: Trading Partner Profile) 등을 등록기에 제출한다.
     TPP  기업의 ebXML능력과 제약시나리오 등의 내용을 포함한다등록기는 업무 객체의 형식과 사용이 정확함을검증한  기업A에게 승인되었음을 전달한다.
     기업A 중소규모의 기업B에게 ebXML 사용하여 거래를 하고자 함을 통지하면기업B 자신의 기존 응용어플리케이션과 접속이 가능하고 ebXML 준수하는 응용어프리케이션을 획득하여 설치하게 된다 ebXML응용은 기본적인객체 라이브러리와  기업이 속한 산업분야의 BP 모델 등을 포함하고 있으나새로 등록된 기업A 관한 정보는 없으므로이를 입수하기 위하여 등록기에 기업A 관한 질의를 하게 된다.
     기업B 등록기로부터 기업A 관한 프로필을 획득한다.
     TPP(Trading Partner Profile) 바탕으로 기업 A 지원하는 특정 시나리오를 수행할  있는지를 결정하게 된다시나리오를 실행하기 전에기업B 작성된 거래 파트너 합의 (TPA: Trading Partner Agreement)  작성하여 기업A 응용 인터페이스에 제출한다.
     메시지 처리사고 처리보안 등의 요구사항과 시나리오를 규정하고 있는 TPA 수신한 기업A  TPA 승인되었음을 기업B ebXML응용어플리케이션에 통보하게 된다.
     기업A 시나리오가 아직 기업B 응용에 존재하지 않기 때문에 등록기에 요청하여  시나리오를 확보한다.
     기업A 기업B ebXML규격서를 사용하여 B2B거래를 실행하게 된다.
 
ebXML Web Service 비교
구분
ebXML
Web Service
서비스 정보
-      RR
-      (B2B) Business Collaboration
-      Registry Federation(v3.0)
-      UDDI
-      (A2A) Application Integration
-      Registry Federation 기능 없음
-      각각의UDDI 연경된 기능은 정의 것이 없음
서비스 흐름
-      BP
-      기업간 거래의 역할관계의무사항 등을 정의한 시나리오
-      BP
-      다수  서비스를 연결한 복합  서비스를 제공하기 위한 시나리오
서비스의 구체적구현
-      XML 사용한 것으로만 정의
-      BPML4WS
 
ebXML 기타 저자 상거래 안과의 비교
구분
ebXML
eCo
UDDI
RosettaNet
Biztalk
대상산업
특별한 규정 없음
특별한 규정 없음
특별한 규정 없음
IT & 전자 부품
특별한 규정 없음
통신프로토콜
HTTP, SMTP
HTTP
HTTP(SOAP)
HTTP/CGI
HTTP(SOAP)/MSMQ
서비스찾기
지원
확장 지원
지원
없음
지원
레파지토리
분산형태
로컬에 위치
분산형태
없음
지원
메시지 형식
XML Document(MIME)
XML Document
XML Document
XML Document(MIME)
Biztalk Document기반을  Biztag
보안
S/MINE, 디지털 서명
선택적임
각각 UDDIregistry에서 인증
HTTP SSL/디지털 서명  인증서
표준화된 계층정보
온톨로지
Common Business Object
Common Business Library
NAICS, UN/SPSC
Technical and Business Dictionaries
Collection of Biztag
 
ebXML 파급효과
-      IT 산업 측면으로 보면 주요 IT기업의 ebXML 지원 제품 출시  시장 지배력 강화 노력 증대 기여
-      새로운 신생기업에게 새로운 기회를 주는 시장
-      경제적 측면으로 전자상거래 활성화에 따른 경제의 역동성 증가
-      신생기업에게 진입 장벽을 낮추어   있는 새로운 전자 상거래 관행 장착
 
ebXML 향후 전망
-      현재 EDI 채택하고 있는 대기업들이 병행적으로 ebXLM 사용을 시작으로 장기적으로는 대부분 기업이 ebXML 사용하여 전자 상거래를  것으로 예견됨
-      그러므로 기업은 ebXML 대한 표준화 동향을 예의 주시하여 신규시장 진입  새로운 기술에 대비하여야 
-      ebXML 이용한 B2B전자 상거래는 새롭게 시작하는 중소기업에게 신규시장에서의 새로운 도약기회를   있으므로이에 대한 대비 필요

[출처] ebXML |작성자 피비티

'BIZTALK > DEFINITION' 카테고리의 다른 글

Microsoft는 BizTalk Server를 이해  (0) 2009.12.22
SOA와 미들웨어, EAI하고 차이  (0) 2009.12.22
SOA와 EAI  (0) 2009.12.22
EAI 연동방안의 차이점  (0) 2009.12.22
EAI와 ERP의 차이점  (0) 2009.12.22
posted by 방랑군 2009. 12. 22. 16:03
1.Service Overview - MS BizTalk Server 구현
기업은 비즈니스 환경의 급속한 전산화 과정을 통하여 필요한 여러 가지의 시스템들을 구축하게 되었습니다. 이러한 과정을 통해 도입된 기업의 시스템들은 점점 기업 내부의 일을 처리하는 영역의 어플리케이션에서 기업간 업무를 처리하는 영역의 어플리케이션으로 그 담당 업무의 영역을 확대해 갔으며, 각 어플리케이션 단독으로 업무를 처리하던 경향에서 연관된 어플리케이션들간의 상호 보완적인 운용을 통하여 담당 업무를 처리하는 경향을 나타내게 되었습니다. 이러한 경향에서 가장 주목 받는 분야가 어플리케이션 통합(Application Integration)입니다.

기업내의 어플리케이션을 주 대상으로 통합하는 것을 EAI(Enterprise Application Integration),
기업간의 (웹)어플리케이션을 주 대상으로 통합하는 것을 B2Bi(Business to Business Integration)이라고 나누며, 이 두 종류의 통합을 통칭하여 eAI(e-Business Application Integration)라고 합니다.

TOBEway는 BizTalk Server에 대한 깊은 이해와 프로젝트 경험을 토대로 고객의 표준화되고 통합화된 기업환경을 구축해 드립니다.

2.Service 유형
어플리케이션 통합 서비스는 다음과 같은 서비스의 조합으로 이루어진다고 할 수 있습니다.

  • 메시징 서비스 및 관리 서비스
    문서의 수/발신, 문서의 포맷을 찾아내기 위한 파싱, 문서의 전송 및 문서 추적/상태 확인 등의 기능을 제공합니다.
  • 데이터브로커 서비스
    상이한 시스템과 어플리케이션을 연동하기 위해 적절한 메시지를 정의하고 생성하며, 이를 변환하는 문서 변환 서비스를 제공합니다.
  • 어댑팅 서비스
    어댑터란 패키지 어플리케이션 또는 메인프레임과 같은 이기종 시스템과의 접속을 위한 소프트웨어 모듈로서 해당 소프트웨어와 플랫폼 사이에 위치하며 데이터 중개 및 어플리케이션 연동의 인터페이스를 담당하게 됩니다. 적절한 어댑터를 선택하여 제공합니다.
  • 비즈니스 프로세싱 서비스
    연동 비즈니스의 프로세스를 분석하여 자연스럽고 통합의 효과를 극대화 할 수 있도록 제어하는 비즈니스 workflow기능을 제공합니다.
  • 글로벌 표준 지원 서비스
    기업간 어플리케이션 연계를 위한 기능을 제공하며, 여러 산업별 표준을 지원하는 프로세스 팩을 제공함으로써, 외부 기업간 B2B 통합 기능을 지원합니다.
  • 플랫폼 기능성 확보 서비스
    eAI의 모든 데이터를 안전하게 전달하고 안정성, 성능 등을 보장하는 기반 소프트웨어로서 주로 미들웨어를 사용하며 이를 적절히 선택/구성합니다.


  • 3. Service Principles
  • Global Standard based Integration : 국제표준 프레임워크를 적극 활용하여 통합함으로써 비즈니스
        환경의 변화에 빠르게 대응할 수 있도록 합니다.

  • Loosely Coupled Integration : 개별 시스템과 어플리케이션의 장점을 살리면서 시너지 효과를 낼 수
        있는 적정한 정도의 통합을 설계합니다.

  • Process-Oriented Integration : 통합대상에 대한 프로세스를 이해하고 자연스럽고 통합의 묘를 가장 잘
        살릴 수 있는 프로세스 중심의 통합을 지향합니다.

  • Leverage of Legacy system : 기존 IT 시스템을 최대한 활용하여 통합으로 인한 추가 비용의 발생과
        업무영향을 최소화하고 익숙한 기존 시스템을 최대한 활용합니다.

  • Scaleable and Securable Integration : 시스템의 확장성과 보안성에 대한 고려가 필요합니다.

  • Adequately Synchronous Integration : 메시지의 전달과 기능 수행 간에 연동 신뢰도와 수행 능률을
       높이기위해 동기화통합(Synchronous Integration)과 비동기화 통합(Asynchronous Integration)을
       적절히 설계합니다
  • 'BIZTALK > DEFINITION' 카테고리의 다른 글

    ebXML  (0) 2012.01.21
    SOA와 미들웨어, EAI하고 차이  (0) 2009.12.22
    SOA와 EAI  (0) 2009.12.22
    EAI 연동방안의 차이점  (0) 2009.12.22
    EAI와 ERP의 차이점  (0) 2009.12.22
    posted by 방랑군 2009. 12. 22. 15:15
    1. 미들웨어
        - 말 그대로, "중간 단계에 위치하여 서비스를 해 주는 소프트웨어적으로 운영되는 프로세스"를 
    말합니다.
        - 이러한 소프트웨어가 출현한 배경으로는 우선 기존 Client/Server의 2 Tier 환경에 있어서 
    업무 처리 로직이 Client에 위치하게 되어 Fat Client를 초래함으로써 버젼 관리가 어렵고, Client 프로그램이 많아지게 되면 
    Server에 추가되는 부하도 동일하게 증가되어 대용량 환경하에서의 컴퓨팅에 적당하지 않게 되었습니다.
        - 이에, 비즈니스 로직을 Client에서 떼어내고, Client의 수가 증가하더라도 Server에 
    미치는 영향을 최소화하고자 하는 측면에서 중간에 Middleware라는 소프트웨어를 활용하게 되었습니다.
        - 현재 사용하는 EAI, WAS(Web Application Server)도 Web 환경하에서 운영되는 
    대표적인 미들웨어라고 볼 수 있습니다.
     
    2. EAI(Enterprise Application Integration)
        - 기업이 업무를 처리하는 데 있어서는 인사 시스템, 회계 시스템, 마케팅 시스템, 재무 시스템 등 많은 
    시스템들이 존재하게 되는 데,
        - 시간이 지남에 따라서 이러한 시스템들간에 데이터 연동이 필요로 하게 되었습니다. 
        - 이러한 연동을 위해서 각 시스템들간의 1:1 직접적인 연동 프로그램을 개발하여 문제를 
    해결하였습니다만,
        - 이 같은 해결 방식은 연동 대상 시스템이 많을 경우, 개발할 연동 프로그램의 수가 많아질 뿐 
    아니라, 연동에 대한 내용이 변경이 될 때에 관련되는 모든 프로그램을 고쳐야 해서 관리 측면에서 많은 문제를 야기 했습니다.
        - 이러한 문제를 해결하기 위해서, 연동 되는 시스템들의 중간에 일종의 Middleware로서 EAI를 
    두고 EAI에서 각 시스템들간의 연동과 다른 시스템으로의 데이터 송수신을 책임지게 하는 아키텍쳐를 고안하게 되었습니다.
        - 이렇게 되면, 연동해야 시스템들은 EAI에게만 데이터를 전송하면 EAI가 다른 
    시스템으로 필요한 데이터를 필요한 포맷에 맞게 전달해 주게 되므로 인해 기존의 1:1적인 연동으로 인해 일어나는 관리상의 문제들을 제거할 수 
    있습니다.
     
    3. SOA(Service Oriented Architecture)
        - IT 자원을 서비스화하여 재사용함으로써 비즈니스의 요구에 빨리 대응할 수 있게하는 IT 
    Architecture의 한 형태를 말합니다.
        - IT 자원을 재사용한다는 측면에서 컴포넌트를 사용하는 개발방법과 유사하다고 할 수 있지만, 요즘 
    얘기되는 SOA는 플랫폼에 관계 없는 표준 기반의 기술을 사용한다는 측면에서 조금 차이가 있다고 볼 수 있습니다.
        - SOA가 되기 위해서는 사용할 수 있는 서비스를 설명(Description)하고, 이러한 서비스를 
    찾을 수(Search) 있는 인프라가 제공이 되어야 하는 데, 그러한 인프라를 요즘 얘기하는 ESB(Enterprise Service 
    Bus)라고 합니다.
        - 이 ESB는 일종의 Middleware로서 기존 시스템의 연동 기능을 제공하는 EAI와 유사한 기능을 
    제공하고 있습니다만,
        - EAI가 제공하는 업체가 사용하는 벤더 종속적인 기술을 사용하는 반면, ESB는 표준 기반(예를들면 
    웹서비스)의 기술을 사용한다는 측면에서 EAI와 가장 큰 차이가 있다고 볼 수 있습니다.
     
    결론은, EAI나 (SOA의) ESB는 미들웨어라고 볼 수 있고 동일한 목적, 즉 시스템의 연동이라는 목적을 수행하는 솔루션이라고
    볼 수 있지만, 그 방법에 있어서는 표준 기술을 사용하느냐 하지 않느냐의 차이가 있습니다.
     
    표준 기술을 사용하는 것의 잇점은 서로 다른 벤더 제품의 ESB를 사용하고 있는 기업이라도 ESB의 연동을 통해 다른 기업의 IT 
    자원을 재사용할 수 있어 기업간 프로세스 통합에 큰 도움이 된다는 것입니다.

    이 지식은 삼성경제연구소에서 공유해주셨습니다.

    'BIZTALK > DEFINITION' 카테고리의 다른 글

    ebXML  (0) 2012.01.21
    Microsoft는 BizTalk Server를 이해  (0) 2009.12.22
    SOA와 EAI  (0) 2009.12.22
    EAI 연동방안의 차이점  (0) 2009.12.22
    EAI와 ERP의 차이점  (0) 2009.12.22
    posted by 방랑군 2009. 12. 22. 15:14
    우선 SOA가 무엇인지 알아보자면요,
     
    SOA는 아키텍처와 인터페이스의 다른점을 신경 쓰지않고 모든 어플리케이션을 
    네트워크를 경유하여 서비스로서 자유롭게 조합하여 이용할 수 있도록 하기위한 시스템 설계상의 방법입니다.
     
    여기서 서비스라는 것은 비지니스 로직을 컴포넌트화 한 것으로, 예를 들면 '2분기연속으로 이익을 내고 있는 기업의 
    리스트를 조회한다'라는 비교적 포괄적인 형태에서도 API를 호출하는 것처럼 서비스를 호출하는 측이 하위레벨(네트워크 설정과 SQL 등)를 의식할 
    필요가 없이 필요로 하는 서비스를 호출하기만 하면 됩니다.
     
    웹 서비스는 여기서 말하는 서비스의 내장방법 중에 하나입니다.
     
    그럼 다음으로 EAI는 무엇인지 알아보겠습니다.
     
    소위 EAI 툴이라 불리 우는 제품을 판매하고 있는 각 벤더는 최근에는 EAI 보다는 BPM이라는 단어를 사용하기 
    시작하고 있고 웹 어플리케이션 서버도 어댑터가 사용되면서 EAI 툴이라 불리게 되었습니다.
     
    더욱 진보한 SOA(Service Oriented Architecture)에 기반으로 하는 ESB 
    (Enterprise Service Bus) 제품 이라는 새로운 흐름도 나타나기 시작했습니다. 그 외에 데이터 웨어 하우스 구축에서 사용되는 
    ETL (Extract, Transform, Loading : IT환경에서 상이한 종류의 데이터를 추출, 변환, 가공하는 툴)도 어플리케이션의 
    데이터 연계라는 의미에서는 EAI의 범위에 포함됩니다.
     
    EAI의 기본은 1대1 어플리케이션 연계에서 시작됩니다.
    다시 말해서 EAI는 부분적으로 도입 되어지는 업무 어플리케이션과 기존 시스템을 통합해서 하나의 시스템으로 활용하기 
    위한 조합을 목적으로 하고 있습니다. 
    여기에서 우선 1대1 어플리케이션 연계를 설명해보도록 하죠.
     
    1대1 어플리케이션 연계에는 MOM(Message Oriented Middleware)이 
    사용됩니다.
    MOM 이라는 것은 어플리케이션간의 계속적인 쌍방향 데이터 교환을 가능하게 하는 미들웨어 이며 EAI의 가장 기본이 
    되는 소프트웨어입니다.
    프로그래머는 MOM을 도입함으로써 어플리케이션의 통신부분을 개발하지 않고도 개발을 마칠 수 있습니다. 어플리케이션의 
    연계부분의 개발시간과 개발비용을 크게 절감 할 수 있다는 얘기가 됩니다.
    MOM에는 메시지 큐잉 모델이 사용됩니다.
     
    여기서는 아이비엠의 MQ를 예를 들어 알아보겠습니다.
    이 시스템간의 통신방식의 최대 특징은 어플리케이션 간에 직접 세션을 맺지않고 큐(Queue)라고 불리는 스토리지 
    (디스크상이나 메모리 상에 생성이 가능)를 경유해서 간접적으로 메시지(데이터)를 주고 받을 수 있습니다.
    결국 메시지 큐잉 모델에서는 메시지 발신 어플리케이션에서 발송 되어진 메시지를 일단 큐에 저장을 하고 그 후에 수신 
    어플리케이션이 큐로부터 메시지를 받는 방식으로 되어있습니다.
     
    이 방법이라면 발신측은 수신측 상태를 신경 쓸 필요가 없어집니다. 실제 어플리케이션 간의 통신에서는  
    운영체재의 장해, 네트워크의 장해 등으로 수신측 어플리케이션이 이용할 수 없는 경우가 발생하지만 그 때에는 이용이 가능할 때까지 큐에 메시지를 
    일시적 (장기간 보존가능)으로 보관해 두기만 해도 됩니다.
     
    구체적으로는 MQ는 tcp/ip, SNA 등의 복수의 프로토콜에 대응하고 있기 때문에 프로그래머는 어떤 통신 
    프로토콜을 통해서 통신을 하고 있는가에 대해 의식 할 필요가 없습니다.
    MQI(Message Queue Interface)라는 복수의 플랫폼 간의 통일된 13개의 인터페이스 
    (MQOPEN:큐의 오픈, MQPUT : 큐로 메시지 전송) 구사만으로 충분합니다.

    이 지식은 삼성경제연구소에서 공유해주셨습니다.

    posted by 방랑군 2009. 12. 22. 15:13

    1. Adaptor를 사용하는 방식은 보통  메시지큐잉이나 MOM 통합 방식에서 사용합니다. Point-to-Point 방식 EAI라고도 합니다. MQ 가 대표적인 방식이구요.

    EAI와 양 연동대상 모두 Adaptor를 설치합니다.

     

    2. Adaptor를 사용하지 않는 방식을 Hub-and-Spoke 방식이라고 합니다.

    EAI가 표준화된 연동기술을 제공하여 연동대상 시스템에는 Adaptor가 설치되지 않는 방식입니다.

    엄밀히 말하면 Hub-spoke방식에서도 Adaptor가 쓰이지만, Adaptor를 EAI만 가지고 있다라고 보시면 됩니다.

    최근의 EAI 제품은 모두 이 방식이 아닐까 싶네요.

    posted by 방랑군 2009. 12. 22. 15:12

    다른 사람들 마냥..^^

    사전식으로 비교 설명해 가며 논문형식으로 쓸 맘의 여유는 없으니.. 허접하지만..^^

     

    간단히 알려드릴께요..^^

     

    EAI는 Application system들 끼리의 연계가 주목적입니다.

     

    ERP는 기업의 자원(예를 들면 돈, 사람, 제품, 재고, 기타등등)을 관리하기 위한

     미리 개발되어서 검증되어져 있으며 하나의 DB를 통해 구현된 기업에서 사용되어지는

    애플리케이션 프로그램들의 종합선물세트같은것입니다.

     

    ERP를 도입하면서 ERP자체에 없는 업무가 회사에 존재할경우 ERP시스템 안에 새로

    개발하여 사용할수도 있으며,  새로 개발 할것이 아니라 기존에 이 업무에 관한 애플리케이션 시스템이 있다면 ERP와의 연계를 위해서

    EAI 툴도 같이 도입하여 기존 애플리케이션 과 새로도입한 ERP시스템과 연계를 시키기도 합니다.

     

    더 자세히 쓰자면 한정이 없어서리..^^  이상입니다...

    posted by 방랑군 2009. 12. 22. 15:07

    순수(Pure-Play) BPM 이라는 용어보다는 WorkFlow 기반 BPM 이라는 용어가 맞습니다.

    그래서 BPMS Solution 은 두가지 형태 즉

     

    1. WorkFlow 기반 BPM ( 핸디 나 Savvion )

    2. EAI 기반 BPM ( Tmax, WebMethod 등)


    으로 나누어 집니다. 이 두개의 그룹으로 나누는 기준은

     

    첫째. 프로세스 단위를 정의하고 통제하는데 적용되는 기술 표준이 다릅니다. 
    WorkFlow 기반은 주로 XPDL 이라는 표준기술을 적용하고
    EAI 기반은 BPEL 이라는 표준기술을 적용하여 개발됩니다.


    둘째. 다루려는 대상의 차이입니다.

    WorkFlow 그룹은 Work 즉 업무수행 중심 즉 하나의 시스템내에서 수행되는 업무의 수행 통제 및 제어가 주 목적이고

    EAI 그룹은 업무를 수행하는데 있어서 관계되는 타 업무 및 관련 시스템들간의 연동 및 통제에 중점을 두었습니다.

     

    그래서 BPMS 라는 개념이 부각되기보다는 WorkFlow 시스템 구축이라는 개념이 만연한 초창기때는 WorkFlow 기반 솔루션이 강세이었는데 근래에 Internet 발달등을 근거로 시스템의 확장 및 다변화에 따라서 회사의 업무가 단위 업무 또는 단일 시스템내에서만 수행되는 업무이기보다는 업무대 업무가 연결되고 업무와 시스템이 엮이고 연관되는 프로세스 개념이 강하게 부각되어서 EAI 기반의 BPMS 즉 BPEL 기반으로 개발된 BPMS에 관심이 집중 되고 있습니다. 이와같이 변화의 근거에는 WebService 라는 개념과 SOA 라는 개념의 발달이 바탕이 되었습니다. (이것까지 여기서는...^^)

     

    그러나 이것들은 작년정도까지 서로 자기집단것이 좋다 고 주장하였던 근거였고요 지금은 이런 기준(WorkFlow, EAI)으로 제품을 나누것이 점점(점점입니다. ^^) 무의미 해지고 있습니다. 각 그룹의 제품마다 그룹 파트의 장점은 살리고 단점은 보강하는 추세입니다. 소속그룹의 단점이 상대 그룹의 장점이니까 WorkFlow 그룹은 EAI 장점을 받아들이고(BPEL, WebService) EAI 파트는 Workflow 의 요소 (수행주체, 사람, 업무단위) 등을 받아들이고(BPEL2, BPEL4People) 있습니다. 아마도 1~2년 후에는 파트 구분 자체가 무의미 해질거라고 저는 예상합니다.

     

    각 그룹의 장, 단점은 어떤 기준으로 BPMS 을 도입하느냐? 의 결정에 따라서 매우 많은 영향을 받습니다.

    첫째. '단일 업무 시스템 을 BPM 기반으로 구축한다.' 즉 BPM 기반의 회계관리시스템 이런 기준이라면 업무중심이 강하기에 WorkFlow 기반의 BPMS 가 유리한 면이 많이 있습니다.

    둘째. 업무의 그룹 또는 연결 즉 프로세스 위주로 수행 업무에 관련된 전체 업무를 연동시킨다면 즉 회계관리-전자결재-지급처리-ERP반영 등 수행 업무를 진행하는데 적용/연관되는 모든 업무 및 시스템의 통합 및 관리위주로 시스템을 구축한다면 시스템 연동 및 통제가 가능하고 쉬운 EAI 기반이 유리합니다.

     

    그리고 어떤 기준으로 BPMS 을 활용할 것인지를 결정하십시요.

    첫째. BPMS 의 역활이 무엇이냐? (하나의 업무 통제냐?, 아님 그 업무와 연관된 다른 업무 및 시스템의 통제까지냐?)

    둘째. 향후 BPMS 의 활용성은 무엇이냐? (구축 대상 시스템만을 위한것인지?  아님 향후 확장되고 만들어지는 모든 시스템의 통제인지?)

    셋째. 미래 기업의 전산 운영 계획 및 정책은 어떻게 되는지? (SOA 체계의 Infra 를 구축할것인지? 지금의 체계를 유지 할 것인지? )

     

    이전에 그룹별 특화된 분야는 은행/금융권에서는 단위업무 위주의 수행시스템이 많은 관계로 주로 Workflow 기반을 도입하였고 시스템이 많은 대기업등에서 연결/연관된 업무가 많은 업무관리시스템을 구축시에는 EAI 기반으로 구축하였는데 지금은 그것이 절대적 기준이나 의미가 되지는 않습니다.

    'BIZTALK > DEFINITION' 카테고리의 다른 글

    SOA와 EAI  (0) 2009.12.22
    EAI 연동방안의 차이점  (0) 2009.12.22
    EAI와 ERP의 차이점  (0) 2009.12.22
    EAI(Enterprise Application Integration)란?  (0) 2009.12.22
    Explaining the BizTalk Architecture  (0) 2009.09.02
    posted by 방랑군 2009. 12. 22. 15:06
    EAI는 기업내의 컴퓨터 애플리케이션들을 현대화하고, 통합하고, 조정하는 것을 목표로 세운 계획, 방법 및 도구 등을 일컫는 비즈니스 컴퓨팅 용어이다. 대체로, 기업들은 오래 전부터 사용해오는 기존의 응용프로그램들과 데이터베이스를 가지고 있으며, 여기에 기능을 추가하거나, 또는 인터넷, 전자상거래, 엑스트라넷 및 기타 다른 기술들을 이용하는 새로운 애플리케이션으로 바꾸어나가는 동안, 기존의 것들을 계속해서 사용하기 원한다. EAI는 기업의 비즈니스와 애플리케이션의 새롭고 통합적인 시각을 개발하고, 기존의 애플리케이션들이 새로운 시각 내에 어떻게 맞추어지는지를 확인하고, 또 새로운 애플리케이션과 데이터를 추가하는 동안 이미 존재하는 것들을 효과적으로 재 사용할 수 있는 방법을 고안하는 등의 활동을 포함할 수 있다. 

    EAI는 객체지향 프로그래밍, 분산처리, CORBA나 COM+와 같은 메시지 브로커 등을 사용한 다중 플랫폼 프로그램 교신, 새로운 목표에 맞추기 위한 ERP의 수정, 공통 데이터베이스를 이용한 기업내의 콘텐츠와 XML로 구현된 데이터 표준의 배포, 미들웨어, 메시지 큐잉, 그리고 기타의 접근방법 등과 같은 방법론들을 포함한다.

    'BIZTALK > DEFINITION' 카테고리의 다른 글

    SOA와 EAI  (0) 2009.12.22
    EAI 연동방안의 차이점  (0) 2009.12.22
    EAI와 ERP의 차이점  (0) 2009.12.22
    순수(Pure-Play) BPM[WorkFlow BPM]과 EAI 기반 BPM 의 차이  (0) 2009.12.22
    Explaining the BizTalk Architecture  (0) 2009.09.02
    posted by 방랑군 2009. 9. 2. 13:58

    참조 : http://www.codeproject.com/KB/biztalk/BiztalkToGrandma.aspx


    Introduction

    I have heard they ask "How would you explain Excel (any product) to your grandmother?" in many companies; a question popularized by Microsoft, I believe. First, I am not so sure my grandma would understand any technology product so easily. Also, I am not sure if this is a good question to ask a software developer; maybe, to someone from sales, yes! On the record, I must say that my grandmother is an incredibly smart lady. So the question really boils down to "How you would make an IT common man understand what a product is all about?" This is what I am trying to endeavor in this article.

    Sometime back, I had to explain to a group of non-IT folks about BizTalk Server. You know the people who wouldn't understand all these geeky terms like SOA, XML, SOAP, or Orchestrations (pardon me, she says she knows about SOAP!). I thought I'd share my experience here in this article for the benefit of the CodeProject community. This article is aimed at you if you have heard about this wonderful thing called BizTalk Server, and want to understand what it is clearly before diving into the marketing material which seems to be the same for every product - the "panacea" of all your problems.

    Drawing a Parallel

    BizTalk Server is Microsoft's enterprise application integration solution, with built-in support for XML and SOAP. It offers integration with Visual Studio .NET, and provides speed, reliability, and flexibility for standards-based enterprise application integration. An analogy they say is "Similarity in some respects between things that are otherwise dissimilar". So for me, to explain BizTalk, I would start off with an analogy. In the section below, I am comparing BizTalk Server to a Customs facility.

    The Customs Facility

    sample image

    What we have in the figure above is a Customs facility. We have an Import Terminal through which a large number of packages come in by different modes of transport: planes, ships, buses, trucks, barges. These packages then go through a standard inspection process, with several stages including identifying the package, unpacking the contents, and then identifying the shipper. The packages then go to a central store. From there, customs inspection of the packages takes place. The process could be different for different types of packages, and there is a "Customs Inspection Rules and Regulations Manual" which details the inspection process, and which in practice, gets updated from time to time. After a package passes the inspection process, it is sent back to the central store, from where it is packaged and sent to the correct destination.

    The BizTalk Server Architecture

    sample image

    The figure above is the architecture of a BizTalk Server messaging subsystem. As you will notice, this figure is same as the previous figure except for the labeling. Here, instead of packages moving, we have XML messages that are moving. The files come in through Receive Ports and are passed to the "Message Box" through a "Receive Pipeline". They are then picked up by "BizTalk Orchestrations" and are processed. Custom rules maybe loaded and executed at this point. They are then send out using a Receive Pipeline through a "Send Port" to the destination.

    Receive Ports

    The Receive Ports are how messages come into BizTalk. Messages can come into BizTalk by any means of transport like HTTP, SOAP, SQL, file, EDI; just like the way packages arrive via planes, ships, buses, or trucks. How they are transported does not change how they are processed later. This is a very powerful feature because it gives you the ability to change the transport type and the source of the data even after your application is deployed, without changing your application implementation. For instance, let us say some sales related data is coming in from a shared "FILE" folder in Europe connected via WAN today, tomorrow you can configure it as an FTP pickup from a remote server from India, or probably accept it as an HTTP request over the web posted from a browser.

    Adaptors

    Adaptors are the BizTalk way of handling additional transport. Just like you can have a private plane fly your package in, you can write your own adaptor for a custom transport, like say POP3. So there is always scope for buying or writing your own custom adaptor to integrate with all the other available transports. For instance, you can have a DB2 adaptor or a SAP adaptor.

    Receive Pipeline

    The Receive Pipeline contains different mechanisms like "Decoding" (if encoded), "Disassembling" (if there are multiple parts), and "Party Resolution". This is similar to the unpacking and identifying the sender, in our example. Just like we have an express lane for certain packages, there is a "Pass Through" pipeline facility in BizTalk which is essential a smooth transfer to the Message Box. Just like you can have special handling instructions for certain packages, you can write custom pipeline components using the framework.

    Message Box and Subscriptions

    The BizTalk Message Box lies in the heart of the BizTalk messaging subsystem; this is like our central store. This message box is, in fact, realized as a SQL Store; so this way, BizTalk ensures reliability for your messages in terms of guaranteed delivery. Even if a node in BizTalk fails, the message will be picked up by another node in the farm. BizTalk also ensures that it does not delete the file from a pickup folder location while using file/any transport, unless it is persisted completely in SQL. Well, this also means you need to have a fault tolerant SQL Server architecture. Just like we will be noting down a few important details while we unpack the packages, in the pipeline, certain properties are promoted into the context, like transport information: the most important of these being the incoming XMLSchema#RootNode. The BizTalk Publish-Subscribe mechanism identifies which Orchestrations subscribe to that particular message, based on this promoted information, and routes it accordingly.

    Orchestrations

    Orchestrations are processes that are defined in the Business Process Execution Language (BPEL). This could be something like, say: if quantity is greater than threshold, apply discount, else standard discount. At this stage, you can also change the format of the message using Transformation Maps, or you can call some other web service to do an operation like credit card verification. This is like our example in which we have the customs inspection process and checking with the bank if the excise payment is cleared.

    Business Rules Engine

    Business Rules Engine is used by BizTalk to load the current policies which are a collection of Rules from the Orchestration. These rules are kept separately as these could change from time to time. In our example above, this would be something like, during Olympics there could be certain relaxations in guidelines or certain promotions in effect. These change from time to time, and they are kept separate. This is the idea behind the Rule Store in BizTalk.

    Send Pipeline

    The "Send Pipelines" are just the opposite of the "Receive Pipelines" and they do operations like "Encoding" the message, or "Assembling" or "Signing" the message. This is like packing and sealing a package before we send it. Just like we have different types of packaging like bubble wrapping and cushion mailers, there could be different pipeline components at this stage.

    Send Ports

    Send Ports also handle transport like receive ports, but their direction is the reverse. Here, the message direction is from the Message Box to the destination. Send Ports can subscribe to a message directly from the Message Box, without passing through the orchestration. This is like having a package coming in from a certain shipper which has a prior clearance attached with it. This is called Content Based Routing (CBR).

    'BIZTALK > DEFINITION' 카테고리의 다른 글

    SOA와 EAI  (0) 2009.12.22
    EAI 연동방안의 차이점  (0) 2009.12.22
    EAI와 ERP의 차이점  (0) 2009.12.22
    순수(Pure-Play) BPM[WorkFlow BPM]과 EAI 기반 BPM 의 차이  (0) 2009.12.22
    EAI(Enterprise Application Integration)란?  (0) 2009.12.22