GWT / Comet: أي تجربة؟

Question

هل هناك أي طريقة "للاشتراك" من GWT إلى JSON Objects Stream والاستماع إلى الأحداث الواردة في اتصال الحفاظ ، دون محاولة جلبها جميعًا مرة واحدة؟ أعتقد أن الكلمة الطنانة-دوور لهذه التكنولوجيا هي "مذنب".

لنفترض أن لدي خدمة HTTP التي تفتح اتصال Keep-Alive ووضع كائنات JSON مع أسعار الأسهم الواردة هناك في الوقت الفعلي:

{"symbol": "AAPL", "bid": "88.84", "ask":"88.86"}
{"symbol": "AAPL", "bid": "88.85", "ask":"88.87"}
{"symbol": "IBM", "bid": "87.48", "ask":"87.49"}
{"symbol": "GOOG", "bid": "305.64", "ask":"305.67"}
...

أحتاج إلى الاستماع إلى هذه الأحداث وتحديث مكونات GWT (الجداول ، الملصقات) في الوقت الفعلي. أي أفكار كيف تفعل ذلك؟

Answer 1

هناك وحدة GWT Comet لـ Streamhub:

http://code.google.com/p/gwt-comet-streamhub/

Streamhub هو خادم المذنب مع إصدار مجتمع مجاني. هناك مثال على ذلك في العمل هنا.

ستحتاج إلى تنزيل STREAMHUB COMET Server وإنشاء قائمة اشتراك جديدة ، واستخدم مثال StockDemo كنقطة انطلاق ، ثم قم بإنشاء تحميل JSONPayload لدفق البيانات:

Payload payload = new JsonPayload("AAPL");
payload.addField("bid", "88.84");
payload.addField("ask", "88.86");
server.publish("AAPL", payload);
...

قم بتنزيل الجرة من موقع رمز Google ، وأضفها إلى ClassPath Projects GWT الخاص بك وأضف التضمين إلى وحدة GWT الخاصة بك:

<inherits name="com.google.gwt.json.JSON" />
<inherits name="com.streamhub.StreamHubGWTAdapter" />

قم بتوصيل واشتراك من رمز GWT الخاص بك:

StreamHubGWTAdapter streamhub = new StreamHubGWTAdapter();
streamhub.connect("http://localhost:7979/");
StreamHubGWTUpdateListener listener = new StockListener();
streamhub.subscribe("AAPL", listener);
streamhub.subscribe("IBM", listener);
streamhub.subscribe("GOOG", listener);
...

ثم قم بمعالجة التحديثات التي تعجبك في مستمع التحديث (أيضًا في رمز GWT):

public class StockListener implements StreamHubGWTUpdateListener {
      public void onUpdate(String topic, JSONObject update) {
          String bid = ((JSONString)update.get("bid")).stringValue();
          String ask = ((JSONString)update.get("ask")).stringValue();
          String symbol = topic;
          ...
      }
}

لا تنسَ تضمين Streamhub-Min.js في صفحة HTML الرئيسية لمشاريع GWT الخاصة بك.

Answer 2

لقد استخدمت هذه التقنية في مشروعين ، على الرغم من أنها تعاني من مشاكلها. يجب أن أشير إلى أنني قد فعلت ذلك فقط على وجه التحديد من خلال GWT-RPC ، ولكن المبدأ هو نفسه بالنسبة لأي آلية تستخدمها للتعامل مع البيانات. اعتمادًا على ما تفعله بالضبط ، قد لا تكون هناك حاجة كبيرة إلى تعقيد الأشياء.

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

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

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

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

Answer 3

هناك بالفعل مكتبة تشبه Cometd لـ GWT - http://code.google.com/p/gwteventservice/

لكنني لم أستخدمها شخصيًا ، لذلك لا أستطيع حقًا أن أؤكد ما إذا كان جيدًا أم لا ، ولكن يبدو DOCO جيدًا. تستحق المحاولة.

هناك عدد قليل من الآخرين رأيته ، مثل GWT-Rocket's Cometd مكتبة.

Answer 4

يمكن العثور على بعض الأفكار الأولية لتنفيذ المذنب لـ GWT هنا... على الرغم من أنني أتساءل ما إذا كان هناك شيء أكثر نضجًا.

Answer 5

أيضا ، تتوفر بعض البصيرة على تكامل GWT/Comet هناك, ، باستخدام المزيد من تقنية الحافة المتقطعة والتشويش: "الاستمرارية رصيف". يستحق إلقاء نظرة.

Answer 6

هنا يمكنك العثور على وصف (مع بعض عينات المصدر) حول كيفية القيام بذلك لخادم تطبيق IBM WebSphere. لا ينبغي أن يكون مختلفًا جدًا مع Jetty أو أي خادم J2EE الذي يدعم المذنب. باختصار ، الفكرة هي: تشفير كائن Java الخاص بك إلى سلسلة JSON عبر GWT RPC ، ثم باستخدام Cometd أرسله إلى العميل ، حيث يتم استلامه بواسطة DoJo ، الذي يؤدي مرة أخرى باستخدام GWT RPC. هاهو! قون

تجربتي مع هذا الإعداد إيجابية ، لم تكن هناك مشاكل في ذلك باستثناء الأسئلة الأمنية. ليس من الواضح حقًا كيفية تنفيذ الأمان للمذنب في هذه الحالة ... يبدو أن Servlets تحديث المذنب يجب أن يكون لها عناوين URL مختلفة ومن ثم يمكن تطبيق أمان J2EE.

Answer 7

يحتوي مشروع JBOSS ERAI على ناقل رسائل يوفر رسائل ثنائية الاتجاه توفر بديلاً جيدًا لـ COMETD.

Answer 8

نحن نستخدم أطر الغلاف الجوي (http://async-io.org/) لـ ServerPush/Comet في gwt application.

على إطار عمل عميل لديه تكامل GWT وهو واضح ومباشر. على جانب الخادم ، يستخدم Servlet عادي.

نحن نستخدمه حاليًا في الإنتاج مع 1000+ مستخدم متزامن في البيئة المجمعة. واجهنا بعض المشكلات على الطريقة التي يجب حلها عن طريق تعديل مصدر الغلاف الجوي. أيضا الوثائق رقيقة حقا.

الإطار مجاني للاستخدام.