IBM®
메인 컨텐츠로 가기
    Korea [국가변경]    이용약관
 
 
   
        제품    서비스 & 솔루션    고객지원 & 다운로드    회원 서비스    
메인 컨텐츠로 가기

한국 developerWorks  >  XML | SOA와 웹서비스  >

클라우드에 연결하기, Part 2: 하이브리드 클라우드 모델 실현하기

JMS 큐 데이터를 Amazon SQS 큐로 가져오기

developerWorks
문서 옵션
PDF format - Fits A4 and Letter

PDF - Fits A4 and Letter
47KB (14 pages)

Get Adobe® Reader®

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

샘플 코드

영어원문

영어원문


제안 및 의견
피드백

난이도 : 중급

Mark O'Neill, CTO, Vordel

원문 게재일 : 2009 년 4 월 28 일
번역 게재일 : 2009 년 7 월 21 일

이 기사는 클라우드 연결에 관한 주제를 다루는 3편의 기사로 구성된 시리즈의 두 번째 기사입니다. 하이브리드 클라우드 애플리케이션을 작성하는 데 가장 적합한 방법을 결정하기 위해 Part 1에서는 주요 클라우드 플랫폼 제공업체의 몇 가지 오퍼링을 살펴보았습니다. 시리즈의 Part 2인 이 기사에서는 로컬 애플리케이션 구성 요소와 클라우드 컴퓨팅을 결합한 하이브리드 클라우드 애플리케이션을 구현합니다. JMS 큐와 SQS 큐를 단일 하이브리드 애플리케이션으로 결합하는 방식으로 작성된 이 애플리케이션은 로컬에서 JMS 큐를 사용하고 클라우드에서 SQS 큐를 사용합니다.

하이브리드 모델

이 시리즈의 다른 기사

이 기사에서는 논의의 폭을 좁혀서 여러 클라우드 공급자 중 Amazon에만 연결되는 하이브리드 클라우드 애플리케이션을 작성하는 과정에 대해서만 중점을 두고 설명한다. 예제 애플리케이션인 HybridCloud는 JMS 큐로부터 데이터를 받아서 Amazon 클라우드에서 호스팅되는 Amazon SQS 큐로 보낸다. 그런 다음 Amazon SQS 큐에 저장되어 있는 데이터를 해당 큐에 대한 권한을 가지고 있는 다른 애플리케이션이 가져갈 수 있다.

이러한 일련의 과정을 예를 통해 살펴보자. 우선, 이미지 처리 애플리케이션을 이용해서 X선 이미지를 처리해야 하는 의료 기관이 있다. 이 의료 기관에서는 데이터를 임시로 저장하는 장소인 Amazon SQS 큐에 X선 이미지를 안전하게 쓴다. 각 X선 이미지의 파일 크기가 매우 크더라도 클라우드 컴퓨팅 공급자 입장에서는 큰 부담이 되지 않는다. X선 이미지가 저장되는 동시에 이미지 처리 애플리케이션이 큐에서 해당 이미지를 읽어온다. 이미지 처리 애플리케이션은 상당히 높은 처리 성능이 필요하기 때문에 하드웨어 용량을 빠르고 쉽게 추가할 수 있는 가상화된 환경((개인용 클라우드)에 전개하는 것이 이상적이다. 이미지 처리 애플리케이션은 X선 이미지를 처리한 후 다른 큐에 저장해 놓으면 의료 애플리케이션에서 해당 이미지를 다시 가져간다. 이 예는 X선 이미지만을 설명했지만 다른 모든 유형의 데이터에도 적용할 수 있는 예이다. X선 이미지의 경우에는 중요한 정보 보호 및 보안 문제가 대두되기 마련이다. 이 시리즈의 Part 3에서 클라우드와 관련된 보안 및 통제에 대해 살펴본다.

자주 사용하는 약어
  • FTP: File Transfer Protocol
  • API: Application Programming Interface
  • HTTP: Hypertext Transfer Protocol
  • JMS: Java™ Message Service
  • JNDI: Java Naming and Directory Interface
  • REST: Representational State Transfer
  • SQS: Simple Queue Service
  • URL: Uniform Resource Locator
  • XML: Extensible Markup Language

이 아키텍처의 장점은 다음과 같다.

  • 시스템이 동시에 온라인 상태에 있는 큐 기록자(의료 애플리케이션) 또는 큐 판독자(이미지 처리 애플리케이션)에 의존하지 않는다. 단순하게 두 애플리케이션 간의 FTP를 통해서 파일이 전송되는 경우에는 두 애플리케이션 중 하나만 오프라인으로 전환되도 시스템이 중단되지만 Amazon SQS 큐를 사용하면 복원성 높은 시스템을 갖출 수 있다.
  • 시스템 작업에 전혀 영향을 주지 않은 채로 양쪽 어디에나 용량을 추가할 수 있다. 예를 들어, 이미지 처리 애플리케이션측에 컴퓨팅 용량을 증가시켜서 이미지 처리 속도를 2배로 높일 수 있다. 의료 애플리케이션에서는 이러한 변화를 인식하지 못한 채로 X선 이미지 파일을 Amazon SQS 큐에 계속 쓴다.
  • 이 하이브리드 모델은 클라우드 컴퓨팅 사용을 고려하고 있는 아키텍트에게 널리 권장되고 있는 모델이다. 모든 것을 하나의 클라우드 컴퓨팅 플랫폼에 의존하거나 클라우드 컴퓨팅을 완전히 배제하는 형태의 극단적인 방법보다는 클라우드 컴퓨팅을 전술적으로 유연하게 채택하는 방법이 효과적이다. 로컬 애플리케이션측에서는 가상화(개인용 클라우드)를 통해 비교적 쉽게 용량을 획기적으로 늘릴 수 있으며, 이는 이미지 처리와 같이 프로세서를 많이 이용하는 애플리케이션의 성능에 큰 영향을 줄 수 있는 중요한 특징이다. 클라우드측에서는 애플리케이션이 서로 연결되지 않은 네트워크에 있다고 하더라도 Amazon SQS 서비스가 애플리케이션 간의 큐잉 서비스를 제공한다.



위로


Amazon SQS 클라우드 서비스에 사용자 식별하기

HybridCloud Java 애플리케이션에서는 Amazon SQS를 사용한다(애플리케이션 소스 코드는 다운로드 참조). HybridCloud 애플리케이션은 인증된 웹 서비스를 통해 Amazon SQS 클라우드에 연결된다. 이 인증을 사용하는 데는 크게 두 가지 이유가 있다. 첫 번째 이유는 Amazon에서 부과하는 Amazon SQS에 대한 사용료를 책정하기 위해 개별 사용량을 추적해야 하기 때문이며, 두 번째 이유는 개별 큐에 대한 액세스를 제어해야 하기 때문이다. HybridCloud 애플리케이션은 분명 개인용 X선 이미지가 포함된 Amazon SQS 큐에 액세스하려는 써드파티에 적합하지 않다.

Amazon SQS 큐를 사용하기 위해서는 먼저 Amazon.com 로그인이 필요한 AWS(Amazon Web Services)의 사용자가 되어야 한다. Amazon.com 로그인을 가지고 있는 사용자는 꽤 많이 있을 것이다. Amazon.com 사이트에서 책을 한 번이라도 구입해 본 사람이라면 이미 Amazon.com 로그인을 가지고 있을 테니 말이다. 하지만 Amazon.com 로그인은 첫 번째 단계에 불과하다. AWS를 이용하려면 "Access Key ID" 및 연결된 보안 키가 있어야 한다.

Amazon Web Services 모델의 Secret Access Key는 Amazon.com과 Amazon 웹 서비스에 연결하고 있는 개발자 사이에 공유되는 비밀이라고 생각할 수 있다. 그에 반해 Access Key ID는 인증 용도가 아닌 식별 용도로 사용되기 때문에 비밀이 아니다. Part 3에서 이러한 두 키에 대해 자세히 설명하며 다른 클라우드 컴퓨팅 공급자가 사용하고 있는 대체 인증 모델에 대해서도 살펴본다.

Amazon Web Services에 등록한 후 Access Key ID와 Secret Access Key를 받은 후 개발자는 특정 서비스에 가입할 수 있다. 이 기사의 예제에서는 Amazon.com SQS 서비스에 가입한다. SQS와 같은 서비스를 사용하려면 Amazon Web Services에 신용 카드를 등록해야 한다. 신용 카드의 세부정보는 아마존에 저장되며, 결제일에 지불되지 않고 바로 결제되는 선불형 모델이다. 서비스에 등록하기 전에 SQS 서비스에 액세스하려고 하면 "The AWS Access Key Id needs a subscription for the service"라는 예외 메시지가 표시된다.




위로


하이브리드 애플리케이션 설계하기

앞에서 설명한 대로 하이브리드 애플리케이션은 데이터를 로컬로 처리하면서 Amazon SQS 클라우드 서비스를 이용하기 때문에 로컬 구성 요소와 클라우드 구성 요소를 가지고 있다. 이 애플리케이션 설계에서 데이터는 JMS 큐(메인프레임 애플리케이션)에서 검색된 후 HTTP GET 및 POST를 사용하여 Amazon SQS 큐로 전송된다. 애플리케이션의 언어로는 Java를 사용한다.

애플리케이션에는 다음 세 가지 주요 부분이 있다.

  1. Amazon SQS 큐를 작성한다.
  2. 로컬 데이터(JMS 큐)를 읽어서 Amazon SQS 큐에 저장한다.
  3. Amazon SQS 큐에서 응답 데이터를 검색한다.

Amazon SQS 이용하기에서 설명하는 애플리케이션 코드를 보면 로컬 JMS 큐 연결과 Amazon SQS 큐 연결에 대한 처리 방법이 비슷하다는 것을 알 수 있다.




위로


Amazon SQS 이용하기

HybridCloud Java 애플리케이션에서 먼저 Amazon SQS 클래스를 가져온다(Listing 1 참조).


Listing 1. Amazon SQS 클래스 가져오기
Import com.amazonaws.queue.*;

HybridCloud 애플리케이션에서는 Amazon SQS를 사용하여 큐에 데이터를 쓴 후 나중에 이 큐에서 데이터를 다시 읽어온다. Amazon SQS는 인증된 웹 서비스 연결을 통해 연결된다. 이때 클라이언트는 Amazon Access Key ID를 통해 식별되고 Amazon Secret Key ID를 통해 인증된다. Java 코드에서 Amazon SQS를 사용하려면 먼저 Amazon Access Key ID와 Amazon Secret Key ID를 코드에 삽입해야 한다(Listing 2 참조).


Listing 2. Amazon 키 설정하기
String accessKeyId = "12345678901234567890";
String secretAccessKey = "abcdefghijklmnopqrstuvwxyz";

그런 다음 Amazon SQS의 Access Key ID와 Secret Key ID를 변수로 전달하여 HTTP 클라이언트 구현을 인스턴스화한다(Listing 3 참조).


Listing 3. Amazon SQS http 클라이언트 인스턴스화하기
AmazonSQS service = new AmazonSQSClient(accessKeyId, secretAccessKey);

이제 Amazon SQS 클라이언트 오브젝트가 인스턴스화되었다. 그러나 아직까지는 인터넷을 통해 Amazon SQS 서비스에 연결되어 있지 않은 상태이다. 따라서 다음 단계에서는 Amazon SQS 클라우드 서비스에서 큐를 작성하게 된다.




위로


Amazon SQS 큐 작성하기

이 애플리케이션에서는 큐를 사용하여 X선 이미지 파일을 저장한다. Amazon SQS 큐를 사용하려면 먼저 작성해야 한다. 이 큐에는 이름을 지정해야 하며, 이 예제에서는 "imageQueue"라는 이름을 지정한다. 바로 이 큐에 HybridCloud 애플리케이션이 X선 이미지 파일을 저장하게 된다(Listing 4 참조).


Listing 4. Amazon 큐 작성하기
CreateQueueRequest request = new CreateQueueRequest();
request.setQueueName("imageQueue");

이제 Amazon SQS 서비스 오브젝트의 메소드인 createQueue를 호출하여 Amazon Web Services에 대한 HTTP GET(REST 유형) 요청을 통해 큐를 작성한다(Listing 5 참조).


Listing 5. Amazon 큐 작성하기
CreateQueueResponse response = service.createQueue(request);

이렇게 하면 Amazon SQS의 웹 서비스에 대한 REST 유형 호출이 작성된다. Amazon SQS 큐를 작성하기 위해 코드를 실행하면 Amazon SQS에 대한 연결에 전송되는 REST 유형 URL이 검색된다. 이 URL에서는 일반 텍스트로 된 Access Key ID, 서명(Secret Key ID 사용) 및 imageQueue라는 이름으로 작성된 실제 SQS 큐를 볼 수 있다. 물론 실제 Secret Key ID는 전송되지 않는다. 메시지의 서명 구성 요소(Listing 6 참조)는 Secret Key ID에 대한 소유 증명을 제공한다. 키의 소유자만 서명 구성 요소를 작성할 수 있다.


Listing 6. Amazon Web Services로 전송된 REST 유형 웹 서비스 요청
queue.amazonaws.com?Action=CreateQueue&SignatureMethod=HmacSHA256&AWSAccessKeyId
=12345678901234567890&QueueName=imageQueue&SignatureVersion=2&Version
=2008-01-01&Signature=U859J2Hoi5qBqlQx1R18dKPgSgrgjlOiJIDD8ug9FPI%3D&Timestamp
=2009-04-01T03%3A25%3A13.575Z

서명은 QueueName을 사용해서 작성될 뿐만 아니라 시간 소인을 기반으로 계산되기도 한다. 따라서 공격자가 단순히 Amazon SQS에 대한 요청을 캡처하여 재생하는 방법으로 올바른 사용자를 모방할 수가 없다. 공격자가 Amazon SQS 서비스에 대한 요청을 다시 전송하게 되면 요청의 서명 반복이 캡처-재생 공격으로 식별되고 Amazon Web Services가 해당 요청을 차단한다.

이제 이미지 데이터를 로드할 imageQueue 큐가 작성되었으므로 로컬 JMS 큐의 소스 데이터를 제공할 수 있다. 이 로컬 큐 자체는 가상화된 환경(로컬 클라우드)을 기반으로 할 수 있다.




위로


로컬 JMS 큐의 데이터 검색하기

지금까지는 Amazon SQS 큐를 작성했으므로 이제부터는 하이브리드 애플리케이션의 로컬 부분을 살펴볼 차례이다. Amazon SQS 큐에 데이터를 공급하기 전에 로컬 큐의 데이터를 먼저 읽어야 한다. 로컬 큐에 사용된 단계와 Amazon SQS 큐에 연결하는 데 필요한 단계를 비교해 보는 것이 좋다.

필수 Java 라이브러리 특히 JMS jar 파일과 JNDI jar 파일을 가져온다. 이러한 파일은 Java 애플리케이션에서 JMS를 사용하는 데 사용된다(Listing 7 참조).


Listing 7. JMS 클래스 가져오기
import javax.jms.ConnectionFactory;
import javax.jms.Connection;
import javax.jms.Session;
import javax.jms.MessageProducer;
import javax.jms.MessageConsumer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.Message;
import javax.jms.TextMessage;
//Required for JNDI.
import javax.naming.*;

JMS 연결을 위해 JNDI를 설정한다. 예를 들어, 파일 시스템에서 데이터를 읽어오는 경우 Listing 8의 코드를 사용할 수 있다.


Listing 8. 로컬 큐의 파일 읽기
ConnectionFactory myConnFactory;
Queue myQueue;
Hashtable env;
Context ctx = null; 
env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory");
env.put(Context.PROVIDER_URL, "file:///C:/Images");	
ctx = new InitialContext(env);

이제 큐 및 연결 팩토리를 작성한다(Listing 9 참조).


Listing 9. 큐 및 연결 팩토리 작성하기
String MYCONNECTIONFACTORY = "MyConnectionFactory";
String MYQUEUE = "MyQueue";
myConnFactory = (javax.jms.ConnectionFactory) ctx.lookup(MYCONNECTIONFACTORY);
myQueue = (javax.jms.Queue)ctx.lookup(MYQUEUE);

그런 다음 연결을 작성하고 연결 내에 세션을 작성한다(Listing 10 참조).


Listing 10. 로컬 JMS 큐에 대한 연결 작성하기
Connection myConn = myConnFactory.createConnection();
Session mySess = myConn.createSession(false, Session.AUTO_ACKNOWLEDGE);

큐의 메시지를 읽으려면(이 경우에는 파일 시스템에 대한 JNDI ID를 사용하므로 결과적으로 파일 시스템에서 읽어오는 것과 같음) Listing 11의 코드를 사용한다.


Listing 11. 로컬 JMS 큐에서 읽어오기
MessageConsumer myMsgConsumer = mySess.createConsumer(myQueue);
myConn.start();
Message msg = myMsgConsumer.receive();

이제 로컬로 검색한 메시지의 내용을 검사한다(Listing 12 참조).


Listing 12. 로컬에서 검색한 메시지의 내용 검사하기
if (msg instanceof TextMessage) {
                TextMessage txtMsg = (TextMessage) msg;
                String inputText = txtMsg.getText());
}

마지막으로 JMS 큐에 대한 연결을 닫는다(Listing 13 참조).


Listing 13. 로컬 JMS 큐에 대한 연결 닫기
mySess.close();
myConn.close();

이 시점에서는 Amazon SQS 큐에 쓸 데이터가 inputText라는 문자열에 저장되어 있다. 이 문자열은 다음에 Amazon SQS 큐에 쓸 내용이다.




위로


Amazon SQS 큐에 쓰기

Amazon SQS 큐에 전달된 데이터는 문자열로 전송된다. 데이터가 이미지라고 하더라도 Amazon SQS에는 문자열로 전송된다. 아래 Listing 14에서는 Amazon SQS 큐에 메시지를 전송하는 데 사용되는 SendMessageRequest 오브젝트에 이 문자열을 설정하는 방법을 보여 준다.


Listing 14. Amazon SQS 큐에 메시지 전송하기
SendMessageRequest sendRequest = new SendMessageRequest();
sendRequest.setMessageBody(inputText);

또한 큐 이름을 앞에서 작성한 큐 이름과 동일한 이름으로 설정해야 한다(Listing 15 참조).


Listing 15. Amazon SQS에서 큐 이름 설정하기
sendRequest.setQueueName("imageQueue");

이제 Amazon SQS 오브젝트의 sendMessage 메소드를 사용하여 Amazon SQS 큐에 메시지를 보낸다(Listing 16 참조).


Listing 16. Amazon SQS 큐에 데이터 전송하기
SendMessageResponse response = service.sendMessage(sendRequest);




위로


Amazon SQS 응답 읽기

다음 단계에서는 Amazon SQS 큐의 응답을 읽는다. 먼저 ReceiveMessageRequest 오브젝트를 작성한다(Listing 17 참조).


Listing 17. Amazon SQS 큐의 데이터를 검색하기 위한 ReceiveMessageObject 작성하기
receiveRequest = new ReceiveMessageRequest();

그런 다음 큐 이름을 설정한다(Listing 18 참조).


Listing 18. Amazon SQS 큐의 데이터를 검색하기 위한 ReceiveMessageObject 작성하기
receiveRequest.setQueueName("imageQueue");

이제 receiveMessage 메소드를 사용하여 Amazon SQS 큐의 메시지를 받으려고 시도한다(Listing 19 참조).


Listing 19. Amazon SQS 큐의 응답 받기
ReceiveMessageResponse response = service.receiveMessage(receiveRequest);

클라우드에서 검색한 메시지의 메시지 ID 및 메시지 본문을 포함한 결과를 검사하기 위해(Listing 20 참조) 해당 결과를 표준 출력으로 전달한다.


Listing 20. Amazon SQS 큐의 응답 검사하기
if (response.isSetReceiveMessageResult()) {
ReceiveMessageResult  receiveMessageResult = response.getReceiveMessageResult();
java.util.List<Message> messageList = receiveMessageResult.getMessage();
for (Message message : messageList) {
if (message.isSetMessageId()) {
                        System.out.print("            MessageId");
                        System.out.print("                " + message.getMessageId());
                        System.out.println();
                    }
                    if (message.isSetBody()) {
                        System.out.print("            Body");
                        System.out.println();
                        System.out.print("                " + message.getBody());
                        System.out.println();
                    }
}




위로


XML 게이트웨이를 통해 로컬 애플리케이션을 클라우드에 연결하기

이 기사에서는 Java 코드를 사용하여 로컬 애플리케이션을 클라우드 컴퓨팅 환경에 연결했다. 이 방법은 개발자에게는 이상적이지만 사용량, 트래픽 및 사용 가능성을 모니터링하는 네트워크 운영 팀의 입장에서는 애플리케이션의 일부로서 Amazon 클라우드 컴퓨팅 서비스에 대한 연결을 제어하지 못한다. 또한 클라우드 컴퓨팅 연결을 변경하려면 코드도 변경해야 한다. 이 기사의 범위를 벗어나는 주제이기는 하지만 네트워크 인프라를 사용하여 로컬 JMS 큐와 Amazon SQS 클라우드 서비스를 하나의 연결로 통합한 후 이 연결을 네트워크 운영 팀에서 제어할 수도 있다.

로컬 애플리케이션 구성 요소(예: JMS 큐)를 클라우드에 연결하려면 클라우드 컴퓨팅 커넥터가 포함된 XML 게이트웨이가 필요하다(게이트웨이에 대한 예제는 참고자료 참조). JMS 큐를 Amazon SQS 큐에 연결하려면 JMS 큐의 데이터가 Amazon 클라우드 서비스로 전달되도록 연결 필터를 끌어놓아야 한다.

케이블 TV 셋톱 박스를 생각하면 이해하기가 쉬울 것이다. 이 셋톱 박스는 로컬 인프라(TV)를 클라우드(케이블 TV 운영자)에 연결한다. XML 게이트웨이는 로컬 케이블 셋톱 박스의 역할을 수행한다. 이 게이트웨이는 클라우드 서비스에 대한 연결을 제공할 뿐만 아니라 해당 연결에 대한 모니터링 및 보안 기능도 제공한다.




위로


요약

이 시리즈의 다른 기사

Java 애플리케이션을 사용하여 로컬 JMS 큐와 Amazon SQS 클라우드를 연결하는 방법을 살펴보았다. 이 HybridCloud 애플리케이션은 로컬 리소스(JMS 큐)와 클라우드 기반 리소스(Amazon SQS)를 사용하여 이미지를 공유하는 예제 작업을 수행한다. 네트워크 레벨에서 Amazon SQS에 대한 연결이 URL을 통해 전달되는 매개변수를 사용하여 HTTP GET 및 PUT 방식으로 전송되기는 하지만 비교적 많이 비슷한 메소드를 사용하여 로컬 큐와 Amazon SQS 큐에 연결할 수 있다.

이 시리즈의 마지막 기사인 Part 3에서는 클라우드 컴퓨팅과 관련된 통제 및 보안 문제를 다룬다. 다양한 클라우드 공급자가 사용하고 있는 인증 모델을 살펴본 후 개인 정보 보호, 규제 준수 및 DoS(Denial-of-Service) 공격 차단 등을 위해 고려해야 하는 사항에 대해 설명한다.





위로


다운로드 하십시오

설명이름크기다운로드 방식
Hybrid Cloud Sample AppHybridCloud.zip3KBHTTP
다운로드 방식에 대한 정보


참고자료

교육

제품 및 기술 얻기

토론


필자소개

Mark O'Neill은 XML 네트워킹 회사인 Vordel의 CTO이다. 그가 집필한 "Web Services Security"와 "Hardening Network Security" 모두 McGraw-Hill/Osborne Media에서 출판되었다. Vordel의 제품 개발 로드맵에 대한 감독 업무를 맡고 있으며 전세계에 있는 Global 2000 회사 및 정부에게 XML, 웹 서비스 및 SOA 기술의 전략 및 전술적 채택에 대한 조언을 제공하고 있다. Trinity College Dublin에서 수학 및 심리학을 전공하고 Oxford University에서 신경망 프로그래밍 자격 과정을 마쳤으며 매사추세츠의 보스톤에 살고 있다.




기사에 대한 평가


보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오.



 


 


 


이 문서 북마킹 하기

mar.gar.in mar.gar.in naver naver eolin eolin del.icio.us del.icio.us





위로


IBM, IBM 로고, ibm.com, DB2, developerWorks, Lotus, Rational, Tivoli 및 WebSphere는 미국 또는 기타 국가에서 사용되는 International Business Machines Corporation의 상표 또는 등록 상표이다. 이와 함께 기타 IBM 상표가 기재된 용어가 상표 기호(® 또는 ™)와 함께 이 정보에 처음 표시된 경우, 이와 같은 기호는 이 정보를 발행할 때 미국에서 IBM이 소유한 등록 상표 또는 일반 법적 상표이다. 또한 이러한 상표는 기타 국가에서 등록 상표 또는 일반 법적 상표이다. 현재 IBM 상표 목록은 웹 "저작권 및 상표 정보"에 있다. Adobe, Adobe 로고, PostScript 및 PostScript 로고는 미국 또는 기타 국가에서 사용되는 Adobe Systems Incorporated의 상표 또는 등록 상표이다. Java 및 모든 Java 관련 상표는 미국 또는 기타 국가에서 사용되는 Sun Microsystems, Inc.의 상표이다. 기타 회사, 제품 및 서비스 이름은 해당 회사의 상표 또는 서비스표이다. 기타 회사, 제품, 및 서비스명은 다른 상표나 서비스 마크일 수 있습니다.

developerWorks 콘텐트를 다른 사이트에 전재하기:
developerWorks 콘텐트에 대한 저작권은 IBM에 있습니다. IBM의 서면 허가나 원본 저자의 허락이 없이는 전재를 금합니다. 저희 콘텐트를 전재하시려면 IBM developerWorks 담당자 에게 문의하십시오.
    IBM 소개 개인정보 보호정책 문의