서비스 제공 플랫폼

Service delivery platform

SDP(Service Delivery Platform)는 고객이든 다른 시스템이든 간에 소비자에게 제공되는 서비스 유형에 대해 서비스 제공 아키텍처(서비스 생성, 세션 제어, 프로토콜 등)를 제공하는 구성요소 집합이다. 일반적으로 통신의 맥락에서 사용되지만, 서비스를 제공하는 시스템(예: VOIP 전화, 인터넷 프로토콜 TV, 인터넷 서비스, SaaS)에 적용할 수 있다. TM Forum(TMF)이 이 분야에서 사양 정의 작업을 하고 있지만, 업계에서는 표준 정의가 없고, 참가국마다 조금씩 다른 방식으로 부품, 폭, 깊이를 정의하고 있다.

SDP는 종종 IT 기능의 통합과 기술과 네트워크 경계를 넘나드는 서비스의 창출을 요구한다. 오늘날 이용 가능한 SDP는 특정 기술 또는 네트워크 영역에서 서비스 제공에 최적화되는 경향이 있다(예: 통신에서는 웹, IMS, IPTV, 모바일 TV 등). 이들은 일반적으로 서비스 제어, 생성, 조정 및 실행을 위한 환경을 제공한다. 다시 통신에서, 이것은 미디어 제어, 존재/위치, 통합 및 기타 낮은 수준의 통신 기능을 위한 추상화를 포함할 수 있다. SDP는 소비자 및 비즈니스 애플리케이션 모두에 적용된다.

통신의 맥락에서만, SDP를 구현하는 사업 목표는 기본 POTS 전화 서비스에서 멀티플레이어 비디오 게임(MPG)을 위한 복잡한 오디오/비디오 회의까지 새로운 통합 멀티미디어 서비스의 신속한 개발과 배치를 가능하게 하는 것이다. SaaS의 맥락에서 유사한 비즈니스 목표를 달성하지만 특정 비즈니스 영역에 특정한 맥락에서 달성된다.

애플의 아이폰, 구글 안드로이드 스마트폰과 같은 기기들을 위한 애플리케이션을 만들고, 호스팅하고, 전달하기 위한 애플리케이션 스토어의 등장은 데이터로부터 수익을 창출하는 통신 서비스 제공업체(CSP)의 수단으로서 SDP에 초점을 맞추었다.[1] SSP를 사용하여 웹 2.0 개발자를 포함한 내부 및 외부 개발 커뮤니티에 네트워크 자산을 노출함으로써 CSP는 수천 개의 애플리케이션과 개발자의 라이프사이클을 관리할 수 있다.[2][3]

텔코디아 테크놀로지스, 노텔, 아바야, 에릭슨, 알카텔루센트 등 통신회사들은 1990년대 초반부터 중반까지 통신 통합 인터페이스와 인프라를 제공해 왔다. IP 기반 VoIP 시스템이 독점적 개인 지점 교환(PBX) 시스템과 데스크탑 전화의 대체로서 비용 절감에 성공함에 따라 독점적 시스템에서 개방적인 표준 기술로 업계의 초점이 전환되었다.

이러한 개방형 환경으로의 변화는 텔리젠트 텔레콤과[4] 같은 소프트웨어 중심 통신 회사들을 끌어들였고, 티에토, 액센츄어, IBM, TCS, HP, 알카텔 루센트, 테크 마힌드라, 인포시스, 위프로, CGI와 같은 시스템 통합업체들이 통합 서비스를 제공할 수 있게 했다. 또한, 통신 소프트웨어 제품 기업의 새로운 컨소시엄은 부가 가치 서비스, 융합 청구, 컨텐츠/파트너 관계 관리 등 요소를 기반으로 한 SDP를 창출하기 위한 사전 통합 소프트웨어 제품을 제공한다.

SDP는 기술 경계를 넘을 수 있기 때문에 다음과 같은 다양한 혼합 애플리케이션이 가능해진다.

  • 사용자는 텔레비전 화면에서 수신 전화(와이어라인 또는 무선), IM 친구(PC) 또는 친구(GPS Enabled Device)를 볼 수 있다.
  • 사용자는 휴대전화에서 VoD(온디맨드 비디오) 서비스를 주문하거나 가정과 휴대전화용 비디오 패키지로 주문한 스트리밍 비디오를 시청할 수 있다.
  • 항공사 고객은 자동 시스템으로부터 항공편 취소와 관련된 문자 메시지를 받고 음성 또는 대화형 셀프 서비스 인터페이스를 사용하여 일정을 변경할 수 있음

역사

1990년대 후반에는 클라이언트-서버 아키텍처의 장악력이 점차 완화되고 n계층 아키텍처의 진입이 가능해지면서 엔터프라이즈 애플리케이션에서 전례 없는 변화를 겪었다. 이는 애플리케이션 서버의 출현을 나타냈는데, 이는 멍청한 단말기의 절대성과 논리 집약적인 클라이언트 PC 사이의 유연한 타협이다. 애플리케이션 서버 링의 진입자는 많고 다양했지만 데이터베이스 벤더 추상화, 개방형 표준(대부분 객체 지향) 프로그래밍 모델, 고가용성 및 확장성 특성, 프레젠테이션 프레임워크 등 공통의 장점을 공유했다. 이러한 변화들은 인터넷 붐이었던 급증하는 해일을 포함한 비즈니스 힘에 의해 촉발되었지만, TCP/IP 프로토콜, 자바 프로그래밍 언어, 자바 EE 웹 애플리케이션 서버 아키텍처와 같은 표준의 확산이 없었다면 그 어느 것도 불가능했을 것이다. 통신의 급속한 변화의 시대가 시작된 것은 이러한 변화의 배경이다.

2000년 처음 몇 년 전까지 상업용 및 사업용 통신 기술 시장은 여전히 독점적인 하드웨어와 소프트웨어로 포화 상태에 있었다. 개방형 표준은 IP 기술이 도입되고 패킷 네트워크를 통한 음성 데이터 전송을 위한 VoIP(Voice-over-IP)와 특히 기업 음성 통신과 관련하여 표준화된 미디어 제어를 위한 SIP(Session Initiation Protocol)가 급속도로 확대되면서 대중화되기 시작했다.

이 새로운 표준 지원 환경에서, 음성 및 데이터 세계의 융합은 재앙적인 통신에 대한 모니커(moniker)가 되지 않았다.IT 통합이 시도되고 더 나은 새 소비자 및 비즈니스 서비스를 생산하기 위한 진정한 길이 열린다. 지난 몇 년 동안 다양한 SIP 프로그래밍 라이브러리(ReSIProcate, Aricent, MjSip 및 HSC에 의한 파생 포트)와 비교적 새로운 SIP 표준에 기반한 제품들이 도입되거나 확산되었으며, 3GPP가 정의한 IP 멀티미디어 서브시스템 표준은 다음과 같은 큰 성과를 거두었다. 이러한 지원 표준의 품질과 수용에서 큰 부분을 차지하는 서비스 제공 플랫폼은 광범위하게 적용되는 아키텍처 패턴으로 빠르게 받아들여지고 있다.

오늘날 업계에서는 서비스 제공 플랫폼(SDP)에 대한 여러 정의가 공통적인 의미에 대해 확립된 합의 없이 사용된다. 이 때문에 서비스 제공업체들이 SDP를 보다 잘 관리할 수 있는 방법을 이해해야 하는 필요성 때문에 TMF(TMF)는 SDF(Service Delivery Framework)와 SDF 관리 개념 표준화 작업에 착수했다. SDF 정의는 애플리케이션 및 에너블러, 네트워크 및 서비스 노출, 조정 등과 같이 관련된 다양한 구성요소를 참조하는 데 필요한 용어와 개념을 제공한다.

여러 SDP에서 최종 사용자에게 개인화된 서비스를 혼합하여 제공하기 위해 필요한 것은 공통 서비스 제공자와 네트워크 리소스를 통해 이러한 SDP를 상호 연동하는 수단이다. 그러나 이러한 서비스 측면을 뒷받침하는 것은 사용자의 속성과 그들이 받는 서비스가 LDAP/X.500 디렉토리 또는 HSS 데이터베이스에 의해 제공되는 것과 같은 공통의 데이터 모델과 공통의 리포지토리가 필요하다는 기본 개념이었다. 이러한 성격의 초기 SDP 구현은 ISP 융합 서비스를 위해 1990년대 중후반부터 시작되었다. MSO 유형 환경과 이동 통신사를 위해 지난 5년 동안 더 크고 더 복잡한 SSP가 구현되었다.

컨텍스트

SSP는 일반적으로 고객의 액세스 및 네트워크 인프라를 OSS 시스템 및 BSS 시스템과 상호 연결하는 핵심 시스템으로서 통신사형 환경에 대해 검토되고 있다. 이러한 맥락에서 SDP는 일반적으로 이동전화와 같은 특정 서비스 체제 또는 통합 서비스와 관련된다.

SDP는 또한 상당한 예산이 필요한 매우 큰 변환, 융합 및 통합 프로그램의 맥락에서 고려된다. 그러한 프로젝트의 어려움은 일단 아키텍처가 합의되면 수십만 건의 설계와 구현 결정이 내려질 수 있다는 것이다. 당연히 이 문제만으로도 소프트웨어 개발과 운영 엔지니어링 기술의 필요성이 결정된다. 아마도 이러한 설계 및 통합 문제를 줄이는 가장 좋은 방법은 주요 프로젝트가 실제로 시작되기 전에 소규모 시스템에서 SDP를 시뮬레이션하는 것일 것이다. 이를 통해 아키텍처가 운영, 서비스 제공 및 비즈니스 요구사항을 충족하는지 검증할 수 있다.

또한 SDP는 단순히 운영자 내의 핵심 기능으로서가 아니라 중복성 이유와 상이한 비즈니스 및 시장 부문에 대한 상이한 서비스 프로파일의 상호연결된 다수의 분산 서비스 노드(예:)로서 고려되어야 한다. 많은 사업자는 정부 및 기업 고객에게 번들 음성, 웹 호스팅, VPN, 메일, 회의 및 메시징 시설과 같은 상업적 규모/등급 제품을 제공한다. 이러한 번들 서비스의 진화는 단편화된 관리 시스템에서 "가상 사설 서비스 환경"으로 발전할 수 있으며, 운영자는 자신의 요구에 따라 그리고 통제하에 자신의 서비스를 필요로 하는 각 고객을 위해 전용 SDP를 운영할 수 있다.

또한 SDP는 쇼핑몰, 공항, 퇴직자 마을, 아웃케어 센터와 같은 독립적인 무선 지원 구역을 관리하는 데 사용될 수 있다.

요소들

서비스 생성 환경

종종 통신 소프트웨어 개발자의 1차 액세스 포인트인 서비스 생성 환경(SCE, 또한 애플리케이션 생성 환경 또는 통합 개발 환경)은 개발자가 노출될 서비스를 대표하는 소프트웨어, 스크립트 및 리소스를 생성하기 위해 사용된다. 이러한 애플리케이션은 기본 Eclipse 플러그인에서 완전히 추상화된 메타데이터 기반의 통신 애플리케이션 모델링 애플리케이션(Avaya의 단종된 CRM Central 제품 등)에 이르기까지 복잡성이 다양할 수 있다.

SCE의 목적은 새로운 통신 서비스의 신속한 창출을 촉진하는 것이다. 당분간 마케팅과 같은 요인을 무시한 채, 개발자들이 특정 플랫폼에 대한 서비스를 쉽게 만들수록, 이용 가능한 서비스의 수는 더 많을 것이고, 따라서 더 넓은 통신 시장에 의한 플랫폼의 수용은 더 커질 것이다. 그러므로 통신 인프라 제공자는 신속한 서비스 창출을 제공하는 SDP를 통해 상당한 이점을 얻을 수 있다.

통합 Java EE 및 SIP 서비스 생성 환경의 활용은 서비스 제공 플랫폼의 채택을 가속화했다. 자바 기반의 애플리케이션 개발자들은 전통적으로 IT 애플리케이션에 초점을 맞추었으며, 자바 EE를 이용한 실시간 통신 애플리케이션과 SIP, Parlay X 웹 서비스와 같은 네트워크 연결 프로토콜을 개발한다. 소프트웨어 벤더는 이러한 기술(예: Oracle Jdeveloper 및 Oracle Communication and Mobility Server와 기본 Eclipse 플러그인)을 결합하여 보다 광범위한 개발자 기반에 접근하고 있다.

실행환경

서비스 실행 환경(SEE)은 SCE에서 개발된 통신 서비스를 실행하는 데 사용된다. 실행 환경은 일반적으로 특정 서비스가 실행될 것으로 예상되는 하드웨어를 모방하도록 설계된다. 참조는 IDE로 SCE와 함께 번들로 제공될 수 있다.

미디어 컨트롤

존재 및 위치

SDP의 한 측면은 그것이 새로운 "존재 지점"에 집중되어야 한다는 것이다. 이는 사용자의 선호도와 자격을 실시간으로 평가하는 융합형 서비스에 대한 사용자 접근 지점이다. 선호도와 권리처리는 기기/위치 컨텍스트에서 사용자의 서비스가 올바르게 제공되도록 보장한다. 자격은 사업자의 제품 및 서비스 관리 제도와 관련되므로, SDP의 핵심 아키텍처는 관리되는 제품, 서비스, 사용자, 선호도 및 자격 부여 프로세스를 정의해야 한다.

표준의 구현은 존재감 애플리케이션에서 여전히 중요한 요소로 남아 있다. SIP와 SIMP(Instant Messaging and Presence Utilizing Extensions)와 같은 표준의 구현이 점점 더 보편화되고 있다. SIMPLE Presence는 SIMP 클라이언트(Watcher)와 Presence 서버(Presence Agent) 간에 존재 정보를 조작할 수 있는 표준 휴대용 보안 인터페이스를 제공한다. 단순 존재는 JSR 164를 참조하십시오. SIMPLE Presence 서버 제공업체에는 Oracle과 Italtel이 포함된다.

통합

SDP 전체와 SDP 내의 인터페이스에 대한 노출 표준을 사용하면 (1) CRM, 과금 및 서비스 활성화(3) 제3자 애플리케이션과 서비스와 같은 지원 애플리케이션 사이의 기본 네트워크 핵심 구성 요소에 대한 남향(2)의 통합 필요성을 최소화해야 한다. 서비스 지향 아키텍처(SOA)의 구현은 표준 인터페이스와 웹 서비스를 사용할 수 있다.

소프트웨어 벤더에는 HP, wwite, IBM, Oracle 및 Sun 마이크로시스템이 포함된다. 네트워크 장비 공급업체들은 또한 IMS, IPTV, 모바일 TV 등과 같은 SDP를 제공하고 이러한 SDP의 진화를 제공한다.

SOA와의 관계

서비스 지향 아키텍처(SOA) 개념의 최근 몇[when?] 년간 많은 것이 이루어졌다. 한때 엔터프라이즈 애플리케이션 통합(EAI) 기술과 개념을 중심으로 진행되던 논의가 SOA 영역으로 전환되면서 단순한 메시지 적응 및 추출, 변환, 로드 기법보다 서비스 구성과 같은 아이디어를 선호하게 되었다.

SOA는 SDP 내에서 애플리케이션 통합 기술로 사용될 수 있지만 트랜잭션 OSS와 BSS 애플리케이션과 SDP 사이의 연결과 같은 낮은 성능 기능에 사용될 때 가장 잘 사용된다. SOA는 통합 이벤트 유형 서비스에 의해 SDP에 배치된 실시간 요구를 충족하려면 신중한 검토가 필요하다.

SOA 영역에서 발견된 SDP에 대한 아날로그 개념은 웹 서비스 에코시스템(웹 서비스 마켓플레이스라고도 함)과 SaaS 플랫폼이다. 웹서비스 생태계는 참여자들이 HTTP, XML, SOAP, REST와 같은 공통 웹 기술을 사용하여 자신의 서비스를 노출하는 호스트 환경이다. 이 호스트 환경은 인증, 신원 관리, 사용량 측정 및 분석, 콘텐츠 적응, 데이터 형식 변환, 충전 및 결제와 같은 측면을 다루는 다수의 서비스 제공 구성요소를 제공한다. 이를 통해 서비스 제공업체는 핵심 기능에 초점을 맞추고 서비스 제공을 제3자에게 아웃소싱할 수 있다. 웹 서비스 에코시스템에 구축된 서비스는 비즈니스에 중요할 수 있지만, 일반적으로 SDP가 전통적으로 구상되는 통신 서비스와 관련된 실시간 및 고성능 요구사항은 없다. 그들은 보통 견적, 주문 관리, 마케팅 캠페인 관리 또는 고객 관리와 같은 일반적인 비즈니스 기능을 지원한다. SOA는 또한 운영 프로세스를 표준화하고 이를 SDP 전체에 걸쳐 재사용하는 데 사용될 수 있다.

SDP 구현

실시간 통합 서비스, 운영 중인 SDP를 구현하려면 IT 및 네트워크 아키텍처에 상당한 변화가 필요하다. 많은 SDP는 "서비스 추상화 계층" 등과 같은 라벨을 사용하는 도표를 가진 추상 프레임워크로 설계된다. 실제 시스템 내에는 그러한 "레이어"가 실제로 존재하지 않는다. 또한 추상 다이어그램에서 실제 운영 데이터 모델이 무엇이며, 통합 서비스 SDP와 자가 관리 기능을 형성하기 위해 얼마나 많은 서버, 데이터베이스 또는 디렉토리를 사용하거나 통합할 수 있는지 파악하기는 어렵다. 운영자들은 연간 수백만 달러의 전기요금에 직면할 수 있다. 동일한 기능을 통합하여 훨씬 적은 전력을 사용할 수 있다면 다중 서버/다중 데이터베이스 SDP는 지구 친화적이거나 비용 효율적이지 않다는 점에 따른다.

ID 및 정보 관리: SDP를 지정하거나 설계하기 위해 우리는 고객과 장치 서비스 차원이 무엇인지 결정해야 한다. 예를 들어, SDP 설계가 1m 사용자를 수용하고 기기를 관리해야 하며 각각의 식별된 항목에 5~10개의 정보 객체가 필요한 경우, 핵심 SDP는 아마도 20m 객체를 실시간으로 처리하고 있을 것이다. 이러한 객체의 관리는 플랫폼의 핵심 ID 관리 프로세스를 좌우하므로, 이들 객체의 구현 방식에 중대한 주의를 기울여야 한다. 경험에 따르면 융합형 서비스 SDP의 단일 사용자는 100개의 속성을 포함하는 기본 설정과 같은 일부 객체를 가진 100개의 정보 객체를 요구할 수 있다. 10m 사용자의 용량 요구사항은 플랫폼이 10억 개 객체와 최대 500억 개 속성을 지원해야 함을 나타낼 것이다.

그룹 ID 및 자격: 전통적으로 당사는 이름과 비밀번호로 로그온하는 단일 사용자 또는 장치로서 ID 관리를 다루었으며, 이름과 비밀번호를 보유한 ID 서버가 문제를 해결한다고 가정해 왔다. MSO 세계에서는 실질적으로 계좌 보유자, 2차 계좌 보유자(가족의 자녀), 손님, 선물, 콘텐츠, 기기, 선호도를 가지고 있는데 관리 서비스를 받기 위해서는 모두 함께 연결해야 한다. 그룹화된 ID가 수신하는 서비스는 이름과 암호를 통해 인증될 수 있지만 제품 프로비저닝과 관련된 사용 권한을 통해서만 활성화해야 한다. SDP 아키텍처는 그룹 ID 관리 및 제품/서비스 자격 부여 기능을 수용해야 한다.

존재 및 이벤트: 존재는 모든 온라인 자산의 상태 관리. 그러나 이것은 시스템 아키텍처에 무엇을 의미하는가? 전통적으로 우리는 사용자가 로그온하여 네트워크 스위치, 웹 서버 또는 데이터베이스 애플리케이션에 트랜잭션을 생성하는 "트랜잭션" 패러다임을 적용해왔다. 프레즌스 서비스는 우리가 우리의 전통적인 거래 시스템보다 훨씬 더 높은 비율로 상태 이벤트를 관리하고 있다는 것을 의미한다. 문제는: 수백만의 이벤트가 조각난 시스템, 다중 데이터베이스 아키텍처 또는 사실 프레임워크에서 어떻게 관리되고 있는가? 또한 SDP 아키텍처는 핵심 기능으로 일관성 있고 고도로 통합된 이벤트 관리 시스템을 가져야 한다.

통합 ID: 3G IMS, SIP 및 통합 서비스와 함께 운영상의 문제가 대두된다. SIP는 수신, 발신, 비아 및 연락처 필드에 IP 주소(IPv4 또는 v6), SIP URI(전자 메일 주소) 및 SIP TEL URI(전화 번호)를 적용할 수 있다. 그러한 식별자는 전화기, 냉장고 문, 컨텐츠 농장, 단일 컨텐츠 조각, 사용자 또는 심지어 사용자 그룹을 가리킬 수 있다. 이러한 유연성은 SIP 호출을 할 자격이 있는 경우 SIP 호출을 거의 모든 것에서 다른 것으로 할 수 있다는 것을 의미한다. SIP는 이러한 인터넷과 전화 시스템 식별자를 통화 프로세스에 혼합하여 적용할 수 있으므로, SDP는 자신의 SIP 처리를 DHCP/DNS 시스템, HSS 모바일 데이터베이스, 사용자 인증 시스템, 프레즌스 이벤트 시스템, 사용자의 주소록, 전화 통화 기능 처리 및 운영자의 권한과 긴밀하게 결합해야 한다. 서비스/제품 관리(모든 것을 실시간으로 사용 가능). 그러한 기능성은 "SOA"를 사용하여 여러 상호연결된 기능과 단편화된 데이터베이스에 걸쳐 적용하기가 매우 어려울 것이라는 것을 따른다.

SDP 기술 및 툴 키트는 다음과 같은 세 가지 기본 문제를 해결해야 한다.[citation needed]

  1. 사업자와 고객자율관리시스템에 의해 실시간 방식으로 제공 및 관리되는 재화와 서비스는 무엇이며, 여기에는 존재 기반 서비스(이벤트 기반 인터넷의 세계)의 관리와 실시간 사용자 자격이 어떻게 처리되는지가 포함된다.
  2. 가입자, 기기, 전화, 선호도, 자격, 주소록 등을 취급하는 사업자의 온라인 비즈니스를 나타내는 SDP 설계에 사용되는 융합형 서비스 정보 모델은 무엇인가? 많은 경우 1,000만 고객만을 보유한 MSO는 5억 개의 정보 항목이 포함된 SSP를 필요로 하며, 이러한 항목에 대해서는 많은 다른 SSP 기능으로 초당 수천 번 액세스해야 한다.
  3. 온라인 비즈니스 이벤트의 속도를 처리하는 SDP 설계에서 사용되는 이벤트/존재 관리 아키텍처는 무엇인가? 밤에 집에 도착하는 도시의 인구가 수십억 개의 온라인 상태 이벤트를 발생시킬 수 있는 상황일 수 있다. 이러한 것들은 SDP에 의해 어떻게 처리될 것인가?

이 세 가지 주요 시스템 요건은 논리 모델, SOA, 메시지 버스 프로토콜 및 서버 상호 연결에 적용되는 "추상적인 라벨"과 무관하게 실제로 실제 운영 중인 SDP의 아키텍처를 지시한다. 만약 이러한 기본적인 요구사항이 SDP 설계에서 누락된다면, 그것은 사업시행자에게 다음과 같은 많은 사업, 서비스 관리 및 운영상의 문제를 야기한다.

  • ID 관리(운영자를 나타내는 SDP의 모든 정보 중 온라인 자산)
  • SDP의 서비스 민첩성(즉, 제공되는 제품과 서비스는 새로운 서비스가 코드 업그레이드를 유발하도록 SDP에 하드 코딩됨) 및
  • 유선 자가 관리 시설(언어, 연령, 시각, 선호 등 SDP 사용자의 유연성 또는 고려 없음)

어떤 상황에서는 MSO가 수백만 라인의 하드 코드 제품 및 서비스 관리 흐름을 시스템에 가지고 있으며 새로운 통합 서비스 차원으로 쉽게 이동할 수 없다.

SDP 설계의 빠른 테스트는 정보 모델을 평가하고 그것이 융합된 서비스의 사용자 환경에 기초하는지, 그리고 그 모델이 존재와 이벤트 관리 기능을 포함해야 하는 모든 시스템에 의해 어떻게 사용되고 관리되는지 확인하는 것이다.

SDP 개발 지원과 실시간, 신속한 변화를 위한 서비스 제공, 차세대 시스템을 고려해야 한다[citation needed].

참고 항목

참조

  1. ^ Connected Planet Online: "SDP 퍼즐 해결" 리치 카르핀스키 2008년 6월. 2010-03-17 검색됨 웨이백 머신에 보관된 2010-05-13
  2. ^ TechTarget: SOA 뉴스. "애플을 체싱하면서 HP는 앱스토어 팩으로 통신사를 공략한다." 롭 베리. 2009년 9월. 검색된 2010-03-17
  3. ^ 2010년 3월 8일. "모바일 광고, 앱스토어 중심으로 2014년까지 46억 달러 돌파할 서비스 제공 플랫폼 시장
  4. ^ 인포네틱스 보도 자료. 통신사들은 2007년 57억 달러를 외주 서비스에 썼다. 2008년 5월. 2010-03-18 검색됨