 | 난이도 : 중급 Stephen Brodsky, Senior Technical Staff Member, IBM Marcia Stockton, Senior Technical Staff Member, IBM
2005 년 6 월 28 일
서비스 데이터 객체(SDO)를 활용하여 서비스 중심의 소프트웨어에서 데이터 액세스와 표현을 간단히 처리할 수 있다.
SDO는 다양한 데이터 액세스 모델을 일관된 추상화로 대체했다. 서비스 구현에 의해 사용되는 비즈니스 데이터의 구현, 검색,
업데이트, 삭제를 위한 하나의 일관된 추상화가 생긴 것이다.
서비스 데이터 객체(Service Data Objects)
SDO는 다양한 데이터 액세스 모델을 일관된 추상화로 대체했다. 서비스 구현에 의해 사용되는 비즈니스 데이터의 구현,
검색, 업데이트, 삭제를 위한 하나의 일관된 추상화가 생긴 것이다. SDO(Service Data Objects 2.0와
차세대 데이터 프로그래밍: 서비스 데이터 객체-참고자료)는 IBM 서비스 지향 아키텍처(SOA)의
기본 개념이다. SDO를 이용하면 특정 백엔드 데이터 소스에 액세스 하는 상세한 방법까지 개발자가 신경 쓸 필요가 없기 때문에
개발자들은 비즈니스 로직에만 집중할 수 있다.(관계형 데이터를 웹 애플리케이션에 통합하기, 자바 환경에서의
차세대 데이터 프로그래밍, 기업 정보 통합 기술과 서비스 데이터 객체 사용하기 - 참고자료).
SDO는 BEA Systems, Inc.와 합동으로 만든 스팩이고 WebSphere® Application Server와
Rational® Studio 툴 같은 IBM 제품들에 널리 적용되어 있다. Java™ DataBase Connectivity(JDBC)는
Structured Query Langauge(SQL) 문을 실행하는 자바 인터페이스이다. 현재 이 프로그래밍은 JDBC,
Web Services Description Language-defined(WSDL) 서비스, Enterprise JavaBeans(EJB) 등 자바로 작성된
서비스 구현들을 모델링 한다.
SDO는 관계형 데이터베이스, eXtensible Markup Language(XML) 데이터 소스, 웹 서비스, 기업 정보 시스템(EIS) 등,
이종의 데이터 소스에서 데이터를 조작 및 액세스 할 수 있는 일관된 방식을 정의하고 있다. 이 모두는 데이터 그래프의 개념에
기반하고 있다. 데이터 그래프는 데이터 소스에서 분리되는 나무 구조로 된(tree-structured) 객체들의 모음이다.
SDO는 애플리케이션 아키텍처 전반에 걸쳐 사용된다.
|
애플리케이션 아키텍처
|
SDO가 사용되는 방법
| | SOA |
| | 데이터 액세스 |
- SDO는 관계형, XML, EJB, Java Data Objects(JDO), Hibernate 데이터 소스에 액세스 한다.
- SDO는 데이터 전송 객체(DTO), 다시 말해서 밸류 객체(Value Objects) 객체이다.
| | 웹 서비스 |
| | 메시징 |
| | XML | 다음과 같은 상황에 SDO를 사용한다.
- XML을 실행하는 애플리케이션
- XML 파일, 문서, 리소스, 메시지에 액세스 할 때
| | 커넥터/어댑터(EIS, CICS) |
| | EJB |
- SDO는 DTO(Value Objects)이다.
- Java 2 Enterprise Edition(J2EE) 디자인 패턴
| | ADO.NET |
- ADO DataSet은 SDO 데이터 그래프의 일부이다.
| | Enterprise Service Bus(ESB) |
| | 교차 언어 프로그래밍 모델 |
- 완전한 애플리케이션은 티어(tier)와 언어를 확장한다.
- 많은 언어 기능 세트에 같은 프로그래밍 모델.
| | 모델 중심 아키텍처(MDA) |
- SDO 모델(Type과 Property)은 Unified Modelling Language(UML) 클래스와 컴포넌트로 정의된다.
- SDO 애플리케이션은 UML 시퀀스, 플로우, 상태, 협업을 따른다.
| | 자바 |
- SDO는 POJO 인터페이스를 가진 "평범하고 오래된 자바 객체"(POJO)이다.
|
SOA에서, 애플리케이션은 데이터 소스와 직접 연결되지 않는다. 대신, 데이터 액세스 서비스(DAS)라고 하는 매개체에
액세스 하여 데이터 그래프를 받는다. DAS는 특정 유형의 데이터 소스의 기술 상세를 핸들하는 서비스이다.
클라이언트를 위해서 데이터를 SDO 그래프로 변형한다. 클라이언트 애플리케이션은 데이터 그래프와 인터랙팅하여
데이터를 얻고 데이터를 변경한다. 원래의 데이터 소스를 업데이트 하기위해 애플리케이션은 업데이트 된 데이터를
다시 DAS로 보내고 결국 데이터 소스와 인터랙팅하게 된다. 일반적으로 런타임은 DAS의 구현을 제공하고
애플리케이션 개발 툴은 데이터 그래프를 지원한다.
SDO는 기술 혼합(변화하는 기술에 따라가기 위해 애플리케이션을
재작성 하는 것(참고자료))을 피한다. 다시 말해서, 기술의 변화로부터 비즈니스 애플리케이션을
고립시키기 위해 데이터 액세스 상세를 캡슐화한다. 데이터베이스에서 제품 디스크립션을 읽고 이를 웹 페이지로서
디스플레이 하도록 설계된 자바 웹 애플리케이션을 생각해 보자. 데이터베이스에 있는 제품 디스크립션에 액세스 하기 위해서
애플리케이션은 JDBC를 사용한다. 애플리케이션과 데이터베이스 사이에 웹 서비스를 둔 상태에서 나중에
애플리케이션 토폴로지가 변한다면? 이제 그 애플리케이션은 더 이상 JDBC를 사용하여 데이터에 액세스 할 수 없고
웹 서비스 애플리케이션 프로그래밍 인터페이스(API)(Document Object Model(DOM))나
XML-Based Remote Procedure Call(JAX-RPC)용 자바 API를 대체하기 위해 엄청난 작업을 해야 한다.
SDO는 이러한 문제를 방지한다. SDO로 작성된 애플리케이션은 변경될 필요가 없다.
게다가 SDO는 애플리케이션, 툴, 프레임웍을 실행하는 메타데이터 API를 제공하여 통일된 방식으로 데이터 모델을 검사한다.
DAS는 백엔드 메타데이터를 표준 SDO 포맷으로 변형시킨다.
SDO 유형은 자바 인터페이스, XML 스키마, 관계형 테이블과 칼럼, EJB, COBOL 레코드, 메시지, UML에 의해
정의될 수 있다.(참고자료-Catalog of OMG Modeling and Metadata Specification).
구현자는 선호하는 시스템 유형을 선택할 수 있다. 간단한 자바와 XML 데이터 유형은 유효한 SDO 데이터 유형이면서
자바 구현자에게 유용하다. SDO는 동적/정적 데이터 액세스 모델을 지원한다.
- 동적 모델(디폴트)로는 데이터 그래프에 데이터 엘리먼트를 이름(스트링)으로 설정할 수 있다.
이는 SDO의 유형이 컴파일 시 알려지지 않거나 프로그램이 전개된 후에 새로운 속성이 추가될 때 특히 유용하다.
클라이언트 프로그램이나 서비스는 SDO를 쿼리하여 구조에 대해 파악하고 어떤 엘리먼트든 읽고 업데이트 한다.
예를 들어, 개별 SDO에 액세스 하려면 일반적인 SDO 액세스 함수를 작성하여 이를 엘리먼트 스팩의 메타데이터와 함께
파퓰레이트한다. SDO는 또한 XML Path Language(XPath) 식의 일부를 사용하여 많은 DataObject들을 빠르게 트래버스한다.
customer[1]/address/zip은 customer DataObejct의 집(zip) 코드를 빠르게 액세스 한다.
- 정적 모델은 네임드 자바 인터페이스와 유형화 된 자바 인터페이스를 사용한다.
각 데이터 엘리먼트는 자신의 "getter"와 "setter" 메소드를 갖고 있다.
툴은 SDO 유형(Type)과 속성(Property)에서 정적 인터페이스를 만든다.
SDO는 데이터 표현에 중요하다. 비록 그림에는 데이터 소스가 없더라도 말이다. 웹 서비스,
Java Message Service(JMS) 메시지,
XML 파일들과 교환되는 XML 메시지도 그 사용 예제라 할 수 있다.
예제
사용자 데이터를 포함하고 있는 데이터 객체를 정의하는 다음 예제는 자바나 XML을 사용하면서
SDO를 정의하고 사용하는 것이 얼마나 쉬운지를 증명하고 있다. 예제 1(XML)은 SDO 유형의 기초이다.
예제 1. SDO 유형 정의(XML 버전)
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.myvalue.com"
targetNamespace="http://www.myvalue.com">
<element name="customer" type="Customer"/>
<complexType name="Customer">
<sequence>
<element name="customerID" type="string"/>
<element name="firstName" type="string"/>
<element name="lastName" type="string"/>
<element name="stockSymbol" type="string"/>
<element name="stockQuantity" type="int"/>
</sequence>
</complexType>
</schema>
|
예제 2의 자바 인터페이스는 정적 인터페이스의 사용법을 설명하고 있다.
예제 2. SDO 유형 정의(자바 버전)
public interface Customer {
String getCustomerID();
void setCustomerID(String customerID);
String getFirstName();
void setFirstName(String firstName);
String getLastName();
void setLastName(String lastName);
String getStockSymbol();
void setStockSymbol(String stockSymbol);
int getStockQuantity();
void setStockQuantity(int stockQuantity);
}
|
일단 SDO 유형이 정의되면 그 유형 정의를 SDO 데이터 팩토리로 전달하여 인스턴스로 만들 수 있다.
(데이터 객체에 스토리지를 할당한다.) 이 팩토리는 단순히 런타임의 컴포넌트이다. 이것의 함수는 SDO 유형 정의에서
SDO 데이터 객체들을 인스턴스로 만든다.
예제 3과 예제 4는 XML 스키마 네임스페이스와 복잡한 유형 이름
또는 자바 인터페이스 클래스(예제 2에서 정의됨)를 인자로서 전달하여 SDO를 만드는 방법이다.
예제 3. XML Schema 네임스페이스와 복잡한 유형 이름으로 SDO 만들기
DataObject customer = DataFactory.INSTANCE.create("http://www.myvalue.com", "Customer");
|
예제 4. 자바 인터페이스 클래스를 가진 SDO DataFactory로 SDO 생성하기
Customer customer = (Customer) DataFactory.INSTANCE.create(Customer.class);
|
SDO가 인스턴스로 만들어진 후에 구현은 여기에 액세스 할 수 있다. 예제 5와 예제 6의 코드 샘플은 Customer SDO로의 동적/정적 액세스이다.
예제 5. SDO로의 동적 액세스
DataObject customer = ... ;
customer.setString("customerID", customerID);
...
customer.setInt("stockQuantity", 100);
String customerID = customer.getString("customerID");
...
int stockQuantity = customer.getInt("stockQuantity");
|
예제 6. SDO로의 정적 액세스
Customer customer = ... ;
customer.setCustomerID(customerID);
...
customer.setStockQuantity(100);
String customerID = customer.getCustomerID();
...
int stockQuantity = customer.getStockQuantity();
|
XML 파일 서비스와 관계형 데이터베이스로의 액세스 예제를 통해 SDO의 프로그래밍 모델이 얼마나 간단한지를
더 알아보기로 하자. 기술적인 차이가 있지만 애플리케이션들은 비슷하다. 애플리케이션 개발자는 비즈니스 로직에 집중하고
서비스가 구현 상세를 핸들하도록 할 수 있다.
예제 7. XML 파일 서비스
이 간단한 예제는 데이터를 XML 파일에서 SDO 데이터 그래프로 로딩하고 데이터를 프린트 및 업데이트 한 다음
이것을 파일에 작성한다.(이 작업의 목적은 "Adam"을 "Kevin"으로 바꾸는 것이다.)
루트 XML 엘리먼트와 많은 값을 가진 customers 속성에 상응하는
루트 customers 데이터 객체로서, XML 파일이 읽히도록 정의한다.
Customers에는 XML 파일에 각 커스터머 엘리먼트당 하나의 데이터 객체를 포함하고 있다.
각 커스터머는 두 개의 속성( SN과 firstName)이 있다.
|
<customers xmlns="http://customers.com">
<customer SN="1" firstName="Adam" />
<customer SN="2" firstName="Baker" />
</customers>
|
| | 파일 데이터를 읽는다. |
DataObject root = xmlService.load(InputStream);
|
| | 커스터머 데이터 객체 리스트를 보고 각 객체의 번째 이름을 프린트한다. |
Iterator i = root.getList("customer").iterator();
while (i.hasNext()) {
DataObject cust = (DataObject) i.next();
String name = cust.getString("firstName");
System.out.println(name);
}
|
| 첫 번째 커스터머 데이터 객체의 firstName 속성을 Kevin으로 설정한다.
미들웨어는 변경 요약을 업데이트 하여 어떤 데이터가 변경되었는지를 가리킨다.
|
DataObject customer1 = root.getDataObject("customer[1]");
customer1.setString("firstName", "Kevin"); // or
root.setString("customer[1]/firstName", "Kevin");
|
| | 데이터 객체들을 파일에 작성한다.
|
xmlService.save(OutputStream, root);
|
| | XML 문서가 업데이트 되었다.
|
<customers xmlns="http://customers.com">
<customer SN="1" firstName="Kevin" />
<customer SN="2" firstName="Baker" />
</customers>
|
|
예제 8. 관계형 데이터베이스에 액세스하기
비록 복잡한 관계형에서 SDO로 매핑이 가능하지만 이 예제는 간단한 것을 사용한다.
각 데이터베이스 테이블은 SDO 유형이고 테이블의 각 열은 SDO 데이터 객체이고 각 칼럼은 SDO 속성이다.
애플리케이션 로직은 같다. 사전 정의된 쿼리를 실행하여 데이터베이스에서 읽어 들여
데이터를 프린트 및 업데이트하고("Adam"을 "Kevin") 변경 사항을 데이터베이스에 저장한다.
이 데이터베이스 쿼리는 CUSTOMER 테이블에서 다음을 리턴한다.
| CUSTOMER ID (int, primary key) | CUSTOMER FIRSTNAME (String) | CUSTOMER LASTNAME (String) | | 1 |
Adam
| Smith | | 2 | Baker | Street |
이 SDO 구현은 다음과 같다.
rdbService를 쿼리하여 데이터베이스에서 데이터를 얻는다. |
DataObject root = rdbService.get();
|
| |
같은 데이터가 XML에서도 똑같이 나타날 수 있다. |
<customers>
<CUSTOMER ID="1" FIRSTNAME="Adam" LASTNAME="Smith"/>
<CUSTOMER ID="2" FIRSTNAME="Baker" LASTNAME="Street"/>
</customers>
|
| |
각 커스터머의 이름을 프린트한다. |
Iterator i = root.getList("CUSTOMER").iterator();
while (i.hasNext()) {
DataObject cust = (DataObject) i.next();
String name = cust.getString("FIRSTNAME");
System.out.println(name);
}
|
| 첫 번째 데이터 객체의 FIRSTNAME을 Kevin으로 설정한다.
미들웨어는 변경 요약을 업데이트 하여 변경 사항을 나타낸다.
|
DataObject customer1 = root.getDataObject("CUSTOMER[1]");
customer1.setString("FIRSTNAME", "Kevin"); // or
root.setString("CUSTOMER[1]/FIRSTNAME", "Kevin");
|
| | 업데이트된 데이터를 데이터베이스에 작성한다.
|
|
이제 데이터베이스에는 다음 내용이 담긴다.
| CUSTOMER ID (int, primary key) | CUSTOMER FIRSTNAME (String) | CUSTOMER LASTNAME (String) | | 1 |
Kevin
| Smith | | 2 | Baker | Street |
첫 번째 줄이 업데이트 되었다.
이 예제 애플리케이션이 데이터 그래프를 얻은 후에 또 다른 애플리케이션이 데이터베이스에 액세스 하여 값을 변경한다면?
데이터 액세스 서비스는 변경 요약을 검토하여 그 업데이트 내용을 데이터 소스에 적용할 방법을 결정한다.
이 데이터베이스는 병행성 제어를 사용하여 데이터베이스가 이렇게 변경이 되기 전에 "Adam" 값을
마지막으로 갖고 있었는지를 확인한다.(다른 경우, 또 다른 애플리케이션이 데이터를 먼저 변경하고
애플리케이션에서 에러 복구를 요구할 수도 있다.) 몇몇 서비스들은 보다 진보된 형태의 낙관적인 병행성을 구현한다.
변경 히스토리가 그러한 알고리즘에 필요한 원래 값을 제공한다.
EJB를 사용할 때, SDO는 DTO(Value Object)
J2EE 디자인 패턴의 역할을 한다. 일반적으로 Entity EJB의 각 속성에 액세스 하는 것은 매우 힘든 일이기 때문에
데이터 그래프에 있는 여러 SDO 객체들을 전달하는 것이 보다 효율적이다. Session EJB는 Entity EJB에
직접 액세스 할 수 있는 SDO의 그래프를 생성 및 소비할 수 있다.
Customer Entity EJB는 Customer 기록에 대한
데이터베이스 액세스를 캡슐화한다. Session EJB는 액세스 메소드를 제공하여 Customer Entity EJB에서
Customer SDO 그래프를 생성 및 리턴할 수 있도록 한다.
예제 9. SDO를 리턴하고 SDO에서 엔터티 EJB를 업데이트 하는 세션 빈 인터페이스
public interface CustomerSession {
Customer getCustomerByID(String customerID);
Customers getCustomersByLastName(String lastName);
void updateCustomers(Customers customers);
}
|
Customers는 SDO의 루트 데이터 객체로서 여러 커스터머들을 포함하고 있다.
Customers의 List에는
Customers 데이터 객체들이 포함되어 있다.
ChangeSummary는 Customers 객체의
모든 변경 내용들을 기록한다. 추가, 삭제, 업데이트가 모두 포함된다.
updateCustomers() 메소드는 변경내용과 함께
Customer Entity EJB를 업데이트하고 데이터 소스에 대한 변경 내용을 일괄로 처리할 수 있다.
예제 10. Customers의 SDO 유형 정의(자바)
public interface Customers {
List<Customer> getCustomers();
ChangeSummary getChanges();
}
|
요약
SDO는 애플리케이션 데이터에 대한 일관된 액세스를 가능케 하고 모든 데이터 소스에 대한 일반적인
프로그래밍 모델을 가능케 한다. 데이터가 언제 어떻게 저장되었는지는 상관이 없다.
SDO는 XML Schema나 직렬화의 퍼포먼스 문제를 개입시키지 않고도 XML의 단순함을 활용한다.
SDO와 SOA를 함께 사용하면 시스템 프로그래밍 태스크는 비즈니스 로직에서 분리되고 재사용 가능한 서비스로 캡슐화 된다.
놀라운 기술력을 갖출 필요도 없다. SDO는 기술과 구현 상세까지 파고들지 않아도 비즈니스 애플리케이션 프로그래밍을
간소화 하면서도 기술 혼합을 방지한다. SDO를 사용하여 비즈니스 애플리케이션은 그들이 진정으로 원했던
비즈니스 애플리케이션이 될 수 있다.
참고자료
필자소개  | 
| Stephen Brodsky: Senior Technical Staff Member, IBM
|
 | 
| Marcia Stockton: Senior Technical Staff Member, IBM |
기사에 대한 평가
|  |