ALM Overview PPT 2009/03/16
2008년 SOA 전망 2008/01/10
EAI 도입 전략 2007/08/21
JVM 튜닝 2008/03/12

오늘도 타이트한 하루가 끝나갑니다.
오전일 끝내고, 와이프와 딸을 데리고 집에서 한시간정도 거리에 있는 용인 한택 식물원에 다녀왔습니다. 오프로드를 유모차를 끌고 올라가는게 상당히 운동이 되더군요. 우리딸은 물만 보면 사죽을 못쓰는지라, 계곡에서 그리고 분수대에서 계속 있을려고 해서.. 데리고 나오느냐고 미안했습니다.

 SOA에 대해서 왜 이런 이야기를 하느냐 하면,
현존하는 아키텍쳐중에서 가장 범위가 넓고 가장 발전한 아키텍쳐중의 하나이기 때문입니다.
DDD의 글을 쓰다가 생각이 난 내용인데, SOA는 기본적으로 서비스를 비지니스적인 의미로 정의를 합니다. 비지니스와 IT조직간에 같은 Context를 사용한다는 겁니다. 그리고 전체 기업을 대상으로 하기 때문에 이 Context의 전파가 중요한 요건이 됩니다.

또한 애자일 사상에서 이야기 하는 Iteration의 개념역시 SOA에서 Vertical Slising과, Short Release의 개념으로 이미 녹아나 있습니다.

 팀조직과 협업 그리고 정치에 대한 부분역시 Governance에 대한 부분에 설명이되어 있고, 비지니스 아키텍쳐(사업의 비젼, 비용 관리등)에 대한 내용 역시 SOA의 비지니스 아키텍쳐에 설명이 되어있습니다.

SOA가 성공한 아키텍쳐네, 벤더들의 마케팅 수단이네 말은 많지만 SOA 자체는 훌륭한 아키텍쳐임에는 틀림이 없습니다. 적용하기가 힘들고, 현실화 시키기 위한 기술이 만만하지 않을뿐이지요.

 SOA를 공부하면 Enterprise System의 전체를 볼 수 있어서 아키텍쳐에 관심이 있으신분들은 꼭 공부해보시기를 추천합니다.

 항상 생각하는건데, 기술을 고민하는 사람들의 고민점과 해답은 시간이 지날수록 점점 비슷한 곳으로 모아지는 것 같습니다.

개인적으로 SOA에 관련해서 읽었던 책중 최고 명서는 http://www.amazon.com/Enterprise-SOA-Service-Oriented-Architecture-Practices/dp/0131465759/ref=sr_1_9?ie=UTF8&s=books&qid=1246714242&sr=8-9 이 아닌가 싶습니다. (Enterprise SOA)
2004년에 작성된 책이고, 웹서비스가 없었을때임에도 불구하고, SOA의 개념과 구현 방법,개념, 조직 구조등에 대해서 아주 잘 설명하고 있습니다. 군더더기가 없는 책이지요. 2004년에 이런 생각을 해낼 수 있다니 놀라울 따름입니다. 번역서도 있는 것으로 알고 있는데, 꼭 추천합니다.

다음으로는 Applied SOA입니다.
http://www.amazon.com/Applied-SOA-Service-Oriented-Architecture-Strategies/dp/0470223650/ref=sr_1_1?ie=UTF8&s=books&qid=1246714619&sr=1-1#
버릴것이 하나 없는 책입니다. 앞의 책보다 깊이가 좀더 있고, 특히 Governance와, Business Architecture 에 대한 부분이 보강이 되는 부분입니다. 작년에 출판사의 번역 여부 조언으로 받아서 읽었는데, 사실 읽을때 마다 새롭습니다. :(

마지막으로 SOA Design Pattern 입니다.
http://www.amazon.com/Design-Patterns-Prentice-Service-Oriented-Computing/dp/0136135161/ref=sr_1_1?ie=UTF8&s=books&qid=1246714775&sr=1-1
아마 SOA에 대한 책을 가장 많이 쓴 사람이 Thomas Erl 일겁니다. 그의 SOA에 대한 초기 두권의 저서가 시기를 잘 탔기 때문에 유명세를 탔다고 생각하는데요. 그 두권의 책의 내용은 사실 매우 별로 였습니다. 파란표지 책은 그나마 서비스 분석과 디자인 방법에 대해서 소프웨어 공학론적인 접근을 하고 있어서 참고할만 하지만, 그 내용을 수백페이지에 다뤄야 하나 하는 의문이 생깁니다.
 SOA Design Pattern은 Thomas Erl 의 이런 기존서적에 대한 비평을 조금이나마 덜어줄 수 있는 책이 아닌가 싶습니다.  역시나 이번책에도 다소 군더더기가 많아 보이기는 합니다만, 책의 질이 좋아서 들고 다니면 폼은납니다. :)
 이번 책에서는 SOA를 몇가지 관점으로 나눠서 정의하는데, 이 접근 방법이 매우 흥미롭습니다.
Service 자체에 대한 디자인 패턴, Composition 패턴, 그리고 기억이 가물가물한테 Service Infra에 대한 패턴 그리고 마지막으로 Service Inventory 패턴입니다.
 패턴 내용 자체보다는 제 경우 4가지 패턴으로 나누었다는 접근 방식 자체가 흥미롭습니다. 실제 설계해도 이렇게 해야 겠다는 생각이 들더군요.
 가장 주목할만한 점은 Service Inventory Pattern 입니다. 이 패턴은 흔히 이야기 하는 Service Repository 입니다. 기존에는  Service Repository를 단순히 UDDI 정도로 접근하는 개념이 많았지만 UDDI는 Runtime 에서 사용되는 서비스의 DNS? 정도입니다. (물론 부가기능은 더 있겠지만요.)
 그러나 SOA 가 성숙되어감에 따라 이 서비스를 어떻게 관리할것인가 (카달로그 또는 Repository 라고 합니다. )에 대한 의문이 생기는데, 이것이 Thomas Erl이 언급한 Inventory 입니다.
 Thomas Erl 아저씨의 특성상 책이 읽기가 어려워서 읽어도 잘 진도가 안나가서 고전을하고 있지만
 접근 방식에 대해서는 충분히 연구를 해볼만한 가치가 있습니다.

쭈욱 적어내려갔는데... 써놓고 보니 또 어렵습니다. :(
 그래도 SOA를 다른분들도 공부해서 많은 것을 얻어가실 수 있지 않을까 하는 생각에 정리해봤습니다.

의견이나 토론은 항상 환영합니다.



이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/357 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. sloth
    2009/07/05 10:46
    댓글 주소 수정/삭제 댓글
    좋은책추천 감사합니다.... SOA in practice도 개인적으로 즐겁게읽었던거같습니다.
    • 2009/07/05 11:35
      댓글 주소 수정/삭제
      안 읽어본 책이네요. 한번 찾아서 읽어봐야겠습니다.
  2. 2009/07/05 15:26
    댓글 주소 수정/삭제 댓글
    좋은 정보 공유 감사합니다. SOA는 '기업혁신을 위한 서비스 지향 아키텍처' 를 읽고 제 블로그에 카테고리로 놔두었는데 SOA를 입문할 기회가 되면 목록을 채워볼까 합니다.

오전에 우리딸 먹을 아빠표 맘마 만들어놓고, 우리식구 새로운 보금자리를 구입해놓고 인터리어 공사때문에, 아파트 76세대를 돌면서 인테리어 공사 동의서에 싸인을 받으러 다녀왔습니다.
메론 한손에 들고 말이지요. 51세대(70%)에 받아야 한다고 해서 어젯밤부터 부지런히 발품을 팔았습니다.

그런데 와이프가 친구가 화장실 타일을 이쁜것을 무료로 몇달후에 주겠다고 해서, 자재비 아끼기 위해서 화장실 공사를 나중에 다시 또 해야 할것 같습니다. 그래서 다시금 76세대를 돌아야 하는 사태가 생길지도 모르겠습니다.

대충 정리하고 들어오니 12시군요. 와이프는 아직 직장에서 돌아오지 않았고, 15개월된 딸은 기분좋게 낮잠을 자고 있어서 오랜만에 주말오전에 다만 몇십분이나마 개인 시간을 가지고 있습니다. DDD에 관심만 가지고 있다가 우연하게 다른분 포스트에서 Context Continuous Integration 에 대한 개념을 보게 되었습니다.

개념 자체는 프로젝트에 속한 모든 인원들이 Context 를 공유한다는 것이고, 이 Context 에 대한 통합을 지속적으로 한다는 것입니다. Context의 개념은 조금더 공부해 봐야 알겠지만 제가 이해하는 바로는 다음과 같은 내용입니다.

  • 프로젝트의 목표
  • 각 모듈별의 기능
  • 용어 (대외계,대내계,계정계,동기화,분할거래,전달보장,순차거래,서비스 등등)
  • 팀별 역할

한 마디로 정리하자면, "누가 무엇을 언제 어떻게 할것인가"에 대한 공감대를 지속적으로 공유하여 서로 같은 목표와 같은 생각으로 프로젝트를 진행하는 개념입니다.

"아! 이거다" 하는 생각이 들정도로 공감이 가는 내용이었는데, 실제 프로젝트에서도 보면, 서로 딴생각 다른 목표로 진행되는 경우가 많습니다. 그러다 보니 "여기는 A팀 역할 아니었냐?" "우리는 B팀으로 알고 있었다."와 같은 상황속에서 역할의 공백이 생기거나, "이 시스템 이렇게 동작하기로 되어 있는것 아니었어? 여기에 맞춰서 설계했는데..." "그게 아니니라 ABCD로 동작한다고 했었잖아요." 와 같은 문제가 생기게 됩니다. 실제 빈번하게 발생하는 상황이지요. 특히나 다수나 여러팀이 협업하는 경우에 많이 생깁니다.

 이런 문제를 해결하는 방법은 소통이 가장 좋은 방법입니다. 끊임없이 만나서 이야기하고 서로의 생각의 차이점을 조율하고 하나의 Context를 가지는 방법입니다.

 그외에도 Boundary를 정하는 방법이나 비지니스 적으로 시스템을 접근하는 방법등 좋은 내용이 많네요.
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?ie=UTF8&s=books&qid=1246678215&sr=8-1

꼭 시간내서 읽어봐야 겠습니다.
요즘 모 출판사에서 책을 마음것 볼 수 있도록 후원을 해주시고 계셔서 읽어야 하는 책만 쌓여 갑니다. Thomas Erl 의 SOA Design Pattern에도 좋은 내용들이 많던데요.. 조금더 부지런해져서 읽어놔야 겠습니다.

저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/356 관련글 쓰기

  1. CI에 대한 좋은 정리글이 올라왔습니다.

    2009/07/05 20:59
    삭제
    http://bcho.tistory.com/356 한번 꼭 읽어 보세요. 지속적인 개념의 통합을 실현하려면 모든 당사자가 빠짐없이 노력해야 한다는 점입니다.:)

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009/07/04 12:52
    댓글 주소 수정/삭제 댓글
    저랑 관심사가 동일하시군요. 그것을 실현하려면 꾸준한 노력이 필요할 것 같습니다.
    저도 그렇고 팀도 그렇구요.:)
    • 2009/07/04 22:00
      댓글 주소 수정/삭제
      아 CI에 대한 개념을 봤다는 블로그가 moova님 블로그입니다. 트랙백 걸어놔야 겠네요.


The RESTful Soa Datagrid with Oracle
View more documents from Emiliano Pecis.


Coherence를 캐슁으로 실제 구축한것이 흥미롭다.
다음 아키텍쳐 구축할때 참고할것
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/355 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


DDD를 잘하기 위한 요구사항이란다.
==

http://www.infoq.com/articles/ddd-in-practice

Let's look at some of the other factors that are required for implementing a domain model.

  • The team should have regular access to business domain subject matter experts.
  • IT team (modelers, architects, and developers) should possess good modeling and design skills.
  • Analysts should have good business process modeling skills.
  • Architects and developers should have strong Object Oriented Design (OOD) and Programming (OOP) experience.
==
이정도 전문성이 있는 사람들이 모여 있다면 DDD가 아니더라도 프로젝트가 잘되지 않을까?
저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/354 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


KX사의 프로젝트에서는 Bugzilla
S사의 프로젝트에서는 JIRA + Hudson + xUnit
H사의 프로젝트에서는 JIRA + Confluence + Bamboo + xUnit 
또다른 H사의 프로젝트에서는 JIRA + Hudson + xUnit + Mantis
S사의 프로젝트에서는 Confluence + Hudson + xUnit
K사에서는 DokuWiki
지금 K사의 프로젝트에서는 Trac 

매번 프로젝트마다 ALM 툴셋을 바꿔가면서 사용해보고 있습니다. 제품들을 실제 경험해봄으로써 최적의 조합을 찾기 위함입니다.

그런데, 프로젝트를 하면서 ALM을 적용하면서 깨달은것중의 하나가, ALM의 4개의 Module을 꼭 모두 적용할 필요가 없다는 것입니다. 프로세스나 사상을 기반으로 하되 프로젝트의 특성에 따라서 필요한 모듈만 사용하면 된다는 것입니다.

Issue Tracker를 이용한 Task Management의 경우, 팀의 규모가 적어도 5인 이상이 되고, 이슈가 많을 경우 즉 추적성을 많이 필요로 하고 Task에 대한 공유가 도구 없이 통제할 수 있는 범위를 벗어나는 경우에만 도입하는 것이 유리합니다. 그렇지 않을 경우 Task Logging하는 것 자체가 Burden이 될 수 있습니다. 특히나 Issue Logging에 대해서는 일정기간 개발자들이 시스템에 익숙해지는 Learning Curve에 대한 시간이 필요하기 때문에, 그 전에는 Excel 을 이용한 Scrum 방법론 기반의 팀 운영 방식이 가장 효율적입니다. 

빌드 자동화의 경우 개발이 있는 경우는 대부분 긍정적입니다. 투자되는 시간대비 효과가 좋습니다. 단 이는 개발 중심의 프로젝트인 경우입니다. EAI와 같은 솔루션 기반의 시스템 개발의 경우 코딩 보다 솔루션의 기능을 사용하는 경우가 많기 때문에 이러한 경우에는 CI의 필요성이 반감됩니다.

테스트 자동화의 경우도 마찬가지입니다. In-House 개발의 경우에는 효과가 좋습니다. 그리고 팀원이 많을수록 품질관리에 대한 요구 사항은 올라가기 마련이지만 소규모 팀의 경우 Sprint (주기)를 짧게 나눠서 Short Release를 하면서 매번 테스트를 하는 것이 단위 테스트 구현이나 테스트 자동화 보다 훨씬 효율적입니다. JUnit을 만든 Kent Beck역시 JUnit Max를 만들면서 단위테스트가 모든 프로젝트에서 필요하지 않다는 것을 언급한적이 있습니다.
 제가 제시하는 방안은 시스템에서는 몇가지 대표적인 구현 패턴이 존재합니다. 이런 패턴들을 프로젝트 초기에 Prototyping을 하고 아키텍쳐 검증이라는 이름으로 테스트를 진행해서 해당 패턴의 아키텍쳐 적인 특성을 검증합니다. 이 단계에서는 기능적인면보다는 성능,장애,안정성에 대한 비기능적 테스트를 위주로 함으로써 아키텍쳐의 위험성을 초기에 검출하여 해결안을 찾아내고 RISK를 조기에 없앱니다. 검증된 패턴에 대해서 개발자들이 찍어내기식의 개발을 하게 되는데, 이미 검증된 아키텍쳐이기 때문에, 비기능적 요건에 대해서는 테스트를 할 필요가 없고, 기능적으로 되냐 안되냐만 검증을 하면 됩니다. 필요할 경우에만 기능 위주의 단위 테스트를 적용하도록 합니다.

모든 기술과 이론은 "꼭 이래야 한다" 라는 것은 없는 것 같습니다. 상황과 조건에 따라서 적절하게 사용해야 그 효과가 극대화 되는 것 같습니다.

다음 프로젝트에서는 Polarion을 도입해서 사용해봐야 겠습니다.




저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협
태그 ALM

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/353 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009/07/03 11:32
    댓글 주소 수정/삭제 댓글
    글 잘 읽었습니다.
    상황에 맞는 최적의 조합을 찾기가 매우 어려운것 같습니다.
    지적허영심이나 과시욕에 의해 방해를 받기도 하구요..
    필요한 경우에만 단위테스트를 적용한다는 내용도 신선한 것 같습니다.
    단위테스트도 실제로 쓰다보면 과도한 부담이 되는 경우가 많거든요..
    그 필요한 경우의 시각차가 클수도 있겠지만요..
    테스트 커버리지의 범위도 생각을 해야 할 것 같습니다.
    • 2009/07/03 11:49
      댓글 주소 수정/삭제
      특히 커버러지는 Middleware같이 각각의 모듈이 기능적으로 유일한 경우에는 80% 이상 가는 것이 맞겠지만 일반적인 엔터프라이즈 애플리케이션이나 웹애플리케이션의 경우 아키텍쳐적인 특성이 대부분 동일하기 때문에 주요 업무 30~40%만 커버해도 충분하리라 생각됩니다. (사견입니다.)

요 몇일간 블로그 포스팅에 대한 고민이 있어서 몇몇 포스트들에 이런 고민들이 반영되었었습니다.
많은 분들이 댓글로 의견과 격려를 보내주셨더군요.
제 블로그 통계를 보면 대부분이 구글 검색,네이버 검색과 특히 RSS로 구독하시는 분들이 많습니다. 
 처음부터 포스팅을 시작한 이유가 몬가 댓가를 바래서 한일이 아니라 지식과 경험을 공유하자는 목적이었기 때문에 지금 처럼 쭈욱 기술 자료에 대해서 포스팅을 하겠습니다.
 제블로그를 열심히 구독해주시는 분들께 조금이나마 죄송스럽고 많은 격려에 감사하다는 말씀을 드리고 싶습니다.

 감사합니다.

저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/352 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009/07/03 11:07
    댓글 주소 수정/삭제 댓글
    항상 좋은 내용의 글 써주셔서 감사합니다..^^
    염치없지만 앞으로도 좋은 글 부탁드립니다..
  2. 2009/07/03 12:11
    댓글 주소 수정/삭제 댓글
    ^^ 항상 뒤를 따르고 있습니다. ㅡㅅ-)b 힘내십시오!! 퐈이아!!!

http://www.martinfowler.com/articles/languageWorkbench.html#ExternalDsl
By Martin Fowler
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/351 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


작년에 이어서 올해에도 한국 아키텍트 대회에 참가합니다.
REST에 대한 세션을 7/10일에 발표합니다. REST 기반의 프로젝트를 했던 경험을 기반으로 발표할 생각인데요. PPT는 제 블로그에 미리 올려놨습니다. (아래 찾아보시고.) 내용 괜찮다 싶으시면 많이 참석해주세요. 댓글 달고 오시면 같이 커피라도 한잔할 수 있는 시간 만들어 보겠습니다. :)
신청은 http://kosta.or.kr/modules/apply/post.html 하시고. 무료랍니다.

참고로 작년에 ALM에 대해서 발표했는데, 금년에는 이 ALM관련 내용이 5트랙이나 되는군요.
저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/350 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009/07/02 16:33
    댓글 주소 수정/삭제 댓글
    관심이 있어서 한번 참석해볼려고 자세한 일정을 보고 싶은데
    어떻게 신청하는 웹사이트에서 일정이 나와 있는 곳이 아무곳도 없네요..
    검색해봐도 조대협님이 가지고 계신 이 이미지 파일이 전부인가봐요..

    그림 크게 해서봐야겠군요..

제 블로그에 오시는 분들은 잘 아시겠지만.
2년동안 ALM에 대해서 많이 공부도 하고, 프로젝트에서 사용도 해보고 보안도 해서 나름대로 체계를 만들어서 블로그에 정리해서 올렸습니다. 공감해주시는 분들도 많았구요.

그래서 이 ALM을 제가 다니는 회사에서 전략 기술로 사용할 수 있도록 몇번 건의도 하고, 발표도 했습니다만, 회사에서는 별 반응이 없었습니다. 홍콩에 있는 친구가 내용을 보고 Global Consulting Program으로 만들자고 했을때도 준비하다가 결국 또 혼자 삽질 하겠구나 싶어서 블로그에만 포스팅 하였습니다.

그런데 이 ALM 프레임웍과 프로세스를 몇몇 회사에 구현 방안을 컨설팅 해주고 자료를 넘겨준 일이 있었는데, 그 회사들이 ALM 프레임웍을 실제 구현해서 아주 자알~~ 팔고.. 그리고 여기저기서 세미나도 하시더군요.

무슨 댓가를 바라고 한일도 아니고 정보를 공유하고자 한일인데...
- 내가 만든 이론들이 왜 내가 다니는 회사에서는 가치를 인정 받지 못하고 다른 회사 사람들이 열광하고 돈을 벌고 있는지..
- 이론들을 가져다가 쓰는 사람들은 IP(Interllectual Property-지적인 권리)에 대한 비용은 지불은 생각도 안했지만, 제 글에 대한 출처를 왜 공개 안하시는지...

별일아닐 수도 있지만 여러가지로 섭섭한 아침입니다.
저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협
태그 ALM

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/349 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 까오기
    2009/07/02 10:16
    댓글 주소 수정/삭제 댓글
    힘내세요 ^^
    그리고 이런 것들이 돈이 되든가 아니면 명예를 얻든가 하는 보상이 없다면 공유도 없을거 같네요.
    좋은 글 잘 봤습니다.
  2. 너부리
    2009/07/02 11:42
    댓글 주소 수정/삭제 댓글
    몸담고 있는 회사가 아니라 다른 회사에서 구현을 했다니 좀 씁쓸하기는 합니다.
    구현한 회사에서 지적권리에 대한 언급이 없었다는 점도 기운빠지게 하는 일이네요.
    지식에 대한 가치를 인정하지 않는 모습도 우습구요.

    아무튼...
    기운 내시구요.
    저를 포함, 여기오시는 많은 기술자분들을 위해 포기하지 않으셨으면 합니다.
    고맙습니다.
  3. 놀새~
    2009/07/02 12:49
    댓글 주소 수정/삭제 댓글
    흐엇~ 어디서요? 난 딱 한군데서 차장님꺼 PT했는데 조대협님꺼임이라고 했음.
    그나저나 어디서 그걸 잘 말아서 쓰고 있데요? 흐어~
    혹시 적은 내부에? 비오는데 조심해서 출퇴근해요.
  4. Nangin
    2009/07/02 13:15
    댓글 주소 수정/삭제 댓글
    에효 속 많이 상하셨겠어요.. 솔직히 이 나라에서 IP 개념 똑바로 박힌 회사가
    정말 얼마나 될까요 쩝.

    회사에서 Bottom-Up 으로 뭔가 해보기가 참 어려운 것 같아요. 조직과 프로세스에서
    좌절하기 쉽상입니다.

    그래도 블로그를 통해 쌓아오신 일들의 가치가 다른 이들에게 정말 큰 도움이 되고,
    또 그래서 정말 소중하다고 생각합니다. 화이팅 임다~
  5. 2009/07/02 13:58
    댓글 주소 수정/삭제 댓글
    항상 본인이 속한 회사에서는 그 가치를 인정받지 못하는 경우가 많은 듯 합니다. 저 또한 그런 경험 많이 하고 있고요. 최근에 인정을 해주시는 분이 있어서 지속적으로 의견개진하고 있는데 아직까지 많은 윗분들이 제대로 된 가치를 인정해주지는 않는 분위기네요.

    하지만 개인적으로 재미있게 일하고, 시도할 수 있다는 것에 만족하려고요. 힘 내시고요. 앞으로도 좋은 기회는 만들어 갈 수 있지 않을까요?
  6. 2009/07/02 22:30
    댓글 주소 수정/삭제 댓글
    얼마전 시리즈로 제 블로그에 올렸던 것들이 대학 논문자료로 쓰여졌더군요. 출처도 안남기구요. 네이버 블로그 같은 경우엔 제가 올린 글들이 출처 없이 여기저기 쓰여진 곳이 있더군요. 블랙박스 시스템에 처음으로 개발생산성 측면에서 생산성을 끌어 올렸음에도 불구하고 나중에 문서를 열어보니 다른 사람이 했다..라고 소문났더군요..
    20대때는 사람들이 잘 쓰면 좋은거라고 생각했었죠... 하지만 정작 지금에 와서 저한테 남는게 무엇인가?.. 라는 의문이 들더군요.
    아직 현실에선 유의식이 부족한 것이 사실입니다. 그래서 지금은 태도를 달리하고 있습니다. 전
  7. 2009/07/03 12:14
    댓글 주소 수정/삭제 댓글
    여전히 우리나라사람들에게는 무의식적인 펌습관이 있기 때문인 듯 하군요.

    후우우웅. 힘내세요. ^^

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



REST Ovewview
View more documents from Byungwook.
저작자 표시
이올린에 북마크하기(0) 이올린에 추천하기(0)
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 조대협

트랙백 보낼 주소 :: http://bcho.tistory.com/trackback/348 관련글 쓰기

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

◀ PREV : [1] : [2] : [3] : [4] : [5] : ... [33] : NEXT ▶

BLOG main image
평범하게 살고 싶은 월급쟁이 by 조대협

공지사항

카테고리

분류 전체보기 (327)
IT 이야기 (19)
사는 이야기 (78)
ALM (98)
솔루션 (29)
Architecture & 방법론 (37)
IT와사람 (1)
성능과 튜닝 (16)
프로그래밍 (29)