EJB(Enterprise Java Beans)와 POJO(Plain Old Java Object) EJB(Enterprise Java Beans) 개념 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션 Java EE의 자바 API 중 하나 특징 동시 접속자 수가 많은 가운데 안정적인 트랜잭션이 필요한 사이트 구축시 사용하는 컴포넌트 기술 ex) 공공기관, 기상청, 병무청, 금융, 보험, 포털사이트, 게임사이트, 기업 등.. JSP, Beans를 사용한 시스템보다 속도는 느리지만, 개발시 개발자에게 많은 자동화된 기능을 제공하여 안정적인 분산 시스템 구축 및 제공을 용이하게 함 기초 기술(JSP, BEANS, RMI, Servlet, Serialization, Transaction, Connection Pooling)을 알면 학습 및 사용이 쉬움 EJB 규약을 집중적으로 습득하면 쉽게 EJB 컴포넌트 개발 가능 장단점 장점 단점 많은 동시접속자에 대한 안정성 지원 객체지향적이지 않음 처리 메소드를 컨테이너가 트랜잭션 자동 처리 복잡한 프로그래밍 모델 빈즈의 상태를 메모리에서 사용 여부에 따라 자동으로 활성화/비활성화 실행하여 관리 특정 환경·기술에 종속적인 코드 다층 구조 시스템 구축 가능 컨테이너 안에서만 동작할 수 있는 객체 구조 라이프 사이클, 보안, Threading 등의 서비스 제공 부족한 개발생산성 및 이동성 POJO(Plain Old Java Object) 특정 자바 모델이나 기능, 프레임워크 등에 종속되지 않고, 클래스 패스(class path)를 필요로 하지 않는 일반적인 Java Object 중량 프레임워크들(Java EE 등…)을 사용하게 되면서 해당 프레임워크에 종속된 “무거운” 객체를 만들게 된 것에 반발해서 사용하게 됨 2000년 9월 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등에 의해 사용되기 시작함 Spring과 Hibernate의 등장 EJB의 단점들로 인해 대표적으로 2가지의 Open Source가 등장하게 되었다.

RAID (Redundant Array of Inexpensive/Independent Disk)는 저장장치(디스크) 여러 개를 묶어 고용량,고성능 저장 장치 한 개와 같은 효과를 얻기 위해 개발된 기법이다. RAID는 여러개의 하드디스크를 함께 사용하는 방식을 말한다. 속도를 위해 함께 사용 할 수도 있고 안정성을 위해 함께 사용 할 수도 있고 둘다를 추구할 수도 있다. RAID-0 속도 추구만을 위한 레이드 구성이다. 단순히 하드 여러개에 데이터를 분산시켜서 한꺼번에 입출력을 수행하는 것이다. 이를 스트라이핑(Disk striping) 기술이라고 한다. 예를 들면 1~10까지의 숫자를 저장하는데, 하드1에는 1 3 5 7 9, 하드2에는 2 4 6 8 10을 저장한다.

객체지향 설계는 긴 세월과 수많은 시행착오를 거치며 5가지 원칙이 정리되었다. 이것은 객체지향 설계의 5원칙이라고 하며, 앞글자를 따서 SOLID라고 한다. SRP (Single Responsibility Principle) - 단일 책임 원칙 SRP 원칙은 클래스가 하나의 기능만을 가지며, 어떤 변화에 의해 클래스를 변경해야하는 이유는 오직 하나 뿐이어야 한다는 원칙이다. SRP에서는 책임자체가 분명해지기 때문에, 변경에 의한 연쇄 작용에서 자유로워 질 수가 있다. OCP (Open-Closed Principle) - 개방-폐쇄 원칙 OCP 원칙은 요구사항의 변경이나 추가사항이 발생해도, 기존 구성요소에는 수정이 일어나지 않고, 기존 구성요소를 쉽게 확장하여 재사용가능하도록 만들어야 한다는 원칙이다.

RuntimeException : Unchecked Exception 프로그램 실행 도중 발생하는 예외로, 프로그래머의 잘못으로 발생한다고 볼 수 있다. 배열의 범위를 넘어선 접근, Null 객채에 대한 접근, 잘못된 형 변환 등을 예로 들 수가 있다, 이러한 예외는 처리에 있어서 강제성을 띄지 않는다. IOException : Checked Exception 런타임 예외는 언제 에러가 발생하는지 알 수 없기 때문에 처리를 하지 않아도 되지만, IOException은 예외가 발생할 시점과 종류를 알 수 있기 때문에 반드시 처리를 해주어야 하는 강제성을 띄게 된다.

NestedRuntimeException RuntimeException의 root cause를 다루기 쉽게 래핑한 예외 클래스 내부적으로는 NestedExceptionUtils 라는 유틸리티 클래스를 이용한다. RestClientException 클라이언트 사이드의 HTTP 에러를 만났을 때 던져지는 기본 예외 클래스 RestClientResponseException 실제 HTTP 응답 데이터를 포함하고 있는 예외클래스들의 공통 기반 클래스 int 타입의 rawStatusCode를 가지고 있다. int rawStatusCode String statusText byte[] responseBody: getResponseBodyAsString() 메서드로 읽어올 수 있다. HttpHeaders responseHeaders String responseCharset HttpStatusCodeException HttpStatus (enum)를 기반으로 하여 만든 추상 클래스 getStatusCode() 메서드를 통해 HttpStatus를 읽어올 수 있다.

생성자 자동 생성 Lombok을 사용하면 생성자를 자동으로 생성할 수 있다. @NoArgsConstructor 어노테이션 : 파라미터가 없는 기본 생성자를 생성해준다. @AllArgsConstructor 어노테이션 : 모든 필드 값을 파라미터로 받는 생성자를 만들어준다. @RequiredArgsConstructor 어노테이션 : final이나 @NonNull인 필드 값만 파라미터로 받는 생성자를 만들어준다. 주로 의존성 주입(Dependency Injection) 편의성을 위해서 사용된다. @RequiredArgsConstructor 어노테이션 @RequiredArgsConstructor 어노테이션은 스프링 의존성 주입의 특징 중 한가지를 이용하는데 이는 다음과 같다. 어떠한 빈(Bean)에 생성자가 오직 하나만 있고, 생성자의 파라미터 타입이 빈으로 등록 가능한 존재라면 이 빈은 @Autowired 어노테이션 없이도 의존성 주입이 가능하다.