1. مقدمة
اليوم، تبحث كل مؤسسة عن طرق لتحسين كفاءتها الإنتاجية، كما أنها تستكشف بنشاط إعادة تنظيم أصول تكنولوجيا المعلومات. حققت مؤسسات تكنولوجيا المعلومات بعض التقدم في التغلب على هذه المشكلات بمساعدة تقنيات البنية الموجهة نحو الخدمة (SOA)؛ ومع ذلك، في معظم الحالات يتم تنفيذ جزء صغير فقط من مجموعة خدمات تكنولوجيا المعلومات بأكملها. حاليًا، معظم الجهود المبذولة في هذا المجال لا تهدف إلا إلى تحقيق حالة "كافية" من اعتماد SOA، أي تحسين القدرة على بناء التطبيقات ودمجها في السوق بشكل أسرع وأفضل وأرخص. وكما تعلمنا، فإن تحقيق هذه الأهداف أسهل من الفعل.
2. التطبيقات المركبة التقليدية القائمة على البرمجيات الوسيطة
الحقيقة الحالية هي أن SOA هي نوع من البرامج الوسيطة - وفي الحالات التقليدية، غالبًا ما تعتمد البرامج الوسيطة على المزيد من البرامج الوسيطة لترجمة البيانات إلى حالة صديقة للمستهلك. عندما تكتشف أخيرًا أن إنشاء تطبيق مركب يشتمل على تقنية SOA لا يتطلب استخدام بوابة (برمجيات وسيطة) فحسب، بل قد يتطلب أيضًا استخدام محرك BPEL (أو حتى برامج وسيطة) لتنسيقه، فإن هذا بالطبع يجعلك بخيبة أمل كبيرة. والأسوأ من ذلك أنك قد تعمل ضمن مؤسسة تنشر سجلات UDDI وتسجل العديد من خدمات الويب. ولسوء الحظ، في معظم الحالات، هناك عدد قليل جدًا من التطبيقات التي تستهلك هذه الخدمات فعليًا. كيف يمكن أن يكون هذا هو الحال؟
هل يؤدي عدم القدرة على إنشاء تطبيقات تستهلك خدمات SOA إلى استنتاج أن هناك خطأ ما؟ هل يرجع ذلك إلى أنه من الصعب جدًا على مطوري محتوى الأعمال إنشاء تطبيقات تستهلك خدمات SOA بشكل مباشر؟ للاعتماد على مؤسسات تكنولوجيا المعلومات الأخرى لإنشاء مثل هذه التطبيقات لنا، هل يعيقنا الافتقار إلى هيكل إدارة SOA؟ وهناك سبب بارز جدًا: من الصعب جدًا على مطوري الأعمال فقط استهلاك واستخدام خدمات SOA التي تعرضها مؤسسة تكنولوجيا المعلومات. في الواقع، المشكلة الحقيقية هي عدم وجود طريقة سهلة لإضافة واجهة SOA - و هذه هي ميزة الجمع بين تقنية AJAX وSOA.
عادةً، يتم تنفيذ خدمة SOA كخدمة ويب مقترنة بشكل غير محكم والتي تتضمن وتكشف عن وظائف الأعمال. قد يبدو هذا واضحًا جدًا، لكنه معقد جدًا ويصعب تنفيذه. غالبًا ما يناقش المطورون تفاصيل تطوير خدمات SOA، ومع ذلك، يتفق معظم المطورين الآن على أن تفاصيل التطوير "على مستوى الأعمال" هي الأكثر ملاءمة؛ ومع ذلك، لا يزال هذا يتطلب انضمام عدد كبير من خبراء المجال ذوي الصلة والعمل مع محتوى الأعمال لوضع اللمسات النهائية على حجم هذه الخدمات.
3. نهضة SOA
لحسن الحظ، أصبح الناس مؤخرًا مهتمين بشدة بـ SOA. ربما أدركت الشركات أخيرًا أن SOA يمكن أن تساعدهم بشكل كبير. ربما يرجع ذلك إلى أدوات التطوير وخدمات الويب الأفضل التي تروج لها Amazon وYahoo وeBay. ربما يكون AJAX نعم، ولهذا السبب أكتب هذا المقال. على محمل الجد، أعتقد أن AJAX أصبح قوة دافعة مهمة في تجديد فهم الناس لـ SOA، وخاصة في مجالات التطبيقات الهجينة لمختلف التقنيات الجديدة اليوم. ومع ذلك، كيف ينبغي الجمع بين هاتين التقنيتين المختلفتين تمامًا وربطهما معًا لإطلاق العنان لقوة أكبر؟ دعونا أولاً نلقي نظرة على تعريف ويكيبيديا لتقنية AJAX الحالية. صفحات الويب متضمنة، ولكن لم يتم ذكر SOA على الإطلاق. الوصف هو:
"AJAX، الذي يرمز إلى 'Asynchronous JavaScript+XML'، هو عبارة عن تقنية تطوير ويب لإنشاء تطبيقات ويب تفاعلية. والغرض منها هو جعل صفحة الويب الأمامية أسهل من خلال تبادل كمية صغيرة من البيانات مع الخادم في الخلفية، يبدو الأمر أكثر استجابة؛ لذلك، في كل مرة يقوم فيها المستخدم بإجراء تغيير، لا يلزم إعادة تحميل صفحة الويب بأكملها. الهدف النهائي هو تحسين التفاعل والاستجابة وسهولة الاستخدام لصفحة الويب.
لم يتم ذكر SOA في هذا التعريف. ليس من المستغرب، لأن تطبيقات AJAX المبكرة ركزت على تحسين وظائف الصفحات وسهولة استخدامها. وقد تم إثبات ذلك في العديد من التطبيقات مثل خرائط Google، وFlickr، وYahoo Mail. ومع ذلك، ليست هذه التطبيقات الموجهة للمستهلك هي ما يجعلني متحمسًا بشأن إمكانات AJAX، بل إن تطبيقات الأعمال التي تعمل خلف جدار الحماية الخاص بالشركة هي التي تستفيد حقًا مما هو جيد في AJAX، لأنها تظهر لنا خاصيتين رئيسيتين: إحداهما عميل - نموذج البرمجة الجانبي والآخر هو تنفيذ سهل للمكالمات غير المتزامنة إلى الخادم. هاتان الإمكانيتان الرئيسيتان — القدرة على تطبيق المنطق على العميل (المتصفح) والقدرة على الوصول إلى بيانات الخادم دون مقاطعة صفحة الويب — تفتحان الباب لإنشاء تطبيقات مؤسسية جديدة وأكثر ثراءً لـ Web 2.0 .
لقد ذكرت سابقًا أن SOA تفتقر إلى الواجهة. هذا هو المكان الذي يأتي فيه AJAX - فهو يضيف مظهرًا لائقًا إلى SOA. وهنا، اسمحوا لي أن أشرح أكثر من ذلك بقليل. ربما نفكر أيضًا فيما سيحدث إذا ظهرت خدمات SOA عبر الإنترنت، وعادةً ما تحتاج مثل هذه الخدمات إلى التسجيل في السجل أو المستودع (إذا كنا محظوظين) ومن ثم يمكن استخدامها للاستهلاك. على سبيل المثال، دعونا نلقي نظرة على ما هو متاح على موقع ويب StrikeIron ( www.StrikeIron.com ). نجحت StrikeIron في إنشاء "سوق خدمات الويب" لعامة الناس. للوهلة الأولى، تبدو آلية الدليل في StrikeIron تشبه إلى حد كبير القائمة المتوفرة في تطبيق الأعمال الصغيرة. ولكن لاحقًا، ستدرك أن هذه ليست مجرد تطبيقات، بل هي في الواقع خدمات ويب. إن مفهوم شركة واحدة تقدم خدمات ويب WSDL/REST لمجموعة واسعة من المستهلكين له آثار عديدة. لكن الآن دعونا نلقي نظرة على ما تبيعه هذه الشركة. وفقًا للمعلومات المقدمة من StrikeIron (التي توفر الوصول إلى هذه الخدمات)، تشمل خدمات الويب الأكثر شيوعًا التي تقدمها ما يلي:
· التحقق من عنوان الولايات المتحدة
· خدمة الرسائل القصيرة العالمية
· ضريبة المبيعات والاستخدام
· التحقق من البريد الإلكتروني
· البحث العكسي عن الهاتف
لا شيء بلا شك، جميعها تعد خدمات الويب هذه مفيدة جدًا ويمكن استخدامها في العديد من المجالات المختلفة. لكنها في الوقت نفسه "سلعة" أيضًا. بمعنى آخر، قد لا أهتم بمن يقدم هذه الخدمات، ولكني أريد فقط الحصول على المعلومات التي أريدها. ومن ناحية أخرى، هل يمكنني ببساطة استخدام أي خدمة ويب لتحويل الأموال النقدية من حسابي الجاري إلى حساب التوفير الخاص بي؟ أحتاج أولاً إلى بناء الثقة في هذه الخدمة، لذا يجب علي إنشاء علاقة معينة مع البائع الذي يقدمها. تمثل "دائرة الثقة" الموجودة بيني (المستهلك) ومقدم الخدمة أيضًا العلاقة داخل المؤسسة وشركائها.
4. الجمع بين تقنية AJAX + SOA
يمكن أيضًا اعتماد نفس الطريقة المذكورة أعلاه من قبل المؤسسات لتقديم خدمات الويب الخاصة بها إلى قاعدة مستخدمين أوسع. من خلال سوق خدمات الويب، يمكن للمؤسسات تسجيل العديد من خدمات الويب — وعادةً ما تكون خدمات الويب هذه متاحة فقط داخل المؤسسة أو للشركاء. من الواضح أن بائعي السوق يريدون أن يحدث هذا، ولكن الأهم من ذلك، أننا نرى فرصة لتطبيق تقنية AJAX+SOA لقيادة فئة جديدة من تطبيقات الأعمال Web 2.0.
لأول مرة، بدأ الناس يشعرون بأن تطوير التطبيقات وSOA يجتمعان معًا أخيرًا. لدينا وظائف الأعمال الموضحة في نموذج قابل لإعادة الاستخدام - خدمة SOA. لدينا اتصال في كل مكان - الويب. لدينا متصفحات تثبت أنها حاويات التطبيقات الجديدة. لدينا نموذج برمجة في هذا النوع من حاوية/متصفح التطبيق - JavaScript. وجميعهم يستخدمون معايير مفتوحة! ماذا نطلب أيضًا؟ في الواقع، هناك أشياء أخرى.
أود بشكل خاص أن أرى طريقة أسرع لتطوير التطبيقات بناءً على جميع التقنيات المذكورة أعلاه - طريقة لبناء التطبيقات دون الحاجة إلى الاعتماد على البرامج الوسيطة المدمجة مع خدمات SOA. هذا هو بالضبط ما أريد أن يكون تطبيق الويب قادرًا عليه - "الاتصال المباشر بـ SOA". يجب أن يكون هذا "الاتصال المباشر بـ SOA" قادرًا على تجاوز حواجز البوابة التقليدية ومحركات العمليات ذات الوزن الثقيل للوصول مباشرة (على الأقل من الناحية النظرية؛ سنتعلم المزيد عن هذا لاحقًا) إلى خدمات SOA. بهذا، لا أعني خدمات الويب فقط، بل يمكن أيضًا أن تكون خدمات تنسيق BPEL، أو خدمات POJO الخشنة، أو خلاصات RSS أو أي شيء آخر يمكن كشفه على أنه "خدمة". وبطبيعة الحال، يجب أن يتم الكشف عن الواجهات باستخدام معايير مفتوحة.
ينشئ نموذج التطوير ووقت التشغيل الجديد هذا طريقة جديدة لإنشاء تطبيقات مركبة تعتمد على التطبيقات. إنه يتمتع بجاذبية نوع العميل/الخادم دون العبء الثقيل للعملاء/الخوادم التقليدية ذات الوزن الثقيل. يتم تشغيله من جانب المتصفح ويمكن تنفيذه وفقًا لمتطلبات محددة.
5. التطبيقات المركبة المعتمدة على المستخدم
خلال السنوات القليلة الماضية، سمعنا جميعًا عن مفهوم "التطبيقات المركبة". ومع ذلك، كان معظم البائعين يتحدثون عن "الخدمات المركبة" - كوسيلة لإعادة هيكلة خدماتهم المضيفة وتحويلها إلى خدمات أخرى أكثر فائدة أو تطبيقات بوابة. واسمحوا لي أن أقوم بإجراء تشبيه لتوضيح المزيد.
يوفر AcmeGrid، مورد الحوسبة الشبكية الخيالي لدينا في هذه المقالة، خدمة — حوسبة الشبكة — تمكن تطبيقاتك من التشغيل كخدمة. أخبرها عملاء الشركة أنهم يريدون طريقة لدمج العديد من الخدمات في خدمة بسيطة. لذلك، بطبيعة الحال، أصدرت AcmeGrid أداة إنشاء التطبيقات المركبة AcmeGrid المستندة إلى Eclipse (CAB). ومن المثير للاهتمام أن CAB يشبه إلى حد كبير مصمم BPEL، ولكنه أكثر تكاملاً مع الخدمات التي تنشرها AcmeGrid. على الرغم من أنه جميل جدًا، إلا أنه ليس تطبيقًا حقيقيًا، فهو في أحسن الأحوال مجرد خدمة. في جوهر الأمر، CAB هو أشبه بمنشئ الخدمة. ولكن من الذي يحتاج إلى منشئ خدمات عندما نحاول إنشاء تطبيقات؟ قريبًا، أعلن بائع وهمي آخر، دعنا نسميه AcmePortal، عن منشئ تطبيق Portal Composite Application Builder (PCAB). يأتي أيضًا مع مصمم يعتمد على Eclipse؛ على الرغم من أنه يبدو أيضًا وكأنه مصمم BPEL، إلا أن هذا البرنامج "يعرف" كيفية إنشاء البوابات. في كثير من الحالات، تعمل البوابة الإلكترونية تمامًا مثل التطبيق. ومع ذلك، إذا أصررت على تحويل البوابة إلى تطبيق، فسيكون ذلك بلا جدوى.
في الواقع، أريد حقًا تنفيذ تطبيق مركب قائم على المستخدم بدلاً من تطبيق مركب قائم على البرامج الوسيطة. وللقيام بذلك، كنت بحاجة إلى نظام أساسي للتطوير ووقت التشغيل لا يمكنه استخدام AJAX وSOA فحسب، بل يمكنه أيضًا إدارة كليهما. لقد اتخذ بعض البائعين مفهوم تطبيقات AJAX خطوة أخرى إلى الأمام - حيث يقومون باستدعاء خدمات الويب المستندة إلى WSDL مباشرة من المتصفح، وهو في الأساس استدعاء SOAP. هذا الأسلوب له أيضًا اسم - "Client/SOA". قد يكون هذا مناسبًا للتطبيقات البسيطة غير الخاصة بالمؤسسات أو التطبيقات الاستهلاكية، ولكن ليس لبرامج المؤسسات الحقيقية. لماذا؟ لأنه عند الاتصال بخدمة ويب مباشرة من المتصفح، فإن وظيفة الإشراف تعادل تسليمها إلى المتصفح - مما يعني ببساطة أنه لا توجد مشكلة في الإشراف على الإطلاق. يوضح الشكل 1 الرسم التخطيطي لاستهلاك خدمة الويب غير الخاضعة للرقابة. لم أقابل مطلقًا شركة لا تراقب خدماتها، ولا أعتقد أن الشركات ستسمح بحدوث ذلك لمجرد أننا فعالون للغاية من الناحية الفنية في ذلك. إذا كنت لا تصدقني، فتذكر فقط أن المؤسسات لا تفتح أبدًا جدران الحماية الخاصة بها لتطبيقات أخرى غير HTTP وSSL. ومهما أقنعنا مسؤولي النظام، فلن يفتحوا منافذ أخرى.
6. نحن بحاجة إلى نوع جديد من المنصات،
كما يتبين مما سبق، فإن ما نناقشه لا يتعلق فقط بتقنيات AJAX وSOA. في الواقع، ما نحتاجه حقًا هو منصة يمكنها توفير إمكانات الإشراف اللازمة لتعايش AJAX وSOA في المؤسسة. توفر هذه المنصة أيضًا القدرة على استهلاك خدمات SOA من وجهة نظر العميل، ويمكنها أيضًا مراقبة استهلاك الخدمة. يوضح الشكل 2 كيف يمكن إدارة خدمات الويب من خلال بوابة الخدمة. بوابة الخدمة هي في الواقع تجريد من جانب الخادم يراقب وينظم الوصول إلى الخدمة نيابة عن العميل، والذي في الحالة التي ناقشناها للتو هو تطبيق AJAX قائم على المتصفح. يكمن جمال استخدام بوابة الخدمة في أنك غير مقيد بالوصول إلى الخدمات التي تعمل داخل المؤسسة فقط. يمكن لبوابة الخدمة هذه الإشراف على أي خدمة مسجلة داخل المؤسسة. في خدمة ويب المستندة إلى WSDL، ستقوم المؤسسة بتسجيل WSDL، وتوفر WSDL ربط الخدمة في وقت التشغيل. قد تكون هذه خدمة تعمل في مركز بيانات إحدى المؤسسات، ولكنها يمكن أن تكون بنفس السهولة خدمة تعمل في مركز بيانات الشراكة. إذا سمحت إحدى المؤسسات (من خلال التنظيم) للتطبيقات بالوصول إلى الخدمات، فلا يهم مكان تشغيل هذه الخدمات.
7. الخلاصة
بعد قراءة هذا المقال، أتمنى أن تكون قد بدأت في تقدير قوة الجمع بين AJAX وSOA معًا - خاصة كيف يمكن لهما التعايش وتمكين أنواع جديدة من التطبيقات المستندة إلى الويب مع الإمكانات التنظيمية التي يتطلبها تطبيق خدمة المؤسسة . وأعتقد اعتقادا راسخا أننا على أعتاب حقبة جديدة من الفرص المذهلة. في عصر الويب 2.0، تعد الشبكات الاجتماعية ومشاركة الصور وتقنيات التعليقات التوضيحية المختلفة كلها رائعة، ولكن المؤثر حقًا هو استجابة الويب 2.0 للمؤسسات.