“
[ 구체화된 기술 구현 ]
1) 서비스 가능화 계층 기술
서비스 가능화 계층에서 사용된 서비스 가능화 기술은, 기존 레거시 시스템의 기능을 서비스화 해주기 위한 ‘어댑터’와, 여러 형태로 저장된 데이터들을 서비스 기능 형태로 변환해주는 ‘데이터 서비스’ 기술이 그 주류를 이루어 왔다. 또한 각각의 분리된 시스템 업무를 묶어서 하나의 서비스 업무로 변환하기 위해서 시스템간의 통합이 필요하게 되었는데, 이를 위해서는 EAI(Enterprise Application Integration)기술이 사용되었다.
2008년의 서비스 가능화 계층 기술에서 눈 여겨 볼만한 기술적인 이슈는 SCA(Service Component Architecture)이다. SCA는 소프트웨어를 개발함에 있어서 각각의 서비스 컴포넌트로 다루어 이러한 서비스들을 조합하여 플랫폼에 중립적인 서비스로 재조합 한다는데 의미를 두는데, 특히 이 기술의 경우에는 기존의 SOA와는 다르게 명시적으로 WEB 2.0에 대한 프로토콜(RSS, ATOM, JSON, Hessian)등을 폭 넓게 지원하여 좀더 개방적인 서비스 가능화 기능을 제공한다는 것이다. SCA를 통해서 서비스 자체에 대한 생성에 필요한 통합 기능이 증대될 것이며, 서비스 가능화 계층에 필요한 ‘어댑터’, ‘데이터 서비스’, ‘EAI’ 솔루션들은 아직까지 몇몇 선두 SOA업체만이 보유하고 있기 때문에, SOA를 지향하는 솔루션 업체라면 이 기술 계층을 마련하기 위한 노력들이 뒤따를 것이다. 이미 이러한 솔루션을 가지고 있는 기업들의 경우에는 이 기술들의 성숙도를 높이는데 포커싱이 될 것이다.
2)서비스 허브 계층 기술
서비스 허브 계층은 SOA에서 흔히 이야기하는 ESB(Enterprise Service Bus)으로 대변되었던 한해였다. 이 서비스 허브 계층을 통해서 각각 다른 형태로 존재하는 시스템들이 통일화된 인터페이스를 가지고, 각각 분리된 시스템들이 비즈니스 업무 단위로 통합 되면서 하나의 서비스로 형태가 변화 된다. 즉 서비스 허브 계층에 대한 요구 사항이 기존의 유연성의 증대와 중앙 집중화된 버스 방식에 더해서, 분리된 시스템 업무간의 통합 기능이 추가됐다. 기존의 EAI 솔루션을 통해서 수행되던 시스템 통합 기능이 서비스 허브 계층으로 올라오면서 SOA에 적절한 형태(웹서비스의 지원, ESB와의 통합성)로 변화되면서 서비스 허브에 통합되도록 진행되고 있다. EAI 솔루션과 ESB 솔루션간의 통합성 문제와, ESB 솔루션을 사용할 때, 시스템 통합에 대한 요건이 필수 불가결하게 발생하기 때문에, 이에 대한 기능이 흡수 통합되는 모델이다. 특히 SOA 모델에서 자주 언급되는것은 프로세스에 대한 이야기에서 ‘프로세스의 주체와 목적이 누구인가?’이다. EAI와 BPM에 각각의 프로세스가 있었고 두개의 프로세스의 존재로 인해서 많은 혼동을 초래하였다. 이러한 프로세스들은 크게 비즈니스 사용자 위주의 사용자 프로세스(Human centric process)와, 시스템 통합에 필요한 시스템 프로세스(System integration process)로 나뉘고, 이를 각각 ‘BPM’과 ‘EAI의 프로세스’로 분리되었으며, 이 시스템 프로세스가 서비스 허브 계층에 통폐합되는 형태로 변화 될 것이다.
3)서비스 조합 계층 기술
서비스 허브 계층에 의해서 제공되는 서비스는 전통적인 SOA에서는 사용자 애플리케이션에서 직접적으로 조합하여 사용하거나 프로세스가 있는 업무의 경우에는 BPM을 사용하는 절차로 가이드돼 왔다. 여기에 BPA, BAM을 통한 비즈니스 프로세스의 설계와 모니터링을 통한 프로세스 개선에 목적이 맞춰져 왔으나, 실제 업무에서 BPM이 필요한 경우는 복잡한 업무 프로세스가 존재하는 경우이고, BPM을 사용할 수 있는 수준의 SOA 성숙 수준까지 시스템이 발전하기 전까지는 각각의 서비스들을 애플리케이션에서 조합해서 사용하는 수준인데, 이 역시 별다른 기술적인 대안이 존재하지 않았다. 이에 대한 대안으로 제시될 수 있는 것이 SCA이다. 앞에서도 설명했듯이 SCA는 컴포넌트에 대한 조합 기능을 제공하기 때문에, 상태나 장기적인 프로세스를 갖는 업무가 아닌 일반적인 업무 조합에서는 SCA를 통해서 충분하게 조합이 가능하게 된다. 이렇게 조합된 업무들은 사용자 인터페이스 (UI)를 통해서 사용자들에게 제공이 될 것이다. 업무별 또는 조직이나 사용자별의 업무 제공 UI를 엔터프라이즈 포털(EP)로 제공되어 왔던 것에 더해서 WEB 2.0의 개념을 도입한 POA의 개념으로 업무에 대한 서비스가 사용자에게 제공될 것이다.
POA란(Participant Oriented Architecture)의 약자로, 사용자 참여 중심의 아키텍처를 이야기한다. ‘공유하지 않으면 망한다’ 라는 말이 있듯이 현재 e-비즈니스 환경은 위키피디아나 블로그 등으로 대변되는 참여 중심의 WEB 2.0 환경으로 변화하고 있다. 마찬가지로 기업의 비즈니스 환경 역시 공유와 참여가 필요로 하게 되는데, 서비스화 된 업무들을 OPEN API 형태로 외부에 제공하거나 또는 부서별이나 개인별로 각각의 업무에 맞춰서 워크플레이스를 Mash-up(매쉬업)을 통해서 조합하게 된다. 기업의 다양한 업무 요건에 대한 대응을 더 이상 IT 부서에만 일임하는 것이 아니라, IT 부서는 업무를 위한 컴포넌트를 제공하고, 실제 현업에서 구성할 수 있는 형태의 개방성을 부여하는 기능이 제공될 것이다. 또한 태그 방식의 검색 등을 통해서 기업내에 흩어져 있는 자산과 서비스들에 대한 사용성이 높아지게 될 것이고, 이는 기업내의 지식과 자산의 공유를 가속화시킬 것이다.
[ 2008년 SOA의 변화 ]
2007년까지는 SOA의 개념이 도입되고 정리되는 기간이었고, 기업에서는 이런 개념들을 관측하고 평가해왔으며, 발빠른 업체는 SOA의 도입을 시작하였다. 2008년에는 SOA의 관련 기술이 성숙단계에 들어서고 기업들 역시 적극적으로 SOA의 도입을 준비할 것이다. 2007년에 진행되었던 SOA의 경험들을 바탕 삼아 벤더에서 제공하는 SOA기술들은 개념으로만 떠드는 SOA가 아니라 고객의 요구사항을 충분히 반영한 실용주의성의 사상과 솔루션으로 발전되어서 부족한 기술이나 쓸모 없는 기술은 도태되고 필요한 사상이나 기술들은 점점 더 진화되는 한해가 될 것이다. 또한 오픈소스 진영을 중심으로 발전한 WEB 2.0 관련 기술과 참여 공유의 사상은 기업의 SOA 시스템의 사상에 급속하게 녹아들면서 POA라는 이름으로 영향을 줄 것이다.
특히 현대의 기업의 IT부서는 예전과는 달리 ROI가 적거나 리스크가 높은 기술에 대해서는 점점 도입을 꺼리고 적극적인 검증을 통한 실용적이고 합리적인 경향이 높아졌기 때문에, 아직 SOA 기술에 진입하지 않은 기업은 SOA를 적극적으로 검토하는 한해가 될 것이고, 이미 SOA 기술에 진입한 발빠른 업체들은 다른 기업보다 앞서서 자사의 SOA 모델을 성숙시켜가고, 비즈니스 모델에 적용해 나가면서 빠르게 변하는 업무 환경에 빠르고 유연하게 대응할 수 있는 IT 시스템들을 갖추게 될 것이다.
“ |
