XML 메시징, 1 부

XML 메시징은 빠르게 성장하는 동적 IT 영역을 나타내며 동시에 흥미롭고 지루한 상황입니다. B2B 교환 및 기타 형태의 비즈니스 간 전자 통신이 성장함에 따라 XML 메시징이 그 어느 때보 다 널리 배포 될 것입니다.

전체 "XML 메시징"시리즈 읽기 :

  • 1 부 : 사용자 지정 XML 메시지를위한 간단한 XML 메시지 브로커 작성
  • Part 2 : SOAP 방식의 XML 메시징
  • Part 3 : JAXM 및 ebXML, XML 메시징의 새로운 표준 설정

이 기사에서는 먼저 XML 메시징과 이것이 유용한 이유를 살펴볼 것입니다. 그런 다음 메시지 라우팅, 변환 및 브로커 링을 포함한 특정 XML 메시징 기능을 살펴 보겠습니다. 마지막으로 XML 브로커의 간단한 예를 살펴 보겠습니다. 개념을 읽고 이해 한 후에는 XML 메시징 솔루션 구현에 적합한 시나리오를 명확하게 이해해야합니다.

XML 메시징이란 무엇입니까?

탐색을 시작하려면 XML 메시징의 기본 전제와 메시징 이라는 용어가 의미 하는 바를 이해해야합니다 . 이 기사에서는 메시지 를 다음과 같이 정의 합니다.

소프트웨어 응용 프로그램간에 함께 보내거나받는 데이터 필드 모음입니다. 메시지에는 헤더 (메시지에 대한 제어 정보 저장)와 페이로드 (메시지의 실제 콘텐츠)가 포함됩니다.

메시징은 메시지를 사용하여 다른 시스템과 통신하여 일종의 기능을 수행합니다. RPC (Remote Procedure Call) 지향 통신과는 달리 작업을 수행하기 위해 메시지를 보내고 받기 때문에 통신을 메시지 지향이라고합니다. 간단한 비유가 도움이 될 수 있습니다. 메시징을 애플리케이션 용 이메일로 생각하면됩니다. 실제로 메시징에는 이메일 메시지를 서로에게 보내는 개인의 많은 속성이 있습니다.

과거에는 메시지 지향 시스템을 사용하거나 작업 할 때 Tibco의 Rendezvous, IBM의 MQSeries 또는 JMS 공급자와 같은 일종의 MOM (메시지 지향 미들웨어) 제품을 사용하여 메시지를 비동기 (단방향) 패션. 오늘날의 메시징은 반드시 MOM 제품을 사용하고 있음을 의미하는 것은 아니며 반드시 비동기 적으로 통신하고 있음을 의미하지는 않습니다. 대신 메시징은 동기 (양방향) 또는 비동기 일 수 있으며 MOM 제품뿐만 아니라 HTTP 또는 SMTP와 같은 다양한 프로토콜을 사용할 수 있습니다.

왜 XML 메시징인가?

메시징을 사용하여 시스템을 개발하려는 이유는 무엇입니까? 메시징을 유용한 디자인 기술로 만드는 것은 무엇이며 어떤 이점이 있습니까? 앞서 언급했듯이 네트워크를 통해 서로 통신하기 위해 두 응용 프로그램이 필요한 경우 RPC 또는 메시지 지향의 두 가지 대안 중에서 선택할 수 있습니다. RPC 기반 접근 방식 (RMI가이 범주에 속함)을 사용한다는 것은 프로 시저 호출의 클라이언트 (또는 호출자)가 호출하려는 프로 시저를 알고 프로 시저에 전달할 매개 변수를 알고 있음을 의미합니다. 또한 호출자는 호출 된 서버 (애플리케이션)가 요청을 완료하는 동안 기다리기를 원합니다.

두 번째 접근 방식 (메시지 지향)에서 호출자는 호출 될 정확한 절차를 반드시 알 필요는 없지만 대신 클라이언트와 서버 모두에 알려진 특정 형식의 메시지를 만듭니다. 클라이언트는 메시지를 만든 다음 네트워크를 통해 서버로 보냅니다. 따라서 클라이언트는 서버 또는 서버의 절차에 의존하지 않고 메시지 형식에 의존합니다. 또한 통신은 비동기 방식으로 발생하기 때문에 클라이언트가 요청을 보내지 만 응답을 기다리지 (차단)하지 않습니다. 이렇게하면 서버를 사용할 수 없게 되더라도 (예 : 크래시) 클라이언트가 계속 작동 할 수 있습니다. 클라이언트가 서버와 더 독립적 인이 디자인은 더 느슨하게 결합 된 것으로 간주됩니다.

메시지 지향 설계를 사용할지 여부를 평가할 때 이러한 시스템의 장단점을 이해하는 것이 중요합니다. 장점은 다음과 같습니다.

  • 느슨한 결합
  • 더 쉬운 메시지 라우팅 및 변환
  • 보다 유연한 페이로드 (예 : 바이너리 첨부 파일 포함 가능)
  • 여러 메시지를 함께 사용하여 주어진 프로 시저를 호출 할 수 있습니다.

일반적으로 메시지 지향 접근 방식은 RPC 접근 방식보다 더 유연합니다.

이제 몇 가지 단점이 있습니다.

  • 메시지를 통한 클라이언트 / 서버 상호 작용을 개발하는 것은 RPC로부터의 또 다른 수준의 간접적 인 것을 나타 내기 때문에 RMI와 같은 RPC 접근 방식에 비해 메시지 지향적 접근 방식을 사용하여 클라이언트 / 서버 상호 작용을 개발하려면 더 많은 작업이 필요합니다. 클라이언트 측 (RPC 접근 방식의 프로 시저 호출과 비교)에서 메시지를 생성하고 메시지 처리 코드를 사용하는 서버 측에서 복잡성이 추가됩니다. 복잡성이 추가 되었기 때문에 메시지 지향 디자인은 이해하고 디버깅하기가 더 어려울 수 있습니다.
  • 메시지가 전송 된 프로그래밍 언어에 대한 유형 정보가 손실 될 위험이 있습니다. 예를 들어 Java의 double은 메시지에서 double로 번역되지 않을 수 있습니다.
  • 대부분의 경우 메시지가 만들어진 트랜잭션 컨텍스트는 메시징 서버로 전파되지 않습니다.

장단점을 고려할 때 언제 메시지 지향 접근 방식을 사용해야합니까? 가장 일반적인 시나리오는 클라이언트 / 서버 통신이 인터넷을 통해 이루어지고 클라이언트와 서버가 다른 회사에 속할 때 발생합니다. 이 시나리오에서는 두 회사가 절차 인터페이스에 동의하도록하는 것이 상당히 어려울 수 있습니다. 또한 회사가 동일한 프로그래밍 언어를 사용하고 싶지 않을 수도 있습니다. 또 다른 예로, 관련된 회사는 비동기 통신 모델을 사용하여 어느 쪽도 다른 애플리케이션의 가동 및 실행에 의존하지 않을 수 있습니다.

또 다른 매력적인 메시징 시나리오는 이벤트가 생성되고 이해 당사자가 사용하는 이벤트 기반 시스템을 개발할 때 발생합니다. 대부분의 GUI는 이벤트 기반입니다. 예를 들어 이해 당사자가 이벤트를 수신하고이를 기반으로 몇 가지 작업을 수행하는 마우스 클릭 이벤트를 생성 할 수 있습니다. 이 시나리오에서 메시징 접근 방식을 사용하면 이벤트 (또는 시스템의 작업)와 서버에서 수행되는 이벤트에 대한 시스템의 반응 간의 종속성을 제거 할 수 있습니다.

이제 메시징에 대해 조금 이해 했으므로 방정식에 XML을 추가 할 준비가되었습니다. 메시징에 XML을 추가하면 메시지에 대해 유연한 데이터 형식화 언어를 사용할 수 있습니다. 메시징에서 클라이언트와 서버는 모두 메시지 형식에 동의해야합니다. XML은 많은 데이터 형식화 문제를 결정하고 Rosetta Net과 같은 다른 XML 표준을 추가하여이를 쉽게 만듭니다. 메시지 형식을 만드는 데 추가 작업이 필요하지 않습니다.

XML 메시지 브로커는 무엇을합니까?

메시지 브로커는 메시지 지향 시스템에서 서버 역할을합니다. 메시지 브로커 소프트웨어는 수신 한 메시지에 대해 작업을 수행합니다. 이러한 작업에는 다음이 포함됩니다.

  • 헤더 처리
  • 보안 검사 및 암호화 / 복호화
  • 오류 및 예외 처리
  • 라우팅
  • 기도
  • 변환

헤더 처리

헤더 처리는 일반적으로 XML 브로커 내에서 메시지 수신시 메시지에서 수행되는 첫 번째 기능 중 하나입니다. 헤더 처리에는 수신 메시지의 헤더 필드 검사 및 일부 기능 수행이 포함됩니다. 헤더 처리에는 수신 메시지에 추적 번호를 추가하거나 메시지를 처리하는 데 필요한 모든 헤더 필드가 있는지 확인하는 것이 포함될 수 있습니다. 아래의 XML 메시지 예제에서 메시지 브로커는 to헤더 필드를 확인하여이 메시지의 올바른 대상인지 확인할 수 있습니다 .

보안 검사 및 암호화 / 복호화

