교육자료

Download Report

Transcript 교육자료

19. SOA
Preview
항목
개요
기출여부
관련KeyWord
상세내역
서비스 통합을 위한 Architecture
77-조, 78-관, 82-관, 93-관
Loosely Coupled, 웹서비스, Brocker, Provider, Consumer
추천사이트
기술발전
RoadMap
기타
-0-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
1. SOA의 개요
가. SOA(Service Oriented Architecture)의 정의
– Service라 불리는 분할된 Application 조각들을 단위로 loosely-coupled하게 연결하여 하나의 완성된
Application을 개발하기 위한 S/W 아키텍처
– 서비스 단위로 아키텍처를 분리하고, 표준화된 프로토콜인 웹 서비스를 기반으로 파트너 및 고객과 유연하게
연결할 수 있는 개방화된 플랫폼
– 업무구조를 재사용이 가능한 컴포넌트 형태로 구축하고 프로세스 기반 통합을 통하여 시스템을 구축하는 방안
나. SOA의 필요성
– 개별 정보시스템들의 기능적인 중복성 존재
– RTE를 구현하기 위한 유연하고 재사용성이 높은 아키텍처의 필요
다. SOA의 특징
특징
플랫폼 독립적
Loosely Coupled
프로세스 중심
위치투명성
내용
-구현기술과 관계없는 연결을 보장
- 서비스 간의 종속성을 줄이고 프로세스를 단순화
-비즈니스 프로세스를 별도의 독립된 구성요소로 보고 이를 설계시 부터 분리
-서비스의 물리적 위치에 무관하게 서비스 접근
-1-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
라. SOA(Service Oriented Architecture)의 개념도
– 서비스 Provider가 서비스 Broker에 등록한 서비스를 서비스 Customer가 찾아 활용
– 웹서비스는 전형적인 SOA의 웹기반 인스턴스. (UDDI, SOAP, WSDL, XML)
[참고] Service 개념
-2-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
2. 기존 아키텍처와 SOA의 비교
가. 기존 아키텍처
– 독립적으로 구축된 여러 시스템이 별개의 섬으로 분리되어 있고, 데이터교환수준의 연동.
– ERP 패키지를 사용하는 경우에도, Biz Chain 변화에 따른 빠르고 용이한 변경이 어려움.
– 전체프로세스의 통합 및 운영이 느리고, High Cost.
-3-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
나. SOA
– 웹서비스 기술을 사용한 서비스 지향 아키텍처(SOA)가 대안(모든IT 벤더수용)
: 서비스가 지역과 기술 환경에 관계없이 유연하게 통합되고, 상호 운용되는 IT 구조
– 프로세스계층을 어플리케이션에서 분리하여, 표준 비즈니스 프로세스 기술 언어로 관리(BPM)
– 비즈니스 변화에 빠르고 신속하게 대응 가능, 실시간 의사결정 지원 적합한 IT 구조(RTE)
-4-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
3. SOA 구축 전략 및 구축절차
가. SOA 구축 전략
1) 최적의 적용 분야 선정
- 업무적합성, 시스템 적합성, 구현 용이성 등으로 판단
2) 최적 크기의 서비스 도출
- 비즈니스 민첩성을 확보할 수 있도록 적당한 크기를 이용
- 고객과 IT 조직이 원활하고 정확한 Communication을 통해 최적의 크기로 서비스 도출 및구현
3) 어플리케이션 통합은 전사적 아키텍처 관점에서 조율(Orchestration)
4) SOA 도입을 위한 원칙 수립
- 단순한 애플리케이션의 개발이 아닌, 추진방식, 구현방법, 구현도구, 역할 등의 변화를 포함한 총체적인
패러다임의 전환 필요
- SOA 거버넌스 적용
나. SOA 구축 절차
-5-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
4. SOA 거버넌스 (Governance)
가. SOA 거버넌스의 등장 배경
– 비즈니스 서비스의 등장 : SOA의 핵심인 비즈니스 서비스가 기업내외의 조직 경계를 넘어 선다는 특징을 갖고
있으며, 여러 조직에 포함되어 있는 비즈니스 서비스를 효율적으로 통합해야 하기 때문
– 서비스의 진화 : SOA를 구성하는 서비스는 라이프 사이클이 반복되면서 진화하게 됨. 반복되는 라이프
사이클을 효과적으로 운영하여 성공적인 SOA 구축/운영을 위해 SOA 거버넌스가 필요
– ROI 확보 : SOA를 적용할 때 적절하게 통제하지 못할 경우, 서비스를 다시 설계/개발/유지하는 등의
프로젝트 지연 비용이 발생할 수 있으며, 또한 서비스 재사용이 어려워 SOA 도입의 장점을 살릴 수 없음
나. SOA 거버넌스 적용 현황 및 시사점
– 거버넌스 프로세스나 전략 없이 SOA 거버넌스 제품 만을 단순히 도입
– SOA 거버넌스의 다양한 영역(Service, Process, Policy, SOA Profile Gov.)이 있음에도 솔루션 벤더에서는
이중 하나에만 초점을 맞추어 제품을 출시하는 경향이 있음
– 거버넌스 도입 시에는 거버넌스 기술 뿐 아니라 거버넌스 조직, 프로세스, 전략수립이 병행 되어야 함
-6-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
5. SOA 기대효과
가. 사업경쟁력 제고 측면 : Time to Market = Enabler of business change
효과
설명
Agile 비즈니스
-빠른 시장 접근, 비즈니스 민첩성, 기업간 협업 향상
-다양한 비즈니스 모델 창출 용이 : 신규 서비스 채널의 신속 추가 용이(CP, PDA,
DMB)
프로세스 최적화
-Biz 프로세스 중심의 아키텍처로 Biz 프로세스의 개선/변화에 적응 용이
나. IT Governance 측면 : IT Cost ( Time & Money ) 절감
효과
Agile 시스템
TCO 제고
설명
-SW, HW 인프라 독립적
-시스템 통합이 용이
-비즈니스 변화에 따른 IT의 변경 최소화 및 빠른 대응
-장기적인 IT비용 대비 효과 절감(서비스 재사용으로 중복 개발제거)
-통합 비용 감소(타 응용시스템과의 연결에 필요한 비용, 시간 축소)
-7-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
[참고]CBD와 SOA간 개념 비교
특성
시스템의 관점
프로세스
SOA
CBD
-기업 내외부 통합관점
-기업 내부 특정 시스템 관점
-컴포넌트를 연결하는 프로세스에 대한
-프로세스보다는 개별 컴포넌트에 집중
고려가 큰 비중
-서비스 컴포넌트 중심(추상화 정도를
높임)
-기능 컴포넌트 중심(상대적으로 추상화
정도가 낮음)
-컨설팅기법(IDEF등), UML, EA
-UML
-비즈니스 목표와 연결시키는 것이
목적,성과 측정과 연계(BPM)
-시스템 관점에서의 컴포넌트 구축
-이기종 통합 연계
-J2EE, NET 개별적 연계
-Loosely Coupling (SOAP)
-Tightly Coupling (Serialization)
인터페이스
-공개적인 인터페이스(WSDL활용)
-개별 인터페이스 활용
활용기술
-EAI, Web Service, BPM, 웹기술
-WAS기반 웹기술
컴포넌트 특성
모델링 기법
목표
플랫폼
연계방식
-8-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
[참고]Web2.0과 SOA간 개념 비교
구분
서비스 모델
Web2.0
SOA
- 웹서비스
- 웹서비스
- HTTP, XML, RSS, REST
- WSDL, UDDI, SOAP, BPEL, WS
- 매우 높음
- 약간 높음
유연성 및 순응성
- 매우 높음, 단순한 데이터 포맷, 가벼운 프로그래밍
모델
- 높음(보다 더 공식적), 조합과 통합, 서비스 지향의 원칙
비즈니스 모델
- 롱테일(Long Tail) 효과, 네트워크 효과, 집단지능
활용, 고객 셀프 서비스
- BPM(Business Process Management), 자산통합(Asset
Integration), 데이터 퓨전, 레거시 자산의 생명주기 연장,
비즈니스 활동 모니터링, 비즈늬스 지능 활용
- AJAX, 신디케이션(Syndication), 멀티 디바이스
소프트웨어
- Service Layer, Service Bus, Unit of Work
- 서비스로서의 SW(SaaS)
- 데이터 소스에 대한 통제
- 공동 개발자로서 사용자 신뢰
- 집단지능 이용
- 롱테일 효과
- 단일 디바이스(PC플랫폼)을 넘어선 소프트웨어
- 가벼운(lightweight) UI, 개발모델, 비즈니스 모델
채용
- 기능의 재정비
- 자산(Asset)으로서 데이터
- 접근/가능성
- 시스템/데이터 통합
- 비용절감
- 비즈니스 기민성(Agility)
- B2B 셀프 서비스
- 오픈 스탠다드(Open Standard)
- 온톨로지
- 오퍼레이션 투명성
- 소비자 중심의 비즈니스 프로세스
선호하는 서비스 표준
재사용성
설계 플랫폼
핵심 역량
-9-
㈜인포레버컨설팅 교육사업본부
SOA(Service Oriented Architecture)
[참고]서비스 식별 전체 공정
출처:정보과학회지 2006년11월호
- 10 -
㈜인포레버컨설팅 교육사업본부
20. Web Service
Preview
항목
개요
상세내역
웹 인프라를 기반으로 Application 및 Contents등을 I/F하고 재사용하고자
하는 서비스
기출여부
관련KeyWord
확장성, Brocker, Provider, Consumer, SOAP, UDDI, WSDL
추천사이트
기술발전
RoadMap
기타
- 11 -
㈜인포레버컨설팅 교육사업본부
Web Services
1. Web Services의 개요
가. Web Services의 정의
– XML, SOAP, UDDI등의 표준 웹기반 기술을 이용하여 정보시스템의 상호운영성을 극대화하는 정보시스템
구현기술
나. Web Services의 특징
– 독립성 : H/W, S/W, O/S 및 기타어플리케이션과는 독립적
– 개방성 : 표준(UDDI/WSDL/SOAP/HTTP)에 근거한 상호 연동
– 확장성 : 상호 연동의 단순화 , 개발용이 , 비용절감효과
– 유연성 : 텍스트 기반 XML 채용
– 취약점 : 트랜잭션 관리, 보안의 취약
2. Web Services구성도 및 표준 기술
가. Web Services 구성도
(1) 기업 A 또는 비즈니스시스템 A는 UDDI를
통하여 어떤 서비스가 비즈니스 시스템 B에
있음을 WSDL형태로 전송 받음
(2) 기업 A는 기업B와 SOAP를 이용한 객체 통
신을 요구함
(3) 기업 B는 UDDI를 통해 기업 A에 대한 정보
습득으로 신뢰를 가지고 해당서비스제공
- 12 -
㈜인포레버컨설팅 교육사업본부
Web Services
나. Web Services 표준 기술
- 13 -
㈜인포레버컨설팅 교육사업본부
Web Services
3. 기본 Web Services 기술 상세
가. SOAP(Simple Object Access Protocol)
1) 정의 - 분산환경(웹)하에서 정보(메시지)를 교환하는 프로토콜로 HTTP+XML임
2) 구성 - HTTP : 기본전송 수단
- XML : 인코딩 (호출요청 및 응답)
3) 등장배경
- 웹 하에서 원격 프로시저 호출에는 HTTP가 부적합
- Firewall에 의한 RPC의 어려움 (80 Port만 통과 됨)
- CORBA, IIOP는 구현이 복잡함
4) 특징
- SOAP는 HTTP 맨 위에 분산객체 프로토콜을 올려서(piggyback) 전송하므로 모든 방화벽 통과 가능
- HTTP의 Verb인 get/put/post 뒤에 정보를 추가하여 전달
- SOAP을 통한 Web Service 구현 시 현 인터넷 인프라 변경없이 분산객체간 RPC가능
- 데이터 packet이 크며, XML Parsing에 따른 overhead (단점)
나. UDDI(Universal Description Discovery Integration)
1) 정의 : 전자상거래 및 웹서비스를 온라인 디렉토리에 등록, 공개하기 위해 개발된 규약
2) 필요성 : B2B e-Commerce 성장장애 요소인 상이한 Applications, 상호정보교환의 표준부재, 단일한 접근
포인트 부재를 해결
3) 구성
- 데이터보관 : Registry
- 검색 : SOAP형식을 닮은 조회API사용(Inquiry API)
- 14 -
㈜인포레버컨설팅 교육사업본부
Web Services
4) 레지스트리 종류
- 화이트 페이지 : 서비스제공자의 기업명, 주소, 전화번호 등 비즈니스기본정보 수록.
- 옐로우 페이지 : 서비스제공자의 업종, 서비스 종류 등 서비스 분류정보 수록
- 그린 페이지 : 웹서비스를 이용하기 위한 기술정보 등록
다. WSDL (Web Service Description Language)
1) 개념 – 웹서비스를 이용하기 위해서는 해당 서비스를 이용하기 위한 인터페이스 사양을 알아야 함.
이 사양을 컴퓨터가 이해할 수 있는 형식으로 기술하기 위한 XML형식의 언어
2) 정의 – 웹서비스의 인터페이스를 정의하는 일종의 IDL(Interface Description Language)
3) 기능
- 메시지 컨텐트 설명
- 서비스를 사용할 수 있는 위치 및 서비스와 대화하는데 사용되는 통신 프로토콜 정의
4) 특징
- XML스키마 표준을 사용함으로써 다양한 플랫폼과 프로그래밍 언어에서 사용가능
- 대부분 소프트웨어에서 자동으로 작성되어짐
- 15 -
㈜인포레버컨설팅 교육사업본부
Web Services
[참고] Web Services 기술 표준 스택(CBDi 포럼)
- 16 -
㈜인포레버컨설팅 교육사업본부
21. ESB
Preview
항목
개요
상세내역
웹서비스 기술을 기반으로 SOA를 지원하는 미들웨어 Platform
기출여부
관련KeyWord
SOA지원, Adapter, Service Component, 통합
추천사이트
기술발전
RoadMap
기타
ESB = EAI + 표준화 + 분산화
- 17 -
㈜인포레버컨설팅 교육사업본부
ESB(Enterprise Service Bus)
1. ESB의 개요
가. ESB(Enterprise Service Bus)의 정의
– 웹 서비스, Content-Based Routing, 메시지 변환 기술을 기반으로 SOA를 지원하는 미들웨어 플랫폼
나. ESB의 특징
– Loosely coupled: 표준인터페이스(WSDL)를 준수하는 메시지 전송에 의해 Application 간의 연관성이 적은
형태에서 연동을 지원
– Highly distributed integration network : 중앙 집중적이면서도 분산 환경의 통합을 지원
– Event-driven : 시스템에 독립적인 이벤트에 의해 자동적인 Process의 시작이나 정지, 재시작 등의 조정이
가능한 형태
– Documents-oriented(Message Driven) : 메시지기반의 통신을 기반으로 함
– 표준인터페이스지원 : COM, CICS, .NET, JMS, JCA, JDBC, Web Services 지원
2. ESB의 SOA에서의 역할 및 기능
가. SOA에서 ESB의 역할
– ESB는 단위 서비스를 조합(Orchestration)하여 다양한 레벨의 복합 서비스들을 쉽게 만들어 재사용을
용이하게 해주는 역할
– 서비스요청(requestor)과 제공(provider) 사이의 연결을 최적화하는 계층
- 18 -
㈜인포레버컨설팅 교육사업본부
ESB(Enterprise Service Bus)
나. ESB의 기능
(1) 인터페이스 통합
- Web Service(SOAP), JMS(MQ), File(FTP)에 대한 통합 기능 제공 : Legacy Application의 경우 JCA를
활용하거나 Custom Adapter 활용가능
- 사용자 User Interface와의 연계 지원
(2) 메시지 변환
- 콘텐츠 변환: XML표준의 메시지를 XPath, XSLT를 활용해 메시지를 변환한다.
- 프로토콜 변환 : JMS, HTTP, RMI 등의 프로토콜을 상호간에 변환.
- 예를 들어 JSM로 요청한 프로토콜이 HTTP 형태로 바뀌어 질 수 있음.
- 19 -
㈜인포레버컨설팅 교육사업본부
ESB(Enterprise Service Bus)
(3) Content-Based Routing (Intelligent Routing)
- 메시지의 내용에 따라 호출할 서비스를 결정하거나 특정한 로직을 처리할 경우 활용
(4) Message Communications
- XML 기반의 동기/비동기 SOAP messaging : SOAP표준에 기반한 메시지를 교환함으로써 이기종/분산
환경에서의 데이터 및 Application 연동 지원
- 신뢰성 있는 통신환경 : MQ와 같은 MOM(Message Oriented Middleware)을 활용하여 메시지 전송의 안정
성과
보안성 지원
3. ESB의 활용사례
가. 서비스와 복합서비스의 관계
- 20 -
㈜인포레버컨설팅 교육사업본부
ESB(Enterprise Service Bus)
나. ESB의 활용사례 – 기존 애플리케이션과 ESB 애플리케이션 비교
4. ESB 동향
- EAI나 BPM 솔루션에 포함되어있던 기능을 선별하고 필요한 기능을 특화하여 정식적인 솔루션을 출시
- Service Mix와 Synapse와 같은 오픈 소스 프로젝트 진행 중
- 21 -
㈜인포레버컨설팅 교육사업본부
ESB(Enterprise Service Bus)
[참고] SCA (Service Component Architecture)
가. SCA의 정의
– SOA 기반의 애플리케이션를 구축하기 위한 모델링 표준
나. SCA의 구성요소
– Design Time Model
– Serialization Format
– Configuration Model
- 22 -
㈜인포레버컨설팅 교육사업본부
22. EDA
Preview
항목
상세내역
개요
비즈니스적으로 기대수준을 벗어나는 상황을 이벤트로 감지하여 실시간으
로 관리하고 처리하기 위한 Architecture
기출여부
관련KeyWord
Event, Sink, Module, 이벤트 메타데이터, 이벤트 프로세싱
추천사이트
기술발전
RoadMap
기타
- 23 -
㈜인포레버컨설팅 교육사업본부
EDA(Event Driven Architecture)
1. EDA의 개요
가. EDA (Event Driven Architecture)의 정의
– 모듈화, 캡슐화, 분배 가능한 컴포넌트화 된 기능들이 특정 이벤트에 반응해 분산된 환경에서 수행되는 기술로
서, 이벤트가 전송되는
애플리케이션과 시스템들의 디자인, 구현 방식을 정의하는 아키텍처
나. EDA의 특징
– 디커플(decouple) 인터랙션 :이벤트 퍼블리셔는 이벤트 등록자의 존재를 알지 못함
– 다대다 통신 : 퍼블리시/등록(Publish/Subscribe) 메시징에서는 한 개의 특정 이벤트가 많은 등록자에게 영향
을 줄 수 있음
– 이벤트기반 트리거 : 수혜자에 의해 결정된 이벤트의 흐름은 제공된 이벤트에 근거
– 비동기식 : 이벤트 메시징에 비동기식 연산을 지원
2. EDA 개념도 및 구성요소
가. EDA의 개념도
– 이벤트 중심 아키텍처에서의 퍼블리시/등록 메커니즘
- 24 -
㈜인포레버컨설팅 교육사업본부
EDA(Event Driven Architecture)
나. EDA의 구성요소
1) 이벤트 메타 데이터: 이벤트 메시지의 모습을 정의한 이벤트 규격과 이벤트를 처리하기 위한 규칙 등 이벤트
관련 메타 데이터로
이벤트 소스 및 수신자, 이벤트 처리자 등이 공유할 수 있어야 함
2) 이벤트 프로세싱: 이벤트 규격을 따르는 이벤트 메시지를 대상으로 이벤트 처리 규칙에 따라 실제 처리를
수행하며 이벤트 메시지의 저장 관리를 담당
3) 이벤트 구축 도구: 이벤트 규격, 이벤트 처리 규칙 등을 정의하는 것을 지원하는 도구
4) 이벤트 관리 도구: 이벤트 처리 상태 모니터링,이벤트 흐름에 대한 모니터링 등 전체 시스템 관리 기능을
제공하는 도구
- 25 -
㈜인포레버컨설팅 교육사업본부
EDA(Event Driven Architecture)
5) 엔터프라이즈 통합: 외부 서비스 호출, 이벤트 전송, 엔터프라이즈 정보 접근 등과 같이 이벤트 입ㆍ출력시
혹은 이벤트 처리시 외부 자원과의 연동을 담당하기 위한 것으로, 기존 응용 환경에서 사용하고 있는
엔터프라이즈 통합 시스템(enterprise integration backbone)을 이용하여 연동
6) 통합할 외부 자원: 다양한 이벤트를 발생하는 소스와 이벤트 기반의 액션으로서 구동되어야 할. 외부 서비스
등을 의미하며, 엔터프라이즈 통합시스템에 의해 EDA 플랫폼에 통합됨
3. SOA와 비교를 통한 EDA의 특징
- 26 -
㈜인포레버컨설팅 교육사업본부
23. REST
Preview
항목
개요
상세내역
분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한형식
기출여부
관련KeyWord
Http, SOAP, 쿠키, 세션트래킹, 인터페이스
추천사이트
기술발전
RoadMap
기타
- 27 -
㈜인포레버컨설팅 교육사업본부
1-5. REST(Representational State Transfer)
1. 경량화된 표준기술사용 REST의 개요
가. REST의 개념
- 웹과 같은 대규모 네트워크 시스템을 위한 표준으로 XML, HTTP 을 사용하여 SOAP이나 쿠키를 통한 세션 트랙킹
같은 부가적인 전송 레이어 없이, 전송하기 위한 아키텍처 스타일
나. REST의 특징
- Stateless : 상태를 유지하지 않는 브라우저/웹서버 구조를 갖음
- 인터페이스 경량성 : GET, POST, PUT, DELETE 등의 최소한의 인터페이스 경량성 적용
- 자원식별의 표준성 : 모든 자원은 URL을 이용하여 유일하게 지칭될 수 있음
- 비표준성 배제 : 쿠키나 세션기반 추가 기능성을 배제하여 자원 표현의 표준화 준용
2. REST의 서비스 개념 및 SOA방식과의 비교
가. REST의 서비스 개념
자원(명사)
URI : 예 http://yara.com/product
처리(동사)
HTTP Methods : 예 GET,POST,PUT,DELETE
컨텐츠타입
XML, JSON
- 모든 자원을 URL 형태로 구조화하여 정의하고, 해당 자원에 대한 처리(CRUD)는 HTTP 메소드로 수행
- 28 -
㈜인포레버컨설팅 교육사업본부
1-5. REST(Representational State Transfer)
2. REST의 서비스 개념 및 SOA방식과의 비교
나. REST의 구성개체
구성개체
자원
(데이터요소)
처리
(컴포넌트)
커넥터
상세설명
- 데이터, 식별자(URI와URL), HTML 문서, XML 문서, 이미지와 같은 데이터 표현
- 아파치(Apache) httpd와 마이크로소프트® IIS(Internet Information Services) 같은
고유서버, 스퀴드(Squid)와CGI 같은 게이트웨이(gateways), 건틀렛(Gauntlet)과
넷스케이프(Netscape) 프록시 같은 프록시, 웹브라우저나 모바일기기 같은 사용자
에이전트
- libwww같은 클라이언트커넥터, NSAPI 같은 서버커넥터, 브라우저캐시 같은 캐시 등
다. REST와 SOA방식의 비교
구분
REST
SOAP
Proxy Server
상태 변이
(Transition state)
Caching
웹의 진화
Generic Interface
상호 운영성
보안
사용가능
가능
사용 불가(별도 구현 필요)
불가능(다음 작업에 대한 정보는 외부 찾음)
가능
일치(리소스는 논리적 URL을 가짐)
있음(확장성 우수)
지원
별도 구현 필요
불가능
불일치
없음(자신의 메소드 정의, 확장성 떨어짐)
비지원 (커스터마이징요소)
우수(내용 및 메소드가 메시지 숨김)
- 29 -
㈜인포레버컨설팅 교육사업본부
REST(Representational State Transfer)
2. REST를 이용한 웹서비스 구현 개념도
REST
SOAP
- 30 -
㈜인포레버컨설팅 교육사업본부
24. WOA
Preview
항목
개요
상세내역
검증된 웹기술을 이용 웹서비스를 쉽게 구현하기 위한 아키텍쳐
기출여부
관련KeyWord
SOA, REST, Http
추천사이트
기술발전
RoadMap
기타
- 31 -
㈜인포레버컨설팅 교육사업본부
WOA(Web Oriented Architecture)
1. 간결하고 최소한의 SOA 구현, WOA의 개요
가. WOA(Web Oriented Architecture) 의 정의
– 간단하고 최소한의 웹 표준만 사용하여 서비스를 처리하기 위해 제시된 아키텍처.
나. WOA의 특징
– 상태정보를 가지지 않는 클라이언트/서버구조
– 캐쉬 활용 옵션 (캐쉬를 통한 응답시간 향상)
– 범용적 표준사용 (HTTP, REST)
– Layer가 있는 시스템
– 클라이언트에서 실행할 수 있는 코드활용(Applet, Flash)으로 서버부하 감소
2. WOA가 차지하는 위치 및 SOA와의 비교
가 WOA가 차지하는 위치
- WOA는 SOA와 달리 기존 개발자를 활
용
하거나 개발자를 구하기 쉽고, 잘 알려져
있으며 거의 모든 사람이 사용하는 검증된
기술인 웹 기술(REST 아키텍처, HTTP
프로토콜 등)을 이용하여 웹 서비스를
쉽게 구현함
- 32 -
㈜인포레버컨설팅 교육사업본부
WOA(Web Oriented Architecture)
나. SOA와의 장단점 비교
- 33 -
㈜인포레버컨설팅 교육사업본부
•인생에 성공하는 사람들은 10년 후의 미래를 보고 의사 결정을 한다.
•물방울이 바위를 뚫는 것은, 그 힘이 아니라 꾸준함이다.
- 34 -
㈜인포레버컨설팅 교육사업본부