'분류 전체보기'에 해당되는 글 267건

2011.04.05 [SOAP강좌] Java 서버 - Delphi 클라이언트
2011.04.05 기본 XML Web Services - MSDN
2011.04.05 JAVA로 SOAP을 구현하려면?
2011.04.05 Soap이란?
2011.04.05 TCP/IP 7 layer 예시
2011.04.05 TCP/IP Seven Layer Model - http://networking.ringofsaturn.com
2011.04.05 OSI 7 Layer 완전분석

SOAP2011. 4. 5. 15:41

[SOAP강좌] Java 서버 - Delphi 클라이언트

▶ SOAP

SOAP(Simple Object Access Protocol)에 대한 설명은 다른 사이트에 잘 나와 있으니 찾아 보세요.
여기에서는 Java로 SOAP 서버를 만들고, Tomcat으로 Web 서비스 하여, 클라이언트는 Delphi로 만들어 보겠습니다.
이와 같은 예가 외국 사이트를 찾아 보아도 별로 없더군요. 그래서 허접한 설명이지만 도움이 될까 해서 올립니다.
(기회가 되면 배열이나, Dataset도 구현 하고 싶지만 시간이 없어서...)

일부 소스와 내용은 에어콘 출판사의 차세대 자바 SOAP AXUS을 참조 했습니다.

▶ 준비물

