Perpesanan XML, Bagian 1

Perpesanan XML mewakili area TI yang dinamis dan berkembang pesat, situasi yang membuatnya menarik dan melelahkan pada saat yang bersamaan. Saat pertukaran B2B dan bentuk komunikasi elektronik antar-bisnis lainnya tumbuh, perpesanan XML akan disebarkan lebih luas dari sebelumnya.

Baca seluruh seri "Perpesanan XML":

  • Bagian 1: Tulis broker pesan XML sederhana untuk pesan XML kustom
  • Bagian 2: Pesan XML dengan cara SOAP
  • Bagian 3: JAXM dan ebXML menetapkan standar baru untuk perpesanan XML

Dalam artikel ini, pertama-tama kita akan mempelajari perpesanan XML dan mengapa ini berguna. Kemudian kita akan mempelajari fitur perpesanan XML tertentu, termasuk perutean pesan, transformasi, dan perantara. Akhirnya, kita akan menyelesaikan dengan contoh sederhana dari broker XML. Setelah membaca dan memahami konsepnya, Anda harus memahami dengan jelas skenario mana yang memungkinkan penerapan solusi perpesanan XML.

Apa itu perpesanan XML?

Untuk memulai eksplorasi kita, kita perlu memahami premis dasar dari olahpesan XML dan apa arti dari istilah olahpesan . Untuk keperluan artikel ini, saya mendefinisikan pesan sebagai berikut:

Kumpulan bidang data yang dikirim atau diterima bersama antara aplikasi perangkat lunak. Pesan berisi header (yang menyimpan informasi kontrol tentang pesan) dan payload (konten pesan yang sebenarnya).

Perpesanan menggunakan pesan untuk berkomunikasi dengan sistem yang berbeda untuk melakukan beberapa jenis fungsi. Kami menyebut komunikasi sebagai komunikasi yang berorientasi pesan karena kami akan mengirim dan menerima pesan untuk melakukan operasi, berbeda dengan komunikasi berorientasi RPC (Remote Procedure Call). Sebuah analogi sederhana dapat membantu: anggap pesan sebagai email untuk aplikasi. Memang, olahpesan memiliki banyak atribut individu yang mengirim pesan email satu sama lain.

Di masa lalu, ketika Anda menggunakan atau bekerja pada sistem berorientasi pesan, itu berarti Anda menggunakan beberapa jenis produk MOM (middleware berorientasi pesan) seperti Tibco's Rendezvous, IBM's MQSeries, atau penyedia JMS untuk mengirim pesan dalam mode asinkron (satu arah). Pesan hari ini tidak selalu berarti bahwa Anda menggunakan produk MOM, dan itu tidak berarti bahwa Anda berkomunikasi secara asinkron. Sebaliknya, perpesanan dapat berupa sinkronisasi (dua arah) atau asinkron dan menggunakan banyak protokol berbeda seperti HTTP atau SMTP, serta produk MOM.

Mengapa perpesanan XML?

Mengapa Anda ingin mengembangkan sistem menggunakan perpesanan? Apa yang membuat perpesanan menjadi teknik desain yang berguna dan apa manfaatnya? Seperti yang disebutkan sebelumnya, kita dapat memilih dari dua alternatif saat membutuhkan dua aplikasi untuk berbicara satu sama lain melalui jaringan: RPC atau berorientasi pesan. Menggunakan pendekatan berbasis RPC (RMI termasuk dalam kategori ini) berarti bahwa klien (atau pemanggil) dari panggilan prosedur mengetahui prosedur yang ingin dipanggil dan mengetahui parameter yang ingin diteruskannya ke prosedur. Selain itu, pemanggil ingin menunggu sementara server yang dipanggil (aplikasi) menyelesaikan permintaan.

Dalam pendekatan kedua - berorientasi pesan - pemanggil tidak perlu mengetahui prosedur pasti yang akan dipanggil, tetapi membuat pesan dengan format tertentu yang diketahui klien dan server. Klien membuat pesan dan kemudian mengirimkannya ke server melalui jaringan. Oleh karena itu, klien tidak bergantung pada server atau prosedur server, tetapi bergantung pada format pesan. Juga, komunikasi kemungkinan besar terjadi dalam mode asynchronous, yang berarti bahwa klien akan mengirimkan permintaan tetapi tidak akan menunggu (memblokir) tanggapan. Ini memungkinkan klien untuk terus berfungsi bahkan jika server menjadi tidak tersedia (lumpuh, misalnya). Desain ini, di mana klien lebih independen dari server, dianggap lebih longgar digabungkan.

Saat mengevaluasi apakah akan menggunakan desain berorientasi pesan, penting untuk memahami pro dan kontra dari sistem semacam itu. Keuntungannya meliputi:

  • Kopling longgar
  • Perutean dan transformasi pesan yang lebih mudah
  • Muatan yang lebih fleksibel (dapat mencakup lampiran biner, misalnya)
  • Dapat menggunakan beberapa pesan secara bersamaan untuk menjalankan prosedur tertentu

Secara umum, pendekatan berorientasi pesan terbukti lebih fleksibel daripada pendekatan RPC.

Berikut beberapa kekurangannya:

  • Dibutuhkan lebih banyak pekerjaan untuk mengembangkan interaksi klien / server menggunakan pendekatan berorientasi pesan dibandingkan dengan pendekatan RPC seperti RMI karena mengembangkan interaksi klien / server melalui pesan mewakili tingkat tipuan lain dari RPC. Kompleksitas ditambahkan melalui pembuatan pesan di sisi klien (versus pemanggilan prosedur dalam pendekatan RPC) dan di sisi server dengan kode pemrosesan pesan. Karena kompleksitas tambahannya, desain berorientasi pesan bisa jadi lebih sulit untuk dipahami dan di-debug.
  • Ada risiko kehilangan jenis informasi untuk bahasa pemrograman yang digunakan untuk mengirim pesan. Misalnya, double di Java mungkin tidak diterjemahkan sebagai double dalam pesan.
  • Dalam kebanyakan kasus, konteks transaksional tempat pesan dibuat tidak menyebar ke server perpesanan.

Mempertimbangkan pro dan kontra, kapan sebaiknya Anda menggunakan pendekatan berorientasi pesan? Skenario yang paling umum terjadi ketika komunikasi klien / server berlangsung melalui Internet dan klien dan server milik perusahaan yang berbeda. Dalam skenario ini, mungkin cukup sulit untuk meminta kedua perusahaan menyetujui antarmuka prosedur. Selain itu, ada kemungkinan perusahaan tidak ingin menggunakan bahasa pemrograman yang sama. Dalam contoh lain, perusahaan yang terlibat mungkin ingin menggunakan model komunikasi asynchronous sehingga keduanya tidak akan bergantung pada aplikasi lain yang sedang aktif dan berjalan.

Another attractive messaging scenario occurs when you're developing an event-based system in which events are created and then consumed by interested parties. Most GUIs are event-based. For instance, they might create a mouse click event in which interested parties listen for the event and perform some action based on it. In this scenario, using a messaging approach allows you to remove the dependency between an event (or action in a system) and the system's reaction to the event that is performed on the server.

Now that we understand a bit about messaging, we're ready to add XML to the equation. The addition of XML to messaging means that we are able to make use of a flexible data formatting language for our messages. In messaging, both the client and the server need to agree on a message format. XML makes this easier by deciding many data formatting issues and with the addition of other XML standards such as Rosetta Net. No additional work is required to come up with a message format.

What does an XML message broker do?

A message broker acts as the server in a message-oriented system. Message broker software performs operations on messages it receives. These operations include:

  • Header processing
  • Security checks and encryption/decryption
  • Error and exception handling
  • Routing
  • Invocation
  • Transformation

Header processing

Header processing is usually one of the first functions performed in the message upon its receipt within an XML broker. Header processing involves examining the header fields of incoming messages and performing some functions. Header processing could include adding a tracking number to an incoming message or ensuring that all of the header fields necessary to process the message exist. In the example XML message below, the message broker could check the to header field to ensure that this is the proper destination for this message.

Security checks and encryption/decryption

From a security perspective, a message broker can perform several different operations, but most likely you'll want to accomplish the "big three" of security: authentication, authorization, and encryption. First, once it determines that the message contains data that can be used to authenticate, the message broker will authenticate messages against a security database or directory. Second, the message broker will authorize operations that can be performed with this type of message and an authorized principal. Finally, the message that arrives at the message broker may be encrypted using some encryption scheme. It will be the broker's responsibility to decrypt the message in order to process it further.

Error and exception handling

Error and exception handling is another important piece of functionality performed by the message broker. Generally, the message will respond to the client (assuming a synchronous invocation) with an error message, caused when the message sent to the broker does not contain sufficient or accurate information. Another cause for errors or exceptions would occur when servicing the request (actually invoking a procedure/method based on the payload of the message).

Routing

Message routing is branching logic for messages. It occurs at two different levels in a message. The first, header-level routing, determines if an incoming message is bound for this application or needs to be resent to another application. The second, payload routing, determines which procedure or method to invoke once the broker determines that the message is bound for this application. Together these two types of routing enable a rich set of functionality when dealing with messages.

Invocation

Invocation means to actually call or invoke a method with the data (payload) contained in the incoming message. This could produce a result that is then returned through the broker back to the client. What is invoked could be anything, including an EJB Session bean, class method, and so on.

Transformation

Transformation converts or maps the message to some other format. With XML, XSLT is commonly used to perform transformation functionality.

An example XML message

Below you'll find an XML message used in the sample application that follows. Notice the header and body portions. This example is a "saveInvoice" type of message, in which the body contains an invoice that needs to be saved.

   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

Sebuah pesan pertama-tama akan menemukan bagian pendengar broker. Sebagian besar broker pesan XML menyediakan dukungan untuk banyak transport (protokol) yang berbeda seperti HTTP, SMTP, JMS (implementasi vendor tertentu), dan sebagainya. Pialang kami mengizinkan hal ini dengan mengisolasi porsi transportasi. Potongan yang ditunjukkan di bawah ini hanya menerima pesan pada transport yang diberikan, menempatkan pesan masuk ke dalam variabel string, dan memanggil broker tunggal: