Preview

1. 19. SOA Preview

2. SOA(Service Oriented Architecture) 1. SOA의 개요 가. SOA(Service Oriented Architecture)의 정의 – Service라 불리는 분할된 Application 조각들을 단위로 loosely-coupled하게 연결하여 하나의 완성된 Application을 개발하기 위한 S/W 아키텍처 – 서비스 단위로 아키텍처를 분리하고, 표준화된 프로토콜인 웹 서비스를 기반으로 파트너 및 고객과 유연하게 연결할 수 있는 개방화된 플랫폼 – 업무구조를 재사용이 가능한 컴포넌트 형태로 구축하고 프로세스 기반 통합을 통하여 시스템을 구축하는 방안 나. SOA의 필요성 – 개별 정보시스템들의 기능적인 중복성 존재 – RTE를 구현하기 위한 유연하고 재사용성이 높은 아키텍처의 필요 다. SOA의 특징

3. SOA(Service Oriented Architecture) 라. SOA(Service Oriented Architecture)의 개념도 – 서비스 Provider가 서비스 Broker에 등록한 서비스를 서비스 Customer가 찾아 활용 – 웹서비스는 전형적인 SOA의 웹기반 인스턴스. (UDDI, SOAP, WSDL, XML) [참고] Service 개념

4. SOA(Service Oriented Architecture) 2. 기존 아키텍처와 SOA의 비교 가. 기존 아키텍처 – 독립적으로 구축된 여러 시스템이 별개의 섬으로 분리되어 있고, 데이터교환수준의 연동. – ERP 패키지를 사용하는 경우에도, Biz Chain 변화에 따른 빠르고 용이한 변경이 어려움. – 전체프로세스의 통합 및 운영이 느리고, High Cost.

5. SOA(Service Oriented Architecture) 나. SOA – 웹서비스 기술을 사용한 서비스 지향 아키텍처(SOA)가 대안(모든IT 벤더수용) : 서비스가 지역과 기술 환경에 관계없이 유연하게 통합되고, 상호 운용되는 IT 구조 – 프로세스계층을 어플리케이션에서 분리하여, 표준 비즈니스 프로세스 기술 언어로 관리(BPM) – 비즈니스 변화에 빠르고 신속하게 대응 가능, 실시간 의사결정 지원 적합한 IT 구조(RTE)

6. SOA(Service Oriented Architecture) 3. SOA 구축전략및 구축절차 가. SOA 구축 전략 1) 최적의 적용 분야 선정 - 업무적합성, 시스템 적합성, 구현 용이성 등으로 판단 2) 최적 크기의 서비스 도출 - 비즈니스 민첩성을 확보할 수 있도록 적당한 크기를 이용 - 고객과 IT 조직이 원활하고 정확한 Communication을 통해 최적의 크기로 서비스 도출 및구현 3) 어플리케이션 통합은 전사적 아키텍처 관점에서 조율(Orchestration) 4) SOA 도입을 위한 원칙 수립 - 단순한 애플리케이션의 개발이 아닌, 추진방식, 구현방법, 구현도구, 역할 등의 변화를 포함한 총체적인 패러다임의 전환 필요 - SOA 거버넌스 적용 나. SOA 구축 절차

7. SOA(Service Oriented Architecture) 4. SOA 거버넌스 (Governance) 가. SOA 거버넌스의 등장 배경 – 비즈니스 서비스의 등장 : SOA의 핵심인 비즈니스 서비스가 기업내외의 조직 경계를 넘어 선다는 특징을 갖고 있으며, 여러 조직에 포함되어 있는 비즈니스 서비스를 효율적으로 통합해야 하기 때문 – 서비스의 진화 : SOA를 구성하는 서비스는 라이프 사이클이 반복되면서 진화하게 됨. 반복되는 라이프 사이클을 효과적으로 운영하여 성공적인 SOA 구축/운영을 위해 SOA 거버넌스가 필요 – ROI 확보 : SOA를 적용할 때 적절하게 통제하지 못할 경우, 서비스를 다시 설계/개발/유지하는 등의 프로젝트 지연 비용이 발생할 수 있으며, 또한 서비스 재사용이 어려워 SOA 도입의 장점을 살릴 수 없음 나. SOA 거버넌스 적용 현황 및 시사점 – 거버넌스 프로세스나 전략없이 SOA 거버넌스 제품 만을 단순히 도입 – SOA 거버넌스의 다양한 영역(Service, Process, Policy, SOA Profile Gov.)이 있음에도 솔루션 벤더에서는 이중 하나에만 초점을 맞추어 제품을 출시하는 경향이 있음 – 거버넌스 도입시에는 거버넌스 기술 뿐 아니라 거버넌스 조직, 프로세스, 전략수립이 병행 되어야 함

8. SOA(Service Oriented Architecture) 5. SOA 기대효과 가. 사업경쟁력 제고 측면 : Time to Market = Enabler of business change 나. IT Governance 측면 : IT Cost ( Time & Money ) 절감

9. SOA(Service Oriented Architecture) [참고]CBD와 SOA간 개념 비교

10. SOA(Service Oriented Architecture) [참고]Web2.0과 SOA간 개념 비교

11. SOA(Service Oriented Architecture) [참고]서비스 식별 전체 공정 출처:정보과학회지 2006년11월호

12. 20. Web Service Preview

13. 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에 대한 정보 습득으로 신뢰를 가지고 해당서비스제공

14. Web Services 나. Web Services 표준 기술

15. 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)

16. Web Services 4) 레지스트리 종류 - 화이트 페이지 : 서비스제공자의 기업명, 주소, 전화번호 등 비즈니스기본정보 수록. - 옐로우 페이지 : 서비스제공자의 업종, 서비스 종류 등 서비스 분류정보 수록 - 그린 페이지 : 웹서비스를 이용하기 위한 기술정보 등록 다. WSDL (Web Service Description Language) 1) 개념 – 웹서비스를 이용하기 위해서는 해당 서비스를 이용하기 위한 인터페이스 사양을 알아야 함. 이 사양을 컴퓨터가 이해할 수 있는 형식으로 기술하기 위한 XML형식의 언어 2) 정의 – 웹서비스의 인터페이스를 정의하는 일종의 IDL(Interface Description Language) 3) 기능 - 메시지 컨텐트 설명 - 서비스를 사용할 수 있는 위치 및 서비스와 대화하는데 사용되는 통신 프로토콜 정의 4) 특징 - XML스키마 표준을 사용함으로써 다양한 플랫폼과 프로그래밍 언어에서 사용가능 - 대부분 소프트웨어에서 자동으로 작성되어짐

17. Web Services [참고] Web Services 기술 표준 스택(CBDi 포럼)

18. 21. ESB Preview

19. 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) 사이의 연결을 최적화하는 계층

20. 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 형태로 바뀌어 질 수 있음.

21. 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의 활용사례 가. 서비스와 복합서비스의 관계

22. ESB(Enterprise Service Bus) 나. ESB의 활용사례 – 기존 애플리케이션과 ESB 애플리케이션 비교 4. ESB 동향 - EAI나 BPM 솔루션에 포함되어있던 기능을 선별하고 필요한 기능을 특화하여 정식적인솔루션을 출시 - Service Mix와 Synapse와 같은 오픈 소스 프로젝트 진행 중

23. ESB(Enterprise Service Bus) [참고] SCA (Service Component Architecture) 가. SCA의 정의 – SOA 기반의 애플리케이션를 구축하기 위한 모델링 표준 나. SCA의 구성요소 – Design Time Model – Serialization Format – Configuration Model

24. 22. EDA Preview

25. EDA(Event Driven Architecture) 1. EDA의 개요 가. EDA (Event Driven Architecture)의 정의 – 모듈화, 캡슐화, 분배 가능한 컴포넌트화 된 기능들이 특정 이벤트에 반응해 분산된 환경에서 수행되는 기술로서, 이벤트가 전송되는 애플리케이션과 시스템들의 디자인, 구현 방식을 정의하는 아키텍처 나. EDA의 특징 – 디커플(decouple)인터랙션 :이벤트 퍼블리셔는 이벤트 등록자의 존재를 알지 못함 – 다대다 통신 : 퍼블리시/등록(Publish/Subscribe) 메시징에서는 한 개의 특정 이벤트가 많은 등록자에게 영향을 줄 수 있음 – 이벤트기반 트리거 : 수혜자에 의해 결정된 이벤트의 흐름은 제공된 이벤트에 근거 – 비동기식 : 이벤트 메시징에 비동기식 연산을 지원 2. EDA 개념도 및 구성요소 가. EDA의 개념도 – 이벤트 중심 아키텍처에서의 퍼블리시/등록 메커니즘

26. EDA(Event Driven Architecture) 나. EDA의 구성요소 1) 이벤트 메타 데이터: 이벤트 메시지의 모습을 정의한 이벤트 규격과 이벤트를 처리하기 위한 규칙 등 이벤트 관련 메타 데이터로 이벤트 소스 및 수신자, 이벤트 처리자 등이 공유할 수 있어야 함 2) 이벤트 프로세싱: 이벤트 규격을 따르는 이벤트 메시지를 대상으로 이벤트 처리 규칙에 따라 실제 처리를 수행하며 이벤트 메시지의 저장 관리를 담당 3) 이벤트 구축 도구: 이벤트 규격, 이벤트 처리 규칙 등을 정의하는 것을 지원하는 도구 4) 이벤트 관리 도구: 이벤트 처리 상태 모니터링,이벤트 흐름에 대한 모니터링 등 전체 시스템 관리 기능을 제공하는 도구

27. EDA(Event Driven Architecture) 5) 엔터프라이즈 통합: 외부 서비스 호출, 이벤트 전송, 엔터프라이즈 정보 접근 등과 같이 이벤트 입ㆍ출력시 혹은 이벤트 처리시 외부 자원과의 연동을 담당하기 위한 것으로, 기존 응용 환경에서 사용하고 있는 엔터프라이즈 통합 시스템(enterprise integration backbone)을 이용하여 연동 6) 통합할 외부 자원: 다양한 이벤트를 발생하는 소스와 이벤트 기반의 액션으로서 구동되어야 할. 외부 서비스 등을 의미하며, 엔터프라이즈 통합시스템에 의해 EDA 플랫폼에 통합됨 3. SOA와 비교를 통한 EDA의 특징

28. 23. REST Preview

29. 1-5. REST(Representational State Transfer) • 1. 경량화된 표준기술사용 REST의 개요 • 가. REST의 개념 • - 웹과 같은 대규모 네트워크 시스템을 위한 표준으로 XML, HTTP 을 사용하여 SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아키텍처 스타일 • 나. REST의 특징 • - Stateless : 상태를 유지하지 않는 브라우저/웹서버 구조를 갖음 • - 인터페이스 경량성: GET, POST, PUT, DELETE 등의 최소한의 인터페이스 경량성 적용 • - 자원식별의 표준성: 모든 자원은 URL을 이용하여 유일하게 지칭될 수 있음 • - 비표준성 배제 : 쿠키나 세션기반 추가 기능성을 배제하여 자원 표현의 표준화 준용 • 2. REST의 서비스 개념 및 SOA방식과의 비교 • 가. REST의 서비스 개념 • - 모든 자원을 URL 형태로 구조화하여 정의하고, 해당 자원에 대한 처리(CRUD)는 HTTP 메소드로 수행 자원(명사) 처리(동사) HTTP Methods: 예 GET,POST,PUT,DELETE URI : 예 http://yara.com/product 컨텐츠타입 XML, JSON

30. 1-5. REST(Representational State Transfer) 2. REST의 서비스 개념 및 SOA방식과의 비교 나. REST의 구성개체 다. REST와 SOA방식의 비교

31. REST(Representational State Transfer) 2. REST를 이용한 웹서비스 구현 개념도 REST SOAP

32. 24. WOA Preview

33. 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 프로토콜 등)을 이용하여 웹 서비스를 쉽게 구현함

34. WOA(Web Oriented Architecture) 나. SOA와의 장단점 비교

35. 인생에 성공하는 사람들은 10년 후의 미래를 보고 의사 결정을 한다. • 물방울이 바위를 뚫는 것은, 그 힘이 아니라 꾸준함이다.