JDK 1.4.x 이상 (http://java.sun.com)
Tomcat 4.1.36 (http://tomcat.apache.org/)
AXIS 1.4 (http://ws.apache.org/axis/)
Delphi 7 (http://www.borland.com)

▶ SOAP Web 서비스 설치

여기에서 JDK, Tomcat의 설치는 따로 하지 않겠습니다. 이것도 다른 사이트를 참조하세요.

1. axis-bin-1_4.zip 압축 풀기

Apache에서 받은 axis-bin-1_4.zip을 압축을 특정 폴더에 풀어 주세요. 저는 C:\SOAP\axis-1_4 에 풀었습니다.
앞으로 설명은 C:\SOAP\axis-1_4 으로 하겠습니다.

2. %tomcat_home%\conf\server.xml

아래 내용을 추가해서 AXIS 가상 경로를 추가 Tomcat을 다시 실행 시켜주세요.

<Context path="/axis" docBase="C:\SOAP\axis-1_4\webapps\axis" debug="0"
reloadable="true" crossContext="true">
</Context>

▶ Java로 SOAP 서버 만들기

아래와 내용과 같이 HelloWorld.java을 만들고, 이 파일을 C:\SOAP\axis-1_4\webapps\axis 디렉토리에 확장자가 .jws로 수정 HelloWorld.jws을 C:\SOAP\axis-1_4\webapps\axis 복사해주세요.

HelloWorld.java 파일

public class HelloWorld {

public HelloWorld() {
}

public String getHelloWorldMessage(String name) {
return "Hello World to " + name;
}
}

확인하기

지금까지 잘 하셨다면 브라우저에서 http://localhost:8080/axis/HelloWorld.jws 주소로 보시면 아래와 같이 나올 것입니다.

▶ WSDL 파일 만들기

SOAP의 WSDL 파일이 어떤 일을 하는지도 다른 사이트에 자세히 나와 있으니 이것도 다른 사이트에서 찾아보세요.
여기에서는 WSDL 파일을 AXIS을 이용해서 만들고, Delphi로 사용하는 방법만 설명하겠습니다.

브라우저에서 http://localhost:8080/axis/HelloWorld.jws 페이지를 열어서 Click to see the WSDL을 선택하시면 아래와 같이 나올 것입니다.

이 내용을 복사해서 메모장에 붙여 넣은 후 HelloWorld.wsdl로 저장합니다.

▶ Delphi 로 Client 만들기

1. 새로운 프로젝트을 만들어 주세요.

2 File > New > Other... 선택 WebServices 창에서 WSDL Importer 아이콘을 더블 클릭

3. HelloWorld.wsdl 선택하고, [Next] 버튼 선택

4. [Finish] 버튼 선택

지금까지 하셨으면 HelloWorld1.pas 파일이 만들어 졌을 것입니다.

5. Unit1.pas을 열어서 Button 과 Edit Box을 추가 해주세요

6. Unit1.pas 아래와 같이 코딩 해주세요. 추가된 코드는 파란색으로 표시 해두었습니다.

unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, HelloWorld1;

type
TForm1 = class(TForm)
Button1: TButton;
Edit1: TEdit;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
FHelloWorld : HelloWorld;
public
{ Public declarations }
function GetHelloWorldService(): HelloWorld;
end;

var
Form1: TForm1;

implementation

{$R *.dfm}

function TForm1.GetHelloWorldService(): HelloWorld;
begin
if FHelloWorld = nil then begin
FHelloWorld := GetHelloWorld();
end;
Result := FHelloWorld;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
Edit1.Text := GetHelloWorld().getHelloWorldMessage('AXIS');
end;

end.

▶ 실행 결과

- 출처 : http://bluexmas.tistory.com/20 크리스

'SOAP' 카테고리의 다른 글

JAVA로 SOAP 구축하기(2) (0)	2011.04.05
JAVA로 SOAP 구축하기(1) (0)	2011.04.05
기본 XML Web Services - MSDN (0)	2011.04.05
JAVA로 SOAP을 구현하려면? (0)	2011.04.05
Soap이란? (0)	2011.04.05

Posted by 아로나

SOAP2011. 4. 5. 15:34

기본 XML Web Services - MSDN

기본 XML Web Services

Roger Wolter

Microsoft Corporation

요약 : 이 기사는 SOAP, WSDL, UDDI 소개 및 개발자용 XML Web services 값의 개요를 설명합니다(6페이지/인쇄 페이지 기준).

XML Web Service

XML Web services는 인터넷상에서 분산된 컴퓨팅으로 이동하는 데 기본이 되는 빌딩 블록입니다. 열린 표준과 통신 중심, 작업자 및 응용 프로그램간의 공동 작업으로 응용 프로그램을 통합하는 데 XML Web services가 플랫폼이 되는 환경을 만들었습니다. 응용 프로그램은 위치나 구현 방법과 상관없이 함께 작동하는 다양한 소스의 여러 XML Web services를 사용하여 구성됩니다.

XML Web Service를 만드는 회사가 많은 만큼 XML Web Service의 정의도 다양하겠지만 모든 정의에는 다음과 같은 공통점이 있습니다.

XML Web Services는 표준 웹 프로토콜을 통해 웹 사용자들에게 유용한 기능을 표시합니다. 대부분의 경우 SOAP 프로토콜이 사용됩니다.
XML Web services는 사용자와 대화할 수 있는 클라이언트 응용 프로그램을 만들 수 있는 인터페이스를 세부적으로 설명하는 방법을 제공합니다. 일반적으로 이 설명은 Web Services 설명 언어(WSDL) 문서라고 하는 XML 문서에 제공됩니다.
XML Web services는 잠재적인 사용자가 XML Web services를 쉽게 찾을 수 있도록 등록됩니다. XML Web services는 UDDI(Universal Discovery Description and Integration)에 등록됩니다.

본 기사에서 위의 세가지 기술을 모두 설명하겠지만 XML Web services에 주의를 기울여야 하는 이유를 먼저 설명하겠습니다.

XML Web services 아키텍처의 주요 장점 중 하나는 별도의 플랫폼에 별도의 언어로 작성된 프로그램들이 표준 기반으로 서로 통신할 수 있다는 점입니다. 이 점에 대해 산업 분야에 종사했던 사람들은 DEC 이전과 CORBA에서도 같은 내용이 있었기 때문에 차이점이 없을 것 같다는 의문이 생길 수 있습니다. 첫 번째 차이점은 SOAP가 이전의 접근 방법보다 훨씬 간단하여 표준 규격의 SOAP 구현을 입력하는 작업이 더욱 용이하다는 것입니다. Paul Kulchenko는 79항목이 포함된 마지막 카운트인 http://www.soapware.org/directory/4/implementations 에서 SOAP 구현 목록을 유지 관리합니다. SOAP 구현은 규모가 큰 소프트웨어 회사에서 찾을 수 있지만 개인 개발자가 작성하고 유지 관리하는 구현도 많이 찾을 수 있습니다. 이전에 비해 XML Web services가 갖는 또 다른 큰 장점은 표준 웹 프로토콜인 XML, HTTP 및 TCP/IP와 작동한다는 것입니다. 수 많은 회사들이 웹 인프라와 이를 유지 관리하는 지식과 경험이 있는 직원들을 갖추었기 때문에 XML Web services에 대한 항목에 소모되는 비용이 이전 기술에 비해 현저히 감소됩니다.

지금까지 WSDL 파일에 설명되고 UDDI에 등록된 XML Web service를 SOAP를 통해 웹에 나타나는 소프트웨어 서비스로 정의했습니다. 그 다음 논리적인 질문은 XML Web services로 무엇을 할 수 있는가 하는 것입니다. 처음에 XML Web services는 주식 시세, 일기 예보, 스포츠 등 응용 프로그램에 쉽게 통합될 수 있는 정보원이었습니다. 원하는 정보를 분석하고 집계하여 다양한 방법으로 표시하도록 작성할 수 있는 응용 프로그램이 있습니다. 예를 들어, Microsoft® Excel 스프레드시트를 사용하여 주식, 401K, 은행 계좌, 대출 등의 전체 금융 상태를 요약할 수 있습니다. 이 정보를 XML Web services에서 사용할 수 있는 경우 Excel은 이 Web services를 계속 업데이트합니다. 이 정보 중 일부는 무료이며 어떤 정보는 서비스 구독이 필요할 수도 있습니다. 대부분의 정보는 웹에서 현재 사용할 수 있지만 XML Web services는 더욱 쉽고 안정적인 프로그래밍 방식으로 액세스됩니다.

기존 응용 프로그램을 XML Web services로 나타내면 XML Web services를 빌딩 블록으로 사용하는 더욱 강력한 새 응용 프로그램을 작성할 수 있습니다. 예를 들어, 여러 공급업체의 가격 정보를 자동으로 얻을 수 있고 공급업체를 선택할 수 있으며 주문한 다음 제품이 도착할 때까지 배달 과정을 확인할 수 있습니다. 공급업체 응용 프로그램은 웹상에 서비스를 표시한 다음 XML Web services를 사용하여 고객의 신용 확인, 요금 부과 및 배달 회사에 배달을 의뢰할 수도 있습니다.

앞으로 몇몇 중요한 XML 웹 서비스를 사용하면 웹을 사용하는 응용 프로그램을 지원하여 오늘날에는 실행하지 못하는 사항들을 실행할 수 있게 될 것입니다. 예를 들어, 일정 관리 서비스는 Microsoft .NET My Services 프로젝트가 지원하는 서비스 중 하나입니다. 치과 의사나 정비사가 XML Web service를 사용하여 일정을 관리하는 경우 고객이 온라인으로 시간 약속을 예약하거나, 고객이 원할 경우 치과 의사나 정비사가 직접 고객과 청소 및 정기 점검 약속을 할 수 있습니다.조금만 생각해 보면, 웹을 프로그램할 수 있는 능력이 있기만 하면 작성할 수 있는 응용 프로그램이 많이 있습니다.

XML Web services 및 응용 프로그램 작성에 대한 더 자세한 내용은 MSDN Web services 홈 페이지를 참조하십시오.

페이지 맨 위로

SOAP

SOAP는 XML Web services용 통신 프로토콜입니다. SOAP를 통신 프로토콜로 설명하면 대부분의 사람들은 DCOM 또는 CORBA를 생각하고 "SOAP가 객체를 활성화하는 방법은 " 또는 "SOAP가 사용하는 이름 서비스는 " 등과 같은 질문을 합니다. SOAP 구현에 이러한 내용이 포함되기는 하지만 SOAP 표준은 이 내용을 지정하지 않습니다. SOAP는 메시지 즉, 요청된 사양의 일부에 대한 XML 형식을 정의하는 사양입니다. 몇몇 SOAP 요소에 포함된 올바른 형식의 XML 조각이 있는 경우 SOAP 메시지가 나타납니다. 간단합니다.

SOAP 사양의 다른 부분은 프로그램 데이터를 XML로 표시하고 SOAP를 사용하여 원격 프로시저 호출을 수행하는 방법을 설명합니다. 이러한 사양의 선택적 부품은 클라이언트에서 전송되는 SOAP 메시지에 호출 가능한 함수와 해당 함수에 전달되는 매개 변수가 포함되어 있는 RPC 스타일 응용 프로그램을 구현하는 데 사용되며 서버는 실행된 함수의 결과와 함께 메시지를 반환합니다. COM 또는 CORBA 응용 프로그램을 실행하는 프로그래머들은 RPC 스타일을 이해하기 때문에 현재 대부분의 SOAP 구현은 RPC 응용 프로그램을 지원합니다. 또한 SOAP는 SOAP 메시지가 XML 문서에서 래퍼 기능만 수행하는 문서 스타일 응용 프로그램도 지원합니다. 문서 스타일 SOAP 응용 프로그램은 매우 융통성이 있으며 여러 새 XML Web services는 이 장점을 활용하여 RPC를 사용하여 구현하기 어려운 서비스를 만듭니다.

SOAP 사양의 마지막 선택 부분은 SOAP 메시지를 포함한 HTTP 메시지의 형식을 정의합니다. HTTP 바인딩은 HTTP가 거의 모든 현재 OS 및 현재가 아닌 여러 OS에 의해 지원되기 때문에 중요합니다. HTTP 바인딩은 선택 사항이지만 SOAP에 대해 유일하게 표준화된 프로토콜이기 때문에 거의 모든 SOAP 구현은 HTTP 바인딩을 지원합니다. 이러한 이유로 인해 SOAP에 HTTP가 필요한 것으로 잘못 생각하는 경우가 있습니다. 몇몇 구현은 MSMQ, MQ 시리즈, SMTP 또는 TCP/IP 전송을 지원하지만 거의 모든 현재 XML Web services는 흔히 사용되는 HTTP를 사용합니다. HTTP는 핵심 웹 프로토콜이므로 대부분의 회사는 HTTP를 지원하는 네트워크 인프라와 이를 관리하는 인력을 갖추고 있습니다. 보안, 모니터링 및 HTTP에 대한 로드 균형 인프라는 오늘날 쉽게 사용할 수 있습니다.

SOAP를 시작할 때 혼동되는 주요 원인은 SOAP 사양과 여러 SOAP 사양 구현간의 차이점입니다. SOAP를 사용하는 대부분의 사람들은 SOAP 메시지를 직접 작성하지는 않지만 SOAP 도구 키트를 사용하여 SOAP 메시지를 만들고 구문 분석합니다. 일반적으로 이러한 도구 키트는 함수 호출을 몇몇 종류의 언어에서 SOAP 메시지로 변환합니다. 예를 들어, Microsoft SOAP Toolkit 2.0은 COM 함수 호출을 SOAP로 전환하고 Apache Toolkit는 JAVA 함수 호출을 SOAP로 변환합니다. 함수 호출의 유형과 지원되는 매개 변수의 데이터 유형은 각 SOAP 구현에 따라 다양하기 때문에 한 개의 도구 키트와 함께 작동하는 함수는 다른 도구 키트와 작동하지 않을 수도 있습니다. 이것은 SOAP의 제한 사항이 아니라 사용자가 사용하는 특정 구현입니다.

훨씬 강제적인 SOAP의 기능은 많은 별도의 하드웨어 및 소프트웨어 플랫폼에 구현되었다는 점입니다. 이것은 사용자의 회사 내부, 외부의 서로 다른 시스템을 연결하는 데 SOAP를 사용할 수 있다는 의미입니다. 과거에 시스템을 통합하는 일반 통신 프로토콜을 개발하려는 노력은 많았지만 아무도 SOAP를 일반적으로 채택하지는 않았습니다. 왜냐하면, SOAP는 이전의 많은 프로토콜에 비해 구현하는 데 훨씬 작고 단순했기 때문입니다. 예를 들어, DCE 및 CORBA는 구현하는 데 수 년이 걸렸기 때문에 소수의 구현만이 출시되었습니다. 그러나 SOAP는 기존의 XML 파서 및 HTTP 라이브러리를 사용하여 대부분의 힘든 작업을 수행하므로 수 개월 내에 SOAP 구현을 완료할 수 있습니다. 따라서 70종류의 SOAP 구현을 사용할 수 있습니다. SOAP는 DCE 또는 CORBA가 수행하는 작업을 모두 수행하지는 않지만 기능 교환이 복잡하지 않기 때문에 SOAP를 쉽게 사용할 수 있습니다.

HTTP의 보편성와 SOAP의 간소성이 동시에 존재하면 거의 모든 환경에서 호출할 수 있는 XML Web services를 구현하는 데 있어 이상적인 기반이 됩니다. SOAP에 대한 더 자세한 내용은 MSDN SOAP 홈 페이지를 참조하십시오.

보안

SOAP를 처음 사용하는 사람들의 첫 번째 질문 중 하나는 SOAP가 보안을 다루는 방법입니다. SOAP 개발 초기에는 SOAP가 HTTP 기반 프로토콜로 표시되어 HTTP 보안이 SOAP에 충분했습니다. 오늘날 수 많은 웹 응용 프로그램이 HTTP 보안을 사용하여 실행되므로 HTTP 보안은 SOAP에 충분합니다. 따라서 현재 SOAP 표준은 보안 문제보다는 전송 문제를 다룹니다.

SOAP가 여러 전송 작업에서 제대로 실행되는 보다 일반적인 용도의 프로토콜로 확장되면 보안은 더욱 큰 문제가 됩니다. 예를 들어, HTTP는 SOAP를 호출하는 사용자를 인증하는 몇 가지 방법을 제공하지만 메시지가 HTTP에서 SMTP로 전송될 때 해당 ID의 전파 방법에 대한 문제가 발생합니다. 다행히 SOAP는 빌딩 블록 프로토콜로 디자인되었기 때문에 SOAP를 작성하는 작업에 이미 사양이 포함되어 Web services에 대한 추가 보안 기능을 제공합니다. WS-Security specification 은 전체 암호화 시스템을 정의하고 WS-License specification은 호출자의 ID와 권한이 부여된 사용자만 Web service를 사용할 수 있도록 하는 기술을 정의합니다.

페이지 맨 위로

WSDL

whiz-dull이라고도 하는 WSDL는 Web Services Description Language의 약어입니다. 편의상, WSDL 파일을 SOAP 메시지 집합 및 해당 메시지가 교환되는 방법을 설명하는 XML 문서라고 할 수 있습니다. 다시 말해서 WSDL은 IDL이 CORBA 또는 COM인 SOAP입니다. WSDL은 XML이기 때문에 읽을 수 있고 편집할 수 있지만 대부분의 경우에는 소프트웨어에 의해 작성되고 사용됩니다.

WSDL의 값을 보려면 비즈니스 파트너가 제공하는 SOAP 메서드를 호출해야 합니다. 비즈니스 파트너에게 몇몇 예제 SOAP 메시지를 요청하고 해당 예제와 같은 메시지를 작성하고 사용하는 응용 프로그램을 작성할 수 있으나, 오류가 발생하기 쉽습니다. 예를 들어, 고객 ID가 2387인 경우 메시지가 문자열이면 ID는 정수입니다. WSDL은 요청 메시지에 포함되는 사항과 응답 메시지의 형식을 명백한 노테이션으로 지정합니다.

WSDL 파일이 메시지 형식을 설명하기 위해 사용하는 노테이션은 XML 스키마 표준을 기반으로 하며, 이것은 프로그래밍 언어 중립적이며 또한 표준 기반이어서 다양한 플랫폼과 프로그래밍 언어에서 액세스할 수 있는 XML Web services 인터페이스를 설명하기에 적합하다는 것을 의미합니다. WSDL은 메시지 컨텐트를 설명할 뿐만 아니라 서비스를 사용할 수 있는 위치 및 서비스와 대화하는 데 사용되는 통신 프로토콜을 정의합니다. 즉, WSDL 파일은 XML Web service와 함께 작동하는 프로그램을 쓰는 데 필요한 모든 사항을 정의합니다. WSDL 파일을 읽고 XML Web service와 통신하는 데 필요한 코드를 생성할 수 있는 몇 가지 도구가 있습니다. 그 중에서 성능이 뛰어난 몇몇 도구들이 Microsoft Visual Studio® .NET에 있습니다.

많은 현재 SOAP 도구 키트에는 기존 프로그램 인터페이스에서 WSDL 파일을 생성하는 도구가 포함되지만 WSDL을 직접 작성하는 도구는 거의 없으며 WSDL에 대해 필요한 만큼 도구가 지원되지 않습니다. WSDL 파일 작성자에게 도구가 지원되어 COM IDL과 같은 프록시 및 스텁을 작성하는 것은 대부분의 SOAP 구현의 일부분이 됩니다. 이런 점에서 WSDL은 XML Web services에 대한 SOAP 인터페이스를 만드는 데 좋은 방법입니다.

http://www.w3.org/TR/wsdl 에서 WSDL 사양을 볼 수 있으며 우수한 description of WSDL 을 사용할 수 있습니다.

페이지 맨 위로

UDDI

UDDI(Universal Discovery Description 및 Integration)는 Web services의 옐로 페이지입니다. 전통적인 옐로 페이지에서는 필요한 서비스를 제공하는 회사를 찾아 제공된 서비스를 검토한 후에 담당자와 연락하여 자세한 정보를 구할 수 있습니다. 지하실에서 비즈니스를 시작하고 말로 광고를 할 수 있는 것처럼 UDDI에 등록하지 않고도 Web service를 제공할 수는 있습니다. 그러나 시장을 넓히기 위해서는 고객이 Web services를 찾을 수 있도록 UDDI에 등록해야 합니다.

UDDI 디렉터리 항목은 비즈니스 및 제공되는 서비스를 설명하는 XML 파일입니다. UDDI 디렉터리의 항목은 세 부분으로 되어 있습니다. "화이트 페이지"는 서비스를 제공하는 회사의 이름, 주소, 연락처 등을 설명합니다. "옐로 페이지"에는 북미 산업 분류 시스템 및 표준 산업 분류 등과 같은 표준 분류법을 기반으로 하는 산업 범주가 나와 있습니다. "그린 페이지"는 Web service를 사용하는 응용 프로그램을 작성할 수 있도록 서비스에 인터페이스를 세부적으로 설명합니다. 서비스 방법은 유형 모델 또는 tModel이라고도 하는 UDDI 문서를 통해 정의됩니다. 많은 경우에, tModel에는 XML Web service에 SOAP 인터페이스를 설명하는 WSDL 파일이 포함되어 있지만 tModel은 융통성이 있어 거의 모든 종류의 서비스를 설명할 수 있습니다.

또한 UDDI 디렉터리에는 사용자의 응용 프로그램을 작성하는 데 필요한 서비스를 검색하는 몇 가지 방법이 있습니다. 예를 들어, 지정된 지역 및 지정된 유형의 비즈니스로 서비스 공급자를 검색할 수 있습니다. 그런 다음 UDDI 디렉터리는 정보, 연락처, 링크 및 기술적인 데이터를 공급하여 사용자의 요구 사항에 맞는 서비스를 평가할 수 있도록 합니다.

UDDI를 사용하여 Web services를 얻을 수 있는 비즈니스를 찾을 수 있습니다. 비즈니스 파트너는 알고 있지만 제공되는 서비스가 무엇인지 모를 경우에는 WS-Inspection specification 을 사용하여 특정 서버에 제공된 XML Web services의 컬렉션을 검색하여 필요한 서비스를 찾을 수 있습니다.

UDDI에 대한 더 자세한 내용은 http://www.uddi.org/about.html 를 참조하십시오.

페이지 맨 위로

기타

지금까지 XML Web services와의 대화 방법(SOAP), XML Web services 설명 방법(WSDL) 및 XML Web services 찾는 방법(UDDI)에 대해 설명했습니다. 이러한 사항들은 응용 프로그램 통계 및 집계에 대한 기초를 제공하는 기준 사양 집합을 구성합니다. 회사는 기준 사양을 이용하여 실제 솔루션을 구축하고 실제 값을 얻습니다.

실제 XML Web services를 만드는 데 많은 노력을 해왔지만 앞으로 더욱 많은 노력이 필요합니다. 오늘날 XML Web services를 성공적으로 작성하고는 있지만 보안, 운영 관리, 트랜잭션, 안정된 메시징과 같이 개발자가 개발해야 할 사항들이 여전히 남아 있습니다. 전역 XML Web Services 아키텍처는 모듈화 및 확장 가능한 XML Web services에 새 고급 기능을 추가하는 데 정확한 다용도 모델을 제공하여 XML Web services를 다음 단계로 이동할 수 있도록 도와줍니다.

위에서 언급한 보안 모듈(WS-Security 및 WS-License) 은 전역 Web Services 아키텍처의 사양 중 일부입니다. 운영 관리를 프로세싱하려면 여러 서버 간에 메시지를 라우팅하고 해당 서버를 동적으로 구성해야 하는데 이러한 작업도 전역 Web Services 아키텍처의 일부이며 WS-Routing specification 및 WS-Referral specification과 일치합니다. 전역 Web Services 아키텍처가 발전함에 따라 해당 사양 및 기타 필요 사항이 소개됩니다.

더 자세한 내용은 Global XML Web Services Architecture 를 참조하십시오.

최종 수정일: 2002년 2월 6일

- 출처 : http://msdn.microsoft.com/ko-kr/library/ms996507.aspx -

'SOAP' 카테고리의 다른 글

JAVA로 SOAP 구축하기(2) (0)	2011.04.05
JAVA로 SOAP 구축하기(1) (0)	2011.04.05
[SOAP강좌] Java 서버 - Delphi 클라이언트 (0)	2011.04.05
JAVA로 SOAP을 구현하려면? (0)	2011.04.05
Soap이란? (0)	2011.04.05

Posted by 아로나

SOAP2011. 4. 5. 15:29

JAVA로 SOAP을 구현하려면?

Tip: SOAP attachments와 JAX-RPC

난이도 : 중급

Russell Butek, 소프트웨어 엔지니어, IBM

2004 년 2 월 27 일

JAX-RPC는 SOAP with attachments를 지원한다. JAX-RPC API를 사용하여 MIME attachments를 보내는 방법을 이 글에서 설명한다.

SOAP 메시징 프로토콜은 SOAP 메시지들을 통해 MIME attachments를 보낼 수 있도록 한다. WSDL은 이 attachment의 디스크립션을 제공한다. JAX-RPC는 attachment의 WSDL 디스크립션을 자바로 매핑한다. 이 글에서 JAX-RPC 매핑을 사용하여 SOAP 메시지에서 attachment를 보내는 방법을 설명한다.

WSDL

attachment의 WSDL 디스크립션은 그다지 단순하지가 않다. Listing 1의 WSDL을 보자.

Listing 1. WSDL with attachments

<?xml version="1.0" encoding="utf-8"?>
<definitions
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
    targetNamespace="urn:attachment.tip"
    xmlns:tns="urn:attachment.tip">
  <message name="empty"/>
  <message name="imageMsg">
    <part name="image" type="xsd:hexBinary"/>
  </message>
  <message name="octetMsg">
    <part name="octet" type="xsd:hexBinary"/>
  </message>

  <portType name="AttachmentTip">
    <operation name="sendImage">
      <input message="tns:imageMsg"/>
      <output message="tns:empty"/>
    </operation>
    <operation name="sendOctet">
      <input message="tns:octetMsg"/>
      <output message="tns:empty"/>
    </operation>
  </portType>

  <binding name="AttachmentBinding" type="tns:AttachmentTip">
    <soap:binding style="rpc"
                  transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="sendImage">
      <soap:operation soapAction=""/>
      <input>
        <mime:multipartRelated>
          <mime:part>
            <soap:body use="literal"/>
          </mime:part>
          <mime:part>
            <mime:content part="image" type="image/jpeg"/>
          </mime:part>
        </mime:multipartRelated>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
    <operation name="sendOctet">
      <soap:operation soapAction=""/>
      <input>
        <mime:multipartRelated>
          <mime:part>
            <soap:body use="literal"/>
          </mime:part>
          <mime:part>
            <mime:content part="octet" type="application/octet-stream"/>
          </mime:part>
        </mime:multipartRelated>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>

  <service name="AttachmentService">
    <port name="AttachmentTip" binding="tns:AttachmentBinding">
      <soap:address
          location="http://localhost:9080/attachment/services/AttachmentTip"/>
    </port>
  </service>

</definitions>

WS-I와 attachments

MIME 유형은 WSDL의 '인터페이스'로 정의될 수 없다. WS-I organization (참고자료)은 모든 MIME 유형을 위한 새로운 XML 유형을 도입하여 부분적이라도 이러한 단점을 보완을 시도하고 있다: wsi:swaRef. 이 글을 쓰는 당시에는 이 유형은 작업중에 있었으며 표준화된 자바 바인딩이 존재하지 않았음을 밝힌다.

우선 기억해야 할 것은 항상 바인딩에 대처하기 전까지는 어떤 MIME 정보도 없다는 것이다. 한 순간이라도 바인딩을 무시하고 WSDL의 '인터페이스'(portType과 메시지)만을 본다면 두 개의 오퍼레이션인 sendImage와 sendOctet를 보게 될 것이다. 이들 각각은 hexBinary 인풋을 갖고 있다. hexBinary는 byte[]로 매핑한다. 단지 이 정보만을 이용하여 이 portType이 Java language Service Endpoint Interface (SEI)로 매핑되는 것을 짐직할 수 있다. 이것은 두 개의 메소드를 갖고 있는데 각각 하나의 byte[] 매개변수를 갖고있다. 이는 MIME 유형을 제외한 모든 것에 알맞은 생각이다. 하지만 MIME 유형의 경우 실제 매개변수 유형을 결정하려면 바인딩을 살펴보아야한다.

바인딩에서 오퍼레이션용 인풋이 실제로 MIME 콘텐트 유형인 image/jpeg와 application/octet-stream이라는 것을 알 수 있다. hexBinary가 아니다. JAX-RPC는 이들을 java.awt.Image와 javax.activation.DataHandler에 매핑하도록 정의한다.

위로

Service Endpoint Interface

Listing 2에는 Listing 1의 WSDL에서 만들어진 Java language SEI가 포함되어 있다.

Listing 2. AttachmentTip SEI

package tip.attachment;

import java.awt.Image;
import java.rmi.Remote;
import java.rmi.RemoteException;
import javax.activation.DataHandler;

public interface AttachmentTip extends Remote {
    public void sendImage(Image image) throws RemoteException;
    public void sendOctet(DataHandler octet) throws RemoteException;
}

WSDL의 sendImage 오퍼페이션은 java.awt.Image 매개변수를 이용하여 자바 프로그램 메소드가 된다. 매우 단순하고 깔끔하다. 표 1은 MIME 유형을 자바 유형으로 매핑한 리스트이다.

표 1 - JAX-RPC 매핑

MIME Type	Java Type
image/gif, image/jpeg	java.awt.Image
text/plain	java.lang.String
multipart/*	javax.mail.internet.MimeMultipart
text/xml, application/xml	javax.xml.transform.Source

위로

클라이언트 구현

JAX-RPC 구현을 사용하여 AttachmentTip WSDL에서 모든 클라이언트 쪽 매핑을 만든다고 가정한다. 클라이언트 구현은 이 매핑에 의존할 것이고 특히 Listing 2의 AttachmentTip SEI를 의존한다.

attachments의 클라이언트 구현은 우선 Service에서 SEI의 구현을 얻는 것으로 시작한다.(Listing 3).

sendImage 메소드 호출하기

SEI 구현을 갖게 되면 attachment로 이 메소드를 호출할 수 있다. sendImage의 경우, 이 attachment는 java.awt.Image 이다. 이 뿐이다. JAX-RPC 구현은 모든 이미지가 attachment로서 보내지는 것을 알고 있고 이에 따라 SOAP 메시지를 만든다. 클라이언트 프로그래머는 attachment가 개입되었는지를 알 필요가 없다. (Listing 3).



Listing 3. AttachmentTip 클라이언트 구현과 sendImage 호출





package tip.attachment;

import java.awt.Image;
import java.awt.Toolkit;

import java.net.URL;

import java.rmi.RemoteException;

import javax.xml.namespace.QName;

import javax.xml.rpc.Service;
import javax.xml.rpc.ServiceFactory;

public class AttachmentTipClient {

    static AttachmentTip getTip() throws Exception {
        QName serviceName = new QName(
                "urn:attachment.tip",
                "AttachmentService");
        URL wsdlLocation = new URL(
                "http://localhost:9080/attachment/services/AttachmentTip?wsdl");
        ServiceFactory factory = ServiceFactory.newInstance();
        Service service = factory.createService(wsdlLocation, serviceName);
        QName portName = new QName("", "AttachmentTip");
        return (AttachmentTip) service.getPort(
                portName,
                AttachmentTip.class);
    }

    static void sendImage(AttachmentTip tip, String fileName)
            throws RemoteException {
        Toolkit toolkit = Toolkit.getDefaultToolkit();
        Image image = toolkit.createImage(fileName);
        tip.sendImage(image);
    }

    public static void main(String[] args) {
        try {
            AttachmentTip tip = getTip();
            sendImage(tip, args[0]);
        }
        catch (Throwable t) {
            t.printStackTrace();
        }
    }
}



sendOctet 메소드 호출하기









비 지정 MIME 유형을 매핑할 때 유의할 점




JAX-RPC는 표 1에 나타나지 않은 MIME 유형을 지원하는 구현을 필요로하지 않는다. 구현은 비 지정 MIME 유형을 DataHandler로 매핑하지 않을 수도 있다. 예를 들어, WebSphere 웹 서비스는 Application Server 6.0 버전이 나오기 전까지는 이 매핑을 지원하지 않는다.
JAX-RPC가 매핑을 정의한 몇 가지 MIME 유형이 있다는 것은 다행이다. (표 1 참조). For those MIME types for which there is no explicit 뚜렷한 JAX-RPC 매핑이 없는 MIME 유형의 경우 javax.activation.DataHandler 객체와 함께 남아있다. 이 클래스는 Java Activation Framework (JAF -- 참고자료)의 일부이다. 따라서 JAF에 대해 알아야한다. 그다지 어렵지 않다. DataHandler에는 javax.activation.DataSource가 포함되어 있고 인풋과 아웃풋 스트림이 포함되어 있다. 대부분의 자바 프로그래밍 유형은 이 스트림에서 매우 쉽게 변환된다. 게다가 활성화 프레임웍도 도움이 된다. attachment 데이터가 파일에 있으면 활성화 프레이웍은 javax.activation.FileDataSource 클래스를 제공하고 따라서 스트림 단계를 우회할 수 있다.(Listing 4) .


Listing 4. 완전한 AttachmentTip 클라이언트 구현





package tip.attachment;

import java.awt.Image;
import java.awt.Toolkit;

import java.net.URL;

import java.rmi.RemoteException;

import javax.activation.DataHandler;
import javax.activation.FileDataSource;

import javax.xml.namespace.QName;

import javax.xml.rpc.Service;
import javax.xml.rpc.ServiceFactory;

public class AttachmentTipClient {

    static AttachmentTip getTip() throws Exception {
        QName serviceName = new QName(
                "urn:attachment.tip",
                "AttachmentService");
        URL wsdlLocation = new URL(
                "http://localhost:9080/attachment/services/AttachmentTip?wsdl");
        ServiceFactory factory = ServiceFactory.newInstance();
        Service service = factory.createService(wsdlLocation, serviceName);
        QName portName = new QName("", "AttachmentTip");
        return (AttachmentTip) service.getPort(
                portName,
                AttachmentTip.class);
    }

    static void sendImage(AttachmentTip tip, String fileName)
            throws RemoteException {
        Toolkit toolkit = Toolkit.getDefaultToolkit();
        Image image = toolkit.createImage(fileName);
        tip.sendImage(image);
    }

    static void sendOctet(AttachmentTip tip, String fileName)
            throws RemoteException {
        FileDataSource fds = new FileDataSource(fileName);
        DataHandler dh = new DataHandler(fds);
        tip.sendOctet(dh);
    }

    public static void main(String[] args) {
        try {
            AttachmentTip tip = getTip();
            sendImage(tip, args[0]);
            sendOctet(tip, args[0]);
        }
        catch (Throwable t) {
            t.printStackTrace();
        }
    }
}



두 개의 attachment 작동에 대한 데이터로 같은 파일을 사용했지만 어디까지나 이것은 sendOctet에 한해서였다는 것을 기억하라. 이를 고려하지 않는다면 상상에 맡기겠다. application/octet-stream은 FileDataSource용 디폴트 콘텐트 유형이다. 이것이 바로 내가 이를 사용한 이유이다. 파일에 데이터를 갖고 있지 않다면 application/octet-stream 말고 다른 것으로 보내야한다. DataSource의 구현을 만들어야 하지만 이는 간단한 인터페이스이기 때문에 많은 노력이 필요하지는 않다.



















위로




참고자료

developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.



zip 파일 다운로드.



Tip: Send and receive SOAP messages with JAX-RPC (developerWorks, September 2003).



tip (developerWorks, February 2004).



Web Services Description Language (WSDL) 1.1.



IBM WebSphere Application Server Technology for Developers, version 6.0.



Java API for XML-Based RPC (JAX-RPC) Downloads & Specifications.



WS-I (Web Services Interoperability).



Java Activation Framework.




















위로




필자소개








Russell Butek: IBM WebSphere Web services engine 개발자. IBM JAX-RPC Java Specification Request (JSR) 전문가 그룹 대표.

- 출처 : http://www.ibm.com/developerworks/kr/webservices/library/ws-tip-soapjax.html#N100EA -

'SOAP' 카테고리의 다른 글

JAVA로 SOAP 구축하기(2) (0)	2011.04.05
JAVA로 SOAP 구축하기(1) (0)	2011.04.05
[SOAP강좌] Java 서버 - Delphi 클라이언트 (0)	2011.04.05
기본 XML Web Services - MSDN (0)	2011.04.05
Soap이란? (0)	2011.04.05

Posted by 아로나

SOAP2011. 4. 5. 14:17

Soap이란?

1. Soap이란?

-SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP,HTTPS,SMTP등을 사용하여 XML기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜

-SOAP은 웹 서비스(Web Service)에서 기본적인 메시지를 전달하는 기반

2. Soap 작동원리

대다수의 방화벽이 웹 포트인 80 포트만 허용하기 때문에 SOAP은 대부분 HTTP에 의존하여 메시징 처리가 이루어진다. SOAP이 인터넷을 통한 메시징 처리의 표준으로 자리 잡을 수 있었던 이유는 HTTP 위에 SOAP이 올라갈 수 있기 때문이다. HTTP위에 SOAP이 올라간다는 것은 HTTP의 요청과 응답에 메시지에 SOAP 메시지가 포함될 수 있다는 것을 의미한다.

SOAP 스펙은 SOAP 메시지들이 단방향(one-way)이 아니라 양방향(two-way)이라고 말하고 있다 서버뿐 아니라 클라이언트도 SOAP메시지를 해석할 수 있어야 한다.

SOAP에 HTTP를 이용하는 이유

· HTTP는 이미 널리 구현되어 있으며, 이해하기 쉬운 프로토콜이다.

· 그 자체가 가지고 있는 요청/응답 패러다임이 RPC와 잘 들어 맞는다.

· 이미 대부분의 방화벽이 HTTP에서 작업할 수 있도록 설정되어 있다.

· HTTP는 보안 소켓 레이어(Secure Sockets Layer, SSL)를 이용하여 쉽게 보안을 구축 할 수 있다.

· 현재의 주 컴포넌트 기술로 일컬어지는 JAVA, CORBA, COM 등은 목적은 비슷하지만 목적을 구현하는 방법은 매우 다르므로 호환성을 기대하기 어렵다.

SOAP은 TCP나 HTTP뿐만 아니라 SMTP 같은 다양한 프로토콜과도 함께 사용할 수 있는 것이다. 메시징 서버를 사용해서 메시지 처리를 할 때와 마찬가지로, SOAP은 기본적으로 단방향으로 메시지를 보낸다. 송신자는 메시지를 보내지만, 수신자로부터 메시지를 받지는 않는다. 하지만 송신자가 메시지를 보내고 그 결과로 다시 SOAP 프로토콜을 통해 메시지를 받는 것은 가능하다.

3. Soap 메시지 구조

SOAP 메시지는 크게 SOAP Envelope, SOAP Header, SOAP Body, SOAP Fault로 구성되어있다.

· SOAP Envelope : Envelope는 SOAP 메시지를 감싸는 가장 상위의 요소이다. Envelope는 Header와 Body를 가질 수 있다.

· SOAP Header : Header는 메시지에서 필수적인 요소는 아니지만 SOAP 메시지에 기능을 추가 하는 역할을 담당한다. 여러 가지 정보를 헤더에 담기 위해 여러 개의 블록으로 구성되어 있으며, Header는 Envelope 태그 다음에 가장 먼저 나오는 항목이어야 한다. 보통 Header는 인코딩, 인증, 트랜잭션 같은 관리적인 문제에 사용된다.

· SOAP Body : Body는 SOAP을 통해 전송할 데이터로 채워진다. 여러 개의 블록으로 구성될 수 있으며, 요청할 때 요청할 웹 서비스의 이름과 매개변수로 채워지고, 응답할 때는 결과로 채워진다.

· SOAP Fault : SOAP 처리를 한 후 발생하는 에러 처리 메시지가 이 영역에 채워진다. SOAP Fault는 에러에 대한 자세한 내용을 기술할 수 있도록 다음과 같이 여러 개의 요소를 지원한다.

- <faultcode> : 에러의 종류를 코드로 구분할 수 있도록 해준다. 웹 서비스 소비자는 이 코드를 보고 어떤 종류의 에러가 발생했는지 알 수 있다. SOAP에는 SOAP 메시징에서 일어날 수 있는 기본 코드를 정의하고 있고 웹 서비스 제공자가 별도로 정의할 수도 있다.

- <faultstring> : 코드가 기계적인 내용인 데 반해, 스트링은 사람이 에러에 대한 내용을 읽고 이해할 수 있도록 해준다.

- <faultactor> : 메시징 처리를 하는 중에 어떤 부분에서 에러가 발생했는지 알릴 때 사용된다.

- <detail> : Body에 관련된 데이터 때문에 SOAP 메시징이 성공하지 못했을 경우에 사용된다. 만약 에러가 발생했는데 <detail> 부분이 없다면, Body와 관련된 부분에서 에러가 발생하지 않았다는 것을 알 수 있다.

4. Soap의 데이터베이스 접근방법

The SOAP developer's approach to such a problem is to encapsulate the database request logic for the service in a method (or function) in C or VB or Java etc, then set up a process that listens for requests to the service; such requests being in SOAP format and containing the service name and any required parameters. As mentioned, the transport layer might be HTTP though it could just as easily be SMTP or something else. Now, the listener process, which for simplicity is typically written in the same language as the service method, decodes the incoming SOAP request and transforms it into an invocation of the method. It then takes the result of the method call, encodes it into a SOAP message (response) and sends it back to the requester. Conceptually, this arrangement looks like the following:

예 ) ORACLE

5. Soap Message Packet

Client code makes a service call by invoking the appropriate method in the SOAP package (1). The

SOAP package's SOAP serializer converts this invocation into a SOAP request and sends that to t

e HTTP encoder (2). The HTTP encoder wraps the SOAP message in a HTTP request and sends it

o the SOAP server (3). The response is received from the SOAP server by the HTTP encoder/deco

er module(4) which decodes it and extracts the SOAP response which it hands to the SOAP deser

alizer(5). The SOAP deserializer deserializes the message and passes the result to the client code

(6) as the return value to the orginal invocation (1).

Appserver process receives a HTTP request from the SOAP Client at the SOAP service's URL (1) and passes it accordingly to the SOAP servlet (2). The SOAP servlet uses the package-supplied HTTP and SOAP decoding functionality to extract the details of the services call (3 and 4), ie. the method name and method parameters. Once armed with these the SOAP servlet can invoke the method (5 and 6), encode the response (7 and 8) and supply the HTTP response to the HTTP Request handler (9) which in turn replies to the SOAP Client (10). Note that the Servlet Thread box simply indicates what is running in the Servlet's VM.

'SOAP' 카테고리의 다른 글

JAVA로 SOAP 구축하기(2) (0)	2011.04.05
JAVA로 SOAP 구축하기(1) (0)	2011.04.05
[SOAP강좌] Java 서버 - Delphi 클라이언트 (0)	2011.04.05
기본 XML Web Services - MSDN (0)	2011.04.05
JAVA로 SOAP을 구현하려면? (0)	2011.04.05

Posted by 아로나

TCP/IP protocol suite2011. 4. 5. 11:37

TCP/IP 7 layer 예시

OSI/IP 모델
7. 응용 계층
NNTP · SIP · SSI · DNS · FTP · 고퍼 · HTTP · NFS · NTP · SMPP · SMTP · DHCP · SNMP · 텔넷 · (더 보기)
6. 표현 계층
MIME · XDR · TLS · SSL
5. 세션 계층
네임드 파이프 · NetBIOS · SAP · SIP
4. 전송 계층
TCP · UDP · SCTP · DCCP
3. 네트워크 계층
IP · ICMP · IPsec · IGMP · IPX · 애플토크
2. 데이터 링크 계층
ARP · CSLIP · SLIP · 이더넷 · 프레임 릴레이 · ITU-T G.hn DLL · L2TP · PPP · PPTP
1. 물리 계층
RS-232 · RS-449 · V.35 · V.34 · I.430 · I.431 · T1 · E1 · POTS · SONET/SDH · OTN · DSL · 802.11a/b/g/n PHY · ITU-T G.hn PHY · 이더넷 · USB · 블루투스

계층	기타	TCP/IP suite	SS7	AppleTalk suite	OSI suite	IPX suite	SNA	UMTS
7 - 응용	HL7, Modbus, SIP	HTTP, SMTP, SNMP, FTP, 텔넷, NFS, NTP	ISUP, INAP, MAP, TUP, TCAP	AFP, PAP	FTAM, X.400, X.500, DAP		APPC
6 - 표현	TDI, ASCII, EBCDIC, MIDI, MPEG	XDR, SSL, TLS		AFP, PAP
5 - 세션	FIFO(파이프), NetBIOS, SAP, SDP	TCP의 세션 관리 부분		ASP, ADSP, ZIP		NWLink	DLC?
4 - 전송	NetBEUI	TCP, UDP, RTP, SCTP		ATP, NBP, AEP, RTMP	TP0, TP1, TP2, TP3, TP4, OSPF	SPX, RIP
3 - 네트워크	NetBEUI, Q.931	IP, ICMP, IPsec, ARP, RIP, BGP	MTP-3, SCCP	DDP	X.25 (PLP), CLNP	IPX		RRC (라디오 리소스 제어)
2 - 데이터 링크	이더넷, 토큰링, FDDI, PPP, HDLC, Q.921, 프레임 릴레이, ATM, Fibre Channel		MTP-2	LocalTalk, TokenTalk, EtherTalk, 애플 리모트 액세스, PPP	X.25 (LAPB), 토큰 버스	802.3 framing, Ethernet II framing	SDLC	미디어 접근 제어(MAC)
1 - 물리	RS-232, V.35, V.34, Q.911, T1, E1, 10BASE-T, 100BASE-TX, ISDN, SONET, DSL		MTP-1	Localtalk on shielded, Localtalk on unshielded (PhoneNet)	X.25 (X.21bis, EIA/TIA-232, EIA/TIA-449, EIA-530, G.703)		Twinax	PHY (Physical Layer)

'TCP/IP protocol suite' 카테고리의 다른 글

TCP/IP Seven Layer Model - http://networking.ringofsaturn.com (0)	2011.04.05
OSI 7 Layer 완전분석 (0)	2011.04.05

Posted by 아로나

TCP/IP protocol suite2011. 4. 5. 02:39

TCP/IP Seven Layer Model - http://networking.ringofsaturn.com

Seven Layer Model

Introduction

When we browse the Internet, a physical connection allows for us to connect to the internet, either through a modem or through an Ethernet card in the case of a dedicated connection. A TCP/IP stack allows us to pass traffic and resolve web sites to IP addresses. Finally, applications, such as Netscape and Eudora, allow us to see the web sites and receive our e-mail.

The modem or Ethernet function has 2 parts. The modem or Ethernet drivers provide the computer with a way to communicate with the hardware. The PPP connection, also known as Dial-up Networking, allows your computer to access the modem. These two components provide the basis of getting a connection to the Internet.

The TCP/IP stack allows the computer to pass traffic across the link to the Internet in a meaningful way. That is, the TCP/IP stack allows your computer to speak the same "language" as the equipment at the other end of your connection. The TCP/IP stack also allows you to resolve friendly host names, such as www.verio.net, into an IP (Internet Protocol) address. Without the TCP/IP stack, we would be forced to go to each web site by it's IP address instead of a name!

Finally, the applications allow us to interact with friendly software to interpret HTML code into web pages for us, interact with mail servers to exchange e-mail, connect to news servers to retrieve and post news articles, and exchange data with FTP servers to allow us to download files. Without these programs, the Internet would be much more difficult to navigate through.

Why was it created?
The principles that were applied to arrive at the seven layers are as follows:

A layer should be created where a different level of abstraction is needed.
Each layer should perform a well defined function.
The function of each layer should be chosen in accordance with developing internationally standardized protocols.
The layer boundaries should be chosen to minimize the information flow across the interfaces.
The number of layers should be large enough that distinct functions need not be thrown together in the same layer out of necessity, and small enough that the architecture does not become unwieldy.

Having a way of categorizing each factor in an internet connection makes it easier for us to do our jobs as troubleshooters.
We all inherently understand that if the modem is not plugged in, you're not going to be able to get your e-mail. The OSI model allows us to follow that logic further: for example, if you can browse the web by IP but can't see websites by name, you know that the problem is not on the Network layer, but on the Transport layer.

How Encapsulation Works

The seven OSI layers use various forms of control information to communicate with their peer layers in other computer systems. This control information consists of specific requests and instructions that are exchanged between peer OSI layers. Control information typically takes one of two forms:

Header- Headers are prepended to the data passed down from upper layers.
Trailer- Trailers are appended to data passed down from upper layers.

Imagine that System A is requesting information from System B. System A makes an HTTP (Layer 7) request, which gets prepended with a header and appended with a footer. Layer 6 specifies whether it's a request for a GIF or an HTML document, and treats the Layer 7 header, data, and footer as its own data, prepending that with a header and appending it with a footer. The same treatment happens on Layer 5, and so on.
System B receives the request on Layer 1, and begins the decapsulation process, stripping the Layer 1 headers and footers off to reveal the Layer 2 information, and so forth, all the way up to the 7th layer.

Application

The application layer interacts with software applications (such as Netscape or Outlook Express) that implement a communicating component. Such application programs are outside of the scope of the OSI model, but they translate an enduser's typing into a Layer 7 request. Application layer functions typically include the following:

Identifying communication partners - The application layer identifies and determines the availability of communication partners for an application with data to transmit.

Determining resource availability - The application layer must determine whether sufficient network resources for the requested communication are available.

Synchronizing communication - Communication between applications requires cooperation that is managed by the application layer.

Example: The Application layer is responsible for identifying that there is a web server answering on port 80 in order for HTTP communication to happen.

Presentation

The presentation layer provides a variety of encoding and encryption functions that are applied to the application layer data. These functions ensure that information sent from the application layer of one system will be readable by the application layer of another system. Some examples of presentation layer encoding and encryption schemes follow:

Conversion of character representation formats - Conversion schemes are used to exchange information with systems using different text and data representations (such as EBCDIC and ASCII).

Common data representation formats -the use of standard image, sound, and video formats (like JPEG, MPEG, and RealAudio) allow the interchange of application data between different types of computer systems.

Common data compression schemes - The use of standard data compression schemes (like WinZip or GZip) allows data that is compressed at the source device to be properly decompressed at the destination.

Common data encryption schemes - The use of standard data encryption schemes allows data encrypted at the source device to be properly unencrypted at the destination.

Session

The session layer establishes, manages, and terminates communication sessions between presentation layer entities. Communication sessions consist of service requests and service responses that occur between applications located in different network devices. These requests and responses are coordinated by protocols implemented at the session layer.
For example, SQL is a Session layer application that manages multiple queries to the SQL database. It's what allows multiple people to log in to, say, the Intranet at the same time.

Transport

The transport layer implements reliable internetwork data transport services that are transparent to upper layers. Transport layer functions typically include the following:

Flow control - Flow control manages data transmission between devices so that the transmitting device does not send more data than the receiving device can process.
Sliding Window - This allows the receiving computer to dictate to the receiving end how many packets the receiver is capable of receiving at one time.
Multiplexing - Multiplexing allows data from several applications to be transmitted onto a single physical link.
Virtual circuit management - Virtual circuits are established, maintained, and terminated by the transport layer.
Three-way handshake - The three-way handshake is a connection establishment protocol. First, host A sends a SYN segment to host B in order to check that host B gets ready for establishing a TCP connection. Second, when host B receives the SYN segment that host A sent and is ready to start the TCP session, it sends a SYN and ACK segment back to host A. This ACK advertises an arrival of the first SYN segment to host A. Finally, host A sends an ACK segment for the second SYN and ACK segment that host B sent.
Error checking and recovery - Error checking mechanisms for detecting transmission errors. Error recovery involves taking an action (such as requesting that data be retransmitted) to resolve any errors that occur.

The two most common Transport layer protocols are TCP and UDP.
Common Transport Layer Ports

21 FTP

22 SSH

23 telnet

25 SMTP

53 DNS

80 HTTP

110 POP3

143 IMAP

443 HTTPS

A complete Port List

Network

The network layer provides routing and related functions that allow multiple data links to be combined into an internetwork. This is accomplished by the logical addressing (as opposed to the physical addressing) of devices. The network layer supports both connection-oriented and connectionless service from higher-layer protocols.
Common protocols on the Network layer are BGP and OSPF. RIP is another Network layer protocol, but is not used on larger networks because of its inefficiency.

Data Link

The data link layer is where the logical information (i.e., IP addresses) is translated into the actual electrical pulses that travel over the physical layer. Frame Relay, ATM, and DSL all work on the Data Link layer.
Different data link layer specifications define different network and protocol characteristics, including the following:

Physical addressing - Physical addressing (as opposed to network addressing) defines how devices are addressed at the data link layer.
Network topology - Data link layer specifications often define how devices are to be physically connected (such as in a bus or a ring topology).
Error notification - Error notification involves alerting upper layer protocols that a transmission error has occurred.
Sequencing of frames - Sequencing of data frames involves the reordering of frames that are transmitted out of sequence.
Flow control - Flow control involves moderating the transmission of data so that the receiving device is not overwhelmed with more traffic than it can handle at one time.

Logical Link Control Sub-layer
The Logical Link Control (LCC) sublayer of the data link layer manages communications between devices over a single link of a network. LCC is defined in the IEEE 802.2 specification. IEEE 802.2 defines a number of fields in data link layer frames that allow multiple higher-layer protocols to share a single physical data link. LLC supports both connectionless and connection-oriented services used by higher-layer protocols.
Media Access Control Sub-layer
The Media Access Control (MAC) sublayer of the data link layer manages protocol access to the physical network medium. The IEEE MAC specification defines MAC addresses, which allow multiple devices to uniquely identify one another at the data link layer.

Physical

The physical layer defines the electrical, mechanical, procedural, and functional specifications for activating, maintaining, and deactivating the physical link between communicating network systems. Physical layer specifications define such characteristics as voltage levels, timing of voltage changes, physical data rates, maximum transmission distances, and the physical connectors to be used.
Common examples of things that work on the Physical layer are Fiber Optic cables, CAT5 (ethernet) cables, and Copper Twisted Pair.

Troubleshooting using the Seven-Layer Model
The key here is to think of the Internet like a giant Taco Bell seven-layer burrito...just kidding.
The whole point of the OSI model is to make our jobs easier through classification and dilineation of functions. Ultimately, the easiest way to use the seven-layer model is by figuring out what the user can do on the Net, then going up one layer and seeing if they can perform the functions that are supposed to be performed on that layer.
For example:

Is the router plugged in? What lights are on? If the router is not a) plugged in to the electrical outlet and b) plugged in to the ISDN jack, the user won't be able to ping.
If the user can ping but can't browse the internet, can the user visit a website by IP address? If the user's TCP configurations are incorrect, they will obviously not be able to translate a name to IP address, and therefore, won't be able to get mail, either.
Elementary.

Seven Layer Model Charts

'TCP/IP protocol suite' 카테고리의 다른 글

TCP/IP 7 layer 예시 (0)	2011.04.05
OSI 7 Layer 완전분석 (0)	2011.04.05

Posted by 아로나

TCP/IP protocol suite2011. 4. 5. 00:48

OSI 7 Layer 완전분석

OSI 참조모델

계층이름	기능설명	예
에플리케이션층	다른 컴퓨터와 통신하고 있는 애플리케이션은 OSI 애플리케이션 계층의 개념을 구현한 것이다. 애플리케이션 계층은 애플리케이션에 대한 통신 서비스를 제공한다. 예를들어, 통신에 대한 기능이 없는 워드프로세서 는 통신에 관련한 코드를 구현하지 않아도 되고 관련 프로그래머는 OSI 7계층에 대해서 신경쓰지 않아도 된다. 그러나 파일 전송 옵션이 추가된다면, 그 워드프로세서는 OSI7계층을 구현해야한다.	telnet, HTTP, FTP, www 브라우저, NFS, SMTP 게이트웨이, SNMP, X.400 메일, FTAM
프리젠테이션층	이 계층의 주된목적은 ASCII 텍스트, EDBCDIC 텍스트, 바이너리, BCD, JPEG 등과 같은 데이터의 포멧을 정의하는 것이다. 또한 암호화도 프리젠테이션 계층의 서비스로서 정의된다. 예를 들어, FTP는 바이너리나 ASCII 전송중에서 선택할수있다. 만약 바이너라가 선택된다면 전송자와 수신자는 그 파일의 내용을 변경하지 않는다. 만약 ASCII가 선택되면 전송자는 전송택스트를 ASCII로 변환하여 전송하고 그 표준 ASCII를 수신 컴퓨터에서 전송하는 문자 집합으로 다시 변환한다.	JPGE, ASCII, EBCDIC,TIFF, GIF, PICT, 암호화, MPEG, MIDI
세션층	세션계층은 세션이라고 부르는 대화의 시작, 조정, 종결에 대해 규정한다. 이러한 역할에는 복수개의 양방향 메시지를 제어, 관리하는 역할도 있어서 만약 연속된 메시지 중 일부만 전송된 경우에는 애플리케 이션이 그 사실을 알 수 있도록 하는 것이 포함된다. 이것은 프리젠테이션 계층이 수신되는 데이터스트림을 중단없이 볼 수 있게 한다. 어떤 경우에 있어 프리젠테이션 계층은 모든 흐름이 끝난 경우에만 데이터를 나타낼 수 있다. 예를 들어, 은행 계좌에서 현금을 인출하는 ATM 기의 거래에 있어 여러분이 그 현금을 손에 쥐기 전까지는 계좌에서 돈이 빠져나간 것으로 처리되어서도 안되며 그 거래가 완성된 것으로 그록되어서도 안된다. 세션 계층은 어떤 흐름이 같은 세션의 일부이며 어떤 흐름이 다른 흐름이 완성되기 전에 끝나야 하는지 등에 대한 방법을 만드는 역활을 한다.	RPC, SQL, NFS, NetBios names, Apple Talk ASP, DECnet SCP
전송층	4계층에서는 에러 복구를 제공할 지의 여부에 따라 프로 토콜을 선택한다. 동일한 호스트의 애플리케이션으로 들어오는 다양한 데이터 흐름을 동시에 전송받기도 하고, 순서가 뒤바뀐 패킷이 들어오면 데이터 스트림의 순서를 재배치하기도 한다.	TCP,UDP SPX
네트워크층	이 계층은 양단 간의 패킷 전송을 정의한다. 네트워크 계층은 어떠한 단말이라도 식별이 가능할수 있도록 논리적인 주소 할당을 정의한다. 또한 패킷이 전달 될 수 있도록 라우팅이 동작하는 원리와 경로를 알 수 있는 방법에 대해서도 정의한다. 또한 네트워크 계층은 보다 작은 MTU크기를 가지는 매체를 위해서 패킷을 보다 작은 패킷으로 분할하는 방법에 대해서도 정의한다. (주의 : 모든 3계층 프로토콜이 분할을 사용하는 것은 아니다.) OSI의 네트워크 계층은 시스코 라우터가 라우 팅할 때 고려하는 대부분의 사항에 대해 정의하고 있다. 예를 들어, 시스코 라우터에서 동작되고 있는 IP는 패킷의 목적지 IP주소를 검사하는 역할을 하고, 그 주소를 IP 라우팅 테이블과 비교한다. 만약 출력 인터페이스가 더 작은 패킷을 필요로 하는 경우에는 그 패킷을 분할하고, 해당 인터페이스로 패킷이 전송될수 있도록 큐잉 (queuing)하는 역할을 한다.	IP, IPX, AppleTalk, DDP, ICMP
데이터 링크층	데이터링크 계층은 특정 링크 또는 매체를 통한 데이터의 전송과 관련이 있다. 데이터 링크 프로토콜은 개별 링크를 통한 전달을 정의한다. 이러한 프로토콜은 매체의 형태와 관련지어야 한다. 예를 들어, 802.3과 802.2는 IEEE에서 규정하였으며, 이는 OSI참조 모델의 유효한 데이터 링크 프로토콜과 관련한다. 이 스펙은 이더넷의 작동 원리에 대해 규정한 것이다. 점-대-점 WAN링크를 위한 HDLC 프로토콜과 같은 프로토콜들은 WAN 링크에 대해서 상세히 다룬다. OSI는 데이터링크 계층에 대해서 다른 프로토콜 스펙에서처럼 어떤 고유 스펙을 규정하지 않는다. 대신에 데이터링크 계층과 물리 계층에 대해서는 IEEE 에서 제정한 표준과 같은 다른 표준안을 따른다.	IEEE802.3/ 802.2, HDLC, Frame Relay, PPP, FDDI, ATM, IEEE 802.5/ 802.2
물리층	물리계층의 스펙 또한 다른 기구의 표준을 참조하며, 이계층은 전송 매체의 물리적인 특성에 대해 정의한다. 커넥터, 핀, 핀의 사용, 전기적 흐름, 인코딩, 빛의 조절 등은 모두 물리계층 스펙의 일부이다. 물리 계층의 모든 세부 사항을 완정하기 위해 다양한 스펙이 사용된다. 예를들어, RJ-45는 커넥터의 형태와 케이블의 선 또는 핀의 수에 정의한다. 이더넷과 802.3은 선 또는 핀 1.2.3.6을 정의하고, 이더넷을 연결하기 이해 RJ-45커넥터와 카테고리 5케이블을 사용하기 위해서는 이더넷과 RJ-45 물리계층의 스펙이 함계 사용된다.	EIA/TIA-232, v.35, EIA/TIA-449, V.24,RJ45, Ethernet802.3 , 802.5, FDDI, NRZI, NRZ, B8ZS

[? JooN.Y.Lee !]

위의 것이 복잡한가?
우리가 네트워크를 공부한다면 어디가서든지 이 OSI 7계층에 대해 알아야할것이다. 위의 표는 내용을 이해하기에는 좋기만 암기하기에는 힘들다.
그래서 암기하기 좋게 요약해주겠다.
고마워서 눈물 흘릴 필요없다. 밥이나 사라...ㅋ

계층	기능설명	예
7	네트워크와 애플리케이션 소프트웨어 간 인터페이스	Telnet,HTTP
6	데이터가 표현되는 방법 암호화와 같은 특수 처리	JPEG,ASCII, EBCDIC
5	다른 애플리케이션에서 데이터 분리	OS,에플리케이션 엑세스의 스케줄링
4	신뢰할 수 있는/ 신뢰할수 없는 전송 다중통신 (Mutiplexing)	TCP,UDP,SPX
3	라우터가 경로의 결정을 위해 사용하는 논리적 주소사용	IP,IPX
2	비트의 바이트화, 바이트의 프레임화의 조합	802.3/802.2, HDLC
1	장비간의 비트의 이동, 볼트, 선로의 속도 케이블핀 사양에 대한 스펙	EIA/TIA-232,V.35

계층화의 개념과 장점

- 네트워크의 기능이나 역활을 "계층"이라고 부르는 작은 단위로 분류하고, 이들 계층간의 표준 인터페이스를 정의함으로써 많은 장점을 얻을 수 있다. 계층이 분류되면서, 즉 복잡한 개념과 프로토콜이 작은 부분으로 쪼개어지면서 하드웨어와 소프트웨어에 적용하거나 문제 해결이 용히해졌고, 이에 대해 논의하기도 쉬워졌다.

이에 대한 장점은....

1. 프로토콜 스펙의 많은 세부 사항에 대하여 보다 쉽게 토론하고 학습할수 있다.
2. 계층간의 표준화된 인터페이스는 모듈화된 엔지니어링을 촉진시킨다. 다른 제품들이 일부 계층의 기능만 제공하거나(라우터의 경우 1~3계층까지의 기능을 제공한다.), 프로토콜의 기능중 일부만 사용할 수 있다.
3. 상호 연동에 더 좋은 환경을 만들어진다. 한 벤더는 상위 계층을 구현하는 소프트웨어, 예를 들어, 웹브라우저를 만들수 있다. 그리고 다른 벤더는 하위계층을 구현하는 소프트웨어, 예를 들어 마이크로소프트의 운영체제 속에 내장된 TCP/IP 소프트웨어를 만들수 있다.
4. 복잡성의 감소는 프로그램의 변경을 쉽게하고, 제품의 진화를 빠르게한다.
5. 각각의 계층은 바로 아래 계층의 서비스를 이용한다. 그러므로 각각의 계층이 어떤 역할을 하는지 기억하기에 쉽다. (예를 들어, 네트워크 계층은 데이터를 양단간에 전달할 수 있다.) 이 역활을 보기 위해 네트워크 계층은 종간간의 경로를 따라 그 다음의 장비로 데이터를 전송하기 위해서 데이터링크 계층을 사용한다.

OSI 계층 간의 상호작용

웹 브라우저가 웹 서버로부터 다운로드한 페이지를 나타낸다고 하자. 그 일이 일어나기전에 브라우저는 클라이언트 컴퓨터의 TCP/IP에 있는 다른 계층을 구현하는 소프트웨어와 상호작동하며, 서버에 요청을 보낸다. 마찬가지로 브라우저 애플리케이션은 브라우저가 어떤 페이지를 보여주려고하는지 서버에 알려주면서 웹서버 애플리케이션과 통신한다. 이런 두가지 생각을 간단히 설명하면 'OSI 계층간의 상호작용'이다. 같은 컴퓨터에서 계층간에 어떻게 상호작용하는지의 과정뿐만 아니라 다른 컴퓨터에서 같은 계층이 어덯게 통신하는지는 서로 연관되어있다. 소프트웨어나 하드웨어 제품은 OSI프로토콜 계층이 제공하는 다음 두가지의 일반적인 기능을 수행한다.

1. 각각의 계층은 프로토콜 스펙안에서 바로 위의 계층에 서비스를 제공한다.
2. 각각의 계층은 다른 컴퓨터의 동일 계층에 해당하는 소프트웨어나 하드웨어와 정보를 교환한다. 어떤 경우에는 그 다른 컴퓨터가 동일한 전송 매체에 연결되있고, 네트워크 반대쪽일수도 있다.

- 연결지향프로토콜 : 양단간에 전송이 시작되기 전에 메시지의 교환을 필요로 하거나 미리 확립된 연관 관계가 필요한 프로토콜
- 비연결지향프로토콜 : 양단간에 메시지의 교환 또는 미리 확립된 연관 관계가 필요하지 않은 프로토콜

- 출처 : http://iksu.egloos.com/391883 , 변익수님 블로그 -

'TCP/IP protocol suite' 카테고리의 다른 글

TCP/IP 7 layer 예시 (0)	2011.04.05
TCP/IP Seven Layer Model - http://networking.ringofsaturn.com (0)	2011.04.05

Posted by 아로나

«이전 1 ··· 24 25 26 27 다음»

'분류 전체보기'에 해당되는 글 267건

'SOAP' 카테고리의 다른 글

기본 XML Web Services

목차

XML Web Service

SOAP

보안

WSDL

UDDI

기타

'SOAP' 카테고리의 다른 글

Tip: SOAP attachments와 JAX-RPC

'SOAP' 카테고리의 다른 글

'SOAP' 카테고리의 다른 글

'TCP/IP protocol suite' 카테고리의 다른 글

Seven Layer Model

Introduction

Why was it created?

How Encapsulation Works

Application

Presentation

Session

Transport

Network

Data Link

Physical

Troubleshooting using the Seven-Layer Model

Seven Layer Model Charts

'TCP/IP protocol suite' 카테고리의 다른 글

'TCP/IP protocol suite' 카테고리의 다른 글

카테고리

공지사항

태그목록

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

달력

링크

티스토리툴바