모든 컴퓨터 안에서는 여러분이 키보드를 누르거나 마우스 클랙을 할때마다 수천개의 "프로시저 호출"이 생성되고 분석, 처리되어 여러분의 동작에 맞게 실행됩니다.

예를 들어, 아이콘위로 마우스를 움직이고 있을때, 여러분이 가리킨 위치를 알아내기 위해 locatemouse 프로시져를 호출한다고 합시다. 마우스가 메뉴를 가리키고 있나요? 아니면 스크롤바? 그렇다면 스크롤바의 어느 부분? 또는 아이콘? 문자열? 이러한 모든 가능성이 고려될 것입니다.

좋습니다. 여기서는 마우스 버튼 클릭시 마우스가 아이콘위에 위치했다고 가정하도록 하죠. 어떤 종류의 아이콘일까요? 프린터 아이콘이라면 인쇄명령에 해당하는 프로시져가 호출될 것입니다. 이러한 종류의 아이콘에 사용자가 마우스 클릭을 하면 무슨 처리를 해야할까요? 특별한 프로시져가 이러한 질문에 답해주는 역할을 담당할 것입니다.

이러한 대화상황은 여러분이 컴퓨터 앞에 앉아있지않더라도 언제나 컴퓨터 안에서 부단히 발생합니다. 언제나 이것은 질문으로 시작합니다. 그리고 답변은 프로시져로부터 오게 됩니다. 그러므로 소프트웨어는 답을 얻기위해 프로시져를 "호출"하게 되는 것이죠.

호출중간에 프로시져는 몇가지 추가정보를 필요로 하는데, 이렇게 함으로서 다른 프로시져에서 이미 알아낸 것들을 다시 처리하지 않아도 되도록 하고 있습니다. 이것들을 "매개변수"라고 부릅니다. locatemouse 프로시져는 마우스가 어디에 있는지를 알아낼 때 필요압니다. 마우스의 위치는 일반적으로 고등학교에서 배운 좌표평면(cartesian plane)과 비슷한 좌표시스템으로 표현합니다. 예를 들자면 x좌표, y좌표같은 방식이 되겠죠. 이러한 프로시져는 x, y라는 두개의 매개변수를 "가진다"라고 말합니다.

매개변수가 중요한 이유가 3가지 있습니다. 먼저 호출자가 마우스 위치를 이미 알고 있을때 다시 locatemouse를 호출할 필요가 있을까요? 그리고 두번째로 locatemouse를 호출한 시점에는 이미 마우스가 이동했을 수도 있습니다. 그리고 세번째, 데이타베이스에서 레코드 검색과 같은 몇가지 연산처리를 수행하기위해 호출될 수도 있습니다. 이러한 프로시져는 찾고자하는 레코드를 식별하기위해, 사용자명 또는 계정번호를 매개변수로 필요로 할 수도 있습니다.

그리고 3번째 이유에 대한 프로시져 호출의 제작동기가 있습니다. 바로 반환값입니다. 이것은 프로시져를 호출한 프로시져에게 되돌려주는 답을 의미합니다. 데이타베이스 접근 프로시져는 매개변수로 넘겨주었던 키 식별정보에 따라 검색된 레코드의 모든 요소 즉 값의 집합일 수도 있습니다.

자, 이제 확실하게 프로시저 호출이 무엇인지 말할 때가 되었네요. 프로시져 호출이란 프로시져 이름 + 매개변수들 + 반환값을 말합니다.

왜 프로시져 호출이 중요할까요? 간단히 답하자면, 이것없이는 컴퓨터라고 할수 없기 때문이죠! 모든 프로그램은 main이라고 하는 하나의 단일 프로시져를 가지고 있으며, 모든 운영체계는 커널이라고 불리는 주 프로시져가 존재합니다. 무언가가 일어나길 대기하는 루프상에 놓여있어서, 응답하고자 하는 프로시져 계층구조로 제어를 분산시키는 프로그램(보통 이벤트 기반 프로그램이라고도 합니다)들에 있어서는 이들은 기본 계층이 됩니다. 이는 상호반응과 네트워크 처리의 심장부이자, 소프트웨어의 심장부라고 할 수 있습니다.

RPC(Remote Procedure Call : 원격 프로시져 호출)이란 프로시져 호출 아이디어를 간단히 확장한 것입니다. 이것은 서로 다른 어플리케이션 또는 서로 다른 기계 상에서 동작하는 프로시져간 연결을 생성해줍니다.

개념적으로 지역 프로시져 호출과 원격 프로시져 호출간의 차이는 없지만, 구현과 실행은 전혀다릅니다.(당연하지만 RPC쪽이 다소 느립니다) 그러므로 각각 다른 분야에 사용됩니다.

원격 호출은 연결된 다른 쪽에서 이해가능한 포맷으로 "마샬링"됩니다. 두 기계간에 하나의 포맷을 계속 허용하는 한, 이들은 서로 통신이 가능합니다. 이것이 윈도우즈끼리 통신이 가능하고, 맥끼리 통신이 가능한 이유입니다. 표준화된 플랫폼간 RPC접근법에 따른 값은 UNIX에서 윈도우즈로 통신하는 것을 가능하게 만들어 줄 것입니다.

이러한 포맷은 무수히 많습니다. 한가지 사용가능한 포맷이 있는데 그것은 컴퓨터와 사람 양쪽이 읽을 수 있는 XML이라는 포맷입니다. XML-RPC는 마샬링 포맷으로 XML을 사용합니다. 이것은 예를 들면 매킨토시에서 윈도우즈, beOS상에서 동작중인 프로시져 호출을 가능하게 만들어줍니다. 물론 UNIX, 자바, IBM 메인프레임, PDA도 가능할 겁니다.

XML을 사용하면 그것이 실행하고자 하는 의도 및 내용을 알아내기 쉽고, 또한 내부 프로시져 호출 포맷에서 원격 포맷으로 변경하기 쉬워집니다.

좋습니다, 이제 XML부분은 무대뒤로 사라지도록 하고 XML-RPC가 무엇인지 이해할 단계입니다. 이것은 구현 명세서입니다. 프로그래머는 웹 개발자로서 XML에 관심이 있겠지만, 여러분이 사용자나 투자자라면 XML은 C++이나 자바만큼 중요할 겁니다. 개발자는 이것을 좋아하거나, 좋아하는 것처럼 보일 수도 있을 것이고, 단지 주로 XML-RPC의 XML 부분만을 관심있어 할지도 모릅니다.

그러나 어떤 포맷이 사용되는지 간에 RPC는 중요합니다. 그 이유는 선택사항을 허락해줌으로서 하나의 구성요소를 다른 구성요소로 교체할 수 있게 됩니다 - 이는 가능성을 열어주며, 고급 사용자들이 개발자가 미처 예측하지 못한 소프트웨어상의 해결책을 궁리해낼 수 있도록 합니다.

저자의 경험을 되살리자면, 개요지정 및 프레젠테이션용 통합 제품인 MORE라고 불리는 제품을 저자가 근무했던 회사가 발표했던 80년대 중반으로 거슬러 올라갑니다.

통합을 함으로서 많은 시너지 효과가 있었지만, 일부 사용자들은 단지 개요지정 없이 (새로운) 프레젠테이션 기능만을 원했습니다 ; 또 몇몇 사용자들은 잘 구성된 개요지정 기능만을 원하기도 했고, 이들은 도리어 프레젠테이션 기능에는 관심이 없었습니다.

양쪽 그룹 모두 선택사항을 원했고, 이들은 제품을 두개의 조각으로 분리하고 이들을 다함께 연결하기를 원했습니다. 개요지정기능을 원하는 사람들은 프레젠테이션 소프트웨어를 살 필요가 없을 것이고 그 반대도 마찬가지 일 겁니다. 그러나 이들이 둘다를 가지고 있다면, 모든 통합된 기능을 얻을 수 있을 겁니다. 이것은 훌륭한 아이디어였습니다! 나는 이 이야기를 여러번 주위에 해왔습니다. 이 일은 내 경력에서 전환점이 되었었으니까요. The users were asking for something reasonable, yet there were no operating system underpinnings to allow such a separation.

A few years later, the needed technology was in the operating system, and we had built software, a database and scripting engine, around the technology. Application developers implemented interfaces that allowed our software to "call" them. We'd send some parameters to a procedure, implemented in another app, and the app would send back an answer. Every app that implemented this could now be viewed as a toolkit that an advanced user could build new applications thru. In this world, we could have done an outliner and a presentation program, and linked them together with "glue" scripts.

Choice is good for users, and for some developers, in some situations, it's not that good. So it was a mixed bag. In some cases, web servers for example, there were absolute standards that were adhered to. And in others, page layout programs for example, the "wires" were seen as a competitive advantage, and never got in synch.

RPC의 또다른 잇점은 사용자들이 개발자들이 이해하지 못한, 두개이상의 제품의 기능들을 조합함으로서 통합의 기회를 가질 수 있도록 한다는 데 있습니다. 어플리케이션간에 서로 접착할 수 있는 기능을 가지고 있다면, 영감을 받은 사용자는 그 기능을 사용할 수 있을 것입니다. 개발자는 사용자가 무엇을 하는지 신경쓰지 않거나 이해하지 못하겠지만, 어쨌든 그것은 일어날 수 있는 일입니다. Interfaces provide room for growth, open doors, allow a user-perspective to create new functionality. 이러한 비젼은 사용자가 소프트웨어 개발자의 지원이나 도움없이 통합 선택을 가능하게 만들어 줍니다.

이러한 비젼은 몇몇 분야에서 이미 실현되어왔습니다. 데이타베이스와 웹 사이트들은 오늘날 매우 활발히 적용되는 분야입니다. 그러나 모든 개척작업은 사용자에 의해 행해지고 있습니다! 처음 웹이 붐을 이루기 시작할때 얼마나 많은 데이타베이스 제작사들이 웹을 이해했겠습니까? 그리고 질문을 잠깐 뒤집어보면, 얼마나 많은 웹개발자들이 데이타베이스가 필요로 했겠습니까? Almost all of them figured it out.

데이타베이스의 표준 인터페이스가 있었기 때문에, 데이타베이스 개발자들이 자신들이 했던 일에 대한 단서가 없었을 지라도 웹 개발자들은 자신이 원하는 작업을 할 수 있었을 수 있었습니다.

모든 소프트웨어 기술들과 같이, 이 기술에도 장단점이 있습니다. 여러분이 프로지져 호출을 같은 어플리케이션안에서 일어나도록 통합한다면, 훨씬 더 나은 성능과 더욱 사용자 지향적인 기능들을 얻을 수 있을 것입니다. 이는 어플리케이션 외부와 원격 프로시져 호출을 하여 실행하는 것보다 단일 어플리케이션안에서 프로시져 호출을 하는 것이 더 쉽기 때문입니다. (게다가 일반적으로 더 빠릅니다!)

Apps will not disappear. In the early heady days of this sub-industry, some people thought they would. But there's too much momentum behind the idea of a process implementing internal procedure calls. So, long live the app! It's a good thing. It's still here, for a while at least.

According to Jeff Walsh's InfoWorld article, Microsoft is planning to open up their operating system using XML-RPC. Such a protocol could be deployed quickly in other operating systems that support HTTP, ranging from Perl scripts running on Linux, to Quark publishing systems running on Macs, to relational databases running on mainframe systems. It could put Windows at the center of a new kind of web, one built of logic, storing objects and methods, not just pages and graphics.

As you know, I'm a big believer in this kind of glue. I've been talking with Bill Gates about this since 1985, when we met to talk about interapplication communication for MS-DOS. Then in 1991 we revisited the idea as Apple was deploying the Apple Event Manager on the Macintosh OS. Apple wasn't willing to license the technology, so Microsoft did COM. But COM mainly runs on Windows, and although there have been recent efforts to popularize it on other operating systems, it'll be an uphill battle because most operating systems have their own native way of connecting systems together at a remote procedure call level.

So, by agreeing, at least at a philosophic level, that XML-RPC is an important way to go, Microsoft is putting out a big Welcome Mat -- come rule our world, they say. You can control Windows without adopting COM. You can replace an NT machine with any other machine that supports the same interfaces.

Even if NT should become a locked-in standard in the enterprise (far from an accomplished feat at this time) users will be able to substitute other operating systems for NT thru simple interfaces. I support that, I think it's a winning strategy, because I know how much value customers place on choices and new possibilities.

It's the lesson that the Internet teaches. It's a lesson that Gates learned so well that he's upping the ante. Instead of a hodge-podge of different wire protocols and payload formats, let's get something in place that can quickly be widely deployed everywhere. Why wait? That's what Microsoft is asking.

There's no reason to wait. Let's get just-enough technology in place and then let a thousand flowers bloom. I absolutely don't care what the wire format is, as long as I can develop simple scripting interfaces on top of it. I give up control, everyone does, and we let the messy cacaphony of competition take over.

That's the way to go.