메시지 지향 미들웨어 (MOM : Message Oriented Middleware)

Computer Science/Common 2013. 1. 11. 14:09


메시지 지향 미들웨어 (MOM : Message Oriented Middleware)는 분산 시스템 간 메시지를 주고 받는 기능을 지원하는 소프트웨어나 하드웨어 인프라이다.

증가하는 서비스의 상호이용과 휴대성, 유연성을 만족하는 분산된 다중 이기종 플랫폼을 사용한다. RPC 기반의 통신은 원래 동시적이나, 구성요소의 통신의 목표는 대다수의 응용 비즈니스 함수를 실행하는 데 제한된다. 비록 비 동기 통신이 몇몇의 RPC수행에 영향을 받았지만, 그건 여전히 조금 더 작고 적당한 발행/기부 형식의 기능성을 가진 프로토콜은 많은 전사적 환경들 특히 교차 응용 솔루션들에 필요하다.

목차

  [숨기기] 

[편집]목표

편의를 위해 이것은 비 동기 기능을 필요로 하는데, 메시지 지향 미들웨어 제품들은 메시지 관점과 큐 서비스의 결합을 소개한다. 메시지와 라우팅 구조는 상당한 영향력이 있는 많은 현재의 EAI 메시지 중개자들의 기초가 되는 메시징 구조. 즉, 메시지 지향 미들웨어 솔루션에 의해 제공된다.

[편집]기능

메시지 지향 미들웨어는 클라이언트와 서버 적용 분야에서 클라이언트/서버 구조와 전형적으로 지원하는 비동기 호출 사이에서 양쪽의 일부분에 존재하는 소프트웨어다. Multi Operating System 그리고 네트워크 프로토콜 들을 단일화 하는 적용 개발자들의 각각의 운영체제 그리고 네트워크 인터페이스 등의 세부적인 개발 적용의 복잡성을 감소시킨다. 플랫폼과 네트워크들 각각의 연결을 확장해 주는 API들은 MOM에 의해 제공된다.

많은 대다수의 메시지 지향 미들웨어는 메시지 큐 시스템에 의존합니다. 그러나 그들의 몇몇 실행들은 Broadcast나 Multicast Message System에 의존합니다.

필요하다면 시스템간의 정확한 동작을 위해 서로 다른 종류의 시스템의 결합도 고려되어야 합니다.

MOM.PNG

[편집]장점

  • 메시지 큐들은 목적 프로그램이 바쁘거나 연결이 되지 않을 때 임시 저장공간을 제공한다.
  • 클라이언트/서버 구조의 주종관계의 복잡성과 개발자 업무와의 관계를 감소시킨다.
  • 내부의 응용 통신 소프트 웨어, 일반으로 신뢰되는 비동기 메시지 흐름과 요청-응답 비유 같은 반대되는 종류를 포함합니다.

[편집]단점

작업 완료시 까지 호출된 함수는 반환되지 않는다. 비동기식 시스템에서 호출된 하위 구조는 자원의 부족으로 호출된 함수의 완료나 에러시 까지 계속 수신자에게 작업 요청을 하게 됩니다.

[편집]참고 자료



메시지 지향 미들웨어 (메시지 지향 미들웨어, 영어 : Message-oriented middleware , MOM )는 응용 프로그램 소프트웨어 사이의 데이터 통신 소프트웨어 이며, 일반적으로 비동기 메시지 전달 을 기반으로 한 것을 가리킨다.

많은 메시지 지향 미들웨어는 메시지 큐 시스템을 기반으로하지만, 그 밖에도 방송 형 메시지 시스템과 멀티 캐스트 형태의 메시지 시스템에 기반 것도있다.

목차

  [ 숨기기 ] 

기원 [ 편집 ]

미들웨어 라는 개념이 등장한 것은 비교적 늦은. 1980 년대 이전 시스템과 새로운 응용 프로그램을 어떻게 연결 하는가하는 문제에 대한 해결책으로 등장했다. 또한, 분산 컴퓨팅 을 조장하게되었다. 즉, 컴퓨터 네트워크 에서 여러 응용 프로그램을 연결하여 전체적으로 큰 응용 프로그램을 형성하게 된 것이다.

우화적인 설명 [ 편집 ]

