제목 : SOA에 대해서 이야기를 해봤으면 합니다.
글쓴이: 조대협(guest) 2006/04/17 15:39:04 조회수:6438 줄수:9 |
|
요즘 SOA에 대한 이야기도 많고..
금년 들어서 슬슬 SOA를 기반으로 시스템을 구축하는 곳이 종종 보입니다.
실제 이 SOA가 구축 가능한 기술인지.. 아니면 CORBA의 전철을 밟을 개념인지..
그리고 SOA를 어떻게 구축하면 좋은지.. SOA에 대한 전반적인 이야기를 나눠보고자합니다.
많은 필드 엔지니어분들의 조언 부탁드립니다.
|
제목 : Re: ...
글쓴이: 일본사는넘(guest) 2006/04/29 09:30:37 조회수:1366 줄수:43 |
|
안녕하셔요? 조대협님. 예전에 님이 관리하시던 사이트에서 일본통신원으로 잠시 활동했던
넘입니다. (당시엔 justjava라는 아이디를 사용했죠.)
SOA는 당연히 구축가능한 기술이라고 생각합니다.
다만 기술적인 구축가능성과는 별개로, 진짜 문제는 관리나 정치적인 문제라고 생각합니다.
SOA를 구축하기 위해 유리한 기술은 있으나 필수적인 특별한 기술이 있는게 아니고, 그보다는
개념과 규칙의 문제라고 생각합니다. 좀 무리하게 말하자면, C나 VB만으로도 SOA는 가능하죠.
말 그대로 아케텍쳐니까요.
SOA에 대한 과대망상도 문제인데 각 벤더나 애널리스트들의 무분별한 선전과 그로 인해
비롯된 오해들이죠. 더불어 웹서비스가 SOA의 핵심기술로써 인식되는 경우가 많으나
웹서비스 기술 자체가 미정비된 부분이 많아 웹서비스만으로 SOA를 실현하는 것은 (아직은)
미션 크리티컬한 시스템에서는 불가능하죠. 따라서 JMS, File/FTP같은 기존 기술과의 연계가
필요합니다.
참고로 최근 화제가 되고 있는 SOA의 핵심부품 중의 하나인 ESB도 아직은 과도기적인 여러
문제를 가지고 있으며 그 문제의 해결엔 기술만이 아니라 위에 언급한 정치적, 관리적인
통제가 더 중요합니다. 그리고 이러한 과도기는 적어도 10년은 지속될 것입니다(적어도
일본에서는). 하지만 대부분의 시스템이 점차 SOA로 이행해 갈 것임에는 틀림이 없다고
생각합니다. 이것은 프로그래밍 언어의 세상이 이전의 절차적 언어에서 객체지향의 언어로
시프트해 온 것과 비슷한 경우라고 생각합니다. 객체지향이 전능한 것은 아니라도 그에
맞설만한 세련된 개념이 없었던 것과 마찬가지로 시스템 아키텍쳐의 분야에서 현재로는
SOA 이외에 별달리 대안이 없죠.
SOA에서 강조하는 것의 하나로 SOA의 가장 강점으로 꼽히는 것이 비지니스와 IT의 갭을
최소화하는 유연한 시스템을 만든다는 것인데 이걸 실제로 실현하자면 -개인적으로는-
SOA만이 아니라 BPM이 필수라고 생각합니다. 그를 위해서는 BPM을 위한 프로세스 모델링,
모니터링 및 개선 활동, 그리고 그에 따른 어플리케이션 설계, 서비스 설계, 컴포넌트 설계등의
작업이 필요합니다만 그러한 스킬은 고객사는 물론 기존의 SIer들이 가지고 있는 스킬셋과도
상당히 차이가 나는게 현실이라 도입 자체가 어려운 것이 또 하나의 문제이기도 합니다.
(일부 벤더들은 빅뱅식이 아니라 서서히 단계적으로 SOA를 도입할 수 있다고 선전하지만
SOA도입의 초기 투자비용이 기존 시스템에 비해 높고 그 투자비용의 효과를 비지니스적인
결과로 측정해야 하는 SOA의 특성상, 서서히 단계적으로 도입하는 것은 현실적으로 무척
어렵습니다. 결국 일부 고객들이 'SOA는 단지 버즈워드이다'라고 투덜대는 원인을
제공하고 있을 뿐이죠. 쉽게 말하면, 벤더들이 제 목 조르고 있는 겁니다.)
일본의 경우도 이른바 SOA를 도입한 사례가 늘어가고 있으며 저 또한 그러한 프로젝트에
참가해 오면서 여러가지 느낀 점이 있습니다만 이곳에다 한번에 모두 풀어 놓기는 어렵군요.
위에 써 놓은 것을 보니 사고과정에 대한 설명이 없이 결론만을 써 놓은지라 순수히 긍정
하기엔 어려움이 있으리라 생각됩니다. 필요한 부분에 대해서는 반론이나 추가설명을
부탁드립니다.
|
제목 : Re: SOA..
글쓴이: 조대협(guest) 2006/05/02 11:29:29 조회수:3464 줄수:31 |
|
justjava님.. 정말 오랜만입니다.
기억하고 말구요...
이렇게 또 만나뵙게 되니까는 반갑네요.
말씀하신데로.. SOA가 아직 성숙하지 않은 기술이라는 데에는 상당 부분 동의합니다.
WebService 스펙 자체가 아직 완벽하게 정의되지 않았고..
벤더마다 이 WebService (특히 WS* 이 되겠지요.)의 지원폭이 상당 부분 다른 만큼 Service
간 연동이 문제가 많은것이 사실입니다.
그리고 FTP나 JMS의 도움이 필요하다고 이야기 하셨는데. 도움이 필요한것은 사실이지만
WebService = SOA 가 아닌 이상 FTP나 JMS도 SOA 구현 기술의 한 부류로 볼 수 있지 않을까 싶습니다.
Service Ochestratin에 필요한 BPM의 필요성도 대부분 동감합니다.
요즘 BPM이 재미있는것중에 하나가 Business Oriented BPM과 Application Oriented BPM이 있더군요.
Business Oriented BPM의 경우 현재 SOA가 지향하는 BPM과 일맥상통한다고 볼수 있습니다.
그러나 Application Oriented BPM은 SOA 내의 Sub Process를 구현하거나 또는 ESB 아래 Layer의
각 서비스들을 Integration하는데 더 큰 의미가 있지 않을까 싶습니다. EAI에 가깝다고 봅니다만.
SOA가 분명히 매력적인 아키텍쳐임에는 분명하지만!!
아직 국내 개발자나 관련 관리자들의 SOA 이해도가 매우 낮다고 생각이 되네요..
국내에서 수행중인 몇몇 SOA 프로젝트를 봐도 그런 느낌을 지울 수 가 없네요..
SOA는 각 개개별 구현 기술도 중요하겠지만.
SOA로 시스템을 이전하는 과정은 기존 방식에 비해서 길고 오랜 투자가 필요하다고 생각됩니다.
개념대로라면 SOA는 나중에 그만한 ROI로 보답을 하겠지요..
오랜만에 justjava님 만난 기쁨에.. 두서없이 글을 써보았습니다.
나중에 시간이 될때.. SOA에 대해서 다시금 체계적으로 정리해볼까 합니다.
좋은 의견 감사드립니다.
|
제목 : Re: BPM
글쓴이: 조대협(guest) 2006/05/02 11:35:33 조회수:1032 줄수:21 |
|
글을 써놓고.. 또 생각이 들어 추가합니다.
BPM에 대한 이야기 인데..
"개인적인 생각" 으로 BPM이 필요하시다고 생각하셨는데..
저는 고급 SOA 에서는 BPM이 반드시 필요하다고 생각을 합니다.
실제로 SOA 자체를 소개하는 많은 책이나 문서를 보면 "민첩성(Agility)"구현을 위해서
BPM을 대안으로 필수적으로 제시하고 있습니다.
BPM이외에..
SOA가 현실화 되기 위해서는
데이타들을 서비스화 해주는 솔루셔..
즉 Data Integration Solution이 필요하다고 생각이되고..
특히 복잡한 Rule을 처리를 Encapsulate하기 위해서, 복잡한 기업 업무내에는 Rule Engine도
필요하다고 판단이 됩니다. 물론 Service 화를 제공하는 솔루션이 필요하겠지요..
좋은 의견들 부탁합니다.
같이 이야기 해보도록 하지요.
|
제목 : Re: SOA...
글쓴이: 일본사는넘(guest) 2006/05/03 02:25:10 조회수:1031 줄수:75 |
|
>> WebService = SOA 가 아닌 이상 FTP나 JMS도 SOA 구현 기술의 한 부류로 볼 수 있지 않을까 싶습니다.
동감합니다. 제 본 글에서 '웹서비스가 SOA의 핵심기술로써 인식되는 경우가 많으나' 라고
한 부분은 일반적인 인식이 그러하다는 지적이었습니다.
다만, 서비스의 정의를 어떻게 하느냐에 대해서는 여러가지 이론이 있을 수 있으나 거의
공통되게 거론되는 부분은 이른바 서비스가 '시스템간 호환성이 있는 표준인터페이스'로
공개된다는 부분일 것입니다. 제가 고민하고 있는 부분은 여기서 도대체 무엇을 '표준'이라고
정의할 것인가 하는 점입니다. 진정한 시스템간 호환성을 생각한다면 웹서비스(의 완성형)
정도일까요? 하지만 현재는 JMS도 엄연한 서비스의 인터페이스로 자리잡고 있습니다. 이
경우 자바의 세계에서 호환성이 있으면 그건 표준의 범주에 들어간다고 할 수 있을까요?
조직의 관점에서 본다면, 어떤 부서에서 독자 프로토콜을 만들고 그 프로토콜로 부서내에서
서비스를 공개, 상호운용한다고 했을 때 그 서비스들은 표준인터페이스를 갖추지 않았으므로
서비스가 아닌걸까요? 그럼 그 프로토콜을 호환성이 높은 웹서비스로 대체하면 그 순간부터는
서비스라고 할 수 있는 걸까요?
즉, 표준인터페이스에서의 표준이라는 정의자체가 불명확하다고 생각합니다. '범용'이라고
하면 조금 더 이해하기 쉽겠습니다만..(이땐 또 범용의 정의를 할 필요가 있죠.)
ESB의 관점에서 생각하면, ESB의 선전문구 중에 하나가, EAI툴로 구축된 시스템통합이
각종 네이티브 프로토콜을 지원하는 과정에서 지나치게 비대해져, 관리가 불편한 반면,
ESB는 표준인터페이스로 공개된 서비스들만을 연계함으로써 슬림하게 관리할 수 있음을
주장하고 있었습니다. (물론 이게 다는 아니지만)
하지만 최근 들어 소개되는 각 벤더들의 ESB제품들은 점점 지원하는 프로토콜을 늘려,
급기야는 RMI, POJO invocation도 지원을 한다는군요.
RMI는 표준인터페이스일까요? POJO는 상호운용성이 있을까요?
(물론 ESB에는 프로토콜변환이란 기능이 있습니다만 그건 EAI툴에도 있지요.)
이렇게 되면 ESB와 EAI툴의 차이는 어디에서 찾아야 하는 걸까요?
결국 시스템적인 관점에서의 서비스란, 표준 인터페이스 운운보다는 Interface와
Implementation을 명시적으로 분리하는 데서 그 의의가 있지 않는가 하는 생각이 듭니다.
(물론 기존 기술과 서비스의 설계/실장 단위라는 부분에 대해서는 이론이 있을 수 있지만
그건 BPM이란 별도의 글타래에서 따로 기술하겠습니다.)
말씀하신 '데이터 인테그레이션에 대한 솔루션'은 이미 작년부터 몇몇 벤더에서 제품을
내놓고 있는 것으로 알고 있습니다. 더불어 각 벤더들의 Reference Architecture를 보면
조금씩 차이는 있더라도 서비스를 여러 계층으로 분류하고 있는 것은 말씀하신 부분에
대한 필요성을 인식하고 있는 것이라고 생각이 듭니다.
(모 벤더의 경우 이를 'Data & Information Service layer'라고 표현을 하더군요.)
(근데 이게 또,'서비스는 비지니스적인 의미를 가지는 단위'라는 일반적인 서비스의
정의와는 모순되지요. 데이터 액세스나 통합하는 기능이 비지니스적인 의미를 가지는가?
하는 질문이 나오니까요. 그 점에 대해서는 SOA의 Reference Architecture를 온통 서비스로
도배한 B모사 보다는 서비스와 컴포넌트로 구분한 I모사의 정의가 더 수긍이 갑니다만..)
SOA에 대한 이해도에 대해서라면 이곳 일본도 아직 굉장히 낮은 수준입니다. 전 개인적으로
일본에서 그래도 SOA라면 대충 이름을 알아주는 사람들을 몇명 알고 있습니다만 그들의
이해도조차도 가끔 놀라울 정도로 낮습니다. 단지 미국에서 작성해준 문서들을 읽고
전달하는 수준에 불과한 사람들이 많습니다. 이른바 opinion leader라는 사람들이 이런
상황이니 고객은 말할 것도 없지요. (물론 뛰어난 사람도 있습니다^^;)
작년엔가, 미국에서 온 모사의 SOA컨설턴트들과 얘기를 한 적이 있었는데,
"SOA의 ROI에 대해 고객들의 질문이 많다. 이 경우 뭐라고 답해야 하나?"
고 물었더니
"SOA의 효과는 시스템에서 나오는 것이 아니다. 비지니스의 효과로 나오는 것이다. 고로,
SOA의 ROI에 대해 묻는 것은 바보같은 질문이다"
라고 답하더군요.
('그걸 누가 몰라 이자식아! 근데 그렇게 고객에게 대답하리?' 하고 멱살을 쥐어 흔들고 싶은
충동을 참느라 힘들었습니다.)
이하는 개인적인 경험에 근거한 얘기인지라 객관성은 떨어집니다만, 일본에서 이른바
SOA의 도입사례 중 흔히 보이는 케이스는 ESB를 도입하면서 시스템간의 연계를 서비스로
랩핑하고 있는 경우입니다. 기존의 무질서한 시스템간 연계를 개선하려는 움직임의 일환이죠.
그로써 시스템간의 연계부분에서부터 서서히 SOA화 해 간다는 개념입니다.
아직 BPM의 수준까지는 고려하고 있는 곳이 적다고 생각합니다.
이상, 개인적인 의구심이나 잘 모르는 부분을 중심으로 적었으므로 의문형의 문장이
많습니다. 이해하고 읽어 주시길..
(적고 보니 얘기가 중구난방이군요..)
|
제목 : Re: Application Oriented BPM
글쓴이: 일본사는넘(guest) 2006/05/03 03:09:20 조회수:915 줄수:52 |
|
SOA를 얘기하기 위한 글타래이지만 BPM 역시 SOA의 중요한 요소라는 데 동의했으므로
적겠습니다. (이번 글은 주로 질문에 가까울거 같군요.)
먼저 말씀하신 'Application Oriented BPM'라는 용어는 제가 처음 접하는 용어로 잠깐의
구글링으로는 그 의미를 정확히 알 수가 없군요.
다만, 제가 아는 BPM의 지식에서는 BPM에는 비지니스 전문가와 시스템의 전문가가 협조작업을
해야 한다고 하고 있습니다. 이걸 SOA와 연계시키면 다음과 같이 이해가 됩니다만..
SOA에서 말하는 '서비스를 이용함으로써 비지니스 프로세스의 변경에 유연히 대응이 가능'
하기 위해서는 비지니스 프로세스의 각 노드를 서비스로 구성해야겠지요. 서비스에 레이어가
있듯이 비지니스 프로세스에도 추상도에 따른 레이어가 존재하고, 비지니스 전문가는 시스템의
관점에서 볼때는 보다 추상화 된 이른바 비지니스적인 의미가 있는 레이어의 프로세스와
서비스를 다루게 됩니다. 이 경우, 비지니스적인 의미를 가진 서비스와 그로 구성된 비지니스
프로세스가 말씀하신 'Business Oriented BPM'이라면, 'Application Oriented BPM'이란,
시스템의 전문가가 보는 보다 하위 레이어의 비지니스 프로세스와 그 구성요소인 서비스
들이라고 이해가 됩니다. (혹 틀렸을 경우엔 지적해 주시기 바랍니다.)
비지니스 전문가가 시스템의 전문가가 아닌 이상, 또한 그 역도 성립하지 않는 이상,
비지니스 전문가에게 시스템적인 의미만을 가지는 서비스를 공개, 사용하도록 해도 의미가 없고,
시스템전문가에게 비지니스적 의미를 가지는 비지니스 프로세스를 변경하게 하는 것도 불가능하죠.
그런 관점에서는 Service Orchestration layer는 실은 Business Service Orchestration Layer와
Application Service layer로 조금 더 세분화해서 고려 할 필요가 있다고 생각합니다.
(적고 보니, ... 그 얘기가 이 얘기였나요?)
그리고 위의 두 세계는 엄연히 다른 언어를 사용하는 세계인만큼, 그 두 세계를 연결해
줄 사람들이 필요합니다만 현재로써는 거의 전무한 상황이 아닌가 합니다. BPM 자체가
아직 그다지 침투해 있지 않은 상황에서 SOA와 BPM을 동시진행하고자 하는 건 불가능에
가깝지 않을까요? (Composite Application을 그 사상대로 제대로 구현해 낼 수 있는 사람이
얼마나 존재할까요? (복수의 회사의 인재로 구성 된 팀이라면 가능하겠지요.))
그리고 아직 이곳에서 거론하고 있지는 않지만 서비스의 설계에 있어 그 류도를 어떻게
할 것인가 등, 방법론에 대해서도 아직 정설이 없는 상황이지요.
하지만 그렇다고 해도 전 SOA와 BPM은 보다 보급될 것이라고 봅니다.
이건 제 고객사 중의 한 곳의 매니저가 한 말인데,
'SOA의 효과가 검증된 바는 아직 없으나 대안이 없다. 그리고 지금 바꾸지 않으면 언제까지라도
아무것도 바뀌지 않는다'
라는 말이 현재의 상황을 잘 대변하고 있지 않나 합니다.
더불어 BPM에 대해서는 일본에서는 JSOX법이라는 새로운 법안이 통과되어 기업내 내부감사를
강화해야할 필요성이 있으므로 그 대응책으로써 BPM이 급속히 파급될 것으로 (개인적으로)
예상하고 있습니다.
(글 중에 일본어적인 표현이 많이 섞여 있다고 생각이 됩니다. 최근에 익힌 용어들이
한국에서는 어떻게 말해지고 있는지 모르는 부분들에 대해서는 일본어의 한자를 그대로
차용해서 사용하고 있습니다.)
(SOA나 BPM에 대해, 제대로 책을 읽거나 하기보다는-아예 안 읽은 것은 아니지만- 개인의
사고나 경험을 토대로 쓰고 있으므로 제가 적고 있는 내용의 객관성과 옳고 그름에 대해서는
절대로(!) 자신할 수 없습니다.)
|
제목 : Re: 수정..
글쓴이: 일본사는넘(guest) 2006/05/03 03:23:06 조회수:824 줄수:6 |
|
Business Service Orchestration Layer와 Application Service layer
를
Business Service Orchestration Layer와 Application Service Orchestration layer
로 수정합니다.
글 올리기 전에 한번 다시 읽어보는 습관을... (가져야 하는데..)
|
제목 : Re: 또 하나의 시도
글쓴이: 손님(guest) 2006/05/03 13:12:28 조회수:898 줄수:33 |
|
비즈니스 영역에서의 CBD 실패 사례를 고려해보면 SOA도
또하나의 마켓팅이 아닐까하는 의구심이 들긴 합니다.
하지만 분산이라는 개념이 대두될때 부터 십수년 전
가트너가 제시한 SOA는 비즈니스 IT의 나아갈 바임은 분명해 보입니다.
SOA가 기존의 CBD와 다른 점은 처음으로 비즈니스 관점에서
IT를 바라본다는 부분이라고 생각합니다.
그래서 아키텍쳐라는 표현을 사용하였겠지요.
SOA는 EA와 BPM을 함께 생각해야만 그림이 그려지는 개념인 듯 합니다.
비즈니스 담당자들은 통제할 수 없는 소스코드에서 비즈니스를 체계적으로 추출하여
통제가능한 선상에 놓고 싶어 하며 나아가 IT부서에 아쉬운 소리하지 않고
BPEL로 편하게 비즈니스를 생성, 조립하고자 할 것입니다.
이렇게 구축된 RTE에서 CEO는 기다리지 않는 경영을 하고 싶어할테구요.
이러한 기본적인 요구가 걸프전 이후 국방 IT를 체계적으로 관리하고자 시작된
ITA가 공공부문을 중심으로 차츰 현실화 되고 있고 그 구성요소인 EA
즉 IT와 비즈니스 룰을 적나라하게 까발린 전사아키텍쳐 구현을 위한
최적화된 아키텍쳐로 SOA가 대두되고 있는 상황입니다.
물론 SOA를 구현하는 최적화된 기술로 웹서비스가 거론되고 있기도 합니다.
벤더들은 SOA 구현을 위한 토털 기술셋으로 중무장하는 중이구요.
CBD의 실패 사례에서 반추해보면 SOA의 성패는 얼마나 비즈니스를 제대로 정립하고
개념을 혁신하여 서비스를 제대로 추출하느냐에 달려 있다고 생각합니다.
이는 컨설팅의 영역이라기 보다는 현업의 마인드 혁신이 필요한 사항이겠지요.
사용하는 IT가 아닌 IT화된 비즈니스를 생각하고 도출해낼 수 있는 역량을 갖추어야 하리라고 판단됩니다.
따라서 SOA는 벤더들의 선전처럼 점진적으로 나아갈 수 있는 ROI가 바로 보이는 개념이 아니라
CEO의 확실한 의지와 전사적인 혁신을 바탕으로 현업과 IT 인력의 의식이 전환된 상황에서
보이지 않는 그림을 그려나가야만 성패가 드러나는 아직 입증되지 않은 시도라고 결론을 짓고자 합니다.
|
제목 : Re: SOA
글쓴이: 조대협(guest) 2006/05/03 16:17:48 조회수:907 줄수:62 |
|
윗분이 쓰신 "벤더들은 SOA 구현을 위한 토털 기술셋으로 중무장하는 중이구요."
말이 참 재미있네요.. 중무장 맞는거 같네요..
이야기에 몇가지 논점이 있어서 나름데로 생각을 이야기 해보겠습니다.
* BPM & SOA
SOA에 Orchestration이 중요한 factor이기는 하지만 필수요소는 아니라고 봅니다.
대부분의 SOA에 대한 구조를 보면 기본적으로 Layering 모델을 취하고 있습니다.
그중에 흥미로운 분류 방법이 Enterprise SOA Service Oriented Architecture Best Practice
라는 책의 Layer 모델을 인용하면
Level 1. P2P
Level 2. Networked
Level 3. Enterprise
로 분류하고 있습니다. 100%는 맞다고는 볼 수 없지만 가장 현실적인 분류 방법이라고 봅니다.
각각 Level을 이야기 해보면
P2P는 말 그대로 각 서비스간을 직접 연결하는 방식입니다. 가장 구축이 쉽고 초보적인 형태입니다
SOA의 연계성이나 재사용성의 이득은 어느정도 포용하겠지만 Gorvernance나 Agility를 기대하기는 어렵겠지요.
Level2 Networked SOA는 이런 서비스를 중앙 집중형인 Hub & Spoke 방식과 같은 구조로 구현하고
Hub 부분에 Routing이나 Process를 구현하는 방식입니다. 이 Level이 ESB를 사용한 구조에 매우 적합니다.
Level 3는 이렇게 정리된 서비스들을 BPM으로 묶는 구조를 이야기 합니다.
각각 보면 Level 1,2,3가 SOA의 각각의 Layer하고도 매칭이 될 수 있겠지요.
그러나 제가 여기서 언급하고자 하는것은 BPM이 SOA에 필수는 아니라는겁니다.
물론 있으면 무지 좋겠지만요...
* ESB
다음으로는 ESB이야기를 해보지요.
ESB가 RMI등을 지원하는거에 대해서 EAI와 차이점을 찾는다...
ESB와 EAI제품이 비슷한거는 사실이지요.
연동이라는 점에서요.
그러나. 글쎄요. 아직 정리를 확실하게 못해드리지만 EAI와 ESB는 제가 보기에는 아주 틀린
역할을 한다고 봅니다.
EAI는 Tightly coupled되어 있고, 주로 연결은 JCA와 같은 Connector를 이용해서 고속의 트렌젝션
처리를 하지요..
그러나 ESB는 Loosly coupled되어 있고, WebService를 주프로토콜로 해서... 연계가 아닌
각 시스템간의 Service정리만을 목적으로 하고 있다고 봅니다.
나중에 좀더 정리가 되면 다시 한번 언급 드리고 싶은데요.
ESB가 EAI 시스템의 영향을 매우 많이 받은것은 사실이고.
EAI 시스템으로 ESB를 구성할 수 있는것도 사실입니다만
디자인된 역할이나 용도는 분명히 다르다고 봅니다.
* SOA 에 대한 개인적인 견해
SOA 솔루션과 WS-I,WS* 스펙들을 보면서 생각이 참 많습니다.
개념 자체는 너무나 훌륭합니다만, 개발자들이 소화해낼 수 있을지와...
또한 SPEC이 통일이 아직 안되었다는 점이 매우 마음에 걸립니다.
그러나 CORBA,IIOP같은 기술이나 CBD같은 분석/설계론 보다는
SOA가 더 현실성이 있다고 생각하고 있습니다.
SOA가 Function based programming(Structured Programming - ex C.. ) 에서 부터 시작되고 있는
Lego-ware (재사용성을 극대화한 소프트웨어 개발)를 구현하는 하나의 기술의 연장선에 있는 만큼
OOP 다음에 대안이 없는 현대 IT 현실상에서는 SOA가 충분히 검토 될 대상이라고 생각됩니다.
단한가지.. SOA로 가느냐 아니면 또 다른 Lego-ware 아키텍쳐가 대두 되느냐는 기술 상황을 봐야겠지요.
일하다 잠깐 커피 마시면서 쓰는거라서 내용에 두서가 없습니다. 이해해주시기를 바랍니다.
|
제목 : Re: Application Oriented BPM
글쓴이: 조대협(guest) 2006/05/03 16:23:11 조회수:939 줄수:22 |
|
* 아.. 그리고 Application Oriented BPM이라는 용어에 대해서 부연 설명 드립니다.
BPM이 말그대로 Business Process를 Modeling하기 위함이지만
실제 EAI 에서 보면 BPM은 시스템간의 연동을 위해서 사용이됩니다.
즉 BPM의 사용 주체가 Technical Engineer냐? 아니면 Business Consultant냐에 따라서
Application Oriented BPM과, Business Oriented BPM으로 나눴습니다.
SOA의 궁극적인 목적은 Business Consultant가 아주 적은 IT 지식으로도 Business Process를
Modeling할 수 있도록 하는데 있는데요.
그 아래에는 그만큼 Service를 잘 구성해야 한다는 것이 전제로 됩니다.
이를 위해서 Application Layer에서도 System을 통합하기 위한 Process가 필요하고
이런 subprocess들을 디자인하기 위한 BPM이 필요하게 됩니다.
구현 방식에서 저는 EAI등에 사용되는 BPM을 이 Layer에 두고 생각합니다.
Subprocess는 BPM술루션으로도 구현이 될 수 있지만, ESB에서 Process definition 기능들을
이용해서도 구현이 가능하고 이미 많은 vendor들의 solution들이 Application Level에
Process를 정의하기 위한 솔루션을 제공하고 있습니다.
아직까지 구체적은 용어들은 정의가 된곳이 없으나, 이미 구현 제품이 출시되었고,
Thomas Erl의 책에서도, 이 Subprocess의 개념등을 application layer에서 설명하는 개념이 있기
때문에 이에 대해 언급했습니다.
언제 술이라도 한잔하면서 같이 이야기 했으면 좋겠네요... SOA.. ^^
|
제목 : Re: SOA와 ROI에 대해
글쓴이: 미노(guest) 2006/05/03 19:35:28 조회수:1089 줄수:45 |
|
저도 잠깐 끼어들어도 되는지 모르겠네요.
위의 글에서 SOA와 ROI에 대한 부분은 제 개인적인 생각으로 분명 좀
맞지 않은 부분이라고 생각합니다.
SOA자체가 조대협님이 언급하신 민첩성(Agility)에 비중을 두고 있습니다.
결국 기업자체가 추구하는 이익추구에 있어서, IT적 투자가 어느정도의 ROI를
낼 수 있느냐를 판단하는것은 이미 시대착오적인 생각이라고 봅니다.
즉 이젠 기업에서 이익추구를 하는것은 투자대비 이익이 아닌,
좀 더 발빠르게 시장 환경에 대응하여 다른 기업보다 더 먼저 상품을 개발하고
그것을 바로 고객에게 제공할 수 있는 능력이라고 봅니다.
그러기 위해서는 기업에서의 IT통합은 반드시 이루어져야 하는 상황이며,
이것이 이제까지 진행되어왔던 EAI보다는 좀더 표준 지향적이며,
느슨한 연결을 제공해야 한다고 보여지며 때문에 Web Service가
아직 충분히 능력을 발휘할 단계가 아님에도 불구하고 SOA에서
중요하게 다뤄진다고 봅니다.
또한 BPM과 함께 Rule Engine의 도입은 통합된 서비스 자원을 효율적으로
도입하기 위해 필수불가결한 요소가 되겠구요.
제가 볼때 SOA의 가장 큰 문제점은, 좀더 근본적인 SOA의 이해를 바탕으로,
기업의 통합과, 서비스의 정의라고 생각합니다.
SOA에서 서비스를 만들어 내고 이용하는 사람들은 IT쪽이 아닌, 상품을 기획하고
개발하는 쪽이어야 한다고 봅니다.
그것을 기업IT통합이라는 과제로 IT에서는 지원을 해야 하는 몫이겠구요.
이 두가지의 만남이 사실은 참 묘연한 얘기입니다.
다들 아시겠지만, 실제 프로젝트의 성공요인중에 현업의 참여는 상당히 큰 몫을
참여합니다.
실패 또는 성과를 거두지 못하는 대부분의 프로젝트는 현업이 제때에 제대로 참여를
하지 못하기 때문에 발생하는 경우가 상당히 많은 상황에서,
SOA와 같이 IT적인 측면과 실무적인 측면이 상당히 강하게 얽혀있는 개념들은
분명 쉽지 않은 문제라고 보여집니다.
그져 SOA가 단순한 마케팅의 단어가 아닌, 제품을 선전하는 문구가 아닌
좀 더 실질적인 입장에서 비즈니스적인 관점과 함께 살펴야 하지 않나 싶네요.
음.. 쓰고 보니깐 너무나 당연한 얘기가 되어버렸네요.
더군다나 중간에 한번 불려갔다고 왔더니 무슨 얘기를 쓰고 있었는지도
기억이 가물가물.. ^^
좋은글들 참 잘 읽었습니다. 이런 얘기를 할 수 있다는것만으로도 참 좋네요. ^^
|
제목 : Re: 아~
글쓴이: 손님(guest) 2006/05/03 20:12:14 조회수:845 줄수:2 |
|
넘 어렵다
무슨 말들인지, 넘 어려워서, 넘 슬프당 ㅠㅠ;
|
제목 : Re: 몇가지 추가
글쓴이: 일본사는넘(guest) 2006/05/03 21:18:59 조회수:966 줄수:116 |
|
위에 말씀해 주신 의견들에 대해 개인적인 생각과 경험을 적겠습니다.
먼저 손님이 말씀해 주신 'SOA는 EA와 BPM을 함께 생각해야만 그림이 그려지는 개념'이라는
부분에 대해서는 100퍼센트 동감합니다. 더불어 현업 및 IT인력의 인식의 전환이 필요하다는
점에 대해서도 전적으로 동의합니다. 다만 문제는 그 필요성을 인정하나 그에 대한 효과적인
대처법이 아직 구체적으로 없다는 것이지요. 제가 전술했듯이 이른바 SOA의 전문가들의 인식
및 이해조차 불분명한 부분과 상이한 부분이 있는 것이 작금의 현실인지라 Opinion leader들의
보다 명확한 개념의 정의 및 통일, 그리고 각 관계자들의 학습이 필요하다고 생각됩니다.
현 상황에서는 가장 명확한 해결책은 시간이라고 하겠네요.
한가지 좋은 소식은 이 곳 일본에서는 기업이 전사적인 차원에서 EA와 SOA의 도입을 검토하는
케이스가 눈에 띄기 시작했다는 것입니다. 작년까지만 해도 부분적인 도입을 통한 효과검증의
프로젝트가 많았지만 금년 들어 본격적으로 전사적으로 움직이기 시작하는 기업들이 눈에 띄입니다.
그러한 사례가 소개되면 학습효과는 가속화되고 그러한 프로젝트들 안에서 경험을 쌓은 인재들이
새로운 사례들을 만들어 가겠죠.
조대협님이 말씀하신 BPM & SOA라는 부분에 대해서는 레벨과 레이어의 구분이 조금 혼동이
되는군요. 어쨌거나 레벨별로 구분하자면 SOA가 지향하는 부분은 레벨3이므로 BPM이 SOA에
있어 필수가 아니라는 부분에 대해서는 저로써는 동의하기 어렵습니다. 일본에서 작년까지 주로
실시된 SOA프로젝트가 ESB를 이용한 시스템 통합부분이라는 것은 이미 말씀드렸습니다만 그건
아마 조대협님이 말씀하신 레벨로 따지면 레벨2의 Networked 정도가 되겠네요. 하지만 그러한
레벨의 SOA로는 '비지니스의 변경에 따른 신속/유연한 대응'이라는 SOA의 특성은 포기하는 것이
됩니다. 단지 시스템간 연계를 서비스를 이용해서 보다 수월히 하고 유연히 변경하겠다는 정도가
예상효과가 되겠네요. 고로, 전 'BPM은 SOA에서 필수'라고 생각합니다. 그렇지 않으면 SOA가 기존의
아키텍쳐에 비해 우월한 부분이 별로 없어집니다.
ESB에 대해서는 조대협님이 말씀하신대로 디자인된 역활과 용도는 다르다고 생각합니다.(이 역활과
용도에 대해서 조대협님의 의견과는 이견이 있습니다만 부수적인 얘기이므로 그건 다음 기회로 하지요.)
다만 제가 말씀드리고 있는 것은 그 최초의 디자인 사상이 제품 Implementation 단계에서 많이
훼손되고 있다는 것입니다. 더불어 ESB를 도입하는 것이 현 단계(!)에서 정말 EAI툴을 도입하는
것보다 효율적인가 하는 의구심도 있습니다. 일례로 제 경험을 하나 말씀드리지요.
저 역시 작년에서 금년에 걸쳐 ESB를 도입하여 시스템간 연계를 하는 프로젝트를 경험한 바
있습니다. 서로 연계해야 할 시스템들은 SAP, Fujitsu Host, J2EE based application 등이었습니다.
사용한 ESB 제품은 WebService, JMS, File/FTP를 서포트하고 있었지요.
처음엔 SOA니까 당연히 WebService를 가장 많이 사용할 것이라고 생각했습니다. 하지만 WS-RM이
아직 지원이 안되더군요.(차기 버전에서는 된다고 합니다만..)
그럼 미션 크리티컬한 시스템에서 HTTP프로토콜에 기반하고 있는 웹서비스(신뢰도가 최저인
Best efforts죠?)를 과연 사용이 가능한가? 하는 문제가 먼저생깁니다.
결국, WebService는 조회용, 또는 2way 방식(=request-with-reply)의 처리에만 사용한다는
조건이 붙어 버리게 되지요. 갱신, 삭제 등의 처리는 보다 신뢰성이 높은 JMS를 고려하게 됩니다.
하지만 SAP나 Host는 JMS를 사용할 수 없습니다.
(ESB의 프로토콜 변환기능을 사용하면 대응은 가능하죠. 하지만 그 경우 어차피 WebService가
끼어드는 부분에서 같은 문제가 발생하게 됩니다.)
또 하나, SAP의 최신 버전은 웹서비스를 지원하지만 기존의 버전은 그렇지 않습니다. 그래서
SAP과 ESB간에 WebService를 사용하기 위해 iWay의 SAP아답터를 사용해야 했습니다.
Fujitsu Host와 연계하기 위해서는 File/FTP를 사용해야 했구요. 이 부분에서 기존의 FTP툴에서
지원하던 일본어 특수문자 처리를 ESB가 지원하지 않기 때문에 그 처리를 위한 레이어를 추가해야
했습니다.
결국, 서비스와 ESB가 직접 연결되는것이 아니라 SAP adapter, 일본어 특수문자처리 등의
처리를 하는 중간층 -Service enabler layer라고 칭했습니다-를 통해 연결되는 구조가 되어
버렸습니다.
자, 이러한 구조가 정말 EAI툴에 비해 개선되었다고 말할 수 있을까요?
한가지 좋은 소식은 있습니다. ESB밴더들은 그들의 차기 버전에서 보다 많은 프로토콜을
지원한다고 발표하고 있습니다. 그렇게 되면 위의 중간층 같은 것은 필요가 없게 되겠지요.
근데, 그거 ESB의 디자인 개념에 맞는 걸까요? 그렇게 지원하는 프로토콜을 늘려 버리면
기존의 EAI툴과 뭐가 틀려지게 되나요? 서비스의 '표준화된 인터페이스'란 무얼 말하는 걸까요?
제가 첫 글에서 말씀드린 '과도기가 10년은 갈 것이다'라는 것은 바로 이러한 경우를 말씀드린
것입니다. 기존의 시스템들이 전부 SOA에 입각한 시스템으로 대체되지 않는한 위에 말씀드린 것과
같은 문제는 상존할 것입니다. 즉, 이상은 좋으나 현실이 아직 따라가지 못하고 있는거죠.
WS-* 관련 스팩이 너무 복잡하다는 것에는 정말로 동의합니다. 마치 일부러 개발자들 곯려
주려고 복잡하게 만드는 것 같다는 느낌도 들고, 그렇게 무식하게 스팩 만들려면 초등학생도
만들겠다는 생각도 듭니다. 한가지 위안이 되는 점은 'Joel on Software'에서 Joel이 한 말 중에
'당신이 이해 못하는 기술은 절대 널리 보급되지 않을 것이다. 왜냐면 다른 사람들도 이해를
못하기 때문에'라는 말에 제가 기대를 걸고 있단 점입니다.
다만, OOP와 SOA를 동일선상-내지는 확장선상-에 놓고 말씀하신 부분에 대해서는 조금 이견이
있습니다. OOP는 개발방법이지만 SOA는 아키텍쳐이기 때문입니다. SOA의 기본 구성요소인 서비스는
인터페이스와 인플리멘테이션으로 구성되고 이 두가지는 서로 독립적입니다. OOP는 서비스의
인플리멘테이션에 있어서 유효한 수단이 되지만 필수는 아닙니다. (그게 제가 첫 글에서 C나
VB로도 SOA는 가능하다고 조금 억지을 섞어서 말한 이유입니다.) 더불어 SOA를 한다고 OOP가
필요없어 지는 것도 아니죠. 여전히 OOP는 서비스를 인플리멘테이션하기 위한 가장 유효한 수단입니다.
결론적으로 OOP와 SOA는 동일 레이어에 놓고 비교하기엔 조금 무리가 있지 않나 합니다. 같은 맥락에서
CORBA/IIOP와 SOA를 비교하는 것도 제 입장에서는 좀 위화감이 있습니다. ^^; CBD는 비교가 가능하지 않을까..
합니다.
Application Oriented BPM에 대한 설명 감사드립니다. 제가 어림짐작한 것과 비슷한 개념으로
이해가 되었습니다. 다만, 사견입니다만, BusinessProcess Engine이 아닌 EAI나 ESB에서
이루어지는 서비스간의 통합, 루팅 등의 프로세스에 대해 '비지니스 프로세스'라고 정의할 수
있는가-비지니스적인 의미를 갖는 프로세스인가-에 대해서는 조금 갸우뚱.. 합니다만 그게
업계의 선구자들의 정의라면 어쩔 수 없죠.^^;;
미노님의 의견에 대해서는, 전부 동의합니다. 다만, 문제는, '그게 문제라는 건 다들 알고
있는데 그걸 어찌 잘(!) 풀어갈지를 모르겠다'가 아닐까 합니다. ^^; 제가 이 토론을 통해
가장 기대하고 있는 부분이 그 부분에 대한 답이기도 하구요.
PS1: 위 글을 읽고 너무 한마디 한마디 따진다는 느낌이 드실까보아 조금 변명을 하자면,
먼저 각자의 용어나 개념의 정의를 확실하게 해 두지 않으면 서로 같은듯 틀린 이해를 해 버리는
경우가 있으므로 -특히 본 주제와 같은 추상적인 주제에서는 더욱더- 가급적 초기 단계에
명확히 해 두고자 했습니다. 더불어 제 개념이나 정의가 맞다는 얘기가 아니라 제 생각은
이렇다는 얘기일 뿐이니 틀린 부분은 과감히 지적해 주시면 더없이 감사하겠습니다.
(이 기회에 뭔가 하나 배워보겠다고 이 장문을 쓰고 있으니까요)
PS2: 위 문장중에 인플리멘테이션이라고 적었는데 이에 적절한 한국어 표현은 무엇인지요?
일본어로 하면 '실장'이 되는데 한국어로는 조금 어색한거 같고.. 한국의 용어를 몰라 그냥
영어로 표기했습니다.
|
제목 : Re: 아차..
글쓴이: 일본사는넘(guest) 2006/05/03 21:21:50 조회수:885 줄수:5 |
|
중요한 얘기를 잊었군요.
조대협님이 말씀하신 술.. 얘긴데.. 혹 동경 쪽에 오시는 분 계시면 언제든 연락 주심
맛난 맥주를 대접하겠습니다.
제가 한국에 갈 일이 거의 없어서...T_T;;
|
제목 : Re: soa와 기술요소.
글쓴이: 손님(guest) 2006/05/03 21:35:18 조회수:872 줄수:34 |
|
개인적으로 soa의 기술스펙은 이미 5년전에 완성되어졌다고 봅니다.
단지, 문제는 서비스란 것을 컴포넌트 이상으로 너무 크게 본다는 것..
서비스에 기술적 요소를 너무 강하게 투입하려는 경향때문에 soa가 추진되지 않는다고 봅니다.
물론 이것은 밴더의 제품,솔루션 판매를 위한 전략이 개입된 결과죠.
(esb든 ajax든 그게 soa와 무슨 상관입니까..
(스키마대로 파싱,배포하기 위한 간단한 파서가 soa의 필요스킬입니다.
(이외의 스킬은 '기반서비스 구현'을 위한 스킬일 따름입니다.
(하다못해 DB aceess도 말이죠.
이미 기반환경이 만들어진지 오래였지만,
문제는 아키텍쳐를 끌어나가는 인력이 서비스를
service-neiborhood정도의 크기로 보고 있다는 것이
문제의 주원인으로 soa를 가로막는다는 것을 말하고 싶습니다.
(네 밴더가 큰 몫을 해줬고 그러한 가이드가 정답인양 말하고 있습니다만.. 저는 다르다고 생각합니다.
서비스 크기를 크게 잡을 수록
그것을 엮어내기 위한 기술들이 들어가게 됩니다.
밴더가 흔히 말하는 soa란... 이라고 말하며
실사례도 없이 떠들어대는 바로 그 형태입니다.
그러면 그것이 당초에 원했던 SOA의 장점을 엮어낼 수 있을까요?
서비스의 크기가 작아짐으로써 우리가 의도했던 soa의 장점효과..
동적으로 드러나는 컨트롤가능한 collaboration을 노릴 수 없게됩니다.
서비스가 커지게 되면 클라이언트 요구의
인터페이스 역할을 하는 현재의 컴포넌트와 무슨 차이가 있겠습니까..
지금과같이 프로세스 엔터티 유틸리티 레이어로 구성을 하는게 차라리 더 직관적이겠죠.
현재의 cbd와 큰 차이가 없어집니다.
우리가 첫번째로 생각할 것은 soa 아키텍쳐에서 노리고자 하는 것과
부합할 수 있는 서비스의 크기이고 이것이 해당 비즈니스와 적정한지를 확인하는 것입니다.
퇴근해야 되서 다음에..
|
제목 : Re: 몇가지 다시 생각해봐야 하는 것들..
글쓴이: 미노(mino) 2006/05/04 09:41:49 조회수:760 줄수:41 |
|
글들을 쭉 읽다가 몇가지 하고 싶은 얘기들이 생기네요.. ^^
첫번째로 조대협님이 말씀하신,
>그중에 흥미로운 분류 방법이 Enterprise SOA Service Oriented Architecture Best Practice
>라는 책의 Layer 모델을 인용하면
>Level 1. P2P
>Level 2. Networked
>Level 3. Enterprise
부분은 책의 내용이 좀 의심스럽네요.
위와 같이 나눈 Level은 그져 EAI에서 그것도 통합이라는 제한된 관점에서 봤을때의
발전단계라고 보여집니다만, 이것을 SOA까지 끌고 올라가서 얘기할 수 있는것은
아니라고 생각됩니다.
SOA가 물론 기업통합이라는 기본적인 것이 이루어져야 하는것이지만, 그 통합이라는
관점에서 SOA를 보는것은 SOA를 왜곡할 수 있다고 보여집니다.
전 기본적으로 기업통합과 서비스 창출은 서로 다른 방향에서 이루어져야 한다고
생각합니다. 기업통합이 SOA가 되는 기본이 되기는 하지만, SOA를 목적으로
기업통합이 이루어지는것보다는 좀더 실질적인(WebService보다는 JMS등..)인
방식으로 통합이 이루어지고 그것이 Application Oriented BPM을 통하여 조립되는
정도까지만 접근을 하고, SOA는 Business입장에서의 단위 서비스의 정의에서
시작하여, Business Oritented BPM을 통하여 조립하는 것까지를 포함하는것이
어떨까 하는 생각입니다만.. ^^ (이것도 넘 당연한 얘기가 되어 버렸네요.)
두번째로 손님이 말씀하신 EA의 경우, 좀 더 세분화할 필요가 있다고 보여집니다.
보통 국내에서 진행되는 EA의 경우 EA = TA의 관점에서 진행되는 case가
거의 대부분이라고 생각됩니다.
분명 SOA가 EA와 함께 또는 바탕으로 이루어져야 한다는것에 대해서는 100% 공감합니다만,
그때의 EA는 분명 BA가 포함된 개념이어야 한다는 것입니다.
물론 손님도 BA를 포함한 EA를 말씀하신것으로 보여집니다만 좀 더 명확히 해야 한다고
생각해서 적은 글입니다. ^^
P.S : implementation은 저같은 경우 보통 "구현"이라고 표현합니다만..
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
Http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: SOA..
글쓴이: 조대협(guest) 2006/05/04 09:43:25 조회수:739 줄수:20 |
|
SOA에 대한 의견들이 많네요. 재미있습니다.
아.. 그런데. 어제 제가 올린글이 없어졌네요... 어찌 된일인지.. ?!?
SOA Level에 대한 개념은 추후에 다시 꼬옥 언급하고 싶습니다.
기업이 초반부터 BPM을 기반으로 하는 Enterprise SOA를 구현할 수 있다고는 생각하기 어렵습니다.
물론 궁극적으로 가야할 방향이기는 하지만 비용적인 문제등에 의해서도..
Orchestration을 BPM이 아니라 Hard coding등으로 하는 경우도 충분히 발생한다고 봅니다.
또한 EP와 같은 경우에는 Orchestatin이 그렇게 복잡하게 들어가지가 않지요.
우리가 일반적으로 문서나 서적에서 접하는 SOA 구조는 BPM을 이야기 하지만..
현실적인 프로젝트들이 그렇듯이.. 100% 구현은 어렵겠지요.
그리고.. 결국 BPM기반의 SOA로 가더라도, 비용이나 단계별 이전 계획등에 의해서.
분명히 중간 과도기적인 형태의 SOA 를 구현해야 하고 이를 위한 가이드가 필요하다고 봅니다.
먼저 기존의 시스템들을 서비스화하고, 그 서비스들을 묶고, 그다음 BPM에 태우는것이 순서라고
보는데요. 처음부터 이런 전사적인 작업을 하기는 어렵겠지요...
BPM 기반의 SOA가 가장 바람직하다는것에 대해서는 동의하지만...
그러나... 실제 프로젝트 진행에 있어서 단계별 SOA에 대한 가이드는 특히나 Opinion Leader들에게
아주 중요한 역할중 하나라고 봅니다.
|
제목 : Re: SOA Level..
글쓴이: 조대협(guest) 2006/05/04 09:50:39 조회수:764 줄수:24 |
|
SOA Level에 대해서 또 몇가지 덧 붙여 보자면...
기업 입장에서 하나의 기업이 언제나 BPM을 가지게 되는것은 아닐 수 있습니다.
즉 무슨 소리냐 하면.
기업 A가 있고, 이 기업 A가 여러개의 협력 또는 하청 업체를 가지고 있을때..
기업 A가 전체적인 Process를 Orchestration을 하고.
하청 업체들은 Sub Process 정도의
Task-Centric or Entity Centric한 서비스만 제공 할 수 있습니다.
자사의 업무 자체는 BPM이 필요하지 않을 정도로 간단할 수 있구요.
이 기업도 B2B 통합을 SOA로 구현하였기 때문에, SOA라고 볼 수 있겠지요.
간과 하지 말아야 할것이 현재 여러 서적이나 문서, 그리고 Vendor들이 이야기 하는
SOA는 가장 이상적인 아키텍쳐를 이야기 하고 있지만.
"모든 시스템이 그렇듯이 목적과 역할에 맞는 구현이 가장 이상적이 구현이라고 생각합니다."
즉 Process가 중요되시 않는 업무에 대해서 BPM을 무리해서 구축할 필요가 없다는거지요.
SOA 관련 서적을 보면 Sub Process에 대한 개념을 많이들 언급하는데요.
이 sub process에서도 어느정도 규모의 Business Process를 구현할 수 있구요.
BPM 솔루션이 아니라 ESB 레벨에서도 Sub Process가 대부분 구현 가능한것으로 알고 있습니다.
Business Agility는 꼬옥 BPM이 아니더라도 ESB나 또는 다른 Layer에서도 충분히 얻을 수 있는
특징이라 볼 수 있겠습니다.
|
제목 : Re: Application Oriented Process
글쓴이: 조대협(guest) 2006/05/04 09:53:47 조회수:708 줄수:14 |
|
justjava님의
" Application Oriented BPM에 대한 설명 감사드립니다. 제가 어림짐작한 것과 비슷한 개념으로
이해가 되었습니다. 다만, 사견입니다만, BusinessProcess Engine이 아닌 EAI나 ESB에서
이루어지는 서비스간의 통합, 루팅 등의 프로세스에 대해 '비지니스 프로세스'라고 정의할 수
있는가-비지니스적인 의미를 갖는 프로세스인가-에 대해서는 조금 갸우뚱.. 합니다만 그게
업계의 선구자들의 정의라면 어쩔 수 없죠.^^;;"
글에 대해서 조금 이해가 안되서요...
제가 분석 하는 방법에서는 비지니스 프로세스와 애플리케이션 프로세스는 분명히 나누고 있습니다.
그러나.. 프로세스가 어느 Layer에 위치할것인가에 대해서는 디자인 단계에 충분히 이견이 있습니다.
어떤 의미인지 알면 서로 좀더 자세히 이야기해 볼 수 있겠네요...
|
제목 : Re: SOA에 대해서..
글쓴이: 조대협(guest) 2006/05/04 09:57:30 조회수:799 줄수:17 |
|
좋은 의견들과 토론 즐겁습니다.
SOA에 대해서 이야기 하면서 몇가지 이야기를 정리해볼까 합니다.
SOA는 말 그대로 아키텍쳐이고... 아직까지 growing하고 있는 기술입니다.
딱히 100% 정해진 spec도 없고.. vendor또는 각 기술자마다 SOA를 바라보는 시각이 틀린점이 있습니다.
SOA를 이야기할때, 좀더 여러 아키텍쳐에 대해서 함께 이야기 해봤으면 합니다.
SOA Level에 대해서 좀더 의견을 들었으면 합니다.
아. 그리고, 동경에는 얼마전에 갔다가 왔는데... 아쉽네요.. ^^
금년에 또 출장갈일이 있을까 잘 몰겠네요.
갈일 있으면 연락드리겠습니다.
ESB와 SOA Level에 대해서 좀더 이야기 해봤으면 합니다.
|
제목 : Re: Application Oriented Process
글쓴이: 일본사는넘(guest) 2006/05/04 10:07:53 조회수:756 줄수:19 |
|
조대협님의 질문에 답하자면,
" Application Oriented BPM에 대한 설명 감사드립니다. 제가 어림짐작한 것과 비슷한 개념으로
이해가 되었습니다. 다만, 사견입니다만, BusinessProcess Engine이 아닌 EAI나 ESB에서
이루어지는 서비스간의 통합, 루팅 등의 프로세스에 대해 '비지니스 프로세스'라고 정의할 수
있는가-비지니스적인 의미를 갖는 프로세스인가-에 대해서는 조금 갸우뚱.. 합니다만 그게
업계의 선구자들의 정의라면 어쩔 수 없죠.^^;;"
이 부분은, 단순히 용어정의에 대한 조금의 불만(?)을 토로한 것입니다.
프로세스에 레이어가 있고 상위 프로세스는 복수의 하위 프로세스로 구성될 수 있다는 점
에는 물론 동의합니다. 하지만 비지니스적인 의미보다는 어플리케이션 적 의미를 갖는 하위
레이어의 프로세스에 대해 BPM이란 용어를 붙인 것이 조금 맘에 걸렸기에 그걸 말한 것입니다.
(BPM은 말 그대로 비지니스 프로세스 관리라고 생각했기에.)
나중에 적어 주신 'Application Oriented Process'라고 용어를 정의한다면 전혀! 불만
없습니다.
(뭐, 전혀 얘기의 진행과는 관계없이 그냥 용어정의를 물고 늘어져 본거죠. 잘못된 용어는
잘못된 이해를 초래할 수 있기에 평소 그런 부분에 조금 시끄러운 편입니다.^^;)
|
제목 : Re: SOA Level에 대해서..
글쓴이: 미노(mino) 2006/05/04 10:18:55 조회수:834 줄수:37 |
|
SOA를 구현하기 위해서 어떠한 Level부터 시작해야 하는 것이지를
결정해야 한다면,
전 적어도 EAI가 도입된 기업환경이 기본이 되어야 한다고 봅니다.
즉 어느선에서 SOA도입을 고려해야 하는가를 기업이 생각해야 될테고,
그런것의 기반이 그져 아무것도 없이 여러 시스템들이 늘어선 형태에서
시작한다는건, 관점자체의 혼돈이 발생할 수 있다고 봅니다.
즉 SOA, Service를 만들어내는 관점이 아닌, 통합관점에서 진행되게 될테고,
통합은 좀더 IT관점에서 시야를 좁혀버리게 될것으로 생각됩니다.
앞에서 말씀드린것처럼, SOA를 도입 고려하는 기업은 EAI까지는 구축이
되어 있어야 하고, 그렇지 않다면, 당장 SOA를 도입하는 것보다는 EAI의 도입을
먼저 고려해야 한다고 봅니다.
따라서 SOA의 Level은 시스템의 통합보다는 통합된 Resource들에 대한 Flow
(위에서 언급하신 Application Oriented Process이 되겠죠.)를 설계하는것이
첫단계가 아닐까 생각합니다.
서비스를 생산하기 위한 기본 단위를 만드는것에서부터 말이죠..
그리고 "Business Agility는 꼬옥 BPM이 아니더라도 ESB나 또는 다른 Layer에서도 충분히 얻을 수 있는
특징이라 볼 수 있겠습니다." 라는 부분에서는 다른 이견이 있습니다.
Business Agility가 제대로 발휘되기 위해서는 IT관련부서에서 Business Process를
만드는것이 아닌 서비스상품을 만들어내는 현업에서 Business Process를 설계할 수
있어야 한다고 생각됩니다. 제가 BPM이 반드시 도입되어야 한다고 말하는 부분에
바로 이 의미가 가장크다고 할 수 있습니다.
기업입장에서 새로운 상품을 만드는 단계가
"현업 상품 기획 -> 결재 -> IT관련 부서 작업 -> 시행" 이 아닌
"현업 상품 기획 -> 결재 -> 시행" 이 되어야 한다는 거죠..
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
Http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: 조금씩 보다 심층적인 부분으로 가는군요..
글쓴이: 일본사는넘(guest) 2006/05/04 11:01:22 조회수:1565 줄수:35 |
|
SOA의 단계적 도입이란 부분에서는 조대협님의 의견에 찬동합니다.
mino님의 'EAI기반 전제론'(맘대로 이름 붙였습니다^^)에 대해서는 조금 제 이해가 부족한
부분이 있습니다. 가능하시면 추가 설명을 해 주시면 제 이해에 도움이 되겠습니다.
- 먼저, ESB가 아니고 EAI인 이유는 무언지요?
- SOA에는 서비스들을 통한 시스템 통합이라는 관점도 존재한다고 생각합니다만 그 부분에
대해서는 인정하지 않고 계신 것인지요?
- EAI상에 통합된 리소스들(서비스를 의식하지 않은 상태에서 통합된)을 가지고 서비스를
도출해 내는 것은 가능할런지요?
조대협님의 "Business Agility는 꼬옥 BPM이 아니더라도 ESB나 또는 다른 Layer에서도 충분히 얻을 수 있는
특징이라 볼 수 있겠습니다." 라는 부분에서는 저도 mino님과 같은 의견입니다.
제가 참가한 한 프로젝트에서, 고객이 ESB를 도입하면 BPM도 도입하는게 된다는 오해를 한
적이 있었습니다. 그도 그럴만한 것이 ESB 안에 서비스들을 가지고 프로세스를 구축하는
기능에다, 멧세지 내용에 기초한 동적 라우팅-Contents based dynamic routing- 등의 기능이
있었으니까요.
하지만 조대협님도 지적하셨듯 ESB는 서비스들간의 소결합을 지원하기 위한 툴일 뿐입니다.
서비스간의 소결합을 지원하기 위해 위와 같은 기능을 가지고 있을 뿐이지 BPM을 위한 기능들이
아닙니다. 실제 ESB 상에서 공개되는 서비스들은 비지니스 프로세스에서 하나의 노드를 구성하는
정도의 류도로 하는게 적정하다고 생각됩니다.
따라서 "ESB나 또는 다른 Layer에서도 얻을 수 있는" 것은 기존의 시스템간 통합 및 서비스의
물리적 위치, 인터페이스 변경 등에 대한 신속/유연한 대응, 즉 System integration의 Agility라고는
할 수 있으나 BPM에서 얻을 수 있는 Business Agility와는 조금 성격이 틀리지 않나 생각합니다.
여전히 개인적인 의견이므로 정정할 곳 있으면 지적 바랍니다.
PS: 번번히 죄송합니다만, Loosly coupled라는 의미로 소결합이라고 기술했습니다만 한국적인
표현은 뭐가 될까요?
PS2: 미노님의 블로그는 제게 등록되었습니다. 향후 악플공세를...
|
제목 : Re: 부족한 답변이지만..
글쓴이: 미노(mino) 2006/05/04 11:26:34 조회수:743 줄수:63 |
|
일단 향후 악플공세를 이란 글이 머리속에서 계속 맴도는 군요.. ^^
먼저 부족한 답변이지만 답을 드린다면..
- 먼저, ESB가 아니고 EAI인 이유는 무언지요?
: ESB란 개념은 벤더들이 SOA를 내세우기 위한 마케팅적인 요소가 강한 단어라고
생각합니다. ESB에 대한 용어의 정의를 살펴봐도, Opinion Leader라는 분들이
제각각 다른 정의를 하고 있는것만 봐도 그렇습니다.
즉 통합이라는 관점에서 기존 EAI가 존재하였고, 그 EAI를 SOA에 끌어들어기에는
분명 부족한 점이 있다고 보았던것 같습니다. (물론 저도 그렇습니다.)
그 이유는 EAI가 통합이라는 관점에서 물론 표준화된 Protocol을 지향하기는 하지만,
통합의 최적화등을 위하여 표준화되지 않은 부분에 대한 사용도 전혀 문제가 없습니다.
SOA에서 바라보는 통합은 Loosly coupled(보통 느슨한 연결이라고 합니다만.. ^^)이
전재가 되어야 하고 그러기 위해서 EAI는 조금 미흡한 부분이 있었다고 보여집니다.
그래서 ESB에서 WebService가 상당히 중요하게 다루어진다고 보여지구요.
덧붙여서 Bus개념이 추가도 어느정도 의미가 있다고 봅니다.
(좀 더 부연설명은 아래의 답을 통해서 하도록 하겠습니다.)
- SOA에는 서비스들을 통한 시스템 통합이라는 관점도 존재한다고 생각합니다만 그 부분에
대해서는 인정하지 않고 계신 것인지요?
: SOA가 바라보는 통합은 EAI가 바라보는 통합보다 한단계 위에 있다고 생각합니다.
즉 하나의 기업에서는 여러 자회사와 여러 시스템 그룹들이 존재할 수 있습니다.
통합의 단계를 봤을때 EAI는 한 기업전체를 묶는 역활을 수행하기에는 프로젝트 단위
등에서 미흡하다 할 수 있습니다.
즉 제가 위에서 말한 EAI가 SOA전에 도입되어야 한다고 말씀드린것은, 한 기업 전체의
통합을 말한다기 보다는 그보단 한단계 아래인 시스템 그룹의 통합 , 또는 한 자회사내에서의
통합이라고 보는것이 맞는것으로 보입니다.
하나의 기업입장에서 EAI시스템은 여러개가 될 수 있습니다. 제가 말씀드린 SOA를 위해서
EAI가 전재되어야 한다는 것은 단위 EAI시스템을 말하는 것입니다.
그위에서 ESB개념의 통합과 동시에 Application Oriented Process의 도입이 SOA의 처음 Level
이라고 생각한것입니다.
덧붙이지면 제가 현재 진행하고 있는 프로젝트가 금융권의 EAI프로젝트입니다.
또한 큰 이슈로 작용하고 있는것이 곧 실효될 "자본 통합법"입니다.
자본 통합법으로 인하여 분명 금융권에는 큰 변동이 생길것입니다.
크던 작던간에 M&A가 발생할것으로 보여지며, 그것은 기업환경에서 커다른 두개의 시스템 군이
합쳐지는것을 의미합니다. 이때 개별적인 통합이 이루어진 상태라면 훨씬 더 수월하게
진행될 수 있을것이며 SOA에서도 비슷한 경우라고 생각합니다.
( 저에게는 당면한 과제입니다만 모회사와 M&A를 할것으로 보입니다.
그렇게 된다면 상대회사가 EAI가 되어있지 않다면 각 시스템들을
저희 EAI에 포함시키는 것이 아닌, 상대회사에 EAI를 도입하고 그 EAI와
저희 EAI를 통합하는 방향으로 가는것을 고려중에 있습니다. )
- EAI상에 통합된 리소스들(서비스를 의식하지 않은 상태에서 통합된)을 가지고 서비스를
도출해 내는 것은 가능할런지요?
: 전 가능하다고 생각합니다. 아니 가능해야 한다고 생각합니다. 그것이 비록, 어느정도 통합이
이루어진 상태에서 서비스로 인하여 특정 부분이 추가 또는 수정이 되어야 할지라도 말입니다.
서비스를 중심으로 통합이 이루어진다는 것은 기반이 닦이지 않은 상태에서 집을 짓는것과
같다고 생각합니다. 완벽한 기반은 아닐지라도, 서비스를 생각하지 않은 상태에서도 기술적인
Component형태의 통합은 충분히 이루어질 수 있다고 봅니다.
또한 덧붙여서 "현업 상품 기획 -> 결재 -> 시행" 가 주가되고, 필요시
"현업 상품 기획 -> 필요서비스 요청 -> IT관련부서 작업 -> 서비스 제공"과 같은 process도
같이 존재해야 한다고 봅니다.
처음부터 완벽할 수는 없겠지만, 초창기에 어느정도 시행착오를 거친다면 어느순간
Time-to-Market이 실현될 수 있는 환경이 되지 않을까요?
(제가 너무 낙관적인걸까요? ^^)
많이 부족한 답변입니다. 고칠 부분이 있다면 말씀해 주십시요. ^^
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
Http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: EAI & SOA
글쓴이: 조대협(guest) 2006/05/04 11:32:18 조회수:855 줄수:10 |
|
EAI와 SOA에 대해서는 저도 고민을 많이 하고 있습니다.
실제적으로 implementation에 대한 접근 방식이 틀릴 뿐이지 integration이라는 목적 자체는
매우 유사하며, SOA 아키텍쳐를 EAI로 구현한 케이스도 많기 때문입니다.
일단 EAI 솔루션은 일반적인 경우(강조합니다.)에는 ESB 아래의 Application Layer에서
Legacy를 service화 하는데 사용이 되어야 한다고 생각합니다.
물론 J2CA와 같은 Adapter등의 솔루션이 있겠지만. 한계가 있는것은 분명하니까요..
식사 시간이네요. 점심 먹고 더 이야기 해보도록 하지요.
|
제목 : Re: EAI와 ESB
글쓴이: 미노(mino) 2006/05/04 12:29:49 조회수:812 줄수:36 |
|
분명 EAI와 SOA(특히 ESB)에 대한 구분은 명확하지 않은것이 사실입니다.
기업환경은 보통 작게는 몇십개의 시스템에서 많게는 몇백개의 시스템으로
구성되어 있습니다.
기업통합이 이루어진다면 기존 시스템들의 영향을 최소화 하는 방향으로
진행이 되겠지만 분명한 것은 변경사항이 없을 수는 없다는 것입니다.
때문에 모든 시스템을 한번에 통합한다는것이 기업입장에서는 쉽지 않은일입니다.
어느정도 규모이하의 기업환경에서 EAI와 ESB가 같은 개념으로 사용될 수는 있겠지만,
그이상의 규모가 된다면, 하나의 EAI로는 통합 할 수 없을 수도 있습니다.
또한 각기 EAI시스템이 존재하는 두개의 회사가 합쳐진 경우도
한개 이상의 EAI는 존재할 수 있을것으로 보입니다.
그렇다면 EAI는 좀더 IT적인 요소를 반영하여(성능/연동방법 등) 최적화 되어야 하고,
때문에 표준이 아닌 방법을 사용하는 Case도 분명 발생할 수 있습니다.
그래서 EAI는 좀더 Tigtly Coupled가 되는 경우가 많을 것으로 생각합니다.
(음.. 쓰고났더니 위에서 조대협님이 언급한 내용이군요.)
이 기반위에 ESB가 loosly Coupled하게 적용이 되는것은 어떨까 생각합니다.
분명 EAI Solution에서 WebService등 표준지향적인 Protocol을 상당히 간편하게
제공할 것이고 그런것들을 ESB가 윗단에 위치하며 연동하는 방식이죠.
SOA를 적용하기 위해서 기업 전체 시스템을 ESB로 엮게 된다면,
상당히 많은 문제점이 발생할 수 있으리라 생각되어지고, 그런것 때문에
위에서 SOA Level이 언급된것이 아닐까요?
EAI와 ESB는 상황에 따라서 같은 개념이 될 수도 , 그렇지 않을 수도 있다고 봅니다.
그러나 어느정도 이상 규모의 기업에서는 구분되어져야 할것 같구요.. ^^
P.S : 저희는 식사시간이 빠른 편입니다. ^^.. 식사들을 하시겠군요. 맛있게 드세요.
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
Http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: 추가하고 싶은데..
글쓴이: 손님(guest) 2006/05/04 13:28:32 조회수:751 줄수:13 |
|
위에 ' soa와 기술요소. ' 썼던 손님인데..
어제 퇴근한 이후에 많은 글들이 올라와 있네요.
ESB에 대해선 저도 할 말이 많고..(부정적)
SOA의 레벨이 낮아져야 하는 이유에 대해서 좀 더 쓰고 싶은데..
시간이 영 나지 않네요.. 밥먹고 잠시 쓰는 중이라..
시연이 끝나고 저녁에 다시 이 글을 봤을 때 좀 더 긴 댓글이 달려있기를 기대해봅니다.
또 뵙죠.
|
제목 : Re: 중간에 잠깐 딴지 죄송합니다.
글쓴이: 놀새~(guest) 2006/05/04 22:55:00 조회수:1014 줄수:19 |
|
안녕하세요? 의견 잘 보고 있습니다.
저도 SOA에 대해서 많은 분들과 이야기를 나누고 "갑론을박"도 해보았지만 아직도 결론을 못내고 있고
그 때 당시의 토론을 몇자 적고 싶지만 근래 찾아온 귀차니즘때문에 포기하렵니다.
워낙 벤더(APM 벤더 및 EAI벤더, MOM based벤더 등)들이 부르짖는 소리들이 제 각각이고 컨설팅펌(I사,
A사, H사 등등)에서도 각자 자기들만의 소설을 쓰고 있는 관계로 말이죠.
제 생각은 "ROI만을 떠드는 고객에게 SOA를 이해시키기 정말 어려우며, 아직 갈길 멀었다. 시작이라도
했으니 다행이다"입니다.
아참..몇 달전에 Gartner에서 BPM에 대한 용어를 새롭게 재정의하였습니다.
그나저나..
조대협님.. 제가 아는 분..
미노님.. 제가 아는 분..
일본사는넘님. 동경에 계시고 혹시 성함 initial이 "SC Lee" 맞으신가요?
궁금궁금해요...꼭 대답해 주세요.
|
제목 : Re: EAI와 ESB
글쓴이: 일본사는넘(guest) 2006/05/04 22:56:46 조회수:882 줄수:72 |
|
음... 조대협님과 미노님은 EAI를 ESB의 하부 레이어로 사용가능하다는 입장이라고 이해를
했습니다. 제가 이해하고 있는 바로는 ESB는 EAI의 상위 레이어라기 보다는 EAI를 대체하는
것이라고 이해하고 있었습니다. 물론 두분이 얘기하고 계시는 것도 현실적인 접근방법으로써
수긍이 가는 바는 있으나, 그와는 별도로, 다음과 같은 관점도 있다고 생각합니다.
또 다시 제가 경험한 프로젝트와도 관련되는 얘기가 되는데, 당시 고객이 안고 있던 문제는
시스템간 연계의 복잡화 회피와 시스템의 가시화, 제어의 국소화였습니다. (또다시 별로
한국어같지 않은 표현이... 한국에서 일한 적이 없고, 한국의 용어를 접할 기회가 없습니다.)
무슨 얘기인가 하면, 기존에 시스템간 연계에 EAI툴을 사용하고는 있었지만 시간이 지나면서
그 내부가 점점 복잡해져 관리가 어려워졌고, 문서와 실제 구현에 상이점이 발생하는 등 점차
시스템의 정보가 일부 전문가들의 머릿속에만 남고 그마저도 각각의 담당자의 머릿속의 암묵적인
지식으로 분산보관됨에 따라 새로운 시스템의 추가/변경시에 영향범위의 파악이 안되고, 기존의
시스템에 손을 대지 못하게 되는 상황으로 발전되어 있는 상황이었습니다.
그에 대한 해결책으로 ESB를 도입한 경우가 있습니다. 도입목적은 표준 인터페이스로 공개된
서비스들을 ESB를 통해 서로 연결함으로써
1. 시스템간 연계의 표준화(각종 네이티브 프로토콜 지원을 지양, 연계허브의 슬림화)
2. 관리의 편이성 도모
3. 영향범위의 가시화와 국소화
4. 향후의 BPM 도입에 대한 준비
를 하고자 한 것입니다.
위에서 ESB를 도입함으로써 EAI를 사용하던 시기보다 개선된 것은 1, 2, 4 정도이겠네요. 하지만
기존의 수많은 네이티브 프로토콜을 복잡하게 연결하던 블랙박스로써의 EAI를 표준
프로토콜만으로 연결하는 보다 슬림한 화이트박스인 ESB로 대체한 것만으로도 고객으로부터는
상당한 호평을 받았습니다.
위의 경우는 EAI를 ESB로 대체한 경우에 해당합니다. (물론 제가 이전 글에서 썼던대로 여전히
몇몇 문제점이 산재해 있는 것은 사실이고 향후의 ESB제품의 기능이 점점 EAI툴을 닮아간다는
우려는 있습니다만) 이 프로젝트에서 만약 기존의 EAI를 그대로 두고 그 위에 ESB를 얹었다면
어땠을까요? 비지니스 레이어 및 SOA를 실시하는 레이어에서는 ESB의 깨끗한 인터페이스를 사용할
수 있었겠지만 그 밑에는 여전히 EAI라는 블랙박스가 버티고 앉아 있는 것이지요. 문제를
해결한 것이 아니고 문제를 잠시 덮어버린 것에 불과하게 됩니다.
SOA에서 얘기하는 아키택쳐는 순수한 서비스들로 구성된 것이지요. 뭐, 서비스 지상주의로
달려갈 필요는 없다고 개인적으로 생각하지만, 적어도 SOA에서는 비지니스 레이어에서만
서비스를 정의/사용하는게 아니라 전 시스템의 각 부분을 서비스로 정의/사용하고자 합니다.
그런 부분에서 SOA에서 바라보는 통합이 EAI가 바라보는 통합보다 위의 레이어에 존재한다는
의견에 대해서는 이견이 있구요, 서비스간의 통합에 대해, 기존의 EAI툴의 문제점을 지적하면서
그걸 해결하겠다고 나선 넘이 ESB이기도 하므로 EAI를 ESB의 하위 레이어로 보는 것은 일반적인
ESB에 대한 인식과는 상이하다고 생각합니다.
SOA에 입각하여 설계/구현된 시스템이란 결국 Composite Application이란 단위로 구성/제공되고
이 Composite Application의 하위 레이어는 ESB를 통해 접근이 가능한 각각의 시스템이 제공하는
서비스로 구성됩니다. 각 시스템이 어떤 기술로 구현되어 있는가 하는 것은 SOA의 관심사항이
아니지요. 그저 각 시스템이 서비스란 형태로 기능을 제공해 주기만 하면 되는거지요. 그리고 서로
다른 시스템에 존재하는 서비스간의 연계에는 ESB를 사용합니다. 즉, EAI가 등장할 장면이
없어진다고 생각합니다. 하나의 시스템 안에서는 통합이란 과제가 없을 테니까요.
다만, 개인적으로는 각각의 시스템이 SOA의 개념에 입각하여 설계/구현되고 그러한 서비스간의
연계를 전부 ESB로 구현하는 단계까지 가기 위한 과도기에는 두분이 말씀하시는 그러한 구성도
현실적으로는 가능하지 않겠는가.. 하는 정도로 인식하고 있습니다.
즉, ESB 밑의 EAI는 결국은 제거되어야 할 대상이다.. 라구요.
위와 같은 관점에서는 미노님이 말씀하신 '상대기업이 EAI가 되어 있다' 보다 더 좋은
조건은 '상대기업이 SOA에 입각한 시스템이 구현되어 있고 시스템간 연계에는 ESB가 도입되어 있다'
가 되지 않을까 합니다. (현재로써는 꿈같은 얘기겠지만요.)
물론, 미노님이 지적하신 EAI의 Tightly coupled의 문제를 해결하겠다고 나선 것이 ESB인만큼
그 반동으로 처리속도의 저하는 필연적입니다. 그 부분은 무식하지만 하드웨어로 보강해가는게
현재로써는 유일한 해결책이겠지요. 더불어 한 기업 안에 그 기업의 시스템 규모에 의거하여
복수의 ESB가 존재하는 것은 당연한 얘기가 되겠지요.
중언부언하는 것 같지만, 이론상, SOA는 표준화된 인터페이스를 가지는 서비스들로 전체
시스템을 구성하는 것을 목표로 하고 있습니다. 즉 SOA의 입장에서는 네이티브 프로토콜을
지원하는 EAI는 제거대상입니다.
이상, 반론 및 지적 부탁 드립니다.
그리고, 서비스의 설계 및 구현단위와 그 방법론이란 주제에 대해서도 기회를 보아 얘기를
해 보고 싶군요.
|
제목 : Re: 제 이니셜은
글쓴이: 일본사는넘(guest) 2006/05/04 22:59:28 조회수:837 줄수:1 |
|
저 일본 동경 사는건 맞는데, 이니셜은 SC Kim 또는 SM Kim입니다.
|
제목 : Re: Why SOA?
글쓴이: 또다른시도(guest) 2006/05/05 00:32:30 조회수:793 줄수:60 |
|
EAI와 ESB, Layer 등 다양하고 경험과 정련을 거듭한 의견들을 개진해주셔서 우선 감사드립니다.
기술, 표준, 방법론은 여기 계신 많은 고수분들의 고견을 듣겠습니다.
저는 SOA가 무엇인가 보다는 왜 SOA인가라는 질문을 던지고자 합니다.
1. CBD
전체 프로그램의 컴포넌트 사용률이 무려 60~70%이며 실제로 업무 프로그램은 이들을 조합하는 게
대부분인 코볼로 구축된 아주 훌륭한 CBD 시스템을 본 적이 있습니다.(기술적인 레벨의 컴포넌트 정의
제시는 사양합니다)
2. EAI
예전에 주로 MQ를 이용한 P2P 방식으로 시스템간 연계시 시스템별로 상이한 전문과
프로토콜로 IT측면에서 관리가 힘들었던건 사실입니다.
하지만 이들의 연계는 결국 공통모듈을 이용하여 수행하므로 업무 프로그램에서는
공통모듈의 추상화를 등에 업고 시스템에 투명하게 코딩하였습니다.
따라서 EAI를 도입하였다고 해서 업무 프로그램단에서 한 작업이라곤 흐트러진 전문을 정리한 정도랄까요.
오히려 전문 변경시 타시스템 담당자에 더하여 EAI 담당자와도 수정 프로세스를 진행해야 하므로
번거러워졌다고도 할 수 있습니다.
일부 관리자는 P2P에서는 문제가 생기면 일부만 장애가 발생하였지만 만약 EAI에 장애가 발생하면
전체 시스템이 뻗을거라는 기우까지 하는 경우도 있었습니다.
시스템 측면에서는 MQ 채널수가 확 줄었고 연계를 담당하는 부서가 따로 생겨서
관리가 용이해진 셈이지만 적어도 업무 프로그램단에서는 그러했더라는 썰이었습니다.
업무 프로그램단에서 이렇게 느꼈다면 실제 현업에서는
과연 EAI의 도입이 회사의 경쟁력에 어떤 기여를 끼쳤는지 전혀 느끼지 못한다는 점입니다.
사실 느낄 필요도 없는 시대였지요.
데스크탑이 출현하기 전 현업이 타자기의 구조와 성능엔 무관심했듯이 말입니다.
3. Why SOA?
그렇게 추구하는 느슨한 결합이 IT와 현업간에는 완벽하게 구현되어 있는 셈입니다.
또다른 예로 현업이 '제의철회를 취소해주세요'라고 하면 IT담당은 '그렇다면 제휴철회 값을 Y로 해야
하나요 N으로 해야 하나요?'
이에 현업은 '예? 취소하는건데요...' ㅡ.ㅡ
IT의 급속한 발달은 IT를 스스로 진화시켜 데스크탑이 그러하였듯이
비즈니스와 IT의 경계를 허무려는 시점이 아닐까 합니다.
이러한 이유로 저도 위의 손님처럼 SOA의 서비스 단위에 관심을 두고 있습니다.
몇몇 문서에서 서비스의 정의를 보았지만 컴포넌트의 인터페이스와 확 다른 무엇은 없어보입니다.
CBD에서 컴포넌트간 연관 관계를 차단하기 위해 덩치를 키우다보니
대표적인 교육사례인 도서관리의 CRUD 컴포넌트 스타일로 굳어졌던 기억이 납니다.
SOA에서는 단위시스템을 뛰어넘는 영역이어서인지 범위가 더 커져서
SCM, CRM, 인사, 재무 등의 시스템 자체를 서비스화하려는 정의도 있더군요.
간략한 의견을 말씀드리자면 서비스의 최소 단위는 룰을 건 데이터였으면 합니다.
수학적으로 증명된 정규화가 적용된 데이터면 더욱 좋습니다.
하지만 현업의 IT화, IT의 현업화가 덜 된 지금은 function 단위를 서비스의 최소 단위로 하였으면 합니다.
여하튼 이렇게 잘게 가져갔으면 하는 이유는 소스코드에 숨지 않은 가시적인 IT를 만들고자 한다면
결국 원자 단위의 서비스로 등록되어야 한다는 생각에서입니다.
서비스의 조립을 통한 또다른 서비스의 생성과 이들의 연관 관계는 비즈니스를 많이 아는 IT 인력 혹은
IT를 많이 아는 비즈니스 인력이 Best practice를 만들어가면서 방법론으로 도출해내는 수 밖에 없어
보입니다. 결국 사람이 하는 일이니까요. 이런 이유에서 SOA 역시 아직 증명되지 않은 또다른 시도라는걸
다시한번 생각하게 됩니다.
졸립군요. 많은 반론 부탁드립니다.
|
제목 : Re: Because of ..
글쓴이: 일본사는넘(guest) 2006/05/05 01:01:55 조회수:844 줄수:15 |
|
제목 : Re: EAI vs ESB
글쓴이: 조대협(guest) 2006/05/08 10:00:36 조회수:918 줄수:53 |
|
출근을 해보니.. 그간 리플이 또 많이 달렸네요.
오늘은 EAI와 ESB에 대해서 이야기 해볼까 합니다.
EAI와 ESB는 언뜻 보면 그 구조와 역할이 매우 유사합니다.
요즘 EAI 제품의 기능만을 보면 ESB를 대체할 수 있을 정도니까는요.
그러나 명백하게 차이가 있다고 봅니다.
EAI 기능 영역
- Transaction 관리 (2PC)
- Adapter 기반 연결
- Process 포함
기본적으로 EAI가 ESB와 가지는 기본적인 차이는 위와 같습니다.
ESB 의 구현 구조등을 살펴보면 EAI와 매우 유사하고, EAI 제품의 마케팅적으로 용어만
바꾼것이 ESB가 아니냐? 라고 할 정도로 제품의 구조가 매우 유사합니다.
그러나 ESB의 경우
WebService 기반으로 2Phase-Commit 기반의 분산 트렌젝션 처리가 불가능합니다.
WS* Transaction spec이 있기는 하지만 아직까지 지원하는 Vendor가 매우 드물고,
개인적인 생각에서는 앞으로도 구현이 쉽지 않을것으로 판단됩니다. (이 이야기는
필요하면 나중에 하도록 하지요)
그리고, EAI는 기본적으로 연결 방식이 Adapter를 사용하는 방식이지만
ESB는 WebService(? etc...)를 이용한 Loosley coupled 방식입니다.
물론 현재 ESB들이 Adapter나 POJO등을 지원하는 방식으로 진화되고 있지만.
(앞으로 지원할거라 생각됩니다.) 그러나.. 현재까지는 ESB 의 표준 프로토콜은
WebService가 대세라고 봅니다.
이로 인해서 Call 방식에 있어서 EAI가 우위를 점유한다고 봅니다.
Async call, reliable messaging등이 EAI로 구현이 가능한데 반해서...
ESB의 경우 WebService spec상에 Async나 Reliable messaging을 지원할 수 있는
WS* Spec은 있지만, ESB vendor에서 이제 지원을 막 시작했고,
ESB의 end point가 되는 system에서 이 WS* spec을 지원할 수 있을지 없을지 여부가
큰 요건이 되기 때문에 Legacy에 맞추어서 개발된 Adapter기반의 EAI가 훨씬 유리하다고
봅니다.
마지막으로 EAI 제품의 경우 BPM이던, 아니면 일반 Application Process건
이런 Process suite들이 기본적으로 내장이 되어 있지만 ESB 제품에서는 BPM은
다른 제품으로 분류하고 있습니다.
결론을 지어 보면
EAI와 ESB는 매우 유사합니다.
개인적으로는 ESB의 모태가 EAI라고 하고 싶네요.
즉 ESB는 EAI를 경량화하고 거기에 WebService 표준 기술을 가미하여 만든 미들웨어로
생각하고 있습니다.
아직까지 Transaction 연동이나 또는 복잡한 메세징 처리에 있어서는 EAI가 강점이 있기
때문에 기존 System을 Service화 하여 ESB에 연결하기 위해서는 Service에 복잡도에
따라서 EAI가 ESB 아래 Layer에서 사용될 필요가 있을 수 있다는 의견으로 받아들여
주셨으면 합니다.
또한 ESB에서 앞으로 Adapter지원등을 통해서 EAI의 기능을 상당 부분 흡수할것으로봅니다.
그때즈음 되면 SOA에 EAI가 필요없게 될 수 있겠지만.
현재 현실적인 기술 안에서는 아직까지 SOA에서 EAI를 무시는 할 수 없을것 같습니다.
|
제목 : Re: ??
글쓴이: 손님(guest) 2006/05/08 10:38:18 조회수:804 줄수:14 |
|
EAI는 어댑터, ESB는 웹서비스.. 라는 정도의 구분으로는 좀 부족할 듯 싶은데요.
일반적으로 EAI에서 통합하는 범위내라면 ESB도 JCA 를 사용하겠죠.
말씀하긴 트랜잭션이나 비동기 메시징도 그 범위 내에서라면 충분히 가능할성 싶고..
프로세스라는 것도 요즘 세상에 ESB 만 따로 파는 벤더는 거의 없다는 것을 생각해 보면
그다지 중요한 차이라고 보긴 힘들것 같네요.
개인적 의견으로 SOA = 서비스 메타 언어(BPEL..) + 서비스 엔진 + 통합 통신망(ESB) 이라는
그럴듯한 구도를 그릴때 사용한 학술/마케팅? 용어라고 봅니다.
EAI 가 스펙을 흡수하기 시작하면서 실제적인 기술로써의 의미는 없는것 같습니다. XML 친화성? 글쎄요.
이상 횡설수설..
|
제목 : Re: EAI와 ESB
글쓴이: 미노(mino) 2006/05/08 14:36:12 조회수:790 줄수:74 |
|
EAI와 ESB에 대한 구분은 분명 명확히 하기 힘들것으로 보입니다.
또한 ESB가 EAI영역을 포함하는 것과, EAI가 ESB의 영역까지를
넓히는것을 생각했을 때, 제가 보기엔 후자의 경우가 더 쉬울 것으로
보입니다.
대부분의 EAI제품들은 웹서비스에 대한 부분을 지원하기 때문이죠.
단 EAI제품의 성격상 Bus형태를 지원하는 경우가 아닌 경우에는 힘들겠지만 말이죠.
전 현실을 직시하고, 미래를 준비해야 한다고 생각합니다.
생뚱맞은 얘기일지는 모르겠지만, SOA가 제대로 적용되기 위해서,
가장 현실적으로 생각하는 것이 ESB 하부구조에서의 EAI를 생각했었습니다.
분명 SOA가 적용되는 프로젝트는 대규모일것입니다.
기업환경에서 세부적인 시스템만 SOA가 적용된다는것은 거의 의미가 없기 때문이죠.
적어도 적사적으로 SOA가 진행되기 위해 서비스를 설계하고, ESB가 적용될 것입니다.
그때 기존의 시스템들이 얼마나 협조를 잘 하느냐도 큰 관건입니다.
즉 ESB가 표준형태의 프로토콜만 적용이 가능하다면, 가능한 연계 시스템들도 있겠지만,
그렇지 않은 시스템들도 분명 존재를 할것입니다.
그리고 대부분의 시스템에세 운영조직만이 존재할텐데, ESB를 위한 연계 모듈 및
기존 프로그램 수정은 거의 힘들것입니다.
때문에 수정사항이 없을 수는 없겠지만, 최소한의 수정사항이 발생해야 한다고 봅니다.
EAI가 표준화된 Protocol보다는 각 시스템에 맞춘 Protocol을 지원하는 이유도,
대부분 위의 이유라고 생각합니다.
위의 이유에서 더 나아가,
EAI가 ESB의 하부에 존재할 수도 있다고 말씀드린 이유는 바로 기존 시스템의
수정사항을 최소로 하여 통합을 전재로 하고 있기 때문에고, 충분히 최대한
현실적으로 접근한 것입니다.
물론 이상적으로 모든 시스템을 Loosly couple하게 만들어, 통합을 한다면
가장 이상적이겠지만 현실적으로 얼마나 가능성이 있을런지 의문입니다.
또한 EAI를 도입하고 나서도, 시간이 지남에 따라 복잡도가 증가하고, 유지보수가
힘들어 지는것에는 제 개인적인 생각이 있습니다.
경험적으로 몇년간에 EAI프로젝트를 진행하면서, EAI가 가져야 할 기능들에 대해서
몇차례 고민을 했던적이 있었습니다.
그 고민의 결론은 EAI는 최대한 단순화 시켜야 한다는 것이었습니다.
(이것은 분명 장단점이 있는 것입니다. 어느게 맞다기 보다는 어느 상황이냐가
더 중요합니다.. 다들 아시겠지만..)
"Enterprise integration Patterns - Addison Wesley"라는 책에서 언급하고 있는
여러가지 EAI Pattern들은 제가 보기엔 별로 바람직하지 않아 보입니다.
특히 "Message Sequence" , "Content-Base Router"등의 Pattern들은 필연적으로
EAI에 Business Logic의 추가를 뜻합니다. (이것을 Business Logic으로 보느냐
그렇지 않느냐에 따라 다를 순 있겠지만요.. ^^)
EAI가 단순화 + 표준화를 중심으로 연계 부분이상을 구현하게 되었을 경우,
기존 P2P형태에 비해 더 많은 테스트와 관련 인력이 필요함을 느꼈습니다.
제가 언급한 사안은 참 많은 논란을 일으실수 있습니다.
보통 예상되는건, " 그럼 EAI가 하는게 뭐냐 - 음.. 이소리 참 많이 들었습니다. ^^"
일텐데..
그져 EAI의 도입으로 기업을 통합하게 되었을 경우, 일본사는넘님이 말씀하신데로,
시간이 지나게 되면, 복잡도가 증가하고, 문서와 구현의 차이점이 증가하여, 분명
그 어느 시스템 보다 유지/보수가 힘들게 될것입니다.
EAI시스템을 개발/운영 하는 사람들은 흔히 얘기하는 super-man은 아니더래도,
그비슷한 능력을 소유한듯한 Force를 가지고 있어야 합니다. ^^
거의 모든 종류의 OS부터 DB .. Program까지를 영역으로 하니깐 말이죠.. ^^
따라서 개발자 구하는게 정말 힘듭니다...
그 상황에서 EAI의 복잡도 증가는 많은 문제점을 가져오죠.. Open이후에도 말이죠.
다른 어떠한 프로젝트(또는 시스템)에 비해서 적절한 인력을 구하는것도 쉽지 않은
이중고를 겪게 됩니다.
일단 여기까지.. ^^
P.S : 몇일 쉬었더니 일이 밀렸네요. 일을 하느라구 제대로 글도 못쓰고, 쓰더라도
횡설수설 되는것 같습니다. 어느순간 한번 정리를 해야겠네요.
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
Http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: 좋은 말씀들입니다.
글쓴이: archidream(guest) 2006/05/08 18:11:02 조회수:754 줄수:55 |
|
위의 이야기들중에 동감이 가는 부분도 있고 그렇치않은 부분도 있지만..
일단 개인적인 생각도 정리도 좀 할겸... 사견을 적어보겠습니다.
=============================================================
Service Oriented Architecture...
SOA라는 단어를 풀어서 쓴 것이다.
왜 서비스 지향 아키텍쳐인가?
- 급변하는 비즈니스 환경에 대해 IT가 민첩(agility)하고 유연(flexibility)하게 변화할 수 있는 환경을
제공해야 한다.
- 급변하는 비즈니스 환경이란....
소비자들의 트렌드가 변화하고... 제조 공정이 바뀌고, Life Cycle 짧은 제품들이 다양한 디자인으로
변화해야 하고... 등등...
다시 말하면 여러 가지 이유로 비즈니스 공정(Process)이 변화하는 것이다.
이러한 공정은 변경되기 전에 테스트 되어야 하고, 공정이 변경 되었을 때
어떠한 공정 개선에 대한 효과(ROI 등)를 얻을지 알 수 있어야 한다.
어떻게 알 수 있을까?
여기서 용어에 대해 잠깐 짚어보자.
■ BPM : Business Process Management
미리 정의된 사람, 정보 자원과 업무의 흐름을 통합적으로 관리,
지원해주는 업무 처리 자동화 기법
또는
기업의 이윤 극대화를 위해 업무 프로세스 를
정의, 구현, 개선, 관리, 자동화 및 최적화하는 시스템입니다
■ SOA : 표준 기반의 공통 사용 가능한 서비스들의 관계를 느슨한 결합으로 모델링 하여
소프트웨어의 서비스화를 지향하는 아키텍처
또는
- 서비스 컴포넌트들의 제공/요청/중계를 지원하는 소프트웨어의 서비스화를 지향하는 아키텍처
- 비즈니스 프로세스에 초점을 맞추고 표준 인터페이스를 사용함으로써 IT 환경이 가진 근본적인
기술적 복잡성을 덮어 주는 기술
-서비스 인터페이스간, 그리고 서비스 인터페이스와 서비스 소비자 사이의 인터렉션과 서비스
인터페이스
결국 SOA란 비즈니스 환경 변화를 가능하게 하는 도구인 것이다.
SOA는 BPM 기반이 아니어도 가능하다. (Data 연계의 관점 등) 하지만,
BPM 기반 SOA가 BPM 기반이 아닌 SOA 보다 효율적으로 비즈니스에 대응 할 수 있을 것이다.
<출처 IBM>
BPM 기반 SOA는 다음과 같은 Life Cycle을 제공한다.
Business Modeling --> Service Assemble(Service Integration)--> Deploy(Run the Process)
--> Manage (Monitoring & Innovation)
위와 같은 단계를 구성하는 것 중에 SOA (또는 SOA의 핵심이라고 이야기 하는 ESB 또는 EAI)는
Service Assemble이다. 정의된 비즈니스를 마침내 IT과 접목하는 순간이다.
이 과정은 민첩성과 융통성을 발휘해야 할 IT의 몫이다. 서두에서 이야기한 왜 서비스 지향 아키텍처가
필요한지, 서비스 지향 아키텍처가 어떻게 제공될 것인지에 대한 부분이다.
여기에서 SOA의 핵심이라고 이야기는 하는 ESB(Enterprise Service Bus)라는 것이 등장하게 된다.
참고 ) ESB에 대해서는 윗글에서 많이 이야기 되어 생략했습니다.
|
제목 : Re: Governance 와 SOA
글쓴이: calmglow(guest) 2006/05/09 00:27:23 조회수:716 줄수:25 |
|
오랜만에 자바서비스넷에 왔더니 참으로 즐거운 토론이 오고갔었네요.
스레드들을 쭉 읽다보니 도움되는 내용이 너무나 많아 즐거웠습니다.
결국 많은 분들이 ESB와 EAI와의 차이점에서 의견차이가 있는 듯 합니다.
저 역시 톡 까놓고 이야기해서 ESB와 EAI 솔루션의 차이가 그리 크지는 않다고 생각합니다.
정말 제품 자체로만 놓고 볼 땐 사실 그렇잖아요? 차이를 찾는 것보단 공통점을 찾는게 훨씬 쉽습니다.
그런데도 불구하고 많은 기존 EAI솔루션을 가진 벤더들이 그 제품과는 별개로
표준기반이랍시고 오히려 기존 EAI보다 성능도 안좋은 ESB제품을 내놓고 있습니다.
게다가 표준이라고 이야기해놓고 내놓은 ESB제품들도 벤더들간에 서로 호환 무지 안됩니다.
앞으로도 쉽지는 않을 것만 같습니다.
그럼에도 불구하고 ESB와 EAI가 다른 점은 ESB가 기존의 Integration만을 담당하던 EAI와 다르게
ESB가 SOA life cycle, 즉 유연한 IT Governance를 위한 SOA 최종 목적인
SOA life cycle 안의 일부분으로 존재한다는 것이 아닐까 생각합니다.
즉, Governancing -> Biz Modeling -> Integration -> Deploy 의 네박자가 자주
반복되면 반복될 수록 IT 유연성이 좋아진다는 SOA 구라 아키텍트들의 입장에서 보았을 때
ESB의 가치가 있는 것은 아닐까도 생각되네요.
위에서도 BPM이야기가 나왔었습니다만 단순히 BPEL수준의 BPM을 넘어 Executive레벨에서 중요시하는
기업 성과 목표치와 전략등이 BPM등과 맞물려 돌아갈 수 있는 SOA기반의
IT Governance의 역할이 SOA에서 매우 중요해지지 않게 되었나 싶네요.
뭐 IT Governance도 어제 오늘 이야기는 아니지만
실제로 각 벤더들이 목표로 하고 있는 혹은 이미 만들어내고 있는 SOA Governance를 위한
제품들을 보면 비록 버그는 무지 많기는 하지만 상당히 놀랄만한 자동화된 비즈니스 관리 모델을
보여주고 있는 듯 합니다.
아무튼.. SOA에서 요새 화두가 되고 있는 IT Governance의 역할에 대한 부분에 대하여
많은 분들의 견해도 듣고 싶네요. ^^
이
|
제목 : Re: 알고들 얘기하시는 건지...
글쓴이: 손님(guest) 2006/05/09 07:18:09 조회수:795 줄수:30 |
|
윗 글들을 보면 마치 딴세상 사람들 얘기 같군요.
도대체 이런 개념들은 누가 만들어 내는 건가요?
제가알고 지금까지 경험한 순수 프로그래밍과는 너무나 거리가 먼 얘기같군요
이러한 개념들이 왜 중요한거죠?
어차피 돌아가는건 컴퓨터에서 돌아가는건데요 아무리 이론적 개념을 떠들어봐야
결국 도는건 컴퓨터 내부처리에 의해 돌수밖에 없습니다.
아무리 추상적인 내용을 떠들어봐야 우리는 컴퓨터 디지털 코드에서 벗어날수 없다는
얘기입니다.
이런 추상적인 개념들을 가지고 다른사람들을 이해시켜 본적 있으신가요?
이해했다한들 과연 제대로 이해된 것 일까요?
아직 객체지향에대한 개념도 제대로 이해못하는 사람들이 많은데 이런 개념이 무슨소용이
있을 까요.
이상하게 자바가 나온이후부터 우리는 용어에서 벗어날수가 없게 됐습니다.
SOA, ESB, SIB, BPM, EAI 등등
무슨내용인지 이해하기 힘들정도의 아주 추상적인 뭉뚱그려진 단어들이 많습니다.
아마도 이모두가 소프트웨어 단가와 진입장벽을 높이기 위한 전략적 마케팅으로 밖에는 보이지 않습니다.
우린 각 벤더가 내세우는 이런 추상적 개념에 놀아나고 있는건 아닌가 생각해봅니다.
역시 솔직하고 단순한 언어가 배우기도 쉽고 사용하기고 훨씬 쉬워보입니다.
|
제목 : Re: SOA ... 어디까지인가? 무엇을 해줄수 있나?
글쓴이: archidream(guest) 2006/05/09 08:24:08 조회수:732 줄수:21 |
|
SOA가 두리뭉실하게 표현되는 단어이다.
구체적인 모습으로 ESB 등이 거론되고 있지만, 현재의 모습에 다들 만족하지 못한다.
IT는 무에서 유를 창조하지 않는다.
항상 컴퓨터라는 것을 기반하고, 기존에 존재하던 사상이나 이론을 구체화 시키거나
변형시킨다.
현재까지 SOA는 그 용어에 대한 정의를 하는데만도 많은 시간이 걸린것 같다.
이제는 좀 더 성숙한 모델로서 SOA를 이야기 해야할 것이다.
기술적인 부분은 여러면으로 가능하리라 본다.
SOA를 구현하는 기술보다는 Service라는 것을 이끌어 내는 것이 더 힘든 일이 아닌가 싶다.
더 많은 이야기들로... 이런 사상들이 성숙되길 바란다.
|
제목 : Re: 윗글에 덧붙여...
글쓴이: archidream(guest) 2006/05/09 08:33:19 조회수:704 줄수:7 |
|
제목 : Re: SOA 토론
글쓴이: 조대협(guest) 2006/05/09 09:45:12 조회수:730 줄수:14 |
|
SOA 토론을 하면서..
참 재미있다는 느낌을 많이 받습니다.
대부분들 제가 고민했던 문제들에 대해서 비슷하게 고민도 하시는것 같고..
세세한 아키텍쳐에 대해서는 다소 이견들도 있는것 같아서 시야를 넓히는데 도움이 되는
것 같습니다.
토론의 내용이 SOA Platform (ESB,BPM)등에서 SOA의 특징과 본질로 조금씩 이동하는것
같습니다.
Platform에 대해서는 어느정도 이야기를 했으니 SOA의 특징들에 대해서 논의해보는것
이 어떨까요? 그리고 SOA가 확산 되기 위해서 필요한 점에 대해서 이야기 해봤으면 합니다.
혹시나 혹시나 했는데.. Governance 이야기 까지 나왔네요..
같이 한번 이야기 해보도록 하지요.
|
제목 : Re: 윗글에 덧붙여...
글쓴이: archidream(guest) 2006/05/09 09:50:19 조회수:709 줄수:7 |
|
제목 : Re: 목수와 건축사
글쓴이: 일본사는넘(guest) 2006/05/09 10:29:27 조회수:773 줄수:43 |
|
일본의 골든위크라는 대형 연휴와 그 끝에 갑자기 불쑥 나타난 퍼포먼스 대책 업무로
바쁜 터라 최근 포스팅을 잘 읽지 못했습니다. 간단한 댓글을 먼저 달고 나중에 찬찬히
읽어보고, 제 의견도 달고 하겠습니다만,
먼저 조대협님:
이제서야 '혹시나 혹시나 했는데.. Governance 이야기 까지 나왔네요' 라니요? (T-T)
제 첫 글에서부터 '기술적인 구축가능성과는 별개로, 진짜 문제는 관리나 정치적인 문제'
라고 적었었는데.. ^^;;
알고들 얘기하시는 건지... 쓴 손님:
우수한 목수가 훌륭한 연장을 들고 할 수 있는 일은 무얼까요? 좋은 개집, 멋진 단독주택까지는
짓겠죠. 그러나 63빌딩을 목수가 지을 수 있을까요? 조엘 온 소프트웨어나 김국현씨의 칼럼에
언급된 바와 같이 IT업계란 실은 모두 같은 일을 하고 있는게 아니죠. 그리고 위에 언급한 두
글에서 언급된 횡적인 구분-게임업계, 웹 서비스 업계, 엔터프라이즈 시스템 구현업계 등- 외에도
종적인 구분-코더, 아키텍트, 설계자, 요건정의자, 프로젝트 매니저 등-도 존재합니다.
만약 코더가 프로젝트 매니저의 회의에 불쑥 들어가 '프로젝트 관리 따위보다 코딩 한줄 한줄에
심혈을 기울이라'고 외치면 어떤 반응이 나올까요? 역으로 프로젝트 관리자가 코더나 아키텍트를
무시한다면 또 어떤 결과가 벌어질까요? 지금 시스템 아키텍쳐의 얘기를 하는데 불쑥 나타나
'역시 솔직하고 단순한 언어가 배우기도 쉽고 사용하기고 훨씬 쉬워보입니다.'
라고 하시면 무어라 답해야 할지 무지 곤란해 집니다. 지금 다른 주제로 얘기하고 있는거거든요.
과연 님이 경험한 '순수 프로그래밍'이라는 것을 저를 비롯한 위의 다른 사람들이 경험을 안 해
보았을까요? 그리고 순수 프로그래밍의 세계만이 이 업계의 전부일까요? 그 순수 프로그래밍이
빛을 발할 수 있는 무대는 어디인가요? 다른 소프트웨어, 시스템과는 별도로 독립되어 혼자서만
고고히 빛날까요?
결국 각자의 레이어에서 각자의 역활을 하면 되는거지요.
상대방의 레이어를 부정할 필요도 없고 그래서도 안됩니다.
혹 추상적인 내용의 지적이 '과도한 추상화'에 대한 지적이라면 레이어 별로 추상화의 수준이
다르다는 말로 대답을 대신하고 싶군요. 더불어 컴퓨터나 프로그래밍 언어의 진화의 역사는
추상화의 역사라 해도 과언이 아닙니다. 디지털 코드에 우리의 사고가 묶여 있었다면 아직도
카드에 구멍 뚫고 있겠죠.
이상 화성인 아키텍트로부터의 답글이었습니다.
|
제목 : Re: SOA 과연 누가 선택할까?
글쓴이: 손님(바보)(guest) 2006/05/09 11:00:21 조회수:705 줄수:49 |
|
여러분들의 의견을 쭉 읽으며 (아직 다 읽지는 못했습니다.) 나름대로 몰려오는
생각들로 저도 잠시 말씀에 끼어들어볼까 합니다.
어쩌면 의견이라기보다는 어찌하면 좋을지 몰라 여려분의 의견을 구하고자 하는
마음이 더 크다로 할 수 있습니다.
제가 지난 몇년간 금융업쪽에서 연계일을 해오다보니 우리가 말하는 최신 기술,
최근 경향과 실제 우리가 만들어야하는 시스템간의 괴리는 과연 누가 해소할까
하는 생각을 하게 됩니다.
SOA 이야기중에 쌩뚱맞게 무슨 소리냐 하시겠지만...
실제 우리나라 금융기관들은 아직도 Main Frame에 Tandem 장비를 사용합니다.
점차 unix로 다운사이징 해가고 있는 추세이고 나름대로들 새로운 시도들을 하고 있으며
어찌보면 돈을 다루는 곳이다보니 굵직굵직한 프로젝트들을 내놓는 주체들이기도 하구요.
하지만 그 속을 들어다보면 당연히 사용하는 언어나 환경도 그에 상응하는 코볼, PL1도
있을뿐더 때론 unix 환경을 이용하면서도 언어를 그대로 사용하는 프로젝트가 진행되기도
합니다. 나름 차세대란 이름을 붙여가면서.
돈을 다루는 것이 워낙 민감한 사항이다보니 어쩌면 아무리 좋은 기술이라도 최우선 해야
하는 것은 안정성이기 때문에 시스템을 함부로 바꿀수 없다는 것이 가장 큰 이유겠지요.
SOA를 언급하면서 언어나 H/W는 큰 문제가 되지 않을지는 모르지만 이런 환경에서
사용자(고객 흔히 갑)이 IT의 트랜드를 이해하고 그 필요성까지 이해하는 수준을 기대하기란
그리 쉽지 않은 상황입니다. 그렇다고 흔히들 말하는 SI업체에서 이런 필요성을 제기한다면
일단 고객 입장에서는 '말은 좋은데 장사속 아닌가?'하는 반응을 보이는 경우가 대부분이고
실제로 그런 오해를 없애기위해 많은 노력을 하게 됩니다. 물론 고객측에도 전산실이나
관련된 기타 부서가 존재하지만 내부적으로 새로운 변화에 대한 필요성을 역설하기에는
많은 제약이 있다고 봅니다.
SOA를 도입하고 구축하는 업체들이 있다고 하는데 SOA를 규정하고 있는 많은 개념들중에서
어느 정도를 충족했을때 '우리 시스템은 SOA 기반에서 구축되어 있다.'고 말할 수 있을가요?
아직도 그 실체를 이해하기도 어려운 BPM, EA를 거쳐 SOA까지...
실제 개념을 설계하고 그것을 이해하고 그 내용을 구축하기까지 대부분의 개념이 IT적인
마인드에서 비롯되었다고 할때 과연 그렇지 못한 사용자를 위해서는 무얼 어떻게 이해시켜야 할까요?
고객이 좋아하는 수지적인 효과는 과연 어떻게 설명해야 할까요?
비지니스적인 빠른 대응은 어떻게 증명해야 할까요?
글을 쓰며 제가 도대체 뭘 말하고 싶은지 저 자신도 바보같다고 느끼긴 하지만
누군가 제 글을 읽으시면서 아주 작은 이유라도 알려주실지 모른다는 기대감에
이 글을 씁니다.
|
제목 : Re: 오타 수정합니다
글쓴이: 손님(바보)(guest) 2006/05/09 11:03:24 조회수:720 줄수:4 |
|
제목 : Re: SOA를 바라보는 시각들..
글쓴이: 미노(mino) 2006/05/09 12:48:12 조회수:686 줄수:55 |
|
이제껏 그 어떤 개념보다 비판적인 시각이 많은게 SOA가 아닌가 싶습니다.
결국 IT환경도 시장이론의 지배를 받게 됩니다.
각 벤더사들은 시장에서 필요할 물건을 미리 판단하고, 생산하여,
홍보하고 매출을 올리게 됩니다.
판단을 할때는 물론 가트너등의 자료가 기반이 되겠지요.
이미 시장에서 확실히 인지하고 있는 제품들을 생산에 들어간다는건,
제대로된 뒷북이 아닐까 싶습니다.
( 비판적인 시각으로 SOA를 바라보는것이 주로 벤더사들에 대한 홍보가 주를 이루기
때문이 아닐까요? )
대부분의 사상들이 그렇듯, 처음에는 구축되고, 확장되며 어느단계에 이르러서
포화상태가 되고 정리할 필요성이 생기게 됩니다.
단지 통합되고, 정리되는것 뿐만 아니라 새로운 Need를 받아들일 수 있는 최적화된
개념으로 진화가 되겠지요.
그것의 1차 단계가 SOA가 아닌가 합니다.
단계별로 나름대로의 진통이 있습니다. 그런 진통들은 확장,포화 단계보다는
그 이후 통합과 최적화에서 더많이 발생할것입니다.
SOA가 실질적으로 다가오지 않는것은 SOA라는 개념의 불확실성 보다는,
현재의 IT환경과, 통합 그리고 최적화로 인한 진통에서의 자기보호 반응은 아닐런지요.
SOA에 제대로 된 지식과 판단없이 그것을 실제적으로 적용하기 위해서 오는
진통과 변화만을 생각한다면, 분명 쉽게 받아들일 수 없을 것입니다.
SOA라는 것을 적용하기 위해 우리가 생각해야할것이란,
결국 현재의 우리의 IT 환경(각자의 IT)환경을 좀 더 체계적이고 현실적으로 받아들이고,
분석하여, 좀 더 최적화시켜야 한다는 것입니다.
(결국 현재의 지금 환경에 대한 제대로 된 이해가 필요하다는 것입니다.)
그리고 IT를 떠나 현재의 기업이 시장이 변화함에 따라 바로바로 대처하기 위해
필요한 상품이 무엇인지를 생각해 내고, 해당 상품에 대한 서비스를 찾아내는 일일
것입니다.
이 또한 IT입장에서의 지원만으로는 되는것이 아닙니다.
모든 업무는 지금보다 간편화(간소화)되어야 합니다.
그리고 나서 비로서 SOA에 대해 생각해야하지 않을까요?
다들 아시는 것들을 써놓았는지 모르겠습니다.
제가 이글에서 말하고자 하는것들은 SOA에 대한 비판적인 시각으로의 접근보다는
좀 더 체계적으로 알아가야하지 않을까 해서입니다.
제 주위에도 일단 SOA라면 부정적인 시각에서 바라보는 견해가 많기에 드리는
말씀입니다.
이 글타래가 좀 더 SOA에대한 부분만을 다룰 수 있었으면 합니다.
P.S : 또 한가지. 맹목적인 추종또한 삼가해야 하지 않을까 합니다.
그져, 이번에 프로젝트 하는데 SOA를 한번 도입해 볼까? 하는 생각보다는
해당 시스템에 대해 좀 더 확실한 시각을 갖고, 더 넓게 바라봐 주셨으면 합니다.
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
Http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: Web services의 정리
글쓴이: 사랑전쟁(lovewar) 2006/05/09 13:42:09 조회수:724 줄수:21 |
|
어제 신문의 광고를 보는 순간 SOA의 마케팅을 하고 있다는 느낌을 받았으며
(오라클 vs SAP)
그리고 오늘 archidream님의 참고자료중 다음 자료를 보고
http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/
SOA를 어떻게 사용(이해)해야 할지를 알게 되었습니다. 의 윤곽을 잡을수
있었습니다.
-- 덧붙이는 글 --
SOA의 혼동은 기술들 보다는 개념을 이해시키지 못해서 오는 마케팅(?) 부재라고 봅니다.
기술들의 이야기와 개념들에 대해서는 토론과정에서 많이들 논의하고 있기에
따로 기술하지 않았습니다.
여담으로 서비스를 받을려면 돈이 많아야 될것이란 생각이 드는군요
(푸드점에서 서비스를 받을려면 돈이 필요하죠).
|
제목 : Re: SOA 벤더들을 구분할때....
글쓴이: archidream(guest) 2006/05/09 14:44:15 조회수:779 줄수:49 |
|
Business 측면의 벤더와 Technical 측면의 벤더로 구분한다고 합니다.
Business 측면의 벤더 : HP, ORACLE(?), SAP등...(platform을 제공할수 없는 벤더)
Techinical 측면의 벤더 : IBM, BEA 등...(platform을 제공할 수 있는 벤더)
한마디로 SOA를 바라보는 관점이 틀린 것입니다.
SOA는 정의하기 나름입니다. 단지 그 의미가 일맥상통하면 SOA인것입니다.
SOA 표현할때 많은 벤더들이 ESB를 핵심이라고 이야기 합니다.
그 이유는 Flexible한 서비스를 제공해줄 연결고리이기 때문이죠..
- 여기에서 내부적으로 ESB가 실현될때 각종 다양한 프로토콜을 지원해야하기에
기존 EAI의 방식을 가져올 수 도 있습니다.
SOA의 핵심은 서비스 기반으로 구성을 해주는 것입니다.
변화하는 비즈니스 환경에 대응 하기 위한 IT의 방패(?)인 것이죠.
따라서 변화할 수 있어야 SOA인 것입니다.
조대협님이 시작한 SOA에 대한 이야기가 이렇게 많은 답글들로 엮일 수 있는 것도
SOA에 대한 다양한 관점들일 것 입니다.
SOA를 구현할 때 IBM 제품을 사용하신다면 IBM의 사상을 따르십시요...
또 BEA의 제품을 사용하신다면 BEA의 사상을 따르시고요...
단지 SOA라는 단어 앞에서 걱정되는건....
ESB의 기능도 아니고, 지원되는 프로토콜의 기능도 아닙니다.
단지... 어떤 방법론을 가지고 SOA에 접근할 것이냐는 거죠....
IBM은 SOMA, SODA, CBM 등의 방법론을 제시하고 있습니다.
다른 벤더들, 컨설팅 펌도 가지고 있습니다.
현재 이런 방법론들이 검증되지 않은 것이겠지요....
SOA 실행을 위해... 준비해야 할 것이 이런것들이 아닐까 싶네요...
SOA를 위한 솔루션들도... 몇 해가 지나면... 현재의 WAS 처럼 되겠죠....
변화하는 SOA를 붙잡아둘려고 하지 맙시다... ^^;
|
제목 : Re: 제가 이해하고 있는 SOA..
글쓴이: 손님(guest) 2006/05/09 14:47:37 조회수:709 줄수:21 |
|
제가 이해하고 있는 SOA는...아주 간단한 것인데 너무 심오한(?) 이야기들이
계속 나오니 조금 당혹스럽군요. 내가 잘못 알았나...싶기도 하고..
제가 아는 SOA의 목적은 단 한 단어로 요약됩니다. 연동.
조직 내의 다양한 서비스를 쉽게 연동하기 위한 수단으로 SOA가 존재하는 것이죠.
이것 이외에 SOA에 어떤 다른 특별한 장점이 있는 것 같진 않습니다.
다른 부서의 서비스를 마치 우리 부서의 서비스인양 조합해서 쓰고 이런 거
이제까지 없었던 기능도 아니고 그 동안 명시적으로 SOA란 말을 붙이거나
표준화된 아키텍처를 사용하지 않았다 뿐 이미 다 해왔던 일들이죠.
이제 SOA란 개념의 등장으로 그런 것들을 표준화하고 편하게 하려는 시도들이
많이 생기고 있다..그런 정도인 것 같습니다.
IT 업계에 어떤 혁명적인 변화를 가져올 그런 것도 아니고 ROI를 확 높일 수 있는
그런 것도 아닙니다. 그냥 문서 교환의 표준으로 XML이 도입된 것처럼 서비스
교환의 표준으로 SOA가 등장했다..그 정도가 아닐까요. IT 업계에 미칠 영향도
XML이 도입될 때의 그것을 별로 넘어서지 않을 것입니다. 물론 그것만으로도
유용한 개념임은 틀림 없지만 여러 벤더들에 의해 과도하게 포장된 것 또한
사실인 듯 합니다.
|
제목 : Re: 음...답글을 적고나니...
글쓴이: archidream(guest) 2006/05/09 14:48:45 조회수:680 줄수:8 |
|
약간...다소 회의적인 논조인듯 해보입니다.. --;;
사실 그런 의도는 아니였는데....
이 토론이 보다 다양한 이야기들로... 엮어졌으면 합니다..^^;
SOA 구현 방법론도 하나의 화두가 될듯해서 덧글 붙인것입니다..^^
|
제목 : Re: 또 다른 생각..^^
글쓴이: archidream(guest) 2006/05/09 14:51:22 조회수:726 줄수:7 |
|
제목 : Re: 또 다른 생각..^^
글쓴이: 손님(guest) 2006/05/09 18:23:10 조회수:713 줄수:4 |
|
저건 이희승씨가 생각하는 것이 아닌 일반적인 ESB의 Concept으로 보여집니다.
Forrester Research, Gartner 및 벤더 ESB의 mixed image같군요.
|
제목 : SOA의 필요성과 추진되지 않는 이유..
글쓴이: u2(Rainman1) 2006/05/09 18:33:19 조회수:1277 줄수:97 |
|
esb와 eai가 많이 언급되고 있네요.
개인적으로는 soa를 언급할때 eai와 esb 는
같이 언급될 대상으로 놓기에는 적절치 않다고 생각합니다.
soa라 불리우는 아키텍쳐가
integration이란 관점을 배경으로 깔고 있는 것도 아니고,
service bus를 만들기 위한 기반환경과 구현기술과도 상관이 없다고 생각합니다.
굳이 언급을 하자면, cbd나 wfms가 언급이 되는게 맞지 않을까 싶네요..
'왜..'라고 묻는다면 soa는 '크기'란 개념에 대한 문제이기 때문이죠.
통상 우리가 손으로 움켜쥐고 싶은 것(오브젝트)을
핸들링 하기 위해서는 비즈니스엔터티, 혹은 액티비티를 개념상으로 디자인합니다.
이것들은 기반환경 위에서 각종 협력과 기능을 수행하고
기반서비스를 미들웨어로 부터 제공받아서 동작을 하게 됩니다.
즉, '제어와 협력'이란 것은 기반환경, 기타 미들웨어에서 돌고 있다는 얘기입니다.
해당 미들웨어나 기반서비스들은 layered archtecture를 기반으로 작성되어 있습니다.
하위 계층에서 상위를 위한 서비스를 제공해서 더 큰 목적을 달성해 나가는 방식이죠.
좋은 개념이고 분명 우리가 현재도 잘 쓰고, 적용하고 있는 아키텍쳐입니다.
그렇지만 생각해봐야 할 것은 그러한 layer가 반드시 정답인가..란 것입니다.
통상 기반환경 위에 올라간
단위 개념들에 대한 개개인의 관심사는
그러한 사이즈에 맞춰가야 되고, 특정수준 이하로는 용인되지 않습니다.
(기반환경을 벗어나서 별개로 구축하지만 일관된 적용을 위한 그룹핑에 곤란함을 겪습니다.
이러한 이유로 개념들의 사이즈라 것은 기반환경에 의해서 결정되어 있고,
손에 쥐고자 하는 개념들이 전반적으로 메모리상에서 존재,협력,구동되고 있을 뿐이죠.
개개인의 개념에 대한 구현과 관심사가 특정계층과 사이즈로 집중하는게 현재입니다.
자.. 그렇지만, 해당 미들웨어에 올라가는 비즈니스는
단 하나가 아니라 상이한 성격과 목적의 비즈니스들이 무수히 많이 올라갑니다.
게다가 그러한 비즈니스들의 주체는 단 한사람이 아니고,
다양한 높이의 시선과 관심사를 가진 무수히 많은 시스템과 사람들이 됩니다.
다수가 연결된 비즈니스에서 롤에 따라 뭉게서 인식해도 되는 비즈니스가 있고,
정밀하게 핸들링을 해야 하는 비즈니스도 있습니다.
게다가 이런 비즈니스프로세스는 여럿이 갖가지로 묶여있죠.
우린 실제 개념들의 단위로 인식하기를 원하고 구성하기를 원하고 핸들링하기를 원합니다.
아키텍쳐나 방법론의 개념따위는 누구도 원하지 않고,
단지 현실 그대로의 '개념'이 보여지기를 원할 따름입니다.
이러한 이유로 같은 비즈니스라도
다양한 관점에서의 '개념'을 지원하기 위해서는
작은 사이즈의 저수준의 서비스도 필요에 따라서 구성할 수 있고
layer 구분없고, 사이즈에 상관없이 조립할 수 있는 아키텍쳐를 필요로 합니다.
그래서 soa가 필요한 것입니다.
참으로 '자유도가 높은 훌륭한 아키텍쳐'이자 '아무것도 아닌것'일 수도 있지만,
layer를 탈출하자는 것이 한단계 더 나아가기 위한 대안이 될 수도 있겠죠.
하다 못해 soa로 컴퓨터를 만들 수도 있고, db도 만들 수 있죠..
계산기도 만들 수 있을겁니다. 물론 service간의 collaboration으로 말이죠.
좀 더 나아간다면 집합적 지성을 만들어서 좀 더 크게 원하는 것을 구현할 수도 있겠죠.
기존의 아키텍쳐라면 자신이 소유하고 메모리상에서 구동해야 겠지만,
soa라면 사용자의 관심사에 따라 비즈니스에 대한 디스크립션을 작성한 것 만으로,
서비스세계에서 내가 원하는 기능의 커스터마이징된 computer를 만들어낼 수 있습니다.
필요할 때에 필요한 식으로 누구든지 언제라도 다르게 말이죠..
물론 지금은 우리가 만든 서비스를 누군가가 요청해서 쓰는것이 당연하겠지만,
사용자가 서비스디스크립션을 만들어서 쓰는 것이 앞으로의 흐름이고,
그것은 이미 5~6년전부터 관심있던 사람들의 머릿속에 그리고 있던 그림들이 아닐까 싶네요.
그런데 왜 적용이 되지 않는 것일까..
다음과 같은 이유때문이라고 생각합니다.
첫번째는 밴더가 흐름을 integration과 제품판매 수단으로 잡은 것이고..
둘째로는 리더가 밴더를 추앙하면서 그대로 따라가기 때문이고..
셋째로는 이러한 개념에 대해서 찬성으로 손을 들어줄 사람이 많지 않다는 것이고..
넷째로는 서비스인프라 구성이 되어야 하는데 어느순간 폭발적으로 늘어나야겠지만,
그것은 이러한 방식으로 내 서비스를 쓰고,공유하고 싶다는 생각을 가진 유저들이 많아질 때입니다.
조금 더 정확히 말하자면 서비스를 프로그래머가 아닌 사람이 생산해낼 수 있어야 됩니다.
다섯째로는 선례가 없고..
여섯째로는 경험있는 기술자가 없고..
일곱째로는 기반서비스가 없기 때문에 어려움이 있습니다.
이러한 것들을 극복하고서라도 개인과 조직이 잘 융합되서
soa의 지침이 될 수 있는 선례(거대프로젝트)를 남길 수도 있겠지만 쉽지 않은 문제입니다.
soa의 적용문제는 뜬구름이라 적용되지 않는 것도 아니고.. 검증되지 않아서도 아니고..
'리딩하고 진행할 수 있는 리더'가 없어서 진행이 안됩니다.
왜 ibam, oracle, ms가 발벗고 달려들지 않을까요.. 확신이 없기 때문이죠..
그렇지만 분명 여러 프로젝트와 회사의 아키텍쳐팀과 개인, 학생, 교수님들 등등..
시도와 고찰은 꾸준히 진행되고 제안되고 있고
그것의 성과가 비록 실패라도 가까운 시일내에 자주 사례가 발생하겠죠..
그런 프로젝트에 참여한다고 생각하면 상상만해도 신이 나네요..
그런 선경험과 많은 실패를 경험하면서 엮어낸 노하우를 통해
우리나라가 soa를 주도해 나가면 얼마나 좋을까 상상을 해봅니다.
언젠가 한번 soa대해서
마구마구 의견을 토해보고 토론해보고 싶었는데..
역시나 제대로 씌여지지도 않고 시간도 용납되지 않네요.
나중에 시간이 허락한다면 soa 추진 방법론에 대해서 얘길해보고 싶네요..
마지막으로 얘기하고 싶은것은 soa는 이미 5년전에 기반환경이 다 마련되었머,
우리가 고민하는 기술적인 문제들은 단지 서비스일 뿐 그 이상도이하도 아니다..라는걸 말씀드리고 싶네요.
p.s 개인적인 주관과 독단입니다.
|
제목 : Re: 보충설명 요청
글쓴이: 일본사는넘(guest) 2006/05/10 03:14:10 조회수:755 줄수:26 |
|
늦은 시간이지만 안 자고 지난 글들을 읽어 보았습니다. 다른 글들에 대해서는 저도 비슷한
생각을 가지고 있거나 사소한 견해차의 범주를 벗어나지 않는 차이입니다만 u2님의 글은
조금 보충설명이 있었으면 합니다.
u2님의 의견에 대해:
- 먼저 님의 글이 엔터프라이즈 시스템을 기준으로 작성된 것인지 아니면 기업과는 무관한
개개인의 사용자의 관점에서 작성된 것인지 알려주시면 감사하겠습니다. (아니면 두가지 관점을
다 가지고 뭉뚱그려 쓰신 건지도..)
- '사용자가 서비스디스크립션을 만들어서 쓰는 것'은 구체적으로 어떤 행위를 말하는 것인지요?
- 아키텍쳐에서 레이어는 필요없다는 얘기를 하고 계신 건가요? 아님 SOA에서는 레이어가
없다는 얘기를 하시는건가요? ( 일반적인 SOA의 정의에 의하면 각 서비스들에도 크기의 차이가
존재하고 그에 따른 레이어도 존재합니다. 누가 맞고 틀리고의 얘기가 아니고 일반적으로 그렇다는
겁니다.)
- 그리고 말씀 하신바와는 달리 IBM을 비롯한 각종 대형 밴더들은 이미 SOA를 향해 달려나가고
있습니다. 실은 남보다 빨리 달려나가기 위해 경주를 하고 있는 상황이라고 보는게 더 맞겠죠.
- '리딩하고 진행할 수 있는 리더'란 구체적으로 누구를 말하는지요?
- '우리가 고민하는 기술적인 문제들은 단지 서비스일 뿐 그 이상도이하도 아니다'라는 말의
의미도 잘 이해가 안됩니다. (제 머리가 나빠서..)
|
제목 : Re: 스타벅스 메타포를 이용한 SOA Governance
글쓴이: calmglow(guest) 2006/05/10 11:48:00 조회수:1158 줄수:101 |
|
저는 요새 '조엘이 엄선한 소프트웨어 블로그 베스트 29선'이라는 책을 매우 재미나게 읽고
있습니다. 여기에 엄선된 글 중 그레고르 호페의 글이 유독 제 시선을 끌었는데요, 스타벅
스의 음료 주문 처리 방식을 IT관점에서 바라본 것이죠.
저는 이 메타포에 의한 접근을 이용하여 SOA Governance를 풀어가는 것도 재밌겠다는 생
각을 해보게 되었습니다.
스타벅스 커피숍에 등장하는 직군은 크게 네 분류로 나뉩니다.
바리스타와 캐시어 그리고 이들을 지휘하는 커피숍 팀장과 사장입니다. 그레고르 호페는 스
타벅스에서 음료 주문을 처리하는 방식에 주목해보았습니다. 스타벅스는 다른 모든 사업체
와 마찬가지로 주문 처리량을 극대화하는 데 집중했습니다. 주문을 더 많이 처리할 수록 수
익이 늘어나기 때문이죠.
그렇기 때문에 스타벅스에서는 비동기적 프로세스를 사용합니다. 고객이 주문을 하면 캐시
어는 커피 컵에주문을 표시해서 대기열에 올려놓습니다. 이 대기열은 말 그대로 에스프레소
기계 위에서 커피컵이 대기하고 있는 줄입니다.
이 대기열은 캐이어와 바리스타를 구분해주는 역할을 하며, 바리스타의 일손이 부족해서 잠
시 도움을 받는 한이 있더라도 캐시어가 계속 주문을 받을 수 있게 해줍니다.
스타벅스는 비동기 방식의 장점을 채택하는 동시에 비동기 방식에서 필연적으로 나타날 수
밖에 없는 문제점을 해결해야만 했습니다. 예를 들자면 상관관계(correlation)같은 것이죠.
음료가 반드시 주문한 순서대로 나오지는 않습니다. 그 이유는 두 가지입니다.
우선 첫째, 바리스타가 여러 명 있는 경우에는 각 바리스타가 서로 다른 장비를 사용해서
주문을 처리하기 때문입니다. 블렌드 음료는 드립 커피보다 만드는 데 시간이 더 오래 걸리
지요.
둘째 이유로는 바리스타들이 주문 처리 시간을 최적화하기 위해 음료 여러 잔을 동시에 만
든다는 것을 들 수 있습니다.
결과적으로 스타벅스에서는 상관 관계에 따른 문제가 발생할 수 있습니다. 음료는 주문 순
서와 다른 순서로 나올 수도 있지만 주문한 사람에게 반드시 제대로 전달돼야 한다는 것입
니다. 스타벅스는 이 문제를 우리가 메시지 구조에서 사용하는 것과 동일한 "패턴"으로 해
결했습니다.
즉 상관 관계 식별자(Correlation Identifier)를 사용한 것이지요. 미국에 있는 대부분의 스
타벅스 매장에서는 컵에 고객의 이름을 써 넣는 식으로 상관 관계 식별자를 사용하고, 음료
가 나오면 고객의 이름을 크게 부름으로써 상관 관계에 따른 문제를 해결합니다.
다른 나라에서는 일반적으로 주문한 음료의 종류로 주문자를 식별합니다.
여기까지가 제가 읽은 글의 요약입니다. 한마디로 스타벅스의 음료 주문 처리 방식은 우리
가 익히 알고 있는 비동기 방식의 메시징 처리 시스템과 유사합니다. 비록 무리가 있겠지만
이러한 스타벅스 음료 주문 시스템을 한 기업의 전산 시스템이라고 생각해보지요. 그러면
커피숍 팀장은 전산과장 정도 되는 사람이라 할 수 있겠습니다.
커피숍 팀장은 이들 바리스타와 캐시어가 정해진 스타벅스의 음료 주문 시스템에 따라 제대
로 업무를 진행하고 있는지를 감시(Resource Monitoring)하고 조율(Deploy and
Integration)하는 일을 맡고 있습니다.
즉 커피숍 팀장의 관심은 오로지 Business Process 자체에 관심이 많고 그것을 예의 주시
하면서 자원 부족 상태등을 해결하는 데 관심을 가지고 있습니다. 커피숍 팀장의 이러한 관
심을 충족시키는 솔루션이 기존 EAI제품이 되었건 ESB+BPM이 되었건 커피숍 팀장의 관
점은 오로지 자원 관리와 인력 투입을 만족하는 기능에만 있겠죠.
자 그럼 이제 관점을 커피숍 사장으로 돌려보겠습니다.
스타벅스 커피숍 사장은 당연히 가장 적은 투자로 가장 높은 수익을 발생시킬 방법을 찾는
데 혈안이 되어있습니다. 사장이 가장 관심을 갖고 있는, 혹은 관심을 보이는 부분이 어떤
것일지 제가 비록 사장이 되본 적은 없지만 한번 유추해보도록 하겠습니다.
- 직원들 노는 꼴은 절대 못본다. 그들의 월급은 최소한으로 줄여야만 한다.
- 하루 중 고객이 붐비는 시간 대는 정해져 있다.
- 고객이 붐비는 날은 요일마다 다르고 계절마다 또 다르다.
- 아무리 고객이 붐비더라도 그들이 짜증을 내지 않도록 음료 주문 시간은 최소화 해야만
한다.
대충 이러한 관심 사항이 보입니다. 그리고 최종적으로 사장이 관심을 보이는 목표가 ROI
라고 할 때 투자와 수익 항목을 보다 단순화해서 보자면 직원들의 월급은 투자에 해당되고
수익은 고객 수에 비례할 것입니다.
즉 고객이 최대한 불편해하지 않는 선에서 직원들 수는 최소화하는 것이 스타벅스 커피숍
사장이 관심을 가지는 항목이 되겠습니다. 여기서 고객이 최대한 불편해하지 않는다는 기준
이 매우 애매모호 하므로 보다 수치화해서 생각해보면 고객이 커피를 기다리는 시간이 최대
2분 이하일 경우에 만족할 수 있다는 가정을 하겠습니다.
그리고 아무리 고객의 만족이 최우선이라 할지라도 무한대의 투자를 할 수는 없으므로 직원
들 월급 역시 한달에 천만원 이상은 지불할 수 없다고 가정할 수도 있습니다.
그럼 이제 이렇게 정해진 몇 개의 커피숍 운영 목표 달성을 위한 수치들이 정의되었으므로
이 수치들에 맞추어 사장은 스타벅스 커피숍을 둘러싼 여러 상황을 분석할겁니다. 일단 커
피숍 이익을 둘러싼, 커피숍 상황을 한 눈에 바라볼 수 있는 차트가 필요할 겁니다. 여기에
는 감히 커피숍 팀장은 관심가질 수 없는 여러가지 요소들, 직원 월급이나
임대료, 고객 기호나 고객 만족도등을 포함하고 있어야겠죠. 이것을 운영을 위한 프로세스
모델이라고 일단 부릅시다.
사장은 끊임없이 이 프로세스모델을 통해 하루 중 고객 peak time과 계절과 요일별 peak
time등에 따라 적절한 직원 분배를 하여 이익을 극대화하려고 할 겁니다. 문제는 시장 상황
이 항상 변한다는 겁니다.
앞서 언급했던 계절별 요일별 고객의 반응도 항상 달라지고 경쟁사와의 관계에 따라서도 전
체 매출 자체가 달라질 수가 있습니다. 따라서 프로세스 모델은 커피숍 운영 전략에 따라
계속 변경이 되어야 하고 바뀐 프로세스 모델에 따라 실제 운영 역시 반영이 바로 바로 되
어야 겠습니다.
위에서 제가 스타벅스 커피숍 메타포를 통해서 SOA의 life cycle인 monitoring ->
modeling -> integration -> deploy -> monitoring...를 이야기했습니다.
즉 사장은 끊임없이 자신이 원하는 기업 성과 수치와 모델을 바탕으로 기업 상황을
Monitoring하고 자신이 원하는 방식으로 비즈니스 적인 상황을 Model에 반영합니다. 이
Model은 별도의 수동적인 변환없이 운영 환경에 반영되어서 새로운 자원의 투입이나 기존
자원의 통합이 자유롭고 이것에 대한 최종 반영 역시 부드럽게 이어지는 그 lifecycle.
이것이 SOA가 지향하는 유연한 IT Governance라고 할 수 있을 것 같습니다.
뭐 사실 integration과 deploy부분만 따로 떼놓고 생각해보면 ESB나 EAI솔루션들이나 거
기서 거기인 듯 싶습니다만, 기업 운영자 관점의 성과 수치등을 모델에 반영하고 이것이 다
시 IT 운영 환경에 즉각적으로 반영될 수 있는 유연한 IT Governance 환경까지를 놓고 보
자면 ESB와 EAI솔루션은 목표 자체에 있어 차이를 가지고 있다고 생각합니다.
---------------------------
http://calmglow.egloos.com
mail:calmglow@gmail.com
---------------------------
|
제목 : Re: 벤더 구분
글쓴이: kaljil(guest) 2006/05/10 17:03:08 조회수:725 줄수:9 |
|
글을 읽다가 보니 벤더를 아래와 같이 구분했는데요.
Business 측면의 벤더 : HP, ORACLE(?), SAP등...(platform을 제공할수 없는 벤더)
Techinical 측면의 벤더 : IBM, BEA 등...(platform을 제공할 수 있는 벤더)
ORACLE, SAP, IBM 등은 business와 technical 모두를 가지고 있다고 생각합니다.
ORACLE은 SOA SUITE이라고 하는 플랫폼을 제공하고
SAP는 넷위버라고 하는 플랫폼을 제공하고 있지요
IBM은 IBM BCS컨설팅이 비즈니스 컨설팅을 제공하고 있구요
|
제목 : Re: Governance
글쓴이: 조대협(guest) 2006/05/10 17:05:51 조회수:762 줄수:48 |
|
위에서까지 ESB냐.. EAI냐.. 에 대한 열띤 토론을 하기는 했습니다만...
사실 상당히 비슷하지요.. 어느것이 편하냐? 또는 어느것이 적절하냐?의 차이지 SOA를
구축하는데 ESB냐 EAI는 큰 논점이 되기 어려운것 같습니다.
calmglow 님께서 스타벅스를 예를 들어 Governance에 대한 설명을 잘해주셨는데요.
SOA는 아키텍쳐 측면도 중요하겠지만 더 중요한것은 Business측면에서 Governance를
구축하기 위함이 아닌가 싶습니다. Agility역시 이 Governance를 지원하기 위한 수단일
뿐이구요...
BPM에 대한 이야기가 다시 나오는데..
결국 모든 시스템을 서비스화한다면 결과적으로 Agility와 Governance에 대한 효과가
나오는것은 BPM이라고 봅니다.
결과적으로는 이 BPM을 얼마나 잘 뽑아 내느냐가 SOA의 성패가 달리겠지요.
calmglow님께서 프로세스를
monitoring -> modeling -> integration -> deploy -> monitoring
이렇게 정의 하셨는데요.
저는 감히 이렇게 제안 드리고 싶습니다.
기존 프로세스 분석 (analysis or monitoring) --> simulation --> modeling --> implementation
--> deploy --> monitoring
비슷한 내용이지만 사족처럼 단계를 더 달아봤습니다.
이유는 이런 BPM에 대한 요구에 따라서..
기존의 비지니스 프로세스를 분석하고 시뮬레이션할 수 있는 도구 BPA와 등장과
BPM의 동작 상태를 모니터링하기 위한 도구 BAM의 등장을 언급하기 위해서입니다.
실제로 BPA-->BPM-->BAM 의 구현은 논리상으로나 이론상으로써는 매우 훌륭합니다.
BPM을 통한 Gorvernance의 구축 또한 매우 훌륭한 개념입니다.
Accenture에서는 제가 위에서 언급한 SOA의 3단계 모델에 이 BPA와 BAM을 더한 4단계
발전 모델을 제시하더군요. 저도 이부분에 동감합니다.
그러나.. 제가 가지고 있는 SOA대한 생각은 실현 가능성에 많은 의문을 가지고 있습니다.
많은 업체들이 최적화된 BPM을 스스로 구축하기에는 '아직' 어렵다는 것이지요.
어려운점이 하~~도 많아서 일일이 언급하기 조차 어렵습니다.
(구현이나, 정책적으로 BPM을 소화할 수 있는지, Governance화에 따른 IT조직 비대화에 의한 정치 싸움
등등등.._)
그래서 저는 단계적 SOA발전 모델에 흥미를 가지고 있구요.
BPM 을 훌륭하게 구축할 수 있도록 그 아래 Layer를 구현할 수 있는 기술을 갖추는것이
일단 IT 개발자의 몫이라고 봅니다..
오늘 이리저리 회의 참석했더니.. 아니나 다를까 오늘도 횡설수설하네요..
^^
|
제목 : Re: 글을 써놓고 보니....
글쓴이: 조대협(guest) 2006/05/10 17:15:00 조회수:865 줄수:21 |
|
윗글을 써놓고 보니.생각이 정리가 안되고 써놨네요..
SOA를 구축함에 있어서
"BPM이 중요하다"라고 언급을 드려서.. 오해를 드릴까봐 덧 붙여 설명합니다.
일단 BPM에서 많은 효과가 나는것이 사실이지만..
가장 중요한것은 개인적으로 Service 자체를 어떻게 나누고 구축하느냐..
에 대한것이 가장 중요하다고 생각합니다.
아.. 그리고... 지금 SOA에 대한 Boundary가 Architecture 측면이랑 Business측면을
오락가락 하네요... Architecture 측면에서
제 개인 생각으로는 기존 시스템의 Service화 하는 부분과
모니터링
그리고 성능에 관해서 SOA는 약점들을 많이 가지고 있을거라 생각하는데요.
약점과 대안에 대해서 이야기 해봤으면 좋겠습니다.
먼저 WS*(Extension)으로 정리되지 않고 난립하고 있는 standard 역시 SOA로 가는
난재가 될것이라고 생각하고 이에 대한 대안들이 필요하다고 생각하는데..
다른분들은 WS* 에 대한 생각들은 어떠신지요?
|
제목 : Re: SOA의 5대 신화
글쓴이: 조대협(guest) 2006/05/10 17:36:59 조회수:788 줄수:40 |
|
재미있는 글이 있어서 퍼옵니다.
SOA에 대해서 고민하는 내용은 다들 비슷한거 같은데.
정리를 잘해놓은것 같네요..
영원히 묻혀져야 할「SOA에 관한 5가지 신화」
Joe McKendrick ( CNET News.com ) 2006/05/04
인텔리전트 엔터프라이즈의 더그 헨센은 기업 임원들의 의견을 바탕으로 SOA에 관한 5가지의 신화를
정리했다. 하는 김에 나의 해설도 추가했다. 하루빨리 이러한 신화를 묻어버려야 한다.
신화 # 1. SOA는 간단하다
매우 많은 벤더들이 SOA를 곧바로 이용할 수 있을 것처럼 떠들어대지만, 잊어서는 안 되는 것이 있다.
정확하게 ‘SOA는 다른 수단보다 간단하다’고 해야 한다. 무엇과 비교해서 더 간단하다는 말인가?
사일로형의 독점 시스템에 붙박힌 비즈니스 프로세스를 관리하거나 변경하는 것보다 더 간단해야 한다.
신화 # 2. SOA를 도입하도록 경영진을 설득하는 것이 최대의 난관이다
신화 #1에서 언급한 것처럼 SOA를 잘 다루려면 거듭되는 노력이 필요하다. 헨센은 “SOA의 표준을
지키기 위해서는 조직 내의 규율을 바로잡고 엄격한 거버넌스를 실시하는 것이 필요하다. IT와 현업
관리자뿐 아니라 최고 경영 임원으로부터의 계속적인 지원을 받지 않으면 안 된다”고 말했다.
아, 신이시여. 역시 노력하고, 노력하고, 노력해야 한다.
신화 # 3. 기존 시스템을 쉽게 서비스로 포장할 수 있다
다시 신화 # 1을 보라. 신화 # 3에서 말하는 내용을 실현하려면 하루를 꼬박 소비해야 할 것이다.
SOA는 기존 시스템 자체를 표준 서비스로 가공해야 하기 때문이다. 요컨대 ‘쉽게’라는 부사가 문제다.
신화 # 4. SOA는 구매하자마자 사용할 수 있다
한 번 더, 신화 #1을 참조할 것. 설명은 이제 충분할 것이다.
신화 # 5. (SOAP over HTTP 같은) 웹서비스를 이용하고 있다면, SOA는 실현될 수 있다
또다시 신화 # 1을 떠올리자. 웹서비스를 구축하는 것은 실로 간단하다. 몇 시간 내에 열 가지는 구축할
수 있을 것이다. 하지만 단지 ‘JBOWS(Just a Bunch of Web Services：장난이 난립한 웹서비스)
아키텍처’가 완성되는 것만으로 끝난다. 이것은 완전히 별개의 SOA, 즉 ‘Spaghetti-Oriented
Architecture(스파게티와 같이 질겅질겅한 아키텍처)’를 만들어낸 것에 불과하다. SOA는 서비스와
거버넌스 사이의 균형이 필수다. @
원문 : http://www.zdnet.co.kr/news/enterprise/soa/0,39036655,39147239,00.htm
|
제목 : Re: 그 마인드맵은...
글쓴이: 이희승(anoripi) 2006/05/11 00:24:19 조회수:751 줄수:33 |
|
여러 아티클들을 종합해서 ESB 를 정의해 본 것입니다.
물론 제 경험을 바탕으로 중요한 것을 위주로 나열해 보았지만요.
저 같은 경우 웹 서비스가 아닌 경량 프로토콜에 기반한 경량 ESB 를 이용해
SMS 전송 시스템을 구축한 이력이 있습니다. 트랜스포트 자체가 달랐지만
개념은 살려서 구현했습니다.
일단 동일한 프로토콜과 미리 정의된 데이터 모델로 데이터를 주고 받았기
때문에 비즈니스 프로세스의 변경에 따른 각 서비스의 추가 삭제 재배치가
아주 쉬웠습니다. 그야말로 어떤 변화에도 손쉽게 적응할 수 있었고,
개발이 거의 완료된 뒤에는 새로운 서비스 개발이나 버그 수정이 아니면
대부분은 룰 파일을 수정함으로써 모든 비즈니스 로직을 구현할 수 있었습니다.
물론 이미 다른 분들께서 논의하신 것처럼 SOA가 지향하는 바는 제가 이 글에서
언급한 것보다 더 광의적인 면이 많습니다만, 문제를 어떻게 해석하느냐에 따라
SOA 의 적용 범위는 많이 달라질 수 있지 않을까 생각합니다. 문제는 어느
경우에 얼마나 더 적절하냐겠지요.
요약하면:
* 잘 된 SOA는 비용을 상당히 절약시킬 수 있다.
* 다른 곳에서도 마찬가지겠지만 SOA에 있어서 업무 파악은 매우 중요하다.
* 데이터 모델의 정의
* SOA는 그 뜻의 범위가 매우 다양할 수 있고 적절한 판단이 필요하다.
요약해 보니 다른 아무 기술에 대해 이야기해도 동일한 이야기가 아닐까 하는
느낌도 드는군요. 제 지식이 많이 부족하다고 이해해 주시면 좋겠습니다.
--
what we call human nature is actually human habit.
--
http://gleamynode.net/
|
제목 : Re: 일본사는넘님 보충설명입니다.
글쓴이: u2(Rainman1) 2006/05/11 01:24:05 조회수:713 줄수:53 |
|
회사에서 장문의 답글을 써서 다듬어 올리려 했는데..
피곤하고 작성할 시간도 없는듯해서 자기전에 짧게 간추려서 긁적여봅니다.
졸려서 제대로 쓰려나 모르겠네요. 궁금하거나 개념이 이상하다 싶으시면 태클환영입니다.
- 먼저 님의 글이 엔터프라이즈 시스템을 기준으로 작성된 것인지 아니면 기업과는 무관한
개개인의 사용자의 관점에서 작성된 것인지 알려주시면 감사하겠습니다. (아니면 두가지 관점을
다 가지고 뭉뚱그려 쓰신 건지도..)
: 엔터프라이즈 시스템 기준입니다. 기업과 무관한 개개인 사용자의 관점과 차이가 없다고 생각합니다.
- '사용자가 서비스디스크립션을 만들어서 쓰는 것'은 구체적으로 어떤 행위를 말하는 것인지요?
: programmer가 아닌 사람이 서비스를 생산해내는 일련의 행위를 말합니다.
서비스를 만들어 내는 것은 서비스를 조합시키는 것이고,
간단한 프로세스디스크립션으로 생산, 해당 형태로 배포, 제공, 공유되겠죠.
- 아키텍쳐에서 레이어는 필요없다는 얘기를 하고 계신 건가요? 아님 SOA에서는 레이어가
없다는 얘기를 하시는건가요? ( 일반적인 SOA의 정의에 의하면 각 서비스들에도 크기의 차이가
존재하고 그에 따른 레이어도 존재합니다. 누가 맞고 틀리고의 얘기가 아니고 일반적으로 그렇다는
겁니다.)
: 개념에 의해서 종적관계를 갖겠지만 그렇다고해서 soa에 layer가 존재해야 한다..
soa는 layered architecture로 구성되어야 한다는 것에는 무리가 있다는 것을 말씀드리겁니다.
하나의 서비스가 관점에 의해서 똑같이 상위와 하위에 배치될 수 있다고 가정한다면,
해당 서비스를 layer로 분류한다거나 기반위에 배치하는것은 적정할 수가 없겠죠.
layered architecture는 구성하는 사람의 선택일 따름이라 말씀드리고 싶습니다.
많은 댓글들이 soa는 layerd architecture란 개념을 기반으로 한 글들이 많더군요.
business component factory개념에 너무나 오랫동안 친숙해졌기 때문이 아닐까 생각해봅니다.
- 그리고 말씀 하신바와는 달리 IBM을 비롯한 각종 대형 밴더들은 이미 SOA를 향해 달려나가고
있습니다. 실은 남보다 빨리 달려나가기 위해 경주를 하고 있는 상황이라고 보는게 더 맞겠죠.
: 밴더는SOA를 이용해서 제품을 판매하기 위한
'SOA가 아닌 방향'으로 갈래를 잡아가고 경쟁하고 있다고 생각합니다.
- '리딩하고 진행할 수 있는 리더'란 구체적으로 누구를 말하는지요?
: SOA에 전문지식을 갖고 있는 선임아키텍트를 말합니다.
- '우리가 고민하는 기술적인 문제들은 단지 서비스일 뿐 그 이상도이하도 아니다'라는 말의
의미도 잘 이해가 안됩니다. (제 머리가 나빠서..)
: 기술적인 부분들은 우리가 사용가능한 서비스들로 봐야합니다.
아키텍쳐의 기반환경으로 미들웨어나 툴에서 제공하면 안됩니다.
성능문제 트랜잭션문제 이런것은 우리가 사용하고 적용할 서비스로 봐야합니다.
왜..인지는 곰곰히 생각해 보셨으면 합니다..
언급하려면 장문의 글이 되어야 할 것 같네요.
추가로, bam, 눈에보이는 프로세스..
동적인 룰과 의사결정에 의한 프로세스핸들링..
프로세스의 재배치나 통합 이런게 언급이 되고 있는데요.
그런 것을 언급하려면 WFMS, xpdl에 대해 얘되는게 맞는것 같네요.
어쨌든 다름아닌 아키텍쳐에 대한 고찰이
가장 많이.. 중요하고 심도있게 언급되어야 할 듯 싶은데
BP나 integration 얘기가 많아 아쉽습니다.
|
제목 : Re: Re: 벤더 구분
글쓴이: archidream(guest) 2006/05/11 08:22:06 조회수:790 줄수:26 |
|
Business 측면의 벤더 : HP, ORACLE(?), SAP등...(platform을 제공할수 없는 벤더)
Techinical 측면의 벤더 : IBM, BEA 등...(platform을 제공할 수 있는 벤더)
음.. 적으면서도 그리 명확치 않은 구분이었습니다.. ^^;;
사실 어디 정리해 놓은 것을 봤는데.. 확실하게 기억은 안나더군여...
HP는 맞죠? ㅋㅋ
그리고 제가 굳이 Business / Techinical을 언급한것은 제품 중심적인 구분이었습니다.
물론 ORACLE/ IBM 이 컨설팅도 하고 있는 것은 익히 알고 있습니다.
제가 IBM, BEA를 Techinical 측면에 놓은 것은 (개인적인 견해지만) 보다 SOA 구성의 제품을
구체적으로 구성했다는거죠... 다른 벤더들보다는.. ORACLE이나 SAP 보다..
기술과 비즈니스.. 바라보는 관점이 틀리다는 것을 설명하기 위함이었는데...
그닥 설득력이 없었죠? 더 자세한 자료를 찾거나 하면 다시 올리겠습니다..^^
=============================================
행복하지않으면 성공하지 않은 것이다.
=============================================
|
제목 : Re: WS-* ?
글쓴이: calmglow(guest) 2006/05/11 10:00:19 조회수:723 줄수:7 |
|
제목 : Re: WS-*
글쓴이: 일본사는넘(guest) 2006/05/11 12:26:59 조회수:715 줄수:8 |
|
언제나 궁금한게 있었는데.... WS-*를 다 이해하고 말하는 사람이 과연 있을까요?
대충 이런거.. 라고는 알고 있어도 그것들을 실제로 적용해본 경우가 얼마나 될까요?
Layed architecture에 대해서는... 서비스들이라도 그 사이즈는 제 각각이므로 레이어는
존재하고 사용자들층에 따라 사용되는 서비스들과 그 추상도도 제 각각이므로 레이어가
좋아서 만드는게 아니라 필연적으로 레이어가 만들어진다고 생각하는데요..
|
제목 : Re: layered architecture 기반이 아닌이유..
글쓴이: u2(Rainman1) 2006/05/11 16:46:49 조회수:673 줄수:22 |
|
다시 또 언급드리는데요..
soa에서 같은 서비스라도
클라이언트의 관심사가 다르다..는 것을 말씀드린 바 있습니다.
'같은 비즈니스 서비스나 기능이라도 다른 레이어에 공존할 수 있다'는 것을 용인해야 한다는 얘기죠.
layer로 구성할 때는 서비스가 비즈니스 내에서 종적으로 고정될 수 있을 때를 말합니다.
우리가 지금 늘상하고 있는 것이 개념을 고정하고 분류하는 작업입니다.
한개의 서비스가 종으로 상/하위에 동시에 존재하고,
같은 곳에 서비스라도 클라이언트에 따라 여러개의 뷰가 존재하고 다른제어가 가능해야된다면,,
일정 레이어에 위치시킨 서비스라면 이런 것은 너무도 어려운 요구사항입니다.
레이어를 잘게 비즈니스뿐만이 아니라 기능선에서도 쪼개서 잘디 잘은 layer가 구성되지 않으면 말이죠.
하지만 그렇게 잘게 분류하기 위해서 layer를 두는 것이 아니기 때문에 이런 요구사항은 일반적으로 무시되는
것입니다.
무시하지 않았을 경우
인접 서비스에 영향을 미치게 되고
collaboration관계에 놓인 다른 비즈니스로 급속히 확산되서 아키텍쳐는 서서히 무너지게 되는 것은 자명하구요.
어쨌든 이러한 요구사항을 용인하자는 것이 soa이고,
따라서 전제가 layer 위의 컴포넌트나 서비스가 아닌 독립적 서비스를 전제로 두는 것입니다.
물론 일부는 레이어를 기반으로 구성될 수도 있겠지만 그것이 soa의 전체가 되어서는 안된다는 얘기입니다.
|
제목 : Re: soa에 왜 관심을 갖고 토론을 하고 있는지요..
글쓴이: u2(Rainman1) 2006/05/11 16:53:54 조회수:648 줄수:17 |
|
댓글을 다는 분들께 여쭤보고 싶습니다.
탄탄한 layer위에 개념적으로 고정된 아키텍쳐와 서비스를 바라면
cbd로 business component factory에 입각해서
업무전문가와 BP,BA,TA,설계자가 업무마다 배치되서 비즈니스 잘 구성하시면 됩니다.
(실제로 어느규모 정도의 프로젝트팀이라면 그렇게 하고있잖습니까..
비즈니스의 가시성과 통합,변경,시점 등을 만족하고자 하면 WFMS를 선택하면 됩니다.
layered architecture를 가져가고 기술적 기반과
soa를 위한 미들웨어와 복잡한 기반서비스들 위에
그 위에 컴포넌트.. 그것으로 서비스를 올리는 거면 왜 SOA를 왜 선택하려 합니까..
굳이 integration이나 룰에 의해 재구성되는 프로세스라던가..
이들을 만족하기 위한 것이라면 대안이 있고 이미 잘 적용하고 있지않습니까..
왜 SOA에 대해 토론하려고 하고 왜 관심을 기울이려는지..가 매우 궁금합니다.
SOA에 느끼는 비젼이 어떻게나..어떠한 방식.. 그런것의 우선이 아닐까요?
왜 관심과 소신을 갖는지 의견을 듣고 싶네요.. 전 이미 썼습니다..
|
제목 : Re: EAI 기반에서 ESB로 발전시키고자 할때..
글쓴이: 쏘아(guest) 2006/05/11 17:55:00 조회수:688 줄수:40 |
|
EAI, ESB를 열심히 고민하던중, 해당 페이지를 발견하여 오랜시간동안 열심히 읽었습니다.
많은 고객들이 궁금해하는 EAI와 ESB의 차이점 내지는 상관관계에서 EAI가 ESB의 하위
layer에 있다는 것은 어느정도 동감합니다.
개인적으로, 통합의 노력을 하지 않은 고객(EAI 구축되지 않은 고객)에게는 ESB가 EAI의
대체 개념이 될 수 있고 - 표준 기반으로 첨부터 구축하는게 수월하게 되니까요..
이미 EAI를 구축한 고객은 그들의 환경을 십분 활용해야 하기 때문에 당연히 ESB가 EAI의
대체 개념이 아니라 하위 layer가 되지 않을까 싶습니다. 걍.. 개인적 생각입니다.
그런데 어떤 경우든 제가 느끼는 가장 큰 딜레마는... "서비스 화"입니다.
도저히 EAI에 대한 ESB의 강점이 표준지원만으로는 고객을 설득시키는 것은 불가능하고
이때 나오는 말이 ESB는 EAI와 달리 loosly coupled된 "서비스"를 연결하는 것이고 어떤
것을 "서비스화"해야 하냐는 질문이 당연히 돌아오면.. "재사용" 가능한 것들로서 프로세스
와 연계 가능한 것들이지요.. 라고 답하고 싶지만..
그렇게 되면 고객들은 우리 EAI에 연결된 레거시 중에 어떤것들이 재사용 가능한지를
평가하려면 결국 프로세스부터 분석하는 BPM부터 시작해야겠군요.. 라는 답이 나옵니다.
다시말해.. EAI가 구축되어 있는 고객에게 "현재 EAI 인프라를 유지하면서요.. EAI에 연계되어
있는 것들 중 재사용 요건이 있는 것들을 서비스화하여 표준기반의 ESB를 구축하고
그것을 EAI와 잘 연계하여 통합 ESB를 구축하면 현재 인프라를 유지하면서 점차적인 ESB
를 구축할 수 있습니다"... 라고 말하고 싶은데.. 그리고
그렇게 구축하고 싶은데...
정말 기구축되어 있는 EAI중에 어떤것을 이렇게 ESB 쪽으로 가지고 와서, 웹 서비스화든
SCA Binding이든 하려고 하면 다시 비즈니스 쪽이 연계될 수 밖에 없고.. 그러다보면
결국 프로세스 분석단으로부터 내려오는 top-down이 아닌 bottom-up 방식의 ESB value
를 고객에게 어떻게 설명해야 할지 막막합니다.
여러분들의 고견을 듣고 싶습니다.
1. ESB 구축시 서비스를 비즈니스 프로세스 단부터 분석하지 않고 기구축 레거시로부터
만드려면 어떠한 방법이 있을까요?
2. 위의 방법, 즉 비즈니스 프로세스단의 분석으로부터 시작하지 않을 경우 ESB단의 재
사용 서비스가 불가능 한것이라면, EAI가 구축되어 있는 고객에게 ESB 구축을 어떻게
설득해야 할까요?
물론 SOA가 최종 효과를 보려면 비즈니스 단까지 반드시 엮여야 합니다. 하지만 SOA는
빅뱅 어프로치가 불가능하고 그러면 어떻게든 시작을 하고 보아햐 하는데.. 인프라단부
터의 시작은 정말 불가능한걸까요?
긴 글 읽어주셔서 감사합니다.
|
제목 : Re: SOA의 BOTTOM UP접근 방식
글쓴이: 조대협(guest) 2006/05/11 18:57:30 조회수:680 줄수:120 |
|
먼저 쏘아님의 질문에 대해서 의견을 말씀드리겠습니다.
SOA의 시스템 분석 방법은 TOP-DOWN방식과 BOTTOM-UP방식
둘다 있습니다. 내용들이 생각을 많이 하게 하는군요.
쏘아님께서 현재 의문시 하시는것은 BOTTOM-UP방식이 되겠구요.
기존 시스템을 서비스화 하는데 부터 시작합니다.
(이게 오히려 현실적일 수 있겠지요. 아무것도 없는 시스템에서
시작하는것이 아니라면요.)
BOTTOM UP 방식이 적절한 경우는 맨 먼저 시스템간의 통합
즉 Integration이 목적일때 적합합니다.
기존의 Legacy를 SOAP 표준 기반으로 Integration으로 묶는데에
목적을 가지고 있는데요.
말씀하신데로 이 Integration만 한다면 기존 EAI와 차이가 없습니다.
Bottom up 방식으로 기존의 Legacy들을 Service화 하여, Integration하는 방식을
P2P 방식 즉 저는 Level 1. P2P based Fundamental SOA라고 정의합니다.
이렇게 각 서비스들을 정의를 해놓고, 서비스간의 연결을 하게 되는데요.
이렇게 P2P로 서비스를 연결해놓게 되면 문제가 생깁니다.
몇가지 예를 들어보도록 하지요.
하나의 업무가 Service A--> B-->C-->D 의 호출 구조를 가진다고 가정합시다.
각 서비스 A,B,C,D는 각각 다른Legacy 시스템입니다.
*주1-기본적으로 SOA는 Loosely Coupled, Statless Service를 지향하기 때문에,
이 4개의 Service를 하나의 트렌젝션으로 묶을 수 없습니다.
(EAI의 경우에는 가능하겠지요.)
즉 A-->B-->C 서비스 까지 실행이 되다가 시스템이 오류가 났을때 rollback이
불가능하기 때문에, C까지 서비스가 진행되었다는 Logging이 필요합니다.
각각 서비스 마다 통합된 Logging기능을 구현을 해야겠지요.
*주2
또 다른 문제는
A,B,C,D 서비스의 Performance가 각각 100TPS,10TPS,100TPS,50TPS라고 했을때
이 업무들의 기준 성능은 어디에 기준이 되어야 할까요? 당연히 10TPS 쪽이 기준이
되어야 합니다. (다른 대안이 없고 sync 방식으로 pipeline 형식으로 연결이 되어
있는 경우.)
그러면 이 업무를 시작할때, 10TPS에 해당하는 request만 받도록 통제하는 부분이
필요합니다.
*주3
또 다른 문제를 또 들어보도록 하지요.
A,B,C,D 업무중에서 B 업무의 Conneciton URL이 변경되었습니다.
이경우에는 A 서비스에서만 Connection URL을 변경하면 되지만.
만약에 B업무를 A1,A2.... A100 서비스들도 참고하고 있다고 가정하면
이 100개의 서비스들의 URL을 모두 바꿔서 새로 deploy해야 합니다.
*주4
또 하나 예를 들어보도록 하지요.
A,B,C,D 업무가 예전에는 순차적으로 실행이 되었지만.
회사 정책이 바뀌어서 VIP고객에 대해서는 A->B->C->D 연결이 아니라
A->B2->E 업무 흐름을 타게 되었다고 가정합시다.
그렇다면 A 서비스 자체를 고쳐야 합니다.
주 1~4까지 설명한 내용은 물론 서비스 자체를 고쳐서 다 수정할 수 있습니다.
그러나 이런 관리의 복잡성이 증대 함에 따라서 서비스간 연결을 통합할
필요성을 가지게 되었고, 그에 의해서 등장한 아키텍쳐가
Level 2. Network SOA (제 나름데로의 정의입니다만, 많은 서적이나 컨설팅에서도
비슷한 개념을 사용하는것으로 알고 있습니다.)
입니다. 중간에 Controller를 두자는 의미인데.. 이것이 바로 Enterprise Service
BUS입니다.
필요성에 대해서는 주 1~4까지 대략 일부 기능에 대해서 설명이 되었습니다.
Logging,Routing,Transfomation,Endpoint의 위치 투명성등을 보장해주고 Monitoring등의
많은 기능을 구현하게 됩니다.
Bottom up 방식에서는 글쎄요.. 제 생각에서는 이 Level 2.Networked SOA까지 오는것이
맞는것은 큰문제가 없는 것 같습니다.
그러나 이 다음단계인 BPM을 붙이는것은 기존 시스템에서 구성된 서비스를 중심으로 해서
사람의 업무 프로세스 자체를 바꿀 수 는 없는 노릇이지 않습니까?
기업의 IT Governance와도 관련된 문제이기 때문에. 결국 BPM에서는 다시 TOP DOWN 방식으로
구현이 접근을 하게 됩니다.
BPM은 이미 ESB를 통해서 이미 서비스화되어 있는 업무들을 묶어서 업무 프로세스를 구현하고
업무 혁신을 하는데 목적을 둡니다.
이 단계를 Level3. Process Based SOA라고 나름데로 정의합니다. (4단계는 위에서도 간략하게
설명했으니까는 생략하도록 하지요.)
이 SOA단계에서 EAI의 역할은 Transaction이 필요한 Tightly coupled된 Legacy간의 통합된
서비스 구현이나 또는... Legacy간의 workflow가 필요할 경우 shor term workflow에 대한 구현
(위에서 설명한 Application Oriented Process라 정의하였습니다.)의 역할이 될겁니다.
결국 Level 1. P2P 모델의 SOA는 System integration을 목적으로 하고 있고.
이는 EAI 시스템이 있다면 이미 중복되는 것이기때문에 기존 EAI 사용 고객에게 접근하기가
매우 어려운것이 사실입니다.
기존 EAI 고객의 경우 P2P 모델의 SOA 구현은 서비스 재사용을 통한 좀더 쉽고 생산성 높은
Integration이라는 장점과 (실제로 EAI보다는 일단 서비스만 구축되면 SOA기반의 Integration이
쉽고 생산성이 높다고 봅니다. EAI는 Adapter에 대한 Dependecy가 매우 높습니다.)
SOA로 전환하기 위한 준비 단계라는 장점밖에 가지지 못합니다.
Level 2의 ESB기반의 SOA도, 실제로 ESB가 없어도 문제는 없습니다.SOA 구축하는데.
그러나 위에 일부 설명드린데로 P2P방식의SOA는 서비스간에 Tightly coupled되서 Agility가 떨어지고
그외에도 SOA를 위해서 구성해야할 Infra가 많이 떨어지게됩니다. 그래서 ESB의 필요성이 대두 되는것이
구요..
결론을 지어 보자면
BOTTOM-UP으로만은 SOA를 구축하기에는 개인적으로 무리수가 많이 따른다고 봅니다.
물론 TOP-DOWN 방식만으로 시작하는 것도 그리 바람직하지 않다고 생각이 되네요.
먼저 BOTTOM-UP방식으로 기존 시스템을 서비스화하고, 서비스들을 연결 정리한후
다시 Process기반으로 TOP-DOWN분석을 하는 단계적인 SOA 추진 방법이 필요하다고 봅니다.
아.. 그리고 여담으로.
EAI 시스템이 이미 존재하고, 그 시스템 자체가 훌륭한 WebService에 대한 HUB역할을 할 수 있다면
ESB나 BPM 솔루션을 따로 구매할 필요없이.. EAI로만으로도 SOA를 구축하는데는 무리가 없습니다.
실제로 예전에 SOA개념이 있고 ESB 제품군들이 없었을때는 EAI가 그러한 역할을 수행한것이 사실이고
EAI로 SOA를 구축하는 가이드도 많습니다.
그렇지만 아무래도 현재 SOA 제품들이 더 편하기는 하겠지요? ^^
머릿속에 떠도는 생각은 많은데.. 의견 전달이 제대로 되었는 지 모르겠습니다.
검토해보신후에 잘 이해 안되시는 부분이 있으시면 답글 주세요.
수고하세요.
|
제목 : Re: SOA Layered architecture는 나중에...
글쓴이: 조대협(guest) 2006/05/11 19:01:37 조회수:639 줄수:16 |
|
u2님이 쓰신 Layered 아키텍쳐에 대한 이견에 대해서...
SOA가 꼬옥 Layered일 필요는 없다는것에 대해서는 공감을 합니다만...
Layered 아키텍쳐가 SOA에서 큰 강점을 가진다고 생각하기 때문에 SOA에 맞지 않는다는
의견에는 의문을 표시합니다.
오늘은 시간이 많이 되서.. 퇴근하구요... 다시 진지하게 생각해보고
글 올리도록 하겠습니다.
P.S. 아.. 그리고 SOA에 관심이 있으신분들은
각 벤더의 SOA 제품 전략을 관심깊게 살펴보셨으면 합니다.
SOA에 대한 기본적으로 공통되는 개념이 많으면서도 서로 구축하는 전략에는 차이가
있다는 것을 아시게 될텐데요.
여러 논쟁의 소지들이 또 다른 가능성이나 아키텍쳐로 이해될듯 싶습니다.
많이들 토론에 응해주셔서 감사합니다.
|
제목 : Re: WS*
글쓴이: 조대협(guest) 2006/05/11 19:07:06 조회수:630 줄수:32 |
|
아.. 퇴근하기 전에.
하나만 떠 써놓고 가도록 하지요.
justjava님께서... WS*을 이해하는 사람이 얼마나 있을까 반문을 하셨는데..
이게 문제이긴 문제입니다.
WS*이 무지 많지요. 아직 진행중인것도 대다수이구요..
그런데 문제는..
보통 개발자들이 개발을 할때 WebService에 대한 개발을
실제로 다 JAXP등을 이용해서 밑에단 부터 하지 않고
wscompile 과 같은 Proxy/WSDL 을 자동으로 generation 해주는 tool을 사용하지 않습니까?
문제가 여기에 있습니다.
일반 sync 방식의 서비스의 경우에는 큰문제가 없습니다만.
Reliable Messaging 하나만 예를 들어도
A vendor는 Reliable Messaging을 WS* Reliable Messaging으로 만들고,
어느 vendor는 자체 구현을 했었을 수 있습니다.
또는 시스템의 버전에 따라서 Reliable Messaging WS* standard가 없을때 구현이 되서
그럴 수 도 있지요.. 이런 경우 참 난감해집니다...
우리는 이걸 똑같은 Reliable Messaging으로 보는데..
이 두 시스템이 통합이 되지 않습니다.
그래서 구현할때.. WS* 을 어느정도 까지 지원을 하고 있는지는 알아둬야겠지요.
직접 JAXP나 JAX_RPC로 구현을 하지 않더라도요...
아직 이 WebService 표준화가 제대로 되지 않아서 WS를 통한 통합에 이것이 걸림돌이
되겠다 하는 생각이 좀 듭니다.
벤더마다 지원하는 WS* 스펙도 제각각 다르잖아요..
아마도 이런 다른 스펙을 지원하는 서비스들때문에 중간에 Bridge 형태의 서비스가
필요하게 될것 같은데.. 이런것을 ESB가 Cover해주면 편할거라 생각하는데..
어떻게 될련지는 지켜봐야겠지요.
|
제목 : Re: 서비스란 무언가요?
글쓴이: 일본사는넘(guest) 2006/05/11 21:34:42 조회수:675 줄수:3 |
|
어쩌면 이 질문이 선행되어야 했을지도 모르겠네요.
서비스란 무엇인가요?
|
제목 : Re: 어떤걸 서비스화해야 할까요..
글쓴이: 쏘아(guest) 2006/05/12 10:14:26 조회수:650 줄수:14 |
|
조대협님의 글 잘 읽었습니다...
답변 감사하고, 많은 도움이 되었습니다.
그런데.. 제가 가장 의문시 되는 것은....
현재 다양한 레거시 시스템 기반의 EAI가 구축되어 있는 환경에서 Bottom-Up Approach를
통해 ESB를 구축하고자 할때.. (ESB 구축 후, BPM을 고려하고 있다면... )
과연 어떤 것을 서비스화해야 할까요?
그리고, 그걸 왜 서비스화 해야 한다고 고객을 설득해야 할까요?
그리고, 그 서비스화된 것들이 과연 재사용이 가능할지는.. 아니 반대로 비즈니스로부터의
분석없이 어떻게 재사용가능한 것들을 뽑아서 서비스화해야할까요?
이것이 가장 궁금합니다.
고견 부탁드립니다.
|
제목 : Re: 어떤걸 서비스화해야 할까요..
글쓴이: archidream(guest) 2006/05/12 17:18:49 조회수:665 줄수:15 |
|
쏘아님 글에 대해 짧게 의견 남기겠습니다.
전체적인 내용은 아닙니다.
한문장에 대해서만입니다... (회의하고 힘빠져서.. 기력이 부족해요..ㅠㅠ)
트집같은건 아니니..오해 말아주십시요..(__);;
ESB 구축 후, BPM을 고려하고 있다면...
일반적으로 ESB 구축 후 BPM을 고려하지 않습니다.
BPM으로 Process의 대한 정의를 한후에 프로세스 연계를 위해 ESB 사용합니다.
|
제목 : Re: 그러니깐.. bottom-up approach가..
글쓴이: 쏘아(guest) 2006/05/12 18:16:12 조회수:656 줄수:6 |
|
AMR research에 의하면 SOA에 대한 투자 분야로 BPM이 1위를 ESB가 2위를 rank 했습니다.
저는 IT 쪽 (비즈니스 쪽이 아닌)이라서 SOA의 첫 단계로 ESB를 제안하고 그걸 향후 프
로세스에 연결시켜 나가는 roadmap을 제시하고자 하는데..
그러다보니 bottom-up approach가 되었습니다.
그럼, 이런 approach 자체가 틀린걸까요?
|
제목 : Re: 정말 말이란.
글쓴이: 손님(guest) 2006/05/13 06:50:31 조회수:705 줄수:17 |
|
모두 짱짱하신 분들이겠지만
정말 말이란
그냥 저같은 놈이 보면
그냥 "이빨"로 밖에
보이지 않는것이
그래서, 컨설턴트는
"이빨뿐이다"라는 말이 생긴거 같군요
솔직히 뭔말인지
모르겠는것 보다도
위에 어떤 분이 말씀하셨듯
지나치게 용어의 난발이
느껴지는
결국, 그게 그거인 소리라도
좀 더 어려워보이게
웬지 그런 느낌을 받아서
저만 바보같은 느낌입니다.
|
제목 : Re: 엔지니어에 대한 회의
글쓴이: 손님(guest) 2006/05/13 06:53:15 조회수:787 줄수:1 |
|
엔지니어들은 어렵게 설명하여 상대가 쉽게 이해 못할때 희열을 느끼는것같다.
|
제목 : Re: 아쉬움...
글쓴이: 미노(mino) 2006/05/13 20:18:55 조회수:697 줄수:36 |
|
공부를 더 해야겠다는 생각이 들었습니다.
제가 쓴.. 또는 다른 분들이 쓴 글타래를 읽으면서,
내가 알고 있는 사실을 좀 더 명확하고, 실제적으로 접근 해야겠다고 생각했습니다.
그래서 그동안 이 글타래에 답글을 달지 않았습니다.
그리고 몇몇 글들을 읽으면서, 생기는 회의감도 글을 쓰는것을 망설이게 하는 이유가
됩니다.
분명 쉽지 않은 내용임이 분명합니다.
때문에 많은 분들이 자신의 생각들을 밝히고, 토론을 하는 것이겠지요.
여기에 글을 쓰시는 분들은 제가 아는 분들도 있고, 그렇지 않은 분들도 계시지만,
나름대로 개발이나 강의를 하시면서 해당 분야에서는 능력을 인정받고 계시는 분들이라
생각합니다. (그만큼 많은 고민과 노력을 해오신 분들입니다.)
상대방을 배려하는 마음을 가지셨으면 합니다.
자신이 모르는것이 있으면 알도록 노력하시기 바랍니다.
설명이 이해가 안가시면 그것은 자신이 알고 있는 지식들이 기반이 되지 않기 때문입니다.
그것을 독설로써 해소하려고는 하지 마십시요.
"이빨뿐"이나, "상대가 수비게 이해 못할때의 희열"이나 정직하지 않은 지식들이나,
알지못하는것을 꾸밀때나 적당한 말입니다.
또는 정직한 지식에 대한 자신의 부족함을 그져 쉽게 남에게 떠넘기려 할때나 쓰는
말입니다.
이 글타래가 무엇을 얘기하는것인지를 판단하시기 바랍니다.
그져 본질적인 얘기를 벗어나서 자신의 기분이나 느낌만을 말하는 것은
전혀 도움이 될 수 없습니다.
적어도 개인적인 기분이나 느낌을 말하려면 누군지를 당당히 밝히시기 바랍니다.
손님이란 닉을 자신을 감추는 가면으로 사용하지 않으셨으면 합니다.
생산적인 토론을 통해 많은 지식을 얻으려는 정직한 손님들속에 숨지 마시길...
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
http://minho.egloos.com
-------------------------------------------------------
|
제목 : Re: 서비스란..
글쓴이: u2(Rainman1) 2006/05/14 05:46:50 조회수:682 줄수:8 |
|
soa에서 서비스란
'클라이언트의 요구에 응해주는 것'에 대한 통칭입니다.
요구와 응답에 대한형식은 SOAP으로 하자는 것이고..
이를 구현하는 기술적 기반과 하부 프로토콜과는 무관합니다. 이것이 서비스입니다.
|
제목 : Re: 서비스 버스에 대한 부정.
글쓴이: u2(Rainman1) 2006/05/14 06:36:06 조회수:697 줄수:23 |
|
연결과 통합을 위한 중계가 서비스버스란것 위에서 이뤄져야 한다..
정확히는 서비스가 다른 서비스를 호출하는데에 있어서
필요한 기반기능, 부가적기능..들 때문에 서비스버스란것으로
서비스단 이하의 컨테이너에서 해결하자것으로 이미 SOA의 핵심은 날아갑니다.
정확하게 하자면 그 위에 얹어진 것은 서비스가 아니라 컴포넌트겠죠.
엔터프라이즈 컨테이너위의 비즈니스 컴포넌트.. 그럼 SOA를 선택할 이유가 없습니다.
컴포넌트에서 서비스로 가려는 이유가 무엇인데 서비스버스를 가져가려 하나요?
컨테이너위의 컴포넌트와
요청을 인터셉트하는 서비스버스위가 아닙니다.
다름아닌 service-oriented service입니다. service-oriented...
'service-oriented'란 말에 대해서 많은 고민을 해주셨으면 합니다..
|
제목 : Re: u2님의 의견에 대한 의견
글쓴이: 일본사는넘(guest) 2006/05/14 12:03:41 조회수:707 줄수:92 |
|
u2님의 글은 언제나 제게 많은 물음표를 남기는군요.
제가 생각하는 서비스는,
"표준적인 인터페이스로 공개된 서비스 이용자에게 있어서 의미를 가지는 기능의 단위로
그 인터페이스와 구현기술간의 의존성을 제거한 것"
입니다.
조금 추가하면 여기서 '표준적인' 이란 부분의 '표준'의 정의를 조직이나 업계별로 보다
구체적으로 해야 할 필요가 있다는 얘기는 이전의 제 글에서 이미 밝힌 바 있습니다.
님이 말씀하시듯 'SOAP을 요구와 응답의 형식으로'란 부분이 현실적으로는 적어도 향후
10년간은 어려울 것이란 얘기도 한 바 있습니다.
더불어 u2님의 정의에서는 등장하지 않지만 제 정의-보다 일반적인 정의라고 생각합니다만-
에 등장하는 '인터페이스와 구현기술간의 의존성의 제거'라는 부분이 실제로 서비스와
컴포넌트를 구별하는 가장 큰 특징중의 하나가 아닌가 합니다. 말 그대로 기존의 컴포넌트가
그 구현기술 또는 미들웨어의 기반에 종속되어 있어서 상호호환성이 낮았던 것에 비해 -그래서
EAI등의 기술이 사용되었죠- 표준적인 -즉, 보다 범용적이고 호환성이 뛰어난- 인터페이스로
공개되어 서로 사용되는 서비스의 경우 그 구현언어나 기반플랫폼과는 상관없이 자유로이
연계/사용/교체가 가능하다는 점입니다.
또 하나의 차이는 위의 정의에 등장하는 '이용자에 있어서 의미를 가지는 기능의 단위'라는
것인데 위의 이용자는 시스템관리자, 시스템 통합 담당자, 어플리케이션 개발자만이 아니고
비지니스맨도 포함합니다. 즉, 기존의 컴포넌트가 비지니스 담당자에게는 의미 모를 블랙박스였다면
비지니스맨이 이해하고 마음대로 조합이 가능한 화이트박스로써 서비스를 이용가능하게 되는
것입니다. 이 서비스들을 비지니스 프로세스의 각 노드로 이용이 가능하므로 비지니스가 요구하는
변화요구에의 신속한 대응이 가능하게 된다는 것이죠. (이론상)
(더불어 이를 위해서는 기존의 컴포넌트들이나 펑션을 신속하게 서비스화할 수 있는 기술이
필요하게 되겠죠. 그래서 제가 이전에 만든 아키텍쳐에서는 Service Enabler layer가 있었습니다)
서비스의 이용자층이 다르기에 그들이 사용하는 서비스의 크기는 각각 틀려지고 그래서 서비스간에는
레이어가 존재하게 됩니다. SOA에 레이어가 필수라는가 아니고 자연히 레이어의 개념이 만들어지게
된다는 얘기입니다.
(무엇이든 많은 대상을 관리하기 위해서는 구분이 필요하고 그건 카테고리등의 횡적인 구분과
레이어란 종적인 구분이 일반적으로 사용됩니다. 더불어 레이어드 아키텍쳐는 수많은 경험을
통해 얻어진 결과물입니다. 그것이 SOA라고 하여 갑자기 부정될 필요는 없다고 생각합니다. 특히나
수천, 수만개의 서비스가 움직이는 엔테프라이즈 레벨의 시스템에서 이러한 구분을 적용하지
않는다면 애초에 개발도, 관리도, 재이용도 불가능할 것입니다.)
더불어, 위의 정의에 의하면 서비스는 인터페이스와 구현기술을 분리함으로써 상호호환성의 대폭적인
향상을 꾀할 수 있었습니다. 하지만 아직 해결하지 못한 문제가 하나 있었으니 바로 '서비스의
위치투명성'과 '인터페이스의 변경'이죠.(위치투명성이 한국어적으로 바른 표현인지는 잘 모르겠습니다만)
실제로는 서비스의 위치가 바뀌거나 그 인터페이스가 바뀌었을 경우에 그 영향범위의
특정자체가 곤란하고 대응작업이 상당히 광범위하게 파급될 가능성이 높습니다. 이걸 해결하기
위해 등장한 것이 바로 ESB라고 생각합니다. 각각의 서비스는 ESB에 자신을 등록하면 ESB는
이를 타 서비스에 공개합니다. 서비스 이용자는 단지 ESB에서 공개하고 있는 서비스를 인식하고
이용할 뿐입니다. 그리고 서비스 공급자측에서 어떤 변경이 있었을 경우엔 -적어도 인터페이스의
하위호환성이 있는 한 - 그 변경 자체는 ESB내에서 흡수되고 서비스 이용자측에는 아무런
영향이 없지요. 이러한 충격완충능력을 극대화하기 위해 ESB는 흡사 BPM으로 오해를 받을수도
있는 여러가지 변환, 루팅, 프로세스 제어 기능을 구비합니다.
더불어 현재의 ESB는 아직 서비스화하지 못한 컴포넌트의 인터페이스를 변환하여 일반적인 서비스화하여
보여줄수 있는 몇몇 변환기능도 보유합니다. 즉 기존의 시스템에서 SOA에 근거한 시스템으로
이행해 가는 동안의 과도기에 기존 시스템과 새로운 시스템간의 연결자 역활을 할 수 있는
것입니다.
고로, 'SOA에 ESB는 필수'라는 정의는 과도한 것이나 '상당히 유익한 존재'임에는 틀림이
없다고 생각합니다.
u2님이 생각하는 서비스와 컴포넌트의 차가 무엇이지는 아직 잘 모르겠지만 제가 생각하기엔
SOA에서 컴포넌트란 배제되어야 할 기술이 아니라, 서비스의 구현기술로써 아주 유용한
기술이라고 생각합니다. 이를 역으로 표현하면 컴포넌트를 그대로 서비스화 하는 것도 아주
유용한 접근방법이라는 것입니다. 그래서 SOA에서는 그 장점의 하나로 '기존 시스템자산의
재활용성이 뛰어나다'고 하고 있습니다. 기존의 시스템 자산을 부정하고 있는 것이 아니라고
생각합니다. (그래서 위의 글타래에서는 SOA에의 현실적인 어프로치로써ESB의 하위단에 EAI가
존재할 수도 있다고 하고 있습니다)
u2님이 강조하시는 'service-oriented'라는 의미를 모르는 바는 아닙니다. 하지만 u2님이
얘기하듯 개발자가 아닌 아무나 서비스 스크립트를 작성해서 각자의 서비스를 만들어 쓰기
위해서는 또다른 서비스가 필요하고 그러한 서비스는 아마도 새로이 작성하려는 서비스보다는
사이즈가 작을 것입니다. 그리고 그 작은 서비스들은 보다 더 작은 서비스들로 구성되어
있을 확율이 높구요. (여기서 레이어의 개념이 나옵니다.)
그리고 서비스가 인터페이스와 그 구현으로 구성되는 기능의 단위라는 것을 생각할 때 그
구현을 어찌할 것인가의 문제는 여전히 존재합니다. 이 부분에서 기존의 컴포넌트와 미들웨어
가 등장할 것이구요. 결국 서비스란 추상화의 결과물인지라 어느 곳엔가에는 구상체가 움직이고
있을 필요가 있습니다.(다 아는 얘기를 하지 말라구요? ^^)
결국 제가 하고자 하는 말은 'service-oriented'라고 하여 서비스만 생각해서 될게 아니란
얘기입니다.
'... oriented'란 '... oriented'일 뿐, '... only'가 아니라는 얘기죠.
이상, 제 글에서 문제나 이견이 있다면 반론이나 지적을 바랍니다.
|
제목 : Re: bottom-up approach에 대해
글쓴이: 일본사는넘(guest) 2006/05/14 12:59:15 조회수:672 줄수:98 |
|
쏘아님의 bottom-up approach에 대한 개인적인 의견을 제시하고자 합니다.
(개인적인 의견이므로 객관성이 결여될 수 있고, 정답이라는 확신이 없으며.. 등등 이하
생략합니다. ^^)
먼저 일본의 얘기라 죄송하지만, 제 고객중에서 Bottom up 방식을 채용하여 프로젝트를
이미 진행 중인 곳이 있습니다. 최초엔 저희도 어찌 고객을 설득해야 할까 고민을 했습니다만
SOA의 컨셉에 대해 몇차례 회의를 하고 현실적인 문제도 솔직히 얘기를 하자 의외로 고개측에서
보다 긍정적인 반응을 보였습니다. 한마디로 요약하면 '그게 최고의 답인지는 모르지만
현재로써는 최선의 답이다'와 '결국 해 보지 않으면 모르는거 아니냐? 하지만 지금이라도
시작하지 않으면 결국 아무것도 바뀌지 않는다'가 고객의 이해였습니다. 그리고 그 시작으로
bottom-up approach를 택했고 우선은 시스템간 연계 부분에 대해 ESB를 도입하고 서비스화를
시작하고 있습니다. 7월말이면 사례발표를 할 수 있는 정도가 될 것 같습니다.
이하, 쏘아님의 질문에 대해 제 나름의 답을 해 보겠습니다.
1. ESB 구축시 서비스를 비즈니스 프로세스 단부터 분석하지 않고 기구축 레거시로부터
만드려면 어떠한 방법이 있을까요?
현재 일반적인(!) SOA의 아키텍쳐에서는 서비스에도 레이어가 있고 보다 하위 레이어로
갈수록 비지니스적인 의미보다는 시스템적인, 또는 어플리케이션 레벨에서의 의미를 갖는
서비스가 됩니다. 즉, 서비스 오케스트레이션이 이루어지는 레이어를 보다 세부적으로 들여다
보면 서비스 오케스트레이션 레이어도 비지니스적인 의미를 갖는 서비스들을 오케스트레이션하는
층과 단순히 시스템적인 요구를 만족하기 위한 서비스들을 오케스트레이션하는 층으로
구분이 가능합니다.
즉 SOA에서 얘기하는 서비스가 반드시 비지니스적인 의미를 가질 필요는 없으며 보다 하위단
으로 갈 수록 BPM은 의식할 필요가 없어집니다.오히려 시스템적인 요구사항을 의식할 필요가
있다고 생각합니다.
쏘아님이 현재 검토하고 있는 레가시들은 어떻게든 다른 시스템과 연계하기 위한 인터페이스를
공개하고 있을 것이고 이는 비지니스적인 의미보다는 시스템적인 의미를 갖는 단위일 가능성이
높다고 생각합니다. 그렇다면 위의 예에서 든 '시스템적인 요구를 만족하기 위한 서비스'로
전환이 가능한 컴포넌트 대상으로 규정하는게 가능하지 않을까요? 이러한 부분은 어차피
기존의 비지니스/어플리케이션 분석/설계의 결과로 도출된 부분이므로 SOA라 해도 그다지
바뀌지는 않을 것이라고 생각합니다,
그러므로 일단 시스템간 연계나 통합의 부분의 인터페이스를 표준적인 인터페이스로 바꾸어
ESB로 이행해 가는 작업부터 시작하면 어떨까 합니다. 이 경우 우선순위는 현행 타 프로젝트에서
그러한 기능을 필요로 하는 우선순위로 하면 되겠지요. (어차피 비지니스레벨의 분석이 아직
이루어지지 않았으니 고려할 수도 없고, 분석후 우선순위를 바꾸는 것은 가능하겠지요.)
코스트란 면에서 생각했을때도, 기존의 프로젝트에서 어차피 시스템간 연계를 위해 할당된
예산이 있을 것이므로 그 부분을 활용할 수 있겠지요.
한가지 유의할 점은 단순히 인터페이스-프로토콜과 멧세지 포멧-을 표준화 할 것이 아니라
연계방식의 리얼타임화를 고려해야 한다는 점입니다. 어차피 SOA를 통해 얻으려는 것이 현실을
보다 신속히 파악할 수 있고 변환이 유연한 시스템이란 점을 생각할 때 기존의 정기적인 뱃치실행
형식의 시스템간 연계를 ESB의 기능등을 이용해 보다 리얼타임화 된 인터페이스로 변경해
갈 필요가 있다는 거지요.
결국, 고객에게 얘기할 수 있는 것은, 또는 요구해야 할 것은,
- 큰 그림을 확정하고 그에 대한 이해를 공유한다.-이게 필수이자, 거의 전부죠-
- 단계적인 어프로치를 결정하고 실행해 간다.
- 그 효과가 실제로 나타나는 시점과 이유를 명확히 한다.
가 되겠죠. -무지하게 교과서적인 답이군요. -
2. 위의 방법, 즉 비즈니스 프로세스단의 분석으로부터 시작하지 않을 경우 ESB단의 재
사용 서비스가 불가능 한것이라면, EAI가 구축되어 있는 고객에게 ESB 구축을 어떻게
설득해야 할까요?
위에서 언급한 바와 같이 서비스에는 비지니스적인 것만이 있는 것이 아니므로 얼마든지
재사용가능한 서비스를 만들어 갈 수 있습니다. 이러한 서비스는 차후에 비지니스분석 후
비지니스적인 의미를 갖는 서비스를 만들 때에 그 하위 서비스로서 재활용이 가능하겠지요.
이전에 어디선가 읽은 IBM의 문서에 의하면 Top-down, Botton-up approach 이외에, 이
두가지를 동시에 실행하는 방식이 있었습니다. 이름이 잘 기억이 안나므로 Hybrid approach
라고 해 두죠. 즉 윗단에서 비지니스를 분석해 내려오고, 아랫단에서부터 기존의 시스템을
분석해서 중간지점에서 그 두가지를 어떻게 매칭할 것인지를 결정하는 것이죠. 이게 가장
이상적이라고 생각합니다만 현실적으로는 Big-bang형식이 될것이므로 가장 실현가능성이
낮겠지요.
그렇담 단계적으로 실행하는 수밖에 없는데 초기비용이 많이 들고 그 효과가 늦게, 그리고
비가시적으로 나타나는 SOA의 특성상 무엇보다도 고객의 이해와 강력한 드라이브가 필수라고
하겠지요.
따라서 위의 질문은 오히려 'SOA와 그 장점을 어떻게 고객에게 이해시킬 것인가?'라는 질문으로
대체하는 것이 더 효과적이라고 생각합니다. ESB라는 제품에 집중해서 생각하면 서로간에
답은 나오지 않습니다. 오히려 SOA에 대한 얘기를 강화하여 '그렇다면 ESB도 필요하지 않나요?'
라는 고객의 질문을 유도해 내는게 더 효과적이지 않을까요?
위에 다른 분도 언급했듯이 SOA와 기존의 방법론과의 가장 큰 차이는 시스템의 ROI란 관점에서
그 효과를 산정할 것인지 아닌지가 아닐까 합니다. 이 얘긴 역으로 SOA를 판매하려는 기업은
기존의 방식대로 고객사의 정보시스템관련자만을 상대해서는 어렵다는 얘기이기도 합니다.
발상의 전환이 필요한 시기, 바야흐로 IT에 진정한 비지니스의 바람이 불기 시작한 것이
아닐까? 하는 생각도 해 봅니다만.
더 이상 IT를 IT만으로 평가하던 시대는 지나간게 아닌가 하는 조금은 무리스런 억측입니다.
이상, 여전히 개인적인 생각이므로 지적, 정정 부탁드립니다.
|
제목 : Re: 일본사는분님께..
글쓴이: 쏘아(guest) 2006/05/15 16:28:08 조회수:1444 줄수:15 |
|
좋은 글 감사드립니다.
제가 궁금해 하는것들이 조금씩 해결되가고 있는듯합니다.
그런데, "단순히 시스템적인 요구를 만족하기 위한 서비스들"은 어떤것이 있을까요?
이경우 비즈니스에 디펜던시가 없으므로 어떤기업이든 비슷할 것 같은데요..
구축하신 ESB를 사례로 아이디어를 주시면 많은 도움 되겠습니다.
그리고 계속 물어봐서 죄송한데... 아직 정리가 안되서요..
기 EAI 구축 고객에 ESB를 drive할 때, 저런 "단순히 시스템적인 요구를 만족하기
위한 서비스"로 drive가 가능한걸까요? 이미 시스템적인 요구 사항은 EAI에서 어느정도
소화하지 않았을까요?
그경우, 고객이 한참듣고, 그럼 그냥 우리 EAI의 제품 버젼을 SOA지원 버젼으로 upgrade
하란 거죠? 라고.. 묻는 고객들이 많아서요..
감사합니다. 꾸벅
|
제목 : Re: 죄송하지만
글쓴이: 일본사는넘(guest) 2006/05/15 23:57:44 조회수:699 줄수:9 |
|
죄송하지만, 제 아이디는 일본사는분이 아니고 일본사는넘입니다.
이전 글에도 쓴 적 있지만, 제가 현재 모 고객사에서 성능테스트와 가용성 테스트를 실시
하고 있는지라 조금 정신이 없습니다. 게다가 내일부터 오오사카 출장이므로 현재 그 준비로
눈코 뜰 새 없습니다. 죄송하지만 이번주 토요일이나 되어야 쏘아님의 질문에 대한 답글을
쓸 수 있을 것 같습니다. 그 전에 더 좋은 의견 있으신 분들은 별도의 답변 부탁드립니다.
그럼 또..
PS; 어차피 교과서적인 답이 될 것이므로 그다지 큰 기대는 마시길..
|
제목 : Re: 아, 참
글쓴이: 일본사는넘(guest) 2006/05/15 23:59:32 조회수:691 줄수:2 |
|
현재 고장중인 무선 인터넷이 내일중으로 -오오사카로 출발하기 전에-고쳐진다면 그 이전
에라도 쓸 수 있습니다.
|
제목 : Re: 우어어어
글쓴이: 일본사는넘(guest) 2006/05/17 01:57:19 조회수:668 줄수:3 |
|
장장 한시간에 걸쳐 쓴 글이 날라갔습니다.
생각하면서 쓴다고 폼을 너무 오래 열어 놓은게 화근?
쏘야님 죄송하지만 오늘은 포기하고 잡니다...
|
제목 : Re: ㅋ 감사합니다. 일본사는넘님
글쓴이: 쏘아(guest) 2006/05/17 11:15:46 조회수:628 줄수:2 |
|
아디 부르기가 좀 거시기 하네요.. 어쨋든.. 주옥같은 글이 날라가서 많이아쉽습니다. ^^
그리고 신경써주셔서 감사합니다.
|
제목 : Re: 웹 서비스와 SOA 차이좀 알려주셈...
글쓴이: 손님(guest) 2006/05/17 23:27:18 조회수:680 줄수:27 |
|
많은 정보를 얻고 있습니다.
XML 웹 서비스와 SOA 차이 좀 알려주세요.
위 글대로라면 SOA는 말 그대로 서비스 지향 구조에 대한 명세서니깐...
웹 서비스는 SOA 개념을 살린 구체적인 실례로 보면 될까요?
참 글구...
서비스와 컴포넌트에 대해 제 생각을 말씀드리면...
컴포넌트 역시 서비스를 한다라고 보고 있슴돠.
컴포넌트 범위를 어디까지 하는냐가 관건인것 같군요.
시스템 개발자에서 보면 개발 목적을 이루기 위한 분리된 단위 기능을
수행하는 모듈을 말할테고
시스템 엔지니어에서 보면 시스템을 구성하고 있는 박스로 묶인 단위 요소로
생각할테고
시스템 설계자에서 보면 유사한 속성을 지닌 그룹 개념으로 생각할 수 있슴돠...
사용자 입장에서 보면 때에 따라서 컴포넌트 역시 서비스 또는
서비스 역시 컴포넌트라고 생각하겠죠.
결국 애매한 이야기가 되는데 SOA 취지만을 살리면 그 안에 컴포넌트가 있던 없던
그게 뭘 하든 안하든 관심 대상이 아니란 이야기를 할 수도 있고
SOA 목적에 비중을 두면 그 안에 컴포넌트 역시 관심 거리가 되는거죠.
아님 말구요.. ㅠㅠ
|
제목 : Re: 궁극의 SoA환경과 ESB
글쓴이: 인생다그래(guest) 2006/05/19 07:30:44 조회수:740 줄수:11 |
|
너무 좋은 말씀들을 구경할 수 있어서 금맥을 찾은 듯한 기분입니다.
그런데 한가지 의문점이 있습니다. 규모 있고, 상거래의 이니셔티브를 쥘 수 있는 기업의
경우야 ESB를 도입할 수 있을 것 같습니다.
사업 파트너(실제로는 납품사가 되려나요?)에게 압력을 넣는다면 같이 진행할 수 있겠죠.
삼성전자처럼 관련소프트웨어를 사 줄 수도 있겠구요.
그런데 웹서비스 혹은 soa가 진정으로 지향하는 business automation환경에서는 ESB라는
개념자체를 적용시키기가 힘든 것 아닌가요?
조대협님께서 친절하게 설명해 주신 ESB도입의 이유에 고개가 절로 끄덕여 졌습니다만...
기업대 기업사이에서,,, 강제시키기 힘든 상황에서 가능한 구조인지 잘 모르겠습니다.
|
제목 : Re: ESB 도입에 대해서..
글쓴이: 조대협(guest) 2006/05/19 10:07:11 조회수:765 줄수:21 |
|
"인생다그래" 님의 ESB에 대한 질문 내용 잘 읽었습니다만..
잘 이해가 안되네요.. ^^;
"웹서비스 혹은 soa가 진정으로 지향하는 business automation환경에서는 ESB라는 개념자체를 적용시키기가 힘든
것 아닌가요?" 가 왜 적용 시키기 힘든지 잘 이해가 안됩니다.
좀더 구체적으로 질문해주시면 잘 설명해드릴 수 있을것 같습니다.
---
오랫동안 회사일로 글을 접었었습니다.
SOA의 ESB에 대해서 많은 생각들이 있으신것 같은데.
SOA에서 ESB는 필수 구성요소는 아닙니다.
SOA는 말 그대로 아키텍쳐일뿐이고, 기업의 업무 구조나 규모에 따라서 적정한 솔루션을 사용하면됩니다.
SOA의 특징중의 하나는 SOA의 도입효과는 단기적으로 나타나는것이 아니라 장기적으로 나타난다는겁니다.
UDDI나 ESB의 경우 초반의 소규모 시스템에 구축해봤자, 처음에는 큰 효과를 기대하기 어렵습니다.
서비스가 많아지고, 연동 되는 내용이 많아질 수 록 서비스 재사용과 서비스의 유연성을 증대시켜주면서,
그 효과를 발휘합니다..
벌써 회의시간이네요.
시간이 날때 더 내용 달아보도록 하겠습니다.
|
제목 : Re: 쏘아님의 질문에 대한 답변
글쓴이: 일본사는넘(guest) 2006/05/23 13:46:29 조회수:728 줄수:74 |
|
쏘아님의 질문에 대한 답이 많이 늦어졌습니다. 오오사카 출장에다 성능테스트에서 예상치
못했던 난관에 봉착했던 관계로 주말마저도 서버와 씨름을 하면서 보냈습니다. 현재, 오오
사카에서 도쿄로 돌아가는 신칸센 안에서 이 글을 씁니다. (과연 무선 인테넷으로 신칸센 안
에서 이 글을 올릴 수 있을 것인가?!)
먼저 이하의 내용은 개인적인 의견이라는 점 먼저 다시한번 강조하며 시작합니다. .
>>그런데, "단순히 시스템적인 요구를 만족하기 위한 서비스들"은 어떤것이 있을까요?
이경우 비즈니스에 디펜던시가 없으므로 어떤기업이든 비슷할 것 같은데요..
구축하신 ESB를 사례로 아이디어를 주시면 많은 도움 되겠습니다.
용어에 대해 약간의 오해가 있는 듯 합니다. 제가 말씀드린 ‘시스템적인 요구’란 비지니스
프로세스의 일부로써의 요구사항이 아니라 비지니스 분석을 끝내고 설계/구현된 어플리케이
션 레벨에서의 요구를 말합니다. 예를 들면 트렌젝션 관리나 인증관리등이 아니고 고객정보
취득, 거래현황 획득, 신규계약 입력 등의 요구사항을 말합니다.
제 이전의 글에서 서비스에도 레이어가 있다는 얘기는 이미 했습니다. 서비스의 레이어에서
보다 하위 레이어에 위치할 수록 비지니스적인 의미보다는 시스템, 또는 어플리케이션적인
의미를 지니게 된다는 것도 이미 말씀드렸구요. 이러한 수준의 요구사항들은 향후 BPM이
도입되더라도 재할용될 가능성이 높다고 생각합니다.
SOA도입에서 이상적인 케이스는 비지니스 분석을 하면서 동시에 기존의 시스템자산을 분
석해 중간에서 맵핑하는 하이브리드 방식이 될 것이라는 것도 말씀드렸습니다. 그러나 현실
적으로 ESB 도입단계에서는 아직 비지니스 프로세스 분석등이 미진하거나 아예 전무한 상
태인 경우가 많습니다. 그리고 이 경우 서비스를 단순히 비지니스 분석을 거쳐 도출되는 것
이라고 고정적인 사고방식을 가질 필요는 없다고 생각합니다.
제가 구축한 ESB시스템의 예를 말씀드리면, 역시 전사적으로 SOA를 도입한다고 해도 그
형태가 빅뱅형식이 될 수는 없으므로 당시 진행되고 있는 프로젝트에 대해 SOA에 입각한
설계와 시스템간 연계를 구현한다는 목표로 진행이 되었습니다. 당시 진행중이던 모 프로젝
트가 그 첫번째 구현대상이 되었구요, 그 프로젝트에서 구현중인 시스템과 기존의 다른 시
스템간의 연계 부분을 서비스화하여 ESB로 중계하는 작업을 실시했습니다.
물론 현업의 프로젝트 담당자들에게서는 익숙하지 않은 개념과 기술을 적용해야 한다는 점
에서 적지 않은 반발이 있었습니다만 고객측의 SOA에 대한 의지가 이미 확고한 상태였기
에 그런 반발들을 무마하면서, 가끔은 밟아가면서 진행을 하게 되었습니다.
이렇게 하여 일단 시스템과 시스템간의 연결부분부터 서비스화 하고 그 연결하는 중개체로
써 ESB를 사용하고 있습니다. 나중에 개별 시스템의 리플레이스가 진행되어 각 시스템이
SOA에 입각한 시스템으로 바뀌더라도 타 시스템과의 인터페이스 자체엔 변경이 없으므로
변경에 따른 코스트는 최대한 억제할 수 있습니다.
>>기 EAI 구축 고객에 ESB를 drive할 때, 저런 "단순히 시스템적인 요구를 만족하기 위한
서비스"로 drive가 가능한걸까요? 이미 시스템적인 요구 사항은 EAI에서 어느정도 소화하
지 않았을까요? 그경우, 고객이 한참듣고, 그럼 그냥 우리 EAI의 제품 버젼을 SOA지원 버
젼으로 upgrade 하란 거죠? 라고.. 묻는 고객들이 많아서요..
최근에 읽은 모 벤더의 문서에 기존의 EAI의 문제점을 아래와 같이 들고 그 문제점을 해
결할 수 있는게 바로 ESB라고 하더군요.
- 벤더고유의 아키텍쳐와 구현
- 워크로드와 코스트가 높음
- 새로운 기술에의 대응 및 다른 기술과의 공존이 어려움
- 표준사양의 부재
그 문서에서 주장한 내용자체는 제 의견과 차이가 있으므로 이곳에 전하지는 않겠습니다만
적어도 기존의 EAI툴에 상기한 문제점이 있다는 것은 사실인것 같습니다. 제가 생각하는
SOA에서 서비스는 표준화된 인터페이스를 통해 스스로를 공개한다고 하고 있습니다. 그렇
다면 이러한 서비스들을 연계하는 중계자는 표준의 인터페이스만 지원하면 되는 겁니다. 이
경우 기존의 여러가지 기술들을 지원하는 EAI툴은 SOA에 기반한 환경에서는 오버스팩인
셈이 됩니다. 물론 오버스팩인만큼 ESB가 지원하는 기술들을 대부분, 또는 그 이상 지원하
고 있다고 생각합니다. 하지만 그만큼 더 비싸고, 관리도 더 손이 많이 가는게 사실이겠지
요. SOA를 추진한다면 거대하고 복잡한 EAI툴보다는 싸고 슬림한 ESB를 도입하는것이 비
용면에서 보다 현실적이 되겠지요. 물론 현재 이미 EAI툴을 가지고 있고 그 기능들을 이용
하여 ESB가 할 일들을 다 대신할 수도 있겠지만 그 경우 질문은 ‘그 EAI툴을 언제까지 사
용할 것인가요? 그리고 ESB로 갈아타는 것은 빅뱅식으로 할 것인가요? 아니면 점진적으로
실시해 갈 것인가요?’라는 것이 되겠지요. 결국 ‘ESB를 팔아 먹겠다’는 일념으로 접근할게
아니라 고객의 시스템에 현재와 미래를 고려할 때 무엇이 최선이고 그 최선의 상태로 도달
해 갈때까지의 로드맵을 어떻게 그려갈 것인가 하는 것이 우선되어야 할 과제라고 생각합니
다. 그러면 결과적으로 ‘자, 그럼 모모 프로젝트부터 ESB를 점진적으로 도입해 가 볼까요?’
라는 얘기로 연결되지 않을까 합니다.
이상 뻔한 얘기를 한거 같아서 죄송합니다만, 실제로 위와 같은 방법으로 이곳에서는 이미
몇개의 프로젝트를 수주했고 진행하고 있습니다.
이상 개인적인 의견이므로 이견이나 지적 달게 받겠습니다.
|
제목 : Re: ESB의 도입에 대해
글쓴이: 일본사는넘(guest) 2006/05/23 13:57:39 조회수:678 줄수:18 |
|
기업대 기업사이에서 ESB를 강제할 하등의 이유가 없습니다. ESB는 표준 인터페이스로
공개된 서비스를 중개하는 역활을 하는 넘입니다. 즉 외부에서 보기에는 ESB는 단순히
하나의 표준인터페이스로 공개된 서비스들로 보인다는 거지요. 서비스의 특성상, 한
기업이 ESB를 도입했다고 해서 그 기업과 연계하기 위한 다른 기업도 같은 ESB를 도입하거나
할 필요는 전혀 없습니다. 그냥 공개된 서비스를 표준적인 프로토콜로 사용하거나, 아님
자신의 서비스를 공개하기만 하면 되는 것입니다. ESB가 있던 없던, 자바로 만들건 C++로
만들건 어셈블러로 만들건 상관이 없습니다.
예를 들어 구글이나 아마존이 제공하고 있는 많은 서비스들을 사용하기 위해서 ESB가
필요하던가요? 아님 그들은 내부적으로 과연 ESB를 사용하고 있을까요? 아닐까요?
서비스 이용자의 관점에서 ESB따위는 애초에 상관도 없고 관심분야도 아닙니다. 그냥
서비스의 인터페이스 명세만 알 수 있으면 되는 겁니다. 서비스 제공자라면 표준적인
인터페이스로 서비스를 공개하기만 하면 되는 겁니다. 내부적으로 ESB를 사용하던, 깡으로
자작을 하던 각자의 상황에 맞게 판단해서 구현하면 되는 거지요.
더불어 비지니스 오토메이션과 ESB는 그 용어 자체만으로는 별 상관이 없습니다. 차라리
BPMS라면 모를까..
|
제목 : Re: 일본사는넘님의 답글에 대한 이견들.
글쓴이: u2(Rainman1) 2006/05/23 19:23:42 조회수:673 줄수:180 |
|
간만에 짬이 생겼네요.
우선 답글에 이견을 적어보겠습니다.
1.서비스의 이용자층이 다르기에 그들이 사용하는 서비스의 크기는 각각 틀려지고 그래서 서비스간에는
레이어가 존재하게 됩니다. SOA에 레이어가 필수라는가 아니고 자연히 레이어의 개념이 만들어지게
된다는 얘기입니다.
=> 제가 강조했던 부분들이 잘 전달되지 않은 것 같습니다.
저는 개념이란 놓인 상황에 따라 상대적이란 것을 언급드린 것입니다.
같은 서비스라도
서비스하는 회사입장에선 거대프로세스로 상당한 컨트롤을 원하는 서비스가 될 수 있고,
서비스를 사용하는 사용자측 프로세스 입장에서는 하찮은 최하단의 서비스로 존재할 수도 있죠.
같은 서비스이지만 바라보는 관점에 따라
개념의 크기나 중요도에 상관없이 높낮이는 역전됩니다.
다시 말씀드리자면 바라보는 사람이 누군가에 따라
개념의 높낮이는 상대적인 것이지 절대적인 것은 아닙니다.
현재 필드에서 우리가 구현하는 것은
한 관점에서 절대적인 높이를 갖고 있는 layered architecture입니다.
컴포넌트 아키텍쳐에서 개념들은 특성layer에 고정되어 있지 개별 layer를 자유롭게 넘나들지 않습니다.
개념의 높낮이는 상대적이기 때문에 때때로 상위와 하위개념을 오갈 필요가 있지만,
layer에 의해서 고정된다면 비즈니스 투명성이란 것이라던가 표현방법에 상당한 제약이 가해지게 됩니다.
하물며 현재와 같이 해당 아키텍쳐의 layer들이 개념만을 포함하는게 아니라
개념+기술적요인(아키텍쳐 사상이나 스킬)으로 layer를 결정 짓고 있다면 두말할 나위 없습니다.
구축할 soa에 현재와 비슷한 기반의
layered architecture로 구현하고자 한다면
이전과 같이 한관점에서 개념의 절대적인 크기와 위치,
아키텍쳐에 대한 고려를 해서 퍼포먼스를 고려하며 엔터프라이즈서비스에 얹어놓는
기존의 개발,아키텍쳐,비즈니스 전문가의 작업들이 골고루 섞여야 됩니다.
그런다고 해서 비즈니스 투명성이 보장되는 것도 아니구요..
이미 상대적개념과 기술에 귀속되어 표현된 비즈니스이기 때문이죠.
그런데 이러한 아키텍쳐위에서
BA(비즈니스 분석가)의 관점과 일치하도록
비즈니스를 구성하고 핸들링할 수 있는
그러한 비즈니스 투명성이 표출될 수 있다란 건 그리 맞지 않습니다.
흔히 우리가 필드에서 BA와 업무에 관해 논의하다보면 그러죠..
그놈의 컴포넌트, 컴포넌트 컴포넌트가 도대체 뭔데 그렇게 답답하게 처리합니까..라고..
그런 의미에서 개념을 고정시키고자하는
layred architecture로 보는 이득은 별도로 존재하지만,
그것이 비즈니스의 투명성을 추구하는데 최선의 도움이 된다고는 인정하고 싶지 않네요.
개념적으로 투명성에 집중하고자 하는 아키텍쳐는
표현을 위해 '기술'이 개념을 지배하거나 규정짓지 말아야 합니다.
그렇지 않고서 현재와 같다면 아키텍쳐와 개발 전문가의 고민을
비즈니스레벨로 풀어나간다면 BA가 어떻게 감당할 수 있을까요.
그렇다고 개발자가 감당하기도 힘들고 아키텍트가 감당하는건 더욱더 힘들어지겠죠.
2.'특히나 수천, 수만개의 서비스가 움직이는 엔테프라이즈 레벨의 시스템에서 이러한 구분을 적용하지
않는다면 애초에 개발도, 관리도, 재이용도 불가능할 것입니다.) '
=> 이부분도 위의 layred architecture연장선 부분입니다.
현실을 생각해보도록 하죠.
비즈니스를 말로 돌릴때 레이어별 구분이 있어서 비즈니스가 이루어질 까요?
우리가 아침마다 출근하는 출근프로세스는
일의 중요 우선순위와 귀속도 개념의 크기가 있어서
그런것에 의해서 출근을 이해하고, 그러한 프로세스를 돌려서 출근이 가능한 것일까요?
테니스를 칠때 라켓으로 공을 치는 행위는 레이어별 사고에 의해서 이루어질까요?
IT기술적 관점에서 본다면 관리가 필요하고
영역을 나눈 아키텍쳐에 귀속되어야 정상이겠지만,
이는 개념을 분류에 귀속시키는 결과를 낳게 됩니다.
내가 말로 하는 것들이
서비스로 되어 있고 요건을 만족시키고 상호운용가능하다면?
그저 서비스가 어떤건지 개념적으로 알고 있고,
그것을 말로 풀어내고 프로세스를 구성해서 원하는 것을 만족시킬 수 있습니다.
이것은 A15-231-4853개념에 의해서
특정 layer는 access할 수 있다 없다란 제약들을 신경쓸 바는 아니죠.
(거대화된 프로젝트에서 개념으로써는 전혀 제약이 없는데
(다양한 아키텍쳐가 존재하고 넘나들때 제약이 강하게 걸립니다.
아키텍쳐가 개념을 구속한다는 것이 옳다고 생각하진 않습니다.
개념들이 분류가 되어 있지 않으면 관리가 불가능하고,
운용을 할 수 없는건 과거와 현재의 아키텍쳐와 구현상에서의 문제입니다.
3.'더불어, 위의 정의에 의하면 서비스는 인터페이스와 구현기술을 분리함으로써 상호호환성의 대폭적인
향상을 꾀할 수 있었습니다. 하지만 아직 해결하지 못한 문제가 하나 있었으니 바로 '서비스의
위치투명성'과 '인터페이스의 변경'이죠.(위치투명성이 한국어적으로 바른 표현인지는 잘 모르겠습니다만)'
=> 이부분도 이전에
'우리가 고민하는 기술적인 문제들은
단지 서비스일 뿐 그 이상도이하도 아니다'라고 적은바가 있습니다.
서비스의 위치투명성과 인터페이스의 변경은 누가 가져갈 문제일까요?
ESB가 가져가야 할 무제일가요? 프로세스를 구성하는 사람이 가져갈 문제입니다.
서비스제공자가 인터페이스와
위치를 변경한 것에 대한 완충장치는
네이밍 서비스로 부터 얻어야 하는 것이고,
인터페이스 변경에 대한 부분은
변경된 인터페잇의 해당서비스를 계속 사용할지 말아야할지 프로세스 전문가가 결정하는 부분입니다.
BA가 인터페이스에 맞게 인접서비스의 인터페이스를 수정하거나
변경된 인터페이스를 커버가능한 wrapper서비스를 만들 수도 있겠죠.
이렇게 풀어간다면 별도의 무언가가 필요한가요?
4.'u2님이 생각하는 서비스와 컴포넌트의 차가 무엇이지는 아직 잘 모르겠지만 제가 생각하기엔
SOA에서 컴포넌트란 배제되어야 할 기술이 아니라, 서비스의 구현기술로써 아주 유용한
기술이라고 생각합니다. 이를 역으로 표현하면 컴포넌트를 그대로 서비스화 하는 것도 아주
유용한 접근방법이라는 것입니다. 그래서 SOA에서는 그 장점의 하나로 '기존 시스템자산의
재활용성이 뛰어나다'고 하고 있습니다. 기존의 시스템 자산을 부정하고 있는 것이 아니라고
생각합니다. (그래서 위의 글타래에서는 SOA에의 현실적인 어프로치로써ESB의 하위단에 EAI가
존재할 수도 있다고 하고 있습니다)'
=> 컴포넌트는 배재되어야 한다고 적은게 아닌데 잘못받아들이신듯 하네요
전 컴포넌트를 좋아하고 그 사상이나 아키텍쳐도 좋아합니다.
단지, SOA의 layered architecture에서
절대적 layer에 위치한 기존 컴포넌트와 같이
동일한 방식으로 SOA를 구현하는 것은 바람직하지 않다고 말씀드린 것 입니다.
5. u2님이 강조하시는 'service-oriented'라는 의미를 모르는 바는 아닙니다. 하지만 u2님이
얘기하듯 개발자가 아닌 아무나 서비스 스크립트를 작성해서 각자의 서비스를 만들어 쓰기
위해서는 또다른 서비스가 필요하고 그러한 서비스는 아마도 새로이 작성하려는 서비스보다는
사이즈가 작을 것입니다. 그리고 그 작은 서비스들은 보다 더 작은 서비스들로 구성되어
있을 확율이 높구요. (여기서 레이어의 개념이 나옵니다.)
=> 레이어가 있을 필요가 없습니다.
수학공식을 풀기 위해서는 레벨에 따른 연산자가 개별적으로 레이어로 구현되어야 할까요?
아니면 내가 '사용하고자 하는 하나의 연산자'로 그저 존재하기만 해야할까요?
의사소통을 위한 단어란 단지 '존재'할 따름입니다.
레이어가 있으면 '분류기준'에 의해서 때때로 편할 수도 있겠지만,
그외의 커다란 제약의 장벽으로 다가오기도 하겠죠. 상대적 기준에 의해서 말이죠.
6. 그리고 서비스가 인터페이스와 그 구현으로 구성되는 기능의 단위라는 것을 생각할 때 그
구현을 어찌할 것인가의 문제는 여전히 존재합니다. 이 부분에서 기존의 컴포넌트와 미들웨어
가 등장할 것이구요. 결국 서비스란 추상화의 결과물인지라 어느 곳엔가에는 구상체가 움직이고
있을 필요가 있습니다.(다 아는 얘기를 하지 말라구요? ^^) '
=> 구현부분.. 미들웨어..
'일본..'님께는 미들웨어로 존재하지만,
제게는 모든게 서비스로 존재합니다.
서비스 이하는? 보아야 할 대상이 아니죠.
6. 결국 제가 하고자 하는 말은 'service-oriented'라고 하여 서비스만 생각해서 될게 아니란
얘기입니다. ... oriented'란 '... oriented'일 뿐, '... only'가 아니라는 얘기죠.
=> service-oriented service는 서비스를 지향하자는 것이죠.
객체지향이 responsibility-driven design을 하면서 다른 structured design을
같은 공간에서 용인하지 않는 것과 마찬가지입니다.
분명 일부는 배타적이고 유사하면서도 다른 부분이 존재하는 데,
그것을 섞어서 쓰면 아키텍쳐의 일관성과 기준을 무너뜨리게 되죠.
서로 배타적인 기준인데 어떤 것을 선택해야 될까.. '상황에 따라 다르게 적용..' 혼란야기..
개인적으로 SOA는 '말','자유'란 단어와 연관짓고있고,
service-oriented는 service-only라고 봐도 무방하다 생각합니다.
축구보러 바로 출발한다는게 장문의 답글이 되었네요^^;
결과적으로, 아키텍쳐가 어떻든간에
개인이나 기업이 자신이 원하는 것과 사상을
시스템화 하는데 로드맵이 있고, 비용이 적게들고 문제가 없으면 나이스합니다.
그렇게 가는데 나름대로의 SOA가 상황에 잘듣고 그대로 가면 그것이 최선의 것이죠.
제가 추구하는 것과 제가 구성할 SOA는 service-oriented-sevice 입니다.
그것으로 기술적문제와 아키텍쳐, layer, 개념적 문제들을 쉽게 풀어나갈 수 있습니다.
간단한 놀이용으로 쓰고자 하는 디스크립션으로 존재하는 database, 미들웨어..
책구매발송획득서비스나 하루일과를 표현하는 것을 시스템화 하는데에
아키텍쳐나 기술적 어려움없이 퇴근해서 짬짬이 조금씩 재미나게 만들고 있죠.
프로세스를 어떻게 정의하는 것이 재미있을까에 대해서 전철에서 짬짬이 고민할 따름이죠.
그것으로 저는 제가 하고 싶은 것을
미들웨어나 하드웨어에 대한 자산투자,
기술적 인력의 투자없이 SOA란 굴레로 얻어낼 수 있습니다.
미래지향적인 이득이 아니라, 지금 현재 심심풀이로 구현하고 얻어내고 있다는 얘기죠.
그것으로 현재시스템보다 한스텝 나은 것을 현시점에 얻어내고 있고,
시간이 지날수록 더욱더 큰것을 얻어낼 수 있다는 것을 체감하고 있습니다.
SOA의 아키텍쳐가 대단하고
기술적 노하우를 얻어낼 수 있다는 것이 아니라..
해당서비스를 만들고 사용해나가는 사람의 입장에서
더 재미있고 편한 서비스를 만들고 큰것을 얻을 수 있겠다는 말이죠.
그것으로써 전 service-oriented-service의 SOA에 불만없이 만족합니다.
어쨌든 많은 분들 각자가 원하는 방향으로 추진하다보면 각자가 나름의 해답을 찾을 수 있겠죠.
p.s 아는게 적고 표현하고자 하는 것이 서툴러
SOA의 비젼이나 방향성에 개인적 의견과
님을 포함한 많은분들의 '동감'이란 것을 얻어내지 못하는 것에 대해 아쉬움을 느끼네요.
|
제목 : Re: 관점의 차이
글쓴이: 일본사는넘(guest) 2006/05/23 23:15:58 조회수:620 줄수:26 |
|
이전에 u2님의 글에 대해 '개인적인 서비스 사용자의 관점에서 적은 것이냐, 아니면 엔터프라이즈
시스템의 관점에서 적은 것이냐?'라고 물은 적이 있습니다만 당시 대답은 엔터프라이즈
시스템의 관점이라는 것이었습니다. 하지만 전 웬지 u2님의 글에서 개인적인 사용자의
관점이 계속 보이는데 그건 제 오해일까요?
...
길게 적었다가, 어차피 이미 한 얘기들이 다시 반복되는것 같아 지우고, 짧게 적겠습니다.
'Service only'라도 좋다고 하셨는데 그거는 그렇다치고 그 뒤에 'Architecture'라는 말이
붙는건 알고 계실 것입니다. 그럼 그 Architecture란 말의 의미는 무엇일까요? 엠파스 사전에는
다음과 같이 나오는군요.
architecture [ktkt]n. 1 건축술, 건축학
civil ~ 보통 건축
ecclesiastical ~ 사원 건축
military ~ 축성법
naval ~ 조선학
2 건축 양식
3 구조, 구성(construction)
4 [집합적] 건축물
5 컴퓨터 아키텍처 ((대형의 복잡한 컴퓨터의 구성 요소를 배치해 조직화하는 구조상의 방식))
아마도 u2님의 의견대로라면 SOA에서 'A'는 필요없지 않을까요?
|
제목 : Re: SCA
글쓴이: 일본사는넘(guest) 2006/05/26 22:42:27 조회수:691 줄수:4 |
|
제목 : Re: SCA
글쓴이: 손님(guest) 2006/05/28 08:58:51 조회수:628 줄수:3 |
|
JBI 스펙에 대응되는 것으로 IBM 과 BEA 가 추진해온 스펙입니다.
다른말로 IBM 과 BEA 는 JBI 스펙에 참여하고 있지 않습니다.
|
제목 : Re: 제안입니다 (케이스 스터디)
글쓴이: 일본사는넘(guest) 2006/05/30 08:23:34 조회수:675 줄수:16 |
|
지금껏 여러가지 얘기를 해 오고 있습니다만, 한가지 케이스스터디를 해 보고 싶습니다.
다음과 같은 경우엔 어찌 해야 할까요?
- 상황: 다수의 웹어플리케이션으로 구성된 시스템을 가지고 있는 회사가 SOA의 도입을
검토하고 그 지원을 요청 중. 각 웹 어플리케이션은 특별한 기준없이 그때 그때 필요에
따라 JAVA(JSP+Tomcat 레벨), PHP 등으로 작성되어 있음. 레이어드 아키텍쳐? 그런거
모름. 대표적인 무계획 시스템의 총합. 고객정보, 상품정보의 조회 이외엔 각 어플리케이션
간의 연계는 거의 없음. 수시로 새로운 웹상의 서비스를 개시하는 비지니스 형태.
- 과제:
이 회사에 SOA를 도입하기 위해 도대체 무엇이 필요할까? 그 스텝은 어찌해야 할까?
(그 이전에, SOA의 도입이 정말 바른 답인가? 부터 논해도 좋겠지요)
지금까지 엔터프라이즈 시스템에서의 시스템 통합을 주된 테마로 얘기가 되었다고 생각
합니다. 하지만 위와 같은 분야의 시스템에 SOA를 적용할려면 어찌해야 할까요?
|
제목 : Re: 요구사항이 불충분합니다.
글쓴이: 사랑전쟁(lovewar) 2006/05/30 08:59:53 조회수:942 줄수:14 |
|
회사가 무슨일을 주업으로 하는지와 web service가 하는 주업무는 무엇인지가
기술되어야 할것 같습니다.
그래야 서비스를 어떻게 할 것인지가 나오고 서비스가 어떻게 변화하는지도
유추를 해야 기본적인 요구사항을 충족하지 않을까 생각합니다.
>> 수시로 새로운 웹상의 서비스를 개시하는 비지니스 형태
추측하건데, 제품을 판매하는 소핑몰일 것으로 보여집니다.
-- 덧붙이는 글 --
SOA의 세부적인 기술은 모르기 때문에, 기술적인 이야기에 대해서는 언급하지 않겠습니다.
다만, 실생활에 정말 필요할지에 대한 의문에 관해서는 저또한 궁금한 사항이 있기에
질문드리겠습니다.
|
제목 : Re: 요구사항 추가합니다.
글쓴이: 일본사는넘(guest) 2006/05/30 12:26:40 조회수:602 줄수:19 |
|
회사의 주업은 온라인 판매입니다. 판매하는 제품은 책, 잡화, DVD 등 다양하고 시즌별로
각종 이벤트나 캠페인도 개최합니다. (웹상에서) 새로운 아이디어는 무수히 나오고 그걸
선별해서 신속히 서비스로 올려야 합니다.
웹서비스 자체는 아직 사용하지 않고 있습니다. 이미 말씀드렸듯 스크래치로 작성한 독립적인
웹어플리케이션이 다수 산재해 있습니다. 어플리케이션간의 연계는 HTTP로 하고 있습니다.
데이터모델, 업무 프로세스등은 절대 정리되어 있지 않습니다.
이런 회사가 SOA를 도입하고자 합니다. 이유는... 남들이 다 한다니까, 뭔가 뒤쳐지는거
같아서 우리도 함 해보자!라고 생각한거죠. 목적은? 그것도 잘 모르는 회사입니다. 다만
돈은 많습니다.
이 정도면 정보가 충분한가요? 아직 모자라면 더 보충하겠습니다.
|
제목 : Re: 일단 접고..
글쓴이: u2(Rainman1) 2006/05/30 13:06:31 조회수:716 줄수:25 |
|
일본사는넘님께 //
soa는 'architecture'가 아니라 'architecture style'입니다.
soa의 기본 아키텍쳐는 consumer->provider입니다. 심플하죠.
enterprise architecture 사이트 등에 언급되어 있는부분이죠.
이미 제가 계속 언급해온 부분들은
layer pattern의 weak point나..
soa architecture style에서integration, network에 의해
layer, monolithic, soa등이 구분되어 다른 위치에 그려진 그림들과 상동하는 부분입니다.
(soa architecture style 사이트들을 찾아보면 layer와 비교된 내용들이 좀 있습니다.
케이스 스터디를 하신다고 하니 한가지 의견을 내놓자면,
'soa를 선택하려는 이유'부터 출발하시는게 좋을 듯 싶네요.
모든 ea의 출발점은 'why change~'..
쏘아님 //
soa이 시작은 기저부터 작게 출발하는게 정론으로 되어 있고,
서비스화.. 메세지라우터.. 내부서비스화.. 외부서비스 결합.. 이런식으로 가구요.
상위모델링 완성후 간다.. <-이런식의 방법은 금기시 하고 있습니다.
서점에 가시면
web services and service-oriented architecture나 soa conecept,,.에서
심플하게 전략에 대한 조언 등이 적절하게 나와 있으니 참고하시길..
|
제목 : Re: SOA 전략
글쓴이: 조대협(guest) 2006/05/30 13:18:27 조회수:653 줄수:34 |
|
"일본사는넘"님의 case에 대한 SOA 전략에 대해서 제 생각은 적어봅니다.
저는 단계별 SOA 추진 전략을 권고하고 싶습니다.
1단계
먼저 1단계로는 SOA기반의 시스템 통합이 목적입니다.
EAI와 같은 개념의 Integration으로 보면 되겠지만 좀더 Loosely coupled된 상태입니다.
먼저 통합했을때 가장 effective한 업무를 선택한후에 그 대상 시스템을 통합하는것을 우선으로합니다.
대상 시스템은 1~2개 정도의 사용빈도가 많은 업무를 선택하고..
가능하다면 의사소통상의 문제를 없애기 위해서 한 부서내에 분리되어 있는 시스템을 우선으로
WebService화하고, 이를 Service간 호출을 통해서 두 업무를 하나로 통합하는데 목적을 둡니다.
가장 기본적인 SOA모델로, 이 단계에서는 SOA 기반 기술의 습득과 업무 통합으로 인한 이득을 목표로 합니다.
별다른 솔루션의 구매가 필요없을 것으로 판단이 되고,
기술상의 가장 큰 주의점은 재사용 가능한 Business Component를 구축하는데 목적이 있습니다.
2단계
이 단계를 거치면 각 부서내에 서비스 기반의 연동 프로젝트를 시작합니다.
통합 프로젝트가 2~3개 이상이 되면 추후 확장을 위해서 Service Repository 즉
UDDI를 도입하여 서비스를 중앙에서 통합 관리하고, 해당 서비스 위의 Layer에
ESB를 도입하여 Flexibility를 확보합니다.
ESB를 초반에 도입하는것이 endpoint변경이 없어서 좋기는 하겠지만
비용이나 기술 습득면에서 1~2프로젝트는 플랫폼이 없이 진행해도 좋겠습니다.
3단계
이 단계까지 진행이 되면
많은 업무들이 Service화 되어있고 ESB에 연결이 되게 됩니다.
다음은 경영 혁신면에서 접근하여, Business Process를 As-Is와 To-Be형태로 분석하고
Business Process기반의 SOA를 구축합니다.
대략적인 단계별 컨셉에 대해서 러프하게 서술해봤습니다.
의견 나눠보도록 하지요.
|
제목 : Re: 접힌 곳에서..
글쓴이: 일본사는넘(guest) 2006/05/30 16:57:15 조회수:572 줄수:42 |
|
u2님께 //
>>soa는 'architecture'가 아니라 'architecture style'입니다.
>>enterprise architecture 사이트 등에 언급되어 있는부분이죠.
Architecture style라는 부분은.. 어떤 다른 의미가 있는지 잘 모르겠습니다.
웹을 찾아보았지만 SOA as Architur[al] style 이라는 글 외엔 뾰족한 결과물의 검색에
실패했습니다. 수고스럽겠지만 말씀하신 사이트들의 링크를 알려 주시면 진지하게 공부해
보겠습니다. 제가 발견한 사이트는 아래와 같습니다만 말씀하신 사이트가 맞나요?
http://www.eds.com/sites/cs/blogs/eds_next_big_thing_blog/archive/2006/04/10/8538.aspx
>>soa의 기본 아키텍쳐는 consumer->provider입니다. 심플하죠.
맞습니다. 그리고 그건 연쇄가 가능하죠. 즉 프로바이더는 또 다른 서비스의 컨슈머이기도 하지요.
추상화하면 심플하지만 실제 구현하기는 그렇게 심플하지 않을 수도 있습니다.
>>케이스 스터디를 하신다고 하니 한가지 의견을 내놓자면,
>>'soa를 선택하려는 이유'부터 출발하시는게 좋을 듯 싶네요.
>>모든 ea의 출발점은 'why change~'..
원론적으로 말씀하시면 그건 맞는 말이지만 현실은 꼭 그렇지 않지요. 위의 케이스는 제가
실제로 겪은 경우입니다. 일본의 위와 같은 한 고객이 SOA를 하고 싶은데 도와 달라고
왔구요, 왜 SOA냐? 고 물었더니 '요즘 유행한다니까..'가 답이었습니다. 그런 고객의
시스템에 대해 어떻게 SOA를 적용할 것인가를 고민해 보고자 한 것이었습니다.
(실제로는 그 고객과의 SOA 얘기는 정치적인 문제로 없어졌습니다만.. )
>>soa이 시작은 기저부터 작게 출발하는게 정론으로 되어 있고,
>>서비스화.. 메세지라우터.. 내부서비스화.. 외부서비스 결합.. 이런식으로 가구요.
>>상위모델링 완성후 간다.. <-이런식의 방법은 금기시 하고 있습니다.
위의 얘기는 제게 한게 아니라 제가 끼어들긴 좀 뭐하지만.. 말씀하신 그 'SOA의 정론'
이란게 정말 확립되어 있다면 정말 알고 싶습니다. 말씀하신 책자를 제가 읽었는지 아닌지는
모르겠지만 (일본과 한국의 책 타이틀이 틀립니다. 번역서라도) 그 책자에 나오는 얘기들이
정론일까요?
제가 한가지 말씀드리고 싶은 것은 SOA를 작게 출발하는 것은 현실적인 제약에서 어쩔 수
없다고 하더라고 머릿속에 큰 그림을 가지고 시작하지 않으면 반드시 실패한다는 것입니다.
고객과 함께 큰 그림을 그려놓고 인식을 함께 한 후 마일스톤을 정하고 하나하나 해 나가는 거죠.
최소한 몇년에 걸쳐서.
|
제목 : Re: 조대협님의 의견에 대해
글쓴이: 일본사는넘(guest) 2006/05/30 17:23:05 조회수:660 줄수:7 |
|
좋은 의견 감사합니다. 하지만 상세한 방법론에 들어가기에 앞서 고객의 업무형태와
기존의 시스템 구성을 토대로 바람직한 To-be 모델이 어떤 것이 될 것인가를 정하고
싶습니다. 그 결과에 따라서는 SOA는 '필요없음'이라는 결론이 나올수도 있겠지만 그건
또 그런대로 의미가 있지 않나 싶습니다.
시스템통합이 과제가 아닌 위와 같은 시스템에 대해서는 어떤 방식으로 SOA를 적용해
가야 할까요?
|
제목 : Re: 혹시라도..
글쓴이: 일본사는넘(guest) 2006/05/30 17:30:06 조회수:590 줄수:12 |
|
혹시라도 '숙제는 스스로 해'라는 글이 올라올까 봐 미리 연막을 쳐 두자면,
위의 케이스는 제가 실제로 겪을뻔한 케이스였고, 아쉽게도 실제 프로젝트로 연결되지
못하고 중간에 없어진 케이스입니다.
하지만 저 나름대로는 고심을 했었고 나름대로의 아이디어도 가지고 있습니다. 하지만
그걸 먼저 말씀드리지 않는 이유는 여러분들의 의견이 혹시라도 제 의견에 의해 애초의
방향성 설정의 부분에서 영향을 받을까 해서입니다.
그러므로 제 의견은 나중에라도 반드시 밝히겠습니다.
하지만 우선은 여러분들의 식견을 듣고 싶습니다.
|
제목 : Re: 보충 설명을 부탁드립니다.
글쓴이: 사랑전쟁(lovewar) 2006/05/30 17:54:33 조회수:606 줄수:9 |
|
>>새로운 아이디어는 무수히 나오고 그걸 선별해서 신속히 서비스로 올려야 합니다.
여기서 새로운 아이디어를 서비스한다고 했는데, 그 아이디어란 어떤 유형인지
예로 하나만 설명부탁 드립니다.
-- 덧붙이는 글 --
돈이 많다는 것에 구미가 땡기는 군요. -.-;
|
제목 : Re: 새로운 아이디어란
글쓴이: 일본사는넘(guest) 2006/05/30 18:00:05 조회수:654 줄수:13 |
|
서비스기획팀이 시스템부문과는 별도로 존재하고, 그 곳의 일이란게 항상 새로운 아이디어
를 창출하는 것입니다.
예를 들자면 새로운 이벤트나 캠페인을 만들어 내거나, 아니면 판매만 하던 DVD를 렌탈도
하는 식으로 새로운 형태의 서비스를 제공한다던지, 접속단말을 컴퓨터에서 핸드폰으로
확대한다던지 하는 것이죠.
시스템적인 관점에서 보면 새로운 화면플로우와 그에 따른 백그라운드 시스템이 추가/확장
되거나 아예 새로운 웹어플리케이션을 만들거나 하는게 되겠죠.
|
제목 : Re: 좀더 정리가 필요할거라 생각합니다.
글쓴이: 사랑전쟁(lovewar) 2006/06/03 10:38:48 조회수:606 줄수:32 |
|
>> 이런 회사가 SOA를 도입하고자 합니다. 이유는... 남들이 다 한다니까, 뭔가 뒤쳐지는거
>> 같아서 우리도 함 해보자!라고 생각한거죠.
일본에서는 SOA가 대세인가 봅니다. 남들 다한다고하니 반드시 장점이 있을 것 같은데,
아직 와닿는 것이 없습니다. 단지 SOA와 현재 벌어지는 일(웹 2.0)들과 함께 생각해야
할것도 같고, 좀더 나가서는 U-세상까지 봐 줘야 할것 같은데, 정확하게 잡히지 않고
있으니, 가슴이 답답할 뿐입니다.
>> 예를 들자면 새로운 이벤트나 캠페인을 만들어 내거나, 아니면 판매만 하던 DVD를 렌탈도
>> 하는 식으로 새로운 형태의 서비스를 제공한다던지,
이벤트나 캠페인들을 한다면 그에 관련된 업무 담당자들이 처리해야 할 일들이 필요할
것으로 봅니다. 한사람이 아니라 여러사람들이 관련 업무(서비스)를 수정하거나
업무(서비스)를 재개발하거나 해야 할 것으로 봅니다.
그리고, 대여업은 하나의 사업으로 봐야 하지 않을까 생각합니다. 단순한 예이긴
하지만, 업무에 관한 것으로 보기에는 너무 큰다고 생각합니다.
이 회사의 다른 업무들이나 서비스들에 대해서는 좀더 정리가 필요할 것 같습니다.
기존의 업무방식 + 앞으로 발생하게되거나 해야할 일들에 대한 정리가 우선시 되어야
할것 같습니다. 서비스란것이 추상화된 개념이라서 XX서비스란 표현까지는 정리
(요구사항정리)가 되면 형상화시키는데는 좋을것 같습니다.
일본에서는 "남들 다한다"는 것은 정말인가요?
-- 덧붙이는 글 --
미래 기업(예, 전자장터)을 본다면 서비스화를 하긴해야 할것 같은데,
고정관념이 있어서 인지 SOA(?)의 정확한 사상을 이해하기가 힘드네요.
아래 기사는 태우님의 블러그에 있는 내용입니다.
http://twlog.net/wp/?p=469
|
제목 : Re: -- SOA 토로은 여기서 접도록 하지요 --
글쓴이: 조대협(guest) 2006/06/07 10:43:32 조회수:647 줄수:8 |
|
안녕하세요?
조대협입니다.
그간 SOA토론에 매우 열띤 토론과 의견 교류가 이루어 진것을 매우 기쁘게 생각합니다.
요 몇일 동안 업데이트도 없고, 기본적인 SOA에 대한 의견 교류는 이정도에서 끝마치는게
어떨까 싶습니다.
추후에 좀더 깊은 주제로 토론할 내용들은 새로운 주제를 열어서 진행해보록 하지요.
그간 참여해주신분들 감사합니다.
|
제목 : Re: 헉.. 케이스 스터디 결론은 안나나요?
글쓴이: 쏘아(guest) 2006/06/07 10:58:21 조회수:582 줄수:25 |
|
오랜만에 들어왔습니다.
근데 정말 끝마치는 건가요?
케이스 스터디 결론 안내고요?
적어도 일본 사는넘님께서 생각하셨다는 부분이라도 공유를 했으면 하는데..
어쨋든...
저역시 가장 어려움을 겪는 부분은 왜 그 고객에게 SOA를 적용해야 하느냐는 것입니다.
대략적인 잇점은 알겠지만.. 그래서 우리 회사엔 무슨 잇점이 있나요? 라고 물으면..
그게 대답하기 쉽지 않더라구요.. 표준의 활용, 먼 미래를 위한 유연성, 눈에 보이지 않는
재사용성으로 고객을 설득하기 정말 쉽지 않습니다.
위의 케이스 스터디에서도 고객의 비즈니스를 속속들이 분석하지 않는한 왜 필요한지를
IT단으로부터 이끌어들이기는 쉬워보이지 않습니다.
무언가 외부와의 인터페이스 요건, 분산/복잡 환경으로 인한 개발 비용 증가 등
IT단에서 눈에 보이는 것이 없는한..
전 딱히 떠오르는 것이 없습니다.
그리고 언제나 비즈니스적인 부분이 약한 저로서는 IT단에서 SOA를 끌어내기가 쉽지가
않습니다
비록 실패는 하셨다고 하나 일본 사는 넘님께서는 어떻게 drive를 하셨었는지요?
토론이 끝나버렸다면 메일로라도 공유 부탁드립니다. ^^
감사합니다.
|
제목 : Re: 좋은 토론 감사합니다.
글쓴이: 손님(guest) 2006/10/12 16:20:36 조회수:1044 줄수:46 |
|
좀 지나서야 이렇게 좋은 토론을 보았네요.
저는 요즘 ESB와 BPM에 관한 작업을 하고 있습니다.
메타적 개념 / 레이어 / 쓰임새등등.. 여러사람의 의견을 읽을 수 있어서 참 유익했습니다.
메타에도 개념이 있어서 메타의 메타포.. 그이상이 SOA에 담겨있지 않나 싶습니다.
아래는.. 사족으로 제가 생각하는 개념을 적어보았습니다.
-----------------------------------------------------
SOA : 서비스 중심으로 이루어지는 아키텍쳐
webservice : 서비스 연동시 대화가 통해야 하는데 이러한 대화의 표준
외부 연결시에 가장 큰 장점으로 존재
EAI
주로 레거시와 연동되는 adapter 표준을 추구
구현시 주로 강력한 결합력을 보임
ESB
한 회사와 같은 동일 그룹내에 작은 auto-service 간의 연결에 사용
단순히 중앙 bus를 통한 통신방식을 이용하여 외부 service를 매핑
또한 buinding과 business 로직을 분류하여 mult-access-protocol 지원이 가능
JBI 표준을 통한 ESB-Object의 재사용성 커짐
EAI와 ESB를 비교 대상으로 보지 않음
그런 Webservice와 corba가 어짜피 분산 Object를 핸들링 하는것이니까 같은 개념이라고 우기는 것과 같음
BPM
SOA와 동일 영역에서 말하면 안됨
SOA는 개발자 view의 작은 object를 보던것을 좀더 외부 자원 즉 서비스를 결함하여
재사용성을 높이자는 방식.
외부자원과의 연결을 위해 당연히 공통성 높은 아주 common한 부분으로 service가 집중
그러나 BPM은 재사용성 이런 부분 보다는 해당 비즈니스 로직 체인 형성을 보다 유연하게 하여
기업 프로세스 변경과 개발/배치를 분리하여 보다 빠른 처리를 높이는 기술을 말한다.
현재 통합이슈
SOA 아키텍쳐 + BPM를 통한 로직 배치의 자유로움 + ESB를 사용한 auto-service 연동 및 mult-bound 확장
* SOA는 그동안의 객체중심이 아니라 "서비스" 중심으로 결합하여 이용하자는 방식으로
외부 interface와 access에 집중하는 block-box 아키텍쳐/사상라고 생각함
* 그러나 BPM은 좀더 구체적인 bussiness 요소의 배치의 자유로움 주는 보다 세밀한 테크니컬 방식
* 그리고 ESB는 EAI의 지겨운 adatper 구현을 벗어나게 해줄수 있는 가벼운 container로 생각.
* SOA는 SCM과 같은 다수의 기업간 연동시에는 그 사상만으로도 빛이 될수 있지만
일반 close 운영을 하는 기업에서는 매리트 없음
* 오히려 RTE 환경 접근을 위해 무엇보다도 BPM과 ESB의 결합이 중요할 것임
|
|
하하하
