Written By 신성호

2. Socket Programming

6. 기 타

의 CPU, Memory, Disk 저장장치 등을 사용할 수 있다.

RMI(Remote Method Invocation) 나 CORBA(Common Object

Request Broker Architecture) 와 같은 분산객체가 등장하기 이전에

대표적인 예로 Sun 에서 만든 RPC(Remote Procedure Call)가

있으며 이 개념은 현재의 RMI, CORBA, DCOM 의 기반이 되고

RPC 는 단지 리모트 컴퓨터상의 특정 메모리 번지에

리모트 객체의 레퍼런스를 통해 서비스(Remote Method)를 호출

즉, OOP(Object Oriented Programming) 에서 제공하는 상속,

즉, 컴포넌트는 재컴파일없이 Tool 을 이용해 입맛에 맞게

Property 등을 수정한뒤 바로 사용되어 질 수 있다.

자바에는 JavaBeans 라고 하는 컴포넌트 모델이 있다.

하지만 JavaBeans는 분산환경하에서 서버측 Business Logic을

RMI 서버객체 또한 컴포넌트는 아니다.

그것은 현재까지 나와있는 버전(2.3)의 CORBA 도 마찬가지다.

CORBA 의 가장 큰 단점중에 하나는 컴포넌트 모델의 부재이다.

프로그래머는 CORBA 에서 제공하는 Service 및 Facility 를 사용

하게 되며 IDL(Interface Definition Language) 을 통해 클라이언트

즉, 프로그래머에게 주어지는것은 IDL 이 전부이며 IDL은 인터페

이것은 CORBA 가 언어에 독립적이라는것을 감안한다면 충분히

실제 구현언어가 C++ 이면 COM / DCOM 이 될 수 있을

것이며 JAVA 라면 EJB(Enterprise JavaBeans)가 될 수 있을

OMG(Object Management Group) 에서는 99년 4/4 분기에 나올

CORBA 3.0 Spec 에서 EJB 를 기반으로 하는 표준 컴포넌트 모델

2. Socket Programming

Socket은 유닉스에 기반하며 객체기반 분산컴퓨팅이 나오기 이전까

며 CORBA 나 RMI등의 스텁, 스켈레톤 이 실질적으로 통신하는

1) 클라이언트는 NNTP 서버에 접속을 한다.

Socket clientSocket = new Socket("news.kaist.ac.kr", 119);

클라이언트는 특정 도메인 네임이나 IP 를 이용해 특정포트에서

2) 클라이언트는 서버로 Posting 한다.

// 클라이언트는 서버에게 "POST" 라는 Command를 보냄으로써

// Posting 하겠다는 뜻을 전한다.

out.println("Post");

out.println("From: " + UserName + "<" + Mail Address + ">");

out.println("Newsgroups: " + group);

out.println("Subject: " + subject);

out.println("Reply-To: " + mail address);

out.println("Organization: " + organization);

// HEAD 의 끝을 알리기 위해 빈라인을 전송한다.

out.println();

out.println();

// BODY, 즉 본문을 전송한다.

out.println(Message);

out.println(".");

클라이언트와 서버는 RFC에 정의된 표준 Command(Post,

From 등) 를 이용해 서로 통신한다.

도 Command 에 해당한다.

소켓은 물리적인 위치를 이용해서 서버를 찾지만 Corba 등의 분산객

체에서는 Directory and Name Service 를 이용해서 객체의 문자열

Post, Subject.. 등과 같은 Command 는 분산객체에서의 서비스

(메소드) 이름과 대응되며 Command: 이후의 메세지는 해당 서비스

3. RMI (Remote Method Invocation)

RMI 는 네트웍상에서 자바 객체들을 분산시킬수 있는 방법이다.

RMI 는 EJB, JINI 등 자바 분산기술의 기반 기술이다.

RMI API 는 프로그래머에게 객체가 네트웍상에서 분산되어 있

RMI 는 JRMP 라는 프로토콜을 사용하게 되며 클라이언트 / 서버

RMI 에 대해서는 간단히 살펴보고 넘어 가겠다.

RMI 를 비롯한 모든 분산객체 시스템들이 갖는 공통적인 특징이

RMI 에서는 java.rmi.Remote 인터페이스를 상속하는 인터페이스

2). 클라이언트와 서버는 스텁(Stub), 스켈레톤(Skeleton) 을 이용해

- 스텁 : 클라이언트측에 위치하며 서버객체의 Proxy 역할을

(IP Address)를 이용 실제로 네트웍을 통해 서버상의

(기본자료형 혹은 java.io.Serializable 인터페이스를 구현하는

클래스)하거나 원격 객체(원격인터페이스를 구현하는 객체)이어야

마지막으로 RMI 를 위해 필요한 jdk내에 포함된 툴들에 대해서 알아

1) RMIC

2) RMIREGISTRY

CORBA ORB 제품중의 하나인 Visibroker 의 OSAgent 와 동일한

있으며, 객체 서버는 특별한 형태의 URL(rmi://...)을 통해 객체

Corba 는 1984년 700 여개 이상의 컴퓨팅 관련 회사들이 공동 설립

한 컨소시엄인 OMG(Object Management Group)에서 제안한 OMA

(Object Management Architecture) 표준의 일부이다.

OMA는 Corba, UML 등과 같은 객체, 분산 등에 관한 솔루션을 제공

Corba 는 주로 분산환경하에서 객체간의 통신기능과 이를 조작하는

데 필요한 기능들을 주로 언급하고 있으며 ORB 는 Corba 표준안으

Corba 의 목적은 플랫폼, 언어에 독립적이고 위치에 투명한 방식으

즉, Corba 는 방법론이다.

1) IDL (Interface Definition Language)

IDL 은 서로다른 언어, 플랫폼간의 통신을 위한 표준을 제공한다.

IDL 은 코바객체가 제공하는 서비스를 정의하기 위한 명세언어

이며 IDL 은 선언만 있을뿐 구현은 없다.

2) ORB (Object Request Broker)

ORB는 Corba 객체 버스(Bus)이다.

ORB 의 목적은 Corba 객체의 위치 투명성을 보장하기 위함이며

즉, ORB 는 클라이언트 객체가 서버객체의 오퍼레이션를 호출할

그리고 작업이 완료되며 ORB 는 역으로 그 결과 값을 받아 클라

따라서 Corba 클라이언트, 서버는 모두 ORB 를 필요로 하며 서로

다른 회사제품의 ORB 가 서로 상호작용할 수 있도록 ORB 간

표준 통신 프로토콜인 IIOP(Internet Inter ORB Protocol) 을 사용

3) 인터페이스 저장소 (Interface Repository)

인터페이스저장소는 IDL이 저장되어 있는 데이타베이스이다.

가장 중요한 목적은 코바동적호출(DII, Dynamic Invocation

Interface) 을 가능하게 하며 서버와 다른 언어로 작성된 클라이언

4) 객체 어댑터(Object Adapter)

코바객체를 대신하여 스텁으로부터의 호출요청을 받아 전달해

주며, 코바객체에 객체 ID(객체참조) 를 할당한다.

객체 어댑터는 BOA(Basic Object Adapter) 와 POA(Portable

Object Adapter) 가 있으며 BOA 는 벤더마다 서로다른 방식을 사용

함으로 이식성이 떨어짐으로 JDK1.2 에서는 POA 만을 지원한다.

5) 스텁(Stub), 스켈레톤(Skeleton)

Corba 의 정적호출을 위해 사용되며 IDL 컴파일러로부터 해당구현

6) 동적 호출 인터페이스 (DII, Dynamic Invocation Interface)

스텁, 스켈레톤을 이용한 정적호출이아닌 런타임시 새로이 생성되

7) 동적 스켈레톤 인터페이스 (DSI, Dynamic Skeleton Interface)

스텁, 스켈레톤이 없는 코바객체에 대한 호출 요청을 처리하는데

- Corba 객체 참조는 분산환경에서 Corba 객체를 찾아내기 위한

객체 식별자(ID) 이다.

- 인터페이스 저장소 API 를 사용하여 객체 참조를 얻을 수 있다.

10) Corba Service

각각의 Corba 구현 벤더에서 제공해야 하는 시스템 차원의 서비스

- 네이밍(Naming) 서비스

가장기본적이면서도 가장 중요한 서비스이다.

- 생명주기 (Life Cycle) 서비스

객체의 생성, 소멸, 이동, 복사 등의 조작기능을 제공한다.

- 영속성 (Persistence) 서비스

ODBMS, RDBMS, File System 등에 객체를 저장하기 위한

- 외부화 (Externalization) 서비스

- 이벤트 (Event) 서비스

특정 객체에게 이벤트를 전달하여 새로운 서비스를 요구하거나

수행시키기 위한 서비스를 제공한다.

- 프로퍼티(Peoperty) 서비스

IDL을 통해 정의된 정적인 속성들에 동적으로 추가적인 속성을

- 관계 (Relationship) 서비스

- 질의 (Query) 서비스

코바객체에 대한 질의 서비스로써 SQL 을 포함하며 SQL3 및

OQL(Object Query Language)에 기반한다.

- 객체 트랜잭션 서비스(OTS, Object Transaction Service)

가장 주목받는 서비스 중의 하나이며 기존의 미들웨어로 많이

쓰이는 TP-Monitor(턱시도, 엔시나 등) 를 대체하는 차세대

미들웨어로써 Corba 가 주목받을 수 있는 중요한 서비스이다.

OTS 는 Flat Transaction, Nested Transaction 둘다를 지원하며

2-phase commit 방식이다.

- 동시성 제어 (Concurrency Control) 서비스

트랜잭션, 쓰레드간의 lock 을 관리하는 lock 관리자이다.

- 객체 시간 (Object Time) 서비스

- 라이센스 (Licensing) 서비스

- 객체 보안 (Object Security) 서비스

인증, 접근제어리스트(ACL, Access Control List), 신뢰도 등을

이 서비스는 미정부가 제정한 보안표준 등급인 C2 차원의

즉, ID, 암호 인정절차를 거치도록 하는 방법이다.

- 트레이딩(Trading) 서비스

Corba 트레이딩 서비스는 114 전화 안내와 같은 역할을 한다.

- 컬렉션 (Collections) 서비스

11) Corba Facilities

Corba Facilities 는 Corba Serice 와는달리 상위레벨의 서비스이며

여기에는 다음 두가지 외에 여러가지 Facilities 들이 존재한다.

- Mobile Agent

객체의 동적인 이동기능과 유용성을 지원하기 위한 토대를 제공

- Data Interchange

객체들 사이의 데이타 전송과 응용프로그램 수준의 상호호환을

12) Corba 3.0 에 포함될 기능들

- IIOP firewall proxy

- CORBA / DCOM 연동

- EJB 에 기반한 비즈니스 객체 골격구조

지금까지 Corba에서 많이 쓰이는 용어를 중심으로 살펴보았다.

Corba 는 여러가지 서비스를 제공한다.

즉, 실제 Corba 구현 제품을 내놓은 벤더들이 이 많은 기능을 모두

예로써 많이 쓰이는 Inprise 의 Visibroker for Java 에는 ORB 와 함께

트랜잭션 서비스를 위해서는 ITS 라는 제품을 추가로 사용해야 한다.

자바프로그래머들은 Corba 를 여러방법으로 이용할 수 있다.

IDL 을 모르는 개발자라도 Caffeine on Visibroker 를 이용하면 자바

인터페이스로 시작해서 IDL, 스텁, 스켈레톤 등을 얻을 수 있다.

그리고 JDK1.2 Core 내에는 기본적 서비스와 ORB 가 포함되어

또한, 이후에 설명할 RMI_OVER_IIOP 를 이용하면 RMI 를 이용해서

코바와 자바는 그 유명한 "ObjectWeb" 이라는 개념을 탄생시킨

다음 장에서는 장안의 화재(?)가 되고 있는 EJB 에 대해서 알아보자

Sun 의 Enterprise JavaBeans 스팩에 따르면 "EJB는 분산환경하의

즉, EJB 는 특정 User Interface 를 가지지 않는 서버측 컴포넌트

모델이며 Java 의 여러가지 Enterprise API(JNDI, RMI, JAVA IDL,

SERVLET & JSP, JMS, JTS, JTA, JDBC 등)들과 어우러져 또하나의

Sun 의 엔터프라이즈 시장을 위한 노력이 결실을 거두고 있는 것이

EJB 의 특징은 다음과 같다.

1) Enterprise Bean's instances 들은 Container 에 의해 RunTime

2) Enterprise Bean 는 environment properties를 수정함으로써

4) Client Access 는 Container 혹은 EJB Server(OS, DBMS 등)에

5) Enterprise Bean 이 EJB specification 에 정의된 standard

6) Enterprise Bean 는 재컴파일이나 소스코드 변경없이 애플리케이

EJB 가 돌아가기 위해서는 EJB 서버와 EJB 컨테이너가 필요하다.

대표적인 EJB 서버는 DBMS가 될 수있으며 OS 및 File System 이 될

이들 서버는 EJB 의 상태저장소 역할을 한다.

EJB 컨테이너는 EJB 가 동작하는 환경을 제공한다.

놀랍게도 현재 나와있는 EJB 서버는 100여가지가 넘는다.

BEA Weblogic Server, IBM 웹스피어 등과같은 덩치큰 컨테이너가

있는 반면 Voyager Server, OrbixHome, PowerTier 와 같은 불과

몇 메가에 달하는 thin 서버도 존재한다.

그럼 EJB 에 대해 좀더 자세히 알아보자

하나의 Enterprise JavaBeans 는 2개의 인터페이스와 1개의 클래스

javax.ejb.EJBHome 인터페이스를 상속하며 클라이언트는 JNDI

(Java Naming and Directory Interface) 를 이용하여 홈인터페이스를

javax.ejb.EJBObject 인터페이스를 상속하며 클라이언트는 홈

리모트 인터페이스는 Enterprise Bean 클래스를 위한 Proxy 이다.

즉, 클라이언트는 실제 Enterprise Bean 클래스내의 메소드를 직접

3) Enterprise Bean 클래스

엔티티빈일 경우는 javax.ejb.EntityBean 인터페이스를 구현하며

세션빈일 경우는 javax.ejb.SessionBean 인터페이스를 구현하며

EJB 는 크게 Session Bean과 Entity Bean빈으로 나뉜다.

Session Bean 은 또한 Statefull Session Bean 과 Stateless Session

Bean 으로 나뉘며 Entity Bean 은 Bean Managed Entity Bean 와

Container Managed Entity Bean 으로 나뉘어 진다.

1) Session Bean

일반적으로 말하는 컴포넌트(DCOM 등)가 Session Bean 이다.

Session Bean 은 서버상에서 실행하는 비즈니스 로직을 다루는

클라이언트는 JNDI 를 이용해 Home Interface 를 찾고 Home

인터페이스를 통해 Remote 객체에 대한 레퍼런스를 획득한다.

구현되어 있는 Enterprise Beans 객체내의 대응되는 메소드 호출

이러한 과정은 entity Bean 도 마찬가지다.

- Stateless Session Bean

클라이언트의 요청이 있을때 실행이 된다.

대표적인 사용예는 클라이언트의 요청을 받아 DBMS 에 쿼리를

보낸후 결과를 클라이언트로 리턴한다거나 다른 Session Bean

이나 Entity Bean 을 호출하는데 사용되어 질 수 있다.

- Statefull Session Bean

클라이언트의 요청이 있을때 실행되고 Socket 자원이나 JDBC

Connection 자원등의 상태정보를 파일시스템이나 DBMS 에 저장

2) Entity Bean

Entity Bean 은 IBM 에서 제안한 것으로 아주 재미있는 놈이다.

컨테이너내의 Entity Bean 객체들은 DBMS 혹은 File System 등에

하나의 Entity Bean 클래스는 데이타베이스내의 하나의 테이블,

Entity Bean 클래스 내의 데이타 멤버들은 테이블내의 하나의 필드

따라서 하나의 Entity Bean 객체는 DB 테이블내의 하나의

즉, 10개의 객체가 create 되었다면 10개의 레코드가 만들어졌다

이렇게 생성된 객체는 이후에 ejbFind~() 등의 메소드를 이용해서

(세션빈은 비 지속성이므로 find~ 메소드가 없어야만 한다)

Bean Managed entity Bean 인 경우는 개발자가 직접Enterprise Bean 내에

서 JDBC를 사용하여 DB 에 저장하고 읽어들인다.

Container Managed Bean 인경우는 데이타 멤버를 DBMS 에 저장

즉, 적당히 JDBC나 JSQL Code 를 삽입해 준다.

모든 EJB 컨테이너가 Entity Bean 을 지원하는 것은 아니다.

그것은 EJB 스팩상에서도 명시되었지만 현재까지 버전(1.1) 은

옵션이며 1년후에 나올 EJB2.0 에서는 필수조건이 된다고 한다.

위에서 설명한 Voyager Server는 Container Managed EntityBean이 지원되지

않으며, Oracle 8i는 엔티티빈을 아예 지원하지 않고OrbixHome에서

Container Managed Entity Bean 은 Oracle에서만 가능하고, IBM 웹스피어는

이제 EJB의 트랜잭션 처리에 대해서 알아보자

빈 개발자는 JTS 를 이용해 트랜잭션의 범위를 지정해 줄 수 있고

컨테이너 벤더는 JTA 를 이용해서 실제 트랜잭션 로직을 구현한다.

6. 기 타

java IDL 이 기초로 하고있는 내용은 다음과 같다

- IDL to Java Mapping : IDL의 각요소를 자바 언어 요소에 매핑한다.

- idltojava 컴파일러 : IDL 정의로부터 스텁과 스켈레톤 파일을 제공한다.

- IIOP를 지원하는 자바 ORB : 스텁과 스켈레톤간의 통신과 OA의 투명한

생성을 지원한다. 그리고 다양한 ORB 사이

의 통신을 지원한다

- 일시적인 객체 네임 서버(Tnameserv) : 계층적인 객체 공간으로부터

원격 객체에 대한 참조를 구할 수

있게 해준다.

- API 패키지의 org.omg.CORBA와 org.omg.CosNaming 패밀리 :

CORBA 와 자바객체를 통합하기 위해 필요한 자바 API 클래스와

인터페이스를 제공한다.

Object Times 에 실린 글을 보면 "Java + Corba = Java IDL" 라는 문구가

있다.

즉 java IDL 은 순수 자바 솔루션만으로 코바 프로그래밍을 가능하게 해준

다.

다음글은 Object Times의 기사를 발췌했다.

Sun사에서 Java2 플랫폼이 발표되면서 새롭게 등장한 특징 가운데 하나

는 Java 언어와 분산 표준 아키텍쳐인 CORBA와의 상호 연동을 지원하는

“Java IDL” 이라고 볼 수 있다. 프로그래머들이 특정 언어로 개발한 모듈

이 서로 다른 플랫폼이나 서로 다른 언어로 개발된 다른 모듈과 상호 연동

이 이루어진다면 개발된 프로그램이 훨씬 안정적이게 될 것이다. 새롭게

등장한 Java IDL이 바로 이러한 부분을 해결해 준다. 본 기사에서는 Java

2 플랫폼의 일부분으로 제공되는 Java IDL에 대한 개요와 CORBA와 어

떻게 연동할 수 있는지에 대해 살펴보고자 한다.

1) Java IDL의 정체

Java IDL은 JDK 1.2라고 알려진 Java 2 플랫폼의 한 부분이다. 이 Java

IDL은 IDL 스펙(Specification)을 Java 인터페이스로 컴파일해서 Java 언

어로 작성된 프로그램들이 CORBA를 구현한 모든 ORB와 연동할 수

있도록 한다. 즉, Java IDL은 IDL 컴파일러와 ORB를 포함하는 것이라고

생각하면 된다. Java 애플리케이션과 Java 애플릿들이 어떠한 ORB와도

상호 연동이 가능하며 ORB로 연결된 모든 시스템과도 연동이 가능하게

된다. 따라서, 이제는 애플릿도 ORB를 통해 구현 언어에 상관없이 기존

의 Legacy 시스템과 상호 연동이 가능하게 된다.

Java IDL에는 IIOP 를 이용한 분산 컴퓨팅을 위한 Java ORB가 포함되

어 있고, 다른 ORB와 Java 객체들을 연동시키기 위한 Stub과 Server

클래스들이 포함되어 있다. Java ORB는 CORBA/IIOP 2.0 스펙을 기반으

로 한 ORB이다. 그러나, 현재 버전에서는 단지 COSNaming 서비스만

지원되고 일시적(Transient)인 CORBA 객체들만 지원한다. 따라서 Java

ORB 상의 객체들은 서버의 프로세스가 살아 있을 동안에만 객체들이

존재하게 된다. 즉, 서버 프로세스가 끝나면 객체들도 소멸되게 된다.

3) Java Name 서버

Java IDL은 객체들을 트리 디렉토리 구조에 저장하기 위해 transient한

name 서버를 제공하고 있다. 이 name 서버는 CORBA의 Common

Object Services 스펙에 있는 Naming Service 스펙을 구현한 것이다.

Java IDL에서 이 name 서버를 구동시키기 위해서는 도스 창의 커맨드

라인(명령어 라인) 상에서 “tnameserv” 프로그램을 실행시켜야 한다.

예) c:\>tnameserv -ORBInitialPort 1234

ORBInitialPort 다음에 사용된 번호(1234)는 name 서버와 연결하기 위한

포트 번호에 해당한다. 디폴트로 tnameserv는 900포트에서 실행된다.

그러나 일반적으로 1024이하의 포트 번호들은 시스템 서비스 용으로 용

도가 제한되었기 때문에 1024 이하의 포트번호는 사용하지 않는 것이

바람직하다.

Name 서버는 트리 구조에 이름에 기반으로 객체 레퍼런스들을 저장한

다. 클라이언트는 이름을 가지고 객체 레퍼런스를 찾는다. Name 서버는

transient한 서버이기 때문에, 전체 디렉토리 구조는 tnameserv가 실

행을 멈추면 상실하게 된다.

4) JavaIDL ORB를 이용한 분산 애플리케이션 개발 과정

이제 JavaIDL ORB를 이용하여 분산 애플리케이션을 개발하는 과정을

살펴보자. 전체 개발 과정을 요약하면 다음과 같은 순서로 진행된다.

- IDL 인터페이스를 정의한다.

- 정의된 idl 스펙에 대해 “idltojava” 컴파일러를 이용하여 컴파일한다.

- 서버 클래스(프로그램)를 구현한다.

- 클라이언트 클래스(프로그램)를 구현한다.

- Name 서버/orb를 초기화 한다.

- 서버를 실행한다.

- 클라이언트를 실행한다.

6.2 RMI_OVER_IIOP

RMI_OVER_IIOP 는 RMI 이다.

차이점은 java.rmi 패키지에 있는 RMI는 JRMP 프로토콜을 사용하는데

반해 RMI_OVER_IIOP는 javax.rmi 패키지내에 포함되어 있으며 IIOP 프로

토콜상에서 재구현되었다.

RMI_OVER_IIOP 는 Sun 의 코바를 위한 또다른 노력이다.

RMI는 다른언어와의 이식성이 부족하다

왜냐하면 비표준 통신 프로토콜을 사용하기 때문에 Corba 객체와 통신할

수 없다.

RMI_OVER_IIOP 의 목적은 기존의 RMI 와 동일한방식으로 간편한 프로그

래밍을 제공하면서 CORBA 객체에 접근할 수 있게 하는 것이다.

현재 RMI_OVER_IIOP 는 베타버전까지 릴리즈 되 있으며

IIOP 를 위한 스텁을 생성하는 새로운 RMIC 컴파일러와 Call By value를

지원하는 새로운 idlj 컴파일러를 가지고 있다.

이제 RMI_OVER_IIOP의 새로운 면을 알아보자

1) 만일 네임 서비스를 위해 RMI registry 를 사용한다면 CosNaming 플러그

인과 함께 JNDI 를 사용하라

- 클라이언트 / 서버 코드에 다음과 같이 변경하라

- 기존의 RMI registry 의 lookup(), bind() 메소드를 사용하지 마라

RMI_OVER_IIOP에서는 JNDI 의 lookup()과 bind() 를 사용하라

즉, 아래와 같은 코드 대신에...

다음과 같은 코드를 사용하라

- 만일 클라이언트가 애플릿이라면 JNDI 의 CosNaming 플러그인에 this

를 전달하라

2) 만약 RMI registry 를 네임 서비스로 사용하지 않는다면 초기 리모트

객체의 레퍼런스를 bootstrapping 하기위한 여러가지 방법을 사용할

수 있다.

예를 들어 서버 코드는 RMI 객체 참조를 ObjectOutputStream으로

쓰고 클라이언트 코드에 보낸후 다시 역직렬화하는 Java Serialization

을 사용할 수 있다.

서버측에서는 스텁을 얻기 위해 PortableRemoteObject.toStub() 을

호출할수 있고, 그런다음 weiteObject() 를 이용해 스텁을 직렬화

한다.

그런 코드는 다음과 같은 모습일 것이다.

// myWombat 은 이제 myORB 에 연결되었다

// 같은 ORB 내의 다른 객체에 연결하기 위해서는

// 를 사용하라

클라이언트 측에서는 역직렬화를 위해 readObject() 를 사용한다.

// myWombat 은 이제 myORB 에 연결되었다

// 같은 ORB 내의 다른 객체에 연결하기 위해서는

// 를 사용하라

3) CosNaming 서버를 시작하기 위해 "tnameserv"를 사용하라

디폴트 포트 900번을 바꾸기 위해서는 "tnameserv -ORBInitialPort 1050"

과 같이 사용하라

4) 클라이언트와 서버를 실행하기 이전에 다음과 같은 옵션을 주어서 시작

하라.

만약 클라이언트가 애플릿이라면 다음과같은 applet tag 를 사용하라