عرّف Coulouris الأنظمة الموزعة على أنها "أنظمة تتواصل فيها مكونات الأجهزة و / أو البرامج الموجودة في شبكة الكمبيوتر وتنسق أعمالها من خلال تبادل الرسائل".
أصبح هذا المفهوم شائعًا في السنوات الأخيرة بسبب عدة عوامل. كان العامل الأول الذي عزز تطوير الأنظمة الموزعة هو ظهور شبكات محلية عالية السرعة. عامل مهم آخر هو التقدم التكنولوجي في أداء أجهزة الكمبيوتر الشخصية وتطوير البرامج لدعم التطبيقات الموزعة. ترتبط الأنظمة الموزعة بمفهوم الويب والإنترنت. مع تطور الويب وظهور مناطق وتفاعلات واحتياجات وتطبيقات جديدة ، ظهر مفهوم الويب 2.0. تمت صياغة هذا المصطلح بواسطة Tim O'Reilly في عام 2004 للإشارة إلى الجيل الثاني في تاريخ الويب استنادًا إلى مجتمعات المستخدمين ومجموعة خاصة من الخدمات ، مثل الشبكات الاجتماعية أو المدونات أو مواقع wiki أو الأشخاص ، والتي تشجع على التعاون والسرعة. تبادل المعلومات بين المستخدمين.
استندت البنى الأولى التي يمكن اعتبارها موجهة للخدمة (SOA) على CORBA (بنية وسيط طلب كائن مشترك) ، والتي عملت كطبقة تجريد لربط العناصر المختلفة للهندسة المعمارية وخدمات البناء. كانت التقنيات السابقة الأخرى هي DCOM (نموذج كائن المكون الموزع) أو RPC (بروتوكول الإجراء البعيد). مع الحاجة إلى تصميم وتنفيذ الأنظمة الموزعة بكفاءة على الويب ، تظهر العديد من التحديات ، ويركز بعضها على التطوير نفسه (الأداء ، وتجربة المستخدم ، وما إلى ذلك) والأخرى التكميلية ، بناءً على قابلية إعادة الاستخدام وتوافق الخدمات. من هذه الاحتياجات تنشأ خدمات الويب ، التي توفر آليات موحدة لربط مختلف المستخدمين بخوادم المعلومات.
المهندسون الموجهون إلى الخدمة
وفقًا لـ SOA (بنية الخدمة الموجهة) هي هياكل برمجية تحدد استخدام الخدمات لدعم متطلبات العمل ، والتي تهدف إلى تحقيق أقل اقتران ممكن بين وكلاء البرامج. الخدمة هي وحدة عمل يؤديها مقدم الخدمة لتحقيق النتيجة النهائية التي يرغب فيها مستهلك الخدمة. يعتبر كل من مقدم الخدمة ومستهلك الخدمة من الأدوار التي يؤديها وكلاء البرامج ، وليس مالكو البرامج. بشكل عام ، فإن البنية الموجهة نحو الخدمة هي حل برمجي يهدف إلى تمكين المؤسسة من تنظيم العمليات المختلفة والاستفادة منها. باستخدام SOA ، لم تعد تطبيقات البرامج كتل ضخمة من الوظائف والعمليات. بدلاً من ذلك ، تتكون هذه التطبيقات من خدمات معيارية مجمعة. تذكر أن الخدمة هي وظيفة برمجية بسيطة (مثل إلغاء قرص مضغوط). يمكن تشغيله عند الطلب بواسطة أي نظام ، بغض النظر عن نظام التشغيل أو النظام الأساسي أو لغة البرمجة أو الموقع الجغرافي.
ما هو ثوري في SOA ليس المفهوم نفسه ، الذي كان موجودًا منذ فترة طويلة ، ولكن حقيقة أنه يمكن تنفيذه عبر WWW (شبكة الويب العالمية). بنفس الطريقة التي يتم بها تحميل صفحات الويب على أي نظام أساسي ، تعمل خدمات الويب بشكل مشابه بغض النظر عن النظام الأساسي حيث يتم إنشاؤها باستخدام
المعايير العالمية.
تنبع فكرة SOA مباشرة من البرمجة الشيئية ، والتي تشير إلى وجود علاقة بين البيانات ومعالجتها. وبالتالي ، فهم يحددون الخدمات رسميًا من خلال واجهات مستقلة عن النظام الأساسي الأساسي ولغة البرمجة. تخفي هذه الواجهات خصائص تنفيذها ، مما يجعلها مستقلة عن المطور ولغة البرمجة. من خلال هذه البنى ، من الممكن تصميم وتنفيذ أنظمة قابلة للتطوير بدرجة عالية تعكس منطق الأعمال وفي نفس الوقت تسهل التفاعل بين أنظمة مختلفة مملوكة أو طرف ثالث. السبب وراء رغبتنا في قيام شخص آخر بالعمل نيابة عنا هو أنهم خبراء. عادةً ما يكون استخدام الخدمة أرخص وأكثر فاعلية من القيام بذلك بنفسك. لذلك يفهم معظمنا أنه لا يمكننا أن نكون خبراء في كل شيء. يمكن تطبيق نفس القاعدة على بناء أنظمة البرمجيات.
تعد الواجهات مهمة جدًا ، إذا لم يتم تعريفها جيدًا أو لا تعمل ، فلن يعمل النظام. يعد دمج المزيد من الواجهات أمرًا مكلفًا ويزيد أيضًا من احتمال حدوث أخطاء في التطبيقات الموزعة. تعد الواجهات البعيدة أبطأ جزء في معظم التطبيقات الموزعة. مع كل هذا ، بدلاً من إنشاء واجهات جديدة لكل تطبيق ، من المنطقي إعادة استخدام الواجهات العامة لجميع التطبيقات.
لذلك ، نظرًا لأن لدينا عددًا قليلاً فقط من الواجهات العامة المتاحة ، يجب علينا تضمين دلالات خاصة بالتطبيق في الرسائل. يمكننا إرسال أي نوع من الرسائل من خلال واجهاتنا ، ولكن هناك بعض القواعد التي يجب اتباعها للقول إن البنية موجهة نحو الخدمة.
- أولاً ، يجب أن تكون الرسائل وصفية وليست إرشادية ، حيث أن مزود الخدمة مسؤول عن حل المشكلة. على سبيل المثال ، سيكون الأمر مشابهًا لحالة الذهاب إلى مطعم وإخبار النادل بما تود أن تشربه وما تفضله ، لكن لا ينبغي لنا أن نشرح للطاهي كيفية تحضير أطباقك خطوة بخطوة.
- ثانيًا ، لن يتمكن مقدمو الخدمة من فهم طلبك إذا لم تكن رسائلهم مكتوبة بتنسيق وبنية ومفردات مفهومة من قبل جميع المعنيين. وبالتالي ، فإن الحد من مفردات وهيكل الرسائل هو أ
ضروري للاتصال الفعال. كلما كانت الرسالة أضيق ، كان من الأسهل فهمها.
- ثالثا ، إمكانية التمديدات ذات أهمية حيوية. العالم مكان دائم التغير ، وكذلك البيئة التي تعيش فيها البرامج. تتطلب هذه التغييرات تغييرات مقابلة في برامج النظام والمستهلكين من الخدمات ومقدمي الخدمات والرسائل التي يتبادلونها. إذا لم تكن الرسائل قابلة للتوسيع ، فسيتم تقييد المستهلكين ومقدمي الخدمة بإصدار معين من الخدمة. القيد وقابلية التمدد مرتبطان بعمق ، فأنت بحاجة إلى كليهما ، وزيادة أحدهما يعني تقليل الآخر. المثالي هو تحقيق التوازن الصحيح.
- رابعًا ، يجب أن يكون لدى SOA آلية تسمح للمستهلك باكتشاف مزود الخدمة في سياق الخدمة التي يسعى إليها المستهلك. يجب أن تكون الآلية مرنة وليست سجلاً مركزياً.
- خامسًا ، الخدمة عديمة الجنسية: يجب أن تحتوي كل رسالة يرسلها المستهلك إلى مقدم الخدمة على جميع المعلومات اللازمة لمقدم الخدمة لمعالجتها. يجعل هذا التقييد مزود الخدمة أكثر قابلية للتوسع ، حيث لا يحتاج الموفر إلى تخزين معلومات الحالة بين الطلبات. يمكن أن يسمى هذا "خدمة الإنتاج الشامل" حيث يمكن معالجة كل طلب بشكل عام. يوفر هذا التقييد أيضًا مزيدًا من الرؤية ، حيث يمكن لأي برنامج مراقبة أن يفحص الطلب بشكل مستقل ويستخلص نيته. يسمح هذا أيضًا بالاسترداد السهل من حالات الفشل الجزئي نظرًا لعدم وجود حالات وسيطة ، مما يجعل الخدمة أكثر موثوقية.
- سادساً ، الطلبات غير الفعالة (عدم إجراء تغييرات): الطلبات المكررة التي يتلقاها وكيل البرمجيات لها نفس تأثير طلب واحد. يسمح هذا المطلب للموفرين والمستهلكين بزيادة الموثوقية الإجمالية لـ الخدمة ، ببساطة كرر الطلب إذا كان هناك أي فشل.
لذلك يمكننا القول أن الخدمية ليست أداة ، ولكنها مجموعة من المعايير لبناء تطبيقات جديدة ، أكثر ديناميكية وأقل اعتماداً. تسهل بنية SOA الوصول إلى منطق الأعمال والمعلومات عبر خدمات متعددة بطريقة منهجية ، ويمكنها أيضًا تنظيم عدة خدمات عن بُعد لإنشاء خدمة واحدة. معظم تحدد التعريفات استخدام خدمات الويب ، والتي سنراها في الفصل التالي ، في تنفيذ بنية موجهة نحو الخدمة. ومع ذلك ، يمكن تنفيذه باستخدام أي تقنية أخرى قائمة على الخدمة.