ארכיטקטורת שירות מתייחסת לאופן שבו השירותים מורכבים ולאופן שבו הם מתקשרים עם רכיבים אחרים במערכת.
יצירת חבילות שירות
חבילות שירותים הן קבוצות של יחידות שירות קשורות שאפשר לפרוס יחד. המאפיין היחיד שנדרש לחבילת שירות הוא שם. יחד עם שם החבילה, השם יוצר את השם המוגדר במלואו של חבילת השירות.
חבילות שירות מוגדרות באמצעות קבצים של שפת הגדרת ממשקי שירותים לרכב (VSIDL) (קבצים עם הסיומת .vsidl).
בדוגמה הבאה מוצגים שני חבילות שירותים: חבילת שירותים של TirePressureMonitoring וחבילת שירותים של BodyControl:
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
}
service_bundle {
name: "BodyControl"
}
כאשר:
-
service_bundleהוא המזהה של המבנה כחבילת שירותים. -
nameהוא שם חבילת השירות.
דפוסי העברת הודעות: Pub/Sub ו-RPC
מסגרת ה-SDV משתמשת בשני דפוסי העברת הודעות עיקריים: פרסום-הרשמה (Pub/Sub) וקריאה לפרוצדורה מרוחקת (RPC).
ב-Pub/Sub, המערכת מגיבה למצב המתפתח של הרכב על ידי סטרימינג של נתונים לכל הרכיבים הרלוונטיים. הנתונים מאורגנים לפי נושאים. בעלי תוכן דיגיטלי שולחים הודעות בנושאים. המוציא לאור שולח הודעות בנושאים בלי לדעת אילו מנויים (או כמה מנויים) מאזינים. המנויים מקבלים הודעות בנושאים בלי לדעת אילו מפרסמים בדיוק שלחו את ההודעות.
לעומת זאת, RPC נועד לפעולה ולתוצאה. היא משמשת כשהמתקשר יוזם בקשה כי חשוב לו לקבל את התוצאה הספציפית או אישור על הפעולה. מבצע הקריאה מפעיל שיטה ספציפית בערוץ.
הדפוסים האלה משמשים לצרכים תפעוליים שונים, אבל יש להם מאפיין מבני משותף: שניהם מסתמכים על נתיבי תקשורת עם שמות – נושאים ב-Pub/Sub וערוצים ב-RPC – כדי להפריד בין הזהות של השולח לבין הזהות של המקבל.
הצהרה על אפליקציה לשליחת הודעות ואפליקציה רשומה
מודל פרסום והרשמה הוא דפוס העברת הודעות שבו שולחי ההודעות, שנקראים מפרסמים, לא שולחים את ההודעות ישירות לנמענים ספציפיים, שנקראים נרשמים. במקום זאת, בעלי התוכן הדיגיטלי מסווגים את ההודעות לנושאים, והמנויים נרשמים לנושא תקשורת אחד או יותר ומקבלים רק הודעות שפורסמו בנושאים האלה. מידע נוסף על פרסום והרשמה למינוי זמין במאמר בנושא דפוס פרסום והרשמה למינוי.
הוספת מוציא לאור לחבילת שירותים
בדוגמה הבאה מוצג מפרסם שנוסף לחבילת השירות TirePressureMonitoring:
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
publisher {
message: "TirePressure"
topic: "front-left"
capacity: 10
}
}
service_bundle {
name: "BodyControl"
...
}
כאשר:
publisherהודעות שירות מפרסמות הודעות בתור הודעות.messageמבנה הנתונים או סוג ההודעה שמוגדרים ב-protobuf (קובץ עם הסיומת.protobuf).topicמזהה ייחודי של נושא הפרסום. הוא חייב להיות באותיות קטנות עם מקפים.capacityמספר ההודעות שאפשר להכניס לתור הפרסום. הערך חייב להיות מספר זוגי מ-2 ומעלה.
הוספת חבילת מינוי לשירות
בדוגמה הבאה מוצג בעל תוכן דיגיטלי שנוסף לחבילת השירותים BodyControl:
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
publisher {
message: "TirePressure"
topic: "front-left"
capacity: 10
}
}
service_bundle {
name: "BodyControl"
subscriber {
message: "com.android.sdv.sample.vsidl.TirePressure"
topic: "front-left"
}
}
כאשר:
- חבילת השירותים נרשמת לנושאים.
subscriber messageמבנה הנתונים או סוג ההודעה שמוגדרים ב-protobuf (קובץ עם הסיומת.protobuf).topicמזהה ייחודי של נושא הפרסום. היא צריכה להתאים לנושא של בעל התוכן הדיגיטלי ולהיות באותיות קטנות עם מקפים.
הגדרת לקוחות ושרתים של RPC
הפעלת פרוצדורה מרוחקת (RPC) מספקת עצמאות מיקום של הפעלות פונקציה. בדפוס הזה, הערוץ משמש כנקודת מפגש בעלת שם שבה הלקוח והספק נפגשים. כשמטרגטים את הערוץ ולא מופע ספציפי של שירות, המסגרת מפרידה בין הכוונה של הפקודה לבין המיקום הפיזי של ההטמעה.
בדוגמה הבאה, חבילת השירות CabinComfort מארחת שרת ClimateControl, וחבילת השירות BodyControl מורחבת כדי לארח לקוח ClimateControl:
package: "com.sdv.cc"
service_bundle {
name: "CabinComfort"
server {
service: "ClimateControl"
channel: "front-climate-control"
}
}
service_bundle {
name: "BodyControl"
client {
service: "ClimateControl"
channel: "front-climate-control"
}
subscriber {
message: "com.android.sdv.sample.vsidl.TirePressure"
topic: "front-left"
}
}
כאשר:
-
serverמציין שחבילת השירות מכילה שרת שמספק שירות RPC כלשהו (מזוהה על ידיserviceכ-ClimateControl). -
clientמציין שחבילת השירות מכילה לקוח שמפעיל את השירותClimateControl. -
channelהוא השם של ערוץ ה-RPC. הוא צריך להיות באותיות קטנות עם מקפים, וייחודי לכל שירות.
בדוגמה הזו, חבילת השירות BodyControl יכולה לבצע קריאות לפרוצדורות מרוחקות לחבילת השירות CabinComfort כדי לשלוט באקלים באזור הקדמי של תא הנוסעים.
המאמרים הבאים
אחרי שמגדירים את הארכיטקטורה, יוצרים קוד של תוכנת ביניים.