건희아범의 지속가능한 삽질

문) CBD방법론
답)
  1. 컴포넌트 재사용을 통한 생산성 향상 CBD방법론
    가. CBD(Component Based Development)방법론의 정의
      - 컴포넌트의 개발 및 기존 컴포넌트의 재사용을 통해 조립하여 소프트웨어를
        개발하는 방법론
    나. 특징
      - 정의된 인터페이스 단위의 조립을 통한 개발(Black-Box framework)
      - 아키텍처 중심 재사용 개발 방법론 : 기반 아키텍처 없이는 공용컴포넌트 개발 불가
      - 반복점진적 개발프로세스 제공 : 일련의 반복을 통해 개별위험 식별/제거
  2. CBD방법론의 특성
    가. CBD방법론의 장점
      - 생산성 : 부품조립을 통해 SW개발기간 단축, Plug&Play
      - 변경용이성 : 요구사항 수용에 신속/안정적 변경지원, Time To Market
      - 재사용성 : 바이너리 기반의 재사용 및 컴포넌트 대체 용이
      - 관리용이성 : 독립적인 컴포넌트 단위로 복잡성 최소화, 장애의 Locality
      - 기술집약성 : 기술숙련에 대한 검증, 아키텍처, 프레임워크, 분산 기술 등
    나. CBD 방법론의 종류
구분  |  RUP                            | Catalysis                 | 마르미III       |
정의  | 대규모프로젝트의 포괄적 F/W     | UML표기법개발 CBD방법론   | 한국형 CBD기반 표준방법론|
목적  | 계획/범위 내에서 고품질 SW/개발 | 개방적 분산시스템 모델링 및 구축 | 체계적 컴포넌트 개발관리절차 확립|
재사용| SW컴포넌트                      | 모든산출물(F/W)           | 모든산출물(재사용컴포넌트)
모델링| UML                             | UML기반 다소 변경         | UML, PERT/CPM, 간트차트
  3. 향후 전망
    가.컴포넌트를 넘어 아키텍처 기반의 재사용(MDA/MDD), 제품라인(Product Line)에 의한
       재사용으로 발전예상
    나. Business Architecture, SW Architecture등의 영역별 세분화, 전문화 진행
    3. Web서비스의 출현 이후 비지니스 컴포넌트의 진화예상. "끝"

----추가 -----------
    *. 컴포넌트 구조와 객체지향 모듈과의 차이점
구분                  객체지향모듈                    컴포넌트
재사용방식/플랫폼 | 주로소스기반/동일Compiler기반 | Binary code기반/이종Compiler수용
상속성/접근방법   | 상속허용/객체지향언어 | 상속불가/모든언어대상
종속성/서비스제공 | 구현기술종속/타모듈결합필요 | 구현기술에 독립적/독자적 가능

문) 요구공학
답)
  1. 요구사항 검증을 통한 SW위기의 해결 요구공학
    가. 요구공학(Requirement Engineering) 의 정의
      - 초기 개발 요구사항 및 이후 상세요구사항들이 설계와 구현 단계에서 제대로
        지켜지고 있는지 검증하는 기법
    나. 요구사항의 특성
      1) 정확성 : 명확화된 요구사항이 실제 구현시 필요한 것인지 알수 있게 정확해야함
      2) 명확성 : 여러가지가 아니라 단 한가지로 해석되어야 함, 프로토타이핑으로 해결가능
      3) 완전성 : 시스템 구현에 필요한 모든 것이 표현되어야 함
      4) 일관성 : 요구사항들 간의 충돌이 없어야 함
      5) 수정용이성 : 구조와 스타일에 일관성유지, 요구사항 변경 용이
      6) 추적성 : 요구사항들간 유기적 연결, 산출물이 각 단계와 mapping 되어야 함.
                  RTM(Requirements Traceability Matrix) - 순방향, 역방향 검색
  2. 요구공학 구성 및 절차
    가. 요구공학 구성
      - 도구 : 요구사항 요청, 영향분석, 변경수행, 배포 등의 자동화도구
      - 프로세스 : 요구사항 관리를 수행하기 위한 절차와 방법
      - 방법론 : 요구사항 추출,분석,정의,검증,관리의 각단계룰 정의한 정형화된 방법
    나. 요구공학 절차
      1) 추출 : 문제를 이해하고, 요구사항 추출
      2) 분석 : 추출된 요구사항을 분석하여 요구사항을 구조화하고, 각종 대안을 결정
      3) 정의 : 시스템이 무엇을 해야하는지를 기술, 분석된 요구사항을 명세화(명확성,
           완전성,검증가능성,일관성,수정용이성, 추적가능성,개발후 이용성)
      4) 검증 : 문제를 기술하고, 상이부분의 일치여부를 확인, (Review,Work-Through,Inspection)
      5) 관리 : 요구사항에 대한 최종결정 및 Baseline관리, 변경통제 및 확인기능
  3. 정형명세 기법과 비정형 명세기법 비교
    구분 |            정형명세      |        비정형명세
    -------------------------------------------------------
    기법 |      수학적기반/모델기반 |  상태/기능/객체중심
    종류 |      Larch,OBJ/Z,UDM,CSP |  FISM/Decision Table/SADT
    장점 | 시스템요구특성정확,명세간결,명세/구현의 일치성| 명세작성/이해용이, 의사전달방법 다양성
    단점 | 수학적이해, 이해관계자 부담| 불충분한 명세 가능, 모호성

------- 추가분--------
 **. 요구사항 분석의 문제점과 해결방안
    가. 요구사항 검증을 위한 V&V : 프로젝트 SDLC개발단계의 Verification(검증)과
        Test 단계의 Validation을 통한 검증 필요
    나. 요구사항 해결책에 대한 비문서화된 경험을 형식화한 Repository 관리, 업무 전문가
        양성계획 수립 및 프로젝트 참여로 제품품질 향상 기여."끝"

    *. 프레임워크 개요도 - 구성요소에 해당내용이 설명되어 1교시에서는 제외
        (추출/분석/정의/검증/관리 해당 구조도 첨부)

    *. 요구사항 분석이 어려운 이유
      1) 문제영역에 대한 명확한 이해부족 : 개발자의 도메인 이해부족으로 요구사항
         이 불명확하게 작성
      2) 참여자 사이의 이해문제 : 참여자들의 Role에 따라 서로다른 관점으로
         표현하고 분석함으로써, 같은 내용에 대해 충돌 또는 불명확성 발생
      3) 의사소통에 대한 문제 : 공동작업 중 충분한 의견교환이 없어 문제 발생
      4) 요구사항의변경 : 사용자의 변경요구, 습득된 지식 및 환경변화에 따른 변경

    * 요구사항 명세시 고려사항
      1) 기술적 내용과 제약조건은 언급하지 않는다. (외부 Entity 관점)
      2) 명세화 이전 자료에 기반두어 작성한다. - RFP, 제안서, 상위 요구사항
      3) 비기능적 요구사항도 모두 포함 작성
      4) 사용자별 중요도 및 난이도 고려하여 우선순위 정의.
         - 중요도 및 난이도는 어떤 기준으로 산정하는가?? 고민해볼것.
         - 중요도 난이도 구한 후에는 우선순위는 무엇으로 정하는가. - 중요도/난이도 차트?

    * 요구사항 명세서의 이해관계자별 목적
      1) 사용자측면 : 요구사항정의, 정의된 요구사항의 적용 및 추적성, 의사소통,
            프로젝트 품질, 납기기준 (특징:친숙한 용어사용베이스라인 제공, 연결)
      2) 개발자측면 : 사용자와의 의사소통 창구역할 수행(JRP), 프로젝트 목적에
            맞는 설계,개발 진행 (특징:정형화된 형식, 정량화,측정가능한 가치제공)
      3) PM측면 : 프로젝트 관리기준(일정, 비용, 품질), 프로젝트 범위에 대한 기준
           및 수용가능성 (특징:요구사항추적매트릭스-요구사항 관리)

  *. 요구사항 유형 분류를 위한 FURPS+ 모델
     가. FURPS : 기능성,편의성,신뢰성,성능, 지원성
     나. "+" : 구현성, 연계성, 운영성, 합법성. "끝".

문) UML과 JAVA코드변환
답)
  1. UML의 개요
    가. UML(Unified Modeling Language)의 정의
      - OMG에서 객체모델링기술과 방법론을 표기한 표준화 모델링 언어로서 모델링을 위한 Notation을 말함
    나. UML의 구성요소
      1) 사물(Things) : 추상적 개념으로서 모델구성의 기본요소
      2) 관계(Relations) : 사물간의 의미있는 연결, 객체들 간 대화경로, 데이터 흐름아닌 메시지통로, 의존,연관,일반,실체화
      3) 도식(Diagram) : 사물과 관계를 각종 도식으로 표기
  2. UML의 4가지관계와 JAVA코드변환
    가. UML의 4가지관계
      - 의존관계 : 독립사물의 변화가 종속사물에 영향끼침
      - 연관관계 : Has-a 관계, 모델요소간 링크를 설명하는 구조적관계
      - 일반화관계 : 상속(Inheritance)의 관계, 한클래스가 다른 클래스를 포함
      - 실체화관계 : 구현(Implement)의 관계, 필요한 인터페이스를 구현
    나. JAVA 코드변환
      1) 의존관계  =>   코드변환        
         Diagram  class A {              
                  public void getB(B pB) {
                  {.....}
                  }
                  class B {.....}
      2) 연관관계  =>   코드변환        
         Diagram  class A {
                   public B[] B;}
                  class B {
                   public A a;}
      3) 일반화관계 =>   코드변환
         Diagram  class A{}
                  class B extends A {...}
      4) 실체화관계 =>  코드변환
         Diagram  interface A{}
                  class B implements A {..}
  3. UML의 JAVA 변환시 고려사항
    가. 사용자 : Business Process, 요구사항 구체적 도출
    나. 분석자 : 코드변환의 용이성 위해 모델링 용어 통일, 표기법 점검
    다. 개발자 : CASE Tool 기반으로 이해쉽도록 주석 활용코딩, 임의로 생성 탬플릿
        변경없도록 유의."끝"

거짓말로 쓴것, 애플리케이션 프레임워크라는 주제를 놓고
아는것과 검색한 것을 짜집기 하다가 포기함.
그냥 답안 복사를 해야하나..
----------------
문) 애플리케이션 프레임워크
답)
 1. 애플리케이션 프레임워크 개요
   가. 애플케이션프레임워크(Application Framework)의 정의
      -  기본적인 아키텍처와 공통 모듈을 제공하면서
         별도의 추가 모듈 구현이 가능한 컴포넌트 및 툴들의 집합
   나. 애플리케이션 프레임워크의 특징
      - 확장성 (extensibility) : 프레임워크의 기본기능에 선택적인 overriding을
        통해 기능을 확장 할 수 있다.
      - 수정불가코드 (non-modifiable framework code) : 프레임워크의 코드는
        기본적으로 변동될수 없다.

  2. 애플리케이션 프레임워크의 구조
   가. 애플리케이션 프레임워크의 구조
      - Run Tier, JobTier, Application Tier, Data Tier : Spring
      - 채널, 비지니스, 데이터 Tier : 프로프레임
      - 개발환경, 실행환경, 관리환경, 운영환경
  

문) BRE
답)
  1. 신속한 Time to Market 실현을 위한 BRE의 이해
    가. BRE(Business Rule Engine)의 정의
      - 비지니스 유연성과 경쟁력 강화를 위하여 비지니스룰을 정리하고 자동화를
        수행할 수 있는 BPM의 핵심요소
    나. BRE의 주요기능
      - GUI기반 개발도구 : 설계,개발,시험,검증,배포의 전과정 처리가능
      - Rule 표현언어 : 비지니스 Rule 표현언어 제공 (SRL:Structured Rule Language)
      - 지원도구제공 : 디버깅, 분석, Rule 추적도구 제공
      - 자동 Rule분석 : Rule 타장성, 일관성, 무결성 테스트 및 자동보고서 생성
      - Rule 시뮬레이션 지원 : Question Set에 의한 질의 및 Rule 처리결과 출력
  2. BRE 구성요소 및 비지니스 프로세스 개선기술 비교
    가. BRE의 구성요소
      - Rule Base : 기업내 모든 비지니스 룰에 대한 저장소
      - Rule Engine : 비지니스 룰 검색 및 처리기능 수행
      - 추론 알고리즘 : 최적화 된 업무처리를 위한 알고리즘
    나. 비지니스 프로세스 개선기술 비교
       |        | BPM                           | BAM             | BRE         |
       |특성    | 핵심프로세스개선              | 실시간모니터링  | 실시간Rule관리|
       |정보유형| 프로세스 모델                 | Activity상태/KPI| 비지니스룰  |
   |비지니스목적|고객지향EndToEnd프로세스 통합, 관리|민첩성위험파악|비지니스융통성,적시성|
  3. BRE기대효과 및 활용분야
    가. 비지니스 측면 : 다변화 비지니스 환경 신속한 대처 및 대응력 향상
    나. IT측면 : 생산성 향상 및 비용절감
    다. 자금세탁방지 등 각종금융사기방지, 보험 개발 및 여신관리, 방카슈랑스."끝"

  * 추가활용분야
    가. 금융상품매매 : 우수고객별 이자율 계산 Rule 정의 이자율은 Dynamic하게 적용
    나. TMS : 위험관리시스템에서 위험룰셋을 모든 위험관리시스템에 전파
    다. e-CRM : 개인화 서비스를 위한 Click&Stream 기반의 One Stop Service
    라. u-교통 : GPS기반의 사용자 운전패턴분석을 통한 10대 위험운전행위 분석

문) SOA
답)
  1. 서비스 단위 재사용 위한 SOA개요
    가. SOA(Service Oriented Architecture)의 정의
      - 소프트웨어를 기업의 프로세스 관점에서 공유와 재사용이 가능한 "서비스"
        단위로 개발하는 아키텍쳐
    나. SOA의 특징
      - Reuse : 논리적 재사용단위인 SOA Service Block 구성
      - Integration : 표준 Interface (XML, SOAP, WSDL) 통한 통합
      - Agility : 서비스단위 조립을 통한 민첩성 제공
  2. SOA구축 방법론 및 관련 정보기술
    가. SOA 방법론
      1) SOA 전략수립 : 고객사현황분석, 요구사항 정의, SOA목표및 전략수립
      2) Biz 프로세스 수립 : Biz 프로세스 분석, 현행 App 분석
      3) 서비스 정의 : 서비스 식별, 서비스 명세화, 서비스 구현 분석
      4) 시스템 분석/설계 : Use Case Modeling, Component Modeling, Service Orchestration
      5) SW 아키텍쳐 : SW 아키텍쳐 설계, 프레임웍 개발
      6) SOA 거버넌스 수립 : 서비스 관리계획 수립
    나. SOA 관련 정보기술
      - BPM : Biz Process 모델링(BPMN), 시뮬레이션, 최적화, BPEL, BAM, BRE
      - ESB : 분산, 지능형 버스, 유연성(Loosely Coupled), 상호운영성, Open Standard
      - EII : Data Hub, Metadata, App-Data 독립성, 가상화
      - 웹서비스 : SOAP over HTTP(S), WSDL, UDDI, XML
  3. SOA 기대효과 및 문제점
    가. 기업 내외 애플리케이션간 통합, 유연성,확장성,가용성 보장
    나. 성공적인 SOA방법론 적용사례 및 전문가 부족, 지속적 교육/경험축적 필요
    다. 전자정부 프로젝트 등 적용범위 확대에 따른 서비스품질평가 기준마련 필요
    라. ITA/ISP통한 로드맵 구축으로 과다/중복 구축비용 지출 절감필요."끝"

  1. MCI의 정의 및 추진배경
    가. MCI (Multi Channel Integration)의 정의
      - 영업점 창구, 자동화기기(CD/ATM), 인터넷, 콜센터의 4대고객접점정보를 통합,
        채널운영비용 절감 및 고객에서 맞춤형 개인화서비스를 지원하기 위한 솔루션
    나. MCI의 추진배경
      - 대외채널 증가, 다양한 채널, 관리통제가 어려움
      - 서비스중복에 따른 비용 증대 발생
  2. MCI의 주요기능 및 구성요소
    가. MCI 주요기능
      - 채널통합 : 4대고객접점 통합
      - 전사통합서비스 : Host Interface, Package, Application Interface, Multi Protocol
      - 외부통합서비스 : B2B
      - 고객정보의 단일view제공
    나. MCI 구성요소
     창구          Channel               *Channel Common                   정보계
     인터넷    <=> Specific  <=> ESB <=>  Layer                <=> ESB <=> 계정계
     콜센터        Layer                 *Business Transaction               ..
     자동화기기                           Layer
     <-고객접점-><----------------Channel Integration Layer ------------><-Backend->
      - 고객접점 : 영업점, 자동화기기, 인터넷, 콜센터
      - Channel Integration Layer : 채널통합관리
      - Business Transaction Layer : 멀티채널 트랜잭션 관리
      - Channel Common Layer : 공통 비지니스 수행
  3. MCI 기대효과 및 현황
    가. 채널비용감소 : 신규채널 증가 및 기존채널 관리 비용 감소
    나. 전략적 프로젝트 : 맞춤형서비스, 신규채널 증가 대응, 복합상품판매와 같이
        상품 및 서비스 체계 구현, Cross Sale 및 Up Sale의 기회제공
    다. 고객지향 역량 : 고객지향 채널 확보와 프로세스 통합수행
    라. 유연성 우수하나 고성능 Transaction 지원이 어렵고, 특정채널별 비지니스 발
        생시 관리포인트 증가 우려 ex) 스마트폰 특판 예금등."끝"
     *. 통합기술간 비교
     항목                MCI                 ESB                  EIP
     ----------------------------------------------------------------------------
     목적        고객채널 통합      서비스,App수평수직적통합  기업 내외부정보 통합
     정보종류    내부정보           내부정보                  내외부정보
     접근방법    Back-Office 솔루션 Back-Office 솔루션        Front-Office 솔루션
     주요기술    ESB/EAI            Web-Service,              SSO,Ajax, SSL
                                    Message Routing

ISP (Infomation Strategy Planning) : 정보화 전략 계획
2. 계획 순서도
  가. 환경분석
    1) 경영환경
        - 외부환경분석 : 기회/위험 분석
        - 내부환경분석 : 강점/약점 분석
        - 경영환경분석을 위해 4가지요소를 통합하여 SWOT 분석을 한다.
---------------------------------------------------------
               |       기회                       |  위험
---------------------------------------------------------
   강점     |                                     |
---------------------------------------------------------
   약점     |                                     |
---------------------------------------------------------
    2) 정보화환경
        - IT트랜드 정리
        - 적용가능한 기술 개략 선별(이미 인터뷰가 선행되어 있음)
  나. AS IS -분석
    1) Business Process 분석
       - 프로세스 체계도
          증권
        --------
       |           |
      AM      IBSP (Infomation Strategy Planning) : 정보화 전략 계획

2. 계획 순서도
  가. 환경분석
    1) 경영환경
        - 외부환경분석 : 기회/위험 분석
        - 내부환경분석 : 강점/약점 분석
        - 경영환경분석을 위해 4가지요소를 통합하여 SWOT 분석을 한다.
---------------------------------------------------------
               |       기회                       |  위험
---------------------------------------------------------
   강점     |                                     |
---------------------------------------------------------
   약점     |                                     |
---------------------------------------------------------
    2) 정보화환경
        - IT트랜드 정리
        - 적용가능한 기술 개략 선별(이미 인터뷰가 선행되어 있음)
  나. AS IS -분석
    1) Business Process 분석
       - 프로세스 체계도
          증권
        --------
       |           |
      AM      IB
    ------
   |      |
  위탁  저축 .......
      - 프로세스 순서도
       고객  :  시작 -> 종목선택 -> 주문의뢰
       증권사:                        ↓
                                     주문접수
                                         ↓
                                     예수금확인
                                      ....
      - 프로세스 조직 상관도
                금융상품부    증권영업부
     ------------------------------------
     금융상품 |     O
     증권매매 |                   X
     ------------------------------------

    2) 정보시스템현황 분석
       - HW/SW/APP/Network/Data
       ex) HW
          HW명        구매비         CPU      메모리       구매일자   담당자
      ------------------------------------------------------------------------------------
          .....
 다. TO BE -분석
    ------
   |      |
  위탁  저축 .......
      - 프로세스 순서도
       고객  :  시작 -> 종목선택 -> 주문의뢰
       증권사:                        ↓
                                     주문접수
                                         ↓
                                     예수금확인
                                      ....
      - 프로세스 조직 상관도
                금융상품부    증권영업부
     ------------------------------------
     금융상품 |     O
     증권매매 |                   X
     ------------------------------------

    2) 정보시스템현황 분석
       - HW/SW/APP/Network/Data
       ex) HW
          HW명        구매비         CPU      메모리       구매일자   담당자
      ------------------------------------------------------------------------------------
          .....
 다. TO BE -분석

  1. ESB의 정의 및 특징
    가. ESB(Enterprise Service Bus)의 정의
      - 애플리케이션을 Loosely Coupled 비지니스 서비스로서 연결 및 중재해주는 표준
      - 이기종 시스템간의 서비스 및 컴포넌트의 메시지를 전달하는 미들웨어
    나. ESB 특징
      - 기업 정보시스템을 공유와 재사용이 가능한 서비스와 컴포넌트 중심으로 묶는
        IT아키텍처를 지원하는 서비스 인프라(Service Infra)
      - 표준기반의 체계적으로 정의된 인터페이스(Web Service)를 통한 통합지원
      - 다양한 시스템과 연동을 위한 멀티프로토콜 지원/BPM을 지원/이벤트 지향적
  2. ESB의 주요기능 및 EAI와의 비교
    가. ESB의 주요기능
      - Service Oriented : 미들웨어 컴포넌트간의 약결합 지원
      - Event Oriented : 이벤트 발생시에 이벤트를 전송
      - 상호운영성 : 벤터별 미틀웨어 간의 상호연동
      - Runtime 환경 : SOA지원위한 Runtime Bus
      - Quality of Service : 성능, 안정성, 보안, 가용성의 높은 품질 제공
      - 통합 : 메시지 브로커를 기반으로 단계적 통합지원, 라우팅, Multi-Protocol,
        multi-APU 및 프로세스 통합을 지원하고 시스템간/애플리케이션간 통합지원
    나. ESB vs EAI (ESB의 상호 비교표와 동일)
      -----------------------------------------------------------------------
      구분               EAI                        ESB
      -----------------------------------------------------------------------
      통합종류    Application통합            Service통합/호스팅
      통합방안    시스템별 Adaptor           표준기술사용
      통합형태    Tightly Coupled(1:1)       Loosely Coupled (1:N)
      표준        벤더별                     Open Standard
      비용        증가                       감소 (재사용)
      구현        Hub&Spoke중앙집중          Bus구조
      속도        제한된 용량내에서 속도빠름 상대적으로 속도느림(표준준수)
      -----------------------------------------------------------------------
  3. ESB의 기대효과 및 전망
    가. 사용과 관리 단순화 : Install, Version Control, Documentation, Configuration 지원
    나. 개발생산성 증대 : Mapping, Java Support, ESQL, Debugging
    다. 연계 및 기능 : File(VSAM), JMS 및 Web Service 상호운영성
    라. SOA 시스템 구축에 ESB를 활용한 아키텍쳐 구성 및 구축이 필수적임, SOA의 구성에서
        ESB의 역할이 점차 확대될 것임."끝"
     * SOA에서 ESB의 역할
      - ESB는 단위서비스를 조합(Orchestration)하여 다양한 레벨의 복합서비스들을 쉽게 만들어
        재사용을 용이하게 해 주는 역할
      - 서비스 요청(requestor)과 제공(provider)사이의 연결을 최적화 하는 계층

1. 전사적 애플리케이션의 통합 EAI
  가. EAI(Enterprise Application Integration)의 정의
    - 기업내부의 이질적인 시스템간의 상호연동을 지원하는 미들웨어
    - Hub&Spoke구조의 중앙집중적 통합, 벤더 종속적인 Interface
  나. 추진배경
    - 다양한 플랫폼 및 애플리케이션이 산재, 프로세스/데이터 통합을 위한 시스템간
      Integration이 요구
    - 기업정보 가치 극대화를 위한, 시스템간 정보의 전달, 연계, 통합 이슈 발생
2. EAI 구성요소 및 ESB와의 비교
  가. EAI 구성요소
                             |------------------------------------------------|
      서비스    |------|     |                                                |
      요청  --> | 포털 | --> | -> -----------------------                     |
                |------|     |    |Broker                | <=> Adaptor-시스템A|
                             |    |Hub(메시징, 미들웨어) | <=> Adaptor-시스템B|
                             |    |Work-Flow             |                    |
                             |    |                      |                    |
                             |------------------------------------------------|
    - Platform : 데이터 전달 및 성능 보장
    - Adaptor:이기종 시스템간연동위한 SW모듈, Interface 담당
    - Broker:데이터매핑지원, 포맷/레벨 자동변환
    - Work-Flow:비지니스 WorkFlow를 정의/운용
  나. EAI vs ESB
      -----------------------------------------------------------------------
      구분               EAI                        ESB
      -----------------------------------------------------------------------
      통합종류    Application통합            Service통합/호스팅
      통합방안    시스템별 Adaptor           표준기술사용
      통합형태    Tightly Coupled(1:1)       Loosely Coupled (1:N)
      표준        벤더별                     Open Standard
      비용        증가                       감소 (재사용)
      구현        Hub&Spoke중앙집중          Bus구조
      속도        제한된 용량내에서 속도빠름 상대적으로 속도느림(표준준수)
      -----------------------------------------------------------------------
3. EAI 기대효과 및 활용사례
  가. 애플리케이션 통합통합 비용절감, 유지보수 비용 감소, 기존 시스템 재사용
      및 정보데이터의 실시간 통합, 전사 IF의 통합화/표준화/단순화
  나. 제한된 용량에서 고속처리가 필요한 기업 : 증권, 은행
      Input/Output이 다양하고 대내이질성이 있는 트랜잭션의 연결이 중요한 기업
      : 보험사."끝"