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

adsense(728_90)


Bea의 AquaLogic Enterprise

AquaLogic 제품을 다운받아 설치하여 이것저것 만지작 만지작 거려보았다.
이 제품은 기업이 SOA환경에 적응할 때 필요한 플랫폼으로서 현재까지는 ESB와 Data 변환 및 서비스를 시켜주는 제품이 나왔고 이에 더하여 프로세스 관리 부분은 차후에 나올 예정으로 보인다. ESB는 Service Bus라는 이름의 제품으로 나왔는데 WebLogic 9 기반이었으며 데이터 변환 및 서비스화하는 것은 Data Service Platform이라는 이름으로 WebLogic 8.1과 Workshop 2(?)기반으로 나왔다. 굳이 웹로직 8.1기반이 된 것은 일단 데이터 변환 등의 작업이 아직 새로 출시된 Workshop 3에서는 아직까지 가능하지 않기 때문인 것으로 보인다.
일단 가장 관심있게 보게 된 제품은 Data Service Platform이다. 이것은 Bea와 IBM이 공동으로 스펙 작업에 참여한 SDO 기술을 기반으로 만든 것으로서 모든 데이터 리소스들을 동일한 인터페이스에서 제어하기 위해 만들어진 스펙이며 이 SDO 스펙을 기반으로 하여 보다 편하고 어떠한 프로그래밍 로직없이도 관리하고 이것들에 대한 서비스화를 자동으로 작성할 수 있게 한 것이 AquaLogic Data Service Platform이라 하겠다. IBM의 WebSphere Integration Developer(WID)와 비교될 수 있는 이 제품은 일단 기능은 차치하고라도 그 가벼움이 맘에 들었다. 일단 SOAESB가 제대로 기업 내에서 적용되기 위해서 가장 필요한 기능 중의 하나가 기존 자원들에 대한 서비스화이고 이것들에 대한 자동화된, 일체의 코딩이 없이 이루어질 수 있게 하는 환경이라 했을 때 Bea가 이 Data Service Platform(DSP)을 전면에 내세우고 있는 점은 충분히 공감할 만한 마케팅 전략이라 생각한다.
반면에 ESB 구현물인 AquaLogic Service Bus의 경우 아직 자료도 뭔가 부실하고 새로 출시된 Workshop 3 역시 뭔가 나사하나쯤은 빠진 듯한 느낌이 든다. 관리 화면이 이쁜 것은 마음에 들지만... 일단 좀 더 파헤쳐봐야겠다.

공유하기 버튼

 

My New PDA Art and Life


I bought a Palm PDA from used market,Yesterday. um? sigh, yes yes. The 뽐뿌 God win from me. But I spent little money because I sold my equipments that my old pda and mp3 player. My new pda is a Palm Tungsten 3. It can be not only a PIMs but for MP3 player, eBook, Movie player, news paper and dictionary. It can synchronize with Lotus notes that is used from my company. And It is also very slim like a tabacco case. So It's a thing of beauty for me.

공유하기 버튼

 

한페이지 단편소설 Art and Life


It's a cool site for new generation's writers.

공유하기 버튼

 

기자들이 좋아하는 필자 Art and Life

OOOOOOOO: 계세요?
OOOOOOOO: 대상: 중고등학생
OOOOOOOO: 주제: 인생에 도움이 될만한, 선배로서의 조언
OOOOOOOO: 마감 임박, 펑크
OOOOOOOO: .....
calmglow: 뭡니까?
calmglow: 저한테 말씀하신 것이에요?
--------------------------------------
주말 오후 새로 산 PDA(결국 지름신은 나를 이겼다 -O-)를 만지작 거리면서 보내는 중에 난데없이 메신저를 통해서 메시지를 받았다. 비록 가끔 잡지에 IT관련 기사를 쓰기도 하고 때론 마감이 임박한 기자의 요구에 없는 글감 짜내며 써본 적이 없지는 않으나 이것은 내 전문이 아니지 않은가? 더구나 중고등학생이라니...
나는 조금 황당함을 감추지 못하고 퉁명한 자세로 그 기사는 쓸 수 없다는 둥, 나는 그들과 같은 길 위에 있는 사람인데 그들에게 무슨 말을 해줄 수 있는가 길 끝에 있을만한 사람에게 부탁하라는 말로 갈 길 바쁜 기자의 요청을 사양하고 말았다.
기자들이 매체에 글을 채울 때 그들이 원하는 것은 Writer의 글이지 어느 누구의 글은 아니다. 그 글이 매체에 어울리고 충분히 독자의 주의를 끌만한 글이면 되는 것이다. 사실 그런 면에서 아무리 기자가 바빴다고는 해도 그러한 글을 쓸 수 있는 사람 중의 하나가 나였다는 것만으로도 일단은 그 기자에게 충분한 감사의 변을 보내주었어야만 했으나 그러지 못하고 그저 도망쳐버리듯 기자에게 등을 돌렸다는 것이 죄송하다.
잡지사 기자분들이 좋아하는 필자들은 대박을 터뜨릴만한 기사를 써주는 이라고 생각할지도 모르겠으나 사실 기자분들이 가장 좋아하는 필자는 어떤 까다로운, 게다가 아무리 사소한 주제와 내용이라할 지라도 무리없이 써줄 수 있는 만능의 Writer이다. 따라서 그것은 특정 영역의 고도로 전문화된 사람이 아니어도 깊은 생각과 풍부한 글감으로 무장한 Writer이다. 때때로 그러한 Writer로서의 자질을 과연 내가 키워서 촉망받는(?) 제2의 직업으로서의 POP Writer가 될 수 있을런지에 대해 고민해본다. 하지만 이번 등돌린 사건으로 생각해보건대 그러한 자질.. 내게는 없어보인다.

공유하기 버튼

 

Nostalgia with ex-team Art and Life

The facts are the facts. I've been honest with me. JStorm is not as meaningfully as it used to be for me. That took it well. The truth is a thing of beauty. Deep attachment for past team is not my gift.

공유하기 버튼

 

SOA의 기본 원칙들 Enterprise

  1. Loose-coupling - every service is atomic, self-describing, accessible, declarative, stateless and composite
  2. Contracted - All services in an SOA are represented by a contract that describes its inputs, outputs, access policies, QoS requirements and error handling procedures
  3. Manageable - all services can be individually managed or managed as a group
  4. Versioned - multiple versions of the same service should be able to co-exist to maintain backward compatibility in a changing environment
  5. Discoverable - services should be able to be discoverable at time of execution.
  6. Addressable - A service should be able to be uniquely identified in a network
  7. Distributed - Services in an SOA are separated by geographic and machine boundaries and, therefore, must be good netizen applications. That is, they must be developed with the ability to recover from loss of communications.
  8. Point-to-Point - At any point in time one consumer uses one and only one producer
from the Abstract Thought

공유하기 버튼

 

한 사람에게 전략과 전술을 다 기대하는 것이 옳은가? IT

JP Morgenthal의 블로그 (http://www.avorcor.com/morgenthal/index.php?entry=entry051106-125114)에서 그의 포스트를 읽으면서 동감 백표를 해보았다.

EA(Enterprise Architect)들의 역할은 과연 무엇일까? 우리는 그들에게 IT 기술 전반에 걸친 폭넓은 지식과 경험을 기대하고 적어도 하나의 도메인 분야에서만큼은 매우 전문가적인 수준의 관점과 견해를 기대한다. 내가 알고 있기로도 EA에게 우리가 기대하는 것은 단순한 구현 기술이 아닌, 넓고 깊게 볼 수 있는 안목이며 한 기업이 방향설정 하는 데 있어 전략을 세울 수있는 토대를 제시하는 것이 바로 EA의 역할이라 할 수 있다.

JP는 해당 포스트에서 EA가 때로는 지나친 세부적인 전술에 대한 참여로 인하여 오히려 EA에게 큰 안목을 기를 수 있게 하는 기회를 빼앗게 하고 있는 것은 아닌가 하며 우려하고 있다. 때로 대단한 천재의 경우 전략가이면서 전술가를 기대할 수 있겠지만 보통의 경우는 최고의 전략가와 최고의 전술가는 별개의 영역인 것이다.
그러나 곰곰히 생각해보면 JP는 EA를 너무 추상화시켜놓은 것이 아닌가 한다. 어떤 고객에 대한 컨설팅에서도 단 한명의 EA가 담당하는 경우는 없다. 기업의 Value와 전략을 제시하는 데에는 Analyst가 주로 담당하며 그 분석결과를 바탕으로 여러 전문 아키텍트가 각각의 분야를 담당하여 전략과 전술을 만들어가는 것이다. 물론 JP가 언급한 부분이 일부 문제를 일으키는 경우는 적지 않지만 때로 개념을 너무 추상화할때 놓치는 것이 있다는 생각을 해본다. 따라서 제목은 '한 사람에게 전략과 전술을 다 기대하는가?'에서 '한 조직에게 전략과 전술을 다 기대하는가?'라고 바꿔야하며, 당연히 EA 조직은 고객의 전략과 전술에 대한 기대를 충족시켜줄 수 있어야 하는 것이다.


공유하기 버튼

 

이전 41 42 43 44 45 46 47 48 49 50 다음


Google Analytics