대형 은행의 경우를 예로 생각하면, 미들웨어가 비즈니스 의 요구로 어떻게 발전되어 왔는지 알 수있다. 은행은 1960 년대부터 고객에 대한 모든 정보를 대규모 메인 프레임 에 저장했다. 이 메인 프레임은 몇 번의 업데이트를 거쳐 지금도 현역으로 계속 사용하고있다. 이후 개인용 컴퓨터 (PC) 기반의 독립적 인 애플리케이션으로 고객에게 메인 프레임에는없는 새로운 서비스를 제공하게되면, 메인 프레임의 유용성은 감소 하였다. 이상적으로는 PC 기반 응용 프로그램과 메인 프레임 응용 프로그램이 연결되어 메인 프레임과 PC가 데이터 를 공유하는 것이 바람직하다. 메인 프레임의 데이터에 액세스 할 수 있다면 다음의 두 가지 장점이 생긴다.

  1. 새로운 프론트 엔드로 PC 응용 프로그램은 오래 사용하기 어려운 메인 프레임 터미널을 대체 할 수있다.
  2. PC 기반의 시스템은 메인 프레임의 데이터를 기존 시스템에서는 불가능했던 새로운 방식으로 활용할 수있다.

1980 년대 말까지 이러한 응용 프로그램을 서로 연결하는 쉬운 방법은 존재하지 않았다. 개발자는 몇 가지 문제에 직면했다.

  1. 소프트웨어 개발자 는 두 시스템을 연결하기에 앞서, 송신 측에서 보낸 데이터를 수신 측에서 취급 형식으로 변환하는 소프트웨어 "어댑터"를 개발해야한다 (양방향 통신이라면 모두 시스템 어댑터 필요).
  2. 한편 시스템의 처리 속도가 다른 시스템을 제한한다. 예를 들어, 메인 프레임이 느리면, PC 기반 응용 프로그램은 메인 프레임이 따라 잡을 때까지 기다려야 결과로 PC 응용 프로그램의 속도가 느려집니다.
  3. 통신 프로그래머는 메인 프레임의 네트워크와 PC의 네트워크 프로토콜이 다를 게이트웨이 시스템을 구현할 필요가있다. 이 게이트웨이는 패킷의 내용을 변환하여 쌍방의 시스템 간의 통신을 가능하게한다.

이러한 문제로 인해 응용 프로그램의 통합은 점점 힘들어지고 있었다. 또한, 개별 시스템에서 상황이 다르기 때문에 이러한 통합은 개별 시스템마다 설계가 필요하다. 이기종의 애플리케이션 사이의 연결은 원래 시스템 개발 이상의 비용 (또는 10 배)이 걸렸다.

여러 응용 프로그램의 중간에 위치하여 그들 사이의 "배관"를 새로운 독립적 인 소프트웨어가 필요한 것은 분명했다. 이러한 소프트웨어는 다른 플랫폼 , 다른 프로그래밍 언어 , 각종 통신 프로토콜 , 다양한하드웨어 를 취급 할 필요가 있었다. 즉, 기본 인프라 의 복잡성을 분리함으로써 개발자가 개별 응용 프로그램의 기능 개발에 주력 할 수있게된다.

1980 년대 말까지 미들웨어가 이러한 문제에 대한 대책으로 등장했다. 초기의 미들웨어 지원하는 플랫폼이나 언어가 제한되어있어 유용성은 제한적이었다. 그러나 시간이 지남에 미들웨어 제품은 여러 플랫폼, 언어, 프로토콜을 지원하게되고, 고도화 해 갔다.

이기종 네트워크 환경에서 각 시스템을 연결하는 미들웨어의 능력이 기술의 장점 몇 가지 예에 불과하다. 2006 년 현재, 미들웨어 상호 연결 가능한 기존 응용 프로그램을 늘리고 강화하는 새로운 기능을 제공하고있다.

장점 [ 편집 ]

메시지 기반의 통신 프로토콜의 장점은 메시지 를 전달하는 과정에서 보관하거나 라우팅, 변환 할 수있는 점에있다.

저장 [ 편집 ]

많은 메시지 지향 미들웨어는 전송되는 메시지의 백업 을 유지함으로써 지속성 을 제공한다. 즉, 송신 측과 수신 측 동시에 네트워크에 연결되어있을 필요는 없다. 이것은 네트워크의 품질이 낮거나, 사용자가 임의로 연결 오는 경우 라든지, 연결 시간 제한이있는 경우, 연결이 간헐적 인 경우에 특히 편리하다. 또한 수신에 문제가 발생하여 응용 프로그램이 중지 버려도 보내는 그것에 영향받지 않고 전송을 계속 메시지를 저장 해놓고 나중에받는 응용 프로그램이 다시 시작할 때 처리 가 열린다.

라우팅 [ 편집 ]

메시지 지향 미들웨어의 중요한 장점은 미들웨어 계층 스스로 메시지 라우팅이 가능하다는 점을들 수있다. 이를 추진하면 미들웨어 하나의 메시지를 여러 수신자에게 배포 할 수도있다 ( 멀티 캐스트 ).

변환 [ 편집 ]

메시지 지향 미들웨어는 수신자가받는 메시지는 발신자가 보낸 메시지 자체 일 필요는 없다. 지적 시스템에서는 송신과 수신 측의 요구에 따라 메시지의 변환이 가능하다. 라우팅 및 브로드 캐스트 / 멀티 캐스트와 함께 사용하면 응용 프로그램이 메시지를 자신의 형식으로 발송하고 여러받는 응용 프로그램이 고유의 형식으로 변환 된 메시지를받을 수도 가능하다. 최근 메시지 지향 미들웨어 세련된 메시지 변환 도구를 가지고 있으며, 프로그래머가 GUI 에 따르면 드래그 앤 드롭 조작으로 변환 규칙을 지정할 수있게되어있다.

단점 [ 편집 ]

메시지 지향 미들웨어의 주요 단점은 구조적으로 외부 구성 요소 인 메시지 전송 에이전트를 필요로한다는 점에 기인하고있다. 일반적으로 새로운 구성 요소를 추가하면 시스템의 성능이 저하되고, 신뢰성도 저하한다. 또한 시스템 전체로 볼 때 보수 가 어렵고 비용도 걸리게된다.

게다가 응용 프로그램 간 통신은 본질적으로 동기 이고 송신 처리를 계속하기 전에 응답을 기다리도록되어있는 것이 보통이다. 메시지 기반의 통신은 기본적으로 비동기 적이며 불일치가 발생하고있다. 따라서 많은 메시지 지향 미들웨어는 요청을 그룹화하여 하나의 의사 동기 트랜잭션 응답하는 기능을 가지고있다.

표준의 부족 [ 편집 ]

메시지 지향 미들웨어는 표준이라고 부를 표준이 존재하지 않기 때문에 문제가 발생하고있다. 주요 벤더들은 자체적으로 구현하고, 독자적인 API 와 관리 도구를 가지고있다.

Java EE 프로그래밍 환경에서 JMS (Java Message Service)라는 표준 API를 제공하고 있으며, 많은 벤더들이 채용하고있다. 마이크로 소프트 MSMQ는 JMS를 지원하지 않지만, 타사가 그런 제품을 제공하고있다.

경향 [ 편집 ]

Advanced Message Queuing Protocol (AMQP)는 메시지 지향 미들웨어의 상호 운용성을 확보하는 것을 목적으로 한 것이다. 이 프로토콜은 매우 유연하고, P2P 형 메시징, 출판 / 구독 형 메시징, 또는 혼합 한 것 등을 정의하고 있으며, 매우 강력한이기 때문에이 분야의 표준이 될 가능성이있다. 이 영역에서 표준이 될 수 있도록 개발 된 것으로, XMPP 와 Streaming Text Oriented Messaging Protocol이있다.

관련 항목 [ 편집 ]

외부 링크 [ 편집 ]





Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating system and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.[1]

MOM provides software elements that reside in all communicating components of a client/server architecture and typically support asynchronous calls between the client and server applications. MOM reduces the involvement of application developers with the complexity of the master-slave nature of the client/server mechanism.

Contents

  [hide] 

[edit]Advantages

Central reasons for using a message-based communications protocol include its ability to store (buffer), route, or transform messages while conveying them from sender to receiver(s).

[edit]Asynchronicity

MOM comprises a category of inter-application communication software that generally relies on asynchronous message-passing, as opposed to a request-response metaphor. In asynchronous systems,message queues provide temporary storage when the destination program is busy or not connected. In addition, most asynchronous MOM systems provide persistent storage to back up the message queue. This means that the sender and receiver do not need to connect to the network at the same time (asynchronous delivery), and solves problems with intermittent connectivity. It also means that should the receiver application fail for any reason, the senders can continue unaffected, as the messages they send will simply accumulate in the message queue for later processing when the receiver restarts.

[edit]Routing

Many message-oriented middleware implementations depend on a message queue system. Some implementations permit routing logic to be provided by the messaging layer itself, while others depend on client applications to provide routing information or allow for a mix of both paradigms. Some implementations make use of broadcast or multicast distribution paradigms.

[edit]Transformation

In a message-based middleware system, the recipient's message need not replicate the sender's message exactly. A MOM system with built-in intelligence can transform messages en route to match the requirements of the sender or of the recipient.[2] In conjunction with the routing and broadcast/multicast facilities, one application can send a message in its own native format, and two or more other applications may each receive a copy of the message in their own native format. Many modern MOM systems provide sophisticated message transformation (or mapping) tools which allow programmers to specify transformation rules applicable to a simple GUI drag-and-drop operation.

[edit]Disadvantages

The primary disadvantage of many message oriented middleware systems is that they require an extra component in the architecture, the message transfer agent (message broker). As with any system, adding another component can lead to reductions in performance and reliability, and can also make the system as a whole more difficult and expensive to maintain.

In addition, many inter-application communications have an intrinsically synchronous aspect, with the sender specifically wanting to wait for a reply to a message before continuing (see real-time computingand near-real-time for extreme cases). Because message-based communication inherently functions asynchronously, it may not fit well in such situations. That said, most MOM systems have facilities to group a request and a response as a single pseudo-synchronous transaction.

[edit]Standards

Historically, there was a lack of standards governing the use of message oriented middleware that has caused problems. Most of the major vendors have their own implementations, each with its ownapplication programming interface (API) and management tools.

The Advanced Message Queuing Protocol (AMQP) is an emerging standard that defines the protocol and formats used in the messaging server and client, so implementations are interoperable. AMQP is defined to provide flexible routing, including common messaging paradigms like point-to-point, fanout, publish/subscribe, and request-response. It also supports transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support. Java applications that use AMQP are typically written in Java JMS. Other implementations provide APIs for C#, C++, PHP, Python, Ruby, and other languages.

The Java EE programming environment provides a standard API called JMS (Java Message Service), which is implemented by most MOM vendors and aims to hide the particular MOM API implementations; however, JMS does not define the format of the messages that are exchanged, so JMS systems are not interoperable.

A similar effort is with the actively evolving OpenMAMA project, which aims to provide a common API, particularly to C clients. However, at the moment (August 2012) it is primarily appropriate for distributing market-oriented data (e.g. stock quotes) over pub-sub middleware.

[edit]Trends

AMQP has been gaining adoption in applications that need an interoperable protocol for Message-oriented middleware.

Other protocols used for message-oriented middleware include XMPP and Streaming Text Oriented Messaging Protocol.

An additional trend sees message-oriented middleware functions being implemented in hardware - usually FPGAs or other specialized silicon chips.[3]

[edit]See also

[edit]References

  1. ^ Curry, Edward. 2004. "Message-Oriented Middleware". In Middleware for Communications, ed. Qusay H Mahmoud, 1-28. Chichester, England: John Wiley and Sons. doi:10.1002/0470862084.ch1. ISBN 978-0-470-86206-3
  2. ^ E. Curry, D. Chambers, and G. Lyons, "Extending Message-Oriented Middleware using Interception", presented at Third International Workshop on Distributed Event-Based Systems (DEBS '04), ICSE '04, Edinburgh, Scotland, UK, 2004.
  3. ^ Are You Soft in the Middle? The future of enterprise IT rests in hardware applications




출처 - http://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C%EC%A7%80_%EC%A7%80%ED%96%A5_%EB%AF%B8%EB%93%A4%EC%9B%A8%EC%96%B4







저작자표시

'Computer Science > Common' 카테고리의 다른 글

HDCP(High-bandwidth Digital Content Protection)  (0) 2013.03.25
메시지 큐(Message Queue)  (0) 2013.01.11
AMQP(Advanced Message Queuing Protocol)  (0) 2012.12.09
Posted by linuxism
,

티스토리툴바