T T A S t a n d a r d .kr



|T T A  S t a n d a r d |정보통신단체표준(국문표준) |

| |TTAx.xx-xx.xxxx        제정일: 2014년 xx월 xx일 |

| | |

| | |

| | |

| | |

| |기업 스마트워크에서 REST 기반의 통합 커뮤니케이션을 위한 서비스 인터페이스 |

| | |

| |RESTful API for Unified Communication in Enterprise Smart Work |

| | |

| | |

| | |

| |[pic] |

|정보통신단체표준(국문표준) |

|TTAx.xx-xx.xxxx         제정일: 2014년 xx월 xx일 |

| |

| |

| |

| |

| |

| |

|기업 스마트워크에서 REST 기반의 통합 커뮤니케이션을 위한 서비스 인터페이스 |

| |

|RESTful API for Unified Communication in Enterprise Smart Work |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

|[pic] |

|본 문서에 대한 저작권은 TTA에 있으며, TTA와 사전 협의 없이 이 문서의 전체 또는 일부를 상업적 목적으로 복제 또는 배포해서는 안 |

|됩니다. |

| |

|Copyrightⓒ Telecommunications Technology Association 2014. All Rights Reserved. |

서   문

1. 표준의 목적

국내 IT 융합 산업의 경쟁력을 높이기 위해서는 산업계 전반의 여러 응용 분야에서 서비스 개발의 효율성 제고가 필요하고, 이를 위한 방안으로 다양하고 융합서비스를 공통적으로 지원하는 새로운 플랫폼이 필요하다. 따라서 본 문서는 기업 스마트워크 환경에서 통합커뮤니케이션을 위한 REST (REpresentational State Transfer) 기반의 서비스 컴포넌트 기능을 기술한다. 또한 통합 커뮤니케이션 응용 제공 시 필요한 기능을 도출하여 각각의 서비스 컴포넌트로 정의한다.

2. 주요 내용 요약

본 문서는 기업 스마트워크 환경에서 통합 커뮤니케이션 응용 제공 시 필요한 주요 기능 요소를 REST 기반의 서비스 컴포넌트화하고 각 서비스 컴포넌트의 파라메터와 제공 기능에 대해 기술한다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

스마트워크 도입 시 필요한 공통 서비스 기능 및 특정 분야 서비스 기능을 제공하는 스마트워크 공통플랫폼으로 기업의 스마트워크 도입 시 활용될 수 있다.

4. 참조 표준(권고)

4.1. 국외 표준(권고)

- 해당사항 없음

4.2. 국내 표준

- 해당사항 없음

5. 참조 표준(권고)과의 비교

5.1. 참조 표준(권고)과의 관련성

- 해당사항 없음

5.2. 참조한 표준(권고)과 본 표준의 비교표

- 해당사항 없음

6. 지식재산권 관련사항

  본 표준의 '지식재산권 확약서‘ 제출 현황은 TTA 웹사이트에서 확인할 수 있다.

※본 표준을 이용하는 자는 이용함에 있어 지식재산권이 포함되어 있을 수 있으므로, 확인 후 이용한다.

※본 표준과 관련하여 접수된 확약서 이외에도 지식재산권이 존재할 수 있다.

7. 시험인증 관련사항

7.1. 시험인증 대상 여부

- 해당사항 없음

7.2. 시험표준 제정 현황

- 해당사항 없음

8. 표준의 이력 정보

8.1. 표준의 이력

|판수 |제정․개정일 |제정․개정내역 |

|제1판 |2014.xx.xx. |제정 |

| | |TTAx.xx-xx.xxxx |

8.2. 주요 개정 사항

- 해당사항 없음

Preface

1. Purpose of Standard

It is essential to enhance the efficiency of service development in many applications throughout the industry in order to increase the competitiveness of the domestic IT industry convergence and the new platform to commonly support a variety of converged services is required as an alternative to achieve it. Therefore, in this standard we describe service component features based on the REST (REpresentational State Transfer) for Unified Communication in the enterprise smart work environment. In addition, we define the functions required in providing Unified Communication applications as each of the service components.

2. Summary of Contents

This standard defines the main functional elements in providing applications for Unified Communication in the smart work enterprise environment as the REST-based service components and describes the parameters and functions of each service component.

3. Applicable Fields of Industry and its Effect

This standard can be used as a reference to the smart work common platform providing the function of common services and specific field services when the company introduces smart work.

4. Reference Standards(Recommendations)

4.1. International Standards(Recommendations)

- None

4.2. Domestic Standards

- None

5. Relationship to Reference Standards(Recommendations)

5.1. Relationship of Reference Standards(Recommendations)

- None

5.2. Differences between Reference Standard(Recommendation) and this Standard

- None

6. Statement of Intellectual Property Rights

IPRs related to the present document may have been declared to TTA. The information pertaining to these IPRs, if any, is available on the TTA Website.

No guarantee can be given as to the existence of other IPRs not referenced on the TTA website.

And, please make sure to check before applying the standard.

7. Statement of Testing and Certification

7.1. Object of Testing and Certification

- None

7.2. Standards of Testing and Certification

- None

8. History of Standard

8.1. Change History

|Edition |Issued date |Outline |

|The 1st edition |2013.xx.xx |Established |

| | |TTAx.xx-xx.xxxx |

8.2. Revisions

- None

목   차

1. 개 요 1

2. 표준의 구성 및 범위 1

3. 참조 표준(권고) 1

4. 용어 정의 및 약어 1

4.1. 용어 정의 1

4.2. 약어 2

5. 서비스 컴포넌트 제공 구조 및 기능 목록 3

5.1. 서비스 컴포넌트 제공 구조 3

5.2. 서비스 컴포넌트 기능 목록 3

6. REST 기반의 서비스 컴포넌트 4

6.1. 제3자호 서비스 컴포넌트 4

6.2. 이메일 서비스 컴포넌트 8

6.3. 단문메시지 서비스 컴포넌트 10

6.4. 프레즌스 서비스 컴포넌트 12

관련문헌 16

Contents

1. Overview 1

2. Structure and Scope 1

3. Reference standards(recommendations) 1

4. Term definitions and Acronyms 1

4.1. Term definitions 1

4.2. Acronyms 2

5. The Structure and Function list of Service components 3

5.1. The Structure of Service component 3

5.2. The Function list of Service components 3

6. REST-based Service component 4

6.1. Third party calling service component 4

6.2. E-mail service component 8

6.3. Short messaging service component 10

6.4. Presence service component 12

References 16

기업 스마트워크에서 REST 기반의 통합 커뮤니케이션을 위한

서비스 인터페이스

(RESTful API for Unified Communication)

1. 개 요

국내 IT 융합 산업의 경쟁력을 높이기 위해서는 산업계 전반의 여러 응용 분야에서 서비스 개발의 효율성 제고가 필요하고, 이를 위한 방안으로 다양하고 손쉽게 융합서비스를 제공하도록 공통적으로 지원하는 신규 플랫폼이 필요하다. 특히, 국내산업의 균형적인 경쟁력 향상을 도모하기 위해서는 다양한 산업 분야에서 IT 기반의 융합 서비스 창출 및 고부가가치 서비스 제공을 위한 서비스 공통구조를 개발하여 확산 보급할 필요가 있다.

본 문서는 기업 스마트워크 환경에서 통합 커뮤니케이션을 위한 REST (REpresentational State Transfer) 기반의 서비스 컴포넌트 기능을 기술한다. 또한 통합 커뮤니케이션 응용 제공 시 필요한 기능을 도출하여 각각의 서비스 컴포넌트로 정의한다.

2. 표준의 구성 및 범위

본 문서는 기업 스마트워크 환경에서 통합 커뮤니케이션 응용 제공 시 필요한 주요 기능 요소를 REST 기반의 서비스 컴포넌트화하고 각 서비스 컴포넌트의 파라메터와 제공 기능에 대해 기술하였다. 이를 위하여 다음과 같은 내용을 포함한다.

- REST 기반의 제3자호 서비스 컴포넌트

- REST 기반의 이메일 서비스 컴포넌트

- REST 기반의 단문메시지 서비스 컴포넌트

- REST 기반의 프레즌스 서비스 컴포넌트

3. 참조 표준(권고)

해당사항 없음

4. 용어 정의 및 약어

4.1. 용어 정의

4.1.1. 컴포넌트 서비스

재사용 가능한 서비스 단위로, 단일/복합/추상적인 형태로 인터넷을 통해 제공되고, SOAP (Simple Object Access Protocol) 또는 REST 방식으로 공개(exposing) 가능한 온라인 서비스. 본 문서에서 별도의 언급이나 수식어 없이 사용된 ‘서비스’는 컴포넌트 서비스를 의미

4.1.2. 응용 서비스

재사용 가능한 컴포넌트 서비스를 조립하여 원하는 비즈니스 기능을 수행하는 어플리케이션을 의미한다. 본 문서에서 응용서비스는 기존의 일체형 어플리케이션이 아닌 서비스 기반 어플리케이션임

4.1.3. 플랫폼 서비스

응용서비스를 쉽게 개발, 실행, 구축할 수 있도록 응용서비스 개발자 관점에서 통합된 플랫폼 형태의 서비스 형태로 제공한다는 의미로, 클라우드 환경에서는 일반적으로 PaaS (Platform as a Service)라고 알려져 있음

4.1.4. REST 프로토콜

REST는 Representational State Trasfer의 줄임말로 웹 환경에서 데이터를 송수신하기 위한 소프트웨어 아키텍처이다. 부가적인 전송 계층(layer) 없이 간단한 인터페이스로 데이터 통신을 수행할 수 있음.

4.2. 약어

|AMI |Asterisk Management Interface |

|API |Application Programming Interface |

|DB |Data Base |

|IM |Instant Messaging |

|IPPBX |Internet Protocol Private Branch eXchange |

|JSON |JavaScript Object Notation |

|PaaS |Platform as a Service |

|REST |REpresentational State Transfer |

|SOAP |Simple Object Access Protocol |

|SIP |Session Initiation Protocol |

|SMS |Short Message Service |

|SMTP |Simple Mail Transfer Protocol |

|TPC |Third Party Call |

|URL |Uniform Resource Locator |

|XMPP |eXtensible Messaging and Presence Protocol |

5. 서비스 컴포넌트 제공 구조 및 기능 목록

본 장에서는 통합 커뮤니케이션을 위한 REST 기반의 서비스 컴포넌트 제공 구조 및 기능 목록을 기술한다.

5.1. 서비스 컴포넌트 제공 구조

통합 커뮤니케이션을 위한 REST 기반의 서비스 컴포넌트 제공 구조는 크게 서비스 컴포넌트가 탑재되는 웹서비스 모듈과 백엔드 서버로 나누어진다. 이를 위하여 아래 그림에서 구체적으로 도시를 하였다.

[pic]

5.2. 서비스 컴포넌트 기능 목록

아래 표는 REST 기반의 서비스 컴포넌트 주요 기능을 요약한 목록이다. 이는 제3자호, 이메일, 단문메시지, 프레즌스 서비스 컴포넌트를 포함한다.

|기능 그룹 |서비스 컴포넌트 |설명 |

|RESTful 서비스 |제3자호 |두 개의 단말에 각각 전화를 걸어 연결시켜주는 서비스 기능 |

|컴포넌트 | | |

| |이메일 |임의의 이메일 주소로 이메일을 발송하는 서비스 기능 |

| |단문메시지 |임의의 이동단말에 단문메시지를 송신하는 서비스 기능 |

| |프레즌스 |개인의 프레즌스 정보를 조회/설정 및 버디리스트를 조회하는 서비스 기능 |

6. REST 기반의 서비스 컴포넌트

6.1. 제3자호 서비스 컴포넌트

IPPBX (Internet Protocol Private Branch eXchange) 기반 호 연결 제어를 위한 아래와 같은 기능을 제공한다. 제3자호 서비스 컴포넌트는 IPPBX 서버와 연동을 한다. 명령의 호출은 오퍼레이션별로 정의된 리소스에 대한 URL (Uniform Resource Locator)에 대하여 명령어 별로 정의된 HTTP Method를 사용하여 HTTP Request를 보냄으로서 수행된다. 아래 표는 제3자호 서비스를 위해서 정의된 리소스이고, 그림은 이를 위한 하나의 예제로서 시퀀스 다이어그램이다.

|기능명 |Resource |HTTP method |

|Make Call |CRofTPC/sc/rest/tpc/ |POST |

|End Call |CRofTPC/sc/rest/tpc/{callId} |DELETE |

|Get Call Status |CRofTPC/sc/rest/tpc/{callId} |GET |

[pic]

1. HTTP 메소드로 해당 리소스를 요청한다.

2. IPPBX에 리소스를 생성, 삭제, 조회를 한다.

3. IPPBX에서 해당 정보를 보낸다.

4. 요청한 응용에게 해당 결과를 전달한다.

아래 그림은 제3자호 서비스 컴포넌트의 상위 레벨의 구조도이다. 그림에서 보이듯이, 제3자호 서비스 컴포넌트는 Web Container에 탑재되는 웹 모듈로 구현된다. 어플리케이션은 REST 기반 웹 서비스를 이용하여 제3자호 서비스 컴포넌트를 사용하고, 제3자호 서비스 컴포넌트는 호를 처리하기 위하여 IPPBX가 제공하는 AMI 인터페이스를 소켓 통신을 이용하여 연동한다. REST API MiddleWare는 제3자호 서비스 컴포넌트가 제공하는 API를 REST 기반 웹 서비스로 변환하는 역할을 수행한다. 따라서 제3자호 서비스 컴포넌트는 순수하게 JAVA 클래스로 호 제어에 관련된 기능만을 구현한다. 대표적 REST API MiddleWare로는 Sun Jersey Rest 라이브러리와 Apache CXF 가 있다.

[pic]

6.1.1. Make call

CallingParty와 CalledParty의 전화번호를 입력받아 두 단말간 전화연결을 시도하고 그 결과를 반환한다. CallingParty는 반드시 IPPBX상 채널로 등록된 내부 사용자의 전화번호이어야 하는 반면, CalledParty는 그러한 제약이 없다. 정상적으로 호가 생성된 경우, 호를 유일하게 식별할 수 있는 호식별자(CallIdentifier)가 반환된다. 정상적으로 호를 생성할 수 없는 경우 적절한 Exception을 발생시켜야 한다. 대표적 Exception 상황은 다음과 같다.

- 입력 파라메터의 문법적 오류

- 존재하지 않는 전화번호 사용

명령어 요청 및 응답시의 파라메터는 JSON (JavaScript Object Notation)으로 기술되도록 한다.

1) Request parameters

|name |description |

|callingParty |발신자의 전화번호 |

|calledParty |수신자의 전화번호 |

1) Response

|name |description |

|callIdentifier |호 식별자 |

6.1.2. End call

이미 연결된 호에 대하여 해제 처리를 하는 기능을 제공한다. 따라서 호 설정 성공시 반환받은 호 식별자가 매개 변수로 반드시 설정되어야 한다. 제3자호 서비스 컴포넌트는 endCall 요첨을 받으면 호 식별자에 의해 식별되는 호를 찾아내고, 또한 호를 구성하는 Call Leg (채널)를 찾아낸다. 찾아낸 각 Call Leg에 대해 IPPBX에 연결 해제를 요청한다. 존재하지 않는 호나 이미 해제된 호에 대해 endCall 요청을 받은 것은 Exception을 발생시킨다. 명령어 요청 및 응답시의 파라메터는 JSON으로 기술되도록 한다.

1) Request parameters

|name |description |

|callIdentifier |호 생성시 반환받은 호 식별자 |

2) Response

없음

6.1.3. Get call status

제3자호 서비스 컴포넌트를 통해 생성한 호에 대한 상태 정보를 제공한다. 따라서 호 설정 성공시 반환받은 호 식별자가 매개 변수로 반드시 설정되어야 한다. 제3자호 서비스 컴포넌트는 getCallStatus 요청을 받으면 호 식별자에 의해 식별되는 호를 찾아내고, 호 상태를 저장하고 있는 DB에 질의하여 해당 호에 대한 정보를 구한다. 명령어 요청 및 응답시의 파라메터는 JSON으로 기술되도록 한다.

1) Request parameters

|name |description |

|callIdentifier |호 생성시 반환받은 호 식별자 |

3) Response

|name |description |

|callId |호 식별자 |

|channel |생성된 채널 명 |

|callingPartyAddress |발신자의 전화번호 |

|calledPartyAddress |수신자의 전화번호 |

|callStatus |호 상태 정보 반환, 최소한 호가 연결해제된 상태 및 연결된 상태가 포함되어야 |

| |한다. |

6.2. 이메일 서비스 컴포넌트

이메일 서비스 컴포넌트는 아래와 같은 기능을 제공한다. 명령의 호출은 Operation별로 정의된 Resource에 대한 URL에 대하여 명령어 별로 정의된 HTTP Method를 사용하여 HTTP Request를 보냄으로서 수행된다. 아래 표는 이메일 서비스를 위해서 정의된 리소스이고, 그림은 이를 위한 하나의 예제로서 시퀀스 다이어그램이다.

|기능명 |Resource |HTTP method |

|Send Mail |CRofEmail/sc/rest/email/ |POST |

[pic]

1. HTTP 메소드로 해당 리소스를 요청한다.

2. Email 서버에 리소스 생성 요청을 한다.

3. Email 서버에서 해당 정보를 보낸다.

4. 요청한 응용에게 해당 결과를 전달한다.

아래 그림은 이메일 서비스 컴포넌트의 상위 레벨의 구조도이다. 그림에서 보이듯이, 이메일 서비스 컴포넌트는 Web Container에 탑재되는 웹 모듈로 구현된다. 어플리케이션은 REST 기반 웹 서비스를 이용하여 이메일 서비스 컴포넌트를 사용하고, 이메일 서비스 컴포넌트는 메일을 보내기 위하여 메일 서버와 SMTP (Simple Mail Transfer Protocol) 프로토콜을 이용하여 연동한다. REST API MiddleWare는 이메일 서비스 컴포넌트가 제공하는 API를 RESTful 웹 서비스로 변환하는 역할을 수행한다. 따라서 이메일 서비스 컴포넌트는 순수하게 JAVA 클래스로 이메일 전송과 관련된 기능만을 구현한다. 대표적 REST API MiddleWare로는 Sun Jersey Rest 라이브러리와 Apache CXF 가 있다.

[pic]

6.2.1. Send mail

어플리케이션에서 간단한 이메일을 쉽게 전송하기 위한 기능을 제공한다. 메일 서버 주소 및 메일 계정 정보는 외부의 설정 파일을 통해 설정된다. 파라메터에 문법적 오류가 있는 경우나 메일 서버와의 연동시 문제가 발생한 경우 Exception을 발생시킨다. 명령어 요청 및 응답시의 파라메터는 JSON으로 기술되도록 한다.

1) Request parameters

|name |description |

|sender |보내는 사람의 이메일 주소 |

|recipientList |받는 사람의 이메일 주소 리스트 |

|referenceList |참조의 이메일 주소 리스트 |

|subject |제목 |

|text |본문 |

4) Response

없음

6.3. 단문메시지 서비스 컴포넌트

단문메시지 서비스 컴포넌트는 아래와 같은 기능을 제공한다. 단문메시지 서비스 컴포넌트는 단문메시지 전송을 위해서 외부 단문메시지 게이트웨이와 연동하며, 연동시 외부 단문메시지 게이트웨이가 제공하는 인터페이스를 따라야 한다. 외부 단문메시지 게이트웨이는 기업형 단문메시지 서비스를 제공하는 업체별로 독자적인 벙법을 사용하고 있으므로, 단문메시지 서비스 컴포넌트는 특정 외부 단문메시지 게이트웨이에 의존적이다. 본 서비스 컴포넌트는 슈어엠사가 제공하는 단문메시지 게이트웨이와 연동한다. 명령의 호출은 오퍼레이션 별로 정의된 리소스에 대한 URL에 대하여 명령어 별로 정의된 HTTP Method를 사용하여 HTTP Request를 보냄으로서 수행된다. 아래 표는 단문메시지 서비스를 위해서 정의된 리소스이고, 그림은 이를 위한 하나의 예제로서 시퀀스 다이어그램이다.

|기능명 |Resource |HTTP method |

|Send SM |CRofSMS/sc/rest/sms/ |POST |

[pic]

1. HTTP 메소드로 해당 리소스를 요청한다.

2. SMS 서버에 리소스 생성 요청을 한다.

3. SMS 서버에서 해당 정보를 보낸다.

4. 요청한 응용에게 해당 결과를 전달한다.

아래 그림은 단문메시지 서비스 컴포넌트의 상위 레벨의 구조도이다. 그림에서 보이듯이, 단문메시지 서비스 컴포넌트는 Web Container에 탑재되는 웹 모듈로 구현된다. 어플리케이션은 REST 기반 웹 서비스를 이용하여 단문메시지 서비스 컴포넌트를 사용하고, 단문메시지 서비스 컴포넌트는 단문 메시지를 전송하기 위하여 단문메시지 서비스 제공사 (슈어엠)의 SMSS(Short Message Service Server)와 TCP/IP 프로토콜을 사용하여 연동한다. REST API MiddleWare는 단문메시지 서비스 컴포넌트가 제공하는 API를 RESTful 웹 서비스로 변환하는 역할을 수행한다. 따라서 단문메시지 서비스 컴포넌트는 순수하게 JAVA 클래스로 단문메시지 전송과 관련된 기능만을 구현한다. 대표적 REST API MiddleWare로는 Sun Jersey Rest 라이브러리와 Apache CXF 가 있다.

[pic]

6.3.1. Send sms

이동통신망을 사용하는 임의의 단말에 단문메시지를 전송하는 기능을 제공한다. 명령어 요청 및 응답시의 파라메터는 JSON으로 기술되도록 한다.

1) Request parameters

|name |description |

|senderAddress |발신자의 전화번호 |

|recipientAddress |수신자 전화번호 |

|text |SM 본문 |

5) Response

|name |description |

|result |전송 결과 |

6.4. 프레즌스 서비스 컴포넌트

아래 표는 프레즌스 서비스를 위해서 정의된 리소스이고, 그림은 이를 위한 하나의 예제로서 시퀀스 다이어그램이다.

|기능명 |Resource |HTTP method |

|Get User Presence |CRofPresence/presence |POST |

|Set User Presence |CRofPresence/presence |PUT |

|Get Buddy List |CRofPresence/buddyList |GET |

[pic]

5. HTTP 메소드로 해당 리소스를 요청한다.

6. IM 서버에 리소스를 검색 및 수정 요청을 한다.

7. IM 서버에서 해당 정보를 보낸다.

8. 요청한 응용에게 해당 결과를 전달한다.

아래 그림은 프레즌스 서비스 컴포넌트의 상위 레벨 구조도이다. 프레즌스 서비스 컴포넌트는 웹 컨테이너에 탑재되는 웹 모듈로 구현한다. 애플리케이션은 REST 기반 웹 서비스를 통하여 프레즌스 서비스 컴포넌트를 사용하고, 프레즌스 서비스 컴포넌트는 프레즌스 정보를 조회 및 설정, 버디리스트를 조회하기 위해서 XMPP 프로토콜을 통하여 IM 서버와 연동한다. 웹 서비스 미들웨어는 프레즌스 서비스 컴포넌트가 제공하는 API를 REST 기반 웹 서비스로 변환하는 역할을 수행한다. 따라서 프레즌스 서비스 컴포넌트는 순수하게 Java 클래스로 프레즌스 정보 조회 및 설정, 버디리스트 조회에 관련된 기능만을 구현한다. 대표적 웹 서비스 미들웨어로는 Sun Jersey, Restlet, Apache CXF 등이 있으며, 이는 구현시 선택할 수 있다.

[pic]

6.4.1. Get User Presence

Watcher가 Presentity들의 프레즌스 정보를 가져온다.

1) Request parameters

|name |Description |

|watcherId |Watcher의 식별자 |

|watcherPw |Watcher의 비밀번호 (Password) |

|presentityId |Presentity들의 식별자 목록 |

6) Response

Presentity의 프레즌스 속성 목록

6.4.2. Set User Presence

Presentity가 자신의 프레즌스 정보를 설정한다.

1) Request parameters

|name |description |

|presentityId |Presentity의 식별자 |

|presentityPw |Presentity의 비밀번호 (Password) |

|presenceAttribute |Presentity의 프레즌스 속성 |

7) Response

없음

6.4.3. Get Buddy List

Watcher가 버디 (즉, Presentity)들의 프레즌스 정보를 가져온다.

1) Request parameters

|name |description |

|watcherId |Watcher의 식별자 |

|watcherPw |Watcher의 비밀번호 (Password) |

8) Response

Presentity 식별자와 Presentity 프레즌스 속성 목록

관련 문헌

[1] SOA4ALL, available at

[2] NEXOF, available at

[3] TMF SDF(Service Delivery Framework), available at

[4] OMA Service Provider Environment Requirements, OMA-RD-OSPE-V1_0-20090420-D, Apr. 2009.

[5] OMA Service Provider Environment Architecture, OMA-AD-OSPE-V1_0-20090420-D, Apr. 2009.

[6] Moriana Group, SDP 2.0 Service Delivery Platforms in the Web 2.0 Era

[7] Cubetree, available at

[8] Yammer, available at

[9] Facebook, available at

[10] IBM Lotus Notes, available at

[11] MS Exchange, available at

[12] Avaya UC, availale at

[13] 3CX IPPBX, available at

[14] Asterisk, available at

[15] Zimbra, available at

[16] XMPP, available at

[17] XMPP Core, available at

[18] XMPP IM & Presence, available at

[19] XMPP Service, available at

[20] OpenFire, available at

[21] OpenLDAP, available at

[22] Ucloud, available at

[23] Dropbox, available at

[24] iFolder, available at

[25] Sharepoint, available at

[26] Syncany, available at

[27] Google Docs, available at

[28] XTEN, available at

[29] Oracle Beehive, available at

[30] Huddle, available at

[31] Moxie, available at

[32] 네이버 개발자센터,

[33] 다음 개발자센터,

[34] 트위터 개발자센터,

표준 작성 공헌자

표준 번호 : TTAx.xx-xx.xxxx

이 표준의 제․개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

|구분 |성명 |위원회 및 직위 |연락처 |소속사 |

| | | |(E-mail 등) | |

|표준(과제) 제안 |민재홍 |- |jhmin@etri.re.kr |한국전자통신연구원 |

|표준 초안 작성자 |민재홍 |- |jhmin@etri.re.kr |한국전자통신연구원 |

|표준 초안 에디터 |민재홍 |- |jhmin@etri.re.kr |한국전자통신연구원 |

| |임선환 | |shlim@etri.re.kr |한국전자통신연구원 |

|표준 초안 검토 |박주영 |정보통신 프로젝트그룹 의장 |jypark@tta.or.kr |한국전자통신연구원 |

| | |외 프로젝트그룹 위원 | | |

|표준안 심의 | |정보통신 기술위원회 의장 |hgd@tta.or.kr |TTA 산업 |

| | |외 기술위원회 위원 | | |

|사무국 담당 |오구영 |- |031-724-0081 |TTA |

| | | |ohky@tta.or.kr | |

| |홍길동 |- |031-724-0000 |TTA |

| | | |hgd@tta.or.kr | |

(뒷 표지)

정보통신단체표준(국문표준)

국문 표준명

(영문 표준명)

발행인 : 한국정보통신기술협회 회장

발행처 : 한국정보통신기술협회

463-824, 경기도 성남시 분당구 분당로 47

Tel : 031-724-0114, Fax : 031-724-0019

발행일 : 20xx.xx

-----------------------

TPC

Application

Service

Component

IPPBX

1)

HTTP Method Resource URL

Authenticate

& authorize

2)

Resource Request

3)

Response

4)

HTTP Response with Result

Email

Application

Service

Component

Email

Server

1)

HTTP Method Resource URL

Authenticate

& authorize

2)

Resource Request

3)

Response

4)

HTTP Response with Result

SMS

Application

Service

Component

SMS

Server

1)

HTTP Method Resource URL

Authenticate

& authorize

2)

Resource Request

3)

Response

4)

HTTP Response with Result

Presence

Application

Service

Component

IM

Server

1)

HTTP Method Resource URL

Authenticate

& authorize

2)

Resource Request

3)

Response

4)

HTTP Response with Result

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download