UDDI는 웹에서 비즈니스 레지스트리의 공유 오퍼레이션을 포함하고 있다. 대부분의 경우 프로그램과 프로그래머는 서비스의 정보를 위치시킬 때 특히 프로그래머의 경우에는 알려진 웹 서비스와의 호환성있는 시스템을 준비하거나, 자신의 웹 서비스를 다른 사람이 호출할 수 있게 기술하는데 UDDI 비즈니스 레지스트리를 사용한다. 이것은 UDDI 비즈니스 레지스트리에 지정된 정보를 사용한다.

UDDI 비즈니스 레지스트리는 비즈니스 레벨에서 사용되며 주어진 파트너가 특정 웹 서비스 인터페이스를 가지고 있는지 확인하거나, 해당 서비스를 가지고 해당 산업에 있는 회사를 찾거나 서비스에 대한 기술 정보를 얻기 위해 어떻게 파트너가 웹 서비스를 export시켰는지에 대한 정보를 위치시킨다.

UDDI Data 구조

UDDI 레지스트리에서 사용하는 핵심 정보 모델은 XML 스키마로 정의된다.

UDDI XML 스키마는 4개의 핵심 타입의 정보로 구성되어 있으며 기술자들이 파트너의 웹 서비스들을 사용하기 위해 알아야 하는 정보를 제공한다. 이 4가지는 시비스의 스펙에 대한 비즈니스 정보(<businessEntity>), 서비스 정보(<businessService>), 바인딩 정보(<bindingTemplate>) 그리고 기술 모델 정보(<tModel>)이다.

웹 서비스에 대한 정보를 기술하거나 검색할 때 사용되는 정보 계층 구조와 XML 태그를 아래 그림에서 보여주고 있다.

[그림 19.1] 정보 계층과 주요 XML 태그 이름

JEUS의 UDDI 서버는 데이터 영속성을 위해서 관계형 DB가 필요하다. JEUS UDDI 서버는 ANSI 표준 SQL을 지원하는 어떤 관계형 DB라도 사용할 수 있다.

JEUS UDDI DataStore는 JDBC를 사용하며 설정 과정은 간단하다. 첫 번째로 JEUS UDDI 서버 패키지와 함께 제공되는 DB 스크립트를 사용하여 새로운 UDDI DB를 생성한다(DB 스크립트는 JEUS_HOME/lib/systemapps/uddi/dbscripts 디렉터리에 위치한다). DataStore의 구성 설정을 하기 위해서는 JEUS에서 'uddiDB'라는 데이터소스를 설정해야 한다.

JEUS_HOME/lib/systemapps/uddi/conf 디렉터리의 예제 파일을 참고한다.

UDDI DB 구성 설정이 완료되었다면 JEUS UDDI 서버를 deploy해야 한다.

JEUS UDDI 서버 EAR 패키지는 JEUS가 설치될 때 JEUS_HOME/lib/systemapps/uddi 디렉터리에 생성된다(파일 이름은 jeusuddi_v2c.ear과 jeusuddi_v3c.ear이다).

JEUS UDDI 서버를 deploy하는 것은 다른 EAR 애플리케이션을 deploy하는 과정과 같다. 예제에서는 컨텍스트 이름이 'uddi'로 UDDI가 deploy되는 것을 가정한다.

<jeus-web-dd>
    <res-ref>
        <jndi-info>
            <ref-name>jdbc/uddiDB</ref-name>
            <export-name>UDDIDB</export-name>
        </jndi-info>
    </res-ref>
</jeus-web-dd>

<web-app>
    . . .
    <resource-ref>
        <res-ref-name>jdbc/uddiDB</res-ref-name>
        . . .
    </resource-ref>
</web-app>

JNDI 데이터소스 이름인 'jdbc/uddiDB'는 기본값으로 사용되는 JNDI 데이터소스 이름이다. 서버에 설정된 실제 데이터소스와 연결하는 <export-name>은 'UDDIDB'이다. 다른 JNDI 데이터소스 이름을 사용한다면 이 구성 설정 파일들을 수정한다.

JEUS UDDI 서버를 구성하기 위해서는 있는 설정 파일 uddi.properties를 수정해야 한다. 파일은 JEUS_HOME/lib/application 디렉터리에 위치한다. 만약 이 설정 파일 존재하지 않으면 deploy할 때 기본 설정 파일을 자동으로 생성한다.

다음은 uddi.properties 파일의 기본 설정에 대한 설명이다.

