Pemesejan XML, Bahagian 1

Pemesejan XML mewakili bidang IT yang berkembang pesat dan dinamik, keadaan yang menjadikannya menarik dan meletihkan pada masa yang sama. Apabila pertukaran B2B dan bentuk komunikasi elektronik antara perniagaan berkembang, pesanan XML akan lebih banyak digunakan berbanding sebelumnya.

Baca keseluruhan siri "Pemesejan XML":

  • Bahagian 1: Tulis broker pesanan XML ringkas untuk mesej XML tersuai
  • Bahagian 2: Mesej XML dengan cara SOAP
  • Bahagian 3: JAXM dan ebXML menetapkan standard baru untuk pesanan XML

Dalam artikel ini, kita akan meneroka pemesejan XML terlebih dahulu dan mengapa ia berguna. Kemudian kami akan menyelidiki ciri pesanan XML tertentu, termasuk perutean, transformasi, dan pembrokeran mesej. Akhirnya, kita akan selesai dengan contoh ringkas broker XML. Setelah anda membaca dan memahami konsepnya, anda harus memahami dengan jelas senario mana yang sesuai untuk melaksanakan penyelesaian pemesejan XML.

Apakah pesanan XML?

Untuk memulakan penerokaan kami, kami perlu memahami premis asas pemesejan XML dan apa maksud istilah pemesejan . Untuk tujuan artikel ini, saya menentukan mesej sebagai berikut:

Kumpulan bidang data yang dihantar atau diterima bersama antara aplikasi perisian. Mesej mengandungi header (yang menyimpan maklumat kawalan mengenai mesej) dan muatan (kandungan sebenar mesej).

Pemesejan menggunakan mesej untuk berkomunikasi dengan sistem yang berbeza untuk melakukan beberapa jenis fungsi. Kami menyebut komunikasi sebagai berorientasikan pesan kerana kami akan mengirim dan menerima pesan untuk melakukan operasi, berbeda dengan komunikasi yang berorientasikan RPC (Panggilan Prosedur Jauh) Analogi sederhana boleh membantu: menganggap pesanan sebagai e-mel untuk aplikasi. Sesungguhnya, pesanan mempunyai banyak sifat individu menghantar mesej e-mel antara satu sama lain.

Pada masa lalu, ketika anda menggunakan atau menggunakan sistem yang berorientasikan mesej, ini bermaksud bahawa anda menggunakan beberapa jenis produk MOM (middleware berorientasikan mesej) seperti Tibco's Rendezvous, MQSeries IBM, atau penyedia JMS untuk menghantar mesej dalam fesyen asinkron (sehala). Mesej hari ini tidak semestinya bermaksud bahawa anda menggunakan produk MOM, dan tidak semestinya anda berkomunikasi secara tidak segerak. Sebaliknya, pemesejan boleh diselaraskan (dua arah) atau tidak segerak dan menggunakan banyak protokol yang berbeza seperti HTTP atau SMTP, serta produk MOM.

Mengapa pemesejan XML?

Mengapa anda ingin mengembangkan sistem menggunakan pesanan? Apa yang menjadikan pesanan sebagai teknik reka bentuk yang berguna dan apa faedahnya? Seperti disebutkan sebelumnya, kita dapat memilih dari dua alternatif ketika memerlukan dua aplikasi untuk saling berbicara melalui jaringan: RPC atau berorientasikan pesan. Menggunakan pendekatan berasaskan RPC (RMI termasuk dalam kategori ini) bermaksud pelanggan (atau pemanggil) prosedur panggilan mengetahui prosedur yang ingin dijalankan dan mengetahui parameter yang ingin diteruskan ke prosedur tersebut. Juga, pemanggil ingin menunggu sementara pelayan yang dipanggil (aplikasi) menyelesaikan permintaan.

Dalam pendekatan kedua - berorientasikan mesej - pemanggil tidak semestinya mengetahui prosedur yang tepat yang akan dipanggil, tetapi membuat mesej format tertentu yang diketahui oleh pelanggan dan pelayan. Pelanggan membuat mesej dan kemudian menghantarnya ke pelayan melalui rangkaian. Oleh itu, klien tidak bergantung pada pelayan atau prosedur pelayan, tetapi bergantung pada format mesej. Juga, komunikasi mungkin berlaku secara asinkron, yang bermaksud bahawa pelanggan akan menghantar permintaan tetapi tidak akan menunggu (menyekat) respons. Ini membolehkan klien terus berfungsi walaupun pelayan tidak tersedia (misalnya, crash). Reka bentuk ini, di mana pelanggan lebih bebas daripada pelayan, dianggap lebih mudah digabungkan.

Semasa menilai sama ada menggunakan reka bentuk berorientasikan mesej, penting untuk memahami kebaikan dan keburukan sistem sedemikian. Kelebihannya termasuk:

  • Gandingan longgar
  • Penghalaan dan transformasi mesej yang lebih mudah
  • Muatan yang lebih fleksibel (boleh merangkumi lampiran binari, misalnya)
  • Boleh menggunakan beberapa mesej bersama untuk menggunakan prosedur yang diberikan

Secara umum, pendekatan berorientasikan mesej terbukti lebih fleksibel daripada pendekatan RPC.

Sekarang ada beberapa kekurangan:

  • Ia memerlukan lebih banyak kerja untuk mengembangkan interaksi klien / pelayan menggunakan pendekatan berorientasikan mesej berbanding dengan pendekatan RPC seperti RMI kerana mengembangkan interaksi klien / pelayan melalui mesej mewakili tahap pengarahan lain dari RPC. Kerumitan ditambahkan melalui penciptaan pesan di sisi klien (berbanding permintaan prosedur dalam pendekatan RPC) dan di sisi pelayan dengan kod pemprosesan mesej. Kerana kerumitan yang ditambahkan, reka bentuk yang berorientasikan mesej menjadi lebih sukar untuk difahami dan di-debug.
  • Terdapat risiko kehilangan maklumat jenis untuk bahasa pengaturcaraan di mana mesej dihantar. Contohnya, ganda di Java mungkin tidak diterjemahkan sebagai dua kali ganda dalam mesej.
  • Dalam kebanyakan kes, konteks transaksi di mana mesej dibuat tidak menyebarkan ke pelayan pesanan.

Mengingat kebaikan dan keburukan, kapan anda harus menggunakan pendekatan berorientasikan mesej? Senario yang paling biasa berlaku apabila komunikasi pelanggan / pelayan berlaku melalui Internet dan pelanggan dan pelayan milik syarikat yang berbeza. Dalam senario ini, agak sukar bagi kedua-dua syarikat untuk menyetujui antara muka prosedur. Juga, mungkin syarikat tersebut tidak mahu menggunakan bahasa pengaturcaraan yang sama. Dalam contoh lain, syarikat-syarikat yang terlibat mungkin ingin menggunakan model komunikasi tak segerak sehingga tidak akan bergantung pada aplikasi pihak lain yang sedang 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

Mesej pertama akan menemui bahagian pendengar broker. Sebilangan besar broker mesej XML memberikan sokongan untuk banyak pengangkutan yang berbeza (protokol) seperti HTTP, SMTP, JMS (pelaksanaan vendor tertentu), dan sebagainya. Broker kami membenarkan ini dengan mengasingkan bahagian pengangkutan. Potongan yang ditunjukkan di bawah ini hanya menerima mesej pada pengangkutan tertentu, meletakkan mesej masuk ke dalam pembolehubah rentetan, dan memanggil singleton broker: