Properties Editor
2009년 9월 10일 목요일
2009년 9월 8일 화요일
2009년 9월 1일 화요일
PMI : Privilege Management Infrastructure
PMI의 정의
- 권한 관련 자원과 이의 소유자간의 관계를 신뢰기관이 보증하고 유지하는 구조. PMI에서 사용되는 인증서를 가리켜 PMI 인증서 또는 속성 인증서(AC: attribute certificate)라 칭함.
PMI의 등장배경
- 임무, 지위 역할 등의 다양한 속성을 인증하기 어려운 PKI의 한계
- X.509 인증서의 확장 필드를 이용하여 PKI 체계 내에 표현은 가능하나, 일반적으로 신원과 속성은 유효기간이 달라지기 마련. 또한 공개키 인증서 발급 기관과 속성 관리 기관은 일반적으로 다름.
- 권한 관련 자원과 이의 소유자간의 관계를 신뢰기관이 보증하고 유지하는 구조. PMI에서 사용되는 인증서를 가리켜 PMI 인증서 또는 속성 인증서(AC: attribute certificate)라 칭함.
PMI의 등장배경
- 임무, 지위 역할 등의 다양한 속성을 인증하기 어려운 PKI의 한계
- X.509 인증서의 확장 필드를 이용하여 PKI 체계 내에 표현은 가능하나, 일반적으로 신원과 속성은 유효기간이 달라지기 마련. 또한 공개키 인증서 발급 기관과 속성 관리 기관은 일반적으로 다름.
reference
PMI: Privilege Management Infrastructure 개요. (주) 퓨쳐시스템 강명희
2009년 8월 28일 금요일
Errors exist in required project(s)
이클립스에서 java source를 실행하면서 위와 같은 에러를 경험해 보고
바로 네이버에 질의를 했다거나 구글링 했다면 좀 반성해야 할것이다.
직역 하면 프로젝트 내에서 에러가 존재하는데 실행을 계속 할 것이냐고 묻는 것이다.
실행하려는 소스가 아닌 소스가 속한 프로젝트내에서 에러가 존재할때 경고 메시지가 발생한다.
고로 해당 프로젝트 내의 오류사항을 수정하면 경고메시지는 발생하지 않을 것이다.
물론 부끄럽게도 난 이미 반성하고 있다.
eclipse 구동시 JVM terminated 오류
eclipse 구동시 아래의
혹은
와 같은 메시지를 출력하면서 eclipse 자체가 종료한다던가 정상 작동하지 않는 경우가 있다.
이럴 경우
eclipse.ini 파일을 열어 파일 내 최상단에 아래 옵션을 추가해준다.
-vm
C:\자바 설치경로\bin\javaw.exe
2009년 8월 26일 수요일
EAI(Enterprise Application Integration) 란?
EAI는 기업의 시스템들끼리의 커뮤니케이션을 위한 미들웨어입니다.
이종(다른) 시스템들 사이에 위치하여 스위치허브처럼 각 시스템간의 필요한 정보를 서로
소통하여 관리의 효율성을 증대 시킬수 있죠. 이부분을 통합이라고도 부르는데 이유는
이종시스템들이 연결되어 전체적으로 하나의 흐름처럼 움직이게 한다는 거죠..
간단히 예를들면 프랑스인 요리사와 중국인 매니저와 일본인 서빙도우미를 고용한 한 대형 레스토랑이 운영되려고 합니다. 각사람이 각자의 업무는 일류라고 해서 데리고 온사람들입니다.
그런데 서로 말이 안통하고 뭐하려면 답이 안나옵니다. 그리하여 통역을 뽑는데 한국말, 프랑스어, 중국어, 일어이렇게 하는사람이 있으면 무지 좋겠으나,
그게 안되니 한국어와 불어, 한국어와 중국어, 한국어와 일어이렇게 하는 사람을 구하는것이나 한국어와 불어와 영어, 영어와 중국어, 영어와 일본어 이런사람을 구해서 각각의 사이에 넣으니 일단 레스토랑은 영업이 가능하나 효율적인 영업을 위한 재료준비, 홀준비, 또는 사람별 요구사항들을 보고 받거나 할 일을 지시하려면 죽겠는 거죠...
차라리 월급을 한국어까지 4개국어 하는 사람을 하나 구하여 2명의 월급을 몰빵으로 줘도 통역여러명 구해서 일하는것보다 낫다고 생각되는 거죠..왜냐..한명만 이해시키면 다른 세명은 그 한명이 이해시킬테니까...
뭐 이런 식의 비유가 그나마 이해하기 쉬운 비유일겁니다..
하나의 시스템이 회사에서 필요한 모든 부분을 커버할 수는 없으니까, 각 부분별로 회사에 맞는 시스템을 도입하고, 도입했거나 또는 하려는 시스템간의 필요한 부분의 정보를 서로 교류하도록 엮는 거죠.
또는 시스템의 부족한 부분을 커버하기위해서 시스템을 통째로 바꾸는 것보다 필요한 부분에 맞는 시스템을 도입하여 관련된 정보를 시스템에서 정의된대로 가공하고, 인터페이스를 EAI 서버와 연결하면 사용자(사내외 직원,관계사)는 이전대로의 시스템 작업을 하더라도 미리 정의된 방식으로 정보가 가공되어 새로 도입된 시스템과 연계할 수 있고, 꼭 필요한 사용자만 교육을 시킴으로써 전체를 바꾸고 모든 사용자를 재교육 시키기 위한 시간과 학습의 오류에서 오는 처리비용과 회계상 비용을 절감할 수 있죠
EAI의 기본구조는
{A시스템} <-- 아답터for A --> EAI서버(정의된 방식으로 데이터 가공) <-- 아답터for B --> {B시스템}
로써 A, B, C, D ~~ 필요한 시스템수까지 네트워크(또는 물리적 서버)로 연결되는 구조입니다.
각 아답터별 셋팅작업,
데이터 가공에 관한 정의와 프로세스 작업,
각각의 커뮤니케이션의 문제나 업무상의 필요에 의하여 담당자에게 현재의 상태를 알려주는 기능,
업무상의 에러가 발생했을때 어떻게 할것인가에 관한 정의및 작업.
처리한 내용에 관한 백업작업.
위의 작업이 EAI 미들웨어의 도입 셋팅과정이죠.
그러나 실무를 하다보면 한계에 부딪히는 경우가 많습니다.
첫째 : 사람들은 EAI 미들웨어가 모든 처리를 다 한다는 착각에서 오는 어려움.
네트워크 문제...또는 시스템의 정책상 문제는 EAI로 해결되는것이 아니죠...
둘째 : 각 회사의 시스템관리자 특히 인하우스(inhouse, 회사의 필요에 의해 제작한 시스템)시스템의 경우
시스템을 정확히 알고 있는 사람이 없는 경우가 많다. (구조조정내지 회사가 어려울시 많이들 내보내죠)
이부분은 인수인계를 받은 사람이나 해준사람이나 사람이다 보니까 아무리 문서를 잘해놔도 항상 생기는
부분이죠
셋째 : 세계적인 ERP 회사 제품들이 미리 정의한 업무방식(Business Logic 또는 정책) 도 우리나라의 실정과는
다르기 때문에 발생하는 문제.
흔히들 말하는 커스터마이징을 통하여 현재 프로세스에 맞게 시스템을 변경시킨경우 개발자 또는
담당자가 있더라도 차기에 업그레이드 부분에서 발생되는 문제를 미리 대비하기가 힘들기 때문에 발생하
는 예기치 못한 상황들입니다.
예로 들면 SAP의 경우 미들웨어를 파트너로 등록시키고 IDOC 메세지를 통하여 커뮤니케이션을 하면
SAP 시스템의 차후 업그레이드 작업을 하더라도 계속 middle웨어와의 커뮤니케이션을 지속할 수 있습니다.
하지만 그부분을 ABAP으로 해결하면 SAP 시스템의 업그레이드 시 해당 개발자/컨설턴트를 없이는
작업이 무지 힘듭니다. 그리고 ABAP으로 커스터마이징한 부분이 SAP 시스템상의 연결된 로직에
완벽히 들어맞는다는 보장도 없죠 (이부분은 제가 예전에 현업에 있을때 독일의 SEEBURGER사에 출장가서
담당과 직접 대화하면서 들은 어려움중의 하나죠).
넷째 : 아답터의 부재에 따른 어려움..
각 시스템과 연결시 어떤 시스템인지 또는 받은 데이터가 누구한테서 온건지, 어디로 보낼건지를 셋팅하기
위한 인터페이스 부분 다시말해 아답터 부분의 부재가 한계입니다. 이 부분은 주로 메세지로 대처를 하기
는 합니다.
아답터의 문제에 비교하면 데이터의 가공(필요한 부분을 미리 정의된 값으로 채우거나 빼거나 이동시키거나
대체 값을 넣는것)은 별 어려움도 아닙니다.
아답터를 잘 정의하고 셋팅을 하는것이 EAI의 핵심부분이고 경쟁력이죠.
2000년대 초반에 국내기술로는 EAI 엔진은 만들어도 아답터를 제공하는 업체는 없었습니다. 그리고 아답터
를 통해서 데이터가 오가는 것보다는 직접DB에 엑세스를 하는것을 위주로 했기때문에 개발 당시는 많이들
포기했으나 시스템들이 점점 발전될수록 외부와의 DB 접근을 차단하고 미리 정의된 방식으로 접근을 유도함
에 따라 이것이 앞으로의 경쟁력이 될 수 밖에 없죠..
네이버 지식인 펌
피드 구독하기:
글 (Atom)