XML-Messaging, Teil 1

XML-Messaging stellt einen schnell wachsenden, dynamischen Bereich der IT dar, eine Situation, die es gleichzeitig spannend und ermüdend macht. Mit zunehmendem B2B-Austausch und anderen Formen der elektronischen Kommunikation zwischen Unternehmen wird XML-Messaging in größerem Umfang als je zuvor eingesetzt.

Lesen Sie die gesamte "XML Messaging" -Serie:

  • Teil 1: Schreiben Sie einen einfachen XML-Nachrichtenbroker für benutzerdefinierte XML-Nachrichten
  • Teil 2: XML-Messaging auf SOAP-Weise
  • Teil 3: JAXM und ebXML setzen den neuen Standard für XML-Messaging

In diesem Artikel werden wir zunächst XML-Nachrichten untersuchen und erläutern, warum sie nützlich sind. Anschließend werden wir uns mit bestimmten XML-Messaging-Funktionen befassen, einschließlich Nachrichtenrouting, -transformation und -vermittlung. Abschließend erhalten Sie ein einfaches Beispiel für einen XML-Broker. Nachdem Sie die Konzepte gelesen und verstanden haben, sollten Sie klar verstehen, welche Szenarien sich für die Implementierung einer XML-Messaging-Lösung eignen.

Was ist XML-Messaging?

Um mit unserer Untersuchung zu beginnen, müssen wir die Grundvoraussetzung von XML-Messaging verstehen und wissen, was der Begriff Messaging impliziert. Für die Zwecke dieses Artikels definiere ich die Nachricht wie folgt:

Eine Sammlung von Datenfeldern, die zusammen zwischen Softwareanwendungen gesendet oder empfangen werden. Eine Nachricht enthält einen Header (der Steuerinformationen über die Nachricht speichert) und eine Nutzlast (den tatsächlichen Inhalt der Nachricht).

Messaging verwendet Nachrichten, um mit verschiedenen Systemen zu kommunizieren und eine Funktion auszuführen. Wir bezeichnen die Kommunikation als nachrichtenorientiert, da wir im Gegensatz zu einer RPC-orientierten Kommunikation (Remote Procedure Call) Nachrichten senden und empfangen würden, um die Operation auszuführen. Eine einfache Analogie kann helfen: Stellen Sie sich Messaging als E-Mail für Anwendungen vor. In der Tat besitzt Messaging viele der Attribute von Personen, die E-Mail-Nachrichten aneinander senden.

Wenn Sie in der Vergangenheit ein nachrichtenorientiertes System verwendeten oder daran arbeiteten, bedeutete dies, dass Sie eine Art MOM-Produkt (Message-Oriented Middleware) wie Tibcos Rendezvous, IBMs MQSeries oder einen JMS-Anbieter zum Senden von Nachrichten in einem System verwendeten asynchrone (Einweg-) Mode. Messaging bedeutet heute nicht unbedingt, dass Sie ein MOM-Produkt verwenden, und es bedeutet nicht unbedingt, dass Sie asynchron kommunizieren. Messaging kann entweder synchron (bidirektional) oder asynchron sein und viele verschiedene Protokolle wie HTTP oder SMTP sowie MOM-Produkte verwenden.

Warum XML-Messaging?

Warum sollten Sie ein System mit Messaging entwickeln wollen? Was macht Messaging zu einer nützlichen Designtechnik und was sind die Vorteile? Wie bereits erwähnt, können wir zwischen zwei Alternativen wählen, wenn zwei Anwendungen über ein Netzwerk miteinander kommunizieren müssen: RPC oder nachrichtenorientiert. Die Verwendung eines RPC-basierten Ansatzes (RMI fällt in diese Kategorie) bedeutet, dass der Client (oder Aufrufer) des Prozeduraufrufs die Prozedur kennt, die er aufrufen möchte, und die Parameter kennt, die er an die Prozedur übergeben möchte. Außerdem möchte der Anrufer warten, während der angerufene Server (die Anwendung) die Anforderung abgeschlossen hat.

Beim zweiten Ansatz - nachrichtenorientiert - kennt der Anrufer nicht unbedingt die genaue Prozedur, die aufgerufen wird, sondern erstellt stattdessen eine Nachricht in einem bestimmten Format, das sowohl dem Client als auch dem Server bekannt ist. Der Client erstellt die Nachricht und sendet sie dann über das Netzwerk an den Server. Daher hängt der Client nicht vom Server oder den Prozeduren des Servers ab, sondern vom Nachrichtenformat. Außerdem erfolgt die Kommunikation wahrscheinlich asynchron, was bedeutet, dass der Client eine Anforderung sendet, aber nicht auf die Antwort wartet (blockiert). Auf diese Weise kann der Client auch dann weiterarbeiten, wenn der Server nicht mehr verfügbar ist (z. B. Abstürze). Dieses Design, bei dem der Client unabhängiger vom Server ist, wird als lockerer gekoppelt angesehen.

Bei der Beurteilung, ob ein nachrichtenorientiertes Design verwendet werden soll, ist es wichtig, die Vor- und Nachteile eines solchen Systems zu verstehen. Die Profis sind:

  • Lose Kopplung
  • Einfachere Nachrichtenweiterleitung und -transformation
  • Flexiblere Nutzdaten (können beispielsweise binäre Anhänge enthalten)
  • Kann mehrere Nachrichten zusammen verwenden, um eine bestimmte Prozedur aufzurufen

Im Allgemeinen erweist sich ein nachrichtenorientierter Ansatz als flexibler als ein RPC-Ansatz.

Hier sind einige Nachteile:

  • Die Entwicklung einer Client / Server-Interaktion mithilfe eines nachrichtenorientierten Ansatzes erfordert im Vergleich zu einem RPC-Ansatz wie RMI mehr Arbeit, da die Entwicklung einer Client / Server-Interaktion über eine Nachricht eine weitere Indirektionsebene von RPC darstellt. Die Komplexität wird durch die Erstellung der Nachricht auf der Clientseite (im Vergleich zu einem Prozeduraufruf in einem RPC-Ansatz) und auf der Serverseite mit Nachrichtenverarbeitungscode erhöht. Aufgrund seiner zusätzlichen Komplexität kann es schwieriger sein, ein nachrichtenorientiertes Design zu verstehen und zu debuggen.
  • Es besteht die Gefahr, dass Typinformationen für die Programmiersprache verloren gehen, in der die Nachricht gesendet wurde. Beispielsweise wird double in Java möglicherweise nicht als double in der Nachricht übersetzt.
  • In den meisten Fällen wird der Transaktionskontext, in dem die Nachricht erstellt wurde, nicht an den Nachrichtenserver weitergegeben.

Wann sollten Sie unter Berücksichtigung der Vor- und Nachteile einen nachrichtenorientierten Ansatz verwenden? Das häufigste Szenario tritt auf, wenn die Client / Server-Kommunikation über das Internet stattfindet und Client und Server verschiedenen Unternehmen gehören. In diesem Szenario kann es ziemlich schwierig sein, die beiden Unternehmen auf die Verfahrensschnittstelle zu einigen. Es ist auch möglich, dass die Unternehmen nicht dieselbe Programmiersprache verwenden möchten. In einem anderen Beispiel möchten die beteiligten Unternehmen möglicherweise ein asynchrones Kommunikationsmodell verwenden, damit keines davon davon abhängt, ob die Anwendung des anderen aktiv ist.

Ein weiteres attraktives Messaging-Szenario tritt auf, wenn Sie ein ereignisbasiertes System entwickeln, in dem Ereignisse erstellt und dann von interessierten Parteien genutzt werden. Die meisten GUIs sind ereignisbasiert. Beispielsweise können sie ein Mausklickereignis erstellen, bei dem interessierte Parteien auf das Ereignis warten und darauf basierend eine Aktion ausführen. In diesem Szenario können Sie mithilfe eines Messaging-Ansatzes die Abhängigkeit zwischen einem Ereignis (oder einer Aktion in einem System) und der Reaktion des Systems auf das auf dem Server ausgeführte Ereignis entfernen.

Nachdem wir uns mit Messaging vertraut gemacht haben, können wir der Gleichung XML hinzufügen. Durch das Hinzufügen von XML zum Messaging können wir eine flexible Datenformatierungssprache für unsere Nachrichten verwenden. Beim Messaging müssen sich sowohl der Client als auch der Server auf ein Nachrichtenformat einigen. XML erleichtert dies, indem es viele Probleme bei der Datenformatierung entscheidet und andere XML-Standards wie Rosetta Net hinzufügt. Es ist keine zusätzliche Arbeit erforderlich, um ein Nachrichtenformat zu erstellen.

Was macht ein XML-Nachrichtenbroker?

Ein Nachrichtenbroker fungiert als Server in einem nachrichtenorientierten System. Die Nachrichtenbroker-Software führt Vorgänge für empfangene Nachrichten aus. Diese Operationen umfassen:

  • Header-Verarbeitung
  • Sicherheitsüberprüfungen und Verschlüsselung / Entschlüsselung
  • Fehler- und Ausnahmebehandlung
  • Routing
  • Aufruf
  • Transformation

Header-Verarbeitung

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

Eine Nachricht trifft zuerst auf den Listener-Teil des Brokers. Die meisten XML-Nachrichtenbroker bieten Unterstützung für viele verschiedene Transporte (Protokolle) wie HTTP, SMTP, JMS (Implementierung eines bestimmten Anbieters) usw. Unser Broker ermöglicht dies, indem er den Transportteil isoliert. Das unten gezeigte Stück empfängt einfach die Nachricht auf einem bestimmten Transport, platziert die eingehende Nachricht in einer Zeichenfolgenvariablen und ruft den Broker-Singleton auf: