لماذا لا تستخدم مآخذ الويب الصابون؟

Question

أولاً ، لا أعتزم أي عداء ولا سلبي ، أريد فقط معرفة أفكار الناس. أنا أبحث في اتصال ثنائي الاتجاه بين العميل والخادم ؛ العميل كونه تطبيق ويب. في هذه المرحلة ، لدي بعض الخيارات: MS-Propristary Duplex Binding ، مما أسمعه غير موثوق به وغير طبيعي: المذنب ، ومآخذ الويب (للمتصفحات المدعومة).

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

لماذا لا تجعل الأمر بسيطًا والاستفادة من الطبيعة الديناميكية JS وترك الجزء الأكبر من الكود حيث ينتمي .... على الخادم؟

بدلاً من

mysocket.send("AFunction|withparameters|segmented");

يمكننا القول

myServerObject.AFunction("that", "makessense");

وبدلا من

...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...

يمكننا القول

...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data....");  alert("Hello " + realData.FullName); }
...

استغرق HTML 5 إلى الأبد للاستمتاع .... هل نفقد قدرا كبيرا من الجهد في الاتجاه الخاطئ؟ أفكار؟

Answer 1

يبدو لي أنك لم تدرك المفاهيم حول WebSockets بالكامل. على سبيل المثال تقول:

النظر في مآخذ الويب من جانب العميل

ليس هذا هو الحال ، فهو مآخذ على جانبين ، يمكنك التفكير في هذه الخادم وعميل ، ولكن بمجرد إنشاء الاتصال ، يمكن أن تفكر أيضًا في العميل والخادم على أنه "أقران" - كل منهما يمكن الكتابة أو القراءة بالأنبوب الذي يربطهم (اتصال المقبس) في أي وقت. أظن أنك ستستفيد من تعلم المزيد عن أعمال HTTP على رأس TCP - WebSockets مشابه / مشابه لـ HTTP بهذه الطريقة.

فيما يتعلق بـ SOAP / WSDL ، من وجهة نظر محادثة تحيط بـ TCP / WebSocket / HTTP ، يمكنك التفكير في جميع محادثات SOAP / WSDL على أنها متطابقة مع HTTP (أي حركة مرور صفحة الويب العادية).

أخيرًا ، تذكر الطبيعة المكدسة لبرمجة الشبكة ، على سبيل المثال ، يبدو SOAP/WSDL مثل:

SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP

ويبدو websockets مثل هذا

WebSocket
--------- (sits atop)
TCP

HTH.

Answer 2

يتيح JavaScript للعملاء التواصل عبر HTTP مع XMLHTTPrequest. يمتد WebSockets هذه الوظيفة للسماح لـ JavaScript بإنشاء شبكة I/O الشبكة التعسفية (وليس فقط HTTP) ، وهو امتداد منطقي ويسمح لجميع أنواع التطبيقات التي تحتاج إلى استخدام حركة مرور TCP (ولكن قد لا تستخدم بروتوكول HTTP) إلى JavaScript. أعتقد أنه من المنطقي إلى حد ما ، مع استمرار التطبيقات في الانتقال إلى السحابة ، أن HTML و JavaScript تدعم كل ما هو متاح على سطح المكتب.

على الرغم من أن الخادم يمكنه القيام بشبكة غير HTTP I/O نيابة عن عميل JavaScript وجعل هذا الاتصال متاحًا عبر HTTP ، فإن هذا ليس دائمًا الشيء الأكثر ملاءمة أو فعالية. على سبيل المثال ، لن يكون من المنطقي إضافة تكلفة إضافية ذهابًا وإيابًا عند محاولة إنشاء محطة SSH عبر الإنترنت. يتيح WebSockets من JavaScript التحدث مباشرة إلى SSH Server.

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

Answer 3

كما لاحظت Websockets اقل عبأ. يشبه النفقات العامة مآخذ TCP العادية: فقط بايتان أكثر لكل إطار مقارنة بالمئات لـ AJAX/COMET.

لماذا المستوى المنخفض بدلاً من نوع من وظائف RPC المدمجة؟ بعض الأفكار:

• ليس من الصعب أخذ بروتوكول RPC موجود و طبقة على بروتوكول المقبس منخفض المستوى. لا يمكنك الذهاب إلى الاتجاه المعاكس وبناء اتصال منخفض المستوى إذا تم افتراض أن النفقات العامة RPC.

• دعم WebSockets هو تافهة إلى حد ما للإضافة إلى لغات متعددة على جانب الخادم. الحمولة هي مجرد سلسلة UTF-8 وكل لغة لديها دعم فعال في ذلك. آلية RPC ليست كثيرا. كيف تتعامل مع تحويلات نوع البيانات بين JavaScript واللغة المستهدفة؟ هل تحتاج إلى إضافة نوع التلميح على جانب جافا سكريبت؟ ماذا عن وسيطات الطول المتغيرة و/أو قوائم الوسيطة؟ هل تبني هذه الآليات إذا لم يكن لدى اللغة إجابة جيدة؟ إلخ.

• ما هي آلية RPC التي سيتم تصميمها بعد؟ هل ستختار واحدة موجودة (SOAP ، XML-RPC ، JSON-RPC ، Java RMI ، AMF ، RPYC ، CORBA) أو واحدة جديدة تمامًا؟

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

لاجلي Novnc Project (عميل VNC باستخدام JavaScript فقط ، قماش ، WebSockets) الطبيعة ذات الرأس المنخفض لـ WebSockets أمر بالغ الأهمية لتحقيق أداء معقول. حتى تتضمن خوادم VNC دعم WebSockets ، تتضمن Novnc wsproxy وهي عبارة عن مواقع الويب العامة لوكالة توصيل TCP.

إذا كنت تفكر في تطبيق تطبيق ويب تفاعلي ولم تقرر لغة من جانب الخادم ، فأنا أقترح النظر في Socket.io وهي مكتبة ل العقدة (JavaScript من جانب الخادم باستخدام محرك V8 من Google).

بالإضافة إلى جميع مزايا العقدة (نفس اللغة على كلا الجانبين ، ومكتبات الطاقة الفعالة للغاية ، وما إلى ذلك) ، يمنحك Socket.io عدة أشياء:

• يوفر كل من مكتبة إطار عمل العميل والخادم للتعامل مع الاتصالات.

• يكتشف أفضل نقل يدعمه كل من العميل والخادم. تشمل وسائل النقل (من الأفضل إلى الأسوأ): Websockets الأصلية ، WebSockets باستخدام مضاهاة الفلاش ، نماذج Ajax المختلفة.

• واجهة متسقة بغض النظر عن النقل المستخدم.

• الترميز التلقائي/فك تشفير أنواع بيانات JavaScript.

لن يكون من الصعب إنشاء آلية RPC على رأس Socket.io نظرًا لأن كلا الجانبين هما نفس اللغة مع نفس الأنواع الأصلية.

Answer 4

يجعل WebSocket Comet وجميع تقنيات نوع Push HTTP أخرى مقروءة عن طريق السماح للطلبات بالانشارة من الخادم. إنه نوع من المقبس الرملي ويعطينا وظائف محدودة.

ومع ذلك ، فإن واجهة برمجة التطبيقات عامة بما يكفي لمؤلفي الإطار والمكتبة لتحسين الواجهة بأي طريقة يرغبون فيها. على سبيل المثال ، يمكنك كتابة بعض خدمة RPC أو RMI على رأس Websockets التي تسمح بإرسال كائنات عبر السلك. الآن داخليًا يتم تسلسلها بتنسيق غير معروف ، لكن مستخدم الخدمة لا يحتاج إلى معرفة ولا يهتم.

لذلك التفكير من مؤلفي المواصفات بوف ، الذهاب من

mysocket.send("AFunction|withparameters|segmented");

إلى

myServerObject.AFunction("that", "makessense");

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

Answer 5

واجهت نفس المشكلة حيث كنت بحاجة لفعل شيء مثل call('AFunction', 'foo', 'bar') بدلا من التسلسل/إزالة التخصيص كل تفاعل. كان تفضيلي أيضًا ترك الجزء الأكبر من التعليمات البرمجية على الخادم واستخدام JavaScript فقط للتعامل مع العرض. كانت WebSockets مناسبة بشكل أفضل بسبب دعمها الطبيعي للتواصل ثنائي الاتجاه. لتبسيط تطوير التطبيق الخاص بي ، أقوم ببناء طبقة فوق WebSockets لإجراء مكالمات عن بعد (مثل RPC).

لقد نشرت RMI/RPC مكتبة في http://sourceforge.net/projects/rmiwebsocket/. بمجرد الإعداد للاتصال بين صفحة الويب و Servlet ، يمكنك تنفيذ المكالمات في أي من الاتجاهين. يستخدم الخادم الانعكاس لاستدعاء الطريقة المناسبة في الكائن من جانب الخادم ويستخدم العميل طريقة "استدعاء" JavaScript لاستدعاء الوظيفة المناسبة في كائن من جانب العميل. تستخدم المكتبة جاكسون لرعاية التسلسل/إلغاء التسلسل لأنواع Java المختلفة إلى/من JSON.

Answer 6

تم التفاوض على WebSocket JSR من قبل عدد من الأطراف (Oracle ، Apache ، Eclipse ، إلخ) مع أجندات مختلفة للغاية. إنها كذلك توقفوا عند مستوى نقل الرسائل وتركوا بناء المستوى الأعلى. إذا كان ما تحتاجه هو Java لـ JavaScript RMI ، تحقق من Fermi Framework.