1. Request - Response : 가장 흔히 사용되는 형태의 MEP이다. 메세지가 서비스 요청자로부터 서비스 제공자로 전송되는 단순한 형태의 교환이다. 메세지를 받으면 서비스 제공자는 서비스 요청자에게 메세지로 응답한다. 동기, 비동기 방식 모두 쓰인다,
2. Fire and Forget : 서비스 요청자에서 서비스 제공자로 메세지를 보내고 응답을 기다리지 않는다. 가장 단순한 비동기 방식이다.
3. 기억안남.(기대 - 응답인가?)
4. 기억안남. 책보고 정리하자. (Notification인가?)

위에 적힌 WSDL을 가지고 Tmax JEUS에서 실행시켜보기로 하겠다. 우선 Tmax Technet에 가서 JEUS 5 Fix#18을 받은 후 적절한 디렉토리에 설치한다. 또한 JMaker 최신 Version을 받아서 설치하자. JMaker는 JEUS환경의 Eclipse기반 개발툴이다. 손쉽게 웹서비스를 구축할 수 있기 때문에 WSDL2JAVA, JAVA2WSDL, java mapping 파일 같은 중노동(?)을 하지 않아도 된다......고 Tmax에서는 얘기하겠지만 천만의 말씀, 만만의 콩떡이다.말그대로 JEUS환경에 적절한 WSDL을 갖고는 손쉽게 구축이 가능한데 위와 같이 비 JEUS 친화적인(?) WSDL로는 generate된 java파일과 여러 Descriptor파일들의 설정이 맞지 않는다. 우선 WSDL2JAVA와 같은 command로 웹서비스를 생성시켜 직접 Deploy해보는것도 학습에는 여러 도움이 된다. 그래야 JMaker생성시킨 엉뚱한 결과물에도 대처가 가능하다. 어찌됐든 개발의 편의성이 있는것만은 사실이다. 하기 귀찮은 사람은 다음 파일을 다운받아서 Deplo시키자.wsexer002ear.ear 이 파일은 JMaker에서 생성시킨파일을 토대로 약간의 수정작업을 거친 ear파일이다. 열어보면 알겠지만 위의 WSDL과 차이점이 있는걸 발견할 수 있다. 여하튼 이런 얘기는 여기까지 하기로 하고 직접 작성한 것이든 위의 파일이든 JEUS 웹어드민을 통해 Deploy시키자.
 

- STEP2. 구현된 Class로부터 WSDL생성.

Axis에서는 Axis.jar파일에 Java2Wsdl이라는 Class파일을 제공하고 있다. 해당 파일의 역할은 STEP1에서 구현한 2개의 Java Class로부터 WSDL파일을 생성하는 것인데 SOAP Part2에서 제공한 문서를 보면 사용법에 대한 자세한 사항이 나와있으니 참조하고.......다음과 같이 실행하자.

java org.apache.axis.wsdl.Java2WSDL -o c:\test\webservice\hello\Hello.wsdl
-l http://localhost:8080/axis/services/Hello -n http://hello.webservice -u literal -pwebservice.hello http://hello.webservice webservice.hello.HelloIF

부연해서 설명하자면 -l 옵션은 실제 웹서비스 URL경로를 지정하는데 WSDL문서를 받은 서비스요청자에서 실제 호출경로로 사용하므로 정확히 작성해야 한다. -n 옵션은 WSDL 문서에서 사용할 targetNamespace의 값을 설정한다. targetNamespace는 해당 문서에서 정의된 XML Element들을 식별하기 위한 것이다. 생성이 잘 되었다면 다음과 같을 것이다.

List2. Hello WSDL

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
    targetNamespace="http://hello.webservice"
    xmlns:apachesoap="http://xml.apache.org/xml-soap"
    xmlns:impl="http://hello.webservice"
    xmlns:intf="http://hello.webservice"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <!--WSDL created by Apache Axis version: 1.4 Built on Apr 22, 2006 (06:55:48 PDT)-->
  
   <wsdl:message name="helloResponse">
      <wsdl:part name="helloReturn" type="xsd:string"/>
   </wsdl:message>
   <wsdl:message name="helloRequest">
      <wsdl:part name="in0" type="xsd:string"/>
   </wsdl:message>

   <wsdl:portType name="HelloIF">
      <wsdl:operation name="hello" parameterOrder="in0">
         <wsdl:input message="impl:helloRequest" name="helloRequest"/>
         <wsdl:output message="impl:helloResponse" name="helloResponse"/>
      </wsdl:operation>
   </wsdl:portType>

   <wsdl:binding name="HelloSoapBinding" type="impl:HelloIF">
      <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <wsdl:operation name="hello">
         <wsdlsoap:operation soapAction=""/>
         <wsdl:input name="helloRequest">
            <wsdlsoap:body namespace="http://hello.webservice" use="literal"/>
         </wsdl:input>
         <wsdl:output name="helloResponse">
            <wsdlsoap:body namespace="http://hello.webservice" use="literal"/>
         </wsdl:output>
      </wsdl:operation>
   </wsdl:binding>

   <wsdl:service name="HelloIFService">
      <wsdl:port binding="impl:HelloSoapBinding" name="Hello">
         <wsdlsoap:address location="http://localhost:8080/axis/service/Hello"/>
      </wsdl:port>
   </wsdl:service>
</wsdl:definitions>

 List1의 WSDL파일을 보면 portType의 name이 HelloIF, operation의 name이 hello인데 HelloIF.java의 class명과 method명과 일치함을 알 수 있다. targetNamespace는 -n 옵션에서 정의한 값이 설정되어 있고 location에는 -l 옵션에서 정의한 값이 설정되어 있다. Bold된 단어를 하나씩 비교해가면서 확인해보면 연관성을 알 수 있을 것이다.

- STEP3. WSDD파일 및 Java파일 생성

WSDD(Web Service Deployment Descriptor)파일의 용도는 새로운 Handler, Chain 그리고 서비스를 올리기 위해 AdminClient에서 사용하는 설정파일이다. WSDD에 대한 자세한 사항은 해당 사이트를 참조하도록하자. AdminClient는 관리툴로서, Handler나 Chain같은 Axis리소스를 올리거나 내릴때 사용한다.
http://ws.apache.org/axis/java/reference.html#DeploymentWSDDReference

cmd#> java org.apache.axis.wsdl.WSDL2Java -o d:\ -d Application -s d:\Hello.wsdl

여기서는 d:\ 디렉토리에 wsdd파일 및 Java파일을 생성했다. 생성된 파일목록은 다음과 같다.
deploy.wsdd
undeploy.wsdd
HelloIF.java
HelloIFService.java
HelloIFServiceLocator.java
HelloSoapBindingImpl.java
HelloSoapBindingStub.java

java 파일에 대한 자세한 설명은 J2EE Web Service에서 자세히 다루기로 하고
deploy.wsdd와 undeploy.wsdd파일은 말그대로 deploy, undeploy 설정파일이다. HelloIF를 implement한 것이 HelloSoapBindingImpl이므로 해당 파일의 hello 메소드에 관련 로직을 작성하면 된다.

- STEP4. 서비스 deploy

• Axis Engine : SOAP 처리기
• Handler : Axis내부의 기본적인 구성요소로 기본의 백엔드시스템과 Axis를 연결하는 역할을 한다.
• Chain : 순차적으로 정렬된 Handler들의 모음을 말한다.
• 전송매체 : SOAP message 흐름이 Axis에 들어오고 나갈 수 있데 하는 메커니즘이다.
• 구축/설정 : Axis를 통해 웹 서비스를 사용할 수 있도록 하는 수단이다.
• Seriaizers / Deserializers : Java와 같은 원래 Datatype을 XML로 변환하는 코드/원래 Datatype으로 복원하는 코드이다.

1. Axis Engine

Axis Engine은 여러 컴포넌트, 즉 Handler를 이용해 SOAP message의 흐름을 운영할 뿐만 아니라 이데 대한 순서를 조정하는 책임을 갖는다.

2. Handler & Chain

Chain은 순서대로 정렬된 코드형태의 컴포넌트 모음을 말하며 Axis는 정해진 순서대로 이들을 순차적으로 기동하게 되는데, 이렇게 순차적으로 기동되는 컴포넌트들을 가리켜 Handler라고 한다. 각 Handler는 웹 서비스 기동 전 후의 message에 대해 추가적인 처리를 수행할 필요가 있을 경우에 사용되는데 logging이나 SOAP Header Block을 처리하기 위해 많이 쓰인다. 그럼 웹 서비스 자체내에서 해당 로직, 즉 바로 앞에서 예로 든 logging이나 SOAP Header block처리 같은,을 처리하지 않고 Handler를 사용해서 처리할까? 이유는 웹 서비스 코드는 비즈니스 관점에서 해당 로직만을 처리함으로써 재사용성이 증대되고 각 Handler는 다른작업에 개의치 않고 각자의 고유역할에만 전념할 수 있으므로 코드가 중복되는 여지를 없앨 수 있으며 Axis설정을 통해 새로운 Handler를 추가하거나 삭제하는 식으로 처리가 가능함으로 인해 웹서비스의 재사용성을 증대시키는 역할을 할 수 있기 때문이다. 만약 Security가  적용되어 있는 기존의 웹 서비스에 RealiableMessage를 적용해야 한다는 요구사항이 발생한다면 기존의 로직을 수정하지 않고 간단하게 RealiableMessage를 처리할 수 있는 Handler를 제작한 후 Axis설정만으로 해당 Handler를 SOAP message처리에 참여시킴으로써  비즈니스 로직을 처리하는 웹 서비스, 보안관련사항을 처리하는 Handler, ReliableMessage를 처리하는 Handler를 각각의 역할만 하도록 제한시킬 수 있는 것이다.

그럼 웹 서비스에 대해 정의되어 있는 Handler의 Chain이 모든 요청에 대해 기동할까? 답은 그렇지 않다. 아니 설정을 통해 모든 요청에 대해 기동할 수도 있고 특정부분만이 기동할 수도 있다. 다음 그림을 보도록 하자

Figure1. Axis Server Architecture.

Figure1은 Axis의 Server단의 Architecture를 도식으로 표현한 것이다. (Apache Axis 도식 참조) 작은 cylinder는 handler, 작은 cylinder를 감싸는 큰 cylinder는 chain을 나타낸다.

Axis Engine내에 크게 3부분(Transport, Global, Service)으로 구성되어 있는데, Transport는 전송매체지정체인으로 특정 전송매체(HTTP, SMTP, MIME...)에 따라 압축 또는 인증 등의 일을 처리하기 위해 정의될 수 있으며, Global은 전역체인으로 웹 서비스의 종류에 상관없이 동일한 처리를 핑요로 하는 경우에 정의된다. 또한 Service는 특정웹서비스용체인으로 말그대로 특정 웹서비스만을 위한 Chain을 필요로 하는 경우에 정의된다. 서비스내의 Provider는 일종의 Handler인데 backend의 실질적인 웹서비스와 Axis를 잇는 중계자 역할을 한다. 즉, SOAP message를 해석해서 필요로 하는 웹 서비스와 관련된 코드 부분을 찾아내어 해당 웹서비스를 기동시키는 역할을 한다. 예를 들어,  XML을 자바객체로 변환한 후 기동시킬 적정한 자바 메소드를 찾아 기동시키고, 가능한 응답 데이터를 XML 형태로 재변환하여 응답 SOAP message에 넣는 일을 한다.  Transport Listener는 request의 특정 protocol의 data를 받는 최초 접점으로 해당 protocol-specific data를 Message Object로 package한 후 Message Object와 각종 properties를 MessageContext에 설정한 후 MessageContext를 Axis에 전달하는 역할을 한다. 장황해서 좀 그런데 다시 정리하면...

 1). TransportListener는 요청에 대해 MessageContext Object를 Axis에 전달한다.

 2). 전송매체지정체인이 정의되어 있으면 Chain에 속한 Handler가 기동된다.

 3). 전역체인이 정의되어 있으면 해당 Chain이 기동된다.

 4). 특정웹서비스용체인이 있으면 해당 Chain이 기동된다.

 5). 응답도 이와 비슷한 과정을 거친다........

3. Transport

SOAP message를 전달하기 위해 전송매체가 HTTP만이 쓰이는 것은 아니다. SMTP, FTP 등이 사용될 수 있는데 실질적으로 Axis자체는 다중 전송매체를 지원하지는 않는다. 무슨말인고 하니, Axis는 들어오는 메세지로 Axis Engine이 호출되어 다시 응답메세지로 보내는 단순한 코드모음 이상, 이하도 아니며 또한 SOAP message를 기다리는 TransportListener는 Axis Engine의 일부가 아니다. Axis에서는 AxisServlet이라는 TransportListener를 제공하고 만약 특별한 처리가 필요하다면 전송매체에 맞는 TransportListener를 새로 작성해야만 한다. 따라서 Axis Engine은 TransportListener에 의해 메커니즘이 관리되는데 Axis Engine의 기동(요청마다 Engine이 생성되느냐 혹은 하나의 instance를 공유하느냐), message의 Axis Engine으로의 전달, 어떠한 전송매체가 사용되는지를 Axis Engine에게 통보함으로써 Axis는 설정된 특정전송매체지정체인을 기동하게 된다.

지금까지 Axis Server Architecture를 간략하게 살펴봤는데 Client Architecture는 Provider대신에 Sender라는 전송매체전송자라는 Handler가 대체되고 Transport, Global, Service가 반대로 실행된다고 생각하면 된다. Figure2를 참조하고 자세한 사항은 Apache Axis관련 사이트를 참조하자.

Figure2. Axis Client Architecture

지금까지 Axis의 기본 Architecture에 대해 살펴보았는데 처음보면 이게 무엇인지 감을 잡기 힘들다.(나만 그런가?ㅡ.ㅡ) 우선은 이것만 기억하자. Axis는 SOAP message처리 Engine으로 Handler라는 기본 component 들에 의해 message처리가 이루어진다. (너무 간단한가? 내 실력이 요것밖에 안된다. 아직...ㅜ.ㅜ) 

[ Axis Installation ]

여기다 정리하려고 했는데 좋은 문서가 벌써 있는것 같아 해당 문서사용.apache_axis.doc

문서를 보면서 그냥 한번 따라해보면 좋고, 아님 말고, 그래도 한번 해보는 것이 둏지 아니할런지...

• BusinessAgreement
• BusinessAgreementWithComplete

Figure1. The Business Transactions scenario

[Step1]. application은 WS-Coordination framework의 activation service를 사용해서 business activity를 생성한다.

List1. Application creates a business activity

<soapenv>
<soapbody>
  <wscoor:CreateCoordinationContext>
    <ActivationService>
        <Address>
             http://myActiviationService
        </Address>     
    </ActiviationService>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationType>
         http://xml-soap.org/2002/xx/BusinessActivity
    </CoordinationType>
   </wscoor:CreateCoordinationContext>
</soapbody>
<soapenv>

[Step2]. Coordinator는 CoordinationContext를 return한다.

CoordinationContext는 하위의 atomic transaction과의 관계를 정의하기의해 사용된다.

List2. Coordination Service returns a CoordinationContext

<soapenv>
<soapbody>
   <wscoor:CreateCoordinationContextResponse>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationContext>
        <Identifier>
             http://myCoordinationService/ts/activity1
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/BusinessActivity
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>            
        </RegistrationService>
    </CoordinationContext>
  </wscoor:CreateCoordinationContextResponse>
</soapbody>
</soapenv>

[Step3]. Application은 activity를 생성한다. 여기서의 activity는 Step1의 business activity를 구성하나는 하위 activity이다. 즉 parent와 child의 관계.

List3. Application sends CreateCoordinationContext

<soapenv>
<soapbody>
  <wscoor:CreateCoordinationContext>
    <ActivationService>
        <Address>
             http://myActiviationService
        </Address>     
    </ActiviationService>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationType>
         http://xml-soap.org/2002/xx/BusinessActivity
    </CoordinationType>
   </wscoor:CreateCoordinationContext>
   <CurrentContext>
        <Identifier>
             http://myCoordinationService/ts/activity1
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/BusinessActivity
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>            
        </RegistrationService>
   </CurrentContext>
   <myActivationService:NestedCreate/>
</soapbody>
<soapenv>

Application은 business task를 위해 activity를 생성하는데 마찬가지로 Activation Service를 사용한다. 또한 List3에서 보면 알겠지만 해당 business task가 전체적인 business activity와 관련이 있다는 것을 나타내기 위해 NestedCreate라는 option을 정의하고 있다.

[Step 4].Coordinator는 CoordinationContext를 return한다.

List4. Coordination Service returns a CoordinationContext

<soapenv>
<soapbody>
   <wscoor:CreateCoordinationContextResponse>
    <RequesterReference>
        <Address>
             http://myApplicationProgram
        </Address>
    </RequesterReference>
    <CoordinationContext>
        <Identifier>
             http://myCoordinationService/ts/activity2
        </Identifier>
        <CoordinationType>
             http://xml-soap.org/2002/xx/BusinessActivity
        </CoordinationType>
        <RegistrationService>
             <Address>
                  http://myCoordinationService/tm/myRegistrationService
             <Address>            
        </RegistrationService>
    </CoordinationContext>
  </wscoor:CreateCoordinationContextResponse>
</soapbody>
</soapenv>

여기서 return된 CoordinationContext는 Step2에서 return 된 Context와는 다른 Context이다. 다시 말하자면 Step2에서 return된 Context는 전체적인 long-running business activity를 관리하기 위한 Context이고 Step4에서 return된 Context는 long-running business activity의 부분을 이루는 atomic transaction activity이다. 여기서 atomic transaction activity를 business task라 명하고 있고 long-running business activity는 business activity라 명하고 있다는 점을 잊지말자. activity의 하위가 task라고 생각하면 될 것 같다.

[STEP 5]. application은 web service에서 제공하는 operation을 수행한다.

List5. SOAP Header with CoordinationContext

URL:http//myhost/myBank
<soapenv>
<soapheader>
    <wscoor:CoordinationContext
    <sequence>
       <CoordinationContext-Parent(Activity1)/>
       <CoordinationContext-Child (Activity2/>
     </sequence>  
</soapheader>
<soapbody>
     <debitAccount ... />
</soapbody>
</soapenv>

XML message를 보면 알겠지만 SOAP Header에 CoordinationContext를 포함하고 있다. activity scope내의 taks는 계층적인 구조를 띄는데 이러한 activity와 task의 관계정보는 Web Service가 invoke될때 operation에 포함된다.

[ Registration ]

[STEP6] Business task registers with the Business activity

business task가 atomic transaction의 메커니즘으로 수행되어 지고 난 후  (Part1 참조) 해당 business task는 business activity에 등록된다. 또한 전체적인 business activity가 fail되면 Registration은 관련 Compensation Process를 invoke한다.

List6. A compensation registration message when business activity fails

<soapenv>
<soapbody>
  <wscoor:Register>
    <RegistrationService>
        <Address>http://myRegistrationService</Address>
    </RegistrationService>
    <RequesterReference>
        <Address>http://myBusinessTask</Address>
    </RequesterReference>
    <ProtocolIdentifier>
        http://xml-soap.org/2002/xx/BusinessActivity/2PC
    </ProtocolIdentifier>
    <ParticipantProtocolService>
        <Address>http://myResource</Address>
    </ParticipantProtocolService>
  </wscoor:Register>
</soapbody>
</soapenv>

[STEP7] Registration Service는 등록요청에 대한 응답으로 bpCoordinatorRef를 return한다.

List7. Registration services sends a bpCoordinatorRef reference

<soapenv>
<soapbody>
  <wscoor:RegisterResponse>
     <RequesterReference>
          <Address>
               http://myBusinessTask
          </Address>
     </RequesterReference>
<CoordinatorProtocolService>
     <Address>
  http://myCoordinator
     </Address>
</CoordinatorProtocolService>
  </wscoor:RegisterResponse>
</soapbody>
</soapenv>

[ Completion/Coordination ]

[STEP8] business activity는 어느 business task가 완료되었는지를 점검하기 위해 Complete Message를 보낸다

Listing 8. Business activity issues a Complete message
<soapenv>
<soapheader>
   <ParticipantProtocolService>
     <Address>
  http://myResource
     </Address>
   </ParticipantProtocolService>
</soapheader>
   <wstx:Notification>
      type=BusinessActivity
      portType=BusinessAgreementwithComplete
      message=Complete
  </wstx:Notification>
</soapbody>
</soapenv>

[STEP9] business task는 해당 task가 성공적으로 완료되었으면 Completed message를 보낸다.

Listing 9. Business Task sends the Completed message
<soapenv>
<soapheader>
   <CoordinatorProtocolService>
     <Address>
  http://myCoordinator
     </Address>
   </CoordinatorProtocolService>
</soapheader>
   <wstx:Notification>
      type=BusinessActivity
      portType=BusinessAgreementwithComplete
      message=Completed
  </wstx:Notification>
</soapbody>
</soapenv>

참고서적

Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services by Thomas Erl
Service-Oriented Architecture : Concepts, Technology and Design by Thomas Erl

Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More   by Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson
 

Radio Head - No Surprise

A heart that's full up like a landfill,
a job that slowly kills you,
bruises that won't heal.
You look so tired-unhappy,
bring down the government,
they don't, they don't speak for us.
I'll take a quiet life,
a handshake of carbon monoxide,

with no alarms and no surprises,
no alarms and no surprises,
no alarms and no surprises,
Silent silence.

This is my final fit,
my final bellyache,

with no alarms and no surprises,

no alarms and no surprises,
no alarms and no surprises please.

Such a pretty house
and such a pretty garden.

No alarms and no surprises,
no alarms and no surprises,
no alarms and no surprises please.

언제부터인지 모르겠다.

감성이 필요할때.................

절대적으로 감성이 필요할때...................

누군가에게 의지하고 싶을때 듣게 되었다.

나른해지고

미소가 나오고

아련한 옛 추억의 행복했던 시절들이

가볍게 가슴 한 켠을 휩쓸고 간다.

가는 것이 아쉬워

반복해서 듣다보면 모하나 싶기도 하지만서도

너무나 따뜻한 기분에 취해 ..........

by lovemade 2006-02-13 21:41

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="BookQuoteWS"

 targetNamespace="http://www.Monson-Haefel.com/jwsbook/BookQuote"

 xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote"

 xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"

 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

 xmlns="http://schemas.xmlsoap.org/wsdl/">

  <!-- message elements describe the input and output parameters -->

  <message name="GetBookPriceRequest">

    <part name="isbn" type="xsd:string" />

  </message>

  <message name="GetBookPriceResponse">

    <part name="price" type="xsd:float" />

  </message>

  <!-- portType element describes the abstract interface of a Web service -->

  <portType name="BookQuote">

    <operation name="getBookPrice">

      <input name="isbn" message="mh:GetBookPriceRequest"/>

      <output name="price" message="mh:GetBookPriceResponse"/>

    </operation>

  </portType>

  <!-- binding tells us which protocols and encoding styles are used -->

  <binding name="BookPrice_Binding" type="mh:BookQuote">

    <soapbind:binding style="rpc"

     transport="http://schemas.xmlsoap.org/soap/http"/>

    <operation name="getBookPrice">

      <soapbind:operation style="rpc"

       soapAction=

       "http://www.Monson-Haefel.com/jwsbook/BookQuote/GetBookPrice"/>

        <input>

          <soapbind:body use="literal"

           namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />

        </input>

        <output>

          <soapbind:body use="literal"

           namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />

        </output>

    </operation>

  </binding>

  <!-- service tells us the Internet address of a Web service -->

  <service name="BookPriceService">

    <port name="BookPrice_Port" binding="mh:BookPrice_Binding">

      <soapbind:address location=

       "http://www.Monson-Haefel.com/jwsbook/BookQuote" />

    </port>

  </service>

</definitions>

• definitions Element
• message Element
• portType Element
• service Element

이외에도 types element, import element등이 있는데 예제에는 사용하고 있지 않다.

[ definitions element ]

definitions는 root element로서 해당 WSDL문서에서 사용할 XML namespace 선언을 한다. attribute로 나오는 targetNamespace는 해당 WSDL문서에서 정의된 element들의 namespace를 식별하기 위해 정의하는 attribute이다.

- The message element for RPC-Style Web Services

GetBookPriceRequest message는 client에서 web service를 call할시에 전송되는 input 전문을 정의하고 있으며 GetBookPriceResponse message는 web service에서 client에게 전송되는 전문을 정의하고 있다.

<message name="GetBookPriceRequest">
  <part name="isbn" type="xsd:string" />
</message>
<message name="GetBookPriceResponse">
  <part name="price" type="xsd:float" />
</message>
  

- The message element for Document-Style Web Services

types XML schema에서 built-in tyle으로 정의되어 질 수 없는 여는 data type을 정의하기 위한 container의 역할을 하는  element이며, import는 다른 XML document를 사용하기 위해 쓰이는 element이다. 해당 구문은 http://www.Monson-Haefel.com/jwsbook/po.xsd에 위치한 po.xsd를 import해서 사용하겠다는 의미이다. po.xsd에는 XSD schema validation한 내용이 정의되어 있을 것이다. 

<types>
    <xsd:schema targetNamespace="http://www.Monson-Haefel.com/jwsbook/PO">
      <!-- Import the PurchaseOrder XML schema document -->
      <xsd:import namespace="http://www.Monson-Haefel.com/jwsbook/PO"
       schemaLocation="http://www.Monson-Haefel.com/jwsbook/po.xsd" />
    </xsd:schema>
</types>
<message name="SubmitPurchaseOrderMessage">
    <part name="order" element="mh:purchaseOrder" />
</message>

[ portType element ]

portType는 개념적으로 java interface라고 보면 된다. 실제 implementation은 abstract type과 methods만을 정의한다. implementation은 binding element와 service element에 의해 이루어지는데 이때 protocol, encoding, address등이 정의되면서 실제적인 구현의 단계에 이르게 된다.portType element내의 operation element는 method라 생각하면 되고 input, output element가 client와 web service사이에 전송되어져하는 전문을 의미한다.

[ operation element ]

portType element내에 정의된 operation element는 input, output, fault를 정의하기 위해 하나이상의 message 정의를 사용한다. 

<portType name="BookQuote">
  <operation name="getBookPrice">
     <input name="isbn" message="mh:GetBookPriceRequest"/>
     <output name="price" message="mh:GetBookPriceResponse"/>
     <fault name="InvalidArgumentFault" message="mh:InvalidArgumentFault"/>
  </operation>
</portType>

input은 web service에게 전해지는 전문이며, output은 client에게 보내지는 전문, fault는 operation 수행시 발생하는 error에 대한 내용을 저장하기 위해 사용된다.

[ binding element ]

portType이 추상적인 인터페이스를 제공했다면 실질적인 implementation은 binding에서 처리된다. 즉 protocol을 어떤 것을 사용할 것인지, messaging style(RPC or document)과 encoding style은 어느 것을 사용할 것인지 binding에서 정의한다. 우리가 일반적으로 사용하는 protocol은 SOAP이지만 SMTP나 MIME같은 protocol도 사용될 수 있다.

List2. binding example

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="BookQuoteWS"

 targetNamespace="http://www.Monson-Haefel.com/jwsbook/BookQuote"

 xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote"

 xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"

 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

 xmlns="http://schemas.xmlsoap.org/wsdl/">

  ...

  <!-- binding tells us which protocols and encoding styles are used -->

  <binding name="BookPrice_Binding" type="mh:BookQuote">     --- 1

    <soapbind:binding style="rpc"                            --- 2

     transport="http://schemas.xmlsoap.org/soap/http"/>

    <operation name="getBookPrice">

      <soapbind:operation style="rpc"

       soapAction=

       "http://www.Monson-Haefel.com/jwsbook/BookQuote/GetBookPrice"/>

        <input>

          <soapbind:body use="literal"                       --- 3

           namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />

        </input>

        <output>

          <soapbind:body use="literal"

           namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />

        </output>

    </operation>

  </binding>

  ...

</definitions>

1. binding element의 attribute인 type은 portType이 'BookQuote'인 것을 binding에서 실제 implementation하겠다는 것을 선언하고 있다.

2. implementation시 messaging style은 RPC이며 transport 값의 의미는 network application protocol은 SOAP over HTTP를 사용하겠다는 것을 의미하고 있다.

3. literal의 의미는 해당 element에 사용되는 XML document가 해당 XML Schema(여기서는 http://www.Monson-Haefel.com/jwsbook/BookQuote/GetBookPrice)에 validation해야 된다는 의미이다.

[ service element ]

service element는 1개 이상의 port element를 포함하고 있는데 각각의 port는 다른 web service를 나타낸다. 따라서 port는 특정 binding에 대한 URL을 부여할 수 있는데 하나의 binding에 대해 1개 이상의 URL을 부여할 수도 있다. 이 경우에는 load balancing 혹은 failover용도로 사용된다.  

List3. service example

<service name="BookPriceService">

  <port name="BookPrice_Port" binding="mh:BookPrice_Binding">

    <soapbind:address location=

     "http://www.Monson-Haefel.com/jwsbook/BookQuote" />

  </port>

  <port name="BookPrice_Failover_Port" binding="mh:BookPrice_Binding">

    <soapbind:address location=

     "http://www.monson-haefel.org/jwsbook/BookPrice" />

  </port>

  <port name="SubmitPurchaseOrder_Port"

   binding="mh:SubmitPurchaseOrder_Binding">

    <soapbind:address location=

     "https://www.monson-haefel.org/jwsbook/po" />

  </port>

</service>
 
List3에서는 service element내에 3개의 port 를 정의하고 있다. 2개는 같은 web service를 가리키고 있으며 하나는 name에서 지칭하는 바와 같이 failover시 사용됨을 알 수 있다. address element의 location은 실질적인 Internet URL 주소를 나타낸다. 
 
솔직히 SOAP도 마찬가지겠지만 WSDL얘기를 하자면 이정도 갖고는 어림도 없다. 현재 web services 의 구조상 SOAP과 WSDL은 뗄래랴 뗄수도 없는 관계인지라 같이 예제를 들면서 비교해보면 좋은일이겠지만 겅부해야할 것은 많고 나름대로의 게으름(^^)으로 인해 이번절은 여기까지.... 다음 SOAP Part2로 넘어간다. Axis에 대해서 한번 들어가보자.