Reference

• Spring IoC Containers – Types of Spring Container
• Spring 공식 문서
• Spring - IoC & DI

아직 많은 것을 알지 못하기 때문에 자세하고 정확한 내용은 제가 참조한 사이트나 따로 검색 또는 책을 통해 알아보는 것을 권장드립니다.

용어정리

Bean - 빌더 형식의 개발도구에서 가시적으로 조작이 가능하고 또한 재사용이 가능한 소프트웨어 컴포넌트

썬 마이크로시스템즈에서 정의한 자바빈. 명칭의 유래는 자바(java)를 개발할 때 개발자들이 커피를 너무 많이 소비하여 커피가 그들의 상징으로 사용하였고, 커피콩(beans)은 작은 커피콩처럼 코딩의 작은 부분들을 나타냅니다.

Spring Bean - 스프링 IoC 컨테이너로 DI(의존성 주입)을 통해 구성 요소를 관리하는 객체

자바빈, EJB의 빈과 비슷한 오브젝트 단위의 애플리케이션 컴포넌트를 말합니다. 하지만 스프링을 사용하는 애플리케이션에서 만들어지는 모든 오브젝트가 빈은 아닙니다. 스프링의 빈은 컨테이너가 생성과 관계 설정, 사용 등을 제어해주는 오브젝트를 가리킵니다.

Container(IoC container) - 개발자가 작성한 코드의 처리과정을 위임받은 독립적인 존재

적절한 설정만 되어 있다면 누구의 도움 없이도 개발자가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸을 컨트롤 해줍니다. 스프링에서는 IoC 방식으로 bean을 관리한다는 의미에서 bean factory나 application context를 가리킵니다.

IoC(Inversion of Control - 제어의 역전)

Inversion of Control(IoC)은 Dependency Injection(DI)라고 알려져 있기도 합니다. 엄밀하게는 DI는 아래의 그림과 같이 IoC 패턴 중 하나이지만 IoC의 개념을 잡는데 흔히 마틴 파울러의 ‘Dependency Injection Pattern’ 글( 번역 )을 참고하다 보니 그런 것 같습니다.

DL (Dependency Lookup) - 의존성 검색

• 저장소에 저장되어 있는 빈(Bean)에 접근하기 위하여 개발자들이 컨테이너에서 제공하는 API를 이용하여 사용하고자 하는 빈을 검색(Lookup)하는 것

DI (Dependency Injection) - 의존성 주입

• 각 계층 사이, 각 클래스 사이에 필요로 하는 의존 관계를 컨테이너가 자동으로 연결해 주는 것
• 각 클래스 사이의 의존 관계를 빈 설정(Bean Definition) 정보를 바탕으로 컨테이너가 자동으로 연결해 주는 것
• DL 사용시 컨테이너 종속성이 증가하여, 이를 줄이기 위해 DI를 사용

Setter Injection

• 객체를 생성 후 의존성 삽입 방식이기에 구현시에 좀 더 유연하게 사용
• setter()를 통하여 필요한 값이 할당되기 전까지 객체를 사용할 수 없음
• 스프링 프레임워크의 빈 설정 파일에서 property를 사용

<bean id="exampleBean" class="examples.ExampleBean">
	<property name="beanOne"><ref bean="anotherExampleBean"/></property>
    <!--setter injection using the neater 'ref' attribute -->
    <property name="beanTwo" ref="yetAnotherBean"/>
    <property name="integerProperty" value="1"/>
</bean>

<bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

public class ExampleBean
{
    private AnotherBean beanOne;
    private YetAnotherBean beanTwo;
    private int i;

    public void setBeanOne(AnotherBean beanOne)
        this.beanOne=beanOne;

    public void setBeanTwo(YetAnotherBean beanTwo)
        this.beanTwo=beanTwo;

    public void setIntegerProperty(int i)
        this.i=i;
}

Constructor Injection

• 생성자에 파라미터를 지정함으로 생성하고자하는 객체가 필요로 하는 것을 명확하게 알 수 있음
• 생성의 순서를 지켜야 하기 때문에 불편
• 스프링 프레임워크의 빈 설정 파일에서 constructor-arg 사용

<bean id="exampleBean" class="examples.ExampleBean">
	<constructor-arg><ref bean="anotherExampleBean"/></constructor-arg>
    <constructor-arg ref="yetAnotherBean"/>	<!-- 위 아래 동일한 방법 -->
    <constructor-arg type="int" value="1"/>
</bean>

<bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

public class ExampleBean
{
    private AnotherBean beanOne;
    private YetAnotherBean beanTwo;
    private int i;

    public ExampleBean(AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i)
    {
        this.beanOne=anotherBean;
        this.beanTwo=yetAnotherBean;
        this.i=i;
    }
}

Method Injection

• Singleton 인스턴스와 Non-Singleton 인스턴스의 의존 관계를 연결 시킬 필요가 있을 경우 사용하지만, 많이 사용되지는 않습니다.

Spring IoC Container

스프링 프레임워크의 IoC 컨테이너에는 크게

• Bean Factory (org.springframework.beans)
• Application Context (org.springframework.context)

두 종류가 있습니다.

1. Bean Factory

1. 소개

1.1 운영체제

• 운영체제(Operating System)란?

  – 컴퓨터 하드웨어를 관리하는 프로그램
  – 응용 프로그램의 토대를 제공해주는 프로그램
  – 사용자와 하드웨어 사이에 중간 매개체 역할 을 해주는 프로그램

• 운영체제 범위에 대한 정의
  하드웨어의 종류와 용도가 다양해서 OS의 범위는 모호하게 정의됩니다​
  정의 1) 운영체제를 구입하였을 때 포함되어 있는 모든 것
  정의 2) 항상 수행되고 있는 유일한 프로그램(보통 Kernel 이라고 한다)
  대체로 2번 째 정의를 사용함

그림에서 처럼 운영체제는 컴퓨터의 사용자와 컴퓨터 하드웨어 사이에 있기 때문에 운영체제를 바라보는 관점도 두 가지로 분류할 수 있습니다.

1.1.1 사용자 관점

• 컴퓨터의 용도 에 따라 OS의 설계 방향이 결정 됩니다.

  – 개인용 컴퓨터(Home PC user)
  – 메인프레임, 미니컴퓨터(Mainframe, minicomputer)
  – 워크스테이션(Workstation)
  – 휴대용 컴퓨터(Mobile devices)

1.1.2 시스템 관점

• 자원 할당자(resource allocator)
  컴퓨터 자원(CPU 시간, 메모리 공간, 파일 저장 공간, 입출력 장치)의 할당은 공정해야 하며 효율적으로 이루어져야 합니다.
• 제어 프로그램(control program)
  사용자 프로그램의 실행을 감독하여 오류와 컴퓨터 오용을 방지하고 입출력 장치의 제어와 동작을 관리 합니다.

1.1.3 운영체제의 목표

• 사용자에게 편리성 제공
• 컴퓨터 시스템의 효율적 운영

사용자에게 컴퓨터에서 프로그램을 효율적이고 편리하게 실행할 수 있는 환경을 제공 하는 것 입니다!!

1.2 메인프레임 시스템

1.2.1 일괄처리 시스템(1950)

Batch processing system이란 처리속도를 향상 시키기 위해 유사한 요구를 필요로 하는 여러개의 작업을 함께 모아 단일 작업으로 일괄 처리하는 시스템입니다

• 운영체제는 항상 메모리 에 상주하고, 주 임무는 하나의 작업에서 다음 작업으로 제어를 자동적으로 옮기는 것

• 작업을 실행하면 끝날 때까지 다른 작업을 못함

• 기계적 입출력 장치가 전자적 장치의 속도보다 상대적으로 느려 CPU가 종종 쉬는 경우가 발생

직접 접근(direct access)이 가능한 디스크의 도입 : Job scheduling과 multi-programming이 가능하게 됨

1.2.2 다중 프로그램 시스템(1960)

Multi-program system 이란 여러 개의 프로그램을 동시에 메모리에 적재하여 하나의 프로그램이 대기 상태가 되면 그 동안 다른 프로그램을 실행하는 시스템입니다

• 입출력과 프로그램의 실행을 병행으로 수행할 수 있어 CPU의 사용 효율(utilization)이 증가
• 다중 프로그래밍에서 운영체제는 사용자를 대신하여 의사결정을 수행해야 함
  – Job scheduling : 디스크에 있는 작업 저장소(Job pool)에서 작업을 선택하여 메모리로 옮기는 것
  – CPU scheduling : 실행 중인 작업이 대기 상태가 되었을 때 메모리에 있는 작업 중 하나를 선택하여 CPU에 할당하는 것
• 여러 프로그램이 동시에 메모리에 상주하므로 메모리 관리가 복잡
• Multi programming을 제공하는 일괄처리 시스템은 CPU의 사용 효율은 높였지만 사용자와 컴퓨터 간에 상호작용은 제공하지 못함

1.2.3 시분할 시스템(1960)

시분할(Time sharing) 또는 멀티태스킹(multi-tasking)은 다중 프로그래밍과 달리 정해진 시간이 되면 무조건 다음 순서의 작업을 실행하는 방식 으로 교대하는 시간이 매우 짧아 프로그램이 실행되는 동안 사용자는 컴퓨터와 상호작용이 가능한 시스템입니다

• 사용자와 시스템 간에 직접 상호작용이 가능한 시스템을 대화식 컴퓨터 시스템(inter-active computer system) 이라 하고 이런 시스템은 응답시간(response time)이 짧아야 함
• 여러 사용자가 동시에 컴퓨터를 사용할 수 있음
• 메모리에 적재되어 실행 중인 프로그램을 프로세스(process) 라고 함
• 많은 사용자의 프로그램을 동시에 수행하기 위해서는 주기억장치 의 용량으로는 부족
  디스크를 주기억장치의 보조 저장 장치로 활용으로 문제를 해결하며 가장 널리 사용되는 기법으로 가상 메모리(virtual memory) 가 있습니다

1.3 실시간 처리 시스템

Real time processing system 이란 프로세서 작동이나 데이터 흐름에 엄격한 시간 제약이 있을 때 사용되는 방식으로 데이터 처리 요구가 있는 즉시 수행하여 결과를 산출하는 시스템입니다

• 보통 특수 목적용(우주선 운행, 레이더 추적기, 핵물리학 실험, 은행의 온라인 업무)
  주의) 실시간과 빠르다는 것은 다른 개념!!
• 엄격한 실시간 시스템(hard real-time system) : 중요한 작업이 정해진 시간 내에 완료됨을 보장
• 완화된 실시간 시스템(soft real-time system) : 중요한 작업이 우선순위를 가지지만 엄격하게 정해진 시간 내에 완료됨을 보장하지는 않음

1.4 분산 처리 시스템

Distributed processing system 이란 다중처리 시스템과 마찬가지로 여러 프로세서(컴퓨터)를 사용하지만 밀결합 형태가 아닌 소결합(loosely coupled) 형태로 컴퓨터 버스나 클럭을 공유하지 않고, 네트워크를 통해 통신하여 하나의 작업을 처리하는 시스템입니다

• 네트워크는 사용하는 프로토콜, 망의 크기, 전송 매체에 따라 분류
  Ex) 망의 크기 : LAN, MAN, WAN

1.4.1 클라이언트-서버 시스템

• 서버 시스템은 크게 두 가지로 분류
  • 계산 서버 시스템(compute-server system)
    : 클라이언트로 부터 요청을 받아 그것을 대신 수행해 준 다음에 클라이언트에게 결과를 되돌려 줌
  • 파일 서버 시스템(file-server system)
    : 클라이언트에게 파일 시스템 인터페이스를 제공, 클라이언트는 이 인터페이스를 통해 파일을 생성, 갱신, 삭제

1.5 다중처리 시스템

Multi-processing system 이란 여러 개의 CPU와 하나의 주기억장치를 이용하여 여러 개의 프로그램을 동시에 처리하는 방식을 취하는 시스템입니다

• 병렬 시스템(parallel system) 또는 밀결합 시스템(tightly coupled system) 이라고도 함
• 처리율(throughput) : N개의 프로세서를 사용한다고 처리율이 N배 증가하지는 않음
• 경제성 : 여러 개의 단일 프로세서 시스템을 사용하는 것 보다 저렴
• 신뢰성 : 하나의 CPU가 고장나더라도 다른 CPU를 이용하여 업무를 처리할 수 있음
  수행되는 하드웨어의 수에 비례하여 서비스를 계속 제공할 수 있는 능력(graceful degradation)

1.6 집단 시스템

Clustered system 이란 병렬 시스템, 분산 시스템과 마찬가지로 다중 CPU를 사용하지만 여러 개의 시스템을 밀결합하여 사용한다는 측면에서 다른 시스템입니다

• 집단화(clustering)의 목적은 높은 가용성
• 대칭형 방식 : 각 컴퓨터는 모두 응용 프로그램을 수행하는 동시에 다른 컴퓨터의 상태를 감시
• 비대칭형 방식: 하나의 컴퓨터는 대기상태로 있고 나머지는 활성화되어 응용 프로그램을 수행

1.7 컴퓨팅 환경

• 초창기 컴퓨팅 환경은 중앙집중 –> 유선통신 기술의 발달로 분산 컴퓨팅 환경 등장 –> 무선통신 기술의 발달로 이동컴퓨팅(mobile computing) 환경 등장

• 인터넷의 발달로 현재의 컴퓨팅 환경을 웹 기반 컴퓨팅이라고 함

• 실시간 운영체제를 각종 기계와 장치에 내장하여 사용하는 컴퓨팅 환경을 임베디드 컴퓨팅(embedded computing) 환경이라고 함

Reference

Plain Old Java Object-위키
POJO(Plain Old Java Object)

아직 많은 것을 알지 못하기 때문에 자세하고 정확한 내용은 제가 참조한 사이트나 따로 검색 또는 책을 통해 알아보는 것을 권장드립니다.

POJO

✔ Plain Old Java Object : (직역) 평범한 옛날 자바 객체

처음에 단순히 정의를 검색하다보니 정말 단순한 자바 객체인 것 같은데 왜 굳이 POJO라는 단어를 사용하는지 혼란스러웠습니다. Stack Overflow 같은데서도 자바빈과 비교하는 토론이 있기도하고 솔직히 현재도 완전히 이해했다고는 할 수 없지만 제가 생각하는 내용을 적었습니다.

POJO의 탄생

Any fool can write code that a computer an understand. Good programmers write code that humans can understand.
컴퓨터가 이해하는 코드는 어느 바보나 짤 수 있다. 좋은 프로그래머는 사람이 이해하는 코드를 짠다.

Martin Fowler, <<리팩토링>>

POJO는 리팩토링과 애자일 소프트웨어 개발로 유명한 영국의 소프트웨어 개발자 마틴 파울러 가 2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 사용한 단어입니다. 그는 당시 EJB(Enterprise JavaBean) 보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이 있는데 왜 사람들이 EJB가 아닌 ‘평범한 자바 오브젝트’를 사용하기를 꺼려하하는지에 대해 의문을 가졌습니다 그래서 그의 생각을 널리 알리기 위해 그는 개발자들의 심리를 이용한 기발한 전략을 세웠습니다. POJO라는 용어를 만들고 이를 기반으로한 기술을 사용한다고 발표하여 다른 개발자들에게 마치 새로운 첨단 기술인 듯한 인상을 주었습니다.
정리하자면, 마틴 파울러는

• 자바 개발자들에게 단순하고 평범한 자바 오브젝트 사용을 권장 하고
• 자신의 생각을 효과적으로 전달 하기 위해 POJO라는 단어를 사용 했습니다
  Cf) 이를 계기로 다른 분야에서도 비슷한 용어들이 생긴 것을 보면 그의 전략이 성공적이 였다는 것을 쉽게 알 수 있습니다.
  • Plain Old Data Structures(PODS) - C++ 언어에서 오직 C 언어의 특징만 사용하는 경우
  • Plain Old Documentation(POD) - 펄(Perl) 언어에서 사용
  • Plain Old PHP Object(POPO) - PHP 언어에서 사용

이제 겨우 POJO의 형체가 희미하게 보이는 것 같습니다. 이 친구를 더 자세히 알기 위해선,

• EJB(Enterprise JavaBean)는 무엇이며 어떤 문제점이 있는가
• POJO란 그럼 그저 EJB 이전의 방식으로 돌아가는 것인가
  를 알아야 겠다고 생각했습니다.

Enterprise JavaBean의 등장

기술이 발전하면서 자바의 기초적인 JDK만으로 복잡해져가는 기업의 비즈니스 로직을 구현하는 것은 개발자들에게 부담이 되었습니다. 이러한 문제를 해결하기 위해 EJB가 등장하였고, ‘EJB를 사용하면 개발자는 로우레벨의 기술들에 관심을 가질 필요 없이 애플리케이션 개발을 쉽게 만들 수 있다’ 라고 EJB 1.0의 스펙에서 제시 되었습니다.
하지만 현실은 불필요할 만큼 과도한 엔지니어링으로 EJB는 실패한 케이스라고 많은 개발자들이 이야기합니다.

• 1% 미만의 애플리케이션에만 필요한 멀티 DB를 위한 분산 트랜잭션(무거운 JTA 기반의 글로번 트랜잭션 관리 기능)
• 고가의 WAS(CPU 당 몇 백에서 몇 천만 원) 필요
• EJB 컴포넌트는 컨테이너 밖에서는 정상적으로 동작하지 않음(많은 시간이 걸리는 수정-빌드-배표-테스트 과정 반복)
• 간단한 기능에 대해서 조차 자동화 테스트를 만드는 것이 거의 불가능
• EJB 스텍을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 포기해야 함

결국 마틴 파울러와 같은 많은 오피니언 리더들은 EJB와 같은 잘못 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바 언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO 방식 으로 돌아서야 한다고 지적하였습니다.

POJO 프레임워크

이때까지 내용을 되짚어 보면 POJO란 결국 단순하고 기본에 충실한 자바 오브젝트로 되돌아 가는 것인데 그렇다면 또다시 로우레벨의 API를 이용해 복잡한 코드를 작성해야 하고, 많은 기술적인 문제들을 애플리케이션 코드에 그대로 노출시켜 개발해야 한다는 문제로 돌아간다는 것이 아닌가? 하는 의문이 생길 것 입니다.
개발자들이 비즈니스 로직에만 집중할 수 있는 애플리케이션 복잡도를 제거하는 장점은 그대로 가져가면서, 객체지향적인 설계와 자동화된 테스트의 편의성 등을 다시 회복시키기 위해 등장한 것이 바로 POJO 기반의 프레임워크 입니다! 가장 대표적인 프레임워크 제품으로는 하이버네이트 와 스프링 이 있습니다.