목차 >> Glue Framework 아키텍처 
+- 시스템 구성도 
+- Glue Framework 동작 원리

2장 Glue Framework 아키텍처

System 구성도

그림 : 아키텍처
아키텍처

Presentation Layer

Presentation Layer는 화면(UI)와 Controller(Web F/W) 로 나눕니다.

  1. UI(화면) : UI는 JSP, MiPlatform, Gauce, Trustform, Flex, jQuery, jQuery Mobile등을 활용하여 개발할 수 있으므로 개발자(혹은 프로젝트)가 이용하기 위한 편한 화면 프로그래밍 방식을 선택할 수 있습니다. Glue F/W 에서 선호하거나 추전하는 프로그래밍 방식은 없습니다. 다만 편의를 위해 특정회사의 요청으로 특정 화면 프로그래밍을 위한 어댑터( MiPlatform, Trustform등)을 제공할 수 있습니다.
  2. Controller : Glue Framework 5의 Controller 부분은 Spring MVC 를 채택하고 있습니다. Glue Framework 3 에서 사용되었던 Struts 기능도 함께 제공하지만, 본 문서를 비롯한 Glue Framework 5 와 관련된 모든 산출물은 Spring MVC를 이용하여 개발되었습니다. Controller부분은 Business Service 를 연결하는 부분을 구현 제공하며, Controller Class가 이 부분에 해당됩니다. Controller가 하는 일은 화면의 Flow를 Control 하고 Glue Framework의 Service를 호출 하는 역할을 수행합니다. 또한 Glue Framework은 화면을 Control 하는 다른 MVC Framework(Struts등)에 대한 구현을 제공하여 Glue Framework을 이용하는 개발자 및 설계자가 이 부분에 대해 추가로 개발 및 Architecture를 수립할 비용을 감소 시킬 수 있습니다.

Business Layer

Glue Framework에서 Service 부분에 해당하는 부분으로 UI 부분과 더불어 개발자가 비즈니스 로직에 맞추어 개발해야 하는 부분입니다.
Business Layer는 POJO(Plain Old Java Object)로 구현되어야 합니다. Glue Framework의 Service는 모두 POJO로 구현되어 있고 Model Layer와 Presentation Layer와의 모든 연결은 Interface로 구현되고 Data또한 Glue의 통합 Context를 통해 Framework의 Coupling을 최소화 하였습니다.
개발자는 Model Layer 혹은 Presentation Layer의 변경이 발생하더라도 Business Layer의 코드 변경은 최소화 되어야 하기 때문에 Business Layer를 구현할 때 Model Layer나 Presentation Layer의 어떠한 Class 및 Interface도 가져다 구현하지 않습니다.

Persistent Layer

Model Layer 의 Framework을 Implements 하여 제공하고 표준 Interface만을 제공하여 Coupling을 최소화를 제공합니다.
DB를 Handling 하는 부분으로 모든 DB를 동일하게 처리하기 위해 JDBC 표준으로 구현되어 있습니다.

모든 Data Handling 하는 부분을 Interface화 하여 Model Layer의 Framework이 변경되어도 Business Layer의 Service Code는 변경이 최소화 되게 하는 역할을 담당합니다. (DAO Class)
이를 위하여 개발자는 Glue Framework에서 제공되는 DAO 통해 Data Handling을 하여야 합니다.

Integration Layer

외부의 다른 시스템과 데이타를 송수신하기 위한 부분으로 기본적인 HTTP 통신을 비롯 웹서비스(JAX-WS, RESTful)을 이용한 형태, u_CUBE와 같은 EAI와 송수신을 위한 인터페이스를 제공하여 개발자가 간단한 셋팅만으로 별도의 개발과정 없이 이용할 수 있도록 제공합니다.

Glue Framework 동작 원리

화면의 경우 해당 URL에 의해 web.xml의 <servlet-mapping> tag에 정해진 dispatcher로 분기합니다. 현재 설명된 예제에서는 "mvc"라는 URL 확장자에 의해 해당하는 servlet mapping은 "dispatcher" 으로 "org.springframework.web.servlet.DispatcherServlet" class 를 이용하고 있습니다.

그림 : Web 동작원리
Web 동작원리

Web Framework Wrapper

