동시성과 병렬성을 해결하는 프로그래밍으로 리액티브나 비동기 요구사항을 명령형 방식으로 만들었을 때 나타나는 콜백 지옥 문제를 해결하는 것이다.
즉 RxJava 를 이용한 리액티브 프로그래밍은 명령형 방식을 이용하지 않고 선언적 접근을 사용한다.
리액티브 프로그래밍이 필요한 순간마우스 움직임이나 클릭, 키보드 타이핑, GPS 신호, 자이로스코프 신호, 터치 이벤트 처리비동기성을 띠는 네트워크 등 지연 I/O 이벤트 응답이벤트나 앞서 나온 사용자 이벤트, 애플리케이션에서 발생하는 이벤트나 데이터를 다룰때
만약 단 하나의 이벤트 스트림만 처리하는 경우는 콜백 기반의 리액티브 명령형 프로그래밍도 괜찮다.
또한 수많은 이벤트 스트림이 서로 독립적인 경우에도 명령형 프로그래밍은 큰 문제는 아니다.
RxJava 는 함수형 프로그래밍과 데이터플로 프로그래밍에 영향을 받아 리액티브 프로그래밍 원칙들을 구체화한 구현이다.
RxJava는 어떻게 동작하는가
데이터나 이벤트 스트림을 나타내는 Observable 타입으로 push / reactive 방식을 선호
즉시동작이 아닌 지연실행 가능하고 비동기와 동기 방식 모두 사용가능하고 시간에 따라 많은 이벤트를 다룰 수 있다.
RxJava 가 리액티브이기 위한 핵심은 밀어내기 인데 Observable과 Observer 타입 시그니처가 이를 지원한다.
밀어내기를 지원하기 위해서는 Observable / Observer 쌍을 subscribe로 연결한다.
Observer는 구독을 통해 3가지 유형의 이벤트를 받는다.
interface Observer<T>{
void onNext( T t )
void onError( Throwalbe t )
void onComplete()
}
onComplete 가 호출되면 Observable 스트림은 끝나고 더 이상 이벤트를 보낼 수 없다.
Observable 이벤트 생성의 중요한 기준은 블로킹/논블로킹 여부이지 동기/비동기 여부가 아니다.
동기 방식 계산
동기 방식을 유지하는 일반적인 이유는 스트림 조합과 연산자를 통한 변환 때문이다. RxJava는 데이터를 조작하거나 결합하고 변환을 위한 map() / filter() take() flatMap() groupBy() 같은 연산자로 구성된 방대한 API이다. 이들 연산자의 대부분은 동기 방식이고, onNext 안에서 이벤트가 지나가는 동안 동기 방식으로 계산을 수행한다.
RxJava Observable의 규약에 의하면 onNext onCompleted onError 이벤트는 동시에 방출되지 않는다. 즉 직렬화된 스레드이다.
Observable은 lazy해서 어딘가에서 subscribe 하지 않으면 아무것도 하지 않음을 뜻한다. 이는 future와 같이 일단 생성되면 즉시 동작하는 조급한 유형과는 다르다.
이런 특성 때문에 Observable의 객체 생성은 어떤 작업을 유발하지 않고 구독했을때 해야 할 작업을 정의한다.
예제
Observable<T> someData = observable.create(s -> {
getDataFromServerWithCallback(args, data -> {
s.onNext(data);
s.onCompleted();
});
})
someData.subscribe( s -> System.out.prinltn("Subscriber 1: " + s ));
이게 느긋함의 힘이다. 2번의 구독을 실행할 수 있으며 원하는 상황에서 원하는 데이터를 뽑아낼 수 있다.
observable 의 특징
" 소비자가 호출하는 next()로 데이터를 끌어오는 대신 생산자가 onNext(T) 를 통해 데이터를 밀어내고, 모든 항목을 순회하는 동안 스레드를 블로킹하는 대신 onComplete() 콜백을 통해 정상 종료 신호를 보내며 호출 스택에 예외를 던지는 대신 onError(Throwable) 콜백을 통해 오류 이벤트를 방출한다. "
// 생산자가 소비자에게 밀어낸다 ?
// 생산자 Observable mouseEvent = ...;
// 소비자 mouseEvent.subscribe()
그렇다면 왜 observable을 사용하나?
반환해야 할 목록이 작으면 성능상 아무런 문제가 없다. 주관적인 선택일 뿐이지만 목록이 크거나 다양한 데이터 소스를 끌어와 목록 요소를 채워야 한다면 Observable 을 사용했을 때 성능이나 반응 시간 측면에서 이점이 있다.
또한 컬렉션 전체가 도착할 대까지 기다리지 않고 항목을 받는 대로 처리할 수 있기 때문이다. 이는 특히 상이한 네트워크 지연이 각 항목별로 영향을 미치는 경우에 그렇다.
Rx Observable이 다중 값 스트림을 다루기에는 좋지만 API를 설계하거나 사용할 때는 단일 값 표현이 단순해서 좋다.
오버헤드 : 어떤 처리를 하기 위해 들어가는 간접적인 처리시간, 메모리 등을 말한다. A처리 실행시 10초걸림 --> 안정성 고려하여 부가적인 B라는 처리를 추가 --> 처리시간이 15초걸림 : 오버헤드는 5초가 된다.
컴포넌트 : 소프트웨어의 재사용의 중요성과 필용성을 위해 나온 기술이 컴포넌트 기술이다. 컴포넌트는 독립적인 단위모듈이다.(소프트웨어에서의 재사용 단위) 하나의 컴포넌트는 하나의 클래스로만 작성될 수도 있지만, 여러개의 클래스로도 작성될 수 있다. 컴포넌트 개념을 잘 적용한 소프트웨어란 부품(인터페이스를 구현받은 클래스)만 바꾸어 주어도 오류없이 잘 작동되는 것을 의미한다.
소프트웨어에 대한 사용자 요구사항 중 초기부터 현재에 이르기까지 가장 중요하게 생각되었던 부분은 "자동화", "재사용" 처리이다!!
소프트웨어 규모의 대형화 및 복잡화로 개발비용이 증대 되었고, 일관되지 않은 개발방식!!으로 인해 유지보수성이 악화되었으며, 새로운 기술에 대한 교육과 훈련이 부족하여 SW 개발 및 운영에 많은 문제점이 발생되게 되었다.
이러한 문제를 해결하기 위해 재사용 방식을 높일 수 있도록 다양한 형태의 기술들이 발전되었다.
재사용 방식의 발전
1) 소스 재사용 : 초보적인 재사용 방식으로 과거에 유사한 문제를 코딩한 적이 있거나 비슷한 예제를 다른 코드에서 복사해서 사용하는 방법
2) 재사용 메소드 : 복사/붙이기 방식과 동일한 코드가 여러 클래스에서 나오는 것을 지양하기 위한 방법으로 C언어에서 하던 것처럼 자주 이용하는 기능을 라이브러리로 만들어 재사용하는 방식
3) 재사용 객체 : 기존의 재사용방식(소스 재사용, 재사용 메소드) 들은 자바뿐만 아니라 다른 언어를 사용할 때도 가능한 방식이나, 확장이 쉽지 않은 방식이었다면, 자바 언어에서는 클래스를 설계하고 상속/확장하는 방식으로 재사용을 진행한다.
4) 디자인패턴 : 클래스의 재사용방식이 객체의 수직적인 재사용 방식이었다면 디자인 패턴은 상황적인 문제를 해결해주는 재사용 방식이다. 공통적인 로직 문제에 대한 일반화된 해결 방법으로 클래스의 재사용이 아니라 메커니즘의 재사용으로 진행되는 방식이다.
5) SW 프레임워크 : 디자인패턴은 상황에 대한 해결은 가능하였지만, 시스템 전체에 대해서는 건건이 직접 패턴을 적용하여 문제를 해결해야 되었다. 이러한 문제점을 해결하기 위해 전체 시스템적 관점에서 표준화된 디자인 패턴을 적용한 설계 및 구현체가 SW 프레임워크이다.
SW프레임워크의 정의 : "무엇을 이루는 뼈대 혹은 기반 구조" --> 사전적 정의..
소프트웨어 개발위기에서 특정한 소프트웨어 개발 영역에서 자주 발생하는 문제점들을 해결하기 위해 경험적으로 축적된 설계 패턴들로써, Best Practice의 모음인 디자인패턴은 해결을 위한 많은 도음울 주었다. 그러나, 디자인 패턴은 실체가 아닌 개념적인 방법만을 제시하고 있는 점에 그 한계가 있다. 반면 프레임워크는 이러한 디자인 패턴을 실체로 구현한 일종의 솔루션이라고 할 수 있다. 최근에는 여기에 다양한 개발 가이드와 개발 도구 등도 함께 제공하여 프레임워크로 볼 수 있다.
전자정부 표준프레임워크의 개요
--> 표준 프레임워크 개발 이전 대부분의 공공정보화 사업에서 대기업의 SW 프레임워크가 도입, 활용되었다. 대기업 SW 프레임워크를 활용했을 때 발생되는 문제점으로는 폐쇄적인 정책으로 인해 자사 SW 프레임워크를 공개하지도 판매하지도 않기 때문에 상호 호환성을 보장하기가 매우 어렵다는 점이다. 즉, A사가 구축한 응용시스템에 대한 구조를 다른 B사가 파악하기 매우 어렵기 때문에 연속사업 혹은 유지보수사업의 사업자 변경을 원천적으로 어렵게 한다는 문제가 있었다. 또한 이미 특정 SW 프레임워크를 활용하여 구축된 소스코드를 다른 SW 프레임워크로 변경은 불가능하기 때문에 SW 프레임워크의 적용은 불가피하게 소스코드의 종속성 문제를 가지게 되었다. SW 프레임워크는 건축물의 철골과 같아서 SW 프레임워크를 교체한다는 것은 기존 건축물을 모두 허물고 철골부터 새로 만드는 것과 같다.
정보시스템이 특정 SW 프레임워크 사용으로 인해 사업자 및 기술 종속성을 가지는 문제점을 해결하기 위해,
개방형 표준을 채택하여 공동으로 활용할 수 있는 SW 프레임워크를 필요로 하게 되었다.
--> 전자정부 표준프레임워크 등장


전자정부 표준프레임워크는 공공사업에 적용되는 SW 프레임워크의 표준을 정립하고, 응용 SW 표준화, 품질 및 재사용성을 높일 수 있는 기반을 제공한다.
표준프레임워크는 실행, 개발, 관리, 운영 등 4개의 환경과 모바일 표준프레임워크, 그리고 공통컴포넌트로 구성되며,
참조프레임워크로 대표적인 오픈소스 SW프레임워크인 스프링 프레임워크를 채택하였으며!!!!, 이외에도 다양한 OSS를 적용/활용하여 구성되었다.
표준프레임워크는 정보시스템 개발을 위해 필요한 기능 및 아키텍처를 미리 만들어 제공함으로써 효율적인 어플리케이션 구축을 지원한다.

궁극적인 목적 :: "전자정부 표준프레임워크"는 공공사업에 적용되는 개발프레임워크의 표준 정립으로 응용 SW 표준화, 품질 및 재사용성 향상을 목표로 하며,
이를 통해 "전자정부 서비스의 품질향상" 및 "정보화 투자 효율성 향상"을 달성하고, 대.중소기업이 동일한 개발기반 위에서 공정한 경쟁이 가능하게 된다.
표준프레임워크는 기존 다양한 플랫폼(.NET, php 등)환경을 대체하기 위한 표준은 아니며, java 기반의 정보시스템 구축에 활용하실 수 있는 개발.운영 표준 환경을 제공하기 위한 것이다.
전자정부 표준프레임워크는 자바기반의 정보시스템 개발과 운영 시에 필요한 기본기능들을 표준화하여 미리 구현해 둔 것으로 개발자는 이를 활용하여 업무 기능을 구현한 후 조립함으로써 전체 시스템을 완성할 수 있다.
 JDK1.7 을 쓰네..
- 표준프레임워크는 표준으로써 목적을 만족하기 위하여 아래의 규칙을 준수하여 적용하여야 한다. 1. 실행환경은 원칙적으로 변경 없이 활용해야 함. 2. 개발환경은 기능의 변경과 추가에 제약사항 없음. 3. 공통컴포넌트는 변경 가능하나, 표준프레임워크 아키텍처 준수 필요
