सेवा का आर्किटेक्चर तय करना

सेवा आर्किटेक्चर का मतलब है कि सेवाएं कैसे बनी हैं और वे सिस्टम में मौजूद अन्य कॉम्पोनेंट के साथ कैसे कम्यूनिकेट करती हैं.

सेवा बंडल बनाना

सेवा बंडल में, सेवा की उन यूनिट को ग्रुप में रखा जाता है जिन्हें एक साथ डिप्लॉय किया जा सकता है. सेवा बंडल के लिए, सिर्फ़ नाम की प्रॉपर्टी ज़रूरी होती है. नाम, पैकेज के नाम के साथ मिलकर सेवा बंडल का पूरी तरह से क्वालिफ़ाइड नाम बनाता है.

सेवा बंडल, Vehicle Services Interface Definition Language (VSIDL) फ़ाइलों (.vsidl एक्सटेंशन वाली फ़ाइलें) के साथ तय किए जाते हैं.

यहां दिए गए उदाहरण में, दो सेवा बंडल दिखाए गए हैं: TirePressureMonitoring सेवा बंडल और BodyControl सेवा बंडल:

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

यहां:

• service_bundle से पता चलता है कि स्ट्रक्चर, सेवा बंडल है.
• name सेवा बंडल का नाम है.

मैसेजिंग पैटर्न: Pub/Sub और RPC

एसडीवी फ़्रेमवर्क, दो मुख्य मैसेजिंग पैटर्न का इस्तेमाल करता है: पब्लिश-सब्सक्राइब (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 पब्लिकेशन क्यू में सेव किए जा सकने वाले मैसेज की संख्या. यह दो या इससे ज़्यादा की कोई सम संख्या होनी चाहिए.

किसी सेवा बंडल में सदस्यता जोड़ना

यहां दिए गए उदाहरण में, 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 सेवा बंडल को रिमोट प्रोसीजर कॉल कर सकता है.

अगला कदम क्या है

अपना आर्किटेक्चर तय करने के बाद, मिडलवेयर कोड जनरेट करें.