Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 Parse error: syntax error, unexpected T_STRING in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 calmglow (최진호)

calmglow (최진호)

calmglow.egloos.com
포토로그

adsense(728_90)

WS-I, WS-Security, BSPWG Enterprise

WS-I는 대체 무엇을 하는 기구인지 궁금해하는 사람들이 있을 것으로 본다.
W3C의 경우는 HTML이나 XML처럼 웹에 직접적으로 관련되는 기술들을 공개라는 원칙에 입각하여 표준을 정하는 단체인 반면에 OASIS는 e-Business에 관련된 각종 기술들의 표준을 적용하고 제정하고 중재하는 역할을 하기 위해 만들어진 비영리기구이다.
반면에 WS-I의 경우는 웹서비스의 상호운영성을 위해 20여개 벤더들이 뭉친 단체이며 얼마전에 WS-Basic Profile을 발표하였는 바 이 안에는 기본적으로 웹서비스로 서로간에 통신하는 데 있어 아주 기본이 되는 요소들을 각 웹서비스 스펙을 적용하여 설명하고 있으며 이 Profile과 함께 예제 시나리오등이 같이 포함되어 공개된다. 하지만 이 Basic Profile은 정말 아주 기본적인 형태의 메시지 교환에 필요한 부분만을 다루고 있기 때문에 기업에서 요구하는 Reliable Messaging 수준에는 한참 뒤쳐져있는 수준이다. 때문에 근래들어 WS-I에서 힘을 쏟고 있는 부분은 WS-Security가 되겠다.

이 WS-Security를 WS-Basic Profile에 추가하여 사용한다면 기업의 내부 보안에 대한 부분이나 Reliable Messaging을 처리할 수 있다. 하지만 Basic Profile과는 다르게 이 WS-Security는 매우 복잡하고 다양한 형태를 띄고 있다. 즉 기존에 각 기업들이 적용하고 있는 Security 관련 소프트웨어들이 너무나 천차만별이기 때문에 한 회사에서 동작하는 보안장치가 다른 회사에서 동작하지 않는 경우는 비일비재한 것이다. 현재 WS-I 내에서 웹서비스 보안을 다루고 있는 곳은 BSPWG(Basic Security Profile Working Group)라는 곳이며 현재에도 이 WS-Security를 위한 작업을 진행중이다. 현재 WS는 이 보안에 발목이 잡혀있는 상태이다.
기업들이 그렇게 현란한 말솜씨로 광고하고 있는 웹서비스가 실제로 각 현장에 쓰이려면 이 보안이 확실하게 안정화되어야 하는 것이다. 말그대로 똥줄타게 부랴부랴 스펙을 만드는 모습이 눈에 선하다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

BEA의 CEO의 발표자료 Enterprise

언젠가 이 블로그를 통해 언급한 적이 있지만 나는 여러 자바 벤더들 중에서도 BEA가 가장 기술을 진취적이고 적극적으로 선도해나간다고 생각한다. 물론 많은 이들이 IBM에 손을 들 수도 있겠지만 최근 웹서비스 스펙동향에서 유독 BEA가 목소리를 예전보다 크게 내고 있음을 느끼게된다.

이번에 나온 웹로직 8.1은 이러한 BEA의 미래 기술에 대한 비젼을 엿볼수 있는 제품이다. BEA의 CEO인 Bosworth의 발표자료를 보면 이러한 BEA의 미래에 대한 비젼이 잘 정리되어있다. 이 자료는 영업이나 기술발표 자료에도 아주 요긴하게 써먹을 것이 많은 괜찮은 자료인 듯 싶다. BEA의 미래에 대한 비젼을 한마리로 요약하자면 SOA라고 할 수 있겠다. 기업의 IT투자의 목적은 통합과 TCO로 귀결될 수 있으며 그 목적을 달성하기 위해 SOA가 탄생하였으며 SOA가 가진 세부 기술은 크게 XML, 웹서비스, 프로세스 통합엔진, 포탈, EAI 기술들이 포함된다. BEA의 웹로직은 이러한 기술들을 다 포함하고 있으며 크게 애플리케이션 서버제품과 메시징 및 통합관련 제품과 워크플로우제품등으로 구성된다. 이러한 요구를 만족시키기 위한 웹서비스 표준이 비즈니스 프로세스와 메시징 및 보안쪽으로 BEA를 비롯한 여러 벤더에서 만들어지고 있는 상황이며 이제 적용하는 데 무리가 없는 상태에 와있다.
다만 너무 복잡한 시스템으로 인하여 고급 개발자가 아니면 개발이 무리가 따를테지만 BEA의 제품의 경우 매우 쉽게 구현이 가능하다. 그리고 이러저러한 기술들을 웹로직에서 제공한다...어쩌구 저쩌구.. 결국 BEA에 대한 광고인 셈인데... SOA에 대한 유명 벤더들의 생각을 읽어보자는 정도에서 심취하면 될 것 같다.

요즘의 웹서비스 표준시장(?)은 여전히 혼탁하다. 한달에 하나씩 표준이랍시고 태어난다. 얼마전에 BEA에서는 WS-ReliableMessaging 을 오아시스에 오픈된 표준으로 제공하였다. 뭐 어떤 이는 그 기사를 읽고 '오~ BEA는 천사인가' 할지 모르겠으나 그다지 반기는 업체는 있을리가 없다. BEA맘대로 스펙과 그 스펙을 이용해서 제품만들고 제품과 함께 같이 스펙을 표준화해달라는 것은 웹서비스 Reliable Messaging 시장쪽을 아예 장악해버리겠다는 심산이다. 과연 어느 벤더가 그 표준을 따르겠는가? 그리고 자료에서 언급하고 있는 대부분의 스펙들은 아직 제대로 구현도 안되어있거나 막 구현되어서 스펙상으로도 문제가 많고 상호운용성 측면에서 전혀 테스트해본 적 없는 제품인데 BEA의 웹로직이나 웹스피어에서 정도만 구현되었다고 어떤 의미가 있겠는가?
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

e-Business의 단계 Enterprise

나는 내가 개발하고 있으며 주된 관심사항인 e-Business 인프라 구축에 있어서 다음 단계를 언급하기를 즐긴다. 펜타테크놀로지 홈페이지에서 예전에 읽은 내용이기도 하다. e-Business의 단계는 다음과 같다.

1. 웹 통합 (Web Integration) 첫번째로 기업의 입장에서 보았을 때 웹은 단지 상품을 진열하는 카탈로그와 기업을 간단하게 소개하는 정도의 기능만을 담당한다. 여기에 더해져서 회사 내부의 특정 정보나 소비자가 필요한 제한된 정보를 웹을 통해 제공한다. 아주 제한된 내용이 회사 내부와 고객을 연결시켜준다.

2. 웹 트랜잭션 (Web Transaction) 이 단계에서는 웹이 단순히 카탈로그 수준에 머무는 것이 아니라 고객과 상호작용을 하여 수익을 창출한다. 현재 대부분의 시스템이 이 수준에 머물러있다. 이 단계의 최고 단계는 기업이 내부 시스템을 완전 통합하고 웹을 통해 긴밀하게 연결되어있으며 고객이 필요로 하는 것들이 기업 내부와 긴밀하게 통합되어 관리된다.

3. 웹 협업 (Web Collaboration) 이것이 바로 마지막 단계로서 웹을 통해 기업간에 협업을 하여 궁극의 공생적 마케팅 목적을 달성할 수 있다. 일어날 수 있는 비즈니스의 형태는 기존의 B2B 거래를 완전 수용함은 물론이고 새로운 비즈니스도 동적으로 창출이 가능하다.

나는 가끔 이 세가지 단계를 떠올리며 묘한 웃음을 짓는다. 확실하였던 것은 1번째와 2번째 단계일 것일진대 그 각 단계마다 IT업계가 매우 큰 호황을 누렸음을 알 수 있다. 그래서 3번째 단계가 곧 올 것이며 오로지 이것만이 IT가 다시 설 수 있는 기회인 것이라며 그 많은 기업들이 웹서비스에 매달리고 있다. 하지만 3번째 단계에 대한 섣부른 희망은 금물이다. 우선 3번째 단계가 제대로 정착이 되려면 기존의 B2B에서 일어나는 그 수많은 거래 형태(Business Process)와 정보(Business Information Element)들이 표준화되어야한다. 이것은 단지 그냥 어렵겠구나 하는 정도가 아니다. 나는 상상할 수 조차 없다. 절대 잘 모르고 허세만 부릴 줄 아는 IT벤더들의 호언장담을 믿으면 안된다. B2B에서의 통합을 바벨탑을 세우는 것에 비교하는 글이 있을 정도이다.

프로젝트를 진행하고 관련된 사람들의 이야기를 들을 때마다 입이 벌어지곤한다. '과연 어느 세월에..' 하지만 이렇기 때문에 오히려 희망이 있고 더 많은 즐거움이 있는 것은 아닐까? 혹은 이러하기 때문에 더욱 준비할 수 있는 시간도 벌 수 있는 것이기도 한 것이다. 혹시 나와 같이 이 길을 걸어볼 사람은 없는지? ^^
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

기술자체가 브랜드인 세상 IT

어느 순간부터 나는 기술이 가져다주는 실제적인 효용성보다는 그 기술이 주는 가능성과 희망만으로 떼돈을 버는 기업들이 많다는 것을 깨달았다. 3년전 채 여물지도 않은 블루투스기술을 에릭슨이라는 회사는 그렇게도 그 희망과 가능성만으로 홍보하였고 내가 몸담았던 힘없이 작은 벤처회사는 그 희망에 솔깃하여 막대한 돈을 로열티를 줘가며 그 기술의 보잘것없는 정보들을 사왔다. 우리는 시장이 형성되지도 않은 블루투스 기술을 응용하여 제품을 만들었지만 결과는 에릭슨같은 회사만을 배불렸을 뿐이었다. 그런데 이런 현상은 비단 IT에만 있는 것은 아니라는 것을 깨닫는 데는 별로 오래걸리지 않았다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

보안은 더이상 별책부록이 아니다 Enterprise

웹서비스라는 놈이 있기 전에는 보안이라는 것은 사실 일반 개발자의 입장에서 보았을 때 크게 문제가 되는 기술은 아니었다. 제품을 개발하던 홈페이지를 구축하던 보안은 항상 나중에 미뤄도 되는 문제였고 따로 담당해주는 네트워크 전문가가 있었다.

사실 그랬다. SSL이나 IPSec이라는 무적의 프로토콜 수준의 암호화 프로토콜도 있었고 PKI기술만 적용한다면 굳이 애플리케이션의 비즈니스 로직에서 보안을 심도있게 고민하며 개발해야할 필요는 없었다. 보안? 항상 중요하다고 생각하지만 잠시 신경꺼주셔도 좋습니다 하는 게 보안아니었나 싶다. 그랬던 것이 웹서비스라는 놈이 대두되면서 문제가 발생하기 시작하였다.
아니 웹서비스 이전에 기업들의 IT 인프라의 성숙도가 다 같이 높아지면서 보다 높은 효용을 발생시킬 수 있는 전략적 제휴같은 공생적 마케팅(Symbiotic Marketing) 전략에 대한 요구가 높아져갔다. 이러다보니 예를 들어 우리 주위에서 흔히 볼 수 있는 형태의 기업간 협력, 카드사와 항공회사 간에 공동으로 행해지는 마일리지제도 같은 것들이 다반사가 되었다. 보다 동적인 기업 전략과 전술을 구사하기 위해서는 이러한 기업간 협력의 자유로움이 필요하였고 여기에 웹서비스라는 서비스들간의 자유로운 접착제 기술이 화려하게 대두하게 된 것이다.
문제는 이렇게 화려하게 대두된 웹서비스 기술을 그대로 적용하기에는 현재의 보안기술이 뒷받침을 해주지 못한다는 점이다. 즉 이제까지는 거의 대부분의 중요한 보안 이슈들은 프로토콜수준 이하의 것이었거나 Client Server간의 양자간의 메시지 교환에서만 다루어졌지 현재의 요구처럼 다자간의 메시지 교환에 필요한 보안 기술은 성숙되지 못하였다.
예를 들면 한 소비자가 여행사를 통해 자신의 스케줄을 주문하면 항공사에 좌석이 예매되고 동시에 카드의 마일리지가 올라가는 단일 트랜잭션이 발생한다고 하였을 때, 소비자와 카드회사와 항공회사와 여행사가 단일 트랜잭션에서 메시지를 주고받기 위해 준수되어야할 최소한의 보안적인 문제들 즉 인증, 암호화, 부인방지, 권한부여등의 문제들이 기존의 기술들로서는 해결할 수 없다는 점에 있다. 따라서 이러한 문제는 더이상 서비스 구축이 다 완료된 다음에 개발자가 네트워크 관리자나 서버관리자와 함께 고민해볼 문제인 것이 아니라 엄연한 비즈니스적인 문제이므로 구축 시작부터 아주 심도깊게 고민하고 비즈니스 로직에서 구체적인 방안을 미리 설계해놔야한다는 암시를 하고있다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

웹서비스 표준화기구 Enterprise

XML, WSDL, SOAP, UDDI와 같은 웹서비스 기본 표준 및 다양한 웹서비스 표준에 참여하고 있는 국제 기구로는 웹표준화 기구인 W3C, 마이크로소프트가 주도하고 있는 WSI, 인터넷 표준화 기구인 IETF 등이 있다.

W3C (The Worldwide Web Consortium)

W3C는 웹과 관련한 모든 표준화 작업을 수행하고 있다. W3C는 각 표준에 대한 스펙(specification), 가이드라인, 각종 툴 및 소프트웨어 등을 개발하고 있다. 웹서비스 분야에서 W3C는 XML의 표준화에 가장 큰 역할을 하고 있으며, 웹서비스를 사용/개발 가능케 할 수 있는 XML 기반의 아키텍처와 빌딩 블록(building block)을 개발하는데 주력하고 있다.

WSI(Web Services Interoperability Organization)

WSI는 지난 2월 마이크로소프트와 IBM 등 웹서비스 트렌드를 주도하는 대형 소프트웨어 벤더를 주축으로 결성되었다. 대형 소프트웨어 벤더들이 주도하는 만큼 아직까지는 웹서비스 표준화에 있어 가장 큰 영향력을 발휘하고 있다. WSI는 웹서비스간의 상호운용성(interoperability) 확보를 목표로 하고 있으며 표준 개발이나 새로운 표준 제안 보다는 웹서비스의 베스트 프랙티스 개발에 더 큰 비중을 두고 있다. WSI는 자체적으로 “프로파일(Profile)”이라고 명명한 웹서비스 관련 표준들의 패키지를 개발 중에 있으며, 프로파일링 작업이 끝나는 대로 본격적인 베스트 프랙티스 개발에 들어갈 예정이다. WSI의 베스트 프랙티스 개발의 최종 목적은 기업들에게 웹서비스 도입의 가이드라인과 로드맵을 제시하기 위한 것이라고 한다.

IETF(Internet Engineering Task Force)

IETF는 인터넷 기술의 확장을 위한 개발자들과 기술자들 중심의 국제 포럼이다. IETF는 특정 표준을 개발하거나 스펙의 표준화를 주도하기 보다는 기존의 표준에 대한 기술적 관점에서의 새로운 아이디어를 제공하는 역할을 한다. 웹서비스와 관련하여 IETF는 연결 중심의(connection-oriented) 메세징 프로토콜인 BEEP(Blocks Extensible Exchange Protocol)을 제시했으며, 이미 BEEP에 대한 SOAP 맵핑 정의가 완료된 상태이다.

그 밖에 OASIS(Organization for the Advancement of Structured Information Standards), 로제타넷(Rosettanet), OBI(Open Buying on the Internet), OAGI(Open Alliance Group, Inc.) 등이 웹서비스 표준 및 웹서비스 지원 표준화 작업을 진행 중에 있다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

XKMS에 대하여 Enterprise

XML서명은 결국 두가지 행위로 구분할 수 있다. 문서를 키를 이용하여 서명하는 행위(Signature)와 문서를 받아서 공개키를 이용하여 다이제스트값이 맞는지 확인하는 행위(Validation,Authentication)이다. 그런데 과연 이 키의 Validation은 어떻게 할 수 있을까? 즉 이 키의 소유자가 믿을 수 있는 이의 것인지 아닌지를 어떻게 보장할 수 있을까? 그것은 CA(Certificate Authority)가 하는 것이다. 즉 키를 관리하고 신원을 보장하는 여러가지 행위를 서비스하는 곳이 CA 이다.
하지만 이제까지는 이러한 PKI관련 기술들이 일정한 표준이 존재하질 않았다. 키를 관리하는 방법도 제각각이고 키조차도 서로 호환이 안되어 여러 인증서를 가지고 있어야하는 경우가 비일비재하였다.
XKMS는 XML 및 웹서비스를 이용하여 키를 관리하고 Validation할 수 있는 서비스 에 대한 스펙이다. VeriSign과 IBM, MS등이 참여하여 만들고 있는 이 표준은 PKI분야의 일대 혁명과도 같은 사건이다.
XKMS는 크게 두가지로 나뉠 수 있는데 첫번째가 X-KISS 두번째가 X-KRSS이다. X-KISS는 키에 대한 정보를 제공하는 서비스에 대한 것이고 X-KRSS는 키의 생명주기를 관리하는 서비스에 대한 것이다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)
이전 51 52 53 54 55 56 57 58 59 60 다음

프로필

밥값하는 IT 아키텍트가 되기 위해 노력중입니다. 연락처: calmglow at gmail.comby Calmglow
이글루스 피플

카테고리

최근 트랙백

RSS

RSS

태그

태그 전체보기

Google Analytics

calmglow.egloos.com is powered by Egloos. Subscribe to RSS. Skin designed by calmglow.