هل تصميم العملية هو برمجة تعريفية حقًا؟

Question

لقد سمعت من شخص ما أنهم يستخدمون أداة أتمتة العمليات التجارية (مثل Weblogic Integration) كلغة برمجة (ما يبدو وكأنه شيء غبي) لجعل الأمور تصريحية.ثم وضعوا كل المنطق داخل العملية، كل على حدة if و while.

ولكن، أليست العملية بمثابة كيان خطوة بخطوة للوصول إلى الهدف؟

بالنسبة لي، هذا يجعل العملية حتمية تمامًا.ماذا تعتقد؟

Answer 1

وأنها بالتأكيد ليست ما الناس عادة ما يعني عندما يتحدثون عن التعريفي البرمجة ، حتى لو كان بعض الشعور يمكن أن يسمى التعريفي.

Answer 2

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

يتم الإعلان عن MS Workflow Foundation على أنها تحتوي على محرك قواعد، ولكن هذا أمر مبسط إلى حد ما ولا يقوم حقًا بالتسلسل الأمامي، إلا بطريقة ملتوية إلى حد ما.تقوم ILOG في الواقع بإنشاء محول لمحرك القواعد الخاص بها خصيصًا لإسقاطه في أساس سير عمل MS.

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

ومع ذلك، تقوم بعض الأنظمة أيضًا بتنفيذ نظام ترميز قائم على تغيير الحالة لسير العمل، والذي يمكن وصفه بشكل معقول بأنه تعريفي، ولكن لا يزال لديهم وضع حتمي للتفاعل مع النظام الأساسي.ما زالوا يقومون بتحديث المتغيرات ولها آثار جانبية.

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

من الناحية العملية، فإن الأداة المصممة لكتابة استعلامات SQL وتحريرها وتشغيلها، والتي يتم تزويدها بإطار عمل برمجة نصية "لغير المبرمجين"، تجعل المرء يتساءل عن الجمهور الذي تستهدفه هذه الأداة حقًا.باعتبارها لغة برمجة نصية، فإن أدوات نمذجة سير العمل خرقاء إلى حد ما وتوفر فرصًا محدودة جدًا للتجريد؛ومن الناحية العملية، فإن لغة البرمجة النصية المستندة إلى .Net مثل IronPython أو Boo، خاصة بالتزامن مع آلية القوالب المناسبة، ستكون إضافة قوية جدًا لمثل هذه الأداة.

إحدى النقاط المتعلقة باللغات الرسومية من هذا النوع هي أنها لا تتكيف بشكل جيد مع التعقيد.تنطبق مشكلة مماثلة على أدوات ETL أيضًا.لقد رأيت تطبيق التزويد (انظر أدناه) تم إجراؤه (من المفارقات) باستخدام Crossworlds (المعروف الآن باسم Websphere Integrator).في غضون شهر من البدء في التطبيق، أصبح من الواضح أن لغة سير العمل الرسومية لن تتوسع مع تعقيد التطبيق وتم إعادة بنائها، استنادًا إلى محرك قواعد مخصصة مكتوب بلغة Java ومجموعة كبيرة إلى حد ما من القواعد المخصصة كود جافا.

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

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