العمارة نظام التداول السندات

بنية نظام تداول السندات
(جوناثان سيمون)
فمن السهل أن المسافة نفسك من مجموعة كبيرة من أنماط أو لغة نمط. أنماط هي التجريد من فكرة في شكل قابلة لإعادة الاستخدام. في كثير من الأحيان، طبيعة عامة جدا من الأنماط التي تجعلها مفيدة جدا يجعل من الصعب فهم. في بعض الأحيان أفضل شيء للمساعدة في فهم أنماط هو مثال العالم الحقيقي. ليس سيناريو مفتعل لما يمكن أن يحدث. ولكن ما يحدث فعلا وما سيحدث.
هذا الفصل ينطبق على أنماط لحل المشاكل باستخدام عملية الاكتشاف. النظام الذي سنناقشه هو نظام تداول السندات الذي عملت معه لمدة عامين من التصميم الأولي من خلال الإنتاج. وسوف نستكشف السيناريوهات والمشاكل التي واجهتها وكيفية حلها مع أنماط. وهذا ينطوي على عملية اتخاذ القرار لاختيار نمط، وكذلك كيفية الجمع وضبط أنماط لتتناسب مع احتياجات النظام. ويتم هذا كله مع الأخذ بعين الاعتبار القوى التي واجهتها في النظم الحقيقية بما في ذلك متطلبات الأعمال، وقرارات العميل، والمتطلبات المعمارية والتقنية، فضلا عن تكامل النظام القديم. والقصد من هذا النهج هو توفير فهم أوضح للنماذج نفسها من خلال التطبيق العملي.
بناء نظام.
يقوم بنك استثماري كبير في وول ستريت بإنشاء نظام تسعير السندات في محاولة لتبسيط سير عمل مكتب تداول السندات. حاليا، التجار السندات لديها لإرسال أسعار لعدد كبير من السندات إلى عدة أماكن تجارية مختلفة، ولكل منها واجهة المستخدم الخاصة بها. والهدف من هذا النظام هو تقليل الحد الأدنى من تسعير كل من سنداتهم جنبا إلى جنب مع وظائف تحليلية متقدمة محددة لسوق السندات في واجهة مستخدم مغلفة واحدة. وهذا يعني التكامل والتواصل مع عدة مكونات على مختلف بروتوكولات الاتصال. يبدو تدفق المستوى العالي للنظام كما يلي:
تدفق عالي المستوى.
أولا، تأتي بيانات السوق في النظام. بيانات السوق هي البيانات المتعلقة بالسعر وغيرها من خصائص السندات التي تمثل ما هو الناس على استعداد لشراء وبيع السندات في السوق الحرة. يتم إرسال بيانات السوق على الفور إلى محرك تحليلات أن يغير البيانات. يشير أناليتيكش إلى الوظائف الرياضية للتطبيقات المالية التي تغير الأسعار وغيرها من سمات السندات. هذه هي الوظائف العامة التي تستخدم المتغيرات الإدخال لتكييف نتائج الدالة إلى رابطة معينة. سيقوم تطبيق العميل الذي سيتم تشغيله على كل سطح مكتب تاجر بتكوين محرك تحليلات على أساس التاجر، والتحكم في تفاصيل التحليلات لكل السندات التاجر هو التسعير. وبمجرد تطبيق التحليلات على بيانات السوق، يتم إرسال البيانات المعدلة إلى أماكن تجارية مختلفة حيث يمكن للمتداولين من الشركات الأخرى شراء أو بيع السندات.
البنية بتصميم، ب، النماذج.
مع هذه النظرة العامة لسير العمل في النظام، يمكننا أن نقترب من بعض المشاكل المعمارية التي نواجهها أثناء عملية التصميم. دعونا نلقي نظرة على ما نعرفه حتى الآن. يحتاج التجار إلى تطبيق سريع الاستجابة على كل من محطات عمل ويندوز نت و سولاريس. لذلك، قررنا تنفيذ تطبيق العميل كعميل جافا سميكة بسبب استقلالية منصة وقدرته على الاستجابة بسرعة لإدخال المستخدم وبيانات السوق. على جانب الخادم، نحن نرث مكونات C ++ القديمة التي سيستعملها نظامنا. تتواصل مكونات بيانات السوق مع البنية التحتية لرسائل تيبكو إنفورماتيون باص (تيب).
نحن نرث المكونات التالية:
بيانات السوق خادم تغذية الأسعار: ينشر بيانات السوق الواردة إلى تيب. أناليتيكش إنجين: يقوم بتحليل بيانات السوق الواردة ويبث بيانات السوق المعدلة إلى تيب. خادم المساهمة: يؤدي جميع الاتصالات مع أماكن التداول. أما أماكن التداول فهي مكونات طرف ثالث غير خاضعة لسيطرة البنك.
النظام الفرعي لبيانات السوق القديمة.
النظام الفرعي المساهمة القديمة.
نحن بحاجة إلى أن نقرر كيف أن النظم الفرعية المنفصلة (العميل جافا سميكة، وبيانات السوق، والمساهمة) ستتواصل. يمكننا أن يكون العميل سميكة التواصل مباشرة مع خوادم القديمة، ولكن هذا يتطلب الكثير من منطق الأعمال على العميل. بدلا من ذلك، سوف نقوم بإنشاء زوج من بوابات جافا للاتصال بالخوادم القديمة Ђ "بوابة التسعير لبيانات السوق بوابة مساهمة لإرسال الأسعار إلى أماكن التداول. وهذا سوف يحقق تغليف لطيفة للمنطق الأعمال المتعلقة بهذه المناطق. وفيما يلي المكونات الحالية في النظام. التوصيلات التي تحمل علامة Ђњ. تشير إلى أننا ما زلنا غير متأكدين من كيفية توصيل بعض المكونات.
النظام ومكوناته.
سؤال الاتصال الأول هو كيفية دمج عميل جافا سميكة واثنين من مكونات خادم جافا من أجل تبادل البيانات. دعونا ننظر إلى أنماط التكامل الأربعة المقترحة في هذا الكتاب: نقل الملفات، قاعدة البيانات المشتركة، استدعاء الإجراء البعيد، والرسائل. يمكننا استبعاد قاعدة البيانات المشتركة على الفور لأننا أردنا إنشاء طبقة من التجريد بين العميل وقاعدة البيانات و دون 't تريد أن يكون رمز الوصول إلى قاعدة البيانات في العميل. كما يمكن استبعاد نقل الملفات نظرا لأن الحد الأدنى من الكمون مطلوب لضمان إرسال الأسعار الحالية إلى أماكن التداول. هذا يترك لنا مع الاختيار بين الاستدعاء الإجراء البعيد أو الرسائل.
توفر منصة جافا المدمج في دعم كل من الاستدعاء الإجراء البعيد والرسائل. يمكن تحقيق التكامل على غرار ريك باستخدام ريموت ميثود إنفوكاتيون (رمي)، كوربا، أو إنتيربريس جافا بينز (إجب). خدمة المراسلة جافا (جمس) هي واجهة برمجة التطبيقات المشتركة لتكامل أسلوب المراسلة. لذلك كلا من أساليب التكامل سهلة التنفيذ في جافا.
ما الذي سيعمل بشكل أفضل لهذا المشروع، استدعاء الإجراء البعيد أو الرسائل؟ هناك مثيل واحد فقط من بوابة التسعير ومثيل واحد من بوابة المساهمة في النظام، ولكن عادة العديد من العملاء سميكة الاتصال في وقت واحد إلى هذه الخدمات (واحد لكل تاجر السندات التي يحدث أن يتم تسجيل الدخول في وقت معين). وعلاوة على ذلك، فإن البنك يود أن يكون هذا نظام التسعير العامة التي يمكن استخدامها في التطبيقات الأخرى. لذلك إلى جانب عدد غير معروف من عملاء التفكير، قد يكون هناك عدد غير معروف من التطبيقات الأخرى باستخدام بيانات التسعير الخروج من البوابات.
يمكن لعميل سميك (أو تطبيق آخر باستخدام بيانات التسعير) استخدام ريك بسهولة إلى حد ما لإجراء مكالمات إلى البوابات للحصول على بيانات التسعير والاستدعاء للتجهيز. ومع ذلك، سيتم نشر بيانات التسعير باستمرار، وبعض العملاء مهتمون فقط ببعض البيانات، لذلك قد يكون من الصعب الحصول على البيانات ذات الصلة للعملاء المناسبين في الوقت المناسب. يمكن للعملاء استطلاع البوابات، ولكن ذلك سيخلق الكثير من النفقات العامة. وسيكون من الأفضل للبوابات أن تتيح البيانات للزبائن فور توافرها. هذا، ومع ذلك، سوف تتطلب كل بوابة لتتبع العملاء التي هي نشطة حاليا، والتي تريد ما هي بيانات معينة؛ ثم، عندما تصبح قطعة جديدة من البيانات المتاحة (الذي سيحدث عدة مرات في الثانية الواحدة)، فإن بوابة يجب أن تجعل ريك لكل عميل مهتم لتمرير البيانات إلى العميل. من الناحية المثالية، يجب إخطار جميع العملاء في وقت واحد، لذلك يجب أن يتم كل ريك في سلسلة الترابط المتزامنة الخاصة به. هذا يمكن أن تعمل، ولكن هو الحصول على معقدة جدا سريع جدا.
الرسائل يبسط إلى حد كبير هذه المشكلة. باستخدام المراسلة، يمكننا تحديد قنوات منفصلة لأنواع مختلفة من بيانات التسعير. ثم، عندما يحصل على بوابة جديدة قطعة من البيانات، فإنه سيتم إضافة رسالة تحتوي على تلك البيانات إلى قناة نشر الاشتراك لهذا النوع من البيانات. وفي الوقت نفسه، فإن جميع العملاء المهتمين في نوع معين من البيانات الاستماع على القناة لهذا النوع. وبهذه الطريقة، يمكن للبوابات بسهولة إرسال بيانات جديدة لمن يهتم، دون الحاجة إلى معرفة عدد تطبيقات المستمع هناك أو ما هي عليه.
العملاء لا تزال بحاجة إلى أن تكون قادرة على استدعاء السلوك في بوابات كذلك. نظرا لوجود بوابات اثنين فقط، ويمكن للعميل منع على الأرجح أثناء استدعاء الأسلوب بشكل متزامن، يمكن بسهولة هذه الإدخالات من العميل إلى البوابة التي يمكن تنفيذها باستخدام ريك. ومع ذلك، لأننا نستخدم بالفعل الرسائل للاتصالات من عبارة إلى عميل، الرسائل هي على الأرجح مجرد جيدة وسيلة لتنفيذ الاتصالات من العميل إلى بوابة كذلك.
ولذلك، سيتم تحقيق جميع الاتصالات بين البوابات والعملاء من خلال الرسائل. لأن جميع المكونات مكتوبة بلغة جافا، يقدم جمس خيارا سهلا لنظام الرسائل. هذا هو خلق فعال حافلة الرسائل أو بنية من شأنها أن تجعل من الممكن لأنظمة المستقبل لدمج مع النظام الحالي مع تغييرات قليلة أو معدومة على البنية التحتية الرسائل. بهذه الطريقة، وظائف الأعمال من التطبيق يمكن استخدامها بسهولة من قبل تطبيق آخر البنك يتطور.
مكونات جافا التواصل مع جمس.
جمس هو مجرد مواصفات ونحن بحاجة إلى اتخاذ قرار بشأن نظام الرسائل المتوافقة مع جمس. قررنا استخدام عب مكسيريز جمس لأن البنك هو متجر ЂњIBM، Ђќ باستخدام خوادم تطبيقات وبسفهير والعديد من منتجات عب الأخرى. ونتيجة لذلك، سوف نستخدم مكسيريز لأن لدينا بالفعل بنية تحتية للدعم في مكان ورخصة الموقع للمنتج.
والسؤال التالي هو كيفية توصيل نظام الرسائل مقسيريز مع خادم مساهمة C ++ مستقل و تيبكو استنادا إلى بيانات السوق وخوادم محرك تحليلات. نحن بحاجة إلى وسيلة للمستهلكين مكسيريز أن يكون الوصول إلى رسائل تيب. ولكن كيف؟ ربما يمكننا استخدام نمط "مترجم الرسائل" لترجمة رسائل تيب إلى رسائل مكسيريز. على الرغم من أن العميل C ++ ل مكسيريز بمثابة المترجم رسالة، وذلك باستخدام التضحية استقلال خادم جمس. وعلى الرغم من أن شركة تيبكو تمتلك واجهة برمجة تطبيقات جافا، إلا أن المهندس المعماري ومدير العميل رفضوا ذلك. ونتيجة لذلك، يجب التخلي عن نهج "مترجم الرسائل".
الجسر من خادم تيب إلى خادم مكسيريز يتطلب الاتصال بين C ++ وجافا. يمكننا استخدام كوربا، ولكن بعد ذلك ماذا عن الرسائل؟ نظرة فاحصة على نمط مترجم الرسائل يظهر أنه مرتبط بمحول القناة في استخدامه لبروتوكولات الاتصال. قلب محول قناة هو ربط أنظمة غير الرسائل إلى أنظمة المراسلة. زوج من محولات القناة التي تربط اثنين من أنظمة الرسائل هو جسر التراسل.
الغرض من جسر الرسائل هو نقل الرسائل من نظام الرسائل واحد إلى آخر. هذا هو بالضبط ما نقوم به مع تعقيد اضافي من لغة جاوة إلى C ++ الاتصالات. يمكننا تنفيذ جسر التراسل عبر لغة باستخدام مزيج من قناة محول s و كوربا. سنقوم ببناء اثنين من خوادم محول قناة خفيفة الوزن، واحدة في C ++ إدارة الاتصالات مع تيب، وواحد في إدارة الاتصال جافا مع جمس. وسيتصل محول القناة هذا، وهما نقطة نهاية الرسالة نفسها، ببعضهما البعض عبر كوربا. مثل خيارنا ل مكسيريز، وسوف نستخدم كوربا بدلا من جني لأنه هو معيار الشركة. جسر الرسائل تنفذ ترجمة الرسائل محاكاة فعالة بين أنظمة الرسائل التي تبدو غير متوافقة ولغات مختلفة.
رسالة المترجم باستخدام محولات القناة.
يظهر الرسم البياني التالي تصميم النظام الحالي بما في ذلك البوابات والمكونات الأخرى. هذا مثال جيد على نمط التطبيق. نحن الجمع بين اثنين من قناة محول s مع بروتوكول غير الرسائل لتنفيذ نمط "مترجم الرسالة"، باستخدام فعال نمط واحد لتنفيذ نمط آخر. بالإضافة إلى ذلك، غيرنا سياق محول القناة s 'لربط اثنين من أنظمة الرسائل مع بروتوكول الترجمة عبر لغة غير الرسائل بدلا من ربط نظام الرسائل إلى نظام غير الرسائل.
النظام الحالي مع محولات القناة.
هيكلة القنوات.
مفتاح للعمل مع أنماط ليس فقط معرفة متى لاستخدام أي نمط، ولكن أيضا كيفية الاستخدام الأكثر فعالية. ويجب أن يأخذ كل نمط من أنماط التنفيذ بعين الاعتبار تفاصيل المنصة التكنولوجية فضلا عن معايير التصميم الأخرى. يطبق هذا القسم نفس عملية الاكتشاف للعثور على الاستخدام الأكثر كفاءة لقناة النشر-الاشتراك في سياق خادم بيانات السوق التواصل مع محرك تحليلات.
بيانات السوق في الوقت الحقيقي تنشأ مع تغذية بيانات السوق، خادم C ++ الذي يبث بيانات السوق على تيب. يستخدم تغذية بيانات السوق منفصلة نشر قناة الاشتراك لكل السندات هو نشر أسعار ل. قد يبدو هذا الأمر متطرفا قليلا لأن كل سند جديد يحتاج إلى قناة جديدة خاصة به. ولكن هذا ليس شديدا جدا لأنك لا تحتاج فعلا إلى إنشاء قنوات في تيبكو. بدلا من ذلك، يتم الإشارة إلى القنوات بواسطة مجموعة هرمية من أسماء الموضوعات تسمى الموضوعات. ثم يقوم خادم تيبكو بتصفية تدفق رسالة واحدة حسب الموضوع، وإرسال كل موضوع فريد إلى قناة افتراضية واحدة. والنتيجة هي قناة رسالة خفيفة الوزن جدا.
يمكننا إنشاء نظام ينشر على عدد قليل من القنوات ويمكن للمشتركين الاستماع فقط للأسعار التي يهتمون بها. وهذا يتطلب من المشتركين استخدام فلتر الرسائل أو المستهلك الانتقائي لتصفية تدفق البيانات بأكمله لأسعار السندات مثيرة للاهتمام، وتحديد ما إذا كان كل رسالة يجب أن تتم معالجتها كما يتم استلامها. وبالنظر إلى أن بيانات السوق تنشر على قنوات مخصصة للسندات، يمكن للمشتركين التسجيل للحصول على التحديثات على سلسلة من السندات. وهذا يتيح للمشتركين فعليا "التصفية" عن طريق الاشتراك بشكل انتقائي في القنوات وتلقي التحديثات فقط من الاهتمام بدلا من اتخاذ قرار بعد استلام الرسالة. من المهم أن نلاحظ أن استخدام قنوات متعددة لتجنب تصفية هو استخدام غير قياسي من قنوات الرسائل. في سياق تكنولوجيا تيبكو ومع ذلك، نحن حقا اتخاذ قرار بشأن تنفيذ أو مرشحات الخاصة أو الاستفادة من تصفية القناة في صلب تيبكو - بدلا من ما إذا كان لاستخدام الكثير من القنوات.
العنصر التالي نحن بحاجة إلى تصميم هو محرك تحليلات، C ++ / تيب خادم آخر من شأنها تعديل بيانات السوق وإعادة بثها إلى تيب. على الرغم من أنه خارج نطاق تطوير جافا / جمس لدينا، ونحن نعمل عن كثب مع فريق C ++ لتصميمه لأننا "العميل" الأساسي تحليلات المحرك. والمشكلة المطروحة هي إيجاد بنية القناة التي تعيد بث بيانات السوق المعدلة حديثا بكفاءة أكبر.
وبما أن لدينا بالفعل قناة رسالة مخصصة لكل سند موروثة من تغذية سعر بيانات السوق، سيكون من المنطقي تعديل بيانات السوق وإعادة بث بيانات السوق المعدلة على قناة رسالة مخصصة للسندات. ولكن هذا لن يعمل منذ تحليلات تعديل أسعار السندات هي التاجر محددة. إذا كنا إعادة بث البيانات المعدلة على قناة رسالة السندات، ونحن سوف تدمر سلامة البيانات عن طريق استبدال بيانات السوق العامة مع بيانات محددة التاجر. من ناحية أخرى، يمكن أن يكون لدينا نوع رسالة مختلفة لبيانات السوق الخاصة بالتاجر التي ننشرها على نفس القناة مما يسمح للمشتركين بتحديد الرسالة التي يهتمون بها لتجنب إتلاف سلامة البيانات. ولكن بعد ذلك سيكون على العملاء تنفيذ مرشحات الخاصة بهم لفصل الرسائل لغيرهم من التجار. وبالإضافة إلى ذلك، ستحدث زيادة كبيرة في الرسائل التي يتلقاها المشتركون، مما يضع عبئا لا لزوم له عليهم.
هناك خياران:
قناة واحدة لكل تاجر: لكل تاجر قناة مخصصة لبيانات السوق المعدلة. وبهذه الطريقة، لا تزال بيانات السوق الأصلي سليمة وكل تطبيق التاجر يمكن الاستماع إلى تجارها قناة رسالة محددة لتحديثات الأسعار المعدلة. قناة واحدة لكل تاجر لكل سند: إنشاء قناة رسالة واحدة لكل تاجر لكل سند فقط لبيانات السوق المعدلة لتلك السندات. على سبيل المثال، سيتم نشر بيانات السوق للسندات أبك على قناة "بوند أبك" بينما سيتم نشر بيانات السوق المعدلة للتاجر A على قناة الرسالة "التاجر أ، بوند أبك"، بيانات السوق المعدلة للتاجر B على "التاجر B ، بوند أبك "، وهلم جرا.
قناة واحدة لكل تاجر.
قناة واحدة لكل سند لكل تاجر.
هناك مزايا وعيوب لكل نهج. نهج كل السندات، على سبيل المثال، يستخدم الكثير من قناة الرسالة. في أسوأ السيناريوهات، فإن عدد قناة الرسائل سيكون عدد السندات الإجمالية مضروبا في عدد التجار. يمكننا وضع الحدود العليا على عدد من القنوات التي سيتم إنشاؤها لأننا نعرف أن هناك فقط حوالي 20 التجار وأنها أبدا السعر أكثر من بضع مئات من السندات. هذا يضع الحد الأعلى تحت نطاق 10،000، وهو ليس غريبا جدا بالمقارنة مع ما يقرب من 100،000 قناة رسالة تغذية السوق سعر البيانات المستخدمة. أيضا، لأننا نستخدم تيب وقناة رسالة غير مكلفة للغاية، وعدد من قناة رسالة ق ليست قضية حادة. من ناحية أخرى، يمكن أن يكون العدد الهائل من قناة الرسائل s مشكلة من وجهة نظر الإدارة. في كل مرة يتم إضافة السندات يجب الحفاظ على قناة لكل تاجر. وقد يكون ذلك شديدا في نظام ديناميكي جدا. نظامنا، ومع ذلك، هو ثابت أساسا. كما أن لديها بنية تحتية لإدارة قناة الرسائل s تلقائيا. هذا جنبا إلى جنب مع العمارة الموروثة للمكون القديم باستخدام نهج مماثل يقلل من الجانب السلبي. هذا لا يعني أننا يجب أن تجعل عددا مفرطا بلا داع من قناة الرسائل ق. بدلا من ذلك، يمكننا تنفيذ نهج معماري يستخدم عددا كبيرا من قناة رسالة s عندما يكون هناك سبب.
وهناك سبب في هذه الحالة أن يأتي إلى موقع المنطق. إذا طبقنا نهج التاجر، يحتاج محرك أناليتيكش إلى منطق لتجميع قنوات الإدخال والإخراج. ويرجع السبب في ذلك إلى أن قنوات الإدخال من محرك أناليتيكش هي لكل سند وأن قناة رسالة الإخراج ستكون لكل تاجر، مما يتطلب من محرك أناليتيكش توجيه جميع مدخلات أناليتيكش من السندات المتعددة لمتاجر معين إلى مخرجات محددة للمتداول قناة الرسالة. يؤدي هذا إلى تحويل محرك التحليلات بشكل فعال إلى جهاز توجيه يستند إلى المحتوى لتنفيذ منطق التوجيه المخصص لتطبيقنا.
بعد بنية حافلة الرسائل، يعد محرك أناليتيكش خادما عاما يمكن استخدامه من قبل العديد من الأنظمة الأخرى في. لذلك نحن لا نريد أن سحابة مع وظيفة نظام معين. من ناحية أخرى، فإن النهج لكل السندات يعمل منذ فكرة التاجر امتلاك الناتج تحليلات أسعار السندات هي ممارسة مقبولة من قبل الشركة. يحتفظ النهج لكل السندات الفصل قناة رسالة من تغذية بيانات السوق سليمة، في حين إضافة عدة أكثر قناة رسالة ق. قبل أن نصل إلى العميل، نريد أن يقوم الموجه القائم على المحتوى بدمج هذه القنوات المتعددة في عدد من القنوات القابلة للإدارة. نحن لا نريد تطبيق العميل يعمل على سطح المكتب ترادر ​​Ђ ™ للاستماع إلى الآلاف أو عشرات الآلاف من قناة رسالة ق. الآن يصبح السؤال أين وضع جهاز التوجيه القائم على المحتوى. يمكن أن يكون لدينا ببساطة C ++ / تيب قناة محول إلى الأمام جميع الرسائل إلى بوابة التسعير على قناة رسالة واحدة. وهذا أمر سيء لسببين؛ فإننا سوف نقسم منطق الأعمال بين C ++ وجافا، ونحن سوف تفقد فائدة قناة رسالة منفصلة s على الجانب تيب مما يسمح لنا لتجنب تصفية في وقت لاحق من تدفق البيانات. بالنظر إلى مكونات جافا لدينا، يمكننا إما وضعه في بوابة التسعير أو إنشاء مكون وسيط بين بوابة التسعير والعميل.
من الناحية النظرية، إذا واصلنا الفصل القائم على السندات لقناة الرسالة ق وصولا إلى العميل، فإن بوابة التسعير إعادة بث معلومات التسعير مع بنية القناة نفسها مثل بوابة التسعير ومحرك أناليتيكش. وهذا يعني ازدواجية كل السندات المخصصة قنوات تيب في جمس. حتى إذا أنشأنا مكون وسيط بين بوابة التسعير والعميل، فسيظل على بوابة التسعير تكرار جميع القنوات في جمس. من ناحية أخرى، تنفيذ المنطق مباشرة في بوابة التسعير يسمح لنا لتجنب تكرار عدد كبير من القنوات في JMS†"مما يسمح لنا لخلق عدد أقل بكثير من القنوات في ترتيب واحد لكل تاجر. تسجل بوابة التسعير نفسها من خلال محول قناة C ++ / تيب كمستهلك لكل سند من كل تاجر في النظام. ثم تقوم بوابة التسعير بإعادة توجيه كل عميل محدد فقط بالرسائل المتعلقة بهذا التاجر المعين. بهذه الطريقة، نحن فقط استخدام عدد قليل من قناة الرسائل s على نهاية جمس، مع تعظيم الاستفادة من الفصل على نهاية تيب.
تدفق بيانات السوق الكامل إلى العميل.
تعد مناقشة تخطيط قناة الرسائل مثالا جيدا على كيفية دمج الأنماط المهمة. وكان الهدف هنا هو معرفة كيفية استخدام قناة الرسائل بشكل فعال. قول استخدام نمط لا يكفي. تحتاج إلى معرفة كيفية تنفيذ أفضل ودمج في النظام الخاص بك لحل المشاكل في متناول اليد. بالإضافة إلى ذلك، يوضح هذا المثال القوى التجارية في العمل. إذا تمكنا من تنفيذ منطق الأعمال في أي من مكوناتنا، كنا يمكن أن تذهب مع نهج التاجر وتنفيذ نهج أكثر بساطة عموما مع العديد من القنوات أقل.
هل تريد تحديد قناة رسالة؟
الآن بعد أن نعرف آليات الاتصال بين مكونات جافا / جمس والمكونات C ++ / تيبكو، ورأينا بعض بنية قناة الرسالة، ونحن بحاجة إلى أن تقرر أي نوع من قناة رسالة جمس s يجب أن تستخدم مكونات جافا للاتصال. قبل أن نستطيع الاختيار بين قنوات الرسائل المختلفة المتوفرة في جمس، نلقي نظرة على تدفق الرسائل عالية المستوى للنظام. لدينا اثنين من بوابات (التسعير والمساهمة) التواصل مع العميل. تدفقات بيانات السوق إلى العميل من بوابة التسعير التي ترسلها إلى بوابة المساهمة. تطبيق العميل يرسل رسالة إلى بوابة التسعير لتغيير التحليلات التي يتم تطبيقها على كل السندات. كما تقوم بوابة المساهمة بإرسال رسائل إلى تطبيق العميل ترحيل حالة تحديثات الأسعار إلى أماكن التداول المختلفة.
تدفق رسالة النظام.
تصف مواصفات جمس نوعين من قنوات الرسائل وقناة من نقطة إلى نقطة (قائمة انتظار جمس) وقناة النشر-الاشتراك (موضوع جمس). تذكر بأن قضية استخدام الاشتراك في الاشتراك هي تمكين جميع المستهلكين المهتمين من تلقي رسالة، في حين أن حالة استخدام نقطة إلى نقطة هي التأكد من أن مستهلك مؤهل واحد فقط يتلقى رسالة معينة.
ومن شأن العديد من الأنظمة ببساطة أن تبث رسائل إلى جميع تطبيقات العملاء، تاركة لكل طلب عميل فردي أن يقرر بنفسه ما إذا كان ينبغي معالجة رسالة معينة أم لا. وهذا لن يعمل لتطبيقنا منذ هناك عدد كبير من رسائل بيانات السوق يتم إرسالها إلى كل تطبيق العميل. إذا قمنا ببث تحديثات بيانات السوق للمتاجر غير المهتمين، فسوف نؤدي إلى إضاعة دورات معالج العميل بشكل غير ضروري لتحديد ما إذا كان سيتم معالجة تحديث بيانات السوق أم لا.
قناة من نقطة إلى نقطة ق في البداية يبدو وكأنه خيار جيد لأن العملاء يرسلون رسائل إلى خوادم فريدة من نوعها والعكس بالعكس. ولكن كان من متطلبات العمل أن التجار قد يتم تسجيل الدخول إلى آلات متعددة في نفس الوقت. إذا كان لدينا تاجر تسجيل الدخول في محطتين عمل في وقت واحد ويتم إرسال تحديث سعر من نقطة إلى نقطة، واحد فقط من اثنين من تطبيقات العميل سوف تحصل على الرسالة. وذلك لأن مستهلك واحد فقط على قناة من نقطة إلى نقطة يمكن أن يتلقى رسالة معينة. لاحظ أن الأول فقط من كل مجموعة من تطبيقات العميل التاجر يتلقى الرسالة.
الرسائل من نقطة إلى نقطة لتحديث الأسعار.
يمكننا حل هذا باستخدام نمط قائمة المستلمين، الذي ينشر الرسائل إلى قائمة المستلمين المقصودين، وضمان أن العملاء فقط في قائمة المستلمين سوف تتلقى رسائل. باستخدام هذا النمط، يمكن للنظام إنشاء قوائم المستلمين مع كافة مثيلات تطبيق العميل المتعلقة بكل تاجر. إرسال رسالة ذات صلة إلى تاجر معين بدوره إرسال الرسالة إلى كل تطبيق في قائمة المستلمين. وهذا يضمن جميع الحالات تطبيق العميل المتعلقة تاجر معين تلقي الرسالة. الجانب السلبي لهذا النهج هو أنه يتطلب نوعا ما من منطق التنفيذ لإدارة المتلقين وإرسال الرسائل.
قائمة المستلمين لتحديثات الأسعار.
على الرغم من أن نقطة إلى نقطة يمكن أن يتم العمل، دعونا see نرى ما إذا كان هناك طريقة أفضل. وباستخدام قناة النشر والاشتراك، يمكن للنظام بث رسائل على قنوات محددة للتاجر بدلا من القنوات الخاصة بتطبيق العميل. وبهذه الطريقة، ستتلقى جميع تطبيقات العميل التي تعالج الرسائل لمتاجر واحد الرسالة وتعالجها.
نشر-الاشتراك الرسائل للحصول على تحديثات الأسعار.
الجانب السلبي من استخدام قناة نشر الاشتراك هو أن معالجة الرسائل الفريدة ليست مضمونة مع مكونات الخادم. سيكون من الممكن أن تكون مثيلات متعددة من مكون ملقم مثيل وكل مثيل معالجة نفس الرسالة، وربما إرسال أسعار غير صالحة.
وإذ يشير إلى تدفق رسالة النظام، فإن اتجاه اتصال واحد فقط مرض مع كل قناة رسالة. الاتصالات من خادم إلى عميل مع نشر الاشتراك هو مرضية في حين أن الاتصال من العميل إلى الخادم ليس والتواصل مع العميل-نقطة مع نقطة إلى نقطة مرضية في حين ملقم العميل ليس كذلك. ونظرا لعدم الحاجة إلى استخدام نفس قناة الرسائل في كلا الاتجاهين، يمكننا استخدام كل قناة قناة اتجاه واحد فقط. سيتم تنفيذ الاتصالات من عميل إلى خادم مع نقطة إلى نقطة في حين سيتم تنفيذ الاتصالات من خادم إلى عميل مع نشر الاشتراك. وباستخدام هذا المزيج من قناة الرسائل s، يستفيد النظام من الاتصال المباشر مع مكونات الخادم باستخدام الرسائل من نقطة إلى نقطة وطبيعة البث المتعدد للنشر دون أي من العيوب.
تدفق الرسالة مع أنواع القنوات.
حل المشكلات مع الأنماط.
أنماط هي أدوات ومجموعات من أنماط هي أدوات. أنها تساعد على حل المشاكل. يعتقد البعض أن الأنماط مفيدة فقط أثناء التصميم. بعد تشبيه الأدوات، وهذا هو مثل القول أن الأدوات مفيدة فقط عند بناء منزل، وليس عند إصلاحه. والحقيقة هي أن الأنماط هي أداة مفيدة في جميع مراحل المشروع عند تطبيقها بشكل جيد. في الأقسام التالية سوف نستخدم نفس نمط عملية الاستكشاف استخدمنا في القسم السابق لحل المشاكل في نظامنا العمل الآن.
وامض تحديثات بيانات السوق.
التجار يريدون خلايا الجدول وميض عندما يتم تلقي بيانات السوق الجديدة للحصول على السندات، مما يدل بوضوح التغييرات. يتلقى عميل جافا رسائل مع بيانات جديدة بتشغيل تحديث ذاكرة التخزين المؤقت لبيانات العميل ثم تومض في الجدول في نهاية المطاف. المشكلة هي أن التحديثات تأتي في كثير من الأحيان. كومة مؤشر ترابط واجهة المستخدم الرسومية أصبحت مثقلة وتجميد في نهاية المطاف العميل لأنه لا يمكن الاستجابة لتفاعل المستخدم. وسوف نفترض أن وامض هو الأمثل والتركيز على تدفق البيانات من الرسائل من خلال عملية التحديث. فحص بيانات الأداء يظهر تطبيق العميل يتلقى العديد من التحديثات في الثانية. حدثت بعض التحديثات أقل من ميلي ثانية واحدة. اثنين من أنماط التي تبدو وكأنها يمكن أن تساعد على إبطاء تدفق الرسالة هي مجمع ورسالة تصفية.
الفكر الأول هو تنفيذ "تصفية الرسائل" للسيطرة على سرعة تدفق الرسالة عن طريق رمي التحديثات تلقت كمية صغيرة من الوقت بعد الرسالة المرجعية. على سبيل المثال، دعنا نقول أننا سنتجاهل الرسائل خلال 5 ميلي ثانية من بعضها البعض. يمكن للذاكرة تصفية ذاكرة التخزين المؤقت وقت آخر رسالة مقبولة وإزالة أي شيء وردت في غضون 5 ميلي ثانية. في حين قد لا تكون التطبيقات الأخرى قادرة على تحمل فقدان البيانات إلى حد ما، وهذا هو مقبول تماما في نظامنا بسبب تواتر التحديثات السعر.
تصفية الرسائل المستندة إلى الوقت.
المشكلة مع هذا النهج هو أنه لا يتم تحديث كافة حقول البيانات في نفس الوقت. كل السندات لديها ما يقرب من 50 حقول البيانات المعروضة للمستخدم بما في ذلك السعر. ونحن ندرك أنه لا يتم تحديث كل حقل في كل رسالة. إذا كان النظام يتجاهل الرسائل المتتالية، قد يكون جيدا جدا رمي البيانات الهامة.
النمط الآخر من الفائدة هو مجمع. يتم استخدام المجمع لإدارة تسوية العديد من الرسائل ذات الصلة في رسالة واحدة، مما يحتمل أن يقلل من تدفق الرسالة. يمكن أن يحتفظ المجمع بنسخة من بيانات السندات من الرسالة المجمعة الأولى، ثم يقوم بتحديث الرسائل المتتالية فقط أو تغييرها. في نهاية المطاف سيتم تمرير بيانات السندات المجمعة في رسالة إلى العميل. في الوقت الراهن، لنفترض أن المجمع سوف يرسل رسالة كل 5 ميلي ثانية مثل "تصفية الرسائل". وفي وقت لاحق، سنستكشف بديلا آخر.
مجمع مع التحديثات المتعاقبة الجزئية.
المجمع، مثل أي نمط آخر، ليس رصاصة فضية. فإن لديها الإيجابيات والنواحي التي تحتاج إلى استكشاف. واحد ناقص محتمل هو أن تنفيذ مجمع سوف يقلل من حركة الرسائل بمقدار كبير في حالتنا إلا إذا العديد من الرسائل تأتي في غضون وقت قصير نسبيا فيما يتعلق السندات نفسها. من ناحية أخرى، فإننا لا ننجز شيئا إذا كان عميل جافا يتلقى تحديثات فقط لحقل واحد عبر جميع السندات التجار. على سبيل المثال، إذا تلقينا 1000 رسالة في إطار زمني محدد مع 4 سندات من الفائدة، فإننا سوف يقلل من تدفق الرسالة من 1000 إلى 4 رسائل خلال هذا الإطار الزمني. بدلا من ذلك، إذا تلقينا 1000 رسالة في نفس الإطار الزمني مع 750 السندات من الفائدة، ونحن قد خفضت تدفق الرسالة من 1000 إلى 750 رسالة. مكاسب ضئيلة نسبيا لكمية من الجهد. تحليل سريع من تحديثات رسالة يثبت أن عميل جافا يتلقى العديد من الرسائل تحديث الحقول من نفس السندات، وبالتالي الرسائل ذات الصلة. لذلك، مجمع هو في الواقع قرارا جيدا.
ما تبقى هو تحديد كيفية معرفة المجمع عند إرسال رسالة تم تجميعها. يصف النمط بعض الخوارزميات للمجمع لمعرفة متى يتم إرسال الرسالة. وتشمل هذه الخوارزميات التي تتسبب في أن يقوم المجمع بتجميع محتوياته بعد انقضاء فترة معينة من الوقت، بعد اكتمال جميع الحقول المطلوبة في مجموعة بيانات، وغيرها. المشكلة مع كل هذه النهج هو أن المجمع هو السيطرة على تدفق الرسالة، وليس العميل. والعميل هو عنق الزجاجة الرئيسي في هذه الحالة، وليس تدفق الرسالة.
ويرجع السبب في ذلك إلى أن المجمع يقوم بافتراض أن مستهلكي رسائله المخزنة (تطبيق العميل في هذه الحالة) هم المستهلكون المستندون إلى الحدث أو المستهلكين الذين يعتمدون على الأحداث من مصدر خارجي. نحن بحاجة إلى تحويل العميل إلى مستهلك اقتراع، أو المستهلك الذي يتحقق بشكل مستمر للرسائل، بحيث يمكن تطبيق العميل التحكم في تدفق الرسالة. يمكننا القيام بذلك عن طريق إنشاء مؤشر ترابط الخلفية التي تدور باستمرار من خلال مجموعة من السندات والتحديثات ومضات أي تغييرات حدثت منذ آخر التكرار. وبهذه الطريقة، يتحكم العميل عند استلام الرسائل ونتيجة لذلك، يضمن عدم تحميلها مطلقا على الرسائل أثناء فترات التحديث العالية. We can easily implement this by sending a Command Message to the Aggregator initiating an update. The Aggregator will respond with a Document Message containing the set of updated fields that the client will process.
The choice of Aggregator over Message Filter is clearly a decision based solely on the business requirements of our system. Each could help us solve our performance problems, but using the Message Filter would solve the problem at cost of the system data integrity.
Major Production Crash.
With the performance of the flashing fixed, we are now in production. One day the entire system goes down. MQSeries crashes, bringing several components down with it. We struggle with the problem for a while and finally trace it back to the MQSeries dead letter queue (an implementation of the Dead Letter Channel ). The queue grows so large that it brings down the entire server. After exploring the messages in the dead letter queue we find they are all expired market data messages. This is caused by “slow consumers, ” or consumers that do not process messages fast enough. While messages are waiting to be processed, they time out (see the Message Expiration pattern) and are sent to the Dead Letter Channel . The excessive number of expired market data messages in the dead letter queue is a clear indication that the message flow is too great – messages expire before the target application can consume them. We need to fix the message flow and we turn to patterns for help slowing down the message flow.
A reasonable first step is to explore solving this problem with the Aggregator as we recently used this pattern to solve the similar flashing market data control rate problem. The system design relies on the client application to immediately forward market data update messages to the trading venues. This means the system cannot wait to collect messages and aggregate them. So the Aggregator must be abandoned.
There are two other patterns that deal with the problem of consuming messages concurrently: Competing Consumers and Message Dispatcher . Starting with Competing Consumers , the benefit of this pattern is the parallel processing of incoming messages. This is accomplished using several consumers on the same channel. Only one consumer processes each incoming message leaving the others to process successive messages. Competing Consumers , however, will not work for us since we are using Publish-Subscribe Channel s in server-to-client communication. Competing Consumers on a Publish-Subscribe Channel channel means that all consumers process the same incoming message. This results in more work without any gain and completely misses the goal of the pattern. This approach also has to be abandoned.
On the other hand, the Message Dispatcher describes an approach whereby you add several consumers to a вЂ˜pool’. Each consumer can run its own execution thread. One main Message Consumer listens to the Channel and delegates the message on to an unoccupied Message Consumer in the pool and immediately returns to listening on the Message Channel . This achieves the parallel processing benefit of Competing Consumers , but works on Publish-Subscribe Channel s.
The Message Dispatcher in context.
Implementing this in our system is simple. We create a single JMSListener called the Dispatcher, which contains a collection of other JMSListener s called Performers. When the onMessage method of the Dispatcher is called, it in turn picks a Performer out of the collection to actually process the message. The result of which is a Message Listener (the Dispatcher) that always returns immediately. This guarantees a steady flow of message processing regardless of the message flow rate. Additionally, this works equally well on a Publish-Subscribe Channel s as it does on a Point-to-Point Channel s. With this infrastructure, messages can be received by the client application at almost any rate. If the client application is still slow to process the message after receiving them, the client application can deal with the delayed processing and potentially outdated market data rather than the messages expiring in the JMS Message Channel .
The crash discussed in this section and the fix using the Message Dispatcher is an excellent example of the limits of applying patterns. We encountered a performance problem based on a design flaw not allowing the client to process messages in parallel. This greatly improved the problem, but did not completely fix it. This is because the real problem was the client becoming a bottleneck. This couldn’t be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but don’t necessarily make up for poor upfront design.
Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems.
Gregor Hohpe and Bobby Woolf.
From Enterprise Integration to Enterprise Transformation:
My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT.

Bond Trading Systems.
How bond trading systems work.
The Service Platform.
E-trading depends on data being shared between services. A service platform that facilitates easy data sharing and service management is essential to building a successful bond trading system. This article describes the core fundamental requirements of the service platform and why they are so important.
Service Access Protocol.
A service supports a particular business process, it provides access to data and functions that are specific to the business process. Typically the data produced by a service needs to be accessed by multiple clients on remote machines. The clients can be applications or other services. A service should not make a distinction between the type of client accessing it; all access is treated in the same way. The way in which a service makes data available and the format of the data is called the service access protocol . All services should use the same access protocol so that a client can connect to any service using the same protocol. A common service access protocol is the backbone of the service platform concept. When all services support the same access protocol, they share a common design and form the foundation of a service platform.
The diagram below helps to illustrate the components of the service access protocol.
Data Access Patterns.
A service provides access to data using one of three patterns:
For each of these, data is published in the form of messages. A message is generally published when an update occurs to a data entity. All three of these patterns can be considered real-time data access patterns. Real-time in this context means the data response is provided as fast as possible with no introduced delays. The service access protocol needs to support these access patterns.
Blind-publish.
This describes the pattern where a service unilaterally publishes data for any client to receive, regardless of whether there is any client that is actually interested in the data. Blind-publishing can be very inefficient, particularly for highly volatile data, as network bandwidth is taken up publishing messages with potentially no clients using the data. Data published using this pattern is always a complete image for each and every update. Multiple clients can receive the same message. Heartbeats (signals published by a service to indicate they are on-line) are one example of the blind-publish data access pattern.
Subscribe-publish.
This pattern requires a service to publish data for a specific entity only when one or more clients subscribe for the entity. This requires that the data has some form of unique identification for each entity. A service will need to track what clients have subscribed for what data entities. A heart-beating mechanism is also required for services to monitor clients. A service stops publishing data for an entity when there are no more clients subscribed for the data entity. This can happen if a client suddenly stops or sends a request to unsubscribe from the data entity. The heart-beating mechanism is used by the service to detect when a client stops unexpectedly. When a client subscribes for data in this way it should, generally, be able to expect an initial version of the data entity that the service has. This initial version might be the current state of the data or a ‘blank’ state which can indicate that the data is not available in the service.
If the service supports publishing deltas, then an image-on-subscribe capability also is needed. The term ‘delta’ describes only publishing changes in the data, not the complete image. This can provide substantial network bandwidth savings as, in general, not all attributes of an entity change all the time. The image-on-subscribe concept refers to the client receiving the initial image of the data entity as its first update and then after this only receiving the deltas. The deltas can be applied on top of the initial image to resolve the current state of the data entity. All messages published for a data entity will need a sequence number. This allows the client to detect any out-of-order messages and is also critical to being able to apply deltas on top of the received image. The image itself must have a sequence that can be identified within a stream of delta messages for the entity. The same delta message can be received by multiple clients.
The subscribe-publish pattern is essential when a service can have a potentially large data universe and expects that at any point in time only a portion of the universe will be subscribed for by clients. This makes the network utilisation more efficient and allows the service to conserve its resources.
Request-response.
A request-response pattern provides the capability for a client to be able to receive a response to a request sent to the service. In general, the service response is only directed at the requesting client; other clients do not see the response message. This access pattern is typically used for clients to invoke functions on services. The request message identifies the function to invoke along with any arguments for the function. The response from the service will contain the result from invoking the function. However, this access pattern can also be used to request images or receive on-shot data upon request by the client.
This pattern requires some form of timeout logic in the client. When a client sends a request it generally starts a countdown for a response. If the response does not arrive within the countdown the client determines that the request has failed. This is a basic way to handle the request timings. An improvement is for the service to send back a signal when it receives the message, another signal when it starts to process the message and then finally send the response. If the client has a separate countdown for each of these phases in the request-response then more fine-grain control is achievable and timeout situations can be tuned out. As an example, if a service takes 0.2 seconds to process a message but, due to the number of requests, each request takes 0.9 seconds before it starts to be processed, then a client with a simple 1 second timeout would fail each request (each request would appear to take 1.1 seconds). However, if the client observed a 1 second start timeout and a 0.5 second processing timeout then the requests would succeed.
Data Format.
The service access protocol also defines what the data looks like, its format. This is very important so that the data is universally understandable by all connecting clients. Translating between data formats is costly, in terms of development and maintenance timescales and runtime processing resources. Therefore a critical aspect for all services is to have a common data format.
Data format defines the rules for how the data is structured and the type of the data values. The structure defines how to understand what the data is representing. If the structure is understood, then the data values can be interpreted in the correct context, e. g. the value 123.45 can be correctly interpreted as the bid price, say, rather than the ask price, because the structure is understood. Generally, data structures fall into one of these categories:
dictionary – this is the key-value structure where every data value is identified with a unique key. This type of structure is very fast for reading and writing sparse data. Sending data changes (deltas) is most efficient when the structure is dictionary-based. hierarchy – data is expressed in a hierarchical manner, e. g. XML. It is generally quite verbose. Data structures that are hierachy-based tend to be more complex to process then dictionary-based ones and are not as fast as a dictionary-based equivalent.
There is a hybrid category where a dictionary-based structure uses hierarchy within the keys to achieve a middle-ground solution. As an example, keys can be “.” separated to provide for an address space like, “foo. bar.1”, “foo. bar.2”, say.
Regardless of the data structure, there has to be a defined range of types that the data values can express. The types allow the data to be interpreted in its correct form, e. g. a string or a number or a binary stream. The basic data types that need to be supported are:
text floating-point numbers integer numbers binary stream images (blobs)
Supporting these 4 data types allows for any real-world data value to be correctly represented.
Service Platform Features.
The data access protocol for a service is supported by some form of messaging technology. However, messaging technology only solves the “plumbing” problem of how to get data from one endpoint to another. The service infrastructure for bond trading requires more than just messaging technology for a common service access protocol, it also needs the capability for:
discovery and monitoring of services – allows functionality to be controlled depending on availability of business services discovery of data available from services – allows functionality to react when specific data is ready discovery of when clients subscribe for data – allows resources to be activated only when there is a need to support a client subscription (e. g. starting data feeds only when a client starts a subscription for the feed) inspection of service state – allows support teams to be able to know when a service is in trouble and take action to fix it viewing of data in a service – allows support teams to be able to diagnose data problems by viewing the data at source permissioning of data – supports data security/fee requirements by preventing unauthorised clients from receiving data controlling data publishing rates (throttling) – protects the environment from high publish rates that can overload clients and hardware resources remote control of services – provides the capability to change service status and settings without needing to disrupt the service high-availability for services – replaces a service that stops unexpectedly with a backup service.
All these capabilities should be provided by a common framework that all services are built upon. This common framework is the service platform . By designing a framework that has these features and supports services and clients that use the same messaging technology, a truly robust and extensible technology solution platform is provided for bond trading.
Why use a service platform?
It is possible to have all the capabilities listed above by not using a service platform, however the features tend to be retro-fitted onto existing designs, sometimes only being applied to certain services, othertimes different technologies are used for the same feature in different services. Eventually the service landscape becomes a heterogeneous mix-n-match of different designs and technologies that ultimately may provide the core features of a service platform but at the expense of unified architecture and increase maintenance costs. Using a service platform to build a bond trading system provides reduced development and maintenance costs and timescales; development can focus on the business logic of the services/clients rather than the infrastructure concerns.
The diagram below helps to illustrate how using a service platform architecture simplifies the access to services. With a service platform, clients only need a single interface to access all services, whereas a non service platform design requires the client to use a different interface depending on the service being accessed. A separate interface per service introduces complexity because, generally, the interfaces use different technologies which increases the resources required for development and maintenance.
A service platform also benefits the user-interface design of a bond trading system. The user-interface (UI) is usually a grouping of various visual displays and controls across different services. If all the services share the same messaging technology and data structure then the UI components become standard across all services. Specialised versions can be created that exist purely for business reasons rather than technical and ultimately all components share a common interface pattern to the business services.
In closing…
This article has introduced the concept of the service platform and highlighted its architectural importance. Building a service platform is not a trivial undertaking. There are only a few commercially available options and even fewer open-source ones. The ClearConnect platform is an open-source example that provides all the capabilities described in this article. This platform will be used as a reference platform for building examples of the services in later articles.

Bond trading system architecture

تداول إلكتروني ثابت الدخل -
حلول للأعمال التجارية.
الفائز نظام التداول على جانب الشراء من السنة في جوائز فو الدولية لعام 2017.
أكسيترادر ​​يجلب الخاص بك الدخل الثابت أماكن التداول ومصادر السيولة معا في واحد تطبيق التداول واحد - لمزيد من الكفاءة وأفضل تنفيذ.
أكسيترادر ​​هو الأول والأكثر تقدما تصميم نظام إدارة الدخل الثابت الهدف في العالم.
أكثر من 90٪ من عملائنا الرجوع أكسيترادينغ.
للعملاء الجدد.
في غضون شهر واحد من العيش مع أكسيترادر،
شهدت شركة وساطة مقرها لندن زيادة في الصفقات.
من 30 إلى أكثر من 150 في اليوم.
شركة رائدة في مجال الدخل الثابت الإقليمي.
وتحسين القدرة على التداول وتوفير آلاف الدولارات سنويا.
عن طريق اختيار أكسيترادر ​​كحلها صنع السوق.
نظام إدارة النظام & أمب؛ وتكامل منصة التداول المتعددة، وسير العمل التجاري وأفضل أدوات التنفيذ، والإبلاغ، بعد أتمتة التجارة.
مكاتب التنفيذ وتداول الوكالة:
أمر العميل توجيه وتنفيذ سير العمل؛
التكامل مع بلومبرغ تسوكس & لوت؛ غو & غ؛
قوية، وأسعار تسعير المستخدم شكلي،
أوتو-كوتينغ، صوت التجارة الحجز،
مباشرة من خلال التجهيز.
AxeTrading® متخصصة في توفير حلول تقنية فعالة للتحديات التي تواجه المستثمرين ذوي الدخل الثابت والتجار في الأسواق اليوم.
لدينا خبرة من ذوي الخبرة وحلول فريدة من نوعها تمكن عملاء أكسيترادينغ لتنفيذ استراتيجياتها التداول الإلكتروني الدخل الثابت بنجاح والميزانية. وهي تمكن عمالئنا من مواجهة التحديات التي تفرضها السيولة المجزأة والتنظيم) بما في ذلك MiFID2 و إمير و دود-فرانك و بازل إي (والطلب على زيادة الكفاءة.
'الفأس': الفائدة التي يظهرها الشخص أو المتداول في شراء أو بيع ضمان دخل ثابت.
قد يكون لدى المتداول مصلحة محددة في ضمان معين للدخل الثابت استنادا إلى مراكز التداول الخاصة به.
ويمكن القول بأن هذا الشخص "محوري" في ذلك الأمن.
تمكن حلول أكسيترادينغ الفريدة والمبتكرة كلا من تجار البيع الثابت من جانب الشراء والبيع للاستفادة من التداول الإلكتروني الثابت الدخل؛ فهي تبسط سير العمل، وتقلل من المخاطر التشغيلية وتسهل الامتثال التنظيمي.
تمكن حلولنا من تقديم التقارير ومساعدة عملائنا على استخراج رؤى تجارية قيمة من نشاطهم التجاري. الموظفين أكسيترادينغ لديها عقود من الخبرة في صناعة تكنولوجيا المعلومات المالية. جودة خدمة العملاء هي أيضا جزء لا يتجزأ من عروضنا.
ويمكن الحصول على المراجع من عملائنا الحاليين إذا لزم الأمر.
أسباب أكسيترادينغ.
سوف تعطيك الحافة.
يوفر أكسيترادينغ متعددة ثابتة منصة تجميع الدخل بما في ذلك أوتك، والتبادلات، سيف.
يدعم أكسيترادر ​​أفضل تنفيذ والامتثال ل MiFID2. قارن التسعير من مصادر متعددة وتتبع تلقائيا السوق من خلال حياة النظام.
توفر أكسيترادينغ حلول التداول الإلكتروني ذات الدخل الثابت التي تخدم احتياجات كلا الطرفين.
شراء وبيع الجانب.
لدينا عقود من الخبرة في التداول الإلكتروني ذات الدخل الثابت.
ونحن قادرون على تقديم المشورة ومساعدة عملائنا.
أكسيترادينغ يبني شراكات التكنولوجيا مع عملائنا. ونحن نعمل معهم لتنفيذ أنظمة التداول الإلكتروني الفعال ذات الدخل الثابت & أمب؛ الاستراتيجيات.
قوية، وأسعار تسعير المستخدم شكلي بما في ذلك الحسابات المخصصة، التسعير الشرطي، التنبيهات المستخدم يمكن تحديدها / ظروف حاليا، & أمبير؛ ميزات السلامة.
أكسيترادينغ يدمج مع الأنظمة الداخلية والخارجية لالتقاط التجارة الآلي & أمب؛ الإبلاغ (المعالجة المباشرة أو "محطة المعالجة")
خدمة الخبراء & أمب؛ يتم تضمين الدعم مع أكسيترادر.
سهل الاستعمال، كفاءة ومرنة.
بنيت أكسيترادر ​​على أحدث تقنيات جافا ونشرها داخل المؤسسة الخاصة بك.
تنفيذ مباشر من قرص أو تحميل؛ وشملت المساعدة.
الحد الأدنى من متطلبات الأجهزة.
أكسيترادر ​​هو نظام شامل مع البصمة المدمجة.
يشمل الخدمة والدعم.
شركاء أكسيترادينغ مع عملائنا لتقديم حلول فعالة،
في الوقت المحدد وعلى الميزانية.
مرنة، نظام سهل الاستعمال. الذاتي للتكوين - يوفر التكاليف.
قابلة للتطوير من تجار اثنين.
إلى المؤسسة العالمية.
ميزات السلامة المضمنة في جميع أنحاء أكسيترادر.
محرك تسعير قوي ومرن - يمكن للمتداولين تكوين وإدارة أنفسهم.
حلول أكسيترادينغ تتكامل مع إدارة النظام وأنظمة المكاتب الخلفية، فضلا عن منصات التداول متعددة الدخل الثابت ومصادر التسعير.
حلولنا تجلب سير العمل الخاص بك الدخل الثابت والسيولة معا في تطبيق سطح المكتب واحد لتداول أكثر كفاءة وأفضل تنفيذ.
ويؤدي التكامل التجاري بعد ذلك مع أماكن الإبلاغ التنظيمية بما في ذلك تريس / فينرا، وأمين الحفظ، ووكالات المقاصة إلى زيادة تبسيط التداول.
أنواع الاتصال التي توفرها أكسيترادر.
من أجل تجارة فعالة ذات دخل ثابت.
بلومبرغ التكامل فكون؛
تأكيد التجارة الصوتية عبر شبكة الإنترنت.
تأكيد التجارة فيكس؛
بلومبرغ فيت، تسوكس؛
ماركيتاكسيس (بما في ذلك فتح التداول)؛
التكامل مع التبادلات الرائدة (فيكس)
متعددة سيف التجميع والتكامل.
التكامل مع نظام إدارة أوامر شركتك (فيكس):
التماس أو سير العمل غير المرغوب فيها.
دمج أي بيانات (حيث يسمح بذلك)؛
لدى أكسيترادينغ شراكات البيانات مع بائعي بيانات الدخل الثابت الرائدة لضمان سرعة & أمب؛ سهلة التكامل.
التكامل مع الوسط & أمب؛ ونظم المكاتب الخلفية، بما في ذلك بلومبرغ تومس، موريكس، كوندور +.
نشر التكامل التجاري مع أمناء الحفظ، والمبررات، وإعداد التقارير التنظيمية بما في ذلك تريس / فينرا.
زبائننا هم من تجار الدخل الثابت بما في ذلك شركات البيع والشراء، الذين يبحثون عن طرق جديدة أو أكثر كفاءة للتجارة، أو لتوزيع سيولة الدخل الثابت.
عبر شبكات التداول الإلكتروني ذات الدخل الثابت.
تساعد تقنيتنا عملائنا على التكيف بشكل فعال مع التأثير المتطور للأنظمة على أسواق الدخل الثابت، بما في ذلك ميفيد و بازل إي و دود-فرانك وغيرها.
ما يقولون عنا.
مارتن ريتشاردسون - أسواق رأس المال في بنك راند ميرتشانت.
& كوت؛ بعد تقييم عدد من البدائل، اخترنا أكسيترادر ​​لأنها قدمت حلا مخصصا خصيصا لنا، وبالتالي فإننا لم ندفع مقابل أي وظيفة زائدة عن الحاجة. والنتيجة النهائية هي أن أكسيترادر ​​قدم لنا منتج كبير وهو فعال للغاية من حيث التكلفة والكمال لاحتياجاتنا الفردية & كوت؛
ريتشارد بوست، رئيس تجارة الائتمان الاسترليني في كاناكورد جينويتي.
& كوت؛ من أجل الوفاء بمتطلباتنا للسندات التجارية إلكترونيا عبر بلومبرغ نظرنا في الخيارات المتاحة لنا وفضل أكسيترادينغ وحل أكسيترادر. وقد وفر هذا وسيلة فعالة للتجارة وأثار أيضا رؤية كاناكورد جينويتي مع العملاء في السوق. وإنني أتطلع إلى شراكة طويلة وصحية مع أكسيترادينغ في المستقبل. & كوت؛
دينوس شارك في تأسيس أكسيترادينغ في عام 2009 ولها أكثر من 25 عاما من الخبرة في مجال الدخل الثابت الوساطة والمبيعات والتجارة الإلكترونية.
وتشمل خبرته السابقة، من بين أمور أخرى، دورا بارزا في المبيعات الإلكترونية الائتمان في سيتي جروب ودخل ثابت.
والتجارة الإلكترونية دور تاجر مبيعات متخصص في بلومبرغ. كل من المناصب التي عقدت في لندن لمدة 5 و 7 سنوات على التوالي.
بعد أن اكتسب خبرة أكثر من 16 عاما في تجارة الدخل الثابت / الريبو والوساطة الإلكترونية، اكتسبت دينوس المعرفة التقنية والتجارية المتعمقة في هذا القطاع له سمعة قوية بين أقرانه وزملائه وعملائه.
المؤسس المشارك لشركة أكسيترادينغ، يمتلك رالف أكثر من 15 عاما من الخبرة في مجال التجارة الإلكترونية ذات الدخل الثابت، وهو مسؤول عن تطوير التكنولوجيا والبرامج في أكسيترادينغ.
حاصل على شهادة في هندسة الحاسوب، خبرته السابقة.
ويشمل تصميم وتنفيذ التسعير الثابت مفصل وأنظمة التداول ل جب مورغان وغيرها من كبار تجار الدخل الثابت.
رالف هو مطور الأعمال الاستراتيجية مع الألفة من الأسواق التجارية في مختلف البلدان. وقبل المشاركة في تأسيس أكسيترادينغ، ساهم في بدء وتطوير العديد من شركات تكنولوجيا التداول ذات الدخل الثابت الناجحة، وكل منها لا يزال ناجحا في الأعمال التجارية اليوم.
كان مارك مسؤولا عن تطوير الأعمال في أكسيترادينغ منذ انضمامه للفريق في عام 2018.
لديه خبرة تزيد عن 17 عاما في بلومبرغ، بما في ذلك الأدوار العليا في التداول الإلكتروني ذات الدخل الثابت.
اكتسب مارك خبرة متخصصة في.
وبيع وتنفيذ نظم مزادات السندات، ومنصات التداول، وأنظمة التداول ذات الدخل الثابت في الأسواق الأولية والثانوية في الأسواق المتقدمة والناشئة.
وقد عمل مع الخزائن الوطنية، ومصدريها، وجانب الشراء والبيع الذي ينفذ التجارة الإلكترونية ذات الدخل الثابت في العديد من البلدان في جميع أنحاء العالم. مارك يجلب تجربة تداول إلكترونية متعمقة إضافية ذات دخل ثابت لفريق أكسيترادينغ.
مهندس برمجيات أقدم.
وقد كان هانز جزءا من فريق أكسيترادينغ منذ عام 2018 وهو مهندس البرمجيات العليا. مع درجة الماجستير في علوم الكمبيوتر وأكثر من 10 عاما من الخبرة في أنظمة التداول الإلكتروني ذات الدخل الثابت، وقال انه يقود تطوير البرمجيات.
وفريق اختبار أكسيترادينغ.
مع فهم قوي للأعمال والتكنولوجيا، وتشمل خبرته تصميم المنتجات للتداول الإلكتروني من السندات، فكس والمشتقات، فضلا عن تقييم وتنفيذ نظم بيانات السوق.
تمكن مجموعة مهارات هانز أكسيترادينغ من الاستجابة بسرعة وبدقة لمتطلبات عملائنا.
يقع أكسيترادينغ المحدودة في لندن ومسجلة في انكلترا وويلز.
المكتب المسجل: كرافن هاوس، 16 نورثمبرلاند أفينو - لندن، WC2N 5AP (المملكة المتحدة) | رقم تسجيل الشركة: 06721631.
© حقوق الطبع والنشر AxeTrading® 2018. أكسيترادينغ هي علامة تجارية مسجلة. كل الحقوق محفوظة.

Trading Systems: Designing Your System - Part 1.
The preceding section of this tutorial looked at the elements that make up a trading system and discussed the advantages and disadvantages of using such a system in a live trading environment. In this section, we build on that knowledge by examining which markets are especially well-suited to system trading. We will then take a more in-depth look at the different genres of trading systems.
The equity market is probably the most common market to trade in, especially among novices. In this arena, big players such as Warren Buffett and Merrill Lynch dominate, and traditional value and growth investing strategies are by far the most common. Nevertheless, many institutions have invested significantly in the design, development and implementation of trading systems. Individual investors are joining this trend, though slowly.
The large amount of equities available allows traders to test systems on many different types of equities - everything from extremely volatile over-the-counter (OTC) stocks to non-volatile blue chips.
The effectiveness of trading systems can be limited by the low liquidity of some equities, especially OTC and pink sheet issues.
Commissions can eat into profits generated by successful trades, and can increase losses. OTC and pink sheet equities often incur additional commission fees.
The main trading systems used are those that look for value - that is, systems that use different parameters to determine whether a security is undervalued compared to its past performance, its peers, or the market in general.
The foreign exchange market, or forex, is the largest and most liquid market in the world. The world's governments, banks and other large institutions trade trillions of dollars on the forex market every day. تعتمد غالبية التجار المؤسساتيين في البورصة على أنظمة التداول. The same goes for individuals on the forex, but some trade based on economic reports or interest payouts.
The liquidity in this market - due to the huge volume - makes trading systems more accurate and effective.
There are no commissions in this market, only spreads. Therefore, it's much easier to make many transactions without increasing costs.
Compared to the amount of equities or commodities available, the number of currencies to trade is limited. But because of the availability of 'exotic currency pairs' - that is, currencies from smaller countries - the range in terms of volatility is not necessarily limited.
The main trading systems used in forex are those that follow trends (a popular saying in the market is "the trend is your friend"), or systems that buy or sell on breakouts. This is because economic indicators often cause large price movements at one time.
Equity, forex, and commodity markets all offer futures trading. This is a popular vehicle for system trading because of the higher amount of leverage available and the increased liquidity and volatility. However, these factors can cut both ways: they can either amplify your gains or amplify your losses. For this reason, the use of futures is usually reserved for advanced individual and institutional system traders. This is because trading systems capable of capitalizing on the futures market require much greater customization, use more advanced indicators and take much longer to develop.
It's up to the individual investor to decide which market is best suited to system trading - each has its own advantages and disadvantages. Most people are more familiar with the equity markets, and this familiarity makes developing a trading system easier. However, forex is commonly thought to be the superior platform to run trading systems - especially among more experienced traders. Moreover, if a trader decides to capitalize on increased leverage and volatility, the futures alternative is always open. Ultimately, the choice lies in the hands of the system developer.
The most common method of system trading is the trend-following system. In its most fundamental form, this system simply waits for a significant price movement, then buys or sells in that direction. This type of system banks on the hope that these price movements will maintain the trend.
Moving Average Systems.
Frequently used in technical analysis, a moving average is an indicator that simply shows the average price of a stock over a period of time. The essence of trends is derived from this measurement. The most common way of determining entry and exit is a crossover. The logic behind this is simple: a new trend is established when price falls above or below its historic price average (trend). Here is a chart that plots both the price (blue line) and the 20-day MA (red line) of IBM:
The fundamental concept behind this type of system is similar to that of a moving average system. The idea is that when a new high or low is established, the price movement is most likely to continue in the direction of the breakout. One indicator that can be used in determining breakouts is a simple Bollinger Band® overlay. بولينجر باندز & ريج؛ show averages of high and low prices, and breakouts occur when price meets the edges of the bands. Here is a chart that plots price (blue line) and Bollinger Bands® (gray lines) of Microsoft:
Disadvantages of Trend-Following Systems:
Empirical Decision-Making Required - When determining trends, there is always an empirical element to consider: the duration of the historic trend. For example, the moving average could be for the past 20 days or for the past five years, so the developer must determine which one is best for the system. Other factors to be determined are the average highs and lows in breakout systems.
Lagging Nature - Moving averages and breakout systems will always be lagging. In other words, they can never hit the exact top or bottom of a trend. This inevitably results in a forfeiture of potential profits, which can sometimes be significant.
Whipsaw Effect - Among the market forces that are harmful to the success of trend-following systems, this is one of the most common. The whipsaw effect occurs when the moving average generates a false signal - that is, when the average drops just into range, then suddenly reverses direction. This can lead to massive losses unless effective stop-losses and risk management techniques are employed.
Sideways Markets - Trend-following systems are, by nature, capable of making money only in markets that actually do trend. However, markets also move sideways, staying within a certain range for an extended period of time.
Extreme Volatility May Occur - Occasionally, trend-following systems may experience some extreme volatility, but the trader must stick with his or her system. The inability to do so will result in assured failure.
Basically, the goal with the countertrend system is to buy at the lowest low and sell at the highest high. The main difference between this and the trend-following system is that the countertrend system is not self-correcting. In other words, there is no set time to exit positions, and this results in an unlimited downside potential.
Types of Countertrend Systems.
Many different types of systems are considered countertrend systems. The idea here is to buy when momentum in one direction starts fading. This is most often calculated using oscillators. For example, a signal can be generated when stochastics or other relative strength indicators fall below certain points. There are other types of countertrend trading systems, but all of them share the same fundamental goal - to buy low and sell high.
E mpirical Decision-Making Required - For example, one of the factors the system developer must decide on is the points at which the relative strength indicators fade.
Extreme Volatility May Occur - These systems may also experience some extreme volatility, and an inability to stick with the system despite this volatility will result in assured failure.
Unlimited Downside - As previously mentioned, there is unlimited downside potential because the system is not self-correcting (there is no set time to exit positions).
The main markets for which trading systems are suitable are the equity, forex and futures markets. Each of these markets has its advantages and disadvantages. The two main genres of trading systems are the trend-following and the countertrend systems. Despite their differences, both types of systems, in their developmental stages, require empirical decision making on the part of the developer. Also, these systems are subject to extreme volatility and this may demand some stamina - it is essential that the system trader stick with his or her system during these times. In the following installment, we'll take a closer look at how to design a trading system and discuss some of the software that system traders use to make their lives easier.

Bond Trading Systems.
How bond trading systems work.
The Service Platform.
E-trading depends on data being shared between services. A service platform that facilitates easy data sharing and service management is essential to building a successful bond trading system. This article describes the core fundamental requirements of the service platform and why they are so important.
Service Access Protocol.
A service supports a particular business process, it provides access to data and functions that are specific to the business process. Typically the data produced by a service needs to be accessed by multiple clients on remote machines. The clients can be applications or other services. A service should not make a distinction between the type of client accessing it; all access is treated in the same way. The way in which a service makes data available and the format of the data is called the service access protocol . All services should use the same access protocol so that a client can connect to any service using the same protocol. A common service access protocol is the backbone of the service platform concept. When all services support the same access protocol, they share a common design and form the foundation of a service platform.
The diagram below helps to illustrate the components of the service access protocol.
Data Access Patterns.
A service provides access to data using one of three patterns:
For each of these, data is published in the form of messages. A message is generally published when an update occurs to a data entity. All three of these patterns can be considered real-time data access patterns. Real-time in this context means the data response is provided as fast as possible with no introduced delays. The service access protocol needs to support these access patterns.
Blind-publish.
This describes the pattern where a service unilaterally publishes data for any client to receive, regardless of whether there is any client that is actually interested in the data. Blind-publishing can be very inefficient, particularly for highly volatile data, as network bandwidth is taken up publishing messages with potentially no clients using the data. Data published using this pattern is always a complete image for each and every update. Multiple clients can receive the same message. Heartbeats (signals published by a service to indicate they are on-line) are one example of the blind-publish data access pattern.
Subscribe-publish.
This pattern requires a service to publish data for a specific entity only when one or more clients subscribe for the entity. This requires that the data has some form of unique identification for each entity. A service will need to track what clients have subscribed for what data entities. A heart-beating mechanism is also required for services to monitor clients. A service stops publishing data for an entity when there are no more clients subscribed for the data entity. This can happen if a client suddenly stops or sends a request to unsubscribe from the data entity. The heart-beating mechanism is used by the service to detect when a client stops unexpectedly. When a client subscribes for data in this way it should, generally, be able to expect an initial version of the data entity that the service has. This initial version might be the current state of the data or a ‘blank’ state which can indicate that the data is not available in the service.
If the service supports publishing deltas, then an image-on-subscribe capability also is needed. The term ‘delta’ describes only publishing changes in the data, not the complete image. This can provide substantial network bandwidth savings as, in general, not all attributes of an entity change all the time. The image-on-subscribe concept refers to the client receiving the initial image of the data entity as its first update and then after this only receiving the deltas. The deltas can be applied on top of the initial image to resolve the current state of the data entity. All messages published for a data entity will need a sequence number. This allows the client to detect any out-of-order messages and is also critical to being able to apply deltas on top of the received image. The image itself must have a sequence that can be identified within a stream of delta messages for the entity. The same delta message can be received by multiple clients.
The subscribe-publish pattern is essential when a service can have a potentially large data universe and expects that at any point in time only a portion of the universe will be subscribed for by clients. This makes the network utilisation more efficient and allows the service to conserve its resources.
Request-response.
A request-response pattern provides the capability for a client to be able to receive a response to a request sent to the service. In general, the service response is only directed at the requesting client; other clients do not see the response message. This access pattern is typically used for clients to invoke functions on services. The request message identifies the function to invoke along with any arguments for the function. The response from the service will contain the result from invoking the function. However, this access pattern can also be used to request images or receive on-shot data upon request by the client.
This pattern requires some form of timeout logic in the client. When a client sends a request it generally starts a countdown for a response. If the response does not arrive within the countdown the client determines that the request has failed. This is a basic way to handle the request timings. An improvement is for the service to send back a signal when it receives the message, another signal when it starts to process the message and then finally send the response. If the client has a separate countdown for each of these phases in the request-response then more fine-grain control is achievable and timeout situations can be tuned out. As an example, if a service takes 0.2 seconds to process a message but, due to the number of requests, each request takes 0.9 seconds before it starts to be processed, then a client with a simple 1 second timeout would fail each request (each request would appear to take 1.1 seconds). However, if the client observed a 1 second start timeout and a 0.5 second processing timeout then the requests would succeed.
Data Format.
The service access protocol also defines what the data looks like, its format. This is very important so that the data is universally understandable by all connecting clients. Translating between data formats is costly, in terms of development and maintenance timescales and runtime processing resources. Therefore a critical aspect for all services is to have a common data format.
Data format defines the rules for how the data is structured and the type of the data values. The structure defines how to understand what the data is representing. If the structure is understood, then the data values can be interpreted in the correct context, e. g. the value 123.45 can be correctly interpreted as the bid price, say, rather than the ask price, because the structure is understood. Generally, data structures fall into one of these categories:
dictionary – this is the key-value structure where every data value is identified with a unique key. This type of structure is very fast for reading and writing sparse data. Sending data changes (deltas) is most efficient when the structure is dictionary-based. hierarchy – data is expressed in a hierarchical manner, e. g. XML. It is generally quite verbose. Data structures that are hierachy-based tend to be more complex to process then dictionary-based ones and are not as fast as a dictionary-based equivalent.
There is a hybrid category where a dictionary-based structure uses hierarchy within the keys to achieve a middle-ground solution. As an example, keys can be “.” separated to provide for an address space like, “foo. bar.1”, “foo. bar.2”, say.
Regardless of the data structure, there has to be a defined range of types that the data values can express. The types allow the data to be interpreted in its correct form, e. g. a string or a number or a binary stream. The basic data types that need to be supported are:
text floating-point numbers integer numbers binary stream images (blobs)
Supporting these 4 data types allows for any real-world data value to be correctly represented.
Service Platform Features.
The data access protocol for a service is supported by some form of messaging technology. However, messaging technology only solves the “plumbing” problem of how to get data from one endpoint to another. The service infrastructure for bond trading requires more than just messaging technology for a common service access protocol, it also needs the capability for:
discovery and monitoring of services – allows functionality to be controlled depending on availability of business services discovery of data available from services – allows functionality to react when specific data is ready discovery of when clients subscribe for data – allows resources to be activated only when there is a need to support a client subscription (e. g. starting data feeds only when a client starts a subscription for the feed) inspection of service state – allows support teams to be able to know when a service is in trouble and take action to fix it viewing of data in a service – allows support teams to be able to diagnose data problems by viewing the data at source permissioning of data – supports data security/fee requirements by preventing unauthorised clients from receiving data controlling data publishing rates (throttling) – protects the environment from high publish rates that can overload clients and hardware resources remote control of services – provides the capability to change service status and settings without needing to disrupt the service high-availability for services – replaces a service that stops unexpectedly with a backup service.
All these capabilities should be provided by a common framework that all services are built upon. This common framework is the service platform . By designing a framework that has these features and supports services and clients that use the same messaging technology, a truly robust and extensible technology solution platform is provided for bond trading.
Why use a service platform?
It is possible to have all the capabilities listed above by not using a service platform, however the features tend to be retro-fitted onto existing designs, sometimes only being applied to certain services, othertimes different technologies are used for the same feature in different services. Eventually the service landscape becomes a heterogeneous mix-n-match of different designs and technologies that ultimately may provide the core features of a service platform but at the expense of unified architecture and increase maintenance costs. Using a service platform to build a bond trading system provides reduced development and maintenance costs and timescales; development can focus on the business logic of the services/clients rather than the infrastructure concerns.
The diagram below helps to illustrate how using a service platform architecture simplifies the access to services. With a service platform, clients only need a single interface to access all services, whereas a non service platform design requires the client to use a different interface depending on the service being accessed. A separate interface per service introduces complexity because, generally, the interfaces use different technologies which increases the resources required for development and maintenance.
A service platform also benefits the user-interface design of a bond trading system. The user-interface (UI) is usually a grouping of various visual displays and controls across different services. If all the services share the same messaging technology and data structure then the UI components become standard across all services. Specialised versions can be created that exist purely for business reasons rather than technical and ultimately all components share a common interface pattern to the business services.
In closing…
This article has introduced the concept of the service platform and highlighted its architectural importance. Building a service platform is not a trivial undertaking. There are only a few commercially available options and even fewer open-source ones. The ClearConnect platform is an open-source example that provides all the capabilities described in this article. This platform will be used as a reference platform for building examples of the services in later articles.