העברת הודעות XML, חלק 1

העברת הודעות XML מייצגת אזור דינמי שצומח במהירות, מצב שהופך אותו למרתק ומייגע בו זמנית. ככל שחילופי B2B וצורות אחרות של תקשורת אלקטרונית בין-עסקית גדלים, העברת הודעות XML תפוצה באופן נרחב מתמיד.

קרא את כל הסדרה "העברת הודעות XML":

  • חלק 1: כתוב מתווך פשוט להודעות XML להודעות XML מותאמות אישית
  • חלק 2: העברת הודעות XML בדרך הסבון
  • חלק 3: JAXM ו- ebXML קובעים את הסטנדרט החדש להעברת הודעות XML

במאמר זה נחקור תחילה הודעות XML ומדוע זה שימושי. לאחר מכן נתעמק בתכונות ספציפיות להעברת הודעות XML, כולל ניתוב הודעות, טרנספורמציה ותיווך. לבסוף, נסיים עם דוגמה פשוטה של ​​מתווך XML. לאחר שתקראו ותבינו את המושגים, עליכם להבין בבירור אילו תרחישים מעניקים ליישום פתרון העברת הודעות XML.

מהי הודעות XML?

כדי להתחיל בחקר שלנו, עלינו להבין את הנחת היסוד של העברת הודעות XML ומה המשמעות של המונח העברת הודעות . למטרות מאמר זה, אני מגדיר הודעה כדלקמן:

אוסף של שדות נתונים שנשלחו או התקבלו יחד בין יישומי תוכנה. הודעה מכילה כותרת (השומרת מידע בקרה על ההודעה) ומטען (תוכן ההודעה בפועל).

העברת הודעות משתמשת בהודעות כדי לתקשר עם מערכות שונות כדי לבצע פונקציה כלשהי. אנו מתייחסים לתקשורת כמכוונת הודעות מכיוון שהיינו שולחים ומקבלים הודעות לביצוע הפעולה, בניגוד לתקשורת מונחית RPC (Remote Procedure Call). אנלוגיה פשוטה עשויה לעזור: לחשוב על העברת הודעות כמו דוא"ל ליישומים. ואכן, העברת הודעות כוללת תכונות רבות של אנשים השולחים הודעות דוא"ל זה לזה.

בעבר, כששימשת או עבדת על מערכת מכוונת הודעות, פירוש הדבר שהיית משתמש במוצר כלשהו של MOM (מכוונת הודעה ממוקדת) כמו Rendezvous של Tibco, MQSeries של IBM או ספק JMS כדי לשלוח הודעות בתוך אופנה אסינכרונית (חד כיוונית). הודעות היום לא אומר בהכרח שאתה משתמש במוצר MOM, וזה לא בהכרח אומר שאתה מתקשר בצורה אסינכרונית. במקום זאת, העברת הודעות יכולה להיות סינכרונית (דו כיוונית) או אסינכרונית ולהשתמש בפרוטוקולים רבים ושונים כגון HTTP או SMTP, כמו גם במוצרי MOM.

מדוע העברת הודעות XML?

מדוע תרצה לפתח מערכת באמצעות הודעות? מה הופך את המסרים לטכניקת עיצוב שימושית ומה היתרונות? כפי שהוזכר קודם לכן, אנו יכולים לבחור מתוך שתי חלופות כאשר אנו דורשים משני יישומים לדבר זה עם זה ברשת: RPC או מכוון הודעות. שימוש בגישה מבוססת RPC (RMI נכנס לקטגוריה זו) פירושו שהלקוח (או המתקשר) של שיחת ההליך יודע את ההליך שהוא רוצה להפעיל ויודע את הפרמטרים שהוא מעוניין להעביר. כמו כן, המתקשר מעוניין להמתין בזמן שהשרת המתקשר (היישום) ישלים את הבקשה.

בגישה השנייה - מכוונת הודעה - המתקשר לא בהכרח יודע את ההליך המדויק שיופעל, אלא יוצר הודעה בפורמט ספציפי המוכר גם ללקוח וגם לשרת. הלקוח יוצר את ההודעה ואז שולח אותה לשרת דרך הרשת. לכן הלקוח אינו תלוי בשרת או בנהלי השרת אלא תלוי בפורמט ההודעה. כמו כן, ככל הנראה התקשורת מתקיימת בצורה אסינכרונית, כלומר הלקוח ישלח בקשה אך לא ימתין (לחסום) לתגובה. זה מאפשר ללקוח להמשיך לתפקד גם אם השרת לא יהיה זמין (קורס, למשל). תכנון זה, בו הלקוח אינו תלוי יותר בשרת, נחשב כמצופה יותר באופן רופף.

כאשר מעריכים אם להשתמש בעיצוב מכוון הודעות חשוב להבין את היתרונות והחסרונות של מערכת כזו. המקצוענים כוללים:

  • צימוד רופף
  • ניתוב ושינוי הודעות קלים יותר
  • מטען גמיש יותר (יכול לכלול קבצים מצורפים בינאריים, למשל)
  • יכול להשתמש במספר הודעות יחד כדי להפעיל הליך נתון

באופן כללי, גישה מכוונת מסרים מוכיחה כי היא גמישה יותר מגישת RPC.

הנה כמה חסרונות:

  • זה דורש עבודה רבה יותר לפיתוח אינטראקציה של לקוח / שרת תוך שימוש בגישה מכוונת הודעה בהשוואה לגישת RPC כמו RMI מכיוון שפיתוח אינטראקציה של לקוח / שרת באמצעות הודעה מייצג רמה אחרת של כיוון מפני RPC. מורכבות מתווספת באמצעות יצירת המסר בצד הלקוח (לעומת קריאה לפרוצדורה בגישה RPC) ובצד השרת עם קוד עיבוד הודעות. בגלל מורכבותו הנוספת, עיצוב מכוון מסר יכול להיות קשה יותר להבנה ולניפוי באגים.
  • קיים סיכון לאבד מידע מסוג לשפת התכנות בה נשלחה ההודעה. לדוגמא, כפול ב- Java עשוי שלא לתרגם ככפול בהודעה.
  • ברוב המקרים ההקשר העסקי בו נוצרה ההודעה אינו מתפשט לשרת המסרים.

בהתחשב בעד ונגד, מתי כדאי להשתמש בגישה מכוונת מסרים? התרחיש הנפוץ ביותר מתרחש כאשר תקשורת הלקוח / השרת מתרחשת דרך האינטרנט והלקוח והשרת שייכים לחברות שונות. בתרחיש זה יכול להיות די קשה לשתי החברות להסכים על ממשק ההליך. כמו כן, יתכן שהחברות לא ירצו להשתמש באותה שפת תכנות. בדוגמה אחרת, החברות המעורבות עשויות לרצות להשתמש במודל תקשורת אסינכרוני, כך שאף אחד מהם לא יהיה תלוי ביישום של האחר.

תרחיש מסרים אטרקטיבי נוסף מתרחש כשאתה מפתח מערכת מבוססת אירועים בה אירועים נוצרים ואז נצרכים על ידי גורמים מתעניינים. רוב ממשקי המשתמש הם מבוססי אירועים. לדוגמא, הם עשויים ליצור אירוע של לחיצת עכבר ובו מעוניינים להאזין לאירוע ולבצע פעולה על בסיס זה. בתרחיש זה, שימוש בגישת מסרים מאפשר לך להסיר את התלות בין אירוע (או פעולה במערכת) לבין תגובת המערכת לאירוע שמבוצע בשרת.

עכשיו, אחרי שאנחנו מבינים קצת את המסרים, אנחנו מוכנים להוסיף XML למשוואה. תוספת XML להעברת הודעות פירושה שאנחנו מסוגלים להשתמש בשפת עיצוב נתונים גמישה עבור ההודעות שלנו. בהודעות, הלקוח וגם השרת צריכים להסכים על פורמט ההודעה. XML מקל על כך בכך שהוא מחליט על בעיות רבות בעיצוב נתונים ובתוספת תקני XML אחרים כגון Rosetta Net. אין צורך בעבודה נוספת בכדי ליצור פורמט הודעה.

מה עושה מתווך הודעות XML?

מתווך הודעות פועל כשרת במערכת מוכוונת הודעות. תוכנת מתווך הודעות מבצעת פעולות בהודעות שהיא מקבלת. פעולות אלה כוללות:

  • עיבוד כותרת
  • בדיקות אבטחה והצפנה / פענוח
  • טיפול בשגיאות ובחריגים
  • ניתוב
  • קְרִיאָה
  • טרנספורמציה

עיבוד כותרת

עיבוד כותרת הוא בדרך כלל אחת הפונקציות הראשונות המבוצעות בהודעה עם קבלתו בתוך מתווך XML. עיבוד כותרת כולל בחינה של שדות הכותרת של הודעות נכנסות וביצוע פונקציות מסוימות. עיבוד כותרת יכול לכלול הוספת מספר מעקב להודעה נכנסת או להבטיח כי קיימים כל שדות הכותרת הדרושים לעיבוד ההודעה. בהודעת ה- XML ​​לדוגמא למטה, מתווך ההודעות יכול לבדוק את toשדה הכותרת בכדי לוודא שזה היעד המתאים להודעה זו.

בדיקות אבטחה והצפנה / פענוח

מנקודת מבט ביטחונית, מתווך הודעות יכול לבצע מספר פעולות שונות, אך ככל הנראה תרצה לבצע את "השלושה הגדולים" של אבטחה: אימות, הרשאה והצפנה. ראשית, לאחר שיקבע כי ההודעה מכילה נתונים שניתן להשתמש בהם כדי לאמת, מתווך ההודעות יאמת הודעות כנגד מסד נתונים או ספריה אבטחה. שנית, מתווך ההודעות יאשר פעולות שניתן לבצע באמצעות הודעה מסוג זה ומנהל מורשה. לבסוף, ההודעה שתגיע למתווך ההודעות עשויה להיות מוצפנת באמצעות ערכת הצפנה כלשהי. באחריות המתווך יהיה לפענח את ההודעה על מנת לעבד אותה הלאה.

טיפול בשגיאות ובחריגים

טיפול בשגיאות ובחרגים הוא עוד פונקציונליות חשובה שמבצע מתווך ההודעות. באופן כללי, ההודעה תגיב ללקוח (בהנחה שהופעל סינכרוני) עם הודעת שגיאה, הנגרמת כאשר ההודעה שנשלחה למתווך אינה מכילה מידע מספיק או מדויק. סיבה נוספת לשגיאות או חריגים תתרחש בעת שירות הבקשה (למעשה הפעלת הליך / שיטה המבוססת על מטען ההודעה).

ניתוב

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

הודעה תיתקל תחילה בחלק המאזין של המתווך. מרבית מתווכי ההודעות של XML מספקים תמיכה בהובלות שונות (פרוטוקולים) כגון HTTP, SMTP, JMS (יישום ספק מסוים) וכן הלאה. המתווך שלנו מאפשר זאת על ידי בידוד חלק ההובלה. היצירה המוצגת למטה פשוט מקבלת את ההודעה בהעברה נתונה, ממקמת את ההודעה הנכנסת למשתנה מחרוזת ומתקשרת לסינגלטון הברוקר: