Jan 9, 2017 - 왜 Spring service에 Interface를 만들어야 할까?

Service 부분에 interface를 사용하는 이유는 단위 컴포넌트로서 경계가 되는 부분이며, transaction 처리, exception 처리 등의 AOP 처리가 주로 service 부분에 지정되기 때문(?)


  1. Spring AOP는 두가지 Type의 Proxy를 지원 그 첫번째는 JDK의 Proxy 기능을 이용 두번째 방법은 CGLIB의 Enhancer 클래스를 이용
  2. JDK Proxy는 인터페이스에 대한 Proxy만을 지원 CGLIB의 Enhancer 클래스를 사용해서 만들면 되는것 그래서 위의 이유로는 설명이 안됨
  • 강제로 CGLIB 통한 프록시객체 생성방법
  • aop:config 태그에 다음 속성 추가 : proxy-target-class=”true”
  • 어노테이션의 경우
<aop:aspectj-autoproxy proxy-target-class="true" />

interface는 어느 시점에 생성하는 것이 적절한가?


“interface를 만드는 것에 대한 거부감은 스프링이 등장하면서 지식을 전파할 때 대부분의 책과 관련 문서에서 Service와 Dao에는 interface를 반드시 만드는 방식으로 예제 소스를 만들다보니 현재 대부분의 프로젝트에서 interface를 왜 만들어야 되는지도 모르는 상태에서 interface를 만드는 상황이 생기다 보니 발생한 것”

자바지기님의 글에서 보듯이 나도 아무 생각없이 만들어서 이용을 했었던것 같다 자바지기님의 포스팅에도 나와있듯이 나도 필요한시점에 만들어서 쓰는것이 좋을것 같다.

인터페이스가 필요한 이유를 스스로가 설명할 수 있고, 그로 인해 얻는 이득을 정확히 알 수 있을 때 도입하는 것이 좋다고 생각한다.

이것은 내 의견이고 지인중 한명은 생성후에(확장이 더이상 안된다고 보장할수 없음므로) 먼저 생성한다는 사람도 있다.

이런 고민을 한번쯤 해보는 것도 좋을것 같다.

Aug 10, 2016 - jbpm

jbpm은 kiegroup에 속해서 프로젝트가 진행 되고 있으며 bpmn 2.0기반으로 프로세스를 그리고 룰엔진은 drools, 워크밴치는 UberFire라는 프레임워크로 만들어져있고 Dashbuilder로 모니터링 요건을 작업하도록 되어 있다.

Aug 9, 2016 - jbpm 실행전략

jbpm Runtime strategy

총 3가지가 있는데 디폴트는 Singleton이다 성능테스트시에 was 쪽에 병목 현상이 일어나서 확인해본결과 아래의 내용대로 실행전략을 잘짜야겠다는 생각을 했다. 성능테스트를 위해 Per request로 모두 수정하여 테스트를 진행하였다.

Singleton stratege

KieSession 및 TaskService의 단일 인스턴스를 유지 합니다. 동기화로 인해서 성능이 저하되어 있긴 하지만 Thread safe하고 엑세스를 동기화 합니다. 아래와 같은 특징을 제공합니다.

  • RuntimeEngine 및 taskService의 단일 인스턴스.
  • 간단한 디자인과 컴팩트.
  • 동기화 액세스 하는 프로세스 엔진중 괜챃음
  • 하나의 KieSession instance의 모든 상태 object를 알수 있다.
  • RuntimeManager간에 사용되는 KieSession의 ID 추적은 같은 세션을 사용합니다. 아래 설정의 임시위치에 이 ID가 저장이 됩니다.
    • jbpm.data.dir
    • jboss.server.data.dir
    • java.io.tmpdir

Per request strategy

모든 요청에 대해 RuntimeEngine의 새로운 객체를 제공합니다. 요청이 완료되면 RuntimeEngine이 영구적으로 제거 됩니다.

  • KieSession 정보가 DB에서 제거됨. 아래와 같은 특징을 제공합니다

  • 모든 요청에 대해 완전히 격리된 프로세스 엔진 및 태스트 서비스를 운영함.
  • 높은 부하에 대한 적합
  • KieSession 요청의 수명 시간 동안 만 사용할 수 있음.

Per process instance strategy

KieSession과 ProecssInstance사이의 엄격환 관계를 유지합니다. 이 전력은 최대의 성능 및 가장 유연한 접근 방식을 제공. 아래와 같은 특징을 제공합니다.

  • ProcessInstance에 대해 동일한 KieSession을 제공하는것을 보장한다
  • ProcessInstance는 모든 프로세스 인스턴스 완료/중단 시 KieSession의 라이프 사이클을 병합
  • 프로세스 인스턴스는 해당 데이터에 액세스 할 수 있습니다.
  • Context instance 허용
    • EmptyContext 나 null : 사용가능한 프로세스 인스턴스 ID가 없다
    • ProcessInstanceIDContext : 프로세스 인스턴스가 생성된 후 사용
    • CorrelationKeyContext - 프로세스 InstanceID의 키를 대신해서 사용