التوجه نحو الخدمة مقابل التوجه نحو الكائن - هل يمكن أن يتعايشا؟

Question

لقد كان هناك الكثير من الاهتمام به الخدمات الهندسية الموجهة (SOA) في شركتي مؤخرًا.كلما حاولت أن أرى كيف يمكن أن نستخدمها، دائمًا ما أواجه حاجزًا عقليًا.بشكل فظ:

• يقول التوجه الكائني:"الاحتفاظ بالبيانات والأساليب التي تعالج البيانات (العمليات التجارية) معًا"؛

• يقول التوجه الخدمي:"الحفاظ على عملية الأعمال في الخدمة، وتمرير البيانات إليها".

انتهت المحاولات السابقة لتطوير SOA إلى تحويل التعليمات البرمجية الموجهة للكائنات إلى هياكل بيانات وإجراءات (خدمات) منفصلة تتلاعب بها، وهو ما يبدو وكأنه خطوة إلى الوراء.

سؤالي هو: ما هي الأنماط والبنى والاستراتيجيات وما إلى ذلك؟السماح لـ SOA وOO بالعمل معًا؟

---

يحرر: الإجابات التي تقول "OO للأجزاء الداخلية، SOA لحدود النظام" رائعة ومفيدة، ولكن هذا ليس ما كنت أقصده تمامًا.

لنفترض أن لديك Account الكائن الذي لديه عملية تجارية تسمى Merge الذي يجمعه مع حساب آخر.سيبدو نهج OO النموذجي كما يلي:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

في حين أن مكافئ SOA الذي رأيته يبدو كما يلي:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

في حالة OO، يتم تضمين منطق الأعمال (والوعي بالكيان بفضل نمط ActiveRecord) في ملف Account فصل.في حالة SOA Account الكائن هو في الحقيقة مجرد هيكل، نظرًا لأن جميع قواعد العمل مدفونة في الخدمة.

هل يمكنني الحصول على فئات غنية وعملية وخدمات قابلة لإعادة الاستخدام في نفس الوقت؟

Answer 1

أعتقد حقًا أن SOA مفيد فقط للواجهات الخارجية (بشكل عام، لأولئك خارج شركتك)، وحتى ذلك الحين، فقط في الحالات التي لا يكون فيها الأداء مهمًا حقًا، لا تحتاج إلى تسليم الرسائل بشكل منظم.

وفي ضوء ذلك، أعتقد أن بإمكانهما التعايش.حافظ على عمل تطبيقاتك والتواصل باستخدام فلسفة OO، وفقط عند الحاجة إلى واجهات خارجية (لأطراف ثالثة)، قم بكشفها عبر SOA (هذا ليس ضروريًا، ولكنه طريقة واحدة).

أشعر حقًا أنه يتم الإفراط في استخدام SOA، أو على الأقل يتم اقتراح البنى التي تحتوي على SOA كثيرًا.لا أعرف حقًا أي أنظمة كبيرة تستخدم SOA داخليًا، وأشك في أنها تستطيع ذلك.يبدو الأمر وكأنه شيء قد تستخدمه فقط لإجراء عمليات المزج أو طلبات بسيطة لتوقعات الطقس، وليس بناء أنظمة جادة فوقها.

Answer 2

رأيي هو أن SOA يمكن أن تكون مفيدة، على المستوى الكلي، ولكن من المحتمل أن تظل كل خدمة كبيرة بما يكفي لتحتاج إلى العديد من المكونات الداخلية.قد تستفيد المكونات الداخلية من بنية OO.

يجب تعريف واجهة برمجة تطبيقات SOA بعناية أكبر من واجهات برمجة التطبيقات الداخلية، نظرًا لأنها واجهة برمجة تطبيقات خارجية.يجب أن تكون أنواع البيانات التي يتم تمريرها على هذا المستوى بسيطة قدر الإمكان، دون أي منطق داخلي.إذا كان هناك بعض المنطق الذي ينتمي إلى نوع البيانات (على سبيل المثال.التحقق من الصحة)، ويفضل أن تكون هناك خدمة واحدة مسؤولة عن تشغيل المنطق على نوع البيانات.

Answer 3

SOA هي بنية جيدة للتواصل بين الأنظمة أو التطبيقات.

يحدد كل تطبيق واجهة "خدمة" تتكون من الطلبات التي سيتعامل معها والاستجابات المتوقعة.

النقاط الرئيسية هنا هي خدمات محددة بشكل جيد، مع واجهة محددة بشكل جيد.إن كيفية تنفيذ خدماتك فعليًا لا أهمية لها فيما يتعلق بـ SOA.

لذلك أنت حر في تنفيذ خدماتك باستخدام أحدث وأفضل تقنيات OO، أو أي منهجية أخرى تناسبك.(لقد رأيت حالات متطرفة حيث يتم تنفيذ "الخدمة" بواسطة بشر فعليين يقومون بإدخال البيانات على الشاشة - ومع ذلك كان كل شيء لا يزال كتابًا نصيًا SOA!).

Answer 4

أعتقد أن هذا سوء فهم لاتجاه الكائن.حتى في Java، الأساليب عمومًا ليست جزءًا من أشياء ولكن منهم فصل (وحتى هذه "العضوية" ليست ضرورية لتوجيه الكائن، ولكن هذا موضوع مختلف).الفصل هو مجرد وصف للنوع، لذا فهو في الواقع جزء من البرنامج، وليس البيانات.

SOA وOO لا يتعارضان مع بعضهما البعض.يمكن للخدمة قبول البيانات، وتنظيمها في كائنات داخليًا، والعمل عليها، وأخيرًا إعادتها بأي تنسيق مطلوب.

Answer 5

لقد سمعت جيمس جوسلينج يقول أنه يمكن تنفيذ SOA في COBOL.

إذا قرأت وصف Alan Kay الخاص لأصول OOP، فهو يصف مجموعة من أجهزة الكمبيوتر الصغيرة التي تتفاعل لأداء شيء مفيد.

خذ بعين الاعتبار هذا الوصف:

يجب أن يتكون X الخاص بك من Ys.يجب أن يكون كل Y مسؤولاً عن مفهوم واحد، ويجب أن يكون قابلاً للوصف بالكامل من حيث الواجهة الخاصة به.يمكن لأحد Y أن يطلب من Y آخر القيام بشيء ما عبر تبادل الرسائل (حسب واجهاته المحددة).

في بعض الحالات، قد يتم تنفيذ X بواسطة Z، والذي يديره وفقًا لواجهته.لا يُسمح لـ X بالوصول المباشر إلى X آخر Z.

أعتقد أن البدائل التالية ممكنة:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

إذا كنت تفكر في المقام الأول من حيث التغليف، وإخفاء المعلومات، والاقتران السائب، وواجهات الصندوق الأسود، فهناك قدر كبير من التشابه.إذا تعثرت في تعدد الأشكال والميراث وما إلى ذلك.أنت تفكر في البرمجة/التنفيذ بدلاً من الهندسة المعمارية، IMHO.

Answer 6

إذا سمحت لخدماتك بتذكر الحالة، فيمكن اعتبارها مجرد كائنات كبيرة ذات وقت استدعاء بطيء.

إذا لم يُسمح لهم بالاحتفاظ بالحالة، فهم كما قلت تمامًا - مشغلون على البيانات.

يبدو أنك قد تقوم بتقسيم نظامك إلى عدد كبير جدًا من الخدمات.هل لديكم معايير مكتوبة ومتفق عليها بشكل متبادل لكيفية التقسيم؟

اعتماد SOA يفعل ذلك لا يقصد تخلص من جميع الأشياء الخاصة بك ولكن يتعلق الأمر بتقسيم نظامك إلى أجزاء كبيرة قابلة لإعادة الاستخدام.