'SOA BPM'에 해당되는 글 22건

2009.04.01 삼보컴퓨터 EAI
2009.04.01 IDE(Integrated development environment)
2009.03.31 ESB (Enterprise Service Bus)
2009.03.31 ESB(Enterprise service bus)
2009.03.31 BAM(Business activity monitoring)
2009.03.31 SOA(Service-oriented architecture)
2009.03.31 COM(Component Object Model)
2009.03.31 EJB(Enterprise JavaBean)
2009.03.31 BPM & SOA(서비스 지향 아키텍처)를 통한 비즈니스 통합
2009.03.31 What is SOA? How to SOA?

삼보컴퓨터 EAI

SOA BPM 2009. 4. 1. 09:58

EAI

EAI는 기업 내의 다양한 애플리케이션들을 통합하기 위한 계획, 방법론 및 솔루션 등을 통틀어 가리킨다. 기업들은 오랜 동안 다양한 응용프로그램들과 데이터베이스를 사용해 왔다. 그러나 시간이 점차 흐르면서 기존 애플리케이션 외에 다른 여러 애플리케이션이 추가되었다. ERP, CRM, SCM, e비즈니스 솔루션, 인트라/엑스트라넷 등이 그것이다. 이처럼 서로 다른 기술들을 이용하는 애플리케이션이 추가되면서 이들이 서로 함께 묶여 움직일 필요가 커졌다. EAI는 IT인력들을 괴롭혀 온 엄청난 통합 작업을 자동화 시켜준다. EAI는 기업 내의 다양한 정보를 통합하고 더 나아가 전체 비즈니스 프로세스를 하나로 묶는다. 이를 통해 오른손이 하는 일을 왼손 뿐 아니라 머리, 발 등 모두가 알게 한다.

2000년 봄 삼보컴퓨터는 두 개의 중요한 IT 프로젝트에 신경이 바짝 곤두서 있었다. 데이터웨어하우스 구축작업과 생산실행시스템(Manufacturing Execution System) 구축 작업이 바로 그것이다. 특히 MES 구현은 삼보컴퓨터에게는 매우 중요한 작업이었다. MES는 PC가 생산되는 모든 과정을 지원하는 생산시스템으로서 시급히 해결해야 할 과제였다. MES를 갖추는 것은 삼보컴퓨터 내부적으로도 생산을 보다 합리적으로 또 과학적으로 관리하기 위해서 필요했지만 외부적인 요인도 있었다. 즉 HP와 같은 주요 고객들은 삼보컴퓨터가 MES같은 생산시스템을 갖추길 원했다. 신뢰할 수 있는 생산체계를 갖춘 PC 제조업체와 거래를 하고 싶어했기 때문이다. HP와 같은 고객 기업들은 자신이 주문한 PC가 얼마나 만들어졌고, 생산중이라면 어느 공정까지 와 있는지를 알고 싶어했다. 그것도 자신들이 원하는 때에 언제든지 말이다. 때문에 삼보컴퓨터는 시급히 MES 구축 프로젝트를 시작했다. 그러나 삼보컴퓨터는 MES 프로젝트를 시작하기 전에 또 다른 프로젝트가 숨어 있다는 것을 직관적으로 알 수 있었다.

EAI(Enterprise Application Integration) 프로젝트가 바로 그것이었다. 즉 이미 사용되고 있던 기간시스템인 ERP(SAP사의 R/3)와 MES를 연결하는 작업이 매우 중요하다는 것을 삼보컴퓨터는 잘 알고 있었다. 삼보컴퓨터는 지난 해 4월부터 안산에 있는 PC 제조공장을 대상으로 MES 프로젝트를 추진했다. 삼보컴퓨터는 컨실리움이라는 솔루션을 가지고 MES 프로젝트를 추진하면서 EAI 작업도 함께 실시했다. 삼보컴퓨터는 팁코소프트웨어사의 TIB/ActiveEnterprise라는 EAI 솔루션을 가지고 EAI프로젝트 추진했다.

EAI 프로젝트는 MES 프로젝트와 함께 추진되었다. 그리고 삼보컴퓨터는 MES 및 EAI 프로젝트를 마무리 지었다.

ERP와 MES 연결

삼보컴퓨터에게 ERP와 MES를 연결시키는 통합작업은 왜 그토록 중요한 일이었을까? 삼보컴퓨터의 MES와 EAI 프로젝트를 책임졌던 삼보정보컨설팅의 최영식 이사는 EAI는 우리가 생각한 것 이상으로 중요하게 대두되고 있다고 설명한다.

“예를 들어 PC를 생산하려면 BOM

(Bill of Material) 정보, 재고정보 등이 있어야 한다. 삼보컴퓨터의 경우 이러한 정보는 ERP시스템인 SAP사의 R/3에서 관리되고 있었다. 따라서 R/3에서 관리되는 BOM 정보, 재고정보 등을 MES로 가져오기 위해서는 둘 사이에 서로 이야기를 나눌 수 있어야 한다. 그런데 이 둘은 대화를 나눌 수 없다. 가령 하나는 영어를 구사한다면 다른 하나는 독일어로 이야기를 하고 있는 것이다. 둘 사이에 의사소통이 가능하도록 통역사가 필요했고 EAI가 바로 그 역할을 했다.”

EAI는 R/3가 말하는 것을 통역해서 MES가 알아 듣도록 한다. 그리고 MES가 말하는 것을 통역해서 R/3가 알아 들을 수 있게 하기도 한다. 즉 MES에서 R/3로 정보가 문제없이 흘러갈 수 있는 것이다. 예를 들어 삼보컴퓨터의 PC 제조 현장인 안산공장에서 어떤 종류의 PC를 몇 대나 만들었는지 하는 정보는 R/3에게도 알려줄 필요가 있다. 이러한 정보가 R/3로 가야 생산진도가 관리되고 비용도 산출할 수 있기 때문이다. EAI는 MES에 있는 ‘어떤 PC가 몇 대나 만들어졌다’ 하는 정보를 R/3가 알아 들을 수 있도록 번역해 전달해 주고 있는 것이다.

“이렇게 양방향 의사소통이 가능한 것이 미들웨어와 EAI의 (기술적인 측면에서의) 두드러진 차이점”이라고 PwC컨설팅 Emerging & Integration Technology 그룹의 정성규 이사는 설명한다.

물론 미들웨어와 EAI를 구분하는 보다 중요한 특징들은 다른 곳에 있다. EAI가 비즈니스 프로세스의 규칙을 지원하는 것이 바로 그것이다. 즉 적절한 비즈니스 프로세스를 정의하면 이 규칙에 따라 데이터를 통합할 수 있는 것이다.

삼보컴퓨터는 물론 EAI를 R/3와 MES만을 연결하는데 사용하지는 않는다. 삼보컴퓨터는 데이터웨어하우스도 구축되어 있기 때문에 MES와 데이터웨어하우스 사이에 다리를 놓거나 또 R/3와 데이터웨어하우스를 연결하는데도 EAI가 활용되고 있다. EAI라는 허브를 중심으로 통합이 필요한 애플리케이션들이 연결되는 것이다.

삼보정보컨설팅의 최영식 이사는 앞으로 삼보컴퓨터가 활용하게 될 애플리케이션들은 계속 증가할 것이라며 이때 EAI 역할은 더욱 커질 것이라고 강조한다.

“조만간 삼보컴퓨터는 CRM이나 e비즈니스 애플리케이션도 구현할 것이다. 이때 EAI는 삼보컴퓨터 내에 이미 존재하는 애플리케이션 및 데이터웨어하우스와 새롭게 도입되는 CRM, e비즈니스 애플리케이션들을 연결하는 중요한 역할을 하게 될 것이다.”

"기업내 애플리케이션 사이에 대화가 불가능했다. 하나는 영어를 구사한다면, 다른 하나는 독일어로 이야기를 하고 있는 것이다. 둘 사이에 의사소통이 가능하도록 통역사가 필요했고, EAI가 바로 그 역할을 했다."

- 최영식 삼보정보컨설팅 이사

본질

EAI의 본질은 오른손이 하는 일을 왼손도 알게 하는 것이다. 애플리케이션 사이의 통합은 이를 가능케 하며 EAI가 존재하는 이유도 바로 여기에 있다. EAI는 서로 다른 언어를 쓰고 있는 기업 내의 다양한 애플리케이션 (및 데이터베이스 플랫폼 등)을 서로 연결함으로써 정보를 쉽게 공유하게 만들고 비즈니스 프로세스를 통합시킨다.

EAI라는 세 글자 중에서 그냥 지나쳐서는 안 되는 것이 있는데 바로 애플리케이션이라는 단어이다. 애플리케이션이란 단어속에서 우리가 찾아야 하는 두개의 본질은 바로 정보이다. 그리고 애플리케이션 뒤에 숨어 있는 프로세스이다. EAI가 말하는 통합은 바로 조직 내에 존재하는 다양한 정보와 비즈니스 프로세스인 것이다. 즉, EAI는 조직 내에 흩어져 있는 모든 정보를 통합시켜 가치사슬 상의 필요한 곳에 뿌려 줄 수 있는 그 무엇으로 이해될 수 있다.(물론 비즈니스 프로세스 통합 측면에서 바라보는 것도 매우 중요하다)

이전까지 이러한 애플리케이션사이의 통합은 개별적인 프로그래밍 작업에 의해 이뤄져 왔다. “그러나 애플리케이션을 연결하기 위한 개별적인 인터페이스 작업은 하나의 재앙이었다”고 삼보정보컨설팅의 최영식 이사는 설명한다.

애플리케이션의 수가 많은 규모가 큰 기업의 경우 애플리케이션 A와 애플리케이션 B를 개별적으로 연결하는 다리놓기 작업(인터페이스 개발 작업)은 수 백에서 수 천번에 이를 수 있기 때문이다.

삼보정보컨설팅의 최영식 이사는 이러한 통합작업을 전화 단자함을 예로 들어 설명한다.

“파란색 빨간색 등 온갖 전화선이 정신없이 얽혀 있는 모습은 흡사 애플리케이션을 일대일로 연결하는 것과 유사하다. 만약 새로 전화기를 설치하기 위해 기존의 다른 전화선들을 모두 건드려야 한다면 어떻게 될까? 그러나 안타깝게도 이러한 모습은 바로 지금까지 IT 조직의 현주소다. 수작업을 통해 새로운 애플리케이션이 들어오면 다시 일대일로 애플리케이션들을 연결시켜왔던 것이다. 새로운 애플리케이션이 들어오면 이것을 다른 애플리케이션과 연결시키기 위해 기존의 다른 애플리케이션을 조금씩 다시 손봐야 했던 것이다.”

EAI는 IT 인력들을 괴롭혀 온 이러한 엄청난 통합 작업을 자동화 시켜준다. 기업 내 애플리케이션들은 EAI라는 파이프에 정보를 흘려보내고 이 정보들은 EAI라는 파이프를 따라 다른 애플리케이션으로 흘러간다. 새로운 애플리케이션이 들어 올 경우도 애플리케이션사이의 통합에 대해서는 고민할 필요가 없다. 새로운 애플리케이션에 EAI라는 파이프를 연결하기만 하면 되기 때문이다.

왜 EAI인가

그렇다면 기업들사이에서 EAI에 대한 요구가 급격히 증가한 이유는 무엇일까? 현대전자 반도체부문(현 하이닉스 반도체)에 있으면서 애플리케이션 통합업무를 해왔고 이제는 미라콤 아이앤씨(MES 및 EAI 솔루션/컨설팅 업체)에서 EAI 컨설팅을 담당하는 정윤식 부장은 그 이유를 e비즈니스의 확산으로 풀이한다.

“고객이 원하는 정보가 기업 내에 어디에 있는지 모르는 경우가 많다. 어디 있는지 안다고 해도 서로 다른 모습으로 존재한다. 고객들은 인터넷을 통해 자신이 주문한 제품이 얼마만큼 만들어졌고 또 어느 공정을 흐르고 있는지 알기 원한다. 이에 대답하기 위해서는 조직 내 모든 시스템이 한 몸처럼 통합되어 있어야 한다. 기업들의 EAI에 대한 요구가 높아지는 이유가 바로 여기에 있는 것이다.”

고객이 요구한 정보는 기업 내에서 하나의 모습으로 존재해야 한다. 그러나 적지 않은 경우, 같은 정보가 애플리케이션 마다 서로 다른 모습으로 존재하고 있는 것이 우리의 현실이다. EAI는 기업 내 존재하는 정보에 일관성을 유지해준다. 때문에 EAI의 필요성이 높아지고 있다.

물론 EAI에 대한 필요성은 SCM, CRM, e마켓플레이스, 데이터웨어하우스 등 기업이 활용하는 애플리케이션들이 증가함으로써 애플리케이션의 복잡도가 높아지기 때문에 더욱 커지고 있다. 새로운 애플리케이션이 도입될 경우, 기존 시스템과 통합되어 움직일 수 있는 준비가 되어 있지 않으면 새로운 애플리케이션은 가동될 수 없다. EAI는 새로운 애플리케이션이 보다 빨리 조직 내에서 돌아갈 수 있게 하기 때문에 중요하게 대두되고 있다.

우리는 ERP가 기업 내에 존재하는 시스템 사이의 통합 문제를 모두 해결해 줄 것이라고 믿었다. 그러나 ERP는 기업 내에 존재하는 IT의 전체 그림 중 하나의 조각(그러나 커다란 조각임에는 분명하다)에 불과하다. 기업 내에는 SAP사의 ERP외에도 시블사의 CRM, i2사의 SCM, 아리바사의 e마켓플레이스 솔루션 등이 서로 혼재되어 있다. 기업은 이들 사이에 서로 이야기할 수 있게 하는 무엇인가가 필요하고 이를 EAI라는 통합 도구가 도와주고 있는 것이다.

그림자들

그러나 EAI는 결코 쉬운 상대가 아니다. EAI는 우리가 생각한 것 이상으로 까다롭고 어려운 그 무엇이라고 전문가들은 지적한다. PwC컨설팅의 정성규 이사는 “EAI 프로젝트는 어떤 IT 프로젝트보다 CIO에게 리스크가 큰 작업이 될 수 있다”고 경고한다. 따라서 EAI의 밝은 측면 뿐 아니라 어두운 측면까지 살필 수 있는 눈이 CIO에게 절실히 요구되고 있다. 아직 우리에게 조금은 낯선 이 태어난 지 얼마 되지 않는 새로운 도구(EAI)를 성공적으로 도입하기 위해서 CIO들은 다음 사항을 살펴볼 필요가 있다.

1. 비즈니스 가치를 명확히 정의하라

CIO는 EAI를 통해 어떤 비즈니스 가치를 창출할 수 있는지 면밀히 검토해야 한다. PwC의 정성규 이사는 EAI 프로젝트를 추진하기 전에 CIO는 EAI를 통해 얻을 수 있는 비즈니스 효과가 무엇인지 자문해 볼 필요가 있다고 강조한다.

“대부분의 EAI 프로젝트는 비즈니스 측면보다는 기술적인 측면의 필요성에 의해 추진된다. 물론 기술적인 측면에서 EAI가 갖는 의미도 상당히 크다. 하지만 우리가 궁극적으로 바라봐야 하는 것은 EAI가 통합을 통해 어떤 비즈니스 가치를 창출할 수 있느냐 하는 것이다. 이러한 것에 대한 청사진 없이 단순히 기술적인 요구에 의해 프로젝트가 진행될 때는 그 효과가 한계를 갖기 쉽다.”

EAI는 애플리케이션 사이에 다리를 연결함으로써 기업 내 정보와 프로세스를 통합한다. 하지만 다리를 놓는 것 자체가 EAI의 궁극적인 목표가 될 수는 없다. 다리를 연결함으로써 발생시킬 수 있는 가치가 무엇인지를 먼저 명확히 정의하고 EAI 프로젝트가 진행된다면 그것이 가져올 효과는 단순히 기술적 측면에서 접근했을 때 보다 더욱 커질 수 있는 것이다. 그러나 많은 기업들은 EAI를 통해 무엇을 얻고자 하는지 자신들도 잘 모른 채 프로젝트를 추진하곤 한다.

PwC의 정성규 이사는 EAI를 통해 가치를 발생시킬 수 있는 비즈니스 사례를 만드는 것이 중요하다고 설명한다.

“CRM, SCM 등 일반적인 IT 프로젝트는 요구사항이나 효과를 정의하는데 크게 어려움이 없다. 그러나 EAI 프로젝트는 상대적으로 추상적인 프로젝트가 될 수 있다. 통합 그 자체가 갖는 의미(설사 이것이 간접적으로 미치는 영향은 크다고 할지라도)는 CFO나 CEO에게 크게 와 닿지 않을 수 있다. 따라 CIO는 통합을 통해 부가적으로 파생시킬 수 있는 비즈니스 가치를 만들고 발굴하기 위해 노력해야 한다.”

2. 프로세스 통합 작업임을 잊지 마라

기업들은 다양한 애플리케이션, 데이터베이스 플랫폼 등을 사용하고 있다. 기본적으로 EAI는 데이터를 통합해 기업 내의 다양한 이질적인 시스템사이에 정보가 마음대로 오갈 수 있도록 한다. 그러나 EAI가 궁극적으로 추구하는 것은 비즈니스 프로세스를 서로 연결시켜 주고 통합하는 것이다. EAI 프로젝트가 성공하지 못하는 주요 원인은 바로 이것이 (단순히 데이터를 다루는 일이라고만 생각하고) 비즈니스 프로세스를 다루는 일이라는 것을 잃고 있기 때문이다.

삼보컴퓨터의 EAI 프로젝트를 책임졌던 최영식 이사는 삼보컴퓨터가 EAI를 통해 ERP 시스템과 MES 시스템을 통합한다는 것은 단순히 정보를 한 몸처럼 주고 받는 것 이상이라고 설명한다.

“EAI는 ERP에서 진행된 프로세스가 MES에서 계속 진행될 수 있도록 다리 역할을 하는 것이다. ERP의 정보가 MES로 가는 것은 단순히 데이터 이동을 위해서가 아닌 어떠한 프로세스를 실행시키기 위해서다. EAI를 통해 두 개의 애플리케이션을 통합했다는 것은 서로 연결되어야 하는 프로세스를 하나로 통합했다는 것을 의미한다. EAI는 기업 내 틈이 벌어져 있는 프로세스를 접착제처럼 붙여주는 기능을 한다.”

물론 EAI를 단순히 데이터 통합측면에서 바라볼 수도 있다. 그러나 프로세스 통합측면에서 EAI를 도입하고자 한다면 프로젝트 초기에 프로세스에 대한 명확한 정의 및 문서화 작업이 반드시 면밀히 이뤄져야 한다. 이러한 작업이 불충분 할 경우 EAI 작업을 통해 무엇을 해야 하는지 우왕좌왕할 수 있으며 프로젝트 완료 후에도 성공 여부를 가늠하기 어렵다.

3. 일관된 통합 규칙을 가지고 프로젝트 진행하라

통합 프로젝트를 추진할 때 대부분의 기업들은 일관된 통합 규칙 아래서 프로젝트를 추진한다. 그러나 실제 통합 프로젝트를 진행하다 보면 미리 정해 놓은 정형화된 통합 규칙이 깨지는 경우가 적지 않다고 미라콤 아이앤씨의 정윤식 부장은 설명한다.

“한 시스템에서 A라는 정보가 다른 시스템에서는 AA일 경우 모든 정보를 반복하면 된다는 통합 규칙이 생긴다. 하지만 세세한 부분까지 모두 통합시키기 위해서 일관된 통합 규칙을 깨는 경우가 발생한다. 이 경우 많은 기업은 통일된 통합 규칙없이 개별적으로 정보를 변환하는 방법을 선택하게 되는데 이는 추후에 커다란 문제를 야기시킬 수 있다.”

통합 작업을 추진할 때 큰 흐름에 지장을 주지 않는 사소한 부분은 통합에서 제외시킬 수 있는 정치적 결단이 필요하다. 만약 이러한 결정을 CIO가 내리지 못한다면 EAI의 확장성이나 탄력성에 커다란 문제를 가져올 수 있다.

“통합에 대한 일관된 규칙없이 통합 작업이 추진되면 EAI 도구를 사용한다고 해도 별로 재미를 볼 수 없다. 새로운 애플리케이션이 도입 될 경우 통합을 위해 기타 다른 애플리케이션들을 손봐야 하는 경우가 발생할 수 있기 때문이다. EAI가 구현되어 있다면 어떤 애플리케이션이 들어와도 손쉽게 연결되어 정보가 서로 통합될 수 있어야 한다. 그러나 일관된 통합 규칙없이 EAI 작업이 진행된다면 이러한 기대는 할 수 없다.”

4. 환상을 버려라

EAI는 기업 내의 모든 통합 문제를 해결해 줄 수 있는 것처럼 스스로를 포장한다. 하지만 EAI는 아직은 덜 익은 사과이다. 기업 내의 통합 이슈를 모두 해결하기에는 개선해야 할 여지를 적지 않게 남겨두고 있다.(물론 EAI 도구들은 계속해서 기능을 강화하고 있고 스스로 진화하고 있다.)

PwC의 정성규 이사는 EAI 도구가 통합을 가능케 하는 만병통치약은 아니라는 것을 명심할 필요가 있다고 강조한다.

“EAI 솔루션의 핵심 중 하나는 어댑터나 컨넥터라고 말하는 부분이다. EAI 솔루션 업체들은 ERP패키지나 CRM 패키지 별로 어댑터나 컨텍터를 개발해서 통합을 지원한다고 설명한다. 그러나 EAI가 여러 애플리케이션을 완벽하게 지원하고 있지는 못하다.”

또한 EAI 솔루션을 제공한다고 다들 말하고 있지만 저마다 EAI를 바라보는 관점이 조금씩 다르다. 따라서 그 기능도 저마다 조금씩 다르다. CIO는 이러한 업체들 사이의 차이점을 면밀히 파악할 필요가 있다.

CIO들은 EAI 도구가 통합작업을 완벽하게 자동화해 주지는 못한다는 사실도 파악하고 있어야 한다. 즉 EAI 도구를 가지고도 통합을 위해서는 적지 않은 프로그래밍 작업을 해야 한다. 따라서 CIO들은 EAI 솔루션이 어느 정도 수준까지 통합을 자동화해주는지 파악해야 한다. 그리고 자동화해주지 못하는 나머지 프로그래밍 작업을 어느 수준까지 내부 IT인력이 해야 하는지 알고 있어야 한다.

EAI 프로젝트를 경험한 몇몇 CIO들은 이미 EAI가 기업이 요구하는 통합 이슈를 100% 지원하지 못한다는 것을 깨닫고 있다.

PwC의 정성규 이사는 최선이 아닌 차선의 선택을 해야 하는 현재의 상황이 CIO들에게는 어려움으로 작용할 수 있다고 설명한다.

“이러한 상황에서 중요한 것은 최적의 차선책을 찾는 것이다. EAI가 완벽하지 못하다는 것을 전제한 상황에서 자기 회사의 통합 문제를 풀어줄 가장 최선의 EAI 도구를 찾아야 한다. 예를 들어 우리 회사에서 돌아가고 있는 애플리케이션에 대한 컨넥터를 EAI 솔루션이 몇 개까지 지원하고 있는가를 살펴볼 필요가 있는 것이다.”

아울러 EAI 솔루션 업체가 지속적으로 제품과 서비스를 제공할 수 있는지에 대해서도 CIO들은 관심을 가져야 한다. EAI 솔루션 시장은 현재 절대 강자가 없는 춘추전국시대와도 같다. 때문에 EAI 솔루션업체사이의 인수 합병 가능성이 항상 존재하고 있다. EAI 솔루션업체사이의 인수 합병으로 인해 불이익을 받지 않기 위해서 이 부분에 대한 고려도 게을리해서는 안 된다.

5. 전문인력 많지 않다

ERP나 SCM이 초기에 그랬듯이 이제 새롭게 대두되고 있는 EAI 전문인력 부족 문제도 CIO에게는 하나의 해결 과제이다.

삼보컴퓨터 EAI 프로젝트를 책임졌던 최영식 이사도 EAI 전문 인력 문제가 하나의 도전사항이었다고 고백한다.

“인력 문제는 단순히 사람이 모자란다는 것보다는 다양한 경험과 노하우를 갖고 있는 인력이 부족하다는데 더욱 심각성이 크다.”

삼보컴퓨터는 이러한 상황에서 내부 IT 인력을 대상으로 EAI와 관련한 교육과 훈련을 심도있게 실시했다. 그리고 성공적으로 EAI 프로제트를 마칠 수 있었다. 그러나 모든 기업이 삼보컴퓨터와 같이 내부 교육과 훈련을 통해 EAI 프로젝트를 성공으로 이끌 수 있는 것은 아닐 것이다.

[출처] 삼보컴퓨터 EAI|작성자 ecobrain2000

EAI의 위험

EAI 프로젝트는 다른 IT 프로젝트와는 적지 않은 차이점을 가지고 있다. 즉, 보다 큰 위험을 내포하고 있는 것이다. EAI 프로젝트를 진행하다 보면 통합을 위해 다양한 애플리케이션을 건드리게 된다. 여러 애플리케이션에 대한 다양한 지식과 노하우 필요하다. 또한 EAI를 통해 비즈니스 측면에서 얻을 수 있는 비즈니스 케이스를 만들어야 하는 부담도 CIO는 져야 한다. EAI 프로젝트를 책임지고 있는 CIO의 고민은 여기서 그치지 않는다. 자기에게 맞는 EAI 도구를 선택하는 작업도 해야 하기 때문이다. 그러나 아직까지 EAI 도구는 덜 익은 사과처럼 만족한 만한 기능을 제공하지 못한다. 또한 EAI 프로젝트는 많은 경우 다른 IT 프로젝트와 함께 추진되곤 한다. 따라서 다른 프로젝트와 조율해가면서 작업을 진행해야 하는 것이다. EAI는 그것이 갖는 효과도 크지만 한편으론 CIO에게 또 다른 무거운 짐이 되고 있다.

사과 고르기

아직 덜 성숙되어 있는 EAI 도구 중에 자신에게 맞는 솔루션을 선택하는 것은 EAI 프로젝트 출발부터 CIO를 괴롭히는 일이 되고 있다. 전문가들은 자기에게 맞는 EAI 도구를 선택하기 위해 안정성, 확장성, 개발용이성, 일관된 규칙을 가지고 통합할 수 있는 능력, 모니터링 능력 등 여러 가지 기준을 제시하지만 CIO들에게 이러한 조언들이 얼마나 크게 피부에 와 닿을 지는 의문이다. 삼보컴퓨터의 EAI 프로젝트를 책임졌던 최영식 이사는 결국 EAI 도구 선택을 위해 실시되는 시범 프로젝트를 통해 최선의 선택을 할 수 밖에 없다고 설명한다.

“많은 기업들은 어떤 EAI 도구를 선택할 것인가를 판단하기 위해 실제 기업의 통합 이슈를 떼어내 작게 파일럿 프로젝트를 실시한다. 각각의 EAI 도구를 가지고 시범 프로젝트를 실시해 자기에게 맞는 도구를 찾아내는 것이다.”

CIO들은 결국 이 파일럿 프로젝트의 결과에 많은 부분을 의지해 EAI 도구를 선택할 수 밖에 없다. 하지만 이러한 파일럿 프로젝트 결과만을 가지고 EAI 도구 선택의 모든 것을 판가름 할 수는 없다. CIO들은 사과가 좀 더 익을 때까지 기다려야 하는 것일까? 아니면 좀 덜 익었다고 해도 지금 먹을 수 있는 사과 중 가장 최선의 것을 선택해야 할까?

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

IDE(Integrated development environment)

SOA BPM 2009. 4. 1. 09:44

Integrated development environment

An integrated development environment (IDE) also known as integrated design environment or integrated debugging environment is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of a:

Sometimes a version control system and various tools are integrated to simplify the construction of a GUI. Many modern IDEs also have a class browser, an object inspector, and a class hierarchy diagram, for use with object-oriented software development.^[1]

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

ESB (Enterprise Service Bus)

SOA BPM 2009. 3. 31. 18:50

I. ESB (Enterprise Service Bus)의 개요

가. ESB (Enterprise Service Bus)의 정의
      - ESB = EAI (Enterprise Application Integration) + 표준화 + 분산화
      - 비즈니스 내에서 서비스, 애플리케이션, 자원을 연결하고 통합하는 미들웨어 또는 인프라 : 이성몽
    - 비즈니스 단위들의 통합을 수월하게 하면서 이종의 플랫폼과 환경들을 잇는 가교 역할을 하는 인프라 : 이성몽
나. ESB (Enterprise Service Bus)가 주목 받은 이유
    - EAI에서 Hub and Spoke 통합방식의 한계점 발견
    - SOA의 핵심 필요 기능으로 중요성 증대

* 다른 사람의 정의 들

- 느슨하게 결합되었거나 결합되지 않은 구성 요소들 간에 중재적인 관계와 직접 통신을 지원하는 웹서비스 가 가능한 인프라 : Gartner Group

- ESB란 표시는 그 제품이 MOM과 웹서비스 프로토콜 모두를 지원하는 일종의 통합 미들웨어 제품

- 표준 기반 통합 백본, 통합 메시징, 웹서비스, 변환, 그리고 인텔리전트 라우팅 : Sonic Software

- 통신과 연결, 변환, 보안을 위한 표준화된 인터페이스를 구현하는 엔터프라이즈 플랫폼

- 쉽게 말해 웹스피어 MQ와 그 밖의 다른 웹스피어 브로커 그리고 통합 서버를 가지고 있다면 당신은 ESB를 가지고 있는 것 : Bob Sutor, IBM

- ESB는 벤더의 독자 기술을 판매하기 위한 일종의 마케팅 전술: 채펠 앤 어소시에이트 CEO

2. ESB (Enterprise Service Bus)의 중요성 및 개념도
가. ESB (Enterprise Service Bus)의 중요성
- 분산된 서비스 컴포넌트를 쉽게 통합 연동할 수 있어 신뢰성 있는 메시지 통신이 가능
- 각 레거시 시스템과의 연동을 위한 다양한 표준 프로토콜의 지원을 기본으로, 재사용 가능한 컴포넌트들을 조립함으로써 서비스 지향적인 기업 환경을 만들 수 있는 기반 제공
나. ESB (Enterprise Service Bus)의 개념도

3. ESB의 특징 및 구성 요소

가. ESB의 특징

- 다양한 시스템과 연동하기 위한 멀티 프로토콜 지원

- 느슨한 결합(loosely coupled)

- 소프트웨어 컴포넌트를 조합하여 서비스를 조립하는 BPM 지원

- 이벤트 지향적, 표준 지향적

나. ESB의 구성요소

① 어댑터 형태의 레거시 연동 컴포넌트

- ESB는 기본적으로 다양한 표준 프로토콜을 어댑터(Adapter) 형태로 지원해야 한다.

- 통합 개발 환경에서 플러거블(Pluggable)할 수 있도록 간단한 형태여야 한다.

② 메시지의 변환, 가공

- 데이터 포맷과 형태 등을 통합 개발 환경 등을 통해 자유롭게 변화하고 가공 한다.

③ BPM

- 다양한 시스템의 데이터와 애플리케이션과의 연동을 통해 하나의 서비스를 이용한다.

④ 컨트롤과 모니터링

- 여러 과정들은 통합적인 조작과 모니터링이 가능해야 한다.

- 모니터링의 대상: 어댑터 단에서의 진행되고 있는 프로세스의 상태 및 데이터 값

⑤ 통합개발환경

- 통합개발환경은 ESB에서 필요한 요소 중 하나이다.

주요 차이점

특징	전통적인 EAI	ESB
통합의 종류	어플리케이션 통합	서비스 통합, 서비스 호스팅
통합 방안	시스템별 어댑터 사용으로 복잡성 증가	표준 기술 사용한 단순 통합
표준	벤더 별 전송기술 상이	개방형 표준 (웹서비스)
통합형태	단단한 결합(Static, 1:1결합)	느슨한 결합(Dynamic, 1:N 결합)
비용	통합대상 시스템별 어댑터 구입 또는 개발로 지속적 비용 발생	동일 표준 기반이므로 추가 개발비용 절감, 비즈니스 로직 재사용을 통합 비용 절감
구현 아키텍처	집중형 (Hub & Spoke)	분산형 (Distributed)

ㅇ 주요 참고 자료
가. 참고 서적
- 유비쿼터스 경영정보 (이성몽, 운정미디어, 2006. 7)

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

ESB(Enterprise service bus)

SOA BPM 2009. 3. 31. 18:44

Enterprise service bus

From Wikipedia, the free encyclopedia

In computing, an enterprise service bus (ESB) refers to a software architecture construct typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards, which provide fundamental services for complex architectures via an event-driven and standards-based messaging engine (the bus).

An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

An ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. Although it is a common belief, an ESB is not necessarily web-services based^{[citation needed]}. An ESB should be standards-based and flexible, supporting many transport mediums. Based on EAI rather than SOA patterns, it tries to remove the coupling between the service called and the transport medium.

Most ESB providers now build ESBs to incorporate SOA principles and increase their sales.

[edit] What is an Enterprise Service Bus?

There is some disagreement on whether an enterprise service bus is an architectural style, a software product, or a group of software products. While use of an ESB certainly implies adherence to a particular architecture, the term "enterprise service bus" is almost always used to denote the software infrastructure that enables such an architecture.

An Enterprise Service Bus (ESB) brings flow-related concepts such as transformation and routing to a Service-Oriented Architecture. An ESB can also provide an abstraction for endpoints. This promotes flexibility in the transport layer and enables loose coupling and easy connection between services.

[edit] ESB Architecture

The word "bus" is a reference to the physical bus that carries bits between devices in a computer. The enterprise service bus serves an analogous function at a higher level of abstraction. In an enterprise architecture making use of an ESB, an application will communicate via the bus, which acts as a message broker between applications. The primary advantage of such an approach is that it reduces the number of point-to-point connections required to allow applications to communicate. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.

[edit] ESB as Software

In such a complex architecture, the ESB is the piece of software that lies between the business applications and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the bus. In order to achieve this objective, the bus must encapsulate the functionality offered by its component applications in a meaningful way. This is typically accomplished through the use of an enterprise message model. The message model defines a standard set of messages that the ESB will both transmit and receive. When the ESB receives a message, it routes the message to the appropriate application. Often, because the application was not built with the message model in mind, the ESB will have to transform the message into a legacy format that is understandable by the application. The software responsible for effecting these transformations is referred to as an adapter (analogous to a physical adapter). It is not widely agreed whether these adapters should be considered part of the ESB or not.

The connection between the enterprise message model and the functionality offered by the applications is crucial. If the message model does not completely encapsulate the applications' functionality, then other applications that desire that functionality will be forced to bypass the bus and invoke the applications directly. Doing so violates all of the principles outlined above, and negates many of the advantages of using an ESB.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

BAM(Business activity monitoring)

SOA BPM 2009. 3. 31. 13:25

Business activity monitoring

From Wikipedia, the free encyclopedia

(Redirected from Business Activity Monitoring)

Jump to: navigation, search

Business Activity Monitoring (BAM) is software that aids in monitoring of business activities, as those activities are implemented in computer systems.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

SOA(Service-oriented architecture)

SOA BPM 2009. 3. 31. 11:12

Service-oriented architecture

Layer interaction in the Service-oriented Architecture.

In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems package functionality as interoperable services. A SOA infrastructure allows different applications to exchange data with one another. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies that underlie applications^[1]. SOA separates functions into distinct units, or services^[2], which developers make accessible over a network in order that users can combine and reuse them in the production of applications^[3]. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. Many commentators^[who?] see SOA concepts as built upon and evolving from older concepts of distributed computing^[2]^[3] and modular programming.

[edit] SOA for Business Applications

A SOA.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

COM(Component Object Model)

SOA BPM 2009. 3. 31. 11:07

Component Object Model

Component Object Model (COM) is an interface standard for software componentry introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages. The term COM is often used in the software development industry as an umbrella term that encompasses the OLE, OLE Automation, ActiveX, COM+ and DCOM technologies.

The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one they were created in, even across machine boundaries. For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separate from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference-counting. Casting between different interfaces of an object is achieved through the QueryInterface() function. The preferred method of inheritance within COM is the creation of sub-objects to which method calls are delegated.

Although the interface standard has been implemented on several platforms, COM is primarily used with Microsoft Windows. For some applications, COM has been replaced at least to some extent by the Microsoft .NET framework, and support for Web Services through the Windows Communication Foundation (WCF). However, COM objects can still be used with all .NET languages without problems. Networked DCOM uses binary proprietary formats, while WCF encourages the use of XML-based SOAP messaging. COM is very similar to other component software interface standards, such as CORBA and Java Beans, although each has its own strengths and weaknesses. It is likely that the characteristics of COM make it most suitable for the development and deployment of desktop applications, for which it was originally designed.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

EJB(Enterprise JavaBean)

SOA BPM 2009. 3. 31. 11:04

Enterprise JavaBean

From Wikipedia, the free encyclopedia

Simple EJB2 Architecture

Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications.

The EJB specification is one of several Java APIs in the Java Platform, Enterprise Edition. EJB is a server-side model that encapsulates the business logic of an application. The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) 1999^[1] and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1) and JSR 220 (EJB 3.0).

The EJB specification intends to provide a standard way to implement the back-end 'business' code typically found in enterprise applications (as opposed to 'front-end' user-interface code). Such code was frequently found to reproduce the same types of problems, and it was found that solutions to these problems are often repeatedly re-implemented by programmers. Enterprise JavaBeans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.

Accordingly, the EJB specification details how an application server provides:

Persistence via the Java Persistence API (JPA)
Transaction processing
Concurrency control
Events using Java Message Service
Java Naming and directory services (JNDI)
Security ( Java Cryptography Extension (JCE) and JAAS )
Deployment of software components in an application server
Remote procedure calls using RMI-IIOP.
Exposing business methods as Web Services.

Additionally, the Enterprise JavaBean specification defines the roles played by the EJB container and the EJBs as well as how to deploy the EJBs in a container.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

BPM & SOA(서비스 지향 아키텍처)를 통한 비즈니스 통합

SOA BPM 2009. 3. 31. 10:25

변화에 대한 민첩성(Agility): 서비스 지향 아키텍처를 통한 비즈니스 통합

소개

비즈니스 프로세스 관리와 서비스 지향 접근법을 결합한 IT 관리는 비즈니스 통합을 통해 모든 프로세스 간 효율성과 자동화를 촉진시킵니다.

오늘날과 같이 빠르게 변화하는 비즈니스 환경에서 대다수 조직은 한 가지 공통되면서 일관된 과제에 직면해 있습니다. 그것은 날로 증가하 는 고객의 기대치를 만족시키고, 첨예한 경쟁 환경에서 경쟁력을 유지 하면서도 또 한편으로는 새로운 규칙과 규제를 준수할 수 있도록 기업 이 얼마나 변화에 민첩하게 대응할 수 있느냐입니다.

이에 대한 해답은 비즈니스 통합입니다. BPM(Business Process Management) 과 서비스 지향적 접근법(Service-oriented approach)을 결합한 IT 관리는 비즈니스 통합을 통해 모든 프로세스 간 효율성과 자동화를 촉진시킵니 다. 이것은 기존 IT 자산이 실제 비즈니스 프로세스를 지원함으로써 새 로운 IT 투자 결과를 최대화하는 데 집중합니다. 이 비즈니스 통합의 개념은 단순하지만 구현의 어려움은 그 동안의 사례를 통해 증명되었습 니다. 그러나 비즈니스와 IT를 동일한 기초에서 고려한 서비스 지향 아 키텍처(SOA) 기반의 접근법과 Oracle 솔루션 및 전문성을 결합한다면 이러한 어려움은 충분히 극복될 수 있습니다. 이 백서에 간단하게 소개 되는 전략을 채택하시면 큰 어려움 없이 단계적으로 보다 완전한 비즈 니스 통합으로 성공적인 전환을 가져올 수 있습니다.

과제

비즈니스 통합 유형은 일반적으로 두 가지 핵심 과제를 가지고 있습니다. 첫번째는 비즈니스와 IT 환경 간의 브리지(bridge)를 구축하는 것이며, 두번째는 이러한 브리지를 지원하는 유연하고 강력한 인프라를 제공하는 것입니다.

점점 더 많은 조직에서 그들의 복잡한 비즈니스 문제에 솔루션을 적용 시키는 툴을 IT에 도입하려고 합니다. 즉, 이것은 비즈니스 프로세스를 지원하는 데 필요한 구성요소를 유연하게 제공하는 것을 의미합니다. 그러나 이러한 비즈니스 통합 유형은 일반적으로 두 가지 핵심 과제를 가지고 있습니다. 첫번째는 비즈니스와 IT 환경 간의 브리지(bridge)를 구축하는 것이며, 두번째는 이러한 브리지를 지원하는 유연하고 강력한 인프라를 제공하는 것입니다. 조직에서는 일반적으로 상향식 또는 하향 식 접근법을 업무에 채택합니다. 이러한 접근법은 거의 성공적이지 못 했습니다. 하향식 접근법(Top-down approach)은 비즈니스 프로세스를 분 해하여 특정 컴퓨팅 작업으로 귀결시킵니다. 이러한 작업의 대부분은 기존 소프트웨어 기능과 유사성이 거의 없습니다. 반대로 상향식 접근 법(Bottom-down approach)은 보다 추상적인 컴퓨팅 작업에 기초하여 코히 어런트(coherent ) 비즈니스 프로세스와 거의 유사성이 없는 작업으로 귀 결됩니다. 더욱이 개별 작업을 연결하는 인프라가 융통성 없이 고정되 어 있기 때문에 비즈니스와 IT를 신속하게 적응시킬 수 없어 경쟁력이 떨어집니다.

해결방법

포레스트 리서치사(Forrester Research)는 SOA 및 BPM 간의 강력한 연결에 대해 발표했습니다. 포레스트 리서치사에서 최근에 실시한 조사에서 SOA를 구현 중이던 응답자의 92%가 BPM은 조직의 미래에 매우 중요하다가 답변했습니다.

BPM과 SOA는 조직의 비즈니스 부서에는 비즈니스 프로세스를 개념적으 로 적용시킨 툴을 제공하고, IT 부서에는 이러한 요구사항과 기존의 서비 스, 데이터 및 애플리케이션을 일치시킨 툴을 제공함으로써 비즈니스 통 합을 가능하게 합니다. BPM과 SOA는 서로 결합하여 비즈니스와 IT에 하 나로 통합된 작업 개념(work concept)을 제공합니다. 이것을 “Atomic Business Service”라고 합니다. 이 모델에서 비즈니스는 판별 가능하면서도 매우 세 밀한 비즈니스 서비스로 프로세스를 분석하고, IT는 기존 자산과 새로운 구성요소를 동일하게 구축합니다. 이렇게 하여 조직의 비즈니스 부서와 IT 부서, 두 사이드가 중간에서 만날 수 있도록 이끕니다. 뿐만 아니라 비 즈니스와 IT는 적응(adaptation)을 돕는 ESB(Enterprise Service Bus)라 불리는 유연한 백본으로 연결됩니다. 결과적으로 조직은 새로운 서비스를 신속하 게 추가할 수 있으며, 내부 서비스를 외부 서비스로 바꿀 수 있고, 이전 서비스를 최신 서비스로 전환하고, 서비스 시퀀스를 재정렬하고, 거버넌스 정책을 시행하며 서비스 실행을 모니터할 수 있는 유연한 인프라를 구축 할 수 있습니다.

구현

성공적인 비즈니스 통합을 위해서는 다음을 비롯한 완벽한 플랫폼이 필 요합니다.

BPM 제품군: BPM 제품을 통해 각 프로세스를 “스토리”로 표현 할 수 있습니다(예: 주문 이행).
Service-enabled 데이터 통합 인프라: 이와 같은 인프라를 통해 IT 직원이 필요한 “명사”를 제공할 수 있습니다(예: 고객, 제품).
Service-enabled 애플리케이션 통합 인프라: 이와 같은 인프라를 통해 IT 직원이 필요한 “동사”를 제공할 수 있습니다(예: 구입하 다, 배송하다).
집계기/ESB: 이것은 명사와 동사를 연결하여 원하는 “스토리” 를 만듭니다(그리고 회사에서 이 스토리를 지속적으로 편집할 수 있도록 허용합니다).

회사의 어느 부서에서 시작하느냐에 관계없이 SOA와 BPM을 결합하여 비즈니스 포트폴리오를 정상적으로 통합할 수 있습니다.

비즈니스 통합의 놀랄만한 이점은 엔터프라이즈의 상황과 요구에 따라 서로 다른 경로를 통해 구현할 수 있다는 점입니다. 예를 들어, 비즈니 스 업무 부서가 가시성(visibility), 제어(control), 민첩성(agility)을 향상시키 려는 노력을 추진한다면 이러한 조직은 BPM 소프트웨어를 사용하여 시 작할 수 있습니다. 그러나 현재 문제에서 이러한 기능이 가장 빠른 ROI(Rreturn on Investment )를 제공할 수 있다면 데이터 또는 애플리케이 션 통합을 사용하여 시작할 수도 있습니다. 마지막으로 ESB는 기존의 통합 프로젝트 간의 공통된 요구를 수행하는 인프라에서 조직의 첫 단 계를 표현한다고 할 수 있습니다.

회사의 어느 부서에서 시작하느냐에 관계없이 SOA와 BPM을 결합하여 비즈니스 포트폴리오를 정상적으로 통합할 수 있습니다. 하나의 크기로 모두에 맞출 필요가 없으며 고유한 경로로 모든 고객을 지원할 필요도 없습니다. Oracle은 기존의 인프라와 애플리케이션의 가치를 확장할 수 있는 포괄적인 제품 세트와 전문 기술을 제공합니다.

서비스 지향 아키텍처를 통한 비즈니스 통합

실제 Clive Finkelstein이 개발하고 James Martin이 정보 공학(information engineering) 의 개념을 대중화한 날로 거슬러 올라가면, 지난 25년간 기업들은 IT 자 산을 비즈니스 목표에 맞추려는 시도를 계속 해왔습니다. 작업에 대한 대부분의 초기 접근법은 현재의 비즈니스 모델을 분석하여 그들이 원하 는 IT 기능을 도출해내는 하향식 절차를 채택했습니다. 그 결과 “blank slate syndrome”이 기존 시스템의 기능과 거의 일치하지 않는 매우 특정 한 요구사항 목록을 만들어냈습니다. 따라서 약속된 조정(alignment)을 제공하는 유일한 방법은 소프트웨어 개발에서 대규모 투자를 하는 것이 었습니다. 물론 비즈니스 목표에 대한 변경사항은 새로운 성능과의 갭 과 또 다른 상당한 투자로 구성된 새로운 세트로 발전하게 되었습니다.

이러한 하향식 접근법의 제한때문에 많은 회사에서는 포인트 솔루션의 확산을 이끄는 상향식 접근법을 시도했습니다. 이러한 접근법의 문제점 은 전체 프로세스의 코히어런트 실행(coherent execution)을 거의 지원하지 않는 점과, 그 결과 나타나는 “stovepipe syndrome”입니다. 예를 들어, 지 역적으로 분산되어 있는 회사의 경우, 회사의 한 파트에서 다른 파트로 데이터를 교환할 때 어려움이 있습니다. 이것은 개별 프로젝트에서 통 합 툴을 사용하여 기존의 낮은 수준의 소프트웨어 기능을 당면한 비즈 니스 요구에 맞춘 추상적인 작업으로 조합하는 것을 의미합니다. 그리 고 이것은 결과적으로 약속된 조정을 제공하는 유일한 방법은 서로 다 른 통합 프로젝트(이러한 프로젝트의 각각은 결과적으로 새로운 스토브 파이프(stovepipe)가 됨)에 끝없이 투자하는 것을 의미합니다. 따라서 회 사는 일관된 비즈니스 모델링 상태에 도달하는 대신, 끝나지 않는 통합 프로젝트에 직면한다는 것을 알게 되었습니다.

SOA 기반 비즈니스 통합은 중요한 두 가지 혁신을 도입하여 이러한 문제를 해결합니다.- 첫번째는 비즈니스와 IT를 연결하는 개념적 작업 단위이고, 두번째는 여러 작업 단위를 유연하게 중재하는 백본입니다.

SOA 기반 비즈니스 통합은 중요한 두 가지 혁신을 도입하여 이러한 문제 를 해결합니다. 첫번째는 비즈니스와 IT를 연결하는 개념적 작업 단위 (Work unit)이고, 두번째는 여러 작업 단위를 유연하게 조정하는 백본입니다. 이 경우 통합된 작업 단위는 Atomic Business Service입니다. Atomic Business Service는 조직의 비즈니스와 IT 부서 모두에 중요한 개념입니다. 비즈니스 부서의 직원들에게 이 Atomic business service는 작은 부서(예: 지급 처리)가 현실 세계(brick-and-mortar)에 제공할 수 있는 작업에 해당하는 유사한 작업 의 컬렉션을 나타냅니다. IT 부서에서 이 Atomic business service는 하나의 애 플리케이션 모듈(예: 지급 프로세서)이 이전 클라이언트/서버 환경에 제공 할 수 있는 기능에 해당하는 관련 기능의 컬렉션을 나타냅니다.

비즈니스 측면에서 Atomic business service는 어떤 특별한 IT 수준의 아키텍 처나 설계를 두지 않고도 가능한 가장 낮은 수준의 서비스입니다. 그리고 IT 측면에서 Atomic business service는 어떤 특별한 비즈니스 수준의 프로세 스 흐름을 두지 않고도 가능한 가장 높은 수준의 서비스를 나타냅니다. 이러한 정의는 유연하여 회사와 업종에 따라 다양한 정의가 가능합니다. 예를 들어, 제조업체 회사인 경우 지급 처리(payment processing)를 Atomic business service로 고려할 수 있지만, 타사 지급 처리 회사에서는 atomic으 로서 더 낮은 수준의 추상적 개념을 포함할 수도 있습니다. 또한 금융 서 비스와 같이 고도의 정보 집약 산업에서는 건축회사와 같이 덜 정보 집 약적인 산업보다 더 세분화된 Atomic business service를 채택할 수 있습니다.

추상적 개념 수준의 이러한 유연성은 비즈니스 서비스의 장점이라고 할 수 있습니다. 패러다임을 깨지 않고도 회사마다 고유한 규칙을 개발하 고 이러한 규칙을 점진적으로 적응시킬 수 있습니다.

그림 1은 이러한 개념적 작업 단위가 비즈니스와 IT 간의 갭을 어떻게 연결하는지를 보여줍니다. 비즈니스는 비즈니스 프로세스 모델을 Atomic business service 계층을 향해 하향식으로 분석하는 반면, IT는 서비스 지향 통합을 사용하여 상향식으로 소프트웨어 자산을 집계합니다. 이렇게 하여 비즈니스와 IT가 중간에서 만나 필요한 Atomic business service의 일치된 뷰 를 협상합니다.

그림 1. Atomic business service에서의 통합

SOA는 비즈니스와 IT에 공통된 그라운드를 제공할뿐만 아니라, 배치된 솔루션에 패러다임을 깨지 않고도 바꿀 수 있는 유연성을 제공합니다.

SOA 기반 비즈니스 통합 다음의 두번째 혁신은 ESB입니다. ESB는 변화 하는 요구를 충족시킬 수 있도록 사용 가능한 서비스 포트폴리오를 지 속적으로 적응시키는 매커니즘을 제공합니다. 모든 환경에 맞는 완벽한 서비스 포트폴리오는 없습니다. 하지만 ESB는 구성 서비스에 대한 지속 적인 업데이트를 요구하는 대신, 서비스들 간에 적응할 수 있도록 조정 합니다. 예를 들어, 두 개의 서비스에서 약간 다른 형식의 메시지를 사 용할 경우 ESB는 이러한 두 형식을 서로 변환할 수 있도록 합니다. 또 는 하나의 영역에서의 비즈니스 변경사항으로 인해 새로운 버전의 서비 스가 필요할 경우, ESB는 기본 기능만 필요로 하는 요청은 이전 버전으 로 라우팅하고, 향상된 기능을 요구하는 요청은 새로운 버전으로 라우 팅합니다. 따라서 SOA는 비즈니스와 IT에 공통된 그라운드를 제공할뿐 만 아니라, 배치된 솔루션에 패러다임을 깨지 않고도 바꿀 수 있는 유 연성을 제공합니다.

서비스 지향 아케텍처 플랫폼

ESB가 SOA 기반 비즈니스 통합의 유일한 구성요소는 아니지만 ESB는 전체 플랫폼을 위한 백본 역할을 수행합니다. 그림 2는 SOA 플랫폼이 어떻게 보이고 작동되는지를 간략하게 전체적으로 보여줍니다.

비즈니스 통합 플랫폼은 프로세스 참가자와 기존 IT 자산 사이 에서 서로 조정합니다.
비즈니스 프로세스 관리 계층은 작업의 시퀀스를 지정하고, ESB를 통해 자동화된 지원을 제공하여 프로세스 참가자와 조정합니다.
애플리케이션 및 데이터 통합 계층은 필요할 경우 데이터와 기 능을 ESB를 통해 게시된 Atomic business service로 추출하여 기존 자산과 조정합니다.

그림 2. SOA 기반 비즈니스 통합

비즈니스 프로세스 관리

비즈니스 측면에서 비즈니스 통합 플랫폼의 가장 가시적인 부분은 비 즈니스 프로세스 관리 계층입니다. 이것은 프로세스 모델링, 실행 및 관리 구성요소를 제공합니다.

구성요소 모델링을 통해 비즈니스 분석가는 BPMN(Business Process Modeling Notation)과 같은 규칙을 사용하여 각 비즈니스 프로세스의 스토리를 작성 할 수 있습니다. 이 외에도 분석가가 프로세스 단계를 문서화할 수 있으며, 사용자가 해당 프로세스에 기여할 수 있는 방법을 설명하기 위해 사용자 인터페이스 화면을 목업(mock up)할 수 있습니다. 마지막으로 이러한 구성 요소 모델링은 작업 흐름을 자동과 수동으로 시뮬레이션할 수 있으므로 분석가가 최적화된 Atomic business service 컬렉션으로 스토리를 세분화할 수 있습니다.

구성요소 실행은 실행할 수 있는 지침으로 프로세스를 변환한 다음, ESB를 통해 필요한 Atomic business service를 호출합니다. 둘 다 작업을 실행하고 수동으로 예외를 처리하는 사용자에 대해 웹 기반 작업 영역 을 제공합니다. 구성요소 모니터링은 실시간 프로세스 흐름과 장기간 프로세스 척도를 추적함으로써 갑작스러운 위기나 진화하는 환경에 대 한 응답 시간을 최소화합니다. Oracle BPM Suite는 입증된 안전성과 가용 성 및 확장성을 갖춘 모델링, 실행 및 관리 구성요소를 모두 하나의 패 키지로 담아 제공합니다.

데이터 통합

비즈니스는 정보로 움직입니다. 정확하고 통합된 정보가 실시간으로 제 공된다면 조직은 보다 훌륭한 의사결정을 할 수 있습니다. 적시에 적소 에서 적합한 데이터를 제공하는 것은 정보의 실시간 흐름을 활성화하 는 핵심입니다.

적합한 데이터: 원래 사용 용도에 적합할 뿐만 아니라 정확하고 신뢰할 수 있는 데이터여야 합니다.
적합한 장소: 종합적인 정보 에코시스템은 여러 개의 운영 시스템 과 분석 시스템으로 구성됩니다. 각 시스템은 위치와 관계없이 다 른 시스템의 데이터를 활용하고 이점을 가져올 수 있어야 합니다.
적시 제공: 데이터는 금방 쓸모 없게 될 수 있습니다. 적시에 데 이터를 가져오지 못하는 의사결정 지원 시스템은 쓸모가 없습니 다. 예를 들어, 확정 기한 전에 주문 정보를 가져오지 못하는 배 송 애플리케이션은 효율성이 떨어집니다. 이 데이터의 원래 사용 용도에 적합한 대기 시간으로 적시에 데이터를 가져오는 기능은 오늘날 비즈니스에서 가장 중요한 과제 중 하나입니다.

Oracle은 Oracle Data Integration Suite를 제공합니다. 이 제품군은 적시 적 소에 적합한 데이터를 제공하는 포괄적인 데이터 통합 오퍼링입니다. Oracle Data Integration Suite는 데이터 변경 캡처, 데이터 품질, 데이터 프 로파일링 및 추출, 변환, 로드와 같은 모든 데이터 통합 요구를 완벽한 성능으로 처리합니다. Oracle Fusion Middleware와 함께 결합하여 사용할 경우, 엔드 투 엔드 IT 아키텍처의 중심 구성요소가 되며, 엔터프라이 즈 간에 최고 수준의 공유 데이터 서비스를 제공합니다.

ESB(Enterprise Service Bus)

전송(transport) 기능 외에 더 많은 것을 제공하는 ESB는 지능형 라우터, 변환기, 정책 실행 장비( policy enforcer), 집계기 및 모니터와 같은 역할 을 수행합니다. 서비스 간 메세지 흐름을 관리할 뿐만 아니라, 관리 및 보안 정책 적용 및 엔터프라이즈 간 SOA 거버넌스 지원을 가속화합니 다. 더 낮은 수준의 데이터와 애플리케이션 서비스 간 조정을 통해 ESB를 사용할 때 최적의 사용 방법을 채택합니다.

Oracle의 ESB 오퍼링에 포함되는 Oracle Service Bus는 엔터프라이즈 전반 의 서비스 네트워크에서 이기종 서비스, 레거시 애플리케이션, 패키지 애플리케이션 및 여러 ESB 인스턴스 간의 인터랙션을 연결, 조정 및 관리하기 위한 목적으로 설계되었습니다. Oracle Service Bus는 Oracle SOA Suite의 핵심 구성요소로서, 엔터프라이즈 전반의 향상된 SOA 거버넌스 를 위한 Oracle의 SOA 거버넌스 솔루션입니다. 최적의 사용 방법(best practices)에 대한 준수를 촉진합니다.

Service Repository 및 Registry

엔터프라이즈 내에 SOA 기반 비즈니스 통합 인프라가 성장할수록, 서 비스 개발 및 배치에 일관된 정책을 적용해야 하고, 모든 주요 사용자 가 이러한 서비스를 완벽하게 이해하는 것이 무엇보다도 중요합니다.

즉, 어떤 서비스가 사용 가능하고, 무엇을 하는지, 또 어떤 클라이언트 와 비즈니스 프로세스에서 서비스를 사용하고 있는지 등을 파악할 수 있어야 합니다.

비즈니스 분석가는 새로운 프로세스 설계에 어떤 Atomic business service가 사용 가능한지 알아야 합니다.
IT 설계자는 변경사항이 미치는 영향을 결정할 수 있게 어떤 서비스 종속성이 존재하는지를 알아야 합니다.
서비스 수준 계약 이행을 충족시키려면 운영 관리자가 서비스 사용과 로드 특성에 대해 정확하게 알고 있어야 합니다.

Oracle Enterprise Repository 및 Oracle Service Registry는 설계 시간과 런타 임 가시성을 비즈니스 통합 플랫폼 간 비즈니스 프로세스와 서비스로 제공함으로써 이러한 서비스 거버넌스 활동과 그 이상을 지원합니다.

채택 모델

비즈니스 통합 초창기에 회사들은 거대한 플랫폼을 하나의 광범위한 구현 프로젝트로서 채택해야 했습니다. 그러나 오늘날에는 SOA를 통 해 비즈니스와 IT를 동일한 기반에 놓을 수 있습니다. 따라서 엔터프 라이즈는 부분적인 통합에서 전체 통합으로 원활하게 전환할 수 있습 니다. 배치를 원활하게 확장해주는 이 기능은 개별 프로젝트에 대한 조직의 ROI를 실제로 높여줍니다. 단일 부서나 활동 간의 비용을 단지 상환하는 대신, 회사는 더 많은 비즈니스 처리 에콜로지에 맞출 수 있 습니다. 다음 하위 섹션에서 소개되는 이러한 접근법을 참고하시면 완 벽한 스케일의 비즈니스 통합으로의 전환을 채택할 수 있습니다.

통합의 시작점

종종 엔터프라이즈는 비즈니스 통합의 시작점으로서 성공적인 정보 시스템 통합 프로젝트를 사용합니다. 결과적으로 비즈니스에 대한 유연한 인프라의 이점을 전체로 확장할 수 있습니다.

종종 엔터프라이즈는 비즈니스 통합의 시작점으로서 성공적인 정보 시 스템 통합 프로젝트를 사용합니다. 결과적으로 비즈니스에 대한 유연 한 인프라의 이점을 전체로 확장할 수 있습니다. 이것의 한 예로 다이 내믹하고 프로세스가 집중된 주택자금 융자 산업이 있습니다. 서브프 라임 모기지를 만들고 펀딩하는 Oracle의 한 고객은 체납된 융자금을 보다 효과적으로 처리하고 유질 처분된 재산의 인벤토리를 줄이기를 원합니다. 이러한 목표를 달성하려면 보다 원활하게 서로 조정해주는 고객의 융자 서비스 지원 소프트웨어 모듈이 필요합니다. 이 고객의 경우, 국내외 500명의 직원들뿐만 아니라 파트너 위치에서 사용하는 최대 1000명의 사용자가 있기 때문에 유연성과 확장성을 결합한 통합 솔루션이 필요했습니다.

이 고객은 Oracle SOA Suite를 표준 미들웨어 플랫폼으로 선택한 후 내 부 및 파트너 모듈을 IT 중심 프로세스로 구성된 Atomic business service 로서 점진적으로 늘려가면서 조정하기 시작했습니다. 주택융자 산업에 서 효율성은 핵심 요소입니다. 따라서 Oracle SOA Suite를 통해 처리 시 간을 단축하고 재산 인벤토리를 낮춤으로써 이 고객은 상당한 이점을 볼 수 있었습니다.

이러한 이유 때문에 이 고객은 다가오는 대출 개시 프로젝트를 위한 BPM 계층으로 Oracle BPM Suite를 채택했습니다.

ESB로 시작

이미 SOA를 채택한 조직에서는 그들의 ESB를 비즈니스 통합의 시작점 으로 사용하고 있습니다. 일반적으로 이러한 조직은 액세스가 수월하면 서도 강력한 성능을 가진 BPM과 비즈니스 통합으로 구성된 아일랜드 (islands)를 가지고 있습니다. 이러한 조직들은 ESB를 전략적 비즈니스 요구사항이 아닌 수평적 인프라 요구사항으로 보는 경향이 있지만, 실 제 ESB 투자는 민첩성과 응답성의 형태로 상당한 비즈니스 이점을 제 공합니다.

적합한 ESB를 통해 이러한 아일랜드를 쉽고 신속하게 연결하고 갭을 메꿈으로써 비즈니스 통합을 달성합니다. 기존의 SOA 기반 기능을 가지고 있는 회사는 ESB를 견고한 투자로 만드는 이점이 있습니다.

이것은 ESB가 기능의 각 아일랜드에 대해 전사적 차원의 접근성을 제 공하기 때문입니다. 또한 보안 및 더 높은 가용성과 밀접한 서비스 수 준을 포함하여 지속적인 정책 적용 기능을 제공합니다. 적합한 ESB를 통해 이러한 아일랜드를 쉽고 신속하게 연결하고 갭을 메꿈으로써 비 즈니스 통합을 달성합니다. 기존의 SOA 기반 기능을 가지고 있는 회사 는 ESB를 견고한 투자로 만드는 이점이 있습니다.

BPM으로 시작

대다수 조직의 경우, 특히 주요 비즈니스 프로세스를 보다 효과적으로 실행하려는 조직은 비즈니스 프로세스 모델링이 비즈니스 통합의 명백 한 시작점으로서 그 역할을 합니다. 이러한 노력을 지원하고 유연하고 확장 가능한 접근법을 제공하기 위해 조직은 다음 단계로서 SOA 기반 비즈니스 통합 구성요소를 고려하고 있습니다.

패스너와 관련 도구를 판매하는 회사인 Screwfix는 보급 프로세스와 관 련하여 경험에 의해서 이전부터 내려온 과제가 있었습니다. 이전에 딜 러들은 종종 특정 제품이 모두 바닥이 나서 세일즈 손실과 배포 비용 이 늘어나는 결과로 나타났습니다. 잠재적 개선조치뿐만 아니라 기존의 모든 프로세스가 순전히 비즈니스 분석가의 머리에만 있었을 때는 이 러한 상황을 극복하기가 어렵습니다. Screwfix는 Oracle BPM Suite를 채택 함으로써 이러한 지식을 형식화하고 새로운 프로세스를 구체화할 수 있었습니다. 그 밖의 Oracle 비즈니스 통합 플랫폼을 사용하는 개념 증 명(proof of concept)을 통해 Screwfix가 기존의 데이터와 애플리케이션 자 산을 그들이 원하는 프로세스로 신속하게 조정할 수 있었음이 증명되 었습니다. 비즈니스 동기가 확고하다면 종합적인 접근법의 이점을 즉시 확인할 수 있습니다.

결론

기존의 BPM, 통합 및 ESB 이니셔티브를 활용함으로써 SOA 기반 비즈 니스 통합의 이점을 거의 바로 확인할 수 있습니다. 적당한 노력과 비 용만으로 조직의 비즈니스 조정을 대폭 개선하도록 함으로써 이러한 유형의 통합은 특정 기회에 응답하여 자연스럽게 그들의 비즈니스 통 합 포트폴리오를 성장하게 합니다.

결과적으로 회사 내에서 비즈니스 통합의 이점은 끝이 없습니다. 새로운 이니셔티브는 기존 비즈니스 서비스 포트폴리오를 자연스럽게 활용하기 를 원하고, 또 가치를 증가시키는 포트폴리오만 추가하기 때문에 비즈니 스(Atomic business service로부터 분석된 프로세스)와 IT(Atomic business service로 자산 집계) 둘 다 자연스러운 네트워크 효과를 가져올 수 있습 니다.

SOA 기반 비즈니스 통합에 접근하는 방법은 조직에 따라 여러 방법이 있지만, 완벽한 플랫폼을 위해서는 BPM, 애플리케이션 및 데이터 통합 과, 솔루션 공간의 어느 지점에서도 시작할 수 있도록 허용하는 ESB 구성요소가 반드시 포함되어야 합니다. Oracle은 업계 최고의 제품과 플 랙티스 및 사용자들을 통해 유연한 SOA 기반 비즈니스 통합 접근법을 이끌고 있습니다.

출처 : 한국 오라클

제공 : DB포탈사이트 DBguide.net

출처 : 한국 오라클

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

What is SOA? How to SOA?

SOA BPM 2009. 3. 31. 10:21

컴퓨터 시스템이 사용되면서부터, 각 시대의 기업 전략에 맞는 소프트웨어 아키텍쳐 존재하여 왔다. 초기 시대의 메인프레임에서는 기업의 업무를 전산화 하는데 목적이 맞춰졌고, 소프트웨어는 구조적 프로그래밍 (Structured Programming)으로 개발되었다.

그 후 개인 PC가 도입되면서 클라이언트 서버 시대 아키텍쳐가 도입되었고, 근래의 인터넷과 e비지니스 시대에서는EJB나 COM을 기반으로하는 컴포넌트 기반의 개발이 중심이 되었다.

그리고 지금의 IT 시스템들은 비즈니스의 급격한 변화를 수용할 수 있는 민첩성이 요구 되게 되었고, 이 요구를 충족시키기 위한 아키텍쳐가 서비스 지향 아키텍쳐 SOA 이다.

이번 강좌에서는 SOA가 무엇이고 어떻게 SOA를 진행할지에 대해서 간략히 살펴보도록 한다.

1. SOA의 기본 개념

SOA란, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐이다.

또한 기존의 시스템이 각각의 독립된 업무 시스템으로 개발되어왔던 반면 SOA는 기업의 전체 업무가 하나의 거대한 SOA시스템으로 구성이 된다.

이해를 돕기 위해 예를 들어보자, 자바 기술 기반으로 개발된 “고객 정보 시스템”과, 룰 엔진으로 구현된 “룰 엔진”, 메인프레임을 구현된 “계좌이체” 업무 등이 있다고 가정하자.

이 각각의 업무들은 각각의 목적에 따라서 따로 개발된것이고, 서로 연계가 불가능했다.

이 각각의 시스템의 기능들을 업무를 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페이스 (예를 들어 XML/HTTP, CORBA,SOAP)를 구현하여 외부로 서비스를 제공한다.

<그림 1 SOA의 개념 >

이렇게 제공된 서비스 인터페이스를 이용하여 “신용 대출” 이라는 새로운 업무를 구현할 때 새롭게 시스템을 신규 개발하는것등이 아니라 기존의 이미 제공되어 있는 서비스들을 조합하여, 하나의 업무를 구현할 수 있다. 이것이 SOA의 기본적인 개념이다.

SOA 자체는 새로운 개념은 아니다. 소프트웨어 개발에 있어서 계속해서 이야기 되어 왔던 “소프트웨어의 재사용성”과 “레고웨어 [주. 소프트웨어 모듈을 레고블럭처럼 재 사용성이 높은 단위로 구성한후, 애플리케이션을 마치 레고 블록을 조립해서 하나의 조립물을 만들듯이 제작하는 개념]” 의 연장성에 있는 것이다.

이런 SOA 개념과 구현된 프로젝트는 이미 1990년대부터 구현되어 왔고 존재되어 왔다. 그럼 지금에 와서야 SOA가 주목 받는 이유는 무었인가? 예전에 서비스 구축을 위한 표준 인터페이스에 대한 방안으로 제시되었던 CORBA등의 기술의 난이도가 높은 점이 문제가 되어 왔으나 현재에는 XML/HTTP나 SOAP 기반의 웹서비스 기술등의 등장으로 서비스의 구현의 기술 난이도 문제가 해결되었고,

e비즈니스 환경에서 기존 업무 환경을 전산화 하는데에만 목적이 맞춰져 있어서 각각의 업무별로 독립된 시스템의 형태로 개발이 되어, 이에 대한 통합이 필요하게 되었으며 [예를 들면 고객 정보를 매출 내용과 연계하여 판매 전략을 수립하는 경우 등] 급격한 비즈니스 환경의 변화에 따라 비즈니스의 요구를 민첩하게 IT시스템에 반영되어야할 필요성이 대두됨에 따라 이에 대한 대안으로 SOA가 대두 되었다.

앞에서도 설명하였지만 SOA는 크게 “서비스와 이를 조합하여 애플리케이션을 구성하는 것” 으로 구성된다. 지금부터 각 “서비스”와 “서비스를 구성하는 방법” 에 대해서 알아보도록 하자

2. 서비스란?

서비스란 “플랫폼에 종속되지 않는 표준 인터페이스(CORBA나 웹서비스) 를 통해서 기업의 업무를 표현한 Loosely coupled하고 상호 조합 가능한 소프트웨어 이다.”

현대의 SOA에서 서비스의 플랫폼 종속성은 SOAP기반의 웹서비스 또는 XML을 통해서 구현된다. 서비스를 표현하는데 있어서 가장 중요한 특징은 “기업의 업무를 표현한다”는 것이다. 즉 ‘임직원 정보 서비스’,’계좌 이체 서비스’와 같이 기업의 업무는 서비스로 정의할 수 있지만 ‘JNDI Lookup’, ‘SMTP 이메일 클라이언트’와 같은 비업무성 서비스는 존재할 수 없다.

(１) 서비스의 구성

서비스는 크게 3가지 요소로 구성된다.

- 서비스 인터페이스

- 서비스 규약

- 서비스의 구현체

< 그림 2서비스의 구조 >

서비스 인터페이스는 서비스내의 하나의 업무 기능을 이야기 한다.

즉 주문서비스라는 서비스가 있을 때, 이 서비스는 “상품 주문” 과 “주문 내용 조회”라는 인터페이스를 가진다. (EJB나 자바 오브젝트의 비즈니스 메서드를 생각하면 되지 않을까?)

그리고 이 서비스를 사용하기 위한 여러가지 규약들 데이터 포맷이나 변수형 서비스를 호출하기 위한 인자나 인터페이스 이름등이 정의되는 곳이 서비스 Contract이다.

이에 대한 실제 구현체가 Implementation다.

현대의 SOA에서는 대부분이 웹서비스를 표준 인터페이스로 사용하기 때문에 서비스 Contract는 WSDL로 정의된다.

(２)서비스의 특징

서비스는 몇가지 특성을 가지고 있는데, 그중 몇 가지 중요한 특성을 뽑아보면 다음과 같다.

Ÿ 수직적 분할 (Vertical Slicing)

수직적 분할이란 애플리케이션을 개발할 때 전체 애플리케이션을 여러 개의 서비스로 나누고 각각의 서비스를 독립적으로 개발하는 것을 이야기 한다.

이전의 소프트웨어 개발은 애플리케이션을 각 Data Layer, Business Logic,View Layer와 같이 수평적으로 분리하였다. 그러나 SOA에서는 각각의 서비스가 Data Layer,Business Logic,View에 대한 모듈을 모두 가지고 있고 그래서 각 서비스간의 의존성이 최소화 된다.

<그림 3 Vertical slicing의 개념 >

Ÿ Has standard interface

서비스가 제공하는 인터페이스는 표준 기술로 구현이 되어야 한다. 서비스를 사용하고자 하는 사람이 “서비스 규약”만을 가지고도 해당 서비스를 호출할 수 있어야 하며, 이는 해당 SOA시스템 내에서 플랫폼이나 기술에 종속되지 않아야 한다.

Ÿ Loosely Coupled

Vertical Slicing에서도 설명하였듯이 각 서비스 컴포넌트들은 다른 서비스에 대해서 의존성이 최소화 되어 있어서 서비스의 구현내용등을 변경하였을 때 다른 서비스가 이에 의해서 영향을 거의 받지 않는다.

Ÿ Composable

서비스 컴포넌트들은 서로 연결되어 조합된 형태의 하나의 애플리케이션을 구성해야 하기 때문에, 서비스간에 연결 및 조합이 가능해야 한다.

Ÿ Coarse grainned

서비스의 구성단위나 인테페이스의 단위는 업무 단위를 기본으로 한다. IT 개발 조직이 아니라 현업의 비즈니스 조직이라도 해당 서비스가 무엇이고 무슨 기능을 하는지 이해할 수 있어야 한다.

Ÿ Dicoverable

서비스에 대한 정보가 검색 가능해야 한다. SOA시스템의 규모가 증가함에 따라 서비스의 중복이 발생할 수 있고, 이를 방지하기 위해서 이미 구현된 서비스가 있는지를 검색할 수 있어야 하며, 검색 내용에는 서비스의 내용과 서비스에 대한 사용방법,권한,보안에 대한 정보들이 포함되어야 한다.

(３) 서비스의 종류

서비스를 그 기능에 따라서 5가지 정도로 나눠볼 수 있다.

일반적으로 우리가 지금까지 이야기 했던 서비스는 “비즈니스 서비스” 이다.

이 비즈니스 서비스는 말 그대로 비즈니스 적인 의미를 가지는 서비스로 SOA의 최소 단위가 되며, 비즈니스 로직을 구현한 “Task centric service”와 비즈니스 데이터를 대표하는 “Data centric service”로 분리된다. [주. EJB의 Session Bean과 Entity Bean 정도로 생각하면 된다.]

다음은 “Intermediary 서비스” 인데, 업무적인 기능을 가지는 것이 아니라 서비스들을 연결하는 데서 발생하는 차이점을 보안해주는 서비스 이다.

몇가지 예를 들어보자

기존의 백화점의 구매 프로세스가 존재하였다고 가정하자. 백화점의 업무 요건이 바뀌어서 일반고객과 VIP고객에 대한 구매 프로세스를 차별화 하였을 때, 고객의 요건에 따라 구매 프로세스를 서로 다르게 호출해야 한다. 이런 유형을 Routing 서비스라고 한다.

서비스에 들어오는 데이터 타입이 “구매자의 이름,구매액과 물품 목록” 이었는데, 서비스가 수정되면서 데이터 타입이 변화가 되었을 때 기존에 이 서비스를 호출하던 모든 서비스 소비자는 데이터 타입의 변경으로 모두 변경이 되어야 하며 이런 이유로 업무 변화에 유연하게 대처를 하지 못하는데, 이런 경우 구 데이터 타입을 새로운 데이터 타입으로 변화시켜주는 서비스가 있으면 유연하게 변화에 대처할 수 있다. 이런 형태의 서비스를 Transform 서비스라고 한다.

<그림 4 Routing 서비스 >

< 그림 5 Transform 서비스>

그 외에도 기존 서비스에 새로운 기능을 추가하는 Functional Adding서비스, Façade 기능을 구현한 서비스등을 그 예로 들 수 있다.

“Process centric 서비스” 는 비즈니스 서비스들을 조합하여 하나의 업무 프로세스를 구현해내는 서비스로, 주로 상태가 있는 (Stateful)를 구현하는데 이용이 된다.

“Application 서비스”는 Technical한 서비스 “트렌젝션 서비스”, “로깅 서비스”가 예가 된다. 지금까지 설명하면서 “서비스는 비즈니스적인 의미를 가진 컴포넌트 이며 트렌젝션 등은 서비스가 될 수 없다..” 라고 이야기를 했지만, 현실세계에서 이런 서비스가 나오지 않을 수 있는 보장이 있을까? 언제나 예외는 존재한다고 SOA에서 지극히 예외적인 서비스이다. 잘 설계된 SOA에서는 “Application 서비스”가 존재하지 않는다.

“Public enterprise 서비스”는 다른 회사나 다른 SOA시스템으로 제공되는 서비스이다. [은행의 대외계 업무 정도가 이에 해당한다.] 다른 서비스에 비해서 외부로 제공되는 서비스인 만큼 성능, 트렌젝션, 보안에 대한 깊은 고려가 필요하다.

3. SOA 아키텍쳐 모델

지금까지 “서비스가 무엇인가?” 에 대해서 알아보았다. 지금부터는 이 서비스들을 어떻게 조합하여 소프트웨어 시스템을 구성하는지, 구성 방법에 대해서 알아보도록 하자.

서비스의 구성 방법의 기업의 SOA 성숙도와 발전 정도에 따라 단계적으로 적용되어야 한다.

단계적인 발전 모델을 설명하기에 앞서서 “application frontend”에 대해서 설명하면, 서비스들이 사용되어 최종 사용자에게 보이는 곳이 application front end이다. 일반적인 웹사이트나 기업 포탈, X 인터넷 클라이언트, 4GL 클라이언트등이 될 수 있다.

(１)Fundamental SOA [통합]

가장 기본적인 형태의 SOA로, 비즈니스 서비스와 애플리케이션 서비스만 존재하며 이 서비스들의 조합들은 application front end에서 이루어 진다.

Fundamental SOA의 가장 큰 목적은 기존의 시스템을 각각 서비스화하는 것과 독립되었던 시스템들을 통합하여 하나의 시스템으로 운영한다는데 목적이 있다.

(２)Networked SOA [ 유연성과 통제 추가 ]

서비스화하여 통합된 SOA시스템은 시간이 갈 수 록 그 크기가 커지게 되고 서비스간의 호출은 관계는 날이 갈 수 록 복잡해진다. 그리고 서비스의 내용이 변경 또는 보강 되어 가면서 의존성에 의해서 서비스간에 수정이 필요한 경우가 발생한다. 이는 서비스의 변화를 어렵게 만들고 결과적으로 기업 업무에 대한 ‘경직성’ 을 유발하는데, 이를 해결하기 위해서 모든 서비스들을 중앙에 하나의 버스를 통해서 관리하여 서비스간 연결의 복잡도를 해소하고 Intermediary 서비스를 추가 함으로써, 서비스의 내용이 변경되었을 때 그 차이를 보강해줄 수 있어야 한다.

< 그림 6 Networked SOA 개념 >

이렇게 중앙에 버스 역할을 하는 것이 Enterprise Service Bus (ESB)이고, 여기에는 서비스에 대한 모니터링과, Intermediary 서비스 기능의 제공, 위치에 대한 투명성 제공을 통해서 기본적인 “통제”와 “유연성” 제공을 특징을 한다.

(３) Process Oriented SOA [ 민첩성의 추가 ]

기업의 업무프로세스가 자주 변화가 되고, IT 시스템이 이에 민첩하게 반응해야 하거나, SOA로 구현해야 하는 기업 업무들에 복잡한 업무 플로우가 존재할 경우 이 업무 프로세스들을 BPM기반으로 구현하는 SOA를 고려해볼 수 있다.

각 서비스를 조합하는 것을 BPM으로 구현함으로써, 업무의 조합이 별도의 코딩 없이 BPM툴로 이루어 지게 되고, 업무프로세스가 바뀌었을 때 BPM툴에서 업무프로세스를 조정하는 것만으로도 빠르게 비즈니스 조직의 요구에 대응하여 IT 시스템이 비즈니스 업무에 대한 민첩한 대응력을 확보할 수 있다.

또한 업무 조직과 기술 조직간의 의사 소통에 있어서도, 기존에는 업무조직은 EJB나 JAVA와 같은 기술적인 내용을 이해하지 못하였고, 기술 조직의 경우 업무에 대한 이해도가 낮았기 때문에 의사소통에 있어서 많은 문제를 유발하였는데, BPM을 도입할 경우, 이 BPM에서 사용되는 모든 서비스는 이미 “업무적인 의미를 가지는 컴포넌트”이기 때문에 IT조직과 업무 조직간에 의사 소통을 하는데 문제가 없으며, 특히 업무 프로세스의 경우 직접 업무 조직이 큰 흐름을 정의하고 IT조직이 구현화에 있어서 보강만 함으로써 빠르고 정확한 의사 소통을 이룰 수 있다.

BPM과 함께 생각할 수 있는 것이 BPA(Business Process Analysis) 와 BAM(Business Activity Monitoring) 이다. BPA는 실제 업무플로우를 BPM으로 구현하기 전에 업무팀에서 해당 업무 플로우에 대한 설계를 하고 이에 대한 시뮬레이션을 할 수 있는 Business Process 분석 설계 도구이다.

BPA를 통해서 현 업무팀에서 해당 업무프로세스를 정의하고, 작동 내용을 시뮬레이션 함으로써 보다 완성된 업무 프로세스를 얻을 수 있으며, 이렇게 설계된 업무는 IT 개발팀에 의해서 BPM으로 변환이 된다.

BPM으로 변환된 업무는 SOA 시스템에 반영되어 실제 운영이 되게 되고,

BAM이라는 비즈니스 프로세스 모니터링 도구를 이용하여 반영된 BPM에 대한 평가가 이루어진다. 이 평가를 기반으로 업무팀에서는 다시 BPA를 이용하여 해당 업무의 최적화를 수행하고 다시 이는 BPM으로 구현이되고.. 이러한 반복을 통해서 업무의 개선과 SOA시스템이 최적화를 이룰 수 있다.

<그림 7. BPA,BPM,BAM을 통한 업무 프로세스의 구현과 업무의 최적화 >

4. SOA 아키텍쳐 모델의 구현

앞에서 설명한 3단계 아키텍쳐를 실제로 구축하는데 있어서 고려할 사항이 있다.

(１) 서비스화

먼저 Fundamental SOA에서 가장 중요한 것은 기존의 시스템을 “서비스화” 시키는 것이다. 현재의 서비스 인터페이스는 대부분 SOAP 기반의 웹서비스를 사용하는데, 솔루션 중에는 이미 Legacy System에 대해서 웹서비스를 제공하는 “서비스 아답터”가 제공된다. (IWay社의 SAP, Siebel 아답터, BEA의 Tuxedo 웹서비스 아답터 SALT etc)

대부분의 서비스 아답터를 통해서 서비스화된 “기존 메서드”들은 비즈니스 적인 의미를 가지지 않는 Application 서비스가 될 가능성이 많다. 서비스화를 하기전에 기존 시스템에 기능등을 업무 단위의 Coarse grainned된 컴포넌트로 묶은후에 서비스화 하는 것이 좋다.

(２) 스펙과 범위

고려 사항중 하나가 트렌젝션이나 Reliable 메세징과 같은 웹서비스 스펙에 해당하는 문제이다. 현재 웹서비스의 확장 규약인 WS* (Webservice Extenstion)의 경우에는 트렌젝션이나 Reliable Messaging과 같은 기능들을 제공하고 있지만 문제는 서비스화를 시켜주는 솔루션에는 이에 대한 지원이 의무사항이 아니라는 것이다. 즉 트렌젝션 기능들을 웹서비스에서 지원하는 기능을 사용하려고 했다가 막상 해당 시스템의 웹서비스에서 트렌젝션 기능들을 지원하지 않아서 문제가 될 수 있다. 서비스를 정의할 때 어떻게 이런 기능들을 구현할지에 대한 고려가 앞서야 한다.

이런 서비스 구현에 있어서 유용하게 사용할 수 있는 것이 EAI이다. EAI는 시스템간의 통합을 목적으로 하는 솔루션으로, SOA는 다르게 Tightly Coupled 되고 비즈니스적인 통합이 아니라 IT 시스템간의 통합을 지원함으로써, SOA 통합에서 다루기 힘든 트렌젝션이나 보안에 대한 내용을 해결해준다.

[이 EAI 솔루션에도 IT 시스템간의 연계 흐름을 정의 하기 위해서 BPM이 사용되는데, 시스템간의 흐름과 업무 흐름을 분리하기 위해서 이를 각각 IC-BPM가 HC-BPM으로 구분하여 부른다.]

(３) 보안

보안에 대해서는 따로 길게 설명하지 않겠다. 암호화 선택할때는 전체 메시지를 암호화할지 메시지 내용중 일부만 암호화 할지가 결정해야 하며, 중앙에서 각 서비스에 대한 사용 권한과 계정에 대한 관리를 할 수 있는 솔루션을 구성할 필요가 있다.

(４) 모니터링

여러 시스템을 하나의 SOA 시스템에 구축한 만큼 각각의 서비스에 대한 모니터링과 성능 측정은 매우 중요한 요소로 작용한다. SOA 시스템을 구축할 때 미리 로깅과 모니터링 성능 측정에 대한 기능을 미리 구현할 필요가 있다.

(５) 서비스 검색

SOA 시스템에서 이미 개발된 서비스를 재사용하기 위해서 서비스를 검색할 수 있어야 하며, 서비스에 대한 메타 정보 (보안,과금체계 등에 대한 규약등)들도 검색할 수 있어야 한다. 웹서비스에서는 이를 UDDI로 구현한다.

(６) Application frontend

Application frontend는 최종 사용자에게 업무 기능을 제공하는 부분으로, 일반적인 웹 인터페이스를 이용할 수 도 있으며, Rich client의 개념을 웹에 도입한 AJAX 기반이나 Flex와 같은 X-Internet 솔루션을 사용할 수 도 있다.

단 SOA 시스템은 여러 시스템을 통합한것으로 여러 메뉴와 UI가 통합 되기 때문에 권한과 메뉴등에 대한 관리 기능이 필요하게 되며, 이는 Enterprise Portal (EP)솔루션등을 이용해서 쉽게 구현할 수 있다. 지금까지 설명한 SOA 아키텍쳐 구성을 하나의 그림으로 표현해보면 다음과 같다.

<그림 8 SOA 레퍼런스 아키텍쳐 >

지금까지 SOA가 무엇인지, 그를 구성하는 서비스의 개념과 서비스를 조합하여 SOA시스템을 구축하는 방법에 대해서 알아보았다.

그렇다면 실제로 SOA 프로젝트를 수행하는데 있어서 어떻게 SOA 시스템을 구축하며 프로젝트를 진행해야 할까? 아래부터는 SOA의 수행 방법론에 대해서 알아보도록 하자.

5. SOA 수행 방법론

SOA 시스템은 기존의 시스템과는 다르게 기업에 업무별로 개개별 시스템이 존재하는 것이 아니라, 이러한 개개별 시스템을 통합하여 하나의 거대한 IT 운영 플랫폼을 구축하는데 있다. 이에 따라 SOA 시스템을 수행 하는 방법도 역시 차이가 나는데, 기업의 전략, 비용의 집행방법, 팀의 통제, 프로젝트 관리 방법을 기준으로 하나씩 알아보도록 하자

(１) 기업의 전략

IT 시스템은 기본적으로 기업 업무에 대한 반영이다. 그래서 SOA시스템을 통해서 제공하고자 하는 기능은 기업의 전략에서부터 파생된다.예를 들어 기업 경영 전략이

2004년 매출 증대

2005년 고객 만족 실현

2006년 브랜드 이미지 관리

와 같다면, 이를 지원하기 위해서 IT시스템의 구현 전략을 다음과 같은 것들이 될 수 있다.

2004년 매출 내용 전산화

2005년 CRM 도입을 통한 고객 정보 수집과 매출 내용을 기반으로 고객 패턴 추출

2006년 수집된 고객 정보를 토대로 마케팅 집중

즉 SOA의 수행은 기업의 경영 전략에 따라서 수행되며, 성공적인 SOA를 위해서는 해당 단계에서 기업의 핵심 업무를 SOA화 하는 것이 필요하다.

또한 기업의 IT전략은 예전처럼 각각의 단위 시스템을 개발하는 것이 아니라 기업의 전략을 IT화하여 구현한 SOA시스템을 기업의 발전에 따라서 계속 반영 및 변화 시켜나가기 때문에 기존 IT전략에 비해서 좀더 장기적인 전략을 필요로 한다.

(２) 비용의 집행

SOA 시스템은 비용 집행에 대한 고려가 필요하다. 기존 IT시스템은 단위 시스템에 대한 개발 프로젝트에 소요되는 비용만 예상하여 집행하면 되었지만, SOA 계속해서 발전해 나가는 시스템이고 한 시스템에 기능이 추가 되기 때문에 비용 집행 방식이 다르다.

SOA 시스템의 경우 초기에 SOA에 필요한 인프라의 구축 (ESB,BPM,모니터링,보안 인증,UDDI 등)에 비용이 많이 소요되기 때문에 초기 투자 비용이 기존의 IT 시스템 보다는 높아진다.

< 그림 9 SOA의 비용 집행 방법 >

그러나 위의 그림에서와 같이 계속해서 업무를 추가해나감에 따라 새로운 업무가 완전히 새롭게 구성이 되는 것이 아니라 앞단계에서 개발하였던 서비스들을 다시 재 사용되기 때문에 개발 비용은 지속적으로 감소하게 되고, 기능이 부족한 서비스들은 계속해서 대체 되면서 안정적으로 유지 되기 때문에 시간이 갈 수 록 소요 비용은 감소하게 된다.

(３) 제어와 통제

SOA 시스템이 거대화해짐에 따라 SOA 시스템에 대한 중앙 관리 및 통제 제어가 필요하게 된다. 어느 서비스부터 개발해야 할것인지, 이번 기간내에 진행해야할 SOA범위, 각 개발에 대한 표준화, 자금 조달 계획등을 수행해야 하며 이를 통제하는 조직이 필요하다. 이러한 통제를 Goverance라고 하는데,

이 통제를 실시하는 Governace 조직에서 하는 일은 다음과 같다.

- SOA 시스템에 대한 정책 수립 및 표준화 - Standard

- SOA 관련 기술 전파 및 가이드 - Evangelist

- SOA 구축 계획 수립 및 실행 (로드맵)- Strategy

- 자금 조달 및 집행 계획

- 업무 분석 및 설계

- 문화 변화  IT조직과 비즈니스 협업 조직의 협업문화 개발

- 모범사례 수집과 배포

여기에는 여러가지 통제 모델을 도입할 수 있는데, 운영 환경상에 서비스의 개발 배포 모니터링을 위한 통제 모델이다.

<그림 10 SOA 제어 통제 모델 예시 >

중앙 통제 조직은 실 개발 조직인 IT 조직과 비즈니스 조직간의 중계 역할을 하게 되며, 비즈니스 조직으로부터 전략과 요구 사항을 받아 실제 구현 조직에 전달을 하며

각 개발 조직에서 개발된 내용들에 대한 검증 및 배포 작업과 SOA 플랫폼에 대한 운영 및 모니터링 통제를 실시 한다.

이외에도 CVS등을 이용한 소스의 통제, apache maven과 같은 도구를 이용한 빌드의 관리, 일일 빌드 정책, 개발 방법론등도 이 “제어와 통제”에 해당한다.

(４) 프로젝트 관리

SOA의 프로젝트 진행에 있어서 특이한 점은 “반복적인 개발(Iterative Development)”과 “점진적인 개발(Incremental Development)”이다. 한번에 SOA 전체 시스템을 개발하는 것이 아니라 중요 업무를 먼저 개발한후에 반복적으로 업무에 대한 개선 작업을 병행하고, 점차적을 필요한 기능을 추가해나가는 모델이다.

또한 SOA의 프로젝트 개발 관리는 앞에서 설명 했던 Thin Thread Model의 개발 방식을 준수 하면 좀 더 좋은 효과를 볼 수 있다.

6. 결론

지금까지 SOA가 무엇인지, SOA를 구성하는 서비스의 형태와 특징은 어떠한지 그리고 SOA 프로젝트를 수행하는 몇가지 권고 방안에 대해서 살펴보았다.

SOA는 ESB나 BPM같은 솔루션을 제외하고라도 이미 서비스의 개념과 서비스 인터페이스의 개념을 도입하여 개발되는 사례가 많다. 특히 AJAX와 X 인터넷의 등장으로 SOA 기반의 시스템 도입은 가속화 되어갈 전망이다.

여기서 중요한점은 SOA의 개념이 무엇인지를 명확하게 이해하고, 현재 기업에서 필요한 SOA의 단계를 파악하여 적절한 수준의 SOA를 도입하고, 이 SOA 시스템을 장기적으로 발전 시켜나갈 수 있는 장기적인 전략과 이를 수행할 수 있는 제어와 통제 모델 (Governance)를 구축하는 것이 중요하다.

이올린에 북마크하기(0)

이올린에 추천하기(0)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Posted by 조대협

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

'SOA BPM'에 해당되는 글 22건

Integrated development environment

Enterprise service bus

From Wikipedia, the free encyclopedia

[edit] What is an Enterprise Service Bus?

[edit] ESB Architecture

[edit] ESB as Software

Business activity monitoring

From Wikipedia, the free encyclopedia

Service-oriented architecture

[edit] SOA for Business Applications

Component Object Model

Enterprise JavaBean

From Wikipedia, the free encyclopedia

1. SOA의 기본 개념

(１) 서비스의 구성

(２)서비스의 특징

(３) 서비스의 종류

3. SOA 아키텍쳐 모델

(１)Fundamental SOA [통합]

(２)Networked SOA [ 유연성과 통제 추가 ]

(３) Process Oriented SOA [ 민첩성의 추가 ]

4. SOA 아키텍쳐 모델의 구현

(１) 서비스화

(２) 스펙과 범위

(３) 보안

(４) 모니터링

(５) 서비스 검색

(６) Application frontend

5. SOA 수행 방법론

(１) 기업의 전략

(２) 비용의 집행

(３) 제어와 통제

(４) 프로젝트 관리

카테고리

태그목록

최근에 받은 트랙백

글 보관함

링크

파란실버라이트

LATEST FROM OUR BLOG

LATEST COMMENTS

BLOG VISITORS

티스토리툴바