Messaggistica XML, parte 1

La messaggistica XML rappresenta un'area dell'IT dinamica in rapida crescita, una situazione che la rende eccitante e noiosa allo stesso tempo. Con la crescita degli scambi B2B e di altre forme di comunicazione elettronica interaziendale, la messaggistica XML sarà diffusa più che mai.

Leggi l'intera serie "XML Messaging":

  • Parte 1: scrivere un semplice broker di messaggi XML per messaggi XML personalizzati
  • Parte 2: messaggistica XML in modo SOAP
  • Parte 3: JAXM ed ebXML definiscono il nuovo standard per la messaggistica XML

In questo articolo, esploreremo prima la messaggistica XML e perché è utile. Quindi approfondiremo le funzionalità di messaggistica XML specifiche, inclusi il routing, la trasformazione e l'intermediazione dei messaggi. Infine, finiremo con un semplice esempio di un broker XML. Dopo aver letto e compreso i concetti, è necessario comprendere chiaramente quali scenari si prestano all'implementazione di una soluzione di messaggistica XML.

Cos'è la messaggistica XML?

Per iniziare la nostra esplorazione, dobbiamo comprendere la premessa di base della messaggistica XML e cosa implica il termine messaggistica . Ai fini di questo articolo, definisco il messaggio come segue:

Una raccolta di campi dati inviati o ricevuti insieme tra applicazioni software. Un messaggio contiene un'intestazione (che memorizza le informazioni di controllo sul messaggio) e un payload (il contenuto effettivo del messaggio).

La messaggistica utilizza i messaggi per comunicare con diversi sistemi per eseguire qualche tipo di funzione. Ci riferiamo alla comunicazione come orientata ai messaggi perché invieremo e riceveremo messaggi per eseguire l'operazione, a differenza di una comunicazione orientata RPC (Remote Procedure Call). Una semplice analogia può aiutare: pensa alla messaggistica come alla posta elettronica per le applicazioni. In effetti, la messaggistica possiede molti degli attributi delle persone che si inviano messaggi di posta elettronica a vicenda.

In passato, quando si utilizzava o si lavorava su un sistema orientato ai messaggi, significava che si stava utilizzando un qualche tipo di prodotto MOM (middleware orientato ai messaggi) come Rendezvous di Tibco, MQSeries di IBM o un provider JMS per inviare messaggi in un modo asincrono (unidirezionale). La messaggistica odierna non significa necessariamente che stai utilizzando un prodotto MOM e non significa necessariamente che stai comunicando in modo asincrono. Piuttosto, la messaggistica può essere sincrona (bidirezionale) o asincrona e utilizzare molti protocolli diversi come HTTP o SMTP, nonché prodotti MOM.

Perché la messaggistica XML?

Perché vorresti sviluppare un sistema utilizzando la messaggistica? Cosa rende la messaggistica una tecnica di progettazione utile e quali sono i vantaggi? Come accennato in precedenza, possiamo scegliere tra due alternative quando si richiedono due applicazioni per parlare tra loro su una rete: RPC o orientata ai messaggi. L'utilizzo di un approccio basato su RPC (RMI rientra in questa categoria) significa che il client (o il chiamante) della chiamata di procedura conosce la procedura che desidera richiamare e conosce i parametri che desidera passare alla procedura. Inoltre, il chiamante desidera attendere mentre il server chiamato (l'applicazione) completa la richiesta.

Nel secondo approccio, orientato al messaggio, il chiamante non conosce necessariamente la procedura esatta che verrà invocata, ma crea invece un messaggio di un formato specifico noto sia al client che al server. Il client crea il messaggio e quindi lo invia al server tramite la rete. Pertanto, il client non dipende dal server o dalle procedure del server, ma dipende dal formato del messaggio. Inoltre, è probabile che la comunicazione avvenga in modo asincrono, il che significa che il client invierà una richiesta ma non attenderà (bloccherà) la risposta. Ciò consente al client di continuare a funzionare anche se il server non è disponibile (ad esempio, si blocca). Questa struttura, in cui il client è più indipendente dal server, è considerata più liberamente accoppiata.

