Endless Endeavor

SSO(Single Sign-On)

SSO는 사용자가 네트웍에 한번 로그온하여, 기업내의 허가된 모든 자원에 접근할 수 있는 능력이다.

SSO 프로그램은 사용자 아이디와 암호를 받아들여서, 적절한 모든 서버에 자동적으로 로그온 한다.

RPC(Remote Procedure Call) 

멀리 떨어져 있는 컴퓨터상의 프로그램을 호출하는 것을 말합니다.

RPC는 원격 호출에 사용되는 프로토콜이지만 네트워크 전송시는 하부 프로토콜 (TCP/IP, IPX 등)을 사용할수 있다.

이후 객체지향 시스템이 나오면서

RMI(Remote Method Invoke) 

멀리떨어져(Remote) 컴퓨터상의 프로그램이 다른 컴퓨터 내에 있는 객체(Method)를 불러낸다(Invoke)

RPC 인터페이스

최상위 계층 - 라이브러리 함수들을 호출하는 것과 같은 방법으로 사용자들이 시스템이 제공하는 RPC함수 호출하는 계층

최하위 계층 - RPC API들을 사용하여 사용자들이 RPC 프로그램을 생성하는 하위 계층

장점 - 쉽게 사용할수 있고 프로그래밍 부담이 적다는 것이다.

 한빛미디어 김대곤(http://www.hanb.co.kr/network/view.html?bi_id=968) 여기에 보면 설명이 잘되어있다.

글의 한 단락이다.

자금 이체를 하는 프로그램을 작성한다고 생각해보자. 

출금계좌와 입금계좌, 그리고 이체금액을 입력받아 SQL 문장 또는 함수 한 번 돌리는 것으로 끝나는가? 

절대 아니다. 먼저 해킹을 방지하기 위해 사용자가  적절한 보안 프로그램을 설치했는지 점검하는 코드도 있어야 하고, 

사용자가 인증 되었는지 점검하는 코드도 써야 하고, 상대방 은행에서 적절하게 처리되었는지 점검해야 하고,

혹시 사용자가 이체버튼을 두번 누른 것은 아닌지 체크해야 하고 로그도 남겨야 한다.

즉, 구현하려고 하는 기능 뿐 아니라 보안, 인증, 로그, 성능와 같은 다른 기능도 들어있어야 한다.

어쩌면 이체를 위한 코드보다 잡다한 측면의 문제를 다루는 코드가 더 길어질 수 있다.

이런 코드들은 입금이나 출금 같은 다른 곳에서 들어가야 한다. 

구현하려고 하는 비즈니스 기능들을 Primary(Code) Concern, 보안, 로그, 인증과 같이 

시스템 전반적으로 산재딘 기능들을 Cross-cutting concern 이라고 부른다.

Aop는 Cross-cutting concern 을 어떻게 다룰 것인가에 대한 새로운 패러다임이라고 할수 있다. 

Aspect는   Advice + Point-cut을 함께 지칭하는 단어이다.

Point-cut은 어떤 Advice를 code 어느 위치에 둘 것인가 하는 것이다.

예를 들면 로그 기능을 구현한 Advice는 code 속에 있는 모든 public method가 수행되고 나면

그 마지막에 실행되어라 라고 지정한 것이라 할 수 있다.

Representaional State Transfer 

웹프로토콜(HTTP)을 활용하여, Resource 중심으로 연동 인터페이스 구조를 제안한 것입니다.

웹이전에 돌아가서 ( 클라이언트 - 서버 ) 연동 문제가 어떻게 해결되었는지 부터 알아야 합니다.

개발의 기본은 라이브러리화 하는 것입니다. 

이렇게 함으로써의 이점은 소스코드를 재활용할수 있으며, 

나 혼자가 아닌 다른 사람들도 이어서 개발을 할수 있는 기반이 됩니다. 

하지만 하나의 컴퓨터에서나 처리가 가능할 뿐 네트웍을 넘어갈 수는 없습니다. 

A컴퓨터에서 B컴퓨터에 있는 라이브러리를 호출할수 없었습니다.

네트웍에 호출 받을수 있도록 작업을 하기 시작합니다. 

그게 RPC데몬 (Remote Procedure Call) 약자로 유닉스에서 사용되었습니다.

RPC는 보안에 문제가 있었으며, 네트웍 자원 활용이나 함수를 동적으로 사용하는 데 제약이 있었습니다.

이 문제를 해결하기 위해 도입한 것은  CORBA 입니다. 

CORBA는 A컴에 있는 C++ 프로그램이 B컴에 있는 자바 서버의 함수도 호출할 수 있게 한다는 그런 취지 입니다.

원리는 IIOP라는 프로토콜을 통해서, 프로그램 언어에 상관없이 인터페이스를 정의(IDL)하고, 그걸 기반으로 각 언어에서

CORBA 플렛폼을 통해 개발하면 C++로 짜여진 함수도 자바에서 호출할 수 있었습니다.

CORBA는 무겁고 비쌌으며 서버쪽 H/W어느정도 속도도 되어야 했으므로 잘 사용하지 않게 되었습니다.

JAVA에서는 RMI(RPC의 자바버젼)이 나왔지만 네트웍 연동은 쉬웠지만 방화벽에 늘 상 걸렸습니다.

그래서 HTTP로 무엇인가 연동하는 방안을 고민했고  

그건 바로 XML과 HTTP를 결합한 SOAP기반의 웹서비스였습니다.

SOAP는 HTTP를 활용할 수 있었으므로 방화벽문제는 어느정도 해결했습니다.

SOAP기반의 웹서비스는 서비스지향 구조(Service-Oriented Architecture)SOA로

SOA는 서비스를 자유자재로 정의할 수 있다는 게 매력인 동시에 그만큼 복잡해질 수도 있다는 게 문제였습니다.

즉 서비스를 정의하는 것 자체도 WSDL이란 놈을 만들어 함수명부터 시작, 매개변수, 결과값 

세부적인 사항 하나하나 정의합니다. 그리고 이를 UDDI(인터넷에서 DNS같은 것)이라 놈을 등록해서 

외부에서 발견할 수 있게 하는 구조였습니다.

서비스지향으로 바라보기 보다는 리소스기반(Resource-Oriented Architecture)ROA으로 정의하면 

어떻겠느냐는  아이디어가 나옵니다.

웹이란 자체가 리소스기반입니다. 웹에서 모든 문서, 객체를 대상으로 Http Get하는게 기본조작입니다.

웹에서 사용하는 HTTP Primitive (GET, PUT, POST, DELETE)를 그대로 쓸수 있지 않겠냐고 해서 그게 바로 REST입니다.

REST는 SOAP기반의 웹서비스인 SOA와 대비되는 자원기반은 ROA 연동방식입니다.

ROA는 더 확장해서 WOA(Web Oriented Architecture)로 발전됩니다. 

REST는 네트웍상에서 원격에 있는 서버의 서비스(API)를 사용할수 있게 그것도 방화벽이라는 제약을 넘어서

가능하게 하자는 취지에서 나왔습니다. 

서비스지향(SOAP)웹서비스도 있었으나 REST는 좀 더 실용적인 접근을 했고, 그 실용성을 이해하기 쉬운 Http의 Verb, request, response를 그대로 사용한다는 특정 덕에 각광받는 Open API 방식이 되었습니다.