블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

기업에서 마이크로 블로그의 도입

지금까지 마이크로 블로그에 대해서 알아보았다. 그러면 이 마이크로 블로그 시스템을 기업에 어떻게 적용할 수 있을까

기업 내부 협업 플랫폼으로써의 마이크로 블로그

먼저 기업 내부의 협업 플랫폼으로써 마이크로 블로그를 도입한다면 어떤 기대 효과를 얻을 수 있을지 살펴본다

개인 브랜드 개발

트윗 메시지의 포스팅의 질은 개인의 브랜드와 직결된다. 전문성이 많은 포스트나 현재의 일 진행 상황을 자세하게 기록하면서 개인의 브랜드 가치를 향상 시킬 수 있으며, 특정화된 브랜드는 조직입장에서 업무의 효율성이 높은 직원을 선별해내고, 조직내에서 전문성을 가지고 있는 사람을 쉽게 찾을 수 있게 한다

리스크 조기 감지

마이크로 블로그 내의 RT Hash Tag를 분석함으로써 현재 회사내의 트렌드를 감지할 수 있으며, 이를 통해서 특정 Risk 요인이 있을 경우에 조기에 발견할 수 있는 일종의 사내 조기 경보기와 같은 역할이 가능하다

전문가와 네트워크 구축

실제로 기업의 규모가 커지면 커질수록 많은 비즈니스 부서가 존재하고, 협업이 필요할 때 누가 전문성을 가지고 있는지를 알아내기가 매우 어렵다. 이는 조직의 결재 구조를 따라서 인재를 요청하거나 또는 인맥을 통하여 추천을 받는 방식을 사용하는데,검증이 쉽지 않고 시간이 많이 걸리는 문제가 있다. 마이크로 블로그의 검색을 통해서 특정 분야에 관심이 있는 사람을 검색하고 그 사람의 트윗 메시지를 살펴봄으로써 필요한 전문성이 있는 사람을 쉽게 찾을 수 있고 네트워크를 구축하여 업무적으로 필요한 전문지식에 대해서 도움을 받을 수 있다

지식 공유

마이크로 블로그내에 링크로 저장되어 있는 많은 문서와 전문성을 가진 사람들이 추천하는 링크 그리고 RT된 링크들은 링크된 문서의 신뢰도를 나타내어 주며 기존의 검색엔진(구글과 같은)과 다른 형태의 지식 검색 및 공유 방법을 제공한다. 단순하게 텍스트나 내용의 일치가 아니라 Following하고 있는 사람의 신뢰도와, 많은 사람에 의해서 퍼 날라지거나 인용된 문서의 경우 신뢰도가 높다는 사람의 신뢰 중심의 지식 검색이 가능하게 된다

업무에 대한 컨텍스트 공유

프로젝트나 업무 그룹에 대해서 그룹 필터를 사용하여 진척 상황이나 이슈를 포스팅하여 구성원과 이해 당사자들이 해당 업무에 대한 진행현황(Context)에 대해서 이해할 수 있도록 한다. 현황과 상황은 과거에서부터 현재 어떻게 되고 있다는 Context를 나타내는 만큼, 당사자가 한두번의 브리핑이나 이메일로 현재 업무의 진행 상태를 파악하기가 어렵다. 마이크로 블로그를 통해서 업무에 대해서 계속해서 포스팅을 하면 포스팅 내용이 시간의 순서대로 연결이 되어 업무에 대한 Context의 의미를 가지게 된다

신뢰감 증대 및 관계 개선

마이크로 블로그를 통해서 임원과 같이 조직에서 일반적으로 접하기 쉽지 않은 사람을 Following 하는 행위 자체만으로도 심리적인 유대감을 형성할 수 있다. 거기에 더해서 해당 임원에게 보낸 답변에 대해서 응답이라도 받는 경우에는 구체적인 교감이 있는 것으로 인식이 되서 심리적으로 느끼는 거리가 줄어든다.

또한 마이크로 블로그의 트윗 포스트는 메일이나 게시판과 같이 정형화된 커뮤니케이션이 아니라 좀더 캐주얼하고 비업무적인 부분 (그날의 기분, 일상)도 다루기 때문에 업무적이 아니라 인간적인면 즉 감성적인 커뮤니케이션을 통해서 직원간의 거리를 줄일 수 있게 한다.

결과적으로 좀더 활발한 커뮤니케이션을 유도하여 조직의 구조에서 오는 커뮤니케이션의 장벽을 허물 수 있고 구성원간의 신뢰도를 높일 수 있다

수평적이고 오픈된 커뮤니케이션

기업의 커뮤니케이션 문화는 수직 계층적인 문화를 가지고 있다. 여러 계층을 통하다 보니 커뮤니케이션의 효율성은 떨어지고, 좋은 아이디어나 의견이 하층에서 상층까지 제대로 전달되지 않거나 경영조직의 메시지가 스팸으로 취급되어 버리는 경우가 많다. 마이크로 블로그에서는 조직간의 상하 관계가 없으며 이슈와 주제만으로 커뮤니케이션을 하기 때문에 수직 계층에서 오는 이러한 차이를 극복할 수 있게 하고, 조직의 구조화된 커뮤니케이션 구조를 수평/네트워크화된 형태의 커뮤니케이션 구조로 개선할 수 있다

Near Real Time형태의 커뮤니케이션 스타일

이메일과 게시판, 메모 시스템들을 대체하여 간단한 비동기적인 커뮤니케이션을 효율적으로 수행할 수 있으며 특히 모바일 디바이스 연동을 통해서 장소와 시간에 관계 없는 커뮤니케이션 플랫폼을 구축할 수 있다. 

기업 외부로의 마이크로 블로그

기업이 비즈니스를 하는데 외부 관점으로는 어떻게 마이크로 블로그를 사용할 수 있을까? 주로 대고객 서비스에 마이크로 블로그를 적용할 수 있고, 실제로 S전자,L전자와 같은 글로벌 국내 기업이나 아마존 같은 기업들은 이미 트위터를 통해서 마케팅 활동을 진행하고 있다.

마케팅

새로운 제품에 대한 정보 제공이나 이벤트 행사등에 사용할 수 있다.

고객 서비스

고객의 불만 접수, 고객 모니터링등에 이용 가능하다

본 글을 기업내의 마이크로 블로그 구축 전략을 중점으로 다루고 있기 때문에 기업 외부에 있는 마이크로 블로그를 이용하여 기업 활동을 증진 시키는 방안에 대해서는 자세하게 설명하지는 않는다.

 기업에서 마이크로 블로그 아키텍쳐


Figure 2 Micro blog architecture for enterprise

 사용자 인터페이스

마이크로 블로그는 직원에게 다양한 사용자 인터페이스를 제공하며 기업의 기존 시스템들과 통한된다.

(1)    웹 인터페이스

가장 일반적인 형태의 인터페이스로, 마이크로 블로그 시스템의 고유 웹인터페이스이다.

(2)    모바일 디바이스

이동이 가능한 핸드폰이나 PDA같은 모바일 디바이스로 마이크로 블로그를 서비스 한다. 단말의 종류 서비스 국가에 따라서 서비스 형태가 다르게 제공된다. 스마트 폰의 경우 애플리케이션 형태로 2G이하의 폰의 경우 SMS형태로 서비스가 제공된다.

(3)    포탈

기업의 엔터프라이즈 포탈이 있을 경우, 포탈을 통해서 마이크로 블로그 서비스를 포틀릿 형태로 서비스 한다.

(4)    IM (Instant Messenger)

기업내 메신져와 통합하여 메신져를 통해서 트윗 메시지를 포스팅하거나 반대로 메신져를 통해서 Following하는 대상의 메시지를 받을 수 있게 한다.

(5)    기타 엔터프라이즈 애플리케이션

엔터프라이즈 시스템의 Notification. 예를 들어 Work flow Approval Request등이 기존 이메일 시스템들을 마이크로 블로그로 대체할 수 있다

IDM (Identity Management System)

기업내부에 이미 사용중인 직원 정보 (LDAP 등에 적용된 조직도나 직원 프로필 서비스)시스템인IDM Single Sign On등을 통해서 계정이 통합되어야 한다.

모바일게이트웨이

모바일 디바이스를 지원하기 위해서 통신사의 통신망을 이용하기 위한 게이트웨이이다.

모바일 디바이스의 타입과 연동 방식에 따라 텍스트 기반인 경우 SMS를 멀티미디어 기반의 경우 MMS를 지원하고 스마트폰 기반의 애플리케이션의 경우 TCP/IP 망등을 지원해야 한다.

즉 모바일 디바이스에 따라 모바일 게이트웨이의 연동 방식이 변경될 수 있다.

또한 글로벌 기업의 경우 각 나라마다 텔레콤 회사가 다르기 때문에 사용자의 근무 위치에 따라서 다른 모바일 게이트웨이를 사용하도록 한다.

검색엔진 및 소셜분석 도구

앞서 기업 내부 플랫폼의로써의 마이크로 블로그에서도 언급했듯이 마이크로 블로그의 포스팅 내용은 정보성을 갖는다. 특히 기존의 정확도 기준의 검색 방식이 아니라 마이크로 블로그에 의해서 언급된 비율이나 내가 Following하고 있는 사람이 언급한 정보(같은 이슈를 공유할 가능성이 높기 때문에)는 검색의 정확성이 더 높기 때문에 검색의 방법역시 마이크로 블로그의 가치를 높일 수 있는 검색 시스템이 필요하다

또 마이크로 블로그의 포스팅 내용을 분석하면 리스크 상황이나 트렌드를 읽을 수 있기 때문에 소셜분석도구들을 이용하여 포스팅 내용을 분석하여 의미 있는 데이터로 가공할 수 있다

Policy & Compliance Rule

마이크로 블로그의 기업 도입은 정보 보안의 문제를 해결해야한다. 기업 내부로는 특정 그룹 구성원들간에만 커뮤니케이션이 필요한 경우가 있고 기업 밖으로 배포 되는 정보역시 기업의 보안 정책에 따라서 선별적으로 배포 되어야 한다. Policy & Compliance 컴포넌트는 보안 정책에 따라 이 두가지 부분을 커버한다.

(1)    Selective publishing

직원의 아이디를 연동하여 외부 마이크로 블로그(트위터)로 배포 하고자 할 때, 직원이 선별적으로 외부에 배포하는 글을 선택하거나 또는 시스템에서 보안 정책에 위배되는 키키워드 있을 때 이를 필터링하게 해주는 선별적 배포 기능이다.

(2)    Multilevel access & grouping

임원과 일반 직원 또는 부서(예를 들어 HR부서) 내부에서만 다루어야 하는 정보가 있기 떼문에 특정 그룹이나 조직 단위로 커뮤니케이션을 할 수 있게 한다

Micro blog (Public)

외부 마이크로 블로그 시스템으로, 기업 홍보와 같은 마케팅을 위해서 기업 내부의 포스팅 메세지가 기업 외부의 일반 고객이 사용하는 마이크로 블로그 시스템으로 메시지가 배포 되는 대상이다

기업에서 마이크로 블로그 도입 Challenge

 문화의 변경

마이크로 블로그의 도입은 단순한 IT 시스템의 도입이 아니다. IT 시스템은 정해진 프로세스에 직원들이 프로세스의 구성원으로써 주어진 역할을 수행하면 됬지만, 마이크로 블로그의 도입은 정형화된 프로세스에서 벗어나 직원에게 새로운 커뮤니케이션 및 정보 저장 도구를 주어줌으로써 창의력 발휘를 통해서 업무 생산성의 혁신을 불러오고자 하는데 있다.

 이를 위해서는 마이크로 블로그를 이용한 수평적 그리고 비정형적인 커뮤니케이션 스타일의 도입이라는 문화적인 변경이 필요하다. 이는 관리 지향적인 조직 입장에서 이해당사자들의 설득이 필요한 하나의 도전 과제이다.

 정보 보안

마이크로 블로그에 저장되는 내용들은 업무의 진행상태, 개인의 상태등에 대한 정보로 기업의 비밀에 해당하는 내용이다. 이러한 내용이 유출되지 않도록 보안을 유지해야 하며, 반대로 마이크로 블로그의 장점은 오픈된 환경에서 오는 참여에 있기 때문에 보안의 폐쇄성이 원래 마이크로 블로그의 특징을 해치지 않도록 해야 한다.

 또한 구축하는 국가에 따라서 법률에 접촉되는 여부를 검토해야 한다. 예를 들어 미국의 Sox 법에 의하면 사내 커뮤니케이션 내용은 최소 7년간 보장/유지 해야한다는 내용이 있기 때문에 포스팅 데이터에 대한 유지 역시 정보 보안 부분의 도전 과제에 해당한다.

 구축

마이크로 블로그 시스템이 기업에 도입되기 시작한 것은 근 1년 이내이다. 그렇기 때문에 이렇다할 기업용 마이크로 블로그 시스템이 많지도 않을뿐더러, 각 기업의 구축 요건을 충족시키지도 않고 기존 기업 시스템과의 통합성도 떨어지기 때문에 구축에 있어서 적절한 솔루션을 찾고 커스터마이징하는 것이 큰 과제중의 하나이다

구축 전략

앞서 마이크로 블로그의 활용 방법과 얻을 수 있는 장점 그리고 이를 위한 아키텍쳐에 대해서 설명하였다. 물론 아키텍쳐에 제안된 모든 부분을 처음부터 구축할 수 있다면 가장 좋겠지만, 모든 것이 구축되었다고 해서 모든 장점을 얻을 수 있는 것은 아니다.

 기업의 문화를 바꿔야 하는 일인 만큼, 기대했던 효과가 한꺼번에 나타나지 않을 수 있고, 기업의 업무 환경이나 시스템 환경이 변화할 수 있기 때문에 단계적으로 시스템을 구축하는 것을 권장한다

1단계 마이크로 블로그 시스템의 구축

 첫번째 단계에서는 가장 기본적인 마이크로 블로그 시스템을 구축한다. 필수적인 기능으로는 IDM 시스템 연동,모바일 인터페이스 제공이다. 이 두가지 기능만 가지고도 마이크로 블로그를 서비스할 수 있고 대부분의 장점을 시험할 수 있다

2단계 활성화

구축이 완료된 후에는 활성화 단계로 기업의 문화를 마이크로 블로그를 사용하는 형태로 바꿔 나가면서 마이크로 블로그를 이용한 커뮤니케이션을 활성화 한다. 이 단계가 지나면, 시스템에 추가적으로 필요한 기능이 선별된다

3단계 확장

시스템이 활성화 되면 기능을 확장한다. 이미지 포스팅, 동영상 포스팅과 같은 기능을 추가하여 마이크로 블로그 시스템의 활용성을 높이고, 검색엔진, 소셜분석기능등을 구축하여 활성화를 통해서 축적된 정보를 재가공하여 그 가치를 높인다

4단계 새로운 모델 구축 및 확장

4단계에서는 전통적인 마이크로 블로그 시스템의 한계를 벗어나서 기업 업무 형태에 특화된 자체적인 확장 모델을 개발한다. 현장 근무가 많은 영업 조직의 경우 LBS (Location Based Service:GPS등을 이용한 위치 정보 시스템)과 연계하여 Status 정보에 개인의 위치 정보를 표시하거나 위험한 현장 업무가 많은 건설/건축 업무의 경우 개인의 건강 상태나 재해 여부를 Status로 표시하여 근로자가 위험에 쳐했을 때, 구난 요청을 자동으로 보낼 수 있는 시나리오등이 이에 속한다.

IT doesn't matter

IT 이야기 | 2009.08.01 12:30 | Posted by 조대협
오전에 손차장님이 선물해준 빅스위치라는 책을 읽고 있습니다.
손차장님 안지도 벌써 대략 5년 정도 되가는것 같습니다. 나이 차이는 나지만 때로는 친구처럼 때로는 파트너나 동료처럼 일하고 있습니다. 같이 일할 수 있는 기회는 얼마 되지 않았지만 말이 잘 통하는 뛰어난 사람중의 하나입니다.

그런데 아침부터 머리가 혼란합니다.
"니콜라스 카"가 이야기한
" IT doesn't matter"
라는 말 때문입니다.
흔히 IT 가 기업 업무에서 타사와 차별화될 수 있는 경쟁력있는 무기로 생각되곤 합니다.
그런데, "IT doesn't matter"의 의미는 IT 는 필수적인 인프라지 더 이상 경쟁력이 되는 부분이 아니라는 겁니다.
생각해보니 또 맞는말 같습니다. IT 시스템을 안가지고 있는 기업은 더 이상 없습니다. 컨설팅등을 통해서 여러 프로젝트를 경험해보면 시스템의 구조나 성능, 성숙도야 천차 만별이지만, 그렇다고 비지니스 자체가 그렇게 차이가 나지 않습니다. 은행들을 예를 들어보더라도, 여러분이 IT 시스템이 틀리다고 "우와 A은행은 정말 일 보기가 편하네..' 하고 느껴보신 적이 있는지? 차라리 이자 많이 주고, 지점이 가까운 은행을 선택하지는 않으시는지? 외국계 은행 인터넷 뱅킹이 낙후됬다고 그 은행 계좌를 안쓰시는지? 물론 IT로 인한 비용 절감으로 인해서 비용에 대한 효율성을 올라가겠지만요..

"IT doesn't matter"에 대해서 생각해보고 오전에 글을 쓰려고 블로그를 열었다가 썼다 지웠다만 몇번하다가 혼란스러운 이 느낌을 남겨 놓고 싶어서 두서없이 몇자 적어봤습니다.

REST Overview (Draft)

아키텍쳐 /WEB 2.0 | 2009.07.01 16:10 | Posted by 조대협
REST에 대한 기본적인 설명 PPT입니다.
REST에 대한 개념 설명, 향상된 REST의 특징 설명, Jersey를 이용한 REST 실제 구현 방법
그리고 REST를 사용하기 위한 ESB 아키텍쳐와 REST의 약점중 하나인 Client STUB을 자동으로 생성하는 방법에 대해서 설명되어 있습니다.
 실제 프로젝트 경험을 통해서 처음 정리한 내용입니다. 아직 DRAFT 버전이라서 내용이 다소 거칠고 논리전개가 미숙한 부분도 있습니다. 의견 주시면 내용을 수정하는데 큰 도움 되겠습니다.



REST Ovewview
View more documents from Byungwook.

REST 연재-2회 Advanced REST

아키텍쳐 /WEB 2.0 | 2009.06.23 23:57 | Posted by 조대협

2회 - Advanced REST (DRAFT)

 

자바스터디 조대협
(http://bcho.tistory.com)

 

전의 글에서는 기본적인 REST의 개념에 대해서 설명하였다. 그러나 REST 는 HTTP의 장점을 이용하여 좀더 발전된 형태의 구현이 가능하다.

하나의 예로 이 글은  http://www.infoq.com/articles/subbu-allamaraju-rest 를 이용하여 편역하여 설명한다. 

예를 들기위해서 은행의 계좌이체를 하는 시나리오를 가정해서 생각해보자.

1. 인터넷 뱅킹 계좌 이체 시나리오의 구현

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

http://bank.org/accounts?findby=7t676323a 

200 OK
Content-Type: application/xml;charset=UTF-8
 <accounts xmlns="urn:org:bank:accounts">
    <account>
        <id>AZA12093</id>
        <customer-id>7t676323a</customer-id>
        <balance currency="USD">993.95</balance>
    </account>
    <account>
        <id>ADK31242</id>
        <customer-id>7t676323a</customer-id>
        <balance currency="USD">534.62</balance>
    </account>
</accounts>

 사용자 ID 7t76323a에 대해서 두개의 계좌 AZA12093과 ADK31242 가 리턴되고 각 계좌의 잔액이 함께 리턴된다. 각 계좌 번호를 조회했기 때문에 각 계좌의 상세 정보는 http://bank.org/account/AZA12093

http://bank.org/account/ADK31242

STEP 3. 계좌 이체를 하는 시나리오를 보면

POST /transfers
Host: bank.org
Content-Type: application/xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

AZA12093에서 ADK31242로 100 USD를 이체하는 것을 HTTP POST를 통해서 보낸다.계좌 이체가 성공하면 다음과 같은 결과값이 리턴된다.

201 Created
Content-Type: application/xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

이때 주의해서 볼 것은 리턴값이 HTTP 200이 아니라 HTTP 201이다. 이 시스템의 경우 계좌이체가 바로 발생하는 것이 아니라 비동기적으로 나중에 발생하는 형태로 가정하기 때문에, 계좌 이체 요청이 접수되었다라는 의미로 HTTP 201 Created를 리턴하고 이체 신청 번호 XTA8763을 리턴한다. 

STEP 4. 하루가 지난후에, 계좌 이체가 된 내용을 다시 확인해보면

http://bank.org/check/XTA8763

GET /check/XTA8763
Host: bank.org 
200 OK
Content-Type: application/xml;charset=UTF-8
<status xmlns="urn:org:bank:accounts">
    <code>01</code>
    <message xml:lang="en">Pending</message>
</status>

 해당 계좌 이체 요청이 Pending이 되어 있는 것으로 나타난다.

 2. 진보된 형태의 REST를 이용한 인터넷 뱅킹 계좌이체 시나리오의 구현

언뜻 보면 상당히 잘 구현된 형태의 REST처럼 보이지만, 이는 실제 REST의 장점을 제대로 살린 아키텍쳐라고 볼 수 없다.

REST는

첫번째로 URI를 이용한 자원의 식별이 가능해야 하고,

두번째로 HTTP 프로토콜의 여러 기능들 특히 HTTP Header들을 이용해서 리소스에 대한 다양한 접근 방법을 표현할 수 있어야 한다. 예를 들어서 Sync/Async 식의 Message Exchange Pattern, Correlation ID 등을 이용한 CALL BACK, 웹캐쉬를 이용하기 위한 Last Update Time등의 메타 정보를 HTTP HEADER에 정의해야 하며 Contents Type등을 통한 Input과 Output Data Format에 대한 정의가 가능할 수 있다.

세번째로는 링크를 이용한 리소스간의 관계나 현재 리소스에 대한 상태 정보를 표현할 수 있어야 한다

그러면 이 특징을 기반으로 해서 앞에서 작성했던 계좌 이체 시나리오를 재 구현해보자

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

200 OK
Content-Type: application/vnd.bank.org.account+xml;charset=UTF-8
<accounts xmlns="urn:org:bank:accounts">
    <account>
        <id>AZA12093</id>
        <link href="http://bank.org/account/AZA12093" rel="self"/>
        <link rel="http://bank.org/rel/transfer edit"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">993.95</balance>
    </account>
    <account>
        <id>ADK31242</id>
        <link href="http://bank.org/account/ADK31242" rel="self"/>
        <link rel="http://bank.org/rel/transfer"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">534.62</balance>
    </account>
</accounts>

앞서 설명한것과 다소 다른 형태의 리턴값이 오게되는데, 먼저 살펴볼 부분은 Content-Type이다. : application/vnd.bank.org.account+xml; 리턴 형태의 Content-Type이 리턴된다. 먼저 +xml은 이 문서의 포맷이 xml임을 의미하며 vnd.bank.org.account는 리턴 데이터의 구조를 정의한다. (마치 XML 스키마와 같이, 실제로 UNIQUE한 이름으로 INPUT또는 OUTPUT으로 사용되는 XML 스키마의 이름에 ID를 부여해서 사용하면, REST의 약점중의 하나인 데이터 형의 미정의에 대한 약점을 보완할 수 있다. )

 또다른 변화점은 LINK부분이 추가되었다는 것이다. 이 LINK는 현재 자원의 상태가 어떤 상태로 변화될 수 있으며, 상태를 변화시키기 위해서는 어떤 URI를 이용하면 된다는 것을 설명한다. 또는 이 자원과 관련성이 있는 다른 자원에 대한 연관 관계를 표현하며 호출시에 리턴되는 데이터 형태에 대해서 Content-Type으로 정의할 수 있다. 이렇게 RETURN되는 메시지 자체에 다른 자원으로의 연결 상태와 데이터 형태등이 정의되면 서비스에 대한 별도의 정의가 없이도, 자원에 대한 사용 방법과 관계를 알 수 있기 때문에 이러한 특성을 REST에서는 self-descriptive message라고 한다.

 <account>

        <id>ADK31242</id>
        <link href="http://bank.org/account/ADK31242" rel="self" type=”application/vnd.bank.org.account+xml”/>
        <link rel="http://bank.org/rel/transfer"
              type="application/vnd.bank.org.transfer+xml"
              href="http://bank.org/transfers"/>
        <link rel="http://bank.org/rel/customer"
              type="application/vnd.bank.org.customer+xml"
              href="http://bank.org/customer/7t676323a"/>
        <balance currency="USD">534.62</balance>

이 부분을 살펴보면 세가지 변화 상태를 볼 수 있다. Self와 http://bank.org/rel/transfer 그리고 http://bank.org/rel/customer 이다.

첫번째로 http://bank.org/rel/transfer 로 이 계좌에 대해서 “계좌 이체”를 할 수 있는 관계(또는 기능)을 정의하며, 계좌 이체를 하기 위해서는  http://bank.org/transfers URL에 보내면 되고 리턴값은 application/vnd.bank.org.transfer+xml 형태가 된다.

두번째 self는 이 Account 자체에 대한 좀더 제사한 정보를 나타내며 http://bank.org/account/ADK31242 를 통해서 조회할 수 있으며 리턴 되는 데이터 형태는 application/vnd.bank.org.account+xml 로 리턴 됨을 정의한다.

세번째 http://bank.org/rel/customer 는 고객 정보를 나타내며 http://bank.org/customer/7t676323a 를 통해서 조회가 가능하고 리턴되는 데이터 형태는 application/vnd.bank.org.customer+xml 이 된다.

STEP 3. 실제로 계좌 이체를 수행한다.

STEP 2에서 리턴 받은 transfer 관계의 URL로 아래와 같은 데이터를 전송한다.

POST /transfers
Host: bank.org
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8
<transfer xmlns="urn:org:bank:accounts">
    <from>account:AZA12093</from>
    <to>account:ADK31242</to>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>
 

 리턴값은 아래와 같다.

201 Created
Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8 
<transfer xmlns="urn:org:bank:accounts">
    <link rel="self"
          href="http://bank.org/transfer/XTA8763"/>
    <link rel="http://bank.org/rel/transfer/from"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/AZA12093"/>
    <link rel="http://bank.org/rel/transfer/to"
          type="application/vnd.bank.org.account+xml"
          href="http://bank.org/account/ADK31242"/>
    <link rel="http://bank.org/rel/transfer/status"
          type="application/vnd.bank.org.status+xml"
          href="http://bank.org/check/XTA8763"/>
    <id>transfer:XTA8763</id>
    <amount currency="USD">100</amount>
    <note>RESTing</note>
</transfer>

 STEP 4. 계좌 이체 진행 상태를 확인한다.

계좌 이체 진행 상태를 확인하기 위해서는 STEP 3에서 리턴된 http://bank.org/check/XTA8763 을 이용하여 확인할 수 있다.

결론

사실 여기서 언급하고자 한 부분은 HTTP의 Content-Type을 이용한 데이터 타입의 정의와 Link를 이용한 리소스간의 관계 정의 방법이다. 많은 REST 관련글을 보면 비슷한 사상들을 가지고는 있지만 아직 “이거다” 하는 식의 표준 디자인 방법은 존재하지 않는다.

위의 예제에서도 Content-Type을 통해서 In/out data format을 정의할 수 는 있지만 고민해보면 Link에 정의된 type만으로는 out(return) data format을 정의할 수 있을지 몰라도 input에 대한 정의는 빠져 있다. 또한 다른 디자인에서는 XML의 namespace의 URI에 실제 XML Scheme의 URI를 정의해서 데이터 타입을 정의하는 방법론도 있다.

 또한 Link를 사용하는 방법은 프로토콜 차원에서는 리소스간의 관계를 정의를 하는것이라서 언뜻 보면 좋아보일 지는 모르지만 실제 구현시에는 여러가지 제약사항을 만들어 낼 수 있다.

이 글은 HTTP의 좀더 활용을 통해서 좀더 발전된 형태의 REST 디자인 방법의 하나의 예시를 설명한 것 뿐이고, 좀더 실용적인 REST 디자인은 더 많은 고려가 필요하리라 생각된다.

=======

Comment

사실 본인도 Advanced 스타일의 REST 디자인에 대해 정리를 하기위해서 작성한 글이라서 내용이 다소 떨어지더라도,  아직까지 다소 정리되지 않은 형태의 글임을 이해해주시기 바랍니다. 다음에 기회가 되면 Advanced Style 특히 LINK와 Data type 대해서는 다시 한번 다루기로 하겠습니다. 다음 연재에서는 실제로 REST를 JAVA에서 구현하는 방법에 대해서 알아보겠습니다.

 




문뜩 궁금해졌습니다. 왜 많은 사람들이 이런 협업에 참여하는지..
1 번 - 온라인 상에 네임 밸류(명성)을 쌓기 위해서
2 번 - 그냥 재미로
3 번 - 지식을 공유하고 싶어서
4 번 - 지금까지 지식을 정리할려고
5 번 - 인맥을 만들어 볼라고
6 번 - 기타


결과


Google Apps - Office 류 및 협업에 사용
Google Groups - 메일링 리스트.
http://twtpoll.com - Survey
http://twitter.com - 마이크로 블로깅
http://facebook.com - 커뮤니티 사이트/ 친구 관리
http://linkein.com - 기술 인맥 관리
http://bit.ly - 북마킹
http://slideshare.com - PPT 파일 쉐어
http://expertjava.blogspot.com/ - 구글 블로그. 영문인데 시작했다가 한글 블로그로.. 

한국 사이트
http://bcho.tistory.com
http://www.me2day.net 마이크로 블로깅
http://www.hanrss.com RSS Reader
TAG web 2.0

별 서비스가 다있군요.

아키텍쳐 /WEB 2.0 | 2009.06.23 09:28 | Posted by 조대협
http://disqus.com/

블로그 Comment 만 전문으로 처리하는 서비스랍니다. 제가 쓴 Comment만 모아서 볼 수 있고, 댓글이 달리면 메일로 전송되는군요.

Enterprise 2.0과 1.0의 차이점

아키텍쳐 /Enterprise 2.0 | 2009.06.22 18:42 | Posted by 조대협

엔터프라이즈 2.0은 WEB 2.0의 참여,개방의 정신을 기업에 적용시켜서 생산성과 효율성을 극대화하게고자하는 모델이다.
엔터프라이즈 2.0은 WEB 2.0의 개념에 비교해서 보면 엔터프라이즈 1.0과 큰 차이를 가지고 있는데, 몇가지를 정리해보면 다음과 같다.

  1. 관리에서 자발적 참여 : 기존의 IT 시스템들이 업무를 위해서, 무언가를 하도록 프로세스를 만들고 관리를 해서 따라오게 했다면 엔터프라이즈 2.0은 사용자들이 자발적으로 무언가를 하도록 만드는 것이다. 위키를 통해서 정보를 공유하고 포럼을 통해서 서로 지식을 주고 받으며, 블로그를 통해서 자신의 경험을 공유하며, 인맥관리를 통해서 필요한 사람을 빠르게 찾는다.
  2. 메뉴 중심에서 검색 중심 : 기존에는 몇몇의 정해진 IT 시스템을 메뉴에 따라서 정해진 절차로만 사용해왔다. 그러나 IT 시스템의 역사가 오래되고 점점 많은 시스템이 추가되면서 아무리 통합이 되더라도, 어디에 내가 원하는 정보가 있는지 찾기가 쉽지 않다. WEB 2.0에서도 볼 수 있듯이, 특정 사이트에 들어가서 메뉴를 찾아서 정보를 찾는것이 아니라 검색을 통해서 내가 원하는 정보에 접근하게 된다. 이 현상중에 재미있는 사례중의 하나가 기존 개인 기반의 커뮤니티 사이트의 영향력 감소이다. 예전에는 프로그래밍 관련 정보들을 얻는 패턴이 특정 개발 커뮤니티 사이트를 통해서 였지만, 요즘은 개인 블로그가 발전해서 예전 처럼 커뮤니티 사이트에 기술자료를 포스팅할 필요 없이 개인 블로그에 기술자료가 올라오고 사용자는 RSS를 통해서 그 블로그를 구독하거나, 웹검색을 통해서 원하는 양질의 자료를 찾는다.
  3. 조직의 경계가 허물어진다. : 예전에는 어떤 협업이 필요하거나, 노하우가 필요할때는 메니져에게 Issue를 escalation해서, 노하우가 있는 사람을 찾아서 assign 받고 같이 일하는 형태인데, 엔터프라이즈 2.0에서는 인맥관리를 통해서 빠르게 다른 조직에 있는 사람이라도 필요한 능력이 있는 사람을 찾아내고, 도움을 받을 수 있게 된다.
엔터프라이즈 2.0의 도입에서 가장 중요한것은 IT 시스템을 만들어서 "이렇게 써라"라고 하는 것이 아니라. "이런게 있는데.. 어때?" 처럼 재미있고 사용하기 좋은 시스템을 만들어서 사용자들이 참여하게 만드는 기업 내부의 "문화"를 만드는 일이다.
엔터프라이즈 2.0을 위한 IT 시스템은 사용자가 무언가를 하게 만드는 시스템이 아니라, 사용자들이 자유롭게 무언가를 할 수 있는 장을 만들어 주는 것이다.

분명히 가능성과 잠재력이 많은 기술이기는 하지만, 경직된 한국의 기업문화에서 얼마나 전파될 수 있을가는 사실 미지수 이다. 또한 국내의 인터넷 환경이 NXX나 DXX의 몇몇 업체에 의해서 리드 되고 있어서 외국에서 인기가 있는 Social Application이 한국에서 맥을 못추는 것이나, 한국형 Social Application 이 개발되는 것을 봐도, 확실하게 문화적인 차이는 존재한다. 아마도 외국의 엔터프라이즈 2.0 모델을 그대로 들여오는 것이 아니라 한국의 문화에 맞는 엔터프라이즈 2.0 모델이 필요하지 않을까?



그간 Technical한 내용에 대한 Post가 뜨음 했습니다.
작년과 금년에 걸쳐서 REST 기반의 시스템을 설계와 구현을 하였습니다. 그때 참 REST에 대한 이해가 잘못되어 가고 있구나, 그리고 REST에도 생각할것이 참 많구나 하는 생각을 하고 꼭 정리해야지 정리해야지 했는데... 몇달이 지난 지금에야 시작합니다.

총 4회의 연재로 구성됩니다.
1회-REST 아키텍쳐에 대한 소개
REST가 무엇인지에 대해 간단한 소개와 REST 기술에 대한 경향을 알아봅니다.
2회-고도화된 REST 아키텍쳐
Roy Fielding이 소개한 진짜 고도화된 REST에 대한 아키텍쳐를 좀더 깊게 알아봅니다.
3회-REST 구현
REST 구현 스펙인 JAX-RS (JSR-311) 기반의 Jersey 프레임웍을 통한 REST 서비스 구현 방법에 대해서 알아봅니다.
4회-REST 아키텍쳐에 대한 설계
REST 서비스 자체뿐만 아니라 ESB와 WebServer등을 이용한 REST 아키텍쳐에 대한 설계 방법과, REST의 단점인 Service Contract과 Stub을 어떻게 관리하고 코드 생성을 할것인지에 대해서 알아보겠습니다.

시간이 나는데로 정리할려고 하는데.. 써놓고 보니 참 크게 범위를 잡았나 싶네요.
기고 내용에 대한 피드백이나 토론은 항시 환영합니다.

'아키텍쳐  > WEB 2.0' 카테고리의 다른 글

별 서비스가 다있군요.  (0) 2009.06.23
REST 관련 강좌  (0) 2009.06.03
REST 아키텍쳐에 대한 연재를 시작합니다.  (2) 2009.05.27
REST 연재-1회 REST 아키텍쳐의 기본  (15) 2009.05.27
AJAX Overview  (1) 2009.04.09
REST의 반격?  (0) 2008.12.08

Composition 과 Mashup의 차이

아키텍쳐 /SOA | 2008.11.13 19:01 | Posted by 조대협
SOA 프로젝트를 하다보면 Mash up과 Composition를 혼용해서 쓰는 사람들이 종종있다.
먼저 유래부터 살펴보면 SOA 사상이 먼저 나온후에, 
WEB 2.0 이란 사상이 대두 되고, SOA의 무거운 부분과 복잡성을 제외하고, 단순성과 편의성을 위주로 OPEN API라는 개념이 나왔다.
SOA에서 통상적으로 웹서비스로 구현되는 서비스를 JSON이나 PLAIN OLD XML등과 같이 경량의 사용하기 쉬운 메세지 포맷을 이용해서 OPEN API라는 것이 개발되었고, 이 오픈 API를 조합하여 새로운 기능을 만들어 내는것을 MASH UP이라고 한다.
   SOA  WEB 2.0
 컴포넌트 개념  웹서비스 기반의 서비스  경량 기반의 서비스
 서비스 조합  Composition (Orchestration)  Mash up

그러면 차이가 무엇일까?
다시 족보부터 따져 보자면 SOA는 기업을 위한 아키텍쳐에서 부터 출발했고 WEB 2.0은 서비스 애플리케이션에서부터 시작되었다.
IBM,BEA,ORACLE등을 선두로 하는 벤더에서 주창되는 아키텍쳐가 SOA이고, 구글이나 아마존, 야후와 같은 서비스 기업에 의해서 주창되는것이 WEB 2.0 사상이다.

사상 처럼 SOA의 서비스는 대부분이 비지니스적인 의미를 갖는다. 대부분의 서비스가 UI를 가지기보다는 비지니스 컴포넌트로써의 의미를 가지고, WEB 2.0의 서비스는 맵이나, 뉴스, 가젯 등등과 같이 UI 성격을 갖는 서비스가 대다수이다.

SOA에서의 Composition은 서비스들을 조합하여 새로운 서비스를 만들어 내는 것으로, 이 새로운 서비스는 재 사용이 가능하고 다시 Composition이 가능하다. 반면 Mash up은 한번 조합이 되서 새롭게 구성된 서비스는 다시금 조합이 어렵다. (물론 아닌 경우도 있지만....) Mash up은 기존 서비스를 조합하여 새로운 화면을 만들어서 자신의 서비스 사이트에 나타내기 위한것이기 때문에, 근본적으로 재활용성에 큰 비중을 둔것이 아니다.
반면 SOA는 컴포넌트 조합을 통해서 다시금 재 사용을 하는 것을 전제로 하기 때문에 재 사용성의 여부에서 Mashup과 Composition의 차이를 볼 수 있다.


'아키텍쳐  > SOA' 카테고리의 다른 글

SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10

2008년 SOA 전망

아키텍쳐 /SOA | 2008.01.10 17:49 | Posted by 조대협
경영과 컴퓨터 1월호에 기고했던글..

==

2008 SOA 기술 전망

 

저자  BEA 조병욱 과장 (Sr. consultant of BEA Systems Korea consulting dept.)

블로그 : http://bcho.tistory.com

온라인상의 필명으로 “조대협” 이라는 이름을 사용하고 있으며,온라인 자바사이트 www.javastudy.co.kr의 초대 운영과, 한국 자바 개발자 협의회 jco의 부회장을 맏았으며, SOA 관련 다수의 강의 경력과 컨설팅 경험을 가지고 있다.

 현재는 BEA Systems Korea에서 엔터프라이즈 시스템 관련 컨설턴트로 재직중이다.

 

1. 개요

 본 기고는 2007년의 SOA관련 기술의 흐름을 되 짚어보고, 2008년의 SOA의 기술의 변화 방향에 대해서 전망하여, SOA 를 적용할 기업들의 방향성에 대한 도움을 주고자 하는 기고이다.

 

2. SOA의 기술 계층

먼저 SOA가 어떤 기술 계층으로 이루어져 있는지를 이해하면, 각 계층들의 변화 방향을 통해서 전체 기술 방향의 변화를 인식할 수 있다.

 

(1) SOA 3단계 기술 계층

SOA는 크게 다음과 같이 3단계 기술 계층을 가지게 되어 있다.

 

1) 서비스 가능화 계층 (Service Enablement Layer)

서비스 가능화 계층의 기존의 레거시 시스템 (기존에 운영되고 있는 시스템)들을 비즈니스의미를 갖는 단위의 컴포넌트로 묶고 표준화된 인터페이스로 시스템 외부로 서비스를 제공할 수 있도록 해주는 계층이다.

현재에 유행하고 있는 웹서비스 중심의 SOA에서는 레거시 시스템들의 기능들을 웹서비스로 노출 시키고, 노출되는 컴포넌트 단위를 비즈니스 업무 단위로 크게 묶는 계층을 정의한다.

 

각각의 시스템들이 표준화된 인터페이스를 통해서 기능을 제공하기 때문에, 이 계층에서는 타 시스템간의 통합(Integration)이 용이하게 된다.

* 키워드 : 비즈니스 업무 단위, 표준화 인터페이스, 서비스화, 시스템 통합

 

2) 서비스 허브 계층 (Service Hub Layer)

서비스화된 각각의 업무 컴포넌트간의 통합과 호출은 각 시스템 대 시스템으로 이루어지기 때문에, P2P 구조를 가지게 되고 결국 이는 시스템간의 복잡도를 증가 시켜서, 시스템간 연계 Topology가 마치 거미줄 처럼 복잡화된 구조를 가지게 된다.

이런 복잡한 Topology를 중앙에 공용 Bus를 넣어서 Hub & Spoke 방식으로 중앙 집중형 통제 구조를 가지게 하여 복잡성을 제거하고, 관리의 용이성을 증가 시키며, Bus 안에 유연성을 가미할 수 있는 서비스 - Intermediary 서비스를 추가하여 시스템의 업무에 대한 유연성을 높인다.

 

 Intermediary 서비스란, 예를 들어 백화점의 구매 프로세스가 있었다고 가정하자 그런데 이 백화점에서 VIP 고객을 위한 특별한 포인트라는 신규 업무를 만들었을 경우에, 백화점 구매 프로세스에 변경을 가해서 포인트 적립하는 비즈니스 로직을 추가하거나 또는 백화점 구매 프로세스를 호출하는 쪽에서 포인트 적립을 하는 서비스를 호출해야 하는 것과 같이 ‘서비스 제공자’나 ‘서비스 사용자’ 에 대한 로직 변화가 필수적 이었다.

 이 문제를 해결하기 위해 ‘서비스 제공자’와 ‘서비스 사용자’ 사이에 중간자 적인 역할을 하는 Intermediary 서비스를 넣어서, ‘서비스 사용자’는 예전과 똑같은 방법으로 서비스 제공자를 호출하지만 이 Intermediary 서비스에서 고객의 정보에 따라서 VIP 고객일 경우, VIP 고객용 서비스로 라우팅(경로변환)함으로써 ‘서비스 사용자’와 ‘제공자’의 로직 변환 없이 그대로 변경된 업무를 유연하게 반영할 수 있도록 할 수 있다.

* 키워드 : 버스, 유연성의 추가

 

3) 서비스 조합 계층 (Service Orchestration Layer)

서비스 가능화 계층과, 서비스 허브 계층을 거치면 시스템의 업무들은 모두 비즈니스적인 의미를 가지고 표준화된 인터페이스를 통해서 서비스 허브에 집중화된 형태로 존재하게 된다.

이 서비스 업무하나하나를 조합하여, 현업에서 필요한 ‘비즈니스 업무 흐름’으로 구현해야 하는데, 이 계층이 서비스 조합 계층이다.

 이 계층에서는 비즈니스 업무 흐름을 조합하고, 이 조합된 업무 흐름을 사용자 인터페이스 (UI)로 보여주는 역할을 수행한다.

 

* 키워드 : 서비스 조합,업무 구현, 통합 사용자 인터페이스

 

(2) SOA 기술 계층별 사용 기술과 발전

지금까지 전통적인 SOA의 각 기술 계층이 어떤 역할을 수행하는지를 살펴보았다. 그렇다면 각각의 기술 계층들은 어떤 구체화된 기술을 이용하여 구현이 되어왔을까?

 

1) 서비스 가능화 계층 기술

서비스 가능화 계층에서 사용된 서비스 가능화 기술은, 기존 레거시 시스템의 기능을 서비스화 해주기 위한 “아답터”와, 여러 형태로 저장된 데이터들을 서비스 기능 형태로 변환해주는 “데이터 서비스” 기술이 그 주류를 이루어 왔다.

 또한 각각의 분리된 시스템 업무를 묶어서 하나의 서비스 업무로 변환하기 위해서 시스템간의 통합이 필요하게 되었는데, 이를 위해서는 EAI (Enterprise Application Integration)기술이 사용되었다.

 

 2008년의 서비스 가능화 계층 기술에서 눈 여겨 볼만한 기술적인 이슈는 SCA (Service Component Architecture)이다. SCA는 소프트웨어를 개발함에 있어서 각각의 Service Component로 다루어 이러한 서비스들을 조합하여 플랫폼에 중립적인 서비스로 재조합 한다는데 의미를 두는데, 특히 이 기술의 경우에는 기존의 SOA와는 다르게 명시적으로 WEB 2.0에 대한 프로토콜 (RSS,ATOM,JSON,Hessian etc)등을 폭 넓게 지원하여 좀더 개방적인 서비스 가능화 기능을 제공한다는 것이다.

 SCA를 통해서 서비스 자체에 대한 생성에 필요한 통합 기능이 증대될것이며, 서비스 가능화 계층에 필요한 “아답터”,”데이터 서비스”,EAI” 솔루션들은 아직까지 몇몇 선두 SOA업체만이 보유하고 있기 때문에, SOA를 지향하는 솔루션 업체라면 이 기술 계층을 마련하기 위한 노력들이 뒷 따를 것이며, 이미 이러한 솔루션을 가지고 있는 기업들의 경우에는 이 기술들의 성숙도를 높이는데, 포커싱이 될것이다.

 

2) 서비스 허브 계층 기술

다음으로 서비스 허브 계층은 SOA에서 흔히 이야기 하는 ESB(Enterprise Service Bus)으로 대변되었던 한해였다. 이 서비스 허브 계층을 통해서 각각 다른 형태로 존재하는 시스템들이 통일화된 인터페이스를 가지고, 각각의 분리된 시스템들이 비즈니스 업무 단위로 통합 되면서 하나의 서비스로 형태가 변화게 된다.

 즉 서비스 허브 계층에 대한 요구 사항이 기존의 유연성의 증대와 중앙 집중화된 버스 방식에 더해서, 분리된 시스템 업무간의 통합 기능이 추가 되었다.

 

 기존의 EAI 솔루션을 통해서 수행되던 시스템 통합 기능이 서비스 허브 계층으로 올라오면서 SOA에 적절한 형태 (웹서비스의 지원, ESB와의 통합성)로 변화되면서 서비스허브에 통합되도록 진행되고 있다. EAI 솔루션과 ESB 솔루션간의 통합성 문제와, ESB 솔루션을 사용할 때, 시스템 통합에 대한 요건이 필수 불가결하게 발생하기 때문에, 이에 대한 기능이 흡수 통합되는 모델이다.

 

 특히 SOA 모델에서 자주 언급되는 , Process에 대한 이야기에서 “Process의 주체와 목적이 누구인가?”이다. EAI BPM에 각각의 Process가 있었고 두개의 Process의 존재로 인해서 많은 혼동을 초래하였다. 이러한 Process들은 크게 비즈니스 사용자위주의 사용자 프로세스(Human centric process), 시스템 통합에 필요한 시스템 프로세스(System integration process)로 나뉘어 지고, 이를 각각 ‘BPM과’ ‘EAI Process’로 분리되었고, 이 시스템 프로세스가 서비스 허브 계층에 통폐합 되는 형태로 변화 될것이다..

 

3) 서비스 조합 계층 기술

서비스 허브 계층의해서 제공되는 서비스는 전통적인 SOA에서는 사용자 애플리케이션에서 직접적으로 조합하여 사용하거나 프로세스가 있는 업무의 경우에는 BPM을 사용하는 절차로 가이드되어 왔었다. 여기에 BPA,BAM을 통한 비즈니스 프로세스의 설계와 모니터링을 통한 프로세스 개선에 목적이 맞춰져 왔으나,  실제 업무에서 BPM이 필요한 경우는 복잡한 업무 프로세스가 존재하는 경우이고, BPM을 사용할 수 있는 수준의 SOA 성숙 수준까지 시스템이 발전하기 전까지는 각각의 서비스들을 애플리케이션에서 조합해서 사용하는 수준인데, 이 역시 별다른 기술적인 대안이 존재하지 않았다.

 이에 대한 대안으로 제시될 수 있는 것이 SCA이다. 앞에서도 설명했듯이 SCA는 컴포넌트에 대한 조합 기능을 제공하기 때문에, 상태나 장기적인 프로세스를 갖는 업무가 아닌 일반적인 업무 조합에서는 SCA를 통해서 충분하게 조합이 가능하게 된다.

 

 이렇게 조합된 업무들은 사용자 인터페이스 (UI)를 통해서 사용자들에게 제공이 될것인데, 업무별 또는 조직이나 사용자별의 업무 제공 UI Enterprise Portal (EP)로 제공되어 왔던것에 더해서 WEB 2.0의 개념을 도입한 POA의 개념으로 업무에 대한 서비스가 사용자에게 제공될것이다.

 

 POA (Participant Oriented Architecture)의 약자로, 사용자 참여 중심의 아키텍쳐를 이야기 한다. 요즘 “공유하지 않으면 망한다..” 라는 말이 있듯이 현재 e-비즈니스 환경은 위키나 블로그등으로 대변되는 참여 중심의 WEB 2.0 환경으로 변화하고 있다.

마찬가지로 기업의 비즈니스 환경 역시 공유와 참여가 필요로 하게 되는데, 서비스화된 업무들을 OPEN API 형태로 외부에 제공하거나 또는 부서별이나 개인별로 각각의 업무에 맞춰서 워크플레이스를 Mash-up (매쉬업)을 통해서 조합하여 기업의 다양한 업무 요건에 대한 대응을 더 이상 IT 부서에만 일임하는 것이 아니라, IT 부서는 업무를 위한 컴포넌트를 제공하고, 실제 현업에서 구성할 수 있는 형태의 개방성을 부여하는 기능이 제공될것이다.

 또한 태그 방식의 검색등을 통해서 기업내에 흩어져 있는 자산과 서비스들에 대한 사용성이 높아지게 될것이고, 이는 기업내의 지식과 자산의 공유를 가속화 시킬것이다.

 

 

3. SOA 2008

이렇게 변화된 각 계층간의 모델을 정리해보면 다음과 같다.

2007년까지는 SOA 의 개념이 도입되고 정리되는 기간이었고, 기업에서는 이런 개념들을 관측하고 평가해왔으며, 발빠른 업체는 SOA의 도입을 시작하였다.

2008년에는 SOA의 관련 기술이 성숙단계에 들어서고 기업들 역시 적극적으로 SOA의 도입을 준비할것이다.  2007년에 진행되었던 SOA의 경험들을 바탕삼아 벤더에서 제공하는 SOA기술들은 개념으로만 떠드는 SOA가 아니라 고객의 요구사항을 충분히 반영한 실용주의성의 사상과 솔루션으로 발전되어서 부족한 기술이나 쓸모없는 기술은 도태되고 필요한 사상이나 기술들은 점점 더 진화되는 한해가 될것이다.

 또한 오픈소스 진영을 중심으로 발전한 WEB 2.0 관련 기술과 참여 공유의 사상은 기업의 SOA 시스템의 사상에 급속하게 녹아들면서 POA라는 이름으로 영향을 줄것이다.

 

 특히 현대의 기업의 IT 부서는 예전과는 달리 ROI가 적거나 RISK 가 높은 기술에 대해서는 점점 도입을 꺼리고 적극적인 검증을 통한 실용적이고 합리적인 경향이 높아졌기 때문에, 아직 SOA 기술에 진입하지 않은 기업은 SOA를 적극적으로 검토하는 한해가 될것이고, 이미 SOA 기술에 진입한 발빠른 업체들은 다른 기업보다 앞서서 자사의 SOA 모델을 성숙시켜가고, 비즈니스 모델에 적용해 나가면서 빠르게 변하는 업무 환경에 빠르고 유연하게 대응할 수 있는 IT 시스템들을 갖추게 될것이다.

“제이슨 블룸버그”의 말처럼, SOA를 하지 않는 기업은 망한다.

 

'아키텍쳐  > SOA' 카테고리의 다른 글

SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04

WEB 2.0

분류없음 | 2007.11.28 15:25 | Posted by 조대협
예전에 써놓은글 옮겨 닮기
==

꽤나 떠들석하다.
얼마전에 UCC에 대한 다큐멘터리를 하더니, 어제는 SBS에서 WEB 2.0(이라는 단어는 안나왔지만), Long Tail,UCC 에 대한 내용의 다큐멘터리가 있었다.

* Simple & Easy
녹화해놓고, 휴일오전에 보다가 생각이 나서 쓰는글인데.
언제나 내 기술에 대한 지론은 "Simple & Easy"이다.
UCC의 대표 컨텐츠인 동영상과,
개인 홈페이지의 대표인 BLOG
를 보면, 결코 새롭지 않다는 것이다.
예전에도 개인 동영상 기술이 있었고, 그 당시에는 개인 방송국이라는 형태로 붐이 있었으며, 개인 홈페이지이 역시 네티앙 시절부터, 이런 형태의 개인 홈페이지와 나름대로의 블로거들이 있었다.
어떻게 보면 자바스터디를 통해서 온라인의 수혜를 보면 나역시도 BLOG 전의 세대가 아닌가 싶다.

그러면 말하고 싶은것은 무엇인가? "무엇"을 표현할것인가가 아니라 "어떻게" 표현할것인가가 중요하다.
이미 UCC에 대한 기술은 퍼져 있었고, BLOG에 대한 기술은 있었는데 왜? 갑자기 WEB 2.0이라는 탈을 쓰고 유명하게 되었을까?
여기에 작용하는것이 벤더의 힘이라고 본다. 여기서 벤더란 포탈이 될것이다.
컨텐츠를 올려서 공유할 수 있는 인프라를 만들고, 컨텐츠를 쉽게 가공 할 수 있는 인프라를 제공해서 UCC를 세상으로 끌어낸것이 아닐까?

 동영상을 쉽게 편집하고 보여줄 수 있는 툴들을 UCC라는 이름 아래 각종 포탈 사이트에서 제공하고 있다.
 
BLOG에 대한 제공과 이를 노출하기 위한 검색 기술도 제공하고 있고

결과적으로 WEB 2.0의 키워드는 "쉬운 구축", 그리고 "노출" 이 아닐까?
거기에 더해서 comment와 trackback으로 얻어지는 양방향 통신이라고 본다.

* NEXT UCC

그렇다면 WEB 2.0의 UCC다음 미디어는 무엇일까?
개인적으로는 PodCast와 같은 음성 컨텐츠와, 이미지 컨텐츠라고 생각한다.
국내에서는 PodCast가 그리 활성화 되지 않았지만, 한국 네티즌 치고 MP3를 가지고 있지 않은 사람이 얼마나 있을까? 단순히 음악만 들을 수 있겠지만, 라디오와 같은 스토리와 또는 학습 목적의 컨텐츠를 PodCast처럼 쉽게 제공할 수 있다면, 한국의 새로운 UCC모델이 될 수 있지 않을까?

그리고 이미지는 이미 싸이월드나 레이소다(www.raysoda.com)을 통해서 활성화 되어 왔다. dcinside도 그렇고, 많은 comment를 통해서 스타를 만들어내고 국내의 DSLR 보급에 획기적인 기여를 했다. 특히 싸이월드는 이미지 기반의 UCC의 최대 수혜자가 아닐까?
그러나 이 시장에 대해서 정작 네이버등의 포탈사이트에는 크게 관심이 없는것 같다.
동영상에 대한 Comment나 Ranking은 있어도, 이미지에 대한 Ranking은 본적이 없다.
Raysoda의 일면 시스템을 벤치마크해보면 어떨까?

아침에 다큐 보다가 생각나는것을 마구잡이로 적어본것이라서 말이 좀 횡설수설하네..
차라리 개발자 그만하고... 기획이나 마케팅으로 업종을 바꿔 볼까?

Long Tail과 WEB 2.0 시대의 수익 모델에 대해서 다음에 시간이 나면 한번더 정리를 해보자..