| Enterprise Java Technologies Tech Tips에 오신 여러분을
환영합니다. Java 2 Platform, Enterprise Edition (J2EE)에 기반한
enterprise Java technologies 와 APIs의 사용에 관한 최신 정보를 얻어
가시기 바랍니다. 이 글에서는 Java 2 Java 2, Enterprise Edition,
v 1.4 를 사용합니다. 다운로드
이번 호에서는,
 EJB 2.1로 메시지 구동 빈 이용하기
JAXR (JAVA API FOR XML REGISTRIES)
을 다루게 됩니다.
저자 Robert Eckstein
EJB 2.1로 메시지 구동 빈 이용하기
EJB(Enterprise Java Beans) 기술의 구성요소에는 세션 빈(session bean), 엔티티 빈(entity bean), 메시지 구동 빈(message-driven bean, MDB) 등의 세 종류가 있다. 상태유지(stateful)와 비상태유지(stateless)가 모두 가능한 세션 빈은 흔히 비즈니스 프로세스를 나타내는데, 상태유지 세션 빈은 일반적으로 한번에 한 클라이언트에 의해 액세스되지만, 상태 유지와 비상태 유지 세션 빈은 모두 동기 방식으로 액세스되며 비영속적이다. 이와 대조적으로 엔티티 빈은 영속적 스토리지에 저장되는 비즈니스 데이터를 나타낸다. MDB는 J2EE 애플리케이션이 JMS(Java Message Service) API를 사용하여 빈과 클라이언트간의 메시지를 비동기적으로 처리할 수 있게 해준다. MDB는 최신 형태의 EJB로, EJB2.0과 함께 도입되었는데, MDB이 도입되면서 J2EE 애플리케이션은 JMS(Java Message Service) API를 사용하여 빈과 클라이언트간의 메시지를 비동기적으로 처리할 수 있게 되었다.
MDB는 여러 면에서 상태유지 세션 빈과 비슷하다. EJB 스펙은 상태유지 세션 빈과 유사한 MDB의 일부 특성을 강조하는 몇 가지 예를 보여주고 있다.
-
메시지 구동 빈의 인스턴스는 특정 클라이언트에 대한 데이터 또는 대화 상태를 유지하지 않는다.
-
EJB 컨테이너는 어떤 메시지 구동 빈 인스턴스에도 메시지를 할당할 수 있어 메시지 구동 빈의 인스턴스는 모두 동등하다.
-
컨테이너는 이들 인스턴스를 풀링하여 메시지 스트림이 병렬 처리되도록 할 수 있다.
-
하나의 메시지 구동 빈이 복수 클라이언트의 메시지를 처리할 수 있다.
두 가지 빈 사이의 가장 뚜렷한 차이는 MDB는 동기 메소드 호출(가령 이벤트) 대신 비동기 JMS 메시지를 수신한다는 점이다. 세션 빈과 엔티티 빈은 JMS 메시지를 전송하고 이를 동기적으로 수신할 수 있지만 비동기적으로 수신할 수는 없다. 이들 비동기 메시지는 애플리케이션 클라이언트, 또 다른 엔터프라이즈 빈, 웹 구성요소 등 어떤 J2EE로든 전송이 가능하다. EJB 2.0이 도입되면서 MDB를 구현하기가 간단해졌다. MDB는 JMS 메시지에만 반응하기 때문에 다른 종류의 엔터프라이즈 빈에서 기대되는 것과 같은 클라이언트 인터페이스(client interface)나 홈 인터페이스(home interface)가 필요치 않다. MDB는 JMS 인터페이스 javax.jms.MessageListener와 javax.ejb.MessageDrivenBean 인터페이스를 구현하는 하나의 클래스만을 요구한다. 다음은 MDB의 간단한 예제이다.
import javax.ejb.*;
import javax.jms.*;
public class MyMessageBean implements MessageDrivenBean,
MessageListener
{
public void ejbCreate() throws CreateException {...}
public void ejbRemove() { ... }
public void setMessageDrivenContext(
MessageDrivenContext ctx) { ... }
public void onMessage(Message msg) { ... }
}
클라이언트 구성요소는 MDB를 찾아서 그곳에서 직접 메소드를 호출하지 않는다. 대신 클라이언트는 MDB 클래스가 MessageListener인 메시지 수신지에 메시지를 전송함으로써 JMS를 통해 MDB에 액세스합니다. 다음은 J2EE 1.4 Tutorial의 MDB 예제를 기초로 한 예제이다. MDB에 메시지를 전송하기 위해 클라이언트는 먼저 커넥션 팩토리 (connection factory)와 큐(queue)를 만든다.
connectionFactory =
(ConnectionFactory) jndiContext.lookup(
"java:comp/env/jms/MyConnectionFactory");
destination =
(Queue) jndiContext.lookup("java:comp/env/jms/QueueName");
다음으로, 클라이언트는 큐 커넥션, 세션, 송신자를 생성한다.
connection = connectionFactory.createConnection();
session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
messageProducer = session.createProducer(destination);
message = session.createTextMessage();
마지막으로, 클라이언트가 큐에 메시지를 보낸다.
for (int i = 0; i < NUM_MSGS; i++) {
message.setText("This is message " + (i + 1));
System.out.println("Sending message: " +
message.gettext());
messageProducer.send(message);
}
큐가 메시지를 수신할 경우 EJB 컨테이너는 MDB의 onMessage() 메소드를 호출하는데, 이 메소드는 메시지의 프로세싱을 처리하는 비즈니스 로직을 포함하고 있다. 메시지를 파싱하고 필요한 비즈니스 로직을 수행하는 것은 MDB의 책임이다. MyMessageBean의 경우, onMessage() 메소드는 들어오는 메시지를 TextMessage로 캐스트하고 텍스트를 로그 파일에 보낼 수 있었다.
public void onMessage(Message inMessage) {
TextMessage msg = null;
try {
if (inMessage instanceof TextMessage) {
msg = (TextMessage) inMessage;
logger.info("MESSAGE BEAN: Message received: " +
msg.getText());
} else {
logger.warning("Message of wrong type: " +
inMessage.getClass().getName());
}
} catch (JMSException e) {
e.printStackTrace();
} catch (Throwable te) {
te.printStackTrace();
}
}
EJB 2.1에서 새로워진 내용
EJB 2.1을 도입하면 더 이상 JMS 사용에 구애를 받지 않아도 되는데, MDB를 웹 서비스에
연결하고자 하는 프로그래머에게는 이런 변화가 매우 중요하다. 이제는 적절한 인터페이스를 구현함으로써
MDB가 다른 종류의 메시지를 청취하도록 할 수 있다. 이 인터페이스는 통상적으로 J2EE 커넥터
아키텍처를 따르는 ‘커넥터(connector)’를 사용하여 추가된다. J2EE 커넥터 아키텍처 1.5는
특별히 MDB에 맞추어진 메시징 계약을 정의한다. (2004년 12월 15일자 테크팁 J2EE
커넥터 아키텍처 1.5 참조).
비동기 커넥터를 기반으로 한 MDB는 표준 javax.ejb.MessageDrivenBean 인터페이스를 구현하며, 아울러 Enterprise Information System 특유의 커넥터 자체에 의해 정의되는 특정한 메시징 인터페이스를 구현한다.
웹 서비스 커넥터와 관계된 간단한 예를 살펴보자. 커넥터 소프트웨어는 RAR(Resource Archive) 파일에 상주하고, 이 RAR는 또한 개발자가 웹 서비스 MDB를 생성하기 위해 사용하는 메시징 인터페이스와 메시징 API를 정의한다. 다음은 EJB 2.1 MDB가 반드시 구현해야 하는 가정적인 인터페이스이다.
package com.someone.web;
public interface WebServiceListener {
public void receiveWebServiceMessage(
XMLDocument message);
}
이 경우 MDB는 javax.ejb.MessageDrivenBean 인터페이스와 WebServiceListener 인터페이스를 모두 구현하게 된다. 다음 코드는 WebServiceListener 인터페이스를 구현하여 XML 메시지를 처리하는 MDB를 보여준다.
package com.someone.web;
public class WebServiceBean implements
javax.ejb.MessageDrivenBean,
com.someone.web.WebServiceListener
{
MessageDrivenContext ejbContext;
public void setMessageDrivenContext(
MessgeDrivenContext context){
ejbContext = context;
}
public void ejbCreate()
{
// Code omitted
}
public void receiveWebServiceMessage(
XMLDocument message)
{
// Do something with message
}
public void ejbRemove(){
// code omitted
}
}
사용되는 메시징 인터페이스가 리턴 타입을 정의하는 메소드를 선언할 수 있다는 데 유의하길 바란다. 이번에도 커넥터가 반드시 개입하여 회신 메시지를 다시 송신자에게 중계해야 한다.
배치 서술자 변경
EJB 2.1에서는 MDB를 위한 배치 서술자(deployment descriptor)가 상당수 변경되었다. 이들은 더 이상 JMS에만 전적으로 의존하지 않기 때문에 EJB 2.1에서는 <message-selector>와 <acknowledge-mode>엘리먼트가 교체되었습니다. 이와 더불어, MDB의 다양한 속성을 열거하기 위해 message-agnostic 엘리먼트인 <activation-config>가 도입되었다. <activation-config>의 속성들은 메시지 구동 빈이 배치될 때 커넥터에 전달된다.
다음은 몇 가지 <activation-config> 속성 설정의
예이다.
<activation-config>
<activation-property>
<activation-config-property-name>messageSelector
</activation-config-property-name>
<activation-config-property-value>Priority = 'Urgent'
</activation-config-property-value>
<activation-property>
</activation-config>
EJB 2.1은 JMS 기반 MDB에 대해 다음 4개의 고정 속성을 정의하며, 이들은 이전의 EJB 2.1 속성을 대체한다.
acknowledgeMode
messageSelector
destinationType
subscriptionDurablity
EJB 2.1은 또한 다음과 같이 두 개의 새로운 엘리먼트, <messaging-type>과 <message-destination-type>을
추가한다.
<messaging-type>javax.jms.MessageListener
</messaging-type>
<message-destination-type>
javax.jms.Queue
</message-destination-type>
<messaging-type> 엘리먼트는 fully-qualified 인터페이스명을 지정함으로써 어떤
메시지 타입을 사용하게 될지를 나타낸다. 인터페이스명이 주어지지 않을 경우 컨테이너는 기본값으로
javax.jms.MessageListener로 정해진다. <message-destination-type>
엘리먼트는 빈이 메시지를 받게 될 수신지의 타입을 나타내는 fully-qualified 클래스를
지정한다. JMS의 경우, 허용된 값은 javax.jms.Queue 와 javax.jms.Topic이다.
메시지 링크
어떤 타입의 EJB도 메시지를 전송할 수 있는 MDB 수신지를 명시하기 위해 배치 서술자에 메시지
링크 기능이 추가되었다. ejb-refs를 사용하고 있다면 전송하는 빈에
대한 배치 서술자의 변경에 익숙할 것이다.
<session>
<ejb-name>SendingEJB</ejb-name>
<resource-ref>
<res-ref-name>jms/MyFactory</res-ref-name>
<res-type>javax.jms.MyConnectionFactory</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<message-destination-ref>
<message-destination-ref-name>
jms/MyDestination
</message-destination-ref-name>
<message-destination-type>
javax.jms.Topic
</message-destination-type>
<message-destination-usage>
Produces
</message-destination-usage>
<message-destination-link>
MyDestinationLink
</message-destination-link>
</message-destination-ref>
</session>
수신하는 MDB의 경우, 배치 서술자 정보에 다음이 포함되어야 한다.
<message-driven>
<ejb-name>ReceivingEJB</ejb-name>
<messaging-type>
javax.jms.MessageListener
</messaging-type>
<transaction-type>Bean</transaction-type>
<message-destination-type>
javax.jms.Topic
</message-destination-type>
<message-destination-link>
MyDestinationLink
</message-destination-link>
</message-driven>
송수신 빈을 링크하기 위해, 어셈블리 서술자에 다음이 표시되어야 한다.
<assembly-descriptor>
<message-destination>
<message-destination-name>
MyDestinationLink
</message-destination-name>
</message-destination>
</assembly-descriptor>
메시지 구동 빈에 관한 자세한 내용을 보려면 J2EE
1.4 Tutorial을 참조하기 바란다.
JAXR (JAVA API FOR XML REGISTRIES)
JAXR(Java API for XML Registries)은 인터넷을 통해 표준 비즈니스 레지스트리에
액세스할 수 있는 편리한 방법을 제공한다. 비즈니스 레지스트리에는 기업이 잠재 기업 파트너가 제공하는
서비스를 검색하고 사용할 수 있게 해주는 정보가 담겨 있다. 일반적으로, 기업은 레지스트리로 등록을
하거나 상호작용할 만한 다른 기업을 검색하기 위해 레지스트리를 이용한다. Java
Web Services Developer Pack 1.5에서 제공하고 J2EE 1.4 튜토리얼에도
기술되어 있는 간단한 JAXR 예제에 기초한 이 테크팁은 자바 클라이언트 애플리케이션이 어떻게 JAXR
API를 이용하여 인터넷 상의 비즈니스 레지스트리에 액세스할 수 있는지를 보여준다.
비즈니스 레지스트리는 완벽한 전용 XML 레지스트리로, 동적 및 소결합 B2B 상호작용을 가능케
하는 중립적인 제3자 인프라이다. 이 상호작용들은 일반적으로 다음 두 가지 표준 중 하나를 따른다.
-
OASIS(Organization for the Advancement of Structured Information Standards)와 U.N./CEFACT(United Nations Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport)가 후원하는 ebXML 레지스트리 및 리포지토리 표준
-
벤더 컨소시엄에서 개발중인 UDDI(Universal Description, Discovery, and Integration) 프로젝트
레지스트리 제공자는 이들 표준 중 한 가지를 준수하는 비즈니스 레지스트리의 구현을 제공하는 엔티티이다.
JAXR 아키텍처
JAXR은 B2B 상호작용의 어느 쪽에서도 사용할 수 있으며, JAXR API는 다음 두 개의
엔티티로 이루어진다.
- JAXR 클라이언트. 이는 JAXR 제공자를 통해 비즈니스 레지스트리에 액세스하기 위해 JAXR API를 사용하는 클라이언트 애플리케이션이다.
- JAXR 제공자. 이는 공통의 스펙을 기반으로 하는 하나 이상의 레지스트리 제공자에 대한 액세스를 제공하는 JAXR API의 서버
측 구현이다.
JAXR 클라이언트는 JAXR API 내의 특수 인터페이스를 사용하여 JAXR 제공자에 액세스하고, JAXR 제공자는 레지스트리와 통신하게
된다.
Java Web Services Developer Pack 1.5에서 제공하는 최신의 JAXR
레퍼런스 구현(JAXR 1.0.7)에는 ebXML가 아닌 UDDI 레지스트리만을 위한 JAXR 제공자가
포함되어 있다는 점에 유의하기 바란다. UDDI에 관한 자세한 내용은 OASIS
UDDI를 참조하기 바란다.
JAXR 사양에 따르면 제공자는 반드시 두 개의 패키지로 키 인터페이스를 구현하도록 되어 있다.
-
javax.xml.registry: 이는 API 인터페이스와 레지스트리
액세스 인터페이스를 정의하는 클래스로 이루어진다.
-
javax.xml.registry.infomodel: 이는 JAXR를
위한 정보 모델을 정의하는 인터페이스로 이루지며, 이 인터페이스는 레지스트리 내에 상주하는 오브젝트의
타입과 그것들이 서로간에 관계하는 방식을 정의한다. 이 패키지의 기본 인터페이스는 RegistryObject
인터페이스이다. 서브인터페이스에는 Organization, Service,
ServiceBinding 등이 있다.
javax.xml.registry 패키지가 특히 중요한 이유는 다음과 같은 여러 가지 유용한 클라이언트 인터페이스를
포함하고 있기 때문이다.
-
Connection: 이 인터페이스는 레지스트리 제공자와 연결된
클라이언트 세션을 나타낸다. 클라이언트가 레지스트리를 사용하려면 반드시 JAXR 제공자와 커넥션을
생성해야 한다.
-
RegistryService: 클라이언트는 연결로부터 RegistryService
오브젝트를 획득한다. RegistryService 오브젝트는 클라이언트가
레지스트리에 액세스하기 위해 사용하는 인터페이스 BusinessQueryManager,
BusinessLifeCycleManager 등을 획득할 수 있게 해준다.
-
BusinessQueryManager: 이 인터페이스를 구현하는
오브젝트는 클라이언트가 javax.xml.registry.infomodel
인터페이스와 일치하는 정보를 레지스트리에서 검색할 수 있게 해준다.
-
BusinessLifeCycleManager: 이 인터페이스를 구현하는
오브젝트는 클라이언트가 레지스트리 내의 정보를 수정하거나 삭제할 수 있게 해준다.
JAXR 커넥션 만들기
JAXR 클라이언트는 처음에 추상 클래스 ConnectionFactory의 인스턴스를 생성한다.
import javax.xml.registry.*;
...
ConnectionFactory connFactory =
ConnectionFactory.newInstance();
다음으로, 클라이언트는 레지스트리의 URL을 지정하는 일련의 속성을 생성한다. 예를 들어, 다음 코드는 IBM 테스트 레지스트리에 대한
질의 서비스와 출판 서비스의 URL을 제공한다.
Properties props = new Properties();
props.setProperty("javax.xml.registry.queryManagerURL",
"http://uddi.ibm.com/testregistry/inquiryapi");
props.setProperty("javax.xml.registry.lifeCycleManagerURL",
"https://uddi.ibm.com/testregistry/publishapi");
필요에 따라(가령 방화벽 뒤에 있는 경우) 클라이언트가 실행되는 네트워크에 대한 프록시 호스트 및 포트 정보를 지정할 수 있다. 질의의
경우, 클라이언트는 HTTP 프록시 호스트 및 포트만을 지정해야 할 수도 있으며, 업데이트의 경우에는
일반적으로 HTTPS 프록시 호스트 및 포트 또한 지정해야 한다.
props.setProperty("com.sun.xml.registry.http.proxyHost",
"myhost.mydomain");
props.setProperty("com.sun.xml.registry.http.proxyPort",
"8080");
props.setProperty("com.sun.xml.registry.https.proxyHost",
"myhost.mydomain");
props.setProperty("com.sun.xml.registry.https.proxyPort",
"8080");
그런 다음 클라이언트는 커넥션 팩토리(connection factory)에 대한 속성을 설정하고 커넥션을 생성한다.
connFactory.setProperties(props);
Connection connection = connFactory.createConnection();
커넥션을 생성한 후 클라이언트는 커넥션을 이용하여 RegistryService 오브젝트를 획득한다. 그런 다음
RegistryService를 이용하여 적절한 질의 인터페이스를 구현하는
오브젝트를 획득한다.
RegistryService rs = connection.getRegistryService();
BusinessQueryManager bqm = rs.getBusinessQueryManager();
BusinessLifeCycleManager blcm =
rs.getBusinessLifeCycleManager();
클라이언트가 레지스트리에 데이터를 읽고 쓸 필요가 있는 경우에는 RegistryService 오브젝트로부터 BusinessQueryManager
오브젝트와 BusinessLifeCycleManager 오브젝트를 모두 획득해야한다.
클라이언트가 간단한 질의만을 수행하는 경우에는 일반적으로 BusinessQueryManager
오브젝트만 필요하다.
레지스트리 쿼리
BusinessQueryManager 인터페이스는 클라이언트가 데이터를
검색할 수 있게 해주는 여러 가지 메소드를 지원하는데, 이 메소드들은 대부분 메소드 인자에 지정된
일련의 기준을 충족하는 BulkResponse(오브젝트의 집합)를 리턴한다.
다음은 메소드들 중에서 가장 유용한 것들이다.
-
findOrganizations: 이 메소드는 지정된 기준(흔히
분류 스키마(classification scheme) 내의 이름 패턴 또는 분류)을 충족하는
조직체(organization)의 목록을 리턴한다.
public BulkResponse findOrganizations(
Collection findQualifiers,
Collection namePatterns,
Collection classifications,
Collection specifications,
Collection externalIdentifiers,
Collection externalLinks)
throws JAXRException
-
findServices: 이 메소드는 지정된 조직체가 제공하는 일련의
서비스를 리턴한다.
public BulkResponse findServices(Key orgKey,
Collection findQualifiers,
Collection namePatterns,
Collection classifications,
Collection specifications)
throws JAXRException
-
findServiceBindings: 이 메소드는 지정된 서비스에
의해 지원되는 서비스 바인딩(서비스에 액세스하는 방법에 관한 정보)을 리턴한다.
public BulkResponse findServiceBindings(Key serviceKey,
Collection findQualifiers,
Collection classifications,
Collection specifications)
throws JAXRException
이름으로 조직체를 검색하기 위해서는 찾기 수식어와 이름 패턴의 조합을 이용한다. findOrganizations()
메소드는 findQualifier 오브젝트 집합을 1차 인자로, namePattern
오브젝트의 집합을 2차 인자로 선택한다. 클라이언트는 퍼센트 부호(%)를
이용하여 조직체 이름 내의 어느 곳에서나 질의 문자열이 발견될 수 있음을 명시한다. 예를 들어,
다음의 코드 단편은 이름에 qString에 포함된 문자가 들어 있는 조직체에
대하여 대소문자를 구분하는 검색을 수행한다.
ArrayList qualifiers = new ArrayList();
qualifiers.add(FindQualifier.CASE_SENSITIVE_MATCH);
qualifiers.add(FindQualifier.SORT_BY_NAME_DESC);
ArrayList names = new ArrayList();
names.add("%" + qString + "%");
BulkResponse response =
bqm.findOrganizations(
qualifiers, names, null, null, null, null);
Collection orgs = response.getCollection();
분류를 이용해 조직체를 찾을 수도 있다. 이를 위해서는 특정한 분류 스키마 내에서 분류를 설정한 다음 이 분류를 findOrganizations()
메소드에 대한 인자로 지정해야 한다. 다음의 코드 단편은 North
American Industry Classification System (NAICS) 분류법
내의 특정 분류에 일치하는 모든 조직체를 찾는다.
ClassificationScheme cScheme =
bqm.findClassificationSchemeByName(null,
"ntis-gov:naics");
Classification classification =
blcm.createClassification(cScheme,
"Snack and Nonalcoholic Beverage Bars", "722213");
Collection classifications = new ArrayList();
classifications.add(classification);
BulkResponse response = bqm.findOrganizations(null,
null, classifications, null, null, null);
Collection orgs = response.getCollection();
클라이언트가 조직체를 찾아낸 후에는 해당 조직체의 서비스를 찾을 수 있다. 비즈니스 서비스를 호출하는 방법은 몇 가지가 있을 수 있는데,
각 호출은 UDDI에서 바인딩 템플릿에 의해 기술된다. ServiceBinding
인스턴스는 UDDI 바인딩 템플릿에 매핑하는 RegistryObjects로,
서비스 호출 방법에 관한 기술 정보를 나타낸다.
Iterator orgIter = orgs.iterator();
while (orgIter.hasNext()) {
Organization org = (Organization) orgIter.next();
Collection services = org.getServices();
Iterator svcIter = services.iterator();
while (svcIter.hasNext()) {
Service svc = (Service) svcIter.next();
Collection serviceBindings =
svc.getServiceBindings();
Iterator sbIter = serviceBindings.iterator();
while (sbIter.hasNext()) {
ServiceBinding sb =
(ServiceBinding) sbIter.next();
}
}
}
이 시점에서 원시 코드는 반드시 문제의 레지스트리 타입에 대한 표준을 따라야 한다. 따라서 UDDI 예제를 계속하려면 개발자가 ServiceBinding에
대한 tModel 정보에 액세스하고 이를 이용하여 서비스 호출 방법에 관한
정확한 정보를 획득할 수 있어야 한다.
좀 자세한 내용은 다음을 참조하기 바란다.
- JAXR: JAXR
page
- UDDI: UDDI.org
및 registry finder
page 참조. 레지스트리 파인더 페이지에 "Inquiry API"와
‘"Publish API" 로 기재된 서버들은 성공적인 JAXR 커넥션을 수행하기
위해 원시 코드 내의 속성 파일에 입력할 URL들이다. UDDI 서버를 호스팅하는 회사에 등록하여
사용자 이름과 비밀번호를 받아야 할 수도 있다. 이 사이트는
tModel과
같은 로-레벨 UDDI 웹 서비스 구성소에 관한 정보를 얻는 데도 유용하다.
- EbXML: the EbXML Page.
Sample Code
이 테크 팁을 위한 예제 코드는 JAXR를 이용하여 이름이 "%USA%"의 패턴과 일치하는 조직체에 대한 레지스트리를 조회합니다.
예제 코드를 구동하려면,
-
이 테크 팁을 위한 샘플 아카이브를 다운로드합니다.
- JWSDP
1.5를 다운로드하여 설치합니다.
-
예제 아카이브를 다운로드한 디렉토리로 이동합니다. 다음과 같이 예제 아카이브가 담긴 JAR 파일의 압축을 풉니다.
jar xvf ttmar2005jaxr.jar
-
각자의
CLASSPATH 환경 변수에 다음 JWSDP 1.5 라이브러리를 추가합니다. 위치는 기본 디렉터리를 기준으로 부여됩니다(jwsdp-1.5)
jaxr/lib/jaxr-api.jar
jaxr/lib/jaxr-impl.jar
jaxp/lib/jaxp-api.jar
jaxp/lib/endorsed/xercesImpl.jar
jaxp/lib/endorsed/xalan.jar
jaxp/lib/endorsed/dom.jar
jaxp/lib/endorsed/sax.jar
jwsdp-shared/lib/mail.jar
jwsdp-shared/lib/activation.jar
jwsdp-shared/lib/jaas.jar
jwsdp-shared/lib/commons-logging.jar
saaj/lib/saaj-api.jar
saaj/lib/saaj-impl.jar
jaxb/lib/jaxb-api.jar
jaxb/lib/jaxb-impl.jar
jaxb/lib/jaxb-libs.jar
jaxb/lib/jaxb-xjc.jar
BusinessQueryTest.java 파일을 컴파일합니다.
-
방화벽이 작동중인 경우에는 반드시 원시 코드 내에 해당 프록시 정보를 입력해야 합니다. 그렇지 않으면
JAXR API가 외부 서버에 연결할 수 없게 됩니다.
BusinessQueryTest를 구동합니다.
java BusinessQueryTest
다음과 같이 시작되는 결과가 표시되어야 합니다.
Successfully queried the registry for organization matching
the name pattern: "%USA%"
Results found: 3
Organization Name: USA-Works
Organization Key: 8cd1668c-64fa-4aa5-a053-bd0be4bd53f5
Organization Description: Liberty and Freedom
Service Name: Federal Government Service
Service Key: 056b2905-3999-4912-89de-fe79cbfedea0
Service Description: Services of the Federal Government
|
|
 |
|
|
