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

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

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

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

सेवा बंडलों को, 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) और रिमोट प्रोसीजर कॉल (आरपीसी).

Pub/Sub में, सिस्टम वाहन की बदलती स्थिति के हिसाब से काम करता है. इसके लिए, वह दिलचस्पी रखने वाले किसी भी कॉम्पोनेंट को डेटा स्ट्रीम करता है. डेटा को विषयों के हिसाब से व्यवस्थित किया जाता है. पब्लिशर, विषयों पर मैसेज भेजते हैं. पब्लिशर को यह जानने की ज़रूरत नहीं होती कि कौनसे (या कितने) सदस्य सुन रहे हैं. सदस्य, विषयों पर मैसेज पाते हैं. उन्हें यह जानने की ज़रूरत नहीं होती कि मैसेज किस पब्लिशर ने भेजे हैं.

इसके उलट, आरपीसी को कार्रवाई और नतीजे के लिए डिज़ाइन किया गया है. इसका इस्तेमाल तब किया जाता है, जब कॉलर कोई अनुरोध शुरू करता है, क्योंकि उसे किसी खास नतीजे या उस कार्रवाई की पुष्टि की ज़रूरत होती है. कॉल करने वाला व्यक्ति, चैनल पर कोई खास तरीका लागू करता है.

ये पैटर्न, अलग-अलग ऑपरेशनल ज़रूरतों को पूरा करते हैं. हालांकि, इनमें एक जैसी स्ट्रक्चरल प्रॉपर्टी होती है: दोनों में, कम्यूनिकेशन के लिए नाम वाले पाथ का इस्तेमाल किया जाता है. Pub/Sub के लिए विषय और आरपीसी के लिए चैनल. इससे, भेजने वाले की पहचान को पाने वाले से अलग किया जा सकता है.

पब्लिशर और सदस्य के बारे में एलान करना

पब्लिश-सब्सक्राइब, मैसेज भेजने का एक ऐसा तरीका है जिसमें मैसेज भेजने वाले लोगों को पब्लिशर कहा जाता है. ये लोग, मैसेज सीधे तौर पर पाने वाले लोगों को नहीं भेजते. मैसेज पाने वाले लोगों को सब्सक्राइबर कहा जाता है. इसके बजाय, पब्लिशर मैसेज को विषयों के हिसाब से कैटगरी में बांटते हैं. इसके बाद, सदस्य एक या उससे ज़्यादा विषयों की सदस्यता लेते हैं और उन्हें सिर्फ़ वे मैसेज मिलते हैं जो उन विषयों के लिए पब्लिश किए जाते हैं. पब्लिश-सब्सक्राइब के बारे में ज़्यादा जानने के लिए, पब्लिश-सब्सक्राइब पैटर्न देखें.

किसी सेवा बंडल में पब्लिशर जोड़ना

यहां दिए गए उदाहरण में, 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 एक्सटेंशन वाली फ़ाइल).
• 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 एक्सटेंशन वाली फ़ाइल).
• topic पब्लिकेशन के विषय के लिए यूनीक आइडेंटिफ़ायर. यह पब्लिशर के विषय से मेल खाना चाहिए. साथ ही, यह अंग्रेज़ी के छोटे अक्षरों में डैश का इस्तेमाल करके लिखा होना चाहिए.

RPC क्लाइंट और सर्वर तय करना

रिमोट प्रोसीजर कॉल (आरपीसी) की मदद से, फ़ंक्शन कॉल को किसी भी जगह से किया जा सकता है. इस पैटर्न में, चैनल को नाम दिया गया है. यह एक ऐसा पॉइंट है जहां क्लाइंट और प्रोवाइडर मिलते हैं. किसी खास सेवा इंस्टेंस के बजाय चैनल को टारगेट करने से, फ़्रेमवर्क कमांड के मकसद को लागू करने की जगह से अलग कर देता है.

यहां दिए गए उदाहरण में, ClimateControl सेवा बंडल को सर्वर और BodyControl सेवा बंडल को क्लाइंट के तौर पर दिखाया गया है:

package: "com.sdv.cc"

service_bundle {
  name: "ClimateControl"

  server {
    service: "SetTemperature"
    channel: "climate-control"
  }
}

service_bundle {
  name: "BodyControl"

  client {
    service: "SetTemperature"
    channel: "climate-control"
  }
}

जगह:

• server से पता चलता है कि सेवा बंडल एक ऐसा सर्वर है जो कुछ आरपीसी सेवा उपलब्ध कराता है. इसकी पहचान service के तौर पर SetTemperature के तौर पर की जाती है.
• client से पता चलता है कि सेवा बंडल, एक ऐसा क्लाइंट है जो SetTemperature सेवा को शुरू करता है.
• channel, आरपीसी चैनल का नाम है. यह अंग्रेज़ी के छोटे अक्षरों में डैश-केस में होना चाहिए. साथ ही, हर सेवा के लिए यूनीक होना चाहिए.

इस उदाहरण में, BodyControl सर्विस बंडल को ClimateControl सर्विस बंडल में रिमोट प्रोसीज़र कॉल करने की अनुमति दी गई है, ताकि तापमान सेट किया जा सके.

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

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