보안 관점에서 메시지 브로커는 여러 가지 다른 작업을 수행 할 수 있지만 대부분의 경우 보안의 "큰 3"인 인증, 권한 부여 및 암호화를 수행하기를 원할 것입니다. 먼저 메시지에 인증에 사용할 수있는 데이터가 포함되어 있음을 확인하면 메시지 브로커는 보안 데이터베이스 또는 디렉터리에 대해 메시지를 인증합니다. 둘째, 메시지 브로커는 이러한 유형의 메시지 및 권한있는 주체로 수행 할 수있는 작업을 승인합니다. 마지막으로 메시지 브로커에 도착하는 메시지는 일부 암호화 체계를 사용하여 암호화 될 수 있습니다. 메시지를 추가로 처리하기 위해 메시지를 해독하는 것은 브로커의 책임입니다.

오류 및 예외 처리

오류 및 예외 처리는 메시지 브로커가 수행하는 또 다른 중요한 기능입니다. 일반적으로 메시지는 브로커에 전송 된 메시지에 충분하거나 정확한 정보가 포함되어 있지 않을 때 발생하는 오류 메시지와 함께 클라이언트 (동기 호출 가정)에 응답합니다. 오류 또는 예외에 대한 또 다른 원인은 요청을 처리 할 때 발생합니다 (실제로 메시지의 페이로드를 기반으로 프로 시저 / 메소드를 호출 함).

라우팅

메시지 라우팅은 메시지에 대한 분기 논리입니다. 메시지의 두 가지 다른 수준에서 발생합니다. 첫 번째 헤더 수준 라우팅은 들어오는 메시지가이 응용 프로그램에 바인딩되어 있는지 또는 다른 응용 프로그램으로 다시 전송되어야하는지 여부를 결정합니다. 두 번째 페이로드 라우팅은 브로커가 메시지가이 응용 프로그램에 바인드되었음을 확인하면 호출 할 프로 시저 또는 방법을 결정합니다. 이 두 가지 유형의 라우팅을 함께 사용하면 메시지를 처리 ​​할 때 다양한 기능을 사용할 수 있습니다.

기도

호출은 수신 메시지에 포함 된 데이터 (페이로드)를 사용하여 실제로 메서드를 호출하거나 호출하는 것을 의미합니다. 그러면 브로커를 통해 클라이언트로 반환되는 결과가 생성 될 수 있습니다. 호출되는 것은 EJB 세션 빈, 클래스 메소드 등을 포함하여 무엇이든 될 수 있습니다.

변환

변환은 메시지를 다른 형식으로 변환하거나 매핑합니다. XML에서 XSLT는 일반적으로 변환 기능을 수행하는 데 사용됩니다.

XML 메시지의 예

다음은 샘플 애플리케이션에서 사용되는 XML 메시지입니다. 머리글과 본문 부분을 확인하십시오. 이 예제는 "saveInvoice"메시지 유형으로 본문에 저장해야하는 송장이 포함되어 있습니다.

   companyReceiver companySender saveInvoice John Smith 123 George St. Mountain View CA 94041 Company A 100 Main St. Washington DC 20015 IBM A20 Laptop 1 2000.00       

You may wonder whether there is an advantage to developing a custom XML message. Why not use one of the existing message standards like ebXML or SOAP to encapsulate the payload (the invoice)? There are a couple of reasons. The first is to demonstrate some of the contents needed in a message without all of the complexity of explaining a full-blown industry standard. Second, although the existing standards fill most needs, there still will be scenarios in which using a custom message will better fit the needs of a situation, much like the tradeoffs between using a higher-level protocol like HTTP or SMTP and using raw sockets.

A prototype XML broker implementation

Having discussed the reasons for using a messaging design in your application, we will now proceed to a prototype XML messaging broker implementation.

Why should you develop a custom message broker implementation instead of using an existing one? Well, because many of the implementations for XML messaging products are new, so it's important to know what goes into a basic implementation. Also, it's possible that because XML message brokers are somewhat immature products, you'll need to develop your own to get the features you want.

The basic broker presented here can service two types of messages: a request to create an invoice, which it stores on the filesystem, and a client code component, which just reads the XML message from a file and sends it.

The broker comprises three main parts: a listener piece that receives incoming messages on some transport (in this example there will only be an HTTP implementation provided); the main broker piece, which will decide what to do with an incoming message; and the invocation piece that will actually perform some logic based on the incoming message. Let's look at each in more detail.

Receive the message from the transport

메시지는 먼저 브로커의 리스너 부분을 만납니다. 대부분의 XML 메시지 브로커는 HTTP, SMTP, JMS (특정 공급 업체의 구현) 등과 같은 다양한 전송 (프로토콜)을 지원합니다. 브로커는 전송 부분을 분리하여이를 허용합니다. 아래에 표시된 부분은 단순히 주어진 전송에서 메시지를 수신하고 수신 메시지를 문자열 변수에 넣고 브로커 싱글 톤을 호출합니다.