SpringMVC의 Controller를 확장
  1. JSP 로 부터 Submit이 발생되면 Spring Framework의 해당 Controller가 실행됩니다. 모든 Activity type(Class)는 Glue Framework에서 제공되는 Action Class를 상속 받은 Class 이어야 합니다.
  2. JSP는 반드시 자신의 Service를 지정하여야 합니다. 지정 방법은 Hidden Tag로 다음과 같이 지정할 수 있습니다.
<input type="HIDDEN" name="ServiceName" value="EmpService"/>

GlueSimpleController Class는 Spring Framework에서 Glue Framework을 호출하기 위한 Wrapper Class로서 다음과 같은 역할을 수행합니다.

  1. Glue Context 생성
    • GlueContext는 Request 마다 생성되는 Data Transfer Object입니다. GlueContext는 JSP 부터 Activity 까지 모든 Data의 공유 통로이고 Web에서 GlueContext는 Request, Session, Attribute Data까지 포함합니다.
    • GlueContext는 Spring Framework의 Application Context를 Loading하고 Bean Object를 서비스 합니다. 개발자는 public static GlueBeanFactory getBeanFactory() Method를 통해 Application Context의 Bean을 획득할 수 있습니다. 대표적인 사례는 DAO Class를 이용하는 것입니다.
    • glue.properties의 Loading 및 Property 에 대한 Access 제공
    • request,session Data를 GlueContext에 저장
  2. GlueBizController 호출
    • GlueBizController는 GlueContext를 Parameter로 요구합니다. GlueBizController는 Request Data (“<input type="HIDDEN" name="ServiceName" value="emp-service"/>”)에 근거해 Service를 Loading 하게 됩니다. 즉 GlueContext에서 ctx.get(“ServiceName”);으로 Return 된 “emp-service”를 Memory에서 찾고 없으면 emp-service.xml 파일을 읽어서 Loading 합니다.
  3. View Page Control 기능
    • Activity에서 “ctx.put(GlueWebConstants.VIEW_PAGE,"showDept");” 과 같이 View Page 를 지정하였다면 GlueController에서는 해당 Page를 View Page로 사용합니다.
  4. Exception 처리
    • Service 실행 중 Exception이 발생하였을 경우 servlet.xml에서 해당 Controller에 대한 errorPage가 정의 되었다면 errorPage가 View Page로 설정되며 errorPage가 정의 되어 있지 않다면 일반 설정(viewPage)을 따릅니다.
    • Interceptor 설정을 통해서 별도의 에러 처리 로직을 구현 할 수도 있습니다.

Service 처리 부분

Service는 하나의 Transaction으로 처리되는 Business 단위로 구성됩니다.
모든 개발 부분은 Service의 Activity로 구현되고 그 결과는 GlueContext를 통해 공유합니다.

그림 : Activity Diagram
Activity Diagram
  1. GlueBizController 에서 GlueContext에 있는 ServiceName을 가지고 GlueServiceLoader를 통해 Service를 조회 합니다.
  2. GlueServiceLoader는 Cache에서 해당 Service를 조회하고 없으면 ServiceName + .xml 파일을 Loading 합니다.
  3. GlueBizController는 Service.xml 내용을 분석하여 각각의 Activity Class들을 실행합니다.
  4. GlueBizController는 Service에서 “<transaction-manager id="tx1" commit="true"/>” 로 등록되어 있는 transaction-manager를 이용해 Commit 또는 Rollback 을 수행합니다.
  5. Logging 처리 : Controller는 Service의 수행 시간과 Activity의 수행시간 Exception의 내용 등을 Logging 합니다.

Non-UI 처리 부문

NonUI는 시작이 Message 또는 File Message로부터 수신되어 Framework의 Service를 처리합니다.

Message 수신을 위한 별도의 Servlet( HttpReceiver )을 이용하며, 다음과 같이 web.xml 에 정의 할 수 있습니다.

<servlet>
    <servlet-name>NonUIReceiver</servlet-name>
    <servlet-class>com.poscoict.glueframework.web.GlueHttpReceiverAdapter</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>uCubeReceiver</servlet-name>
    <url-pattern>*.msg</url-pattern>
</servlet-mapping>
그림 : Activity Diagram
Activity Diagram

^L

Prev Home Next