웹을 연결한다 Yahoo Pipes
방금 야후에서 잠깐동안 파이프서비스를 오픈했었다는 내용으로 애자일이야기에 해당내용이 떴다.
매우 고무적인 얘기이자 몸이 떨릴만큼 기쁜소식..으로 정말 감격스럽다..
간단히 설명하자면 웹에서 일종의 UI와 주어진 단어+룰로 매쉬업을 만들어 갈 수 있다.
웹에서 매쉬업을 만드는게 별거인가 싶지만 개발환경에서 만드는 것과 이것과는 완연한 차이를 가진다.
개념과 기술간의 격차.. 의미론적 거리를 축소하자는 것이 현세대까지의 고민이였고,
야후의 파이프는 넘을 수 없는 벽을 이미 넘어서기 시작한 시점으로 매우 중요한 의미를 나타낸다.
게다가 작은 개인의 시도가 아니라 메이져사가 급변하는 달아오르는 시장에서 꺼내들은 카드란거...
이 '파이프'라는 것은 일종의 디스크립션 랭귀지이자.. 프로세스이자.. 비즈니스이다.
현재와 같이 기술에 종속되어 오로지 비즈니스개념들간
수직적 layer를 수립하고 컴포넌트를 만들던 것은 필수가 아니라 선택가능한 방법중 하나가 될 수 있다.
layered architecture안에서 도메인이 일정그룹안에서 고정된 위상을 갖기 보다
구문내에서 상대적인 위상을 갖는 형태로 갈 수 있는 자연스러운 환경이 제공되었다고 볼 수 있다..
결과적으로 기술에 대한 고민보다는
어떻게 서비스, 이벤트를 구성하느냐, 서비스의 크기나 구성에 대한 고민이 관건이다.
grid computing, os service, dbms service, aop service, spring service, messaging service..
필요한 것은 서비스로 올려서 구성하고, 그 구성(파이프이든 뭐든..)을 제어하는 또 다른 파이프..
프로세스, 서비스, 지능망.. 기타.. 개발자라면 현재 개발관련 요소들을
모두 end user가 이해할 수 있는 수준에서 제어 가능해진다는 얘기다..
말많은 SOA, ESB면 장땡일 듯 밴더에서 떠들어댔던 SOA는 저리가라..
(SOA에서 위치투명성을 보장하기 위해 'ESB'라고 이름까지 붙이는 제품을 구매해야할까..
(ESB요건에 해당하는 서비스를 결합하면 그만이지.. 쩝..
이것이 바로 SOA의 1차적인 형태.. 별거아니네 비웃고 넘어가지 말길 바란다..
근 ~년내 대중화될 개발환경과 컨텐츠 생산형태의 하나의 단면이자.. 미래이다.
3년정도 걸리지 않을까 싶은 건 본인의 예상.. 빨라지면 빨라지지 느려지진 않을 듯..
(다음단계까지 가는데는 특별히 구분할 수 없이 스르륵~ 이동할 것이다..
(이 다음형태에 대한 얘기는 추후에..
다만, 요 이틀전 매쉬업에서도 썼다 싶이
관건은 표현이 얼마나 자유롭고 다양하게 쓸 수 있는지와 기본제공서비스와의 결합정도이다.
야후 파이프는 주어진 notation, 결합형태, 파이프로 분명 표현에 한계가 있다.
이와 같은 표현은 기존 프로그래밍 언어와 같이 개념-변환-랭귀지..의 중간과정을 거쳐야 한다.
변환과정을 떨궈내기 위해서는 개념-랭귀지가 일치하거나,
변환을 못느낄만큼의 풍족한 서비스가 다양한 notation과 결합되어 제공되어져야 한다..
그리고 비즈니스 프로세스 스펙은 경쟁사들이
'서비스 게이트로써의 경쟁우의를 점하기 위한'..
차별요소로 자리매김하기 때문에 표준화되지 않을 것이다..
시간이 지나가며 일반사용자와 고급사용자에게는
표현의 직관성과 표현능력의 고급화가 한계로 다가올 것임은 자명하고..
이런 의미에서 J-language 혹은 그와 비슷하게
일관성과 개념=랭귀지..와 같은 언어가 디스크립션 랭귀지가 되고,
그것을 UI에서 쉽게 구사할 수 있는 야후파이프와 같은 것이 제공되어져야 한다는 것이 본인의 생각..
p.s 개인적으로 2001년에 회사에서 웹서비스기반 WFMS를 기획하고 만들 때 목표로 했던 것이라서 더욱.. T-T
당시에는 아는 것도 하나 없이 꿈에만 부풀었는데다가 무리한 목표에 이것저것 필요한게 없어서..
막말로 이것저것 만들다보니 테이블-서비스간 맵핑스키마만들어서 돌리는 어정쩡한 or맵퍼도 만들어야 했고,
xpdl 커스터마이징도 하고 그걸 읽어들여서 프로세스를 흘리기 위해 또 별 잡짓을 해야 했던...;;
UI도 swing으로 제공했었던;; 이짓저짓하면서 dtd파서, 스키마 파서도 만들었었다.. DOM에 이갈린 옛날T-T
그러나 경험도 없고 필요한 것도 찾는 소질도 없어서 어색한 솔루션을 만들다 실패.. 하하
좋은 추억이고 좋은 실패였다.. 같이 실패했던 분들 잘 지내시려나~ :)
방금 야후에서 잠깐동안 파이프서비스를 오픈했었다는 내용으로 애자일이야기에 해당내용이 떴다.
매우 고무적인 얘기이자 몸이 떨릴만큼 기쁜소식..으로 정말 감격스럽다..
간단히 설명하자면 웹에서 일종의 UI와 주어진 단어+룰로 매쉬업을 만들어 갈 수 있다.
웹에서 매쉬업을 만드는게 별거인가 싶지만 개발환경에서 만드는 것과 이것과는 완연한 차이를 가진다.
개념과 기술간의 격차.. 의미론적 거리를 축소하자는 것이 현세대까지의 고민이였고,
야후의 파이프는 넘을 수 없는 벽을 이미 넘어서기 시작한 시점으로 매우 중요한 의미를 나타낸다.
게다가 작은 개인의 시도가 아니라 메이져사가 급변하는 달아오르는 시장에서 꺼내들은 카드란거...
이 '파이프'라는 것은 일종의 디스크립션 랭귀지이자.. 프로세스이자.. 비즈니스이다.
현재와 같이 기술에 종속되어 오로지 비즈니스개념들간
수직적 layer를 수립하고 컴포넌트를 만들던 것은 필수가 아니라 선택가능한 방법중 하나가 될 수 있다.
layered architecture안에서 도메인이 일정그룹안에서 고정된 위상을 갖기 보다
구문내에서 상대적인 위상을 갖는 형태로 갈 수 있는 자연스러운 환경이 제공되었다고 볼 수 있다..
결과적으로 기술에 대한 고민보다는
어떻게 서비스, 이벤트를 구성하느냐, 서비스의 크기나 구성에 대한 고민이 관건이다.
grid computing, os service, dbms service, aop service, spring service, messaging service..
필요한 것은 서비스로 올려서 구성하고, 그 구성(파이프이든 뭐든..)을 제어하는 또 다른 파이프..
프로세스, 서비스, 지능망.. 기타.. 개발자라면 현재 개발관련 요소들을
모두 end user가 이해할 수 있는 수준에서 제어 가능해진다는 얘기다..
말많은 SOA, ESB면 장땡일 듯 밴더에서 떠들어댔던 SOA는 저리가라..
(SOA에서 위치투명성을 보장하기 위해 'ESB'라고 이름까지 붙이는 제품을 구매해야할까..
(ESB요건에 해당하는 서비스를 결합하면 그만이지.. 쩝..
이것이 바로 SOA의 1차적인 형태.. 별거아니네 비웃고 넘어가지 말길 바란다..
근 ~년내 대중화될 개발환경과 컨텐츠 생산형태의 하나의 단면이자.. 미래이다.
3년정도 걸리지 않을까 싶은 건 본인의 예상.. 빨라지면 빨라지지 느려지진 않을 듯..
(다음단계까지 가는데는 특별히 구분할 수 없이 스르륵~ 이동할 것이다..
(이 다음형태에 대한 얘기는 추후에..
다만, 요 이틀전 매쉬업에서도 썼다 싶이
관건은 표현이 얼마나 자유롭고 다양하게 쓸 수 있는지와 기본제공서비스와의 결합정도이다.
야후 파이프는 주어진 notation, 결합형태, 파이프로 분명 표현에 한계가 있다.
이와 같은 표현은 기존 프로그래밍 언어와 같이 개념-변환-랭귀지..의 중간과정을 거쳐야 한다.
변환과정을 떨궈내기 위해서는 개념-랭귀지가 일치하거나,
변환을 못느낄만큼의 풍족한 서비스가 다양한 notation과 결합되어 제공되어져야 한다..
그리고 비즈니스 프로세스 스펙은 경쟁사들이
'서비스 게이트로써의 경쟁우의를 점하기 위한'..
차별요소로 자리매김하기 때문에 표준화되지 않을 것이다..
시간이 지나가며 일반사용자와 고급사용자에게는
표현의 직관성과 표현능력의 고급화가 한계로 다가올 것임은 자명하고..
이런 의미에서 J-language 혹은 그와 비슷하게
일관성과 개념=랭귀지..와 같은 언어가 디스크립션 랭귀지가 되고,
그것을 UI에서 쉽게 구사할 수 있는 야후파이프와 같은 것이 제공되어져야 한다는 것이 본인의 생각..
p.s 개인적으로 2001년에 회사에서 웹서비스기반 WFMS를 기획하고 만들 때 목표로 했던 것이라서 더욱.. T-T
당시에는 아는 것도 하나 없이 꿈에만 부풀었는데다가 무리한 목표에 이것저것 필요한게 없어서..
막말로 이것저것 만들다보니 테이블-서비스간 맵핑스키마만들어서 돌리는 어정쩡한 or맵퍼도 만들어야 했고,
xpdl 커스터마이징도 하고 그걸 읽어들여서 프로세스를 흘리기 위해 또 별 잡짓을 해야 했던...;;
UI도 swing으로 제공했었던;; 이짓저짓하면서 dtd파서, 스키마 파서도 만들었었다.. DOM에 이갈린 옛날T-T
그러나 경험도 없고 필요한 것도 찾는 소질도 없어서 어색한 솔루션을 만들다 실패.. 하하
좋은 추억이고 좋은 실패였다.. 같이 실패했던 분들 잘 지내시려나~ :)



덧글
민재 2007/02/09 00:50 # 삭제 답글
이젠 end-to-end 가치사슬에서 기술들을 적절하게 엮는게 핵심이 되는 시대인듯...
cavin 2007/02/09 01:13 # 답글
다시 오픈됨.. 느리고 UI사용법이 직관적이지 못함..그럼에도 불구하고 그것들을 뒤덮고도 남을만큼의 의의..
astraea 2007/02/09 11:31 # 삭제 답글
잘 모르는 제가 그냥 봐도 상당히 획기적인 시도 같아보이긴해요무엇보다 야후에서 시작했다는 것도,,,,
어떤 결과물이 튀어나올지 두근두근