Quando si valuta se utilizzare un design orientato ai messaggi, è importante comprendere i pro ei contro di un tale sistema. I vantaggi includono:

  • Accoppiamento lasco
  • Instradamento e trasformazione dei messaggi più semplici
  • Payload più flessibile (può includere allegati binari, ad esempio)
  • Può utilizzare diversi messaggi insieme per richiamare una determinata procedura

In generale, un approccio orientato al messaggio si rivela più flessibile di un approccio RPC.

Ora ecco alcuni svantaggi:

  • Richiede più lavoro per sviluppare un'interazione client / server utilizzando un approccio orientato ai messaggi rispetto a un approccio RPC come RMI perché lo sviluppo di un'interazione client / server tramite un messaggio rappresenta un altro livello di indiretto da RPC. La complessità viene aggiunta attraverso la creazione del messaggio sul lato client (rispetto a una chiamata di procedura in un approccio RPC) e sul lato server con il codice di elaborazione del messaggio. A causa della sua complessità aggiuntiva, un design orientato ai messaggi può essere più difficile da comprendere ed eseguire il debug.
  • Esiste il rischio di perdere le informazioni sul tipo per il linguaggio di programmazione in cui è stato inviato il messaggio. Ad esempio, double in Java potrebbe non essere tradotto come double nel messaggio.
  • Nella maggior parte dei casi il contesto transazionale in cui è stato creato il messaggio non si propaga al server di messaggistica.

Considerando i pro ei contro, quando dovresti usare un approccio orientato ai messaggi? Lo scenario più comune si verifica quando la comunicazione client / server avviene su Internet e client e server appartengono a società diverse. In questo scenario potrebbe essere abbastanza difficile far concordare le due società sull'interfaccia della procedura. Inoltre, è possibile che le aziende non vogliano utilizzare lo stesso linguaggio di programmazione. In un altro esempio, le aziende coinvolte potrebbero voler utilizzare un modello di comunicazione asincrono in modo che nessuno dei due dipenda dall'applicazione dell'altro.

Un altro interessante scenario di messaggistica si verifica quando si sviluppa un sistema basato su eventi in cui gli eventi vengono creati e poi consumati dalle parti interessate. La maggior parte delle GUI sono basate su eventi. Ad esempio, potrebbero creare un evento clic del mouse in cui le parti interessate ascoltano l'evento ed eseguono un'azione basata su di esso. In questo scenario, l'utilizzo di un approccio di messaggistica consente di rimuovere la dipendenza tra un evento (o un'azione in un sistema) e la reazione del sistema all'evento che viene eseguito sul server.

Ora che abbiamo capito qualcosa sulla messaggistica, siamo pronti per aggiungere XML all'equazione. L'aggiunta di XML alla messaggistica significa che siamo in grado di utilizzare un linguaggio di formattazione dei dati flessibile per i nostri messaggi. Nella messaggistica, sia il client che il server devono concordare un formato di messaggio. XML lo rende più semplice decidendo molti problemi di formattazione dei dati e con l'aggiunta di altri standard XML come Rosetta Net. Non è richiesto alcun lavoro aggiuntivo per elaborare un formato di messaggio.

Cosa fa un broker di messaggi XML?

Un broker di messaggi funge da server in un sistema orientato ai messaggi. Il software del broker di messaggi esegue operazioni sui messaggi che riceve. Queste operazioni includono:

  • Elaborazione dell'intestazione
  • Controlli di sicurezza e crittografia / decrittografia
  • Gestione degli errori e delle eccezioni
  • Routing
  • Invocazione
  • Trasformazione

Elaborazione dell'intestazione

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

Un messaggio incontrerà prima la parte listener del broker. La maggior parte dei broker di messaggi XML fornisce supporto per molti diversi trasporti (protocolli) come HTTP, SMTP, JMS (un'implementazione di un particolare fornitore) e così via. Il nostro broker lo consente isolando la parte di trasporto. Il pezzo mostrato di seguito riceve semplicemente il messaggio su un dato trasporto, inserisce il messaggio in arrivo in una variabile stringa e chiama il broker singleton: