조직은 많은 상이한 이유로 인해서 서비스를 제공하거나 사용한다. 한편으로 비즈니스 프로세스를 최적화하기 위해서 공급망(supply chain)을 가로지르는 정보 흐름을 향상시키고 자동화하는 서로 다른 구성원을 한데 아우르는 것과 같은 비교적 명백한 비즈니스 요구사항이 될 수도 있다. 다른 한편으로는 서비스가 IT 시스템의 자원에 구조적인 상승효과를 가져다 주는데에 사용될 수 있으며 그러한 서비스 사용은 비즈니스에 꽤 투명해질 수 있다.

문제는 ROI를 정당화시키기 위해서 서비스가 제공하는 이익의 범위를 이해한다는 것이다. 첫번째 경우, 이익은 해당 비즈니스에 대해서 즉시적이며 명확해야 한다. 하지만, 두번째는 해당 비즈니스에 대한 이익은 덜 직접적이며 장기간을 요할 수도 있다.

이상적으로 조직은 SOA를 적용하기 위한 사유로써 양측을 추구해야만 한다. 즉, 비즈니스에 대해서 즉각적이고 명백하면서도 해당 비즈니스(와 통상 IT)에 대해서 덜 직접적이고 장기간을 요한다는 것이다. 하지만, 비즈니스 이해당사자들에게 장기간의 투자 회수에 대해서 설득하는 것이 더 어렵다는 것이다.

ROI를 정당화시키는데 도움을 주고자 비즈니스와 IT 모두에게 단기간과 장기간 모두를 설명하는 SOA 패턴에 대해서 설명하고자 한다.

패턴

요약

장점

Façade

수많은 기존 어플리케이션 원천들을 모으는 하나의 서비스

변경에 대한 범위를 감소시켜줌
실체화에 대한 투명성
현재 능력에 대한 변화와 합리화

Single Service

기업에 대한 정보, 프로세스, 정책 일관성의 단일 원천

일관된 실행 비즈니스 규칙과 정책
솔루션, 통합 비용, 재사용을 통한 테스팅 공수에 대한 적절한 감소
일관된 정보

Standardized Service

표준화된 서비스 명세 (산업, 업계)

상호운영성 보장
유용 기능 제공자에 대한 사용 촉진
서로 다른 제공자로 부터의 서비스 사용에 대한 유연성
여러 제공자를 가로지르는 정보에 대한 통합, 선택 및 비교의 단순화

Standardized Semantics

정보에 대한 의미론적인 수단이 기업, 업계, 혹은 산업 분류와 연합된다.

오해로 인한 에러 감소
단순화되고 자동화된 중재

Commodity Service

비즈니스에 핵심이 아닌 유용한 기능을 제공

핵심이 아닌 기능에 대한 위임
내부 개발에 대한 비용 감소

Common Component Service

서비스와 자동화 단위 간의 일대일 매핑 제공

에러를 줄이는 비즈니스 규칙에 대한 일관된 실행

Multi-Channel Service

다중 프로세스 혹은 채널을 지원하는 단일 서비스

새로운 채널 요청에 대한 빠른 응대
모든 채널에 대한 일관성

Real time Service Behavior

실시간 프로세스 실행에 대한 접근과 실시간으로 정확한 정보를 제공

STP와 RTE에 대한 장점
채널에 대한 정보와 프로세스 일광성
정보에 대한 정확성와 현재성 향상

Real Time Mediation

서비스 요청에 대한 중재가 정책과 상황에 따라서 실시간으로 결정됨.

오퍼레이터가 정책을 세팅함으로써 개발자 공수를 감소
이벤트 기잔 프로세스 행위 제공
더 높은 QoS 제공
현재의 정보 혹은 상태에 근거한 중재

Differentiated Service Behavior

하나의 서비스가 상황에 민감한 많은 행위를 제공함.

다중 서비스를 제공하는 데에 대한 비용과 복잡성 감소
차별화된 서비스에 대한 제공을 통한 부가 가치 창출

패턴 조합 예

조합

Façade + Single Service

Façade 는 Single Service 이기도 함.

Façade + Single Service + Real-Time Mediation

Real-Time Mediation은 Single Service Façade 를 여러 개의 기존 시스템과 연결하는데 사용됨.

Standardized Service + Standardized Semantics

서비스 시그너처와 내부 의미들이 연합됨

Standardized Service + Commodity Service

표준화가 유용성화를 유발시키는 지점

Façade + Single Service + Multi-Channel Service

모든 채널을 가로지르는 정보에 대한 일관성을 보장받기 위해서 multi-channel 서비스 역시 Single Service 이다. 차례로 Single Service는 원래 채널 기반이었던 기존 시스템을 가로지르는 Façade 이다.

Multi-Channel Service + Differentiated Service Behavior

각 채널에 차별화된 기능을 제공

Multi-Channel Service + Real-Time Service Behavior

채널을 가로지르는 정보에 대한 일관성 보장

ROI 범위

패턴

프로젝트

기업

투자 기간

Façade

Y

Y

단기

Single Service

Y

장기

Standardized Service

Y

Y

장기

Standardized Semantics

Y

단기/장기

Commodity Service

Y

Y

단기

Common Component Service

Y

장기

Multi-Channel Service

Y

Y

단기/장기

Real time Service Behavior

Y

단기

Real Time Mediation

Y

Y

단기

Differentiated Service Behavior

Y

Y

단기/장기


[출처] CBDi Journal, March, 2006

신고

'Homo Faber > Patterns' 카테고리의 다른 글

SOA Service Benefit Pattern  (0) 2008.03.13
비즈니스 패턴  (0) 2008.03.11
EJB3의 Entity Access Object 패턴  (0) 2008.02.22

비즈니스 패턴은 사용자들과 비즈니스 조직 및 어플리케이션, 접근하는 데이터 사이의 관계를 나타낸다.
다음 표와 같이 네가지 주요 비즈니스 패턴이 있다.

비즈니스 패턴

설명

Self-Service
(User-to-Business)

사용자가 인터넷이나 인트라넷을 통해 비즈니스와 상호작용하는 어플리케이션

단순한 웹 사이트 어플리케이션

Information Aggregation
(User-to-Data)

사용자가 데이터, 텍스트, 이미지 등과 같은 대용량 정보로부터 유용한 정보 추출이 가능한 어플리케이션

비즈니스 인텔리전스, 지식 관리, 웹 수집 (Web crawler)

Collaboration
(User-to-User)

인터넷이 사용자 간의 협업 작업을 지원하는 어플리케이션

이메일, 커뮤니티, 채팅, 화상 회의 등

Extended Enterprise
(Business-to-Business)

분리된 기업을 가로지르는 두 개 이상의 비즈니스 프로세스들이 연결된 어플리케이션

EDI, 공급 체인 관리 등

만일 모든 문제가 위의 네가지 분류에 말끔하게 속하게 된다면 매우 간편하겠지만, 현실은 종종 일을 더 복잡하게 만든다. 위의 패턴들은 대부분이 문제들이 기본적인 형태로 나누어졌을 때 위의 패턴들 중에 하나 이상에 속하게 될 것이라고 가정한다. 하나의 문제가 여러 비즈니스 패턴을 필요로 할 경우, e-business 에 대한 패턴은 통합 패턴의 형태로 부가적인 패턴을 제공한다.

통합 패턴

통합 패턴은 비즈니스 문제를 해결하기 위해서 여러 비즈니스 패턴들을 같이 엮여지게 하는 것을 가능하게 한다. 다음 표는 통합 패턴에 대한 개략적인 설명이다.

통합 패턴

설명

접근 통합

공통의 접근점을 통한 몇가지 서비스에 대한 통합

포탈

어플리케이션 통합

사용자의 직접 호출없이 여러 어플리케이션과 데이터 소스에 대한 통합

메시지 브로커, 워크플로우 매니저

이러한 비즈니스 패턴과 통합 패턴은 설치시 특화된 비즈니스 솔루션을 구현하는데 조합될 수 있으며, 이러한 것을 Custom 설계라고 한다.

Custom 설계

Custom 설계를 다음과 같은 그림으로 비즈니스 문제를 해결하는 형태를 표현할 수 있다.

Custom 설계를 설명할 때 사용하지 않는 비즈니스나 통합 패턴은 사용되는 패턴들보다는 옅은 색으로 표현이 가능하다. 예를 들어, 다음 그림에서 Collaboration 비즈니스 패턴이나 Extended Enterprise 비즈니스 패턴이 사용되지 않는 Custom 설계를 표현한다.

Custom 설계는 또한 비슷한 비즈니스 문제들을 가지는 도메인을 걸쳐서 여러 번 발생된다면 Composite 패턴이 될 수도 있다. 예를 들어, 위의 그림은 Sell-Side Hub composite 패턴으로 설명될 수 있다.

Composite 패턴

비즈니스와 통합 패턴에 대한 몇가지 공통된 사용이 Composite 패턴으로 식별되고 공식화된다. 다음 표는 식별된 Composite 패턴들을 나타낸다.

Composite 패턴

설명

전자 상거래

사용자 대 온라인 구매

www.macys.com

www.amazon.com

포탈

여러 정보 자원과 사용자에 대한 일관되고, 단절없는 개인화된 접근을 통합하는 전형적인 시스템

기업형 인트라넷 포탈 : 급여, 이익, 여행 비용과 같은 self-service 기능 제공

이메일이나 메신저와 같은 서비스를 제공하는 Collaboration provider

계정 접근

고객에게 자신의 계정 정보에 대한 24시간 계정 접근을 제공

온라인 중계 어플리케이션
전화 회사 계정 관리 기능
은행, 신용카드, 보험사 온라인 어플리케이션

거래 무역

판매자와 구매자가 공개된 사이트에서 상품과 서비스를 거래가 가능

판매자 측 – 판매자의 조달 시스템과 e-Marketplace의 상거래 기능 간의 상호작용
구매자 측 – e-Marketplace의 조달 기능과 공급자 간의 상호작용

판매측 허브
(공급자)

판매자는 e-Marketplace를 소유하고 웹 상으로 상품과 서비스를 판매하기 위한 수단으로 이를 사용

www.carmax.com (차량 구매)

구매측 허브
(구매자)

상품의 구매자가 e-Marketplace를 소유하고 웹을 통해 가망 판매자로부터 상품과 서비스에 대한 최상의 거래를 원하는 구매나 조달 예산을 저울질하는 수단으로 사용

www.wre.org
(WorldWide Retail Exchange)

위의 패턴들의 구성은 각각의 형태에 대해서 현존하는 기본적인 패턴이 있지만, Composite 는 부가적인 기준을 충족하기 위해서 쉽게 확장될 수 있다는 측면에서 가변적이다.

신고

'Homo Faber > Patterns' 카테고리의 다른 글

SOA Service Benefit Pattern  (0) 2008.03.13
비즈니스 패턴  (0) 2008.03.11
EJB3의 Entity Access Object 패턴  (0) 2008.02.22
세션빈의 비즈니스 로직에서 EntityManager API를 직접적으로 사용하는 방법은 비즈니스 로직 내에 엔티티 접근 코드를 산재하게 한다는 문제가 발생되는데, 이는 유지보수 측면에서 고역이다. Entity Access Object (EAO) 패턴은 비즈니스 로직에서 엔티티 접근 로직을 결합력을 적게 하며 코드 유지보수를 향상시킨다. 이는 비즈니스 로직에 영향을 주지 않고 내부의 엔티티 접근 코드를 쉽게 변경 가능하게 해준다. 만일 어플리케이션에서 EAO 패턴을 도입하면, JDBC나 EJB2 CMP, 혹은 다른 저장 메커니즘에서 JPA로 저장 티어 메커니즘 변경을 훨씬 쉽게 해준다.

선의 blueprint 웹 사이트에서 데이터 접근 객체에 대해서 더 자세하게 배울 수 있다. DAO의 내용에서 DAO를 EAO로 transfer object를 entity로 바꾸기만 하면 된다.

EAO 패턴은 비즈니스 로직에서 JPA를 사용함으로 데이터 접근 코드를 추상화시킨다. 보통은 도메인 객체(엔티티)에 대한 CRUD 오퍼레이션을 수행하는 모든 도메인 객체(엔티티)에 대해서 하나의 EAO 객체를 둔다. 아래 그림은 Bid 엔티티에 대해 정의된 EAO의 클래스 다이어그램이다.
사용자 삽입 이미지
그림에서 보는 바와 같이 BidEAO는 Bid 엔티티를 다루는 엔티티 접근 객체를 나타낸다. PlaceBid EJB와 같은 비즈니스 객체는 BidEAO를 사용해서 Bid 엔티티의 인스턴스를 저장하고 조회한다. 이는 엔티티를 저장하는 실질적인 저장 메커니즘을 PlaceBid EJB로부터 감춘다.

Bid 엔티티에 대해서 엔티티 접근 객체를 어떻게 구현하는지 살펴보자.

엔티티 접근 객체 구현
BidEAO 인터페이스에 대한 다음의 코드는 Bid에 대해서 수행될 수 있는 오퍼레이션을 노출시킨다.
public interface BidEAO {
   public Bid addBid(Item item, String bidId, double bidPrice);
   public Bid cancelBid(Long bidId);
   ...
}
개발자 중에는 엔터티 접근 객체에 대해 인터페이스를 사용하는 것은 많은 문제가 있다고 믿는 사람들이 있다. 하지만, EJB3 JPA와 Spring을 같이 사용할 때 많은 장점들이 있다. 인터페이스를 통해 EAO 인터페이스를 사용하는 클래스들에 영향을 미치지 않고 저장 제공 로직을 변경할 수 있다.

다음은 CRUD 오퍼레이션을 수행하는 EAO에 대한 구현 클래스이다.
public class BidEAOImpl implements BidEAO {
   private static String EM_NAME = "java:comp/env/actionBazaar";
   public BidEAOImpl() {}
   private EntityManager getEntityManager() {
      try {
         Context ctx = new InitialContext();
         return (EntityManager) ctx.lookup(EM_NAME);
      } catch (Exception e) {
         e.printStackTrace();
         return null;
      }
   }

   public Bid addBid(Item item, String bidderId, double bidPrice) throws BidException {
      EntityManager em = getEntityManager();
      if (em != null) {
         Bid bid = new Bid();
         ...
         em.persist(bid);
         return bid;
      }
      ...
   }

   public Bid cancelBid(Long bidId) {
      ...
   }
}
구현 클래스에서 코드는 직관적이다. getEntityManager 메소드는 컨테이너 관리(container-managed) EntityManager의 인스턴스를 검색하는 JNDI lookup을 사용하고 있다. EAO은 일반 POJO이기 때문에 DI(dependency injection)을 사용할 수 없으며, 따라서 EntityManager의 인스턴스를 검색하기 위해서 JNDI를 사용했다. 어플리케이션 관리(application-managed) 엔티티 매니저를 사용하기 원한다면 적절한 형태로 변경해야 한다. 나머지 코드는 비즈니스 로직에 있던 엔티티 접근 코드를 EAO로 옮기는 것에 불과하다. addBid 메소드는 EntityManager의 인스턴스를 얻기 위해서 getEntityManager를 사용하며 Bid 엔티티의 인스턴스를 저장한다.

EAO 코드에 대한 클라이언트가 PlaceBid EJB 라고 가정하자. 다음은 PlaceBid EJB의 코드이다.
@PersistenceContext(unitName="actionBazaar", name="actionBazaar")
@Stateless
public class PlaceBidBean implements PlaceBid {
   public Long addBid(String userId, Long itemId, double bidPrice)
         throws BidException {
      ...
      BidEAO bidEAO = EAOFactory.jpa.getBidEAO();
      Bid bid = bidEAO.addBid(item, userId, bidPrice);
      return bid.getBidId();
   }
}
위의 코드에서 EntityManager의 인스턴스를 얻기 위해 EAO에서 JNDI lookup을 사용했기 때문에 @PersistenceContext annotation을 사용하여 저장 단위(persistence unit)을 참조하고 있다. 그 다음에 EAO의 인스턴스를 생성하기 위해서 EAOFactory를 사용했다. EAO의 인스턴스를 생성한 후, 엔티티 오퍼레이션을 수행하기 위해 이를 사용할 수 있다.
코드에서 EAO 인스턴스를 생성하는 EAOFactory를 사용했다. 다음은 JPA를 통해서 EAO 인스턴스들을 생성하는데 사용할 수 있는 간단한 EAO factory이다.
public abstract class EAOFactory {
   public static final EAOFactory jpa = new JPAEAOFactory();
   public abstract ItemEAO getItemEAO();
   public abstract BidEAO getBidEAO();
   ...
}

public class JPAEAOFactory extends EAOFactory {
   public JPAEAOFactory() {}
   public BidEAO getBidEAO() {
      return (new BidEAOImpl());
   }
}

비즈니스 로직과 저장 코드간에 느스한 결합도를 갖는 장점은 명확하다. 만일 다른 저장 티어로 변경하고자 한다면 EAO 구현 클래스를 변경하기만 하면 된다. FireStorm/DAO와 Hibernate의 hbm2java와 같은 많은 도구와 유틸리티들이 엔티티에 대한 EAO를 생성하는데 도움을 주며, 따라서 EAO를 도입하는 것은 비교적 큰 일은 아니다. 이는 비록 몇개의 추가 클래스를 관리하는데 부가적인 코딩이 필요하지만, 따라하는데 좋은 기법이다.

EAO로 세션빈 사용하기
EJB3 세션빈은 POJO이기 때문에 엔터프라이즈 어플리케이션을 Java EE 컨테이너에 배포한다면 이들이 좋은 EAO의 후보들이다. EAO는 주입(injection)을 통해서 작업을 단순화시킬 수 있으며 EAOFactory를 사용할 필요가 없다. 만일 세션빈을 사용해서 EAO를 구현하기로 결정했다면 코드는 다음과 같은 것이다.
@Stateless
public class BidEAOImpl implements BidEAO {
   @PersistenceContext(unitName = "actionBazaar")
   private EntityManager em;
   public BidEAOImpl() {}

   public Bid addBid(Item item, String bidderId, double bidPrice) {
      Bid bid = new Bid();
      ...
      em.persist(bid);
      return bid;
   }

   public Bid cancelBid(Long bidId) {
      ...
   }
}
위의 코드는 이전 것보다 더 단순해보이며 유지하기 더 쉽다. EAO를 사용하는 코드도 다음과 같이 단순해진다.
@Stateless
public class PlaceBidBean implements PlaceBid {
   @EJB private BidEAO bidEAO;
   public Long addBid(String userId, Long itemId, Double bidPrice)
         throws BidException {
      ...
      Bid bid = bidEAO.addBid(item, userId, bidPrice);
      return bid.getBidId();
   }
}
세션빈을 사용한 EAO 구현은 단순하고 일반적인 것 처럼 보인다. 어떤 사람들은 이와 같은 방법에 대해서 불평을 하지만, EAO에 대한 세션빈을 사용하는 부수 효과로 자동적으로 선언적인 트랜잭션이나 컨테이너 관리 EntityManager를 받아들이기 때문에 심각하게 고민할 필요가 있다. 가벼이 여길 것은 아니다.
신고

'Homo Faber > Patterns' 카테고리의 다른 글

SOA Service Benefit Pattern  (0) 2008.03.13
비즈니스 패턴  (0) 2008.03.11
EJB3의 Entity Access Object 패턴  (0) 2008.02.22

+ Recent posts