MVVM아키텍쳐 패턴 소개 사이트

좋은 사이트가 있어 정보 기록차 링크합니다

https://justhackem.wordpress.com/2017/03/05/mvvm-architectural-pattern/


좋은 사이트 링크합니다

자바스크립트 관련 요약본? 실수모음?잘된 사이트

http://bonsaiden.github.io/JavaScript-Garden/ko/#intro

펌: http://daddycat.blogspot.kr/2011/05/chapter-3-wsdlweb-service-description.html

 

 

Chapter 3 WSDL(Web Service Description Language)


SOAP은 원격 프로시저 호출을 할 수 있는 구조만 제공할 뿐이고, 실제로 호출하는 원격 프로시저명과 필요한 인자, 그리고 반환형이 무엇인지 모른다면 원격 프로시저를 호출하는 내용을 작성 할 수가 없다. 또한 SOAP 메시지를 전송하는 전송 프로토콜의 종류 및 웹 서비스 시스템의 URL(endpoint) 정보도 알고 있어야 한다. 그래서 웹 서비스 제공자는 웹 서비스의 기능을 명세화하여, UDDI 레지스트리에 공개를 해야 한다. WSDL로 XML 문서를 작성하여 웹 서비스에 대한 내용을 명세화 한다. WSDL 문서 사용의 장점은 다음과 같다.
· 서비스 공용 저장소(UDDI)를 이용할 경우 실제 Web Service의 위치와 상관 없이 자신이 원하는 서비스를 찾아서 이용할 수 있다.
· WSDL은 누구나 참조가 가능하기 때문에 이를 통해 쉽게 Web Service 사용에 필요한 정보를 얻을 수 있다.
1. WSDL 문서의 구조

· types는 교환된 메시지를 설명하는 데 사용된 데이터 형식 정의를 제공합니다.
· message는 전송되는 데이터의 추상 정의를 나타냅니다. 메시지는 논리적인 부분으로 이루어져 있으며 각 부분은 특정 형식 시스템 내의 정의와 연관되어 있습니다.
· portType은 추상 작업의 집합이며 각 작업은 입력 메시지 및 출력 메시지를 참조합니다.
· binding은 특정 portType에 의해 정의된 메시지 및 작업에 대해 구체적인 프로토콜과 데이터 형식을 지정합니다.
· port는 바인딩에 대해 주소를 지정하기 때문에 단일 통신 종점을 정의합니다.
· service는 관련된 포트의 집합을 집계하는 데 사용됩니다.
<definition>
WSDL 문서의 루트 엘리먼트이다. 일반적으로 WDSL 문서 내에서 사용되는 대부분의 네임스페이스들을 선언한다. tarrgetNamespace는 현재 WSDL 문서에서 작성될 내용에 대한 네임스페이스 이름을 기술해 준다. WSDL 문서에서 정의되는 원격 프로시저는 이 네임스페이스 이름을 갖는다. 그리고 웹 서비스 클라이언트는 원격 프로시저를 호출할 때 반드시 이 네임스페이스 이름을 이용해서 QName 형태로 원격 프로시저명을 기술해야 한다.
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
</definitions>


WSDL 문서에서 관례적으로 많이 사용되는 네임스페이스 선언
접두사
이름 공간 URI
정의
wsdl
http://schemas.xmlsoap.org/wsdl/ WSDL 프레임워크에 대한 WSDL 이름 공간.
soap
http://schemas.xmlsoap.org/wsdl/soap/ WSDL SOAP 바인딩에 대한 WSDL 이름 공간.
http
http://schemas.xmlsoap.org/wsdl/http/ HTTP GET & POST 바인딩에 대한 WSDL 이름 공간.
mime
http://schemas.xmlsoap.org/wsdl/mime/ MIME 바인딩에 대한 WSDL 이름 공간.
soapenc
http://schemas.xmlsoap.org/soap/encoding/ SOAP 1.1에 의해 정의된 인스턴스 이름 공간.
soapenv
http://schemas.xmlsoap.org/soap/envelope/ SOAP 1.1에 의해 정의된 인스턴스 이름 공간.
xsi
http://www.w3.org/1999/XMLSchema-instance XSD에 의해 정의된 인스턴스 이름 공간.
xsd
http://www.w3.org/1999/XMLSchema XSD에 의해 정의된 스키마 이름 공간.
tns
(다양함) “this namespace”를 의미하는 (tns) 접두사는 현재 문서를 참조하는 규칙으로 사용됩니다.
(기타)
(다양함) 다른 모든 이름 공간 접두사는 단지 예제일 뿐입니다. 특히, “http://example.com”으로 시작하는 URI는 어느 정도 응용 프로그램 종속적이거나 컨텍스트 종속적인 URI[4]를 나타냅니다.


<message>
원격 프로시저의 인자에 대한 정보와 리턴값에 대한 정보를 기술하는 엘리먼트이다. 인자에 대한 정보로는 인자의 수 및 인자의 데이터 타입을 말하고, 리턴값에 대한 정보는 리턴값에 대한 데이터 타입을 말한다. 원격 프로시저의 인자 하나는 하나의 message 엘리먼트로 작성된다.
String addBook1(String title, int price);
이 메서드를 message로 표현
<message name="addBookRequest">
<part name="title" type="xsd:string"/>
<part name="price" type="xsd:int"/>
</message>
<message name="addBook1Response">
<part name="result" type="xsd:string"/>
</message>


<type>
원격 프로시저의 인자 및 리턴값의 데이터 타입으로 사용될 복합 타입을 기술하기 위한 엘리먼트이다. 만약 인자 및 리턴값의 데이터 타입에 복합 타입을 사용하지 않는다면 WSDL 문서에서 이 엘리먼트는 생략될 것이다.
일반적인 분산 컴퓨팅 응용프로그램에서 인자형 및 리턴형이 객체 타입이라면 전송되기 전에 직렬화를 거쳐 이진 포맷으로 변환해야 한다. 그리고 받는 쪽에서는 역직열화르 ㄹ거쳐 객체로 다시 생성하는 작업을 해야 한다. 웹 서비스의 경우에도 웹 서비스 클라이언트 스텁 객체를 통해서 인자를 요청 SOAP 메시지로 마샬링하고, 웹 서비스 시스템은 타이 객체를 통해 SOAP 메시지를 언마샬링하여 원래의 인자 데이터형으로 복원한다.
WDSL 문서의<message> 엘리먼트에 기술되는 인자 및 리턴값의 데이터 타입이 XML Schema의 빌트인 심플타입으로 표현될 수있다면 XML Schema 타입을 직접 사용하지만 배열 및 구조체와 같은 XML Schema에 없는 데이터 타입이 인자 및 리턴값의 데이터 타입으로 사용된다면, 반드시 <types> 엘리먼트에 배열 및 구조체에 해당하는 복합 타입을 정의 해야 한다.
<types>
<schema
targetNamespace="복합 타입 네임스페이스명"
xmlns:tns=”복합 타입 네임스페이스명”
xmlns=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:wsdl=”http://schemas.xmlsoap.org/wdsl/”
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/">
<complexType name="복합 타입명">