UDDI 레지스트리에 UDDI 데이터를 공개하기 위해서는 UDDI 레지스트리의 인증을 얻어야 한다.

JEUS UDDI 레지스트리의 Publisher의 인증은 2단계 과정을 거친다.

JEUS 서버를 기동시킨다. UDDI 서버의 URL은 다음과 같은 형태이다.

http://hostname:port/context/

기본적으로 JEUS UDDI 서버의 context path는 '/uddi'이다. 여기서 JEUS HTTP Listener의 기본 포트 8088을 사용한다고 가정한다면 URL은 다음과 같다.

http://localhost:8088/uddi/

웹 브라우저에서 이 URL을 호출하였다면 다음과 같은 화면으로 이동한다.

[그림 19.2] JEUS UDDI 레지스트리 초기 화면

JEUS UDDI Explorer의 Search을 이용하면 이름으로 Business, Service, Technical Model을 검색할 수 있다.

'UDDI Registry'를 사용해서 UDDI 레지스트리 오퍼레이터를 선택할 수 있고, 'Search For a'에서 Entity 타입을 선택할 수 있다. UDDI Registry와 Entity 타입(Business, Service, Technical Model)을 선택한 후 아래의 텍스트 필드에 찾을 이름의 일부 또는 이름 전체를 입력한다. 와일드 카드로 '%' 심볼을 이용할 수 있다. 'exact name' 또는 'case sensitive'를 사용해서 결과를 필터링할 수 있다.

[그림 19.3] UDDI Search 입력 폼 화면

찾을 이름을 입력 후 [submit] 버튼을 클릭하면 검색을 시작한다. 선택된 UDDI 레지스트리는 사용자가 입력한 이름으로 시작하는 Businesses, Services, Technical Model들의 목록을 조회한다.

JEUS UDDI Explorer는 찾은 Entity에 대한 상세 내역을 다음과 같이 출력한다.

[그림 19.4] UDDI 레지스트리에서 찾은 결과 화면

UDDI 레지스트리에 Publish하기 위해서는 사용자 ID와 패스워드를 사용하여 UDDI 레지스트리에 로그인해야 한다. 사용자가 접속한 후 JEUS UDDI Explorer는 사용자가 등록한 비즈니스들의 목록과 Technical Model들을 조회한다. 등록한 비즈니스 또는 Technical Model은 왼쪽 트리의 [+]를 클릭하면 등록된 서비스들 및 기타 정보들을 간략하게 확인할 수 있고, 다시 오른쪽 화면에서는 이에 대한 상세한 정보 열람 및 수정이 가능하다.

[Add Provider], [Add TModel] 버튼을 클릭해서 기본적인 비즈니스나 Technical Model을 추가할 수 있다. 만약 등록된 레지스트리를 삭제하나 수정하는 경우는 [Delete], [Edit] 버튼을 사용한다.

[그림 19.5] 등록한 entry 화면

비즈니스 추가

다음은 비즈니스를 추가하는 과정에 대한 설명이다.

서비스 추가

다음은 서비스를 추가하는 과정에 대한 설명이다.

tModel 추가

다음은 tModel을 추가하는 과정에 대한 설명이다.

서비스 바인딩(bindingTemplate) 추가

다음은 서비스 바인딩(bindingTemplate)을 추가하는 과정에 대한 설명이다.

JEUS UDDI Explorer에서 JEUS UDDI 레지스트리를 사용하기 위한 사용자를 등록할 수 있다. 우선 관리자 권한을 가진 사용자로 로그인을 해야 한다. 로그인한 후에 메뉴에서 User 링크를 선택하면 다음과 같은 화면이 나타난다. 이 화면에서 관리자는 새로운 사용자를 추가, 수정, 삭제를 할 수 있다.

[Add User] 버튼을 클릭하면 다음과 같은 신규 사용자 등록 화면이 나타난다.

[그림 19.11] JEUS UDDI Explorer 사용자 관리 화면

화면에서 'Username'과 'Fullname'은 필수 입력 사항이다. 'Username'은 JEUS UDDI Explorer에 로그인과 UDDI Data를 공개하기 위한 사용자 ID이다. 입력값을 입력한 후에 [Add]를 클릭하면 사용자가 등록된다.

[그림 19.12] JEUS UDDI Explorer 사용자 등록 화면

다음은 UDDI 클라이언트를 작성하는 과정에 대한 설명이다.

UDDI 클라이언트 코드를 컴파일하려면 클라이언트 소스 코드가 위치한 디렉터리로 이동한다. 예제에서는 JEUS_HOME/samples/webservice/uddi/client 디렉터리에서 다음의 명령어를 실행한다.

JEUS_HOME/samples/webservice/uddi/client$ ant build

UDDI 클라이언트 코드를 실행하려면 클라이언트 소스 코드가 위치한 디렉터리로 이동한다. 예제에서는 JEUS_HOME/samples/webservice/uddi/client 디렉터리에서 다음의 명령어를 실행한다.

JEUS_HOME/samples/webservice/uddi/client$ ant

실행 결과는 다음과 유사할 것이다.

##### Running FindBusinessSample #####
Found Business name: test_Biz
##### Done #####

UDDI v3.0 스펙(specification)에서의 중요한 변화 중 하나는 디지털 서명의 지원이다. UDDI Entity가 디지털 서명되면 데이터 무결성(integrity)과 확실성(authenticity)이 UDDI에 의해 전달된다. UDDI 레지스트리에 대한 요청자(inquirer)는 서명된 데이터만을 요청하도록 질의(Query)를 조정할 수 있고, 요청자가 UDDI 레지스트리로부터 가져온 데이터를 검증할 때 데이터가 정확하게 공개자(Publisher)가 의도한 것인지를 확신할 수 있게 된다.

UDDI 레지스트리에 대한 공개자는 UDDI Entity를 소유하였다고 주장하는 누군가에 의해 잘못 전달되지 않을 것을 확신할 수 있게 되고, 공개자가 서명된 데이터를 가지게 되면, 공개자는 그 데이터의 무결성에 대해 확신할 수 있게 된다.

디지털 서명은 UDDI의 데이터 품질을 향상시키고, 높은 신뢰성을 필요로 하는 웹 서비스 환경에서 요구하는 데이터 보호와 부인 방지를 가능하게 한다.

UDDI v3.0 사양에서는 XML 서명 구문과 처리 방법(http://www.w3.org/TR/xmldsig-core/)을 사용하여 다음의 상위 수준 UDDI Entity에 대한 XML 디지털 서명을 지원한다.

UDDI v3.0 스펙은 XML 서명과 검증을 클라이언트의 역할로 정의하고 있다. 그에 따라 JEUS 환경에서도 클라이언트의 XML 서명과 검증을 지원하고 있으며, 본 안내서에서 기술하고 있는 UDDI 클라이언트는 JEUS UDDI 클라이언트를 사용하고 있음을 가정한다.

XML 서명은 공개(publication) API 호출에 대한 결과로써 UDDI 레지스트리에 저장되는 상위 수준 element에 대하여 계산된다.

각 API의 호출별 수행되는 element는 다음과 같다.

JEUS UDDI 클라이언트는 'java.security.*'의 java.security.PrivateKey 객체와 java.security.cert.X509Certificate 객체를 사용하여 상위 수준 UDDI Entity를 서명한다.

다음은 PrivateKey 객체와 X509Certificate 객체를 얻는 간단한 예제이다.

import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.X509Certificate;
...

String keystoreType = "JKS";
String privateKeyAlias = "...";
String privateKeyPasswd = "...";
String certificateAlias = "...";
...
KeyStore keyStore = KeyStore.getInstance(keystoreType);
keyStore.load(...);

PrivateKey privateKey = (PrivateKey)keyStore.getKey(
    privateKeyAlias, privateKeyPasswd.toCharArray());
X509Certificate certificate = 
    (X509Certificate)keyStore.getCertificate(certificateAlias);

얻어진 PrivateKey 객체와 X509Certificate 객체를 사용하여 XML 서명을 지원하는 JEUS UDDI 클라이언트 프로그래밍 방법은 기본적으로 기존의 JEUS UDDI 클라이언트 프로그래밍 방법과 동일하다. 자세한 프로그래밍 방법은 “19.4. UDDI 클라이언트 생성”을 참고한다.

공개되는 UDDI Entity는 jeus.uddi.v3.client.UDDIClient 클래스에서 제공하는 다음의 메소드를 사용하여 서명된다.

public BindingDetail save_binding(
       String authInfo, bindingTemplate bindingTemplate,
       PrivateKey privateKey, X509Certificate certificate)
public BusinessDetail save_business(
       String authInfo, BusinessEntity businessEntity,
       PrivateKey privateKey, X509Certificate certificate)
public ServiceDetail save_service(
       String authInfo, BusinessService businessService,
       PrivateKey privateKey, X509Certificate certificate)
public TModelDetail save_tModel(
       String authInfo, TModel tModel,
       PrivateKey privateKey, X509Certificate certificate)
public PublisherAssertions set_publisherAssertions(
       String authInfo, PublisherAssertion publisherAssertion,
       PrivateKey privateKey, X509Certificate certificate)

서명할 UDDI Entity는 Entity key를 포함해야 한다. Entity key가 없는 UDDI Entity를 공개할 경우 UDDI 레지스트리는 그 UDDI Entity에 대하여 새로운 Entity key를 할당하게 되고, 이것은 그 UDDI Entity에 대한 서명을 유효하지 않게 만든다. 그러므로 공개자는 Entity key가 포함된 UDDI Entity를 공개할 역할이 있다.

예를 들어 businessService는 serviceKey와 businessKey를 포함해야 한다. businessService가 bindingTemplate을 포함하고 있으면, bindingTemplate은 bindingKey와 serviceKey를 포함하고 있어야 한다.

XML 서명 검증은 요청(inquiry) API 호출에 대한 결과로써 응답되는 상위 수준 element에 대해 수행된다.

각 API의 호출별 수행되는 element는 다음과 같다.

전형적으로 UDDI 레지스트리는 클라이언트의 서명 검증을 하지 않는다. JEUS UDDI 클라이언트는 서명 검증을 위한 별도의 방법을 제공하지 않는다. 해당 요청 API 호출에 대한 응답에 서명 element가 포함된 경우 내부적으로 서명 검증을 자동 수행한다. 서명이 유효하지 않을 때 java.sercurity.SignatureException을 던진다.

UDDI v3.0 스펙(specification)의 새로운 subscription API는 동기적(synchronous), 비동기적(asynchronous)인 방법으로 공지(notification) 기능을 지원한다.

subscription API는 UDDI 레지스트리를 추적할 수 있는 방법을 제공한다. 이를 사용하여 가입자(subscriber)는 특별한 질의(Query) 또는 가입자가 관심을 갖는 Entity를 기반으로 subscription을 수립할 수 있다. 이 subscription을 기반으로 하여 UDDI 정보에 대한 동기식 요청 또는 레지스트리에 의해 가입자에게 이루어지는 비동기식 공지를 통해 UDDI 레지스트리의 내용 변경을 추적할 수 있다.

[그림 19.13] UDDI subscription 흐름도

UDDI subscription은 다음의 경우에 유용하다.

subscription의 수립과 그 결과의 감시는 일반적으로 여러 단계가 필요한 과정이다.

본 절에서는 비동기식 공지와 동기식 요청 예제에 대해서 설명한다.

비동기식 공지

다음은 간단한 비동기식 공지 형태의 subscription 작동 예제이다.

다음은 notify_subscriptionListener API를 구현한 클라이언트의 호출로 공지되는 결과이다.

<notify_subscriptionListener>
    <subscriptionResultsList>
        <coveragePeriod>
            <startPoint>20020101T00:00:00</startPoint>
            <endPoint>20020131T00:00:00</endPoint>
        </coveragePeriod> 
        <subscription brief="true">
            <subscriptionFilter>
                <find_service xmlns="urn:uddi-org:api_v3" >
                    <findQualifiers>
                        <findQualifier>
                            uddi:uddi.org:findqualifier:sql99:like
                        </findQualifier>
                    </findQualifiers>
                    <categoryBag>
                        <keyedReference
                            tModeKey="uddi:uddi.org:ubr:taxonomy:naics"
                            keyName="Motor Vehicle Parts"
                            keyValue="42112_"/>
                    </categoryBag>
                </find_service>
                </subscriptionFilter>
                <bindingKey>
                    bindingKeyOfTheClientsNotifySubscriptionListenerService
                </bindingKey>
                <notificationInterval>P5D</notificationInterval>
                <maxEntities>1000</maxEntities>
                <expiresAfter>20030101T00:00:00</expiresAfter>
        </subscription>
        <keyBag>
            <deleted>false</deleted>
            <serviceKey>matchingKey1</serviceKey>
            <serviceKey>matchingKey2</serviceKey>
            <serviceKey>matchingKey3</serviceKey>
            <serviceKey>matchingKey4</serviceKey>
        </keyBag>
        <keyBag>
            <deleted>true</deleted>
            <serviceKey>matchingKey5</serviceKey>
            <serviceKey>matchingKey6</serviceKey>
        </keyBag>
    </subscriptionResultsList>
</notify_subscriptionListener>

(출처: http://uddi.org/pubs/uddi-v3.0.2-20041019.htm)

'brief' 속성을 'true'로 설정한 subscription은 결과를 단지 Entity key만으로 공지한다. Entity key는 <keyBag>에 포함되어 공지되며, 이미 삭제된 Entity의 key들을 포함한 <keyBag>은 <deleted>가 'true'로 설정되어 공지된다.

동기식 요청

API를 사용하여 동기식으로 subscription 결과를 가져올 수 있다. 동기식 요청을 위한 subscription의 저장은 subscription Listener를 위한 <bindingKey>를 필요로 하지 않는다는 것을 제외하면, 비동기식 공지 예제에 살펴본 subscription의 저장 방법과 동일하다.

다음은 전형적인 get_subscriptionResults API를 사용하는 예제이다.

<get_subscriptionResults>
    <authInfo>myAuthCode</authInfo>
    <subscriptionKey>mySubscriptionKey</subscriptionKey>
    <coveragePeriod>
        <startPoint>20020101T00:00:00</startPoint>
    </coveragePeriod>
</get_subscriptionResults>

(출처: http://uddi.org/pubs/uddi-v3.0.2-20041019.htm)

위의 요청은 동기적으로 <subscriptionResultList> 형태로 응답된다.

<subscriptionResultsList>
    <chunkToken>"nodeGeneratedToken"</chunkToken>
    <coveragePeriod>
        <startPoint>20020101T00:00:00</startPoint>
    </coveragePeriod>
    <subscription  brief="true">
        <subscriptionFilter>
            <find_service xmlns="urn:uddi-org:api_v3">
                <findQualifiers>
                    <findQualifier>
                        uddi:uddi.org:findqualifier:sql99:like
                    </findQualifier>
                </findQualifiers>
                <categoryBag>
                    <keyedReference
                        tModeKey="uddi:uddi.org:ubr:taxonomy:naics"
                        keyName="Motor Vehicle Parts"
                        keyValue="42112_"/>
                </categoryBag>
            </find_service>
        </subscriptionFilter>
        <bindingKey>
            bindingKeyOfTheClientsNotifySubscriptionListenerService
        </bindingKey>
        <notificationInterval>P5D</notificationInterval>
        <maxEntities>1000</maxEntities>
        <expiresAfter>20030101T00:00:00</expiresAfter>
    </subscription>
    <keyBag>
        <deleted>false</deleted>
        <serviceKey>matchingKey1</serviceKey>
        <serviceKey>matchingKey2</serviceKey>
        <serviceKey>matchingKey3</serviceKey>
        <serviceKey>matchingKey4</serviceKey>
    </keyBag>
</subscriptionResultsList>

(출처: http://uddi.org/pubs/uddi-v3.0.2-20041019.htm)

JEUS UDDI 클라이언트는 subscription API를 지원하기 위해 jeus.uddi.v3.client.UDDIClient 클래스에 다음과 같은 메소드를 제공한다.

public subscriptions save_subscription(
    String authInfo, Subscription subscription)
public void delete_subscription(
    String authInfo, String subscriptionKey)
public Subscriptions get_subscriptions(String authInfo)
public SubscriptionResultsList get_subscriptionResults(
    String authInfo, String subscriptionKey,
    CoveragePeriod coveragePeriod, String chunkToken)

subscription 클라이언트 프로그래밍은 기본적으로 기존의 JEUS UDDI 클라이언트 프로그래밍 방법과 동일하다. 이때 subscription 필터 조건을 가능한 제한적으로 설정하는 것에 주의해야 한다.

다음은 간단한 JEUS UDDI subscription 클라이언트 프로그래밍의 예이다.

UDDIClient client;
. . .

AuthToken authToken = client.get_authToken(user, password);

// Make a subscription
Subscription subscription = new Subscription();

// Make a subscriptionFilter
FindBusiness findBusiness = new FindBusiness();
findBusiness.addName(new Name("biz"));
subscription.setSubscriptionFilter(
new SubscriptionFilter(findBusiness));

// execute save_subscription request
Subscriptions subscriptions = client.save_subscription(
    authToken.getAuthInfoString(), subscription);

Subscription savedSubscription = subscriptions.getSubscription(0);
String subscriptionKey =
    savedSubscription.getSubscriptionKeyString();
. . .

등록된 subscription으로부터 얻은 subscription 키는 이 subscription을 delete_subscription API를 사용하여 삭제하거나 get_subscriptionResults API를 사용하여 동기식 요청으로 결과를 얻어올 때 사용된다. get_subscriptions API는 가입자가 등록한 모든 subscription을 조회할 때 사용된다.

가입자가 subscription을 등록할 때 등록된 subscription의 결과가 단지 Entity key만을 사용하도록 제한되길 원한다면 다음과 같이 subscription에 'brief' 속성을 'true'로 설정한다.

. . .
// Make a Subscription
Subscription subscription = new Subscription();
Subscription.setBrief(true);
. . .

가입자가 비동기식 공지를 받기를 원하다면, subscription Listener를 위한 <bindingKey>를 subscription에 설정해야 하고 공지 간격을 설정해야 한다. 공지 간격은 XML 스키마에 정의된 xsd:duration 타입이며, 'PnYnMnDTnHnMnS'를 갖는다.

. . .
// Make a Subscription
Subscription subscription = new Subscription();
subscription.setBindingKey(
    bindingKeyOfTheClientsNotifySubscriptionListenerService);
subscription.setNotificationInterval("P5D");
. . .

JEUS UDDI 서버가 가입자에게 이메일를 통해 subscription 결과를 공지하기 위해서는 메일 서버에 대한 설정이 필요하다. 이 설정은 JEUS UDDI 서버의 설정 파일인 'uddi.properties'에 설정된다.

. . .
uddi.subscription.mail.smtp.host=...
uddi.subscription.mail.smtp.port=...
uddi.subscription.mail.smtp.from=...
. . .

e-business 표준을 위한 기구인 OASIS에서는 UDDI v2.0, v3.0 스펙(specification) 외에 몇 가지 이에 관련된 Technical Note들에 대해 작업하고 있는데 그 중 하나가 바로 UDDI WSDL Publishing(Using WSDL in a UDDI Registry, Version 2.0.2)이다.

WSDL은 abstract한 인터페이스와 임의의 네트워크 서비스의 프로토콜 바인딩들을 제공함으로써 UDDI 표준을 보완할 수 있다. OASIS의 "Using WSDL in a UDDI Registry"는 바로 이러한 WSDL의 description들과 UDDI의 Data Structure와의 매핑에 관해 권고하는 접근 방식을 밝히고 있다. 자세한 사항은 OASIS TC Using WSDL in a UDDI Registry, Version 2.0.2를 참고한다.

[그림 19.14] WSDL description과 UDDI Data Structure 매핑

본 절에서는 JEUS에서 제공하는 wsdl2uddi 툴에 대해 설명하고, wsdl2uddi를 사용해서 wsdl을 UDDI에 Publishing하는 방법을 설명한다.

wsdl2uddi

JEUS UDDI WSDL Publishing은 이러한 매핑을 자동화해주는 툴인 wsdl2uddi를 제공한다. 기본적인 동작 방법은 콘솔에서 다음과 같이 입력하여 명령어를 수행한다.

$ wsdl2uddi

사용 방법은 다음과 같다.

Usage: wsdl2uddi UDDIVersion WSDLURI [wsdl-options] -uddiInquiry
UDDIInquiryURI -uddiPublish UDDIPublish -uddiUsername UDDIUsername
-uddiPassword UDDIPassword [options]

* wsdl-options
    -wsdlUsername                username to access the WSDL-URI
    -wsdlPassword                password to access the WSDL-URI

* options
    -level LEVEL                 specify log level.
                                 LEVEL : SEVERE, WARNING, INFO, FINE, FINER, FINEST
    -verbose                     same as -level FINE

각 파라미터의 설명은 다음과 같다.

임의의 WSDL을 UDDI에 Publishing

wsdl2uddi 툴을 이용하여 하나의 WSDL을 UDDI에 Publishing한다.

$ wsdl2uddi v2 BasicAuthServiceTestService.wsdl -uddiInquiry
http://localhost:8088/uddi/inquiry -uddiPublish
http://localhost:8088/uddi/publish -uddiUsername jeus -uddiPassword jeus
[2006.12.12 17:22:47][2][] [client-10] [WSVC-5240] Analyzing WSDL :
BasicAuthServiceTestService.wsdl

위와 같이 입력하면 wsdl2uddi 툴은 자동으로 wsdl을 해석해서 알맞은 바인딩 규칙에 따라 UDDI에 Publishing한다.

Publishing된 wsdl을 UDDI에서 확인하면 다음과 같다.

[그림 19.15] UDDI에 Publishing된 wsdl의 모습