KR20080023695A

KR20080023695A - 메시지를 이용하여 ｃｒｍ 기능성을 확장하는 방법

Info

Publication number: KR20080023695A
Application number: KR1020077030120A
Authority: KR
Inventors: 아라쉬 가나이-시채니; 알렉산더 트캐치; 케빈 엠. 화이텐버거; 마이클 제이. 오트; 마이클존 밀러
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-07-01
Filing date: 2006-06-30
Publication date: 2008-03-14
Also published as: WO2007005849A2; WO2007005849A3; CN101213572B; JP5174661B2; US7669205B2; EP1899910A2; JP2009500753A; CN101213572A; EP1899910A4; US20070006237A1; KR101203284B1

Abstract

CRM 프로그램에서 API의 기능성을 확장하는 방법 및 그러한 방법을 구현하는 시스템이 개시된다. 본 방법은 사용자로 하여금, CRM 웹 서비스 모듈로서 노출될 수 있는 하나의 인터페이스를 이용하여 송수신되는 요청과 응답 메시지들을 이용해서, 앞서 정의된 클래스들을 확장함으로써 새로운 비즈니스 논리 및 연산들을 생성할 수 있게 한다.

CRM, API, 확장, 기능성, 비즈니스 논리, 비즈니스 연산, 클래스

Description

메시지를 이용하여 ＣＲＭ 기능성을 확장하는 방법{USING MESSAGES TO EXTEND CRM FUNCTIONALITY}

통상적 비즈니스 애플리케이션들은 많은 수의 비즈니스 엔티티들을 포함할 수 있고 비즈니스 논리에 기초하여 이들 엔티티 상에서 다양한 연산들을 수행할 수 있다.

이러한 애플리케이션들은, 이들 엔티티와 관련된 비즈니스 논리에 대한 액세스와 실행을 가능하게 하는 애플리케이션 프로그래밍 인터페이스(API)를 제공한다. 비즈니스 애플리케이션에서는 상호 운용가능성(interoperability)이 매우 중요한 요구사항이기 때문에, 웹 서비스 기술이 API들을 설계하는데 이용될 수 있다. API의 소비자들은 API의 시그니쳐(signature)에 의존하고 API에 대해 그 수명 동안 변경이 발생했을 때 영향을 받는다. 그와 같은 애플리케이션들에 존재하는 비즈니스 엔티티들의 수에 비례하여, 비슷하게 많은 수의 정적 연산들(메소드들)이 정의되고 API를 통하여 이용 가능하게 된다.

CRM 프로그램에서 API의 기능성을 확장하는 방법 및 그러한 방법을 구현하기 위한 시스템에 관하여 기술한다. 본 방법은 사용자로 하여금 CRM 웹 서비스 모듈과 주고받는 요청 및 응답 메시지를 이용하여, 하나의 API 인터페이스를 통하여, 그리고 이미 정의된 클래스들을 확장함으로써, 새로운 비즈니스 논리 및 연산들을 생성하도록 할 수 있다. 각 카테고리에 의해 지원되는 비즈니스 연산들에 기초하여 비즈니스 엔티티들을 카테고리별로 분류함으로써 타겟 베이스 클래스들이 생성되는데, 어떤 비즈니스 엔티티들이 어떤 연산들을 지원하는지를 판정하기 위하여 타겟 클래스 계층구조(hierarchy)가 검토될 수 있다.

도 1은 본 발명에 따라 동작할 수 있는 컴퓨팅 시스템의 블록도.

도 2는 비즈니스 애플리케이션의 사용자들로 하여금 비즈니스 논리를 실행하고 메시지들을 통하여 비즈니스 연산 및 데이터를 액세스하도록 할 수 있는, 메시지 지향 API의 예를 도시한 도면.

도 3은 메시지 중심 접근법의 개념을 도시한 도면.

도 4는 실행(Excute) 메소드와 함께 이용되는 요청(Request) 및 응답(Response) 메시지들의 클래스 계층구조를 도시한 클래스 구조도.

도 5는 메시지들을 이용하여 CRM 시스템 내에서 애플리케이션 프로그래밍 인터페이스의 기능성을 확장하는 방법을 도시한 도면.

도 6은 두 가지 예에 관한 타겟 클래스(Target class) 계층구조를 도시한 도면.

다음 내용은 다양한 많은 실시예들에 관한 상세한 설명을 기술하고 있지만, 본 명세서의 법적 범위는 본 명세서 말미의 특허청구범위에 기재된 단어들에 의해 정의된다는 점을 알아야 한다. 가능한 모든 실시예들을 기술하는 것은, 불가능하지는 않더라도 사실상 비현실적이기 때문에, 발명의 상세한 설명에 기재된 사항은 단지 예시적인 것으로 해석되어야 하고 모든 가능한 실시예를 나타내는 것은 아니다. 현재의 기술 또는 본 특허출원 이후 개발되는 추후의 기술을 이용하여, 특허청구범위에 속하는 많은 다른 형태의 실시예들이 구현될 수 있다.

어떤 용어가 "본 명세서에서 이용되는 용어 '__________'는 ...을 의미하도록 정의된다"와 같은 류의 문장을 이용하여 본 명세서 중에 명확하게 정의되지 않는다면, 명시적으로나 묵시적으로나, 그 용어가 갖는 평범하고 통상적인 의미를 넘어서, 해당 용어의 의미를 제한하려는 의도가 전혀 없으며, 그와 같은 용어는 (특허청구범위의 표현 이외에) 본 명세서 내 임의의 섹션에 포함된 임의의 문장에 기초하여 그 범위가 제한되는 것으로 해석되어서는 안 된다. 본 명세서의 말미에 배치된 특허청구범위에서 사용된 임의의 용어가 하나의 의미로 일관성을 갖고 본 명세서 내에서 사용되었다면, 이는 단지 독자를 혼란시키지 않기 위하여 명확함을 위하여 그와 같이 사용된 것이고 해당 청구항 용어가 암시적으로든 어떤 식으로든 그 하나의 의미로 제한되도록 하고자 의도된 것은 아니다. 마지막으로, 청구항 구성요소가 어떤 구조에 관한 언급이 없이 기능과 "수단"이라는 단어로써 정의되지 않았다면, 청구항 구성요소의 범위가 미국 특허법 35 U.S.C. 112조, 여섯번째 단락의 적용에 기초하여 해석되도록 의도된 것은 아니다.

도 1은, 특허청구범위의 방법의 단계들을 위한 시스템 및 장치가 구현될 수 있는 적합한 컴퓨팅 시스템 환경(100)의 일 예를 도시한 도면이다. 컴퓨팅 시스템 환경(100)은 단지 적합한 컴퓨팅 환경의 일 예일 뿐이며, 특허청구범위의 장치에 의한 방법의 기능성이나 사용의 범위에 관한 어떠한 제한사항을 제안하고자 의도된 것은 아니다. 컴퓨팅 환경(100)은, 예시적인 운영 환경(100)에서 예시된 컴포넌트들 각각이나 이들의 조합에 관한 어떠한 의존이나 요구사항을 갖는 것으로 해석되어서는 안 된다.

특허청구범위 방법의 단계들과 장치는 많은 다른 범용 또는 특수목적 컴퓨팅 시스템 환경들 또는 구성들과도 동작 가능하다. 특허청구범위의 방법들이나 장치들과 함께 이용하기에 적합할 수 있는, 주지의 컴퓨팅 시스템, 환경 및/또는 구성들의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드나 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서 기반형 시스템, 셋톱 박스, 프로그래머블 소비자 전자장치, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전술한 시스템들이나 장치들 중 하나 이상을 포함하는 분산형 컴퓨팅 환경, 기타 등등을 포함할 수 있고, 다만 이로써 제한되는 것은 아니다.

특허청구범위 방법의 단계들 및 장치는, 컴퓨터-실행가능 명령어들, 예컨대 컴퓨터에 의해 실행되는 프로그램 모듈들의 일반적 문맥에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정한 태스크를 수행하거나 특정한 추상 데이터 타입을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 방법 및 장치는 또한, 통신 네트워크를 통하여 링크된 원격 프로세싱 장치들에 의하여 태스크가 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈들은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체 양자 모두에 배치될 수 있다.

도 1을 참조하면, 특허청구범위 방법의 단계들과 장치를 구현하기 위한 예시적 시스템은 컴퓨터(110) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은, 프로세싱 유닛(120), 시스템 메모리(130), 그리고 시스템 메모리를 포함한 다양한 시스템 컴포넌트들을 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)를 포함할 수 있지만, 이로써 제한되는 것은 아니다. 시스템 버스(121)는 메모리 버스나 메모리 제어기, 주변 버스, 그리고 임의의 다양한 버스 아키텍처를 이용하는 로컬 버스를 포함한, 다양한 타입의 버스 구조들 중 하나일 수 있다. 예로서, 그와 같은 아키텍처로는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, 인핸스드 IS(EISA) 버스, VESA(Video Electronic Standards Association) 로컬 버스 및 메자닌(Mezzanine) 버스라고도 알려진 PCI(Peripheral Component Interconnect) 버스 등을 포함하지만, 이로써 제한되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 가용 매체일 수 있고, 휘발성 및 비휘발성 매체 양자 모드를 포함하고, 비이동식(nonremovable) 및 이동식(removable) 매체를 모두 포함한다. (제한이 아니라) 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는, 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈이나 기타 데이터 등과 같은 정보의 저장을 위하여 임의의 방법이나 기술로써 구현된 휘발성 및 비휘발성, 비이동식 및 이동식 매체를 모두 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리나 기타 메모리 기술, CD-ROM, DVD(Digital Versatile Disks)나 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치나 기타 자기 저장 장치들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 기타 매체를 포함하지만, 이로써 제한되는 것은 아니다. 통신 매체는 통상적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를 반송파나 기타 전송 메카니즘 등의 변조형 데이터 신호 형태로 구현하고 임의의 정보 전달 매체를 포함한다. "변조형 데이터 신호"라는 용어는 신호로서 해당 신호에 정보를 인코딩하는 방식으로 변경되었거나 특성 세트(characteristics set) 중 하나 이상의 특성을 갖는 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크나 직접-유선 접속 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함한다. 전술한 것들 중 하나 이상으로 구성된 조합들도 역시 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 예컨대 스타트업 동안에, 컴퓨터(110) 내부의 소자들 간에 정보 전달을 돕는 기본 루틴들을 포함하는 기본 입출력 시스템(basic input/output system: BIOS)(133)이 ROM(131)에 저장된다. RAM(132)은 통상적으로 즉시 액세스 가능하고 그리고/또는 처리 유닛(120)에 의해 바로 조작될 수 있는 데이터 및/또는 프로그램 모듈을 저장한다. 제한이 아니라 예로서, 도 1은 운영체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시하고 있다.

컴퓨터(110)는 또한 기타 비이동식/이동식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1은 이동식, 비휘발성 자기 매체로부터 판독하고 그에 대해 기록하는 하드디스크 드라이브(140), 비이동식, 비휘발성 자기 디스크(152)로부터 판독하고 그에 대해 기록하는 자기디스크 드라이브(151), 그리고 비이동식, 비휘발성 광디스크(156), 예컨대 CD ROM이나 기타 광 매체로부터 판독하고 그에 대해 기록하는 광디스크 드라이브(155)를 도시하고 있다. 이러한 예시적 동작 환경에서 이용될 수 있는 기타 다른 비이동식/이동식, 휘발성/비휘발성 컴퓨터 저장 매체로는, 자기테이프 카세트, 플래시메모리 카드, DVD(Digital Versatile Disc), 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등이 포함될 수 있지만, 이로써 제한되는 것은 아니다. 하드디스크 드라이브(141)는 통상 인터페이스(140) 등의 이동식 메모리 인터페이스를 통하여 시스템 버스(121)로 연결되고, 자기디스크 드라이브(151) 및 광디스크 드라이브(155)는 통상 인터페이스(150) 등의 비이동식 메모리 인터페이스에 의하여 시스템 버스(121)로 연결된다.

도 1에 도시되고 앞서 논의된 드라이브들과 그 관련 컴퓨터 저장 매체들은 컴퓨터(110)를 위한 컴퓨터 판독가능 명령어들, 데이터 구조들, 프로그램 모듈들 및 기타 데이터들의 저장 공간을 제공한다. 도 1에서는, 예컨대, 하드디스크 드라이브(141)가 운영체체(144), 애플리케이션 프로그램(145), 기타 프로그램 모 듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시되어 있다. 이들 컴포넌트들은 운영체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 같은 것일 수도 있고 다른 것일 수도 있다는 점에 유의해야 한다. 운영체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈들(146) 및 프로그램 데이터(147)에는, 최소한 이들이 별도의 카피본이라는 점을 나타내기 위하여 서로 다른 참조부호가 주어졌다. 사용자는 키보드(162)와, 보통 마우스, 트랙볼 또는 터치패드 등으로 불리는 지정 장치(161) 등의 입력 장치를 통하여 컴퓨터(20)에 명령과 정보를 입력할 수 있다. 이와 다른 입력 장치(도시되지 않음)로는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너 등이 포함될 수 있다. 이들 및 기타 입력 장치들은 종종 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통하여 처리 유닛(120)으로 연결되지만, 병렬 포트, 게임 포트 또는 범용 직렬 버스(USB) 등의 기타 인터페이스 및 버스 구조에 의하여 연결될 수도 있다. 모니터(191)나 기타 다른 타입의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통하여 시스템 버스(121)에 연결된다. 모니터에 더하여, 컴퓨터는 또한, 출력 주변 인터페이스(190)를 통해서 연결될 수 있는 스피커(197)와 프린터(196) 등의 기타 주변 출력 장치들도 포함할 수 있다.

컴퓨터(110)는 하나 이상의 컴퓨터들, 예컨대 원격 컴퓨터(180)로의 논리 접속을 이용하는 네트워크형 환경에서 동작할 수 있다. 원격 컴퓨터(180)는, 개인용 컴퓨터, 서버, 라우터, 네트워크 PC, 피어-장치 또는 기타 공통 네트워크 노드일 수 있고, 도 1에서는 메모리 저장 장치(181)만이 도시되어 있지만, 대개는 컴퓨 터(110)와 관련하여 앞서 기술된 구성요소들 전체 또는 그 중 많은 수의 구성요소들을 포함할 수 있다. 도 1에 도시된 논리적 접속은 LAN(171)과 WAN(173)을 포함하지만, 기타 다른 네트워크도 포함할 수 있다. 그와 같은 네트워킹 환경들은 사무실, 기업 컴퓨터 네트워크, 인트라넷 및 인터넷에서 통상적이다.

LAN 네트워킹 환경에서 이용되는 경우, 컴퓨터(110)는 네트워크 인터페이스나 어댑터(170)를 통하여 LAN(171)에 연결된다. WAN 네트워킹 환경에서 이용되는 경우, 컴퓨터(110)는 통상적으로 WAN(173), 예컨대 인터넷 등을 통한 통신을 수립하기 위한 모뎀(171)이나 기타 수단을 포함한다. 외장형 또는 내장형일 수 있는 모뎀(172)은, 사용자 입력 인터페이스(160)나 기타 다른 적절한 메카니즘을 통하여 시스템 버스(121)로 연결될 수 있다. 네트워크형 환경에서는, 컴퓨터(110)와 관련하여 도시된 프로그램 모듈들이나 그 일부가 원격 메모리 저장 장치에 저장될 수 있다. 제한이 아니라 예로서, 도 1은 원격 애플리케이션 프로그램(185)이 메모리 장치(181)에 존재하는 것으로 도시하고 있다. 도시되어 있는 네트워크 접속은 예시적인 것이고 컴퓨터들 간에 통신 링크를 수립하는 기타 다른 수단들이 이용될 수도 있음을 알아야 한다.

통상적 비즈니스 애플리케이션들은 많은 수의 비즈니스 엔티티들을 포함할 수 있고 비즈니스 논리에 따라 이들 엔티티 상에서 다양한 연산들을 수행할 수 있다. 이러한 애플리케이션들은 이들 엔티티에 관련된 비즈니스 논리에 대한 액세스 및 실행을 가능하게 하는 애플리케이션 프로그래밍 인터페이스(API)를 제공한다. API는, 하드웨어 장치, 네트워크, 운영체제, 소프트웨어 라이브러리, 기타 애플리 케이션과 인터랙션하기 위하여 개발자에 의해 이용되는 프로그램, 코드 라이브러리, 또는 인터페이스들의 세트일 수 있다. 상호 운용가능성은 비즈니스 애플리케이션에 있어서 매우 중요한 요구사항이므로, 웹 서비스 기술이 API를 설계하는데 이용될 수 있다. API의 소비자들은 API의 시그니쳐에 의존하고 API에 대해 그 수명 동안 가해지는 변경이 있을 경우 영향을 받는다. 이와 같은 애플리케이션들에 있어서 존재하는 비즈니스 엔티티의 수에 비례하여, 비슷하게 많은 수의 정적 연산들(메소드들)이 API를 통하여 정의되고 이용 가능해진다. 이와 같은 모델은 여러 가지 이유로 확장이 곤란하다.

1. API에 대한 어떠한 변경도 모든 소비자들에 대한 변경을 요구한다. 메소드 기반 확장성은 그다지 융통성 있거나 비용 효율적이지 않다. 그러한 API를 확장하기 위하여, 새로운 메소드가 API 세트에 추가될 필요가 있다.

2. API에 의해 지원되는 타입 시스템에 대한 어떠한 변경도 API 구현 및 모든 소비자들에 대한 변경을 요구한다.

3. 많은 수의 메소드를 관리 및 유지하기 위한 현재의 복잡도 및 비용

4. 다양한 타입의 비즈니스 엔티티들에 걸쳐 연산 및 데이터의 일관성을 관리하기 위한 현재의 복잡도와 비용

5. API의 수명과 많은 수의 다양한 버전의 애플리케이션에 걸친 존속기간

6. 프로그래밍 모델 및 개발 경험은 많은 수의 메시지 및/또는 API 타입으로 인하여 복잡해질 수 있다.

7. 종종 최종 사용자들에 의해 도입되는 새로운 타입들(예컨대, 새로운 비즈 니스 엔티티들)과 고객화(customizations)는 시스템 비즈니스 엔티티들에 비해 상이한 프로그래밍 모델을 요구한다.

8. API의 최종 사용자들은 API 기능성을 쉽게 확장할 수 없다.

9. 워크플로우 및 비즈니스 프로세스는 API로 쉽게 통합될 수 없다.

메시지 지향 접근법은 앞서 언급된 모든 문제들을 해결하는 확장 가능성의 포인트를 생성하고 새로운 메시지들을 통하여 새로운 비즈니스 논리가 구현되도록 하는 프레임워크를 제공한다. 이러한 방법은, 타입 시스템이나 API 시그니쳐를 변경하는 일없이, 임의적 메시지들(심지어 그 메시지들이 구현 이후에 정의된 것인 경우에도)을 수용한다. 이와 같은 메시지 지향 접근법은 다음의 이점을 갖는다.

1. API에 대한 어떠한 변경도, 메소드의 시그니쳐를 변경하거나 그 메소드의 기존 소비자들에게 영향을 미치는 일 없이 새로운 메시지의 추가에 의해 구현될 수 있다.

2. 시스템 타입들은 기존의 소비자들을 방해하지 않고서도 확장될 수 있다.

3. 개발 환경에서, 비교적 많은 수의 비즈니스 엔티티들과 비즈니스 논리가, 유용성과 개발 경험을 향상시키는 방향으로, 잘 짜여진 브라우징 가능한 메시지 리스트로써 통합될 수 있다.

4. 다양한 타입의 비즈니스 엔티티들에 걸쳐 연산과 데이터의 일관성을 관리하기 위한 현재의 비용 및 복잡도가 단순한 메시지 클래스 계층구조에 의해 많이 감소될 수 있다.

5. API의 수명 및 그 존속기간은 간단한 확장 가능성 포인트: 메시지로 인해 개선된다.

6. 최종 사용자들에 의해 도입되는 새로운 타입들(예컨대, 새로운 비즈니스 엔티티들)과 고객화는 메시지 클래스 계층구조에 잘 맞을 수 있고 시스템 비즈니스 엔티티들과 동일한 프로그래밍 모델과 함께 소비될 수 있다.

7. API 및 그 기능성은 새로운 메시지들을 정의함으로써 쉽게 확장될 수 있다.

8. 워크플로우 및 비즈니스 프로세스는 워크플로우 레서피들과 프로세스 디스크립션들을 포함하는 새로이 정의된 메시지들의 세트를 통하여 API와 쉽게 통합될 수 있다.

메시지 지향 API는 비즈니스 애플리케이션의 사용자들로 하여금 메시지들을 통하여 비즈니스 연산들과 데이터에 액세스하고 비즈니스 논리를 실행하도록 할 수 있다. 도 2는 그러한 시스템, 예컨대 고객 관계 관리(CRM) 시스템에서의 시스템 구성의 일 예를 도시한 것이다. CRM은, 비즈니스 관계 및 고객 만족과 관련하여 클라이언트들, 고객들 및 서비스 에이전트들과의 커넥션을 조직화하고 유지하는 능력의 보유를 유지하는 방법일 수 있고, CRM 애플리케이션은, 고객의 프로파일이 작성 및 추적되어 판매 사원을 도와 해당 고객을 위한 더 나은 서비스를 제공할 수 있도록 하여, 전반적으로 개선된 고객 관계를 가져오도록 하는 프로그램들에 해당하는 고객 관계 관리 애플리케이션의 두문자어일 수 있다.

CRM 웹 서비스(200)는 비즈니스 애플리케이션 사용자들이 이용하는 인터페이스일 수 있다. 이러한 인터페이스는, 애초에 시스템에 포함되어 있었던 오리지널 메시지들뿐만 아니라 고객화 이후 CRM 시스템에 추가된 새로운 메시지들(확장)을 동일한 인터페이스를 통하여 노출시킨다. 시스템 오리지널 비즈니스 엔티티들을 위해 이용되는 것과 동일한 인터페이스 및 프로그래밍 모델이 지속적인 프로그래밍 경험을 제공하면서 고객 비즈니스 엔티티들을 위하여 이용된다. 이러한 웹 서비스(200)는 웹 서비스 정의 언어(WSDL)에서 마련된, 잘 정의된 웹 서비스 디스크립션을 가질 수 있고 임의의 기타 다른 바람직한 정의 언어로 정의될 수 있다. WSDL은 UDDI를 통해 웹 서비스 제공자에 의해 제공되는 네트워크 서비스들을 기술하기 위한 XML 기반 계약 언어일 수 있다. UDDI는 Universal Description, Discovery, and Integration을 나타내는 것이고, 웹 서비스 소비자들이 네트워크상에서 이용 가능한 웹 서비스 및 프로그래머블 리소스들의 위치를 찾도록 하는 SOAP-기반 룩업 서비스 및 XML일 수 있다. WSDL은 퍼블릭 메소드들, 모든 파라미터들의 데이터 타입들, 반환 값, 그리고 바인딩들에 의해 웹 서비스 소비자들에 대한 웹 서비스를 기술할 수 있다. SOAP은 웹 서비스 요청 및 응답 메시지들에 포함된 정보를 네트워크를 통해 전송하기 이전에 인코딩하는데 이용되는 경량의 XML 기반 메시징 프로토콜인 Simple Object Access Protocol을 나타낸다. SOAP 메시지들은, 임의의 운영체제나 프로토콜에 독립적일 수 있고, SMTP, MIME 및 HTTP를 포함한 다양한 인터넷 프로토콜을 이용하여 전송될 수 있다. WSDL은 시스템 사용자들을 위하여 동적으로 생성되고 그들로 하여금 웹 서비스에 액세스하고 그에 대해 프로그램하도록 한다.

시스템은 단일의 웹 서비스 메소드, 소위 실행(Excute)을 포함할 수 있다. 일 예는 다음과 같다.

[WebMethod] 퍼블릭 응답 실행(Response Execute) (Request 요청)

시스템 내의 다양한 비즈니스 엔티티들, 비즈니스 연산들 및 데이터와 함께 작업하는데 동일한 메소드와 인터페이스가 이용될 수 있다. 실행 메소드는 요청 메시지(210)를 받고 응답 메시지(220)를 반환할 수 있다. 요청 메시지들은 CRM 웹 서비스(230)의 클라이언트에 의해 인스턴스화(instantiated)되고 구축될 수 있다. 호출자는 웹 서비스(230) 상에서 실행 메소드를 호출함으로써 CRM 플랫폼으로 메시지를 전송할 수 있다. 메시지는, CRM 웹 서비스(200)로 전송되기 이전에, 클라이언트(240)에 의해 SOAP 패킷으로 직렬화될 수 있고 CRM 웹 플랫폼 상에서 메시지 오브젝트로 다시 병렬화될 수 있다. 메시지는 서버(250)로 전송될 수 있고 거기서 처리될 수 있다. 메시지 프로세싱의 결과는 실행 웹 메소드의 호출자로 응답 메시지(220)를 통하여 반환될 수 있다. 요청 및 응답 메시지 콘텐츠는 모두 강하게 타입화되어 호출자로 하여금 타입들을 가지고 작업할 때 더 나은 개발 환경 지원을 이용할 수 있게 한다. SOAP가 분산 환경에서 구조화된 정보를 교환하기 위하여 이용 가능한 프로토콜들 중 하나이지만, 임의의 적절한 프로토콜이 이용될 수도 있음을 알아야 한다.

도 3은 실행 메소드와 함께 이용되는 요청(Request) 및 응답(Response) 메시지들의 클래스 계층구조를 예시한 클래스 구조도이다. CRM 시스템에 의해 지원되는 다양한 비즈니스 연산들을 나타내기 위하여 요청 메시지로부터 유도되는 다수의 클래스가 있을 것이다. 각 요청 유도형 클래스는 대응하는 응답 유도형 클래스를 갖는다. 예컨대 CreateRequest 클래스가 요청 클래스로부터 유도되고 이는 응답 클래스로부터 유도되는 CreateResponse 클래스에 대응한다. 일반적인 원칙으로서, 전형적 웹 메소드 상의 파라미터들은 요청 메시지들(310)의 멤버들로 매핑될 수 있고 전형적 웹 메소드의 반환 파라미터들은 응답 메시지들(320)의 멤버들로 매핑될 수 있다. 지원되는 모든 비즈니스 연산들과 비즈니스 논리는 요청 메시지들(330)의 서브클래스들을 통하여 노출될 수 있고, 요청 및 응답 키워드들로 포스트픽스될(postfixed) 수 있다. 메시지들은 모두, 연산이 CRM 플랫폼에서 지원되는 비즈니스 연산(Operation)인 경우, 연산 이름(Operation name)으로 시작할 수 있다. 이와 같은 이름 결정을 위한 관습들은 모두 개발 환경에서 메시지들의 용이한 브라우징과 개선된 API 유용성을 가능하게 한다.

도 4는, CRM 시스템에서 메시지들을 이용하여 애플리케이션 프로그래밍 인터페이스의 기능성을 확장하는 방법을 도시한 도면이다. 블록(405)에서, CRM 연산이 선택될 수 있다. 메시지 지향 설계는 프로세스 중심적이므로, 프로그래밍 경험은, 개발자가 구체적 요청 메시지 선택을 통하여 원하는 비즈니스 연산(계좌 개설(Create an Account), 계좌 통합(Merge an Account), 이메일 전송(Send an Email)을 고르는 것으로 시작할 수 있다.

블록(405)에서, 선택된 연산에 기초한 요청 메시지가 송수신될 수 있다. 송수신은, 임의의 유선 또는 무선 채널을 통하여, 선택된 채널에 적합한 통신 프로토콜을 이용하여 이루어질 수 있다. 앞서 기술된 바와 같이, 요청 메시지들을 수신하고 응답 메시지들을 반환할 수 있다. 요청 메시지들은 CRM 웹 서비스의 클라이 언트에 의해 인스턴스화(instantiate)되고 구축될 수 있다. 호출자는 웹 서비스 상에서 실행 메소드를 호출함으로써 CRM 플랫폼으로 메시지를 전송할 수 있다. 메시지는 임의의 전송 프로토콜, 예컨대 SOAP를 통하여, CRM 서버로 전송되고 그곳에서 처리될 수 있다.

블록(415)에서, 요청 메시지가 그 요청 메시지의 일부로서 비즈니스 엔티티 타입 이름을 포함하고, 이것이 사용자에게 그 메시지가 오직 그 특정한 비즈니스 엔티티에게만 유효하다는 점을 나타낼 경우, 그 사용자는 요청 메시지를 인스턴스화(instantiate)하고, 블록(420)에서 요청 메시지 파라미터들을 채우고, 그런 다음 블록(425)에서 그 요청 메시지를 처리를 위해서 CRM 서버로 전송할 수 있다.

블록(430)에서, 요청 메시지가 요청 메시지 이름에 어떠한 비즈니스 타입 이름도 포함하지 않은 공통 요청 메시지인 경우, 사용자는 요청 메시지를 인스턴스화할 수 있다. 블록(435)에서, 사용자는 타겟 클래스 타입을 조사함으로써 지원되는 타겟 비즈니스 엔티티들을 발견할 수 있고 타겟 베이스 클래스를 인스턴스화할 수 있다. 블록(440)에서, 사용자는 요청 메시지에 대한 타겟 클래스 파라미터들을 채울 수 있다. 이러한 접근법은, 사용자가 설계시 주어진 비즈니스 엔티티 상에서 지원되는 연산만을 실행할 수 있다는 점을 확인한다.

블록(445)에서, 요청 메시지에 타겟 클래스가 추가될 수 있고, 블록(425)에서 그 요청 메시지가 실행될 수 있다. 실행 결과는 실행 웹 메소드의 호출자에게 응답 메시지를 통하여 반환될 수 있다. 요청 및 응답 메시지 콘텐츠는 강하게 타입화되어 호출자로 하여금 타입들을 가지고 작업할 때 더 나은 개발 환경 지원을 이용할 수 있게 한다. 물론, 이는 본 방법을 실행하는 한 가지 방식일 뿐이고 다른 방식들도 가능하다.

블록(450)에서, 사용자는 어떠한 비즈니스 엔티티로의 아무런 참조도 없는 요청 메시지, 즉 그 요청 메시지 이름에나 요청 메시지 클래스에나 어떠한 비즈니스 엔티티로의 어떠한 참조도 없는 요청 메시지를 인스턴스화할 수 있다. 이러한 메시지 타입은 비즈니스 엔티티 애그노스틱(business entity agnostic)이고 비즈니스 엔티티에 대한 참조를 반드시 요구하지는 않는 범용 연산들을 실행하는데 이용될 수 있다. 블록(455)에서, 요청 메시지 파라미터들을 채울 수 있고, 그런 다음 블록(425)에서 요청 메시지가 처리를 위하여 CRM 서버로 전송될 수 있다.

API는 새로운 메시지들을 통하여 확장될 수 있다. 모든 새로운 메시지들은 기본 요청 및 응답 메시지들로부터 유도되므로, 새로운 메시지들의 추가는 메소드 시그니쳐의 변경을 요구하지 않는다. 예컨대, CRM의 한가지 버전은 SendEmailRequest 메시지를 익스포즈(expose)함으로써 이메일을 전송하는 능력을 갖추고 있고 추후 단순히 SendFaxRequest라는 새로운 메시지를 추가함으로써 전화선을 통해 팩스를 전송하는 새로운 기능을 추가할 수 있다. 양 메시지는 모두 기본 요청 클래스로부터 유도되므로 실행 메소드의 변경을 요구하지 않는다. 클래스 계층 구조의 존재는 메시지들의 직렬화 및 병렬화가 클라이언트와 서버 양자 모두에서 적절하게 발생하도록 할 수 있다.

요청 메시지 계층구조에 관한 다형성(polymorphism)은 각 비즈니스 엔티티를 위한 새롭고 이질적인 인터페이스를 생성할 필요없이 복수의 비즈니스 엔티티 타입 들을 위하여 동일한 인터페이스가 이용될 수 있다는 점을 의미할 수 있다. 예컨대, CreateRequest가 동일한 메시지와 동일한 실행 메소드를 통하여 다양한 타입의 비즈니스 엔티티들의 새로운 인스턴스들을 생성하는데 이용될 수 있다. 이는 메시지 지향 접근법의 이점들 중 한가지이다.

비즈니스 애플리케이션에서 제공되는 다양한 타입의 비즈니스 연산들을 충족시키기 위하여 다양한 타입의 메시지들이 시스템에서 정의될 수 있다. 일부 메시지들은 공통 연산들을 나타내고 시스템 내의 비즈니스 엔티티들 대부분에 적합한 반면, 일부 다른 메시지들은 특정한 비즈니스 엔티티 세트에 대해 좀 더 타겟화되어 있다. 비즈니스 애플리케이션 API를 이용하는 개발자는 설계 환경에서 어떤 비즈니스 엔티티가 어떤 연산들에서 지원되는지를, 문서기록에 대한 참조없이, 알아내는 것을 필요로 할 수 있다. 이와 같은 시스템은 타겟 클래스들과 비즈니스 엔티티 카테고리들을 통하여 어드레싱될 수 있다. 타겟 클래스들은 개발자로 하여금 어떤 메시지들이 어떤 비즈니스 엔티티들을 위하여 지원되는지를 식별할 수 있게 한다. 비즈니스 엔티티들이 다양한 카테고리들 하에서, 각 카테고리에 의하여 지원되는 비즈니스 연산에 기초하여, 그룹화되고, 각 그룹마다 타겟 베이스 클래스가 생성된다.

도 5는 타겟 클래스 계층구조의 두 가지 예를 도시하고 있다. TargetMerge(510) 및 TargetQuantify(520)는 각각 많은 수의 연산들을 지원할 수 있는 비즈니스 엔티티 카테고리를 나타낸다. 해당 카테고리에 속한, 각 비즈니스 엔티티는 이들 클래스로부터 유도된 타겟 클래스를 갖는다. 예컨대, TragetMerge(510)의 경우에, TragetmergeAccount 클래스는 Account 비즈니스 엔티티가 TargetMerge 카테고리의 멤버임을 보여주는 유도된 클래스이다. 이러한 클래스 계층구조에 있어서, API 사용자는, 프로그램에 의해서나 개발 환경에서의 툴을 이용함으로써, 문서기록을 필요로 하지 않고서, 모든 지원되는 구성들을 알아내고 타겟 클래스 계층구조를 브라우징하도록 인에이블될 수 있다.

병합 연산을 실행하기 위한 샘플 코드는 다음과 같다.

//1) 병합 요청의 생성

MergeRequest myMergeReq=new MergeRequest( );

//2) MergeRequest의 타겟 필드의 타입은 TargetMerge이고, 유도되는 클래스는

//TargetMerge<비즈니스 엔티티 이름>으로 명명된다. 선택된 비즈니스 엔티티에 대응하는 TargetMerge로부터 유도되는 클래스의 인스턴스를 생성함

TargetMergeAccount myTargetFirstAccount=new TargetMergeAccount( );

mytargetFirstAccount.EntityId=accountId;

//3) 요청 메시지 상에 타겟을 설정

myMergeReq.Target=myTargetFirstAccount;

myMergeReq.SubordinateId=subordinateId;

myMergeReq.PerformParentingChecks=true;

//4) 병합 요청을 실행, 응답 메시지의 타입은 MergeResponse가 될 것임

MergeResponse myMergeRes=(MergeResponse)myService.Execute(myMergeReq);

프로그래밍 모델과의 고객화 통합은 프로그래밍 모델의 나머지 부분과 지속적이고 일관된 것일 수 있다. CRM 시스템은 사용자들로 하여금 그 시스템에 새로운 비즈니스 엔티티들을 부가할 수 있게 한다. 시스템에 비즈니스 엔티티들을 추가하는 것은 CRM 웹 서비스의 서비스 정의 내에서 새로운 타입들과 메시지들의 생성을 자동으로 트리거링할 수 있고 메시지들의 계층 구조를 확장한다. 이는 개발자들로 하여금 원래의, 고객화되고 강하게 타입화된 비즈니스 엔티티 클래스들과 이들 클래스들을 수용하고 그에 관한 비즈니스 논리 및 연산들의 실행을 가능하게 하는 메시지들 양자를 이용하여 작업하도록 할 수 있다.

고객화의 일부로서 이미 추가된 새로운 비즈니스 엔티티의 인스턴스 생성을 위한 또 다른 예의 코드는 다음과 같다.

//사용자 회사 FAB은 fab_Vendor라는 이름의 시스템에 속한 커스텀 비즈니스 엔티티를 생성하였다. 사용자는 시스템 엔티티들과 작업하면서 동일한 경험을 얻는다.

//비즈니스 연산은 갱신

fab_vendor myVendor=new fab_vendor( );

Key myVendorKey=new Key( );

myVendorKey.Value=new Guid("{EF687190-6F85-4455-B225-93BF842425DD}");

myVendor.fab_description="A trusted vendor that provides safety equipment for Bikes";

myVendor.fab_preference=new PickList( );

myVendor.fab_preference.Value=2;

UpdateRequest myUpdateRequest=new UpdateRequest( );

TargetUpdateFab_Vendor myVendorTarget=new TargetUpdateFab_Vendor( );

myVendorTarget.fab_vendor=myVendor;

myUpdateRequest.Target=myVendorTarget;

UpdateResponse myVendorResponse=

(UpdateResponse)myService.Execute(myUpdateRequest);

도 6은 DynamicEntity(610), 새로운 비즈니스 엔티티 및 그 멤버들에 관한 클래스 구조도이다. 이 클래스는, 역시 BusinessEntity(620)로부터 유도된 CRM 비즈니스 엔티티들의 나머지들에 관한 피어(peer)가 될 수 있다. DynamicEntity(610)는, 엔티티 인스턴스가 WSDL 언어로써 이용 가능한 CRM 웹 서비스의 디스크립션 내에 그 엔티티에 관한 전체 정의를 포함하지 않고서 프로그램될 수 있도록 하는, BusinessEntity(620)로부터 유도된 새로운 클래스일 수 있다. DynamicEntity(610)는 엔티티의 논리적 이름을 나타내는 이름(Name)(640)과 엔티티 애트리뷰트들을 나타내는 강하게 타입화된 속성들(Properties)(630)의 어레이를 포함할 수 있다. DynamicEntity(610) 클래스가 WSDL에서 속성들의 어레이를 갖는 클래스로서 노출되기 때문에, API의 사용자는 이 클래스의 인스턴스들을 생성할 수 있고 임의의 원하는 비즈니스 엔티티(시스템이나 고객, WSDL에 포함된 것이거나 포함되지 않은 것임)에 대해 그 이름을 설정할 수 있고 어떠한 컴파일/설계 시간 오차를 가져오는 일 없이 임의의 원하는 속성들(WSDL에 포함된 것이거나 포함되지 않 은 것임)을 어레이에 추가할 수 있다. 실행시, 속성들 어레이의 내용이 평가될 것이고, 엔티티 이름이 존재하지 않거나 어레이 내에 명명된 속성들이 인식되지 않을 경우 실행 예외 상황이 발생할 수 있다.

DynamicEntity를 정의하기 위한 코드는 다음과 같다.

퍼블릭 클래스 DynamicEntity : BusinessEntity

{

Property[] Properties;

public string Name

}

DynamicEntity 클래스(610)는 강하게 타입화된 클래스들을 넘어서 API를 확장할 수 있고 비즈니스 엔티티들을 이용하여 작업하고 그들의 비즈니스 논리를 실행하는 범용의 확장 가능한 방법을 제공할 수 있다. 사용자는 강하게 타입화된 비즈니스 엔티티들의 클래스 DynamicEntity(610) 포맷을 이용할지를 결정할 수 있다. 사용자는 또한 강하게 타입화된 BusinessEntities(620) 오브젝트들이나 DynamicEntity(610) 포맷으로 비즈니스 연산들의 실행의 결과들을 수신할지를 결정할 수 있다. DynamicEntity(610)의 이점은, 설계시 사용자가 완전히 다 기술된 특정 비즈니스 엔티티 타입의 웹 서비스 정의를 가질 필요가 없고 , 타겟화된 CRM 구현 내의 다양하게 정의된 비즈니스 엔티티들을 동적으로 그리고 실행시에 알아내는 코드를 개발할 수 있고 설계/컴파일 시에 그 정의들을 갖지 않은 채 이들 엔티티를 이용하여 작업을 수행(연산 실행)할 수 있다.

앞서 많은 다양한 실시예들에 관한 상세한 설명을 설명하였으나, 본 발명의 범위는 다음에 첨부된 특허청구범위에 의해 정의된다는 점에 유의해야 한다. 상세한 설명은 예시적인 것으로만 해석되어야 하고, 모든 가능한 실시예를 기술하는 것은, 불가능하지는 않더라도, 비현실적이므로, 상세한 설명에 모든 가능한 실시예들이 기술될 필요는 없다. 특허청구범위에 속하는 범위 내에서, 다양한 대안적 실시예들이, 현재의 기술이나 본 출원일 이후 장차 개발될 기술을 이용하여 구현될 수 있다.

그러므로, 본 발명의 사상과 범위를 벗어나지 않는 범위 내에서 다양한 많은 변형 및 변경이, 본 명세서에 기술 및 예시된 기술들과 구조들에 대해 이루어질 수 있다. 따라서, 발명의 상세한 설명에 속한 방법 및 장치는 오직 예시적인 것일 뿐이고 특허청구범위를 제한하는 것은 아니라는 점을 알아야 한다.

Claims

메시지들을 이용하여, 고객 관계 관리(customer relationship management: CRM) 시스템에서 애플리케이션 프로그래밍 인터페이스의 기능성(functionality)을 확장하는 방법으로서,

연산 - 상기 연산은 CRM 연산임 - 을 선택하는 단계;

상기 선택된 연산에 기초한 요청 메시지(request message)를 CRM 웹 서비스로 전송하는 단계;

상기 요청 메시지가 상기 요청 메시지의 이름에 비즈니스 엔티티 타입 이름(business entity type name)을 갖고, 상기 요청 메시지는 상기 이름의 엔티티에 대해서만 유효(valid)한 경우, 상기 요청 메시지를 인스턴스화(instantiating)하고, 상기 요청 메시지의 필드들을 할당하고, 상기 요청 메시지를 실행하는 단계;

상기 요청 메시지가 상기 요청 메시지의 이름에 비즈니스 타입 이름을 갖지 않는 공통 요청 메시지이고 상기 요청 메시지가 타겟 속성(target property)을 갖는 경우, 상기 요청 메시지를 인스턴스화하고, 지원되는 타겟 클래스들 중 하나를 선택 및 인스턴스화하고, 상기 타겟 클래스의 필드들을 할당하고, 상기 요청 메시지의 필드들을 할당하고, 타겟 클래스를 상기 요청 메시지와 연관시키고, 상기 요청 메시지를 실행하는 단계; 및

상기 요청 메시지의 이름이 비즈니스 엔티티 이름을 포함하지 않고 상기 메시지가 타겟 속성을 갖지도 않는 경우, 상기 요청 메시지를 인스턴스화하고, 상기 요청 메시지의 필드들을 할당하고, 상기 요청 메시지를 실행하는 단계

를 포함하는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서,

상기 새로운 메시지들은 상기 베이스 요청 및 응답 클래스들로부터 유도되는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서,

상기 방법은, 요청 메시지를 전송하고 응답 메시지를 반환함으로써 실행되는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서,

상기 요청 메시지는 CRM 웹 서비스의 클라이언트에 의해 인스턴스화되고 구축되는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서,

상기 메시지는 전송 프로토콜을 통하여 상기 CRM 웹 서비스로 송신되는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서, 비즈니스 연산들이 비즈니스 엔티티들에 할당되는, 애플리 케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서,

타겟 베이스 클래스들이, 상기 비즈니스 엔티티들을 카테고리들로 분류 - 상기 분류는 상기 각 카테고리에 의해 지원되는 비즈니스 연산들에 기초함 - 함으로써 생성되는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
제1항에 있어서,

상기 타겟 클래스의 계층구조가, 어떤 비즈니스 엔티티들이 어떤 연산들을 지원하는지 판정하는데 이용되는, 애플리케이션 프로그래밍 인터페이스의 기능성 확장 방법.
컴퓨팅 장치로서,

비디오 이미지들을 생성할 수 있는 디스플레이 유닛;

입력 디바이스;

상기 디스플레이 유닛 및 상기 입력 디바이스에 동작 가능하게 연결된 처리 장치 - 상기 처리 장치는 프로세서와, 상기 프로세서에 동작 가능하게 연결된 메모리를 포함함 - ; 및

네트워크 및 상기 처리 장치에 연결된 네트워크 인터페이스를 포함하고,

상기 처리 장치는,

연산 - 상기 연산은 고객 관계 관리 연산임 - 을 선택하고,

상기 선택된 연산에 기초한 요청 메시지를, 전송 프로토콜을 통하여, CRM 웹 서비스로 전송하고,

상기 요청 메시지가 상기 요청 메시지의 이름에 비즈니스 엔티티 타입 이름을 갖고, 상기 요청 메시지는 상기 이름의 엔티티에 대해서만 유효한 경우, 상기 요청 메시지를 인스턴스화하고, 상기 요청 메시지의 필드들을 할당하고, 상기 요청 메시지를 실행하고,

상기 요청 메시지가 상기 요청 메시지의 이름에 비즈니스 타입 이름을 갖지 않는 공통 요청 메시지이고 상기 요청 메시지가 타겟 속성을 갖는 경우, 상기 요청 메시지를 인스턴스화하고, 지원되는 타겟 클래스들 중 하나를 선택 및 인스턴스화하고, 상기 타겟 클래스의 필드들을 할당하고, 상기 요청 메시지의 필드들을 할당하고, 타겟 클래스를 상기 요청 메시지와 연관시키고, 상기 요청 메시지를 실행하고,

상기 요청 메시지의 이름이 비즈니스 엔티티 이름을 포함하지 않고 상기 메시지가 타겟 속성을 갖지도 않는 경우, 상기 요청 메시지를 인스턴스화하고, 상기 요청 메시지의 필드들을 할당하고, 상기 요청 메시지를 실행

하도록 프로그램된 컴퓨팅 장치.
제9항에 있어서,

상기 요청 메시지는 CRM 웹 서비스의 클라이언트에 의해 인스턴스화되고 구 축되는, 컴퓨팅 장치.
제9항에 있어서,

타겟 베이스 클래스들이, 상기 비즈니스 엔티티들을 카테고리들로 분류 - 상기 분류는 상기 각 카테고리에 의해 지원되는 비즈니스 연산들에 기초함 - 함으로써 생성되고, 어떤 비즈니스 엔티티들이 어떤 연산들을 지원하는지 판정하기 위해 상기 타겟 클래스 계층구조가 검토될 수 있는 컴퓨팅 장치.
메시지들을 이용하여, 고객 관계 관리(CRM) 시스템에서 애플리케이션 프로그래밍 인터페이스의 기능성을 확장하도록 하는 컴퓨터 실행가능 코드를 저장하도록 적합화된 컴퓨터 판독가능 매체로서, 상기 컴퓨터 실행가능 코드는,

연산 - 상기 연산은 CRM 연산임 - 을 선택하기 위한 컴퓨터 코드;

상기 선택된 연산에 기초한 요청 메시지 - 상기 요청 메시지는 CRM 웹 서비스의 클라이언트에 의하여 인스턴스화되고 구축됨 - 를 CRM 웹 서비스로 전송하기 위한 컴퓨터 코드;

상기 요청 메시지가 상기 요청 메시지의 이름에 비즈니스 엔티티 타입 이름을 갖고, 상기 요청 메시지는 상기 이름의 엔티티에 대해서만 유효한 경우, 상기 요청 메시지를 인스턴스화하고, 상기 요청 메시지의 필드들을 할당하고, 상기 요청 메시지를 실행하기 위한 컴퓨터 코드;

상기 요청 메시지가 상기 요청 메시지의 이름에 비즈니스 타입 이름을 갖지 않는 공통 요청 메시지이고 상기 요청 메시지가 타겟 속성을 갖는 경우, 상기 요청 메시지를 인스턴스화하고, 지원되는 타겟 클래스들 중 하나를 선택 및 인스턴스화하고, 상기 타겟 클래스의 필드들을 할당하고, 상기 요청 메시지의 필드들을 할당하고, 타겟 클래스를 상기 요청 메시지와 연관시키고, 상기 요청 메시지를 실행하기 위한 컴퓨터 코드; 및

상기 요청 메시지의 이름이 비즈니스 엔티티 이름을 포함하지 않고 상기 메시지가 타겟 속성을 갖지도 않는 경우, 상기 요청 메시지를 인스턴스화하고, 상기 요청 메시지의 필드들을 할당하고, 상기 요청 메시지를 실행하기 위한 컴퓨터 코드를 포함하는 컴퓨터 판독가능 매체.
제12항에 있어서,

상기 요청 메시지는 상기 CRM 웹 서비스의 클라이언트에 의해 인스턴스화되고 구축되는 컴퓨터 판독가능 매체.
제12항에 있어서,

타겟 베이스 클래스들이, 상기 비즈니스 엔티티들을 카테고리들로 분류 - 상기 분류는 상기 각 카테고리에 의해 지원되는 비즈니스 연산들에 기초함 - 함으로써 생성되고, 어떤 비즈니스 엔티티들이 어떤 연산들을 지원하는지 판정하기 위해 상기 타겟 클래스 계층구조가 검토될 수 있는 컴퓨터 판독가능 매체.
제12항에 있어서,

상기 새로운 메시지 모두가 베이스 요청 및 응답 클래스들로부터 유도되는 컴퓨터 판독가능 매체.