</complexType>
</schema>
</types>


배열정의
<complexType name="배열의 이름">
<complexContent>
<restriction base=”soap-enc:Array”>
<attribute ref=”soap-enc:arrayType” wsdl:arrayType=”데이터 타입[]”/>
</restriction>
</complexContent>
</complexType>


구조체 정의
<complexType name="클래스명">
<sequence>
<element name=”멤버변수(Field)명” type=”데이터 타입”/>
<element name=”멤버변수(Field)명” type=”데이터 타입”/>

</sequence>
</complexType>


<portType>, <operation>
Web Service의 interface를 정의하는 부분 interface를 정의 한다는 의미는 <message>에서 정의한 메시지를 이용하여 어떻게 Web Service의 Method를 호출할 지에 대해 기술한다는 것을 의미 한다. <portType>은 하나 이상의 <operation>을 포함한다.
Java 메서드
public String say(String name) {
return name+"님 안녕하세요 Apache WSDL 입니다.";
}


WSDL문서 정의
<message name="say0Request">
<part name="name" type="xsd:string"/>
</message>
<message name="say0Response">
<part name="return" type="xsd:string"/>
</message>
<portType name="sayerPortType">
<operation name="say">
<input name="say0Request" message="tns:say0Request"/>
<output name="say0Response" message="tns:say0Response"/>
</operation>
</portType>


<binding>
앞에서 정의된 각 요소들을 실제 메시지 전달에 사용되는 프로토콜과 binding 하는 부분이다.
특정 프로토콜로 웹 서비스 시스템에 접속하는 것을 바인딩이라고 한다. 바인딩하는 방법을 모른다면 웹 서비스 클라이언트는 원격 프로시저에 대한 호출 방법을 비록 안다고 하더라도 호출 행위는 할 수 없다. 웹 서비스 클라이언트가 사용해야할 전송용 프로토콜에 대해서는 WDSL 문서상의 이 엘리먼트에 기술해주면 된다. 이 엘리먼트는 웹 서비스 시스템과 웹 서비스 소비자인 클라이언트 응용프로그램 간의 통신 방법을 기술하는 엘리먼트이다.
바인딩의 종류
· SOAP 바인딩 : 웹 서비스 시스템의 원격 프로시저를 호출할 때 SOAP를 통해서 호출 요청하는 방식을 말한다.
· HTTP 바인딩 : HTTP는 주로 SOAP메시지의 전송 프로토콜로 많이 사용되지만, 원격 프로시저 호출용 프로토콜로 직접 사용될 수 있다. HTTP만 해석하고, 전송할 수 있는 클라이언트 응용프로그램에서 웹 서비스의 원격 프로시저를 호출할 때 유용하다. 이러한 클라이언트 종류로 는 웹 브라우저, 휴대폰, PDA등이 있다.
· MIME 바인딩 : MIME는 SOAP과 HTTP에서 함께 사용하여 문자 데이터와 바이너리 데이터를 함께 전송할 때 사용할 수 있는 방식이다.
가장 흔히 사용되는 SOAP 바인딩
<binding name="sayerBinding" type="tns:sayerPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="say">
<soap:operation soapAction="" style="rpc"/>
<input name="say0Request">
<soap:body use="encoded" namespace="ApacheWSDL" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output name="say0Response">
<soap:body use="encoded" namespace="ApacheWSDL" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>


<service>, <port>
수신자와 웹 서비스 시스템의 URL(종점 : endpoint)정보를 기술한다.
<service name="ApacheWSDL">
<port name="sayerPort" binding="tns:sayerBinding">
<soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
</service>


자동 생성된WSDL
일반적으로 WSDL은 개발 IDE툴이나, JAX-RPC에서 제공하는 wsdeploy.bat, wscompile.bat을 이용하여 자동 생성한다. 다음은 oracle Jdeveloper을 이용한 자동생성 문서의 예이다.
<?xml version = '1.0' encoding = 'UTF-8'?>
<!--Generated by the Oracle9i JDeveloper Web Services WSDL Generator-->
<!--Date Created: Thu Jan 15 16:26:34 KST 2004-->
<definitions
name="TypeMappingWS"
targetNamespace="http://model/UserInfo.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://model/UserInfo.wsdl"
xmlns:ns1="http://model/ITypeMappingWS.xsd">
<types>
<schema
targetNamespace="http://model/ITypeMappingWS.xsd"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<complexType name="model_user" jdev:packageName="model" xmlns:jdev="http://xmlns.oracle.com/jdeveloper/webservices">
<all>
<element name="name" type="string"/>
<element name="age" type="int"/>
</all>
</complexType>
</schema>
</types>
<message name="getUser0Request">
<part name="name" type="xsd:string"/>
<part name="age" type="xsd:int"/>
</message>
<message name="getUser0Response">
<part name="return" type="ns1:model_user"/>
</message>
<portType name="UserInfoPortType">
<operation name="getUser">
<input name="getUser0Request" message="tns:getUser0Request"/>
<output name="getUser0Response" message="tns:getUser0Response"/>
</operation>
</portType>
<binding name="UserInfoBinding" type="tns:UserInfoPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getUser">
<soap:operation soapAction="" style="rpc"/>
<input name="getUser0Request">
<soap:body use="encoded" namespace="TypeMappingWS" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output name="getUser0Response">
<soap:body use="encoded" namespace="TypeMappingWS" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="TypeMappingWS">
<port name="UserInfoPort" binding="tns:UserInfoBinding">
<soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
</service>
</definitions>

 

'WebService' 카테고리의 다른 글

WSDL  (0) 2015.12.31
WS security  (0) 2014.01.29

gc에 대해서 가장 개요및 명확한 설명을 한 글이어서 퍼온다.

작성자분이 펴낸 책도 읽기를 개인적으로 권고하고 싶다.

출처 : http://d2.naver.com/helloworld/1329


Java Garbage Collection

지극히 개인적이고 주관적인 판단 기준을 먼저 밝힌다면, 가비지 컬렉션(Garbage Collection, 이하 GC)에 대해 잘 알고 있을수록 실력이 좋은 Java 개발자라고 생각합니다. GC 과정에 관심을 가질 정도라면 규모가 일정 이상인 애플리케이션을 제작해 본 경험이 있을 것입니다. 또, 어떤 GC 알고리즘을 선택할 것인지 고민할 정도면 스스로 제작한 애플리케이션의 특징을 정확히 이해하고 있다고 볼 수 있습니다. 이러한 판단 기준이 보편적이지는 않지만, GC에 대한 이해는 훌륭한 Java 개발자가 되기 위한 필수 조건이라는 데에는 별다른 이견이 없을 것입니다. 이 글에서는 GC 이론을 되도록 쉽게 소개하겠습니다. 피가 되고 살이 되는 글이 되기를 바랍니다.

가비지 컬렉션 과정 - Generational Garbage Collection

GC에 대해서 알아보기 전에 알아야 할 용어가 있다. 바로 'stop-the-world'이다. stop-the-world란, GC을 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것이다. stop-the-world가 발생하면 GC를 실행하는 쓰레드를 제외한 나머지 쓰레드는 모두 작업을 멈춘다. GC 작업을 완료한 이후에야 중단했던 작업을 다시 시작한다. 어떤 GC 알고리즘을 사용하더라도 stop-the-world는 발생한다. 대개의 경우 GC 튜닝이란 이 stop-the-world 시간을 줄이는 것이다.

Java는 프로그램 코드에서 메모리를 명시적으로 지정하여 해제하지 않는다. 가끔 명시적으로 해제하려고 해당 객체를 null로 지정하거나 System.gc() 메서드를 호출하는 개발자가 있다. null로 지정하는 것은 큰 문제가 안 되지만, System.gc() 메서드를 호출하는 것은 시스템의 성능에 매우 큰 영향을 끼치므로 System.gc() 메서드는 절대로 사용하면 안 된다(다행히도 NHN에서 System.gc() 메서드를 호출하는 개발자를 보진 못했다).

Java에서는 개발자가 프로그램 코드로 메모리를 명시적으로 해제하지 않기 때문에 가비지 컬렉터(Garbage Collector)가 더 이상 필요 없는 (쓰레기) 객체를 찾아 지우는 작업을 한다. 이 가비지 컬렉터는 두 가지 가설 하에 만들어졌다(사실 가설이라기보다는 가정 또는 전제 조건이라 표현하는 것이 맞다).

  • 대부분의 객체는 금방 접근 불가능 상태(unreachable)가 된다.
  • 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

이러한 가설을 'weak generational hypothesis'라 한다. 이 가설의 장점을 최대한 살리기 위해서 HotSpot VM에서는 크게 2개로 물리적 공간을 나누었다. 둘로 나눈 공간이 Young 영역과 Old 영역이다.

  • Young 영역(Yong Generation 영역): 새롭게 생성한 객체의 대부분이 여기에 위치한다. 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많은 객체가 Young 영역에 생성되었다가 사라진다. 이 영역에서 객체가 사라질때 Minor GC가 발생한다고 말한다.
  • Old 영역(Old Generation 영역): 접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사된다. 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생한다. 이 영역에서 객체가 사라질 때 Major GC(혹은 Full GC)가 발생한다고 말한다.

영역별 데이터 흐름을 그림으로 살펴보면 다음과 같다.

JavaGarbage1

그림 1 GC 영역 및 데이터 흐름도

위 그림의 Permanent Generation 영역(이하 Perm 영역)은 Method Area라고도 한다. 객체나 억류(intern)된 문자열 정보를 저장하는 곳이며, Old 영역에서 살아남은 객체가 영원히 남아 있는 곳은 절대 아니다. 이 영역에서 GC가 발생할 수도 있는데, 여기서 GC가 발생해도 Major GC의 횟수에 포함된다.

그렇다면 "Old 영역에 있는 객체가 Young 영역의 객체를 참조하는 경우가 있을 때에는 어떻게 처리될까?"라고 궁금해 하는 분도 더러 있을 것이다. 이러한 경우를 처리하기 위해서 Old 영역에는 512바이트의 덩어리(chunk)로 되어 있는 카드 테이블(card table)이 존재한다.

카드 테이블에는 Old 영역에 있는 객체가 Young 영역의 객체를 참조할 때마다 정보가 표시된다. Young 영역의 GC를 실행할 때에는 Old 영역에 있는 모든 객체의 참조를 확인하지 않고, 이 카드 테이블만 뒤져서 GC 대상인지 식별한다.

JavaGarbage2

그림 2 카드 테이블 구조

카드 테이블은 write barrier를 사용하여 관리한다. write barrier는 Minor GC를 빠르게 할 수 있도록 하는 장치이다. write barrirer때문에 약간의 오버헤드는 발생하지만 전반적인 GC 시간은 줄어들게 된다.

Young 영역의 구성

GC를 이해하기 위해서 객체가 제일 먼저 생성되는 Young 영역부터 알아보자. Young 영역은 3개의 영역으로 나뉜다.

  • Eden 영역
  • Survivor 영역(2개)

Survivor 영역이 2개이기 때문에 총 3개의 영역으로 나뉘는 것이다. 각 영역의 처리 절차를 순서에 따라서 기술하면 다음과 같다.

  • 새로 생성한 대부분의 객체는 Eden 영역에 위치한다.
  • Eden 영역에서 GC가 한 번 발생한 후 살아남은 객체는 Survivor 영역 중 하나로 이동된다.
  • Eden 영역에서 GC가 발생하면 이미 살아남은 객체가 존재하는 Survivor 영역으로 객체가 계속 쌓인다.
  • 하나의 Survivor 영역이 가득 차게 되면 그 중에서 살아남은 객체를 다른 Survivor 영역으로 이동한다. 그리고 가득 찬 Survivor 영역은 아무 데이터도 없는 상태로 된다.
  • 이 과정을 반복하다가 계속해서 살아남아 있는 객체는 Old 영역으로 이동하게 된다.

이 절차를 확인해 보면 알겠지만 Survivor 영역 중 하나는 반드시 비어 있는 상태로 남아 있어야 한다. 만약 두 Survivor 영역에 모두 데이터가 존재하거나, 두 영역 모두 사용량이 0이라면 여러분의 시스템은 정상적인 상황이 아니라고 생각하면 된다.

이렇게 Minor GC를 통해서 Old 영역까지 데이터가 쌓인 것을 간단히 나타내면 다음과 같다.

JavaGarbage3

그림 3 GC 전과 후의 비교

참고로, HotSpot VM에서는 보다 빠른 메모리 할당을 위해서 두 가지 기술을 사용한다. 하나는 bump-the-pointer라는 기술이며, 다른 하나는 TLABs(Thread-Local Allocation Buffers)라는 기술이다.

bump-the-pointer는 Eden 영역에 할당된 마지막 객체를 추적한다. 마지막 객체는 Eden 영역의 맨 위(top)에 있다. 그리고 그 다음에 생성되는 객체가 있으면, 해당 객체의 크기가 Eden 영역에 넣기 적당한지만 확인한다. 만약 해당 객체의 크기가 적당하다고 판정되면 Eden 영역에 넣게 되고, 새로 생성된 객체가 맨 위에 있게 된다. 따라서, 새로운 객체를 생성할 때 마지막에 추가된 객체만 점검하면 되므로 매우 빠르게 메모리 할당이 이루어진다.

그러나 멀티 스레드 환경을 고려하면 이야기가 달라진다. Thread-Safe하기 위해서 만약 여러 스레드에서 사용하는 객체를 Eden 영역에 저장하려면 락(lock)이 발생할 수 밖에 없고, lock-contention 때문에 성능은 매우 떨어지게 될 것이다. HotSpot VM에서 이를 해결한 것이 TLABs이다.

각각의 스레드가 각각의 몫에 해당하는 Eden 영역의 작은 덩어리를 가질 수 있도록 하는 것이다. 각 쓰레드에는 자기가 갖고 있는 TLAB에만 접근할 수 있기 때문에, bump-the-pointer라는 기술을 사용하더라도 아무런 락이 없이 메모리 할당이 가능하다.

간단하게 Young 영역에 대한 GC에 대해서 알아보았다. 위에서 이야기한 두 가지 기술(bump-the-pointer, TLABs)을 반드시 기억하고 있을 필요는 없다. 몰라도 쇠고랑 안차고 경찰 출동 안한다. 그러나 Eden 영역에 최초로 객체가 만들어지고, Survivor 영역을 통해서 Old 영역으로 오래 살아남은 객체가 이동한다는 사실은 꼭 기억하기 바란다.

Old 영역에 대한 GC

Old 영역은 기본적으로 데이터가 가득 차면 GC를 실행한다. GC 방식에 따라서 처리 절차가 달라지므로, 어떤 GC 방식이 있는지 살펴보면 이해가 쉬울 것이다. GC 방식은 JDK 7을 기준으로 5가지 방식이 있다.

  • Serial GC
  • Parallel GC
  • Parallel Old GC(Parallel Compacting GC)
  • Concurrent Mark & Sweep GC(이하 CMS)
  • G1(Garbage First) GC

이 중에서 운영 서버에서 절대 사용하면 안 되는 방식이 Serial GC다. Serial GC는 데스크톱의 CPU 코어가 하나만 있을 때 사용하기 위해서 만든 방식이다. Serial GC를 사용하면 애플리케이션의 성능이 많이 떨어진다.

그럼 각 GC 방식에 대해서 살펴보자.

Serial GC (-XX:+UseSerialGC)

Young 영역에서의 GC는 앞 절에서 설명한 방식을 사용한다. Old 영역의 GC는 mark-sweep-compact이라는 알고리즘을 사용한다. 이 알고리즘의 첫 단계는 Old 영역에 살아 있는 객체를 식별(Mark)하는 것이다. 그 다음에는 힙(heap)의 앞 부분부터 확인하여 살아 있는 것만 남긴다(Sweep). 마지막 단계에서는 각 객체들이 연속되게 쌓이도록 힙의 가장 앞 부분부터 채워서 객체가 존재하는 부분과 객체가 없는 부분으로 나눈다(Compaction).

Serial GC는 적은 메모리와 CPU 코어 개수가 적을 때 적합한 방식이다.

Parallel GC (-XX:+UseParallelGC)

Parallel GC는 Serial GC와 기본적인 알고리즘은 같지다. 그러나 Serial GC는 GC를 처리하는 스레드가 하나인 것에 비해, Parallel GC는 GC를 처리하는 쓰레드가 여러 개이다. 그렇기 때문에 Serial GC보다 빠른게 객체를 처리할 수 있다. Parallel GC는 메모리가 충분하고 코어의 개수가 많을 때 유리하다. Parallel GC는 Throughput GC라고도 부른다.

다음 그림은 Serial GC와 Parallel GC의 스레드를 비교한 그림이다.JavaGarbage4

그림 4 Serial GC와 Parallel GC의 차이 (이미지 출처: "Java Performance", p. 86)

Parallel Old GC(-XX:+UseParallelOldGC)

Parallel Old GC는 JDK 5 update 6부터 제공한 GC 방식이다. 앞서 설명한 Parallel GC와 비교하여 Old 영역의 GC 알고리즘만 다르다. 이 방식은 Mark-Summary-Compaction 단계를 거친다. Summary 단계는 앞서 GC를 수행한 영역에 대해서 별도로 살아 있는 객체를 식별한다는 점에서 Mark-Sweep-Compaction 알고리즘의 Sweep 단계와 다르며, 약간 더 복잡한 단계를 거친다.

CMS GC (-XX:+UseConcMarkSweepGC)

다음 그림은 Serial GC와 CMS GC의 절차를 비교한 그림이다. 그림에서 보듯이 CMS GC는 지금까지 설명한 GC 방식보다 더 복잡하다.

JavaGarbage5

그림 5 Serial GC와 CMS GC(이미지 출처)

초기 Initial Mark 단계에서는 클래스 로더에서 가장 가까운 객체 중 살아 있는 객체만 찾는 것으로 끝낸다. 따라서, 멈추는 시간은 매우 짧다. 그리고 Concurrent Mark 단계에서는 방금 살아있다고 확인한 객체에서 참조하고 있는 객체들을 따라가면서 확인한다. 이 단계의 특징은 다른 스레드가 실행 중인 상태에서 동시에 진행된다는 것이다.

그 다음 Remark 단계에서는 Concurrent Mark 단계에서 새로 추가되거나 참조가 끊긴 객체를 확인한다. 마지막으로 Concurrent Sweep 단계에서는 쓰레기를 정리하는 작업을 실행한다. 이 작업도 다른 스레드가 실행되고 있는 상황에서 진행한다.

이러한 단계로 진행되는 GC 방식이기 때문에 stop-the-world 시간이 매우 짧다. 모든 애플리케이션의 응답 속도가 매우 중요할 때 CMS GC를 사용하며, Low Latency GC라고도 부른다.

그런데 CMS GC는 stop-the-world 시간이 짧다는 장점에 반해 다음과 같은 단점이 존재한다.

  • 다른 GC 방식보다 메모리와 CPU를 더 많이 사용한다.
  • Compaction 단계가 기본적으로 제공되지 않는다.

따라서, CMS GC를 사용할 때에는 신중히 검토한 후에 사용해야 한다. 그리고 조각난 메모리가 많아 Compaction 작업을 실행하면 다른 GC 방식의 stop-the-world 시간보다 stop-the-world 시간이 더 길기 때문에 Compaction 작업이 얼마나 자주, 오랫동안 수행되는지 확인해야 한다.

G1 GC

마지막으로 G1(Garbage First) GC에 대해서 알아보자. G1 GC를 이해하려면 지금까지의 Young 영역과 Old 영역에 대해서는 잊는 것이 좋다.

다음 그림에서 보다시피, G1 GC는 바둑판의 각 영역에 객체를 할당하고 GC를 실행한다. 그러다가, 해당 영역이 꽉 차면 다른 영역에서 객체를 할당하고 GC를 실행한다. 즉, 지금까지 설명한 Young의 세가지 영역에서 데이터가 Old 영역으로 이동하는 단계가 사라진 GC 방식이라고 이해하면 된다. G1 GC는 장기적으로 말도 많고 탈도 많은 CMS GC를 대체하기 위해서 만들어 졌다.JavaGarbage6

그림 6 G1 GC의 레이아웃(이미지 출처: "The Garbage-First Garbage Collector" (TS-5419), JavaOne 2008, p. 19)

G1 GC의 가장 큰 장점은 성능이다. 지금까지 설명한 어떤 GC 방식보다도 빠르다. 하지만, JDK 6에서는 G1 GC를 early access라고 부르며 그냥 시험삼아 사용할 수만 있도록 한다. 그리고 JDK 7에서 정식으로 G1 GC를 포함하여 제공한다.

그러나 JDK 7을 실서비스에서 사용하려면 많은 검증 기간(1년은 필요하다는 생각이다)을 거쳐야 할 것으로 보이기 때문에, G1 GC를 당장 사용하고 싶어도 더 기다리는 것이 좋다는 것이 개인적인 생각이다. JDK 6에서 G1 GC를 적용했다가 JVM Crash가 발생했다는 말도 몇 번 들었기에 더더욱 안정화될 때까지 기다리는 것이 좋겠다.

마치며

이번 글에서는 Java의 GC에 대해서 아주 간단하게(?) 살펴보았다. 다음 글에서는 Java의 GC 상황을 모니터링하는 방법과 GC 튜닝 방법을 알아볼 예정이다.

마지막으로 한 가지 더 말하고 싶은 것이 있다. 어떤 서비스에서 A라는 GC 옵션을 적용해서 잘 동작한다고 그 GC 옵션이 다른 서비스에서도 훌륭하게 적용되어 최적의 효과를 볼 수 있다고 생각하지 말라는 것이다.

만약 애플리케이션에서 만들어지는 모든 객체의 크기와 종류가 같다면 회사에서 사용하는 모든 WAS의 GC 옵션을 동일하게 설정할 수 있다. 하지만, 각 서비스의 WAS에서 생성하는 객체의 크기와 생존 주기가 모두 다르고, 장비의 종류도 다양하다. WAS의 스레드 개수와 장비당 WAS 인스턴스 개수, GC 옵션 등은 지속적인 튜닝과 모니터링을 통해서 해당 서비스에 가장 적합한 값을 찾아야 한다. 이 이야기는 필자의 경험에서 나온 이야기가 아니고, 2010년 JavaOne에서 Oracle JVM을 만드는 엔지니어들이 한 말이다.

참고 자료

이 글의 내용과 그림은 다음의 자료를 참고했다.


'Java기초' 카테고리의 다른 글

Java Garbage Collection (펌)  (0) 2015.12.16
gc g1  (0) 2015.12.10
gc 방식  (0) 2015.12.10
gc 후 메모리 사용순서  (0) 2015.12.10
jvm 메모리  (0) 2015.12.10
단위 테스트 활용 방법: JUnit 참조 가이드  (0) 2014.11.25

'Java기초' 카테고리의 다른 글

Java Garbage Collection (펌)  (0) 2015.12.16
gc g1  (0) 2015.12.10
gc 방식  (0) 2015.12.10
gc 후 메모리 사용순서  (0) 2015.12.10
jvm 메모리  (0) 2015.12.10
단위 테스트 활용 방법: JUnit 참조 가이드  (0) 2014.11.25

'Java기초' 카테고리의 다른 글

Java Garbage Collection (펌)  (0) 2015.12.16
gc g1  (0) 2015.12.10
gc 방식  (0) 2015.12.10
gc 후 메모리 사용순서  (0) 2015.12.10
jvm 메모리  (0) 2015.12.10
단위 테스트 활용 방법: JUnit 참조 가이드  (0) 2014.11.25

'Java기초' 카테고리의 다른 글

gc g1  (0) 2015.12.10
gc 방식  (0) 2015.12.10
gc 후 메모리 사용순서  (0) 2015.12.10
jvm 메모리  (0) 2015.12.10
단위 테스트 활용 방법: JUnit 참조 가이드  (0) 2014.11.25
Browser별 file name깨짐현상  (0) 2014.08.13


'Java기초' 카테고리의 다른 글

gc 방식  (0) 2015.12.10
gc 후 메모리 사용순서  (0) 2015.12.10
jvm 메모리  (0) 2015.12.10
단위 테스트 활용 방법: JUnit 참조 가이드  (0) 2014.11.25
Browser별 file name깨짐현상  (0) 2014.08.13
replace replaceAll 차이  (0) 2014.08.01

출처 : http://egloos.zum.com/choungjae/v/470630

 

너무 정리를 잘해놓으신 사이트가 있어서, 사라지기 전 얼른 펌 합니다.

귀한 지식 정리 감사합니다.

 

LoadRunner(로드런너) 사용법

http://choungjae.egloos.com/470630

오늘은 성능테스트 및 로드런너에 대해 포스팅 하고자 합니다. ^^

 

저도 아직 얕은 지식이기 때문에, 네이버에서 도움을 얻고자 검색을 해봤는데..

로드런너에 대한 정보가 너무 없더라고요.. OTL..

그래서 저처럼 로드런너의 기능 및 사용법에 대해 궁금한데, 검색이 안돼는 분들을 위해서!!

로드런너에 대해 정보를 공유하고자 작성해 봅니다.

 

회사에서 점심시간에 틈틈히 짬내서 작성하다 보니.. 엄청 오래 걸렸네요. ㅠㅠ

각설하고!! 시작하겠습니다!! ㅎㅎ

 

아시다시피 로드런너는 HP에서 제공하는 값 비싼?? 성능테스트 툴 입니다.

QA나 테스터가 성능테스트를 성공적으로 수행하기 위해서는, 우선 성능테스트에 대한 전반적인 지식이 있어야 한다고 생각하기에 간략한 설명부터 시작해 보도록 하겠습니다.

 

성능테스트에서 성능은 시스템의 처리량, 속도, 메모리 사용량 등이 주어진 환경에서 명시된 기능에 대해 정상적으로 수행하는 것을 말합니다.

사용자 요청을 처리하기 위해 소요된 응답시간은 클라이언트에서 측정하고, 단위 시간당 시스템에서 처리되고 있는 처리량은 서버에서 측정합니다. 보통 웹기반 시스템에서는 성능 측정의 기준을 TPS(Transaction Per Second - 단위시간당 처리건수)로 합니다.

 

성능테스트의 목적을 다음과 같이 간략하게 정리해 볼 수 있습니다.

1. 안정적인 서비스를 위해 안정성 확보

2. 다수의 사용자에 의하여 발생할 수 있는 부하에 대한 예방

3. 서버의 최적화를 위해 서버환경 검사

4. 병목 구간을 파악하여 수정

 

그리고, 목적에 따라 다음과 같은 3개의 유형으로 분류할 수 있습니다.

1. 단위테스트 - 단위 별 업무의 최대한의 성능을 측정하는 단계

2. 통합테스트 - 목표를 정해놓고 계산된 부하를 발생시켜 측정하는 단계

3. 임계테스트 - 정해놓은 목표없이 도출할 수 있는 최대 성능을 측정하는 단계

 

아래는 성능테스트의 주요 용어인데요. 꼭 읽어보시기 바랍니다.

1. Concurrent Users (동시사용자) - 해당 시스템을 사용하기 위한 사용자로서, Active Users와 Inactive Users로 분류할 수 있습니다.

Active Users는 Request를 수행한 후, 응답을 기다리고 있는 사용자이며, Inactive Users는 Request를 수행하지 않고 대기중인 사용자 입니다.

2. Load (부하) - 사용자들이 테스트하고자 하는 시스템을 단위시간당 몇 건으로 호출 하고 있는지에 대한 빈도

3. Think Time (대기시간) - 사용자가 다음 요청을 전송하기 전까지의 시간

4. Response Time (응답시간) - 사용자 요청을 처리하는데 소요되는 총 시간

5. Request Interval (호출 간격) - 호출간격 = Response Time + Think Time

6. Throughput (처리량) - 대상 웹 서버가 부하발생 클라이언트에게 송신한 데이타량

7. Vuser (Virtual user) - 시스템에 부하를 주기 위한 가상 사용자

8. Transaction (작업단위) - 하나의 작업이 시작하여 완료되는 시점을 하나의 트랜잭션으로 정의

9. TPS (단위시간당 처리건수) - 단위 시간에 처리 가능한 트랜잭션의 수(TPS = ConcurrentUser/Request Interval)

10. Test Script - 시스템의 성능에 대해 확인하기 위해서 레코딩한 소스

11. Test Scenario - 어떤 방식으로 시스템에 부하를 줄 것인지 정하는 방식

12. 병목현상 - 부하가 많이 걸려 전체 시스템에 영향을 주는 현상

 

성능테스트 프로세스는 각 회사마다 다르지만 저는 다음의 4단계로 분류해 봤습니다.

기획 및 분석 > 설계 및 구현 > 테스트 실행 > 결과 분석 및 평가

1. 기획 및 분석 - 요구사항에 대해 검토한 후, 계획 수립

2. 설계 및 구현 - 성능 목표를 설정하여 테스트 시나리오를 설계하고 테스트 환경을 구축한다.

3. 테스트 실행 - 성능 테스트를 실행하여 모니터링 한 후, 해당 결과가 초반에 설정한 성능 목표에 충족하는지 확인한다.

4. 결과 분석 및 평가 - 결과 데이터를 병합하고 유관부서와 공유하여 함께 분석한다.

 

이것으로 성능테스트에 대한 간략한 설명을 마치고...

로드런너 사용방법에 대해 말씀 드리겠습니다.

로드런너는 크게 3가지 방법으로 분류할 수 있습니다.

1. 스크립트 작성

2. 시나리오 작성

3. 실행 및 결과분석

 

아주 간단하죠??

 

자 이제 1번인 스크립트 작성부터 시작하겠습니다.

 

시작 > Mercury LoadRunndr > Applications > Virtual User Generator 선택하여 Vugen 실행

New 클릭하여 Web (HTTP/HTML)을 선택

 

 

 

URL Address에 레코딩 하고자 하는 주소를 입력 합니다.

Record into Action

- Init: 시작하면서 한번만 실행되는 영역

- Action: 반복적으로 실행되는 영역

- End: 종료되면서 한번만 실행되는 영역

 


 

Start Recording 에서 Options을 선택하여 설정을 몇가지 변경해줘야 합니다.

Options > Recording > HTML AdvancedAdvaced > 아래의 스샷과 같이 설정

- HTML-based script: browser application

- URL-based script: non-browser application

- A script describing user actions: 사용자 액션을 설명하는 스크립트

- A script containing explict URLs only: 명시적인 URL만 포함하는 스크립트

 

 

 

Options > Advanced > Support charset > UTF-8 선택하여 OK클릭

- UTF-8: UTF-8 인코딩 지원

 

참고로, Recording Options은 한번만 설정해 놓으면 이후부터는 똑같이 적용이 됩니다.

 

설정 완료 후, Start Recording 창에서 OK 버튼을 클릭하면, 설정해 놓은 URL Address 페이지를 열어 레코딩을 시작합니다.

Recording bar의 events가 count되면 정상적으로 동작하는 것 입니다.

 

 

 

측정하고자 하는 페이지가 완전히 열린 것을 확인하고 STOP 버튼을 클릭하여 레코딩을 종료합니다.

 

 

 

레코딩을 종료한 후, 측정한 스크립트를 저장합니다.

 

 

 

트랜잭션이 시작되는 부분을 마우스로 클릭한 후, Insert Start Transaction 버튼을 클릭하여 Transaction Name을 입력합니다.

 

 

 

트랜잭션이 끝나는 부분도 마찬가지로 마우스로 클릭한 후, Insert End Transaction 버튼을 클릭하여 Transaction Name을 입력합니다.

시작할때 입력한 이름이 나오므로, OK버튼만 클릭하면 됩니다.

 

 

 

이제 해당 스크립트를 측정하기 위해, 상단의 Run버튼을 클릭하여 스크립트를 실행합니다.

스크립트가 정상적으로 실행돼면 하단 Replay log에 Pass가 출력될 것 입니다.

 

 

 

이제 작성된 스크립트가 정상적으로 동작하는지 검증하는 단계 입니다.

사람이 직접 테스트를 진행할 때는, 육안으로 확인이 가능하지만, 로드런너 같은 툴을 사용할때는 로그와 같은 결과 값으로 검증할 수 있습니다.

사용자가 서버에 Request를 보내면 Response가 오는데요.

서버에서 오는 Response를 잡아서 해당 문자를 한가지 정해서 검증해 보도록 하겠습니다.

여기서는 네이버 홈페이지의 "회원가입"이란 문자를 검증하겠습니다.

 

 

 

상단메뉴 우측의 Run-time Settings를 클릭하여, Log를 선택하고 아래와 같이 설정합니다.

- Extendeed log: 데이터 검증용이므로 디버그 시에만 사용

- Parameter substitution: 수행 시, 적용되는 파라미터 값을 log에 출력

- Data returned by server: Server에서 Response되는 값을 log에 출력

 

 

 

설정을 완료한 후, 상단의 Run을 클릭하여 스크립트를 실행합니다.

스크립트 실행이 완료돼면 Replay Log를 클릭한 후, 검증할 단어를 찾습니다.

여기서는 "회원가입" 이란 단어를 검증할 문자로 선택해 보겠습니다.

회원가입 문자를 찾은 후, 해당 문자(Replay Log:회원가입)를 더블클릭 합니다.

그럼 본문의 web_url(www.naver.com, 로 자동으로 이동합니다.

 

 

 

이제, 검증할 문자인 "회원가입"을 web_url(www.naver.com, 앞에 커서를 클릭하여 입력합니다.

처음에 진행했던 Insert Start Transaction 부분과 비슷하지만, 여기서는 상단의 Insert > New Step > Service > Web_reg_find >회원가입 > OK 클릭 순서로 진행합니다.

- web_reg_find: 실제 결과 페이지가 사용자에게 보여졌는지를 확인하기 위해 사용되는 함수

 

  

 

그럼 본문에 web_reg_find("Text=회원가입", LAST); 문구가 입력됩니다.

 

 

 

이제 상단의 Run 버튼을 클릭하여 스크립트 실행이 완료된 후, 하단의 Replay Log를 선택하여 검증하고자 하는 문자가 체크 되었는지 web_reg_find를 입력하여 확인해 보면 됩니다.

첫번째 나오는 web_reg_find 함수는 테스트조건이 정상적으로 등록되었다는 표시이므로, 무시하면 됩니다.

 

 

 

두번째 나오는 web_reg_find 함수가 검증하기로 했던 문자입니다.

즉, web_reg_find successful for "Text=회원가입" (count=2) 라고 출력돼야 해당 문자가 정상적으로 검증된 것 입니다.

 

 

 

문자 검증 완료 후, 상단 메뉴에서 View > Test Results를 클릭하여 해당 테스트 결과를 확인할 수 있습니다.

드디어 1단계 스크립트 작성 단계가 끝났네요. ㅎㅎ

여기까지 오시느라 수고 많으셨습니다.

 

 

이제, 2단계인 시나리오 작성에 대해 시작하겠습니다. :D

 

시작 > Mecury LoadRunner > Applications > Controller 클릭하여 실행

New Scenario 에서 스크립트 선택하여 Add 한 후, OK버튼 클릭합니다.

 

 

 

OK버튼을 클릭하면, Scenario Schedule 페이지가 출력됩니다.

해당 페이지에서 시나리오 설정을 하면 됩니다.

 

 

 

제일 먼저, Running설정 부분입니다.

Vusers를 설정하면 돼는데요. 딱히 특별한건 없습니다.

AddVuser을 사용해서 Vuser을 늘리거나, Details을 사용해서  해당 스크립트를 변경 및 조회할 수 있습니다.

 

 

 

 

 

이제 Scheduler 설정하는 방법입니다.

Edit Schedule를 클릭하여 Schedule Builder을 불러낸 후, 아래와 같이 설정하면 되는데요.

우선, Slow Ramp Up 부분에 대해서 설정하겠습니다.

- Vuser를 2분마다 2명씩 유입시키는 내용

 

 

 

- Run until completion: Iteration 횟수만큼 진행

- Run for 10분 after the ramp up has been completed: 주어진 시간(10분)만큼 진행

- Run indefinitely: 무한정 진행

 

 

 

- Stop all Vusers simultaneously: 모든 Vuser을 일제히 정지

- Stop 5 Vusers every 30: Vuser를 30초마다 5명씩 정지

 

 

 

위에서 Slow Ramp Up 부분에 대해서 각각 설정했는데요.

Schedule Name 콤보박스에서 Ramp Up을 선택한 후, Slow Ramp Up와 같이 설정을 다시 한번 해줍니다.

물론, 설정은 약간 다른방식으로 아래처럼 해줘야 합니다.

-Ramp Up: Start 2 Vusers every 00:00:15

-Duration: Run for 000:05:00

-Ramp Down: Stop all Vusers simultaneously

 

 Scheduler을 사용하는 이유는 정해진 스케쥴에 따라 load가 입력되므로 결과분석 시, 결과 값을 추출하는 것이 용이하기 때문 입니다.

 

이번에는 Generators를 사용해서 부하발생기의 상태를 확인하도록 하겠습니다.

상태가 Ready가 아닌 경우에는 Connect해서 연결하면 되며, 반대로 사용하고 싶지 않은 경우에는 Disconnect 하면 됩니다.

드디어!! 2단계인 시나리오 작성까지 완료하였습니다. ㅎㅎ

 

 

 

 

마지막 3단계인 실행 및 결과분석!! 단계 입니다. :D

 

하단의 Run탭을 선택한 후, Start Scenario 버튼을 클릭하여 실행합니다.

 

 

 

그럼, 아래와 같이 Running 표시가 뜨는데요.

스크립트를 시나리오대로 정상적으로 진행하고 있다는 표시 입니다.

중간중간 돋보기를 클릭하여 해당 내용에 대해 확인해 볼 수도 있습니다.

그리고, 왼쪽의 Available Graphs의 항목을 더블클릭하면 해당 도표를 그래프로 중앙에서 상세하게 보여줍니다.

테스트가 완료돼면 자동으로 테스트가 종료됩니다. 물론, Stop버튼을 클릭하여 임의로 종료할 수도 있고요.

 

 

 

자, 이제 모든 테스트가 종료됐습니다.

But!! 결과를 분석할 줄 모른다면 테스트를 한 의미가 없겠죠?

 

지금부터 Analysis Tool을 사용해서 결과를 분석해 보도록 하겠습니다.

메뉴탭에서 Results > Analyze Results 클릭하면 저장된 결과 *.lra 파일을 자동 분석해서 아래와 같은 창이 하나 출력됩니다.

왼쪽의 메뉴가 분석한 항목들이며, 해당 항목을 클릭하면 중앙에 해당 항목의 그래프가 보여집니다.

 

 

 

 

Merge라는 기능으로 여러 그래프를 한번에 보여줄 수도 있습니다.

우선, 하나의 그래프를 클릭해서 연 다음에 해당 그래프 에서 마우스 우측 버튼을 클릭하여 Merge를 클릭하고, 추가하고자 하는 항목을 선택하면 됩니다.

 

 

 

 

 

필터링 기능을 통해 좀 더 자세하게 확인해 보고 싶은 구간을 필터링 해서 볼 수도 있습니다.

Set Global Filter > Scenario Elapsed Time > Set Range 설정 > OK 클릭

 

 

 

 

 

이제 테스트 된 결과에 대해 Reports 할 시간입니다.

LoadRunner Analysis는 친절하게도 일반PC에서도 볼 수 있도록 HTML or Word로 작성이 가능합니다.

해당 목록을 클릭하는 순간 자동으로 결과문서가 작성 완료되므로, 확인하시면 됩니다.

 

 

 

아, 드디어 LoadRunner 테스트가 완료됐습니다. ㅎㅎ

주요 기능에 대해 빼먹은 부분도 있고, 미흡한 부분도 있는데요.

나중에 좀 더 공부해서 추가하도록 하겠습니다. ㅎㅎ

 

XML과 인터넷 프로토콜을 통해 표준화된 방식으로 상호작용하기위한 소프트웨어 시스템을 말한다.

 

웹서비스는 SOAP, WSDL, UDDI 등의 표준기술로 이뤄진다.

따라서, 서로 다른 개발환경과 운영체제에서도 상호 통신을 가능하게 된다.

HTTP를 사용한다는 점에서 CORBA나 DCOM 보다 우위에 있다.

 

 

SOAP (Simple Object Access Protocol) :

XML과 HTTP등을 기본으로 하여 다른 컴퓨터에 있는 데이터나 서비스를 호출하기 위한 통신규약(Protocol)이다.

SOAP을 지원하는 서버가 대중화가 되면서 대부분의 SOAP 서버들을 웹에서 Access가 가능해졌으며 다양한 프로그램언어에서도 쉽게 실행할 수 있게 되었다

 

 

WSDL (Web Service Description Language) :

웹서비스에서 제공하는 기능들(서비스 오퍼레이션에 해당함)을 외부에서 이용할 수 있도록 그 사용방법을 알려주는 인터페이스 언어로 XML 기반으로 작성된다.

즉, 웹서비스 설명서이다.

 

 

WSDL 웹 서비스를 표현하고 기술하는 언어 (서비스 표현)
SOAP 웹 서비스에서 사용되는 보편적이며 확장성 있는 메시지 프로토콜 (데이터 통신 프로토콜)
UDDI 필요한 서비스를 찾을 수 있는 웹 서비스 레지스트리 (서비스 등록, 검색)

 

 

 

 

 

 

SOAP(Simple Object Access Protocol)

SOAP(Simple Object Access Protocol)은 HTTP, HTTPS, SMTP등을 사용하여 XML 기반의 메시지 를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜로써 웹 서비스(Web Service)의 기본적인 메시지 전송 수단 이며 XML-RPC와 WDDX에서 envelope/header/body로 이루어진 구조와 전송(transport)과 상호 중립성(interaction neutrality)의 개념을 도입하였다.
  • SOAP Message 구조
  • SOAP 메시지는 루트 엘리먼트로 Envelope를 가지며, SOAP Header와 Body를 하위 엘리먼트로 가지고 있다. SOAP의 메시지 구조는 XML을 근간으로 Header와 Body를 조합하는 디자인 패턴으로 설계되었고 Body는 필수사항으로 전송될 메시지의 내용을 기술(Header는 선택사항)한다.
  • SOAP 특징
  • 장점
    설명
    1 SOAP은 기본적으로 HTTP 기반 위에서 동작하기 때문에, HTTP와 같이 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능하다.
    2 SOAP는 표준 트랜스포트 프로토콜인 HTTP 이외의 다른 트랜스포트 프로토콜들을 사용할 수 있다.
    3 플랫폼 및 프로그래밍 언어에 독립적이다.
    4 간단하고 확장 가능하며, (멀티파트 MIME 구조를 사용하여) 첨부를 통합하는 SOAP XML 메시지를 지원한다.

    단점
    설명
    1 XML 포맷은 태그 형태로 보내기 때문에 CORBA 같은 미들웨어 기술과 비교해서 상대적으로 느리다. (최근 네트워크 속도의 비약적인 발전과 성능 최적화 기술의 발전으로 대부분 해결됨)

WSDL(Web Services Description Language)

WSDL(Web Services Description Language)이란, 웹 서비스(Web Services)가 제공하는 서비스에 대한 정보를 기술하기 위한 XML 기반의 마크업 언어이다.
즉, 원하는 서비스가 어디(Where)에 존재하며, 웹서비스로 무엇(What)을 할 수 있고, 또 이를 실행하기 위해서는 어떻게(How) 해야 하는가를 XML 형식으로 기술하여 제공하는 웹 서비스(Web Services) 기술 언어이다.
  • WSDL 문서 구조
  • definitions 태그를 루트 엘리먼트로 하여 추상적 정의(types/message/portType)와 구체적 정의(binding/service)로 나뉜다. 추상적 정의와 구체적 정의를 분리하여 기술함으로써, 서로 다른 서비스 구현에 대해 서비스의 추상적 정의를 재사용할 수 있다.

  • WSDL 문서 구조 상세
  • WSDL의 주요 기술 내용에는 웹 서비스의 이름과 URI 정보, SOAP 메시지의 인코딩 방법, SOAP 메시지 전송을 위한 프로토콜 정보, 웹 서비스를 이용하는데 필요한 인터페이스 정보가 있으며 문서 구조 로는 추상적 정의와 구체적 정의를 분리하여 기술함으로써, 서로 다른 서비스 구현에 대해 서비스의 추상적 정의를 재사용할 수 있다. WSDL의 구성요소는 아래와 같다.


    WSDL의 각각의 구성 요소에 대한 설명은 다음과 같다.
    요소
    설명
    <service> Endpoint(실제 웹 서비스로 구현된 어플리케이션)의 물리적 위치를 정의하고 각 바인딩에 대한 포트 주소를 기술한다.
    <port> binding 정보와 address location을 정의한다.(WSDL 2.0에서는 <endpoint>로 변경됨)
    <binding> portType과 네트워크 호출 프로토콜, 어떤 통신 프로토콜을 통해서 통신을 할 것인지를 정의한다.
    <portType> 인터페이스의 메소드들을 정의한다. Interface(WSDL 2.0에서 <interface>로 변경됨)
    <operation> 서비스의 함수에서 사용되는 요청(Request)/ 응답(Response) 메시지 정의
    <message> 서비스가 사용하는 메시지를 정의한다. 메소드의 인자와 리턴 값을 선언한다. (WSDL 2.0에서는 <types>를 통해 XML 스키마 타입을 사용하여 기술)
    <types> 문서에서 사용되고 있는 데이터 타입을 정의한다.

출처 : http://dev.anyframejava.org/anyframe/doc/core/3.1.0/corefw/guide/webservices.html

 

 

+ Recent posts