Предимства на брокер на компонент на услугите

Използването на средства за обслужване Брокер приложения на база данни компонент, приготвен редица съществени предимства. Сред тези средства и ползи включват:

• интеграция Database подобрява производителността на приложенията и опростяването на административните процедури.
  
• Усъвършенстване на комуникацията и координацията опростява процеса на разработване на приложение
  
• Свободните приложения свързване осигурява гъвкаво управление на натоварването.
  
• Заключете свързаните съобщения позволява на множество копия на приложения за обработка на съобщения от опашката без изрично синхронизация.
  
• Благодарение на автоматичното активиране на заявлението може да се мащабира в зависимост от броя на съобщенията.
  

Благодарение на интегрираната структура на Service Broker увеличава производителността на приложенията и по-лесно администриране.

Интеграция с SQL Server позволява транзакциите съобщения без да се увеличава режийните разходи и без усложненията, които възникват в случай на външна Разпределени координатор на транзакциите. Заявление получава едно или повече съобщения, обработва съобщението или съобщения, и предава съобщение за отговор в рамките на една-единствена сделка база данни. Ако е налице неизпълнение на сделката, всички операции са отменени и на полученото съобщение се връщат на мястото, което го прави възможно да се направи още един опит да се справя. Никакви действия не може да влезе в сила до момента, когато заявлението не заключва сделката. Заявлението остава в стабилно състояние.

С традиционните системи за съобщения може да възникне загуба на съгласуваност като магазин съобщение и база данни. Например, когато един компонент се възстанови от резервно копие, а другият компонент също трябва да бъдат възстановени от резервно копие, взето в същото време, в противен случай съдържанието на паметта за съобщения ще престанат да отговарят на данните от базата данни. Компонент Service Broker съхранява съобщенията и данни в същата база данни, така че проблеми с последователността не е там.

Друго предимство, предоставени от интеграцията на базата данни - това е една обща среда за разработка. Различните части на приложението, което обработи съобщението и данните могат да използват едни и същи инструменти езикови и SQL Server, приложение Service Broker. Това дава възможност за организиране на работата по програмиране на съобщението обработка модули използват факта, че възложителят е запознат с техники за програмиране на бази данни. Прилагане Service Broker е съхранена процедура може да се запише в Transact-SQL език или на един от езиците на CLR. Инсталираният софтуер е базата данни, използвана Transact-SQL база данни и програмни интерфейси известни данни, като ADO.NET.

В допълнение, интеграцията на базата данни ви позволява да управлявате ресурси в автоматичен режим. Service Broker се извършва в контекста на инстанция на SQL Server, така че Service Broker следи всички съобщения готови да прехвърли всички бази данни, например. Ето защо, всички бази данни могат да поддържат собствената си опашка и в същото време насърчават компонент Service Broker при решаването на проблема с използването на ресурси в цяла например SQL сървър.

В традиционните системи за съобщения, които отговарят за поръчване и координиране на съобщения, които могат да действат по неподходящ начин, се възлага на съответното приложение. Например, приложение А изпраща съобщение 1, 2 и 3. Приложение Б получава съобщението 1 и 3, и потвърждава получаването им, но грешката мнения за пренос 2 случи. Приложение A повторно предава посланието 2, а сега това е получено съобщение, след съобщенията, 1 и 3. В миналото, на разположение на разработчиците са два начина за решаване на проблема: или да пишат приложения, така че да пристигат съобщения разпореждането не е от значение, или да публикуват съобщение 3 до временен кеш преди да влязат в съобщението 2, така че приложението може да обработва съобщенията в правилния ред. Както първа и втора решения не са нито ефективни, нито лесно.

За традиционните системи се характеризират с още един проблем: дублирането на доставка. Връщайки се към предишния пример. Ако заявлението Б получава съобщението 2, но признание е насочено към Приложение А, загубен, Приложение А препредава съобщение 2, така че приложение Б трябва да получи съобщението два пъти. Ето защо, кодът за кандидатстване е необходимо да се напише по такъв начин, че то е било предизвикан и изхвърлете размножаване или преиздаване третира два пъти предава съобщение, без никакви странични ефекти. Отново, както на тези подходи е трудно да се приложат.

Координация на комуникациите е традиционно нерешим проблем. Например, едно приложение може да изпрати услуга стотици или дори хиляди заявки. Час извършва паралелна обработка на тези искания и връща отговор веднага след приключване на обработката на съответното искане. Поради факта, че различно време се изразходва за преработка на различни искания, приложението получава отговорите не са в реда, в който го насочва изходящите искания. Но прилагането може да осигури правилни отговори за лечение само в случай, ако тя може правилно да свърже всеки отговор със съответния оригиналното съобщение. В конвенционалните системи, сдружение за съобщения се извършва с помощта на приложението, което води до по-високи разходи и по-голяма сложност на разработване на приложения.

, Service Broker решава този проблем, като предоставя автоматично подреждане на съобщенията, доставка, без дубликати, както и идентифициране на диалозите. След установяването на диалог между двете крайни точки на приложение Service Broker получава всяко съобщение само веднъж и в реда, в който са били предадени на тези съобщения. Заявления могат да обработват съобщенията не повече от веднъж по подходящ начин, и не се изисква допълнителен код. И накрая, Service Broker компонент се включва автоматично на всеки идентификатор на съобщение. Заявленията винаги имат информация за това коя диалог, в който дадено съобщение.

Възможността за които са опашки също допринася за по-равномерно разпределение на задачите за обработка, което намалява пиковите изискванията за мощност на сървъри. Това дава възможност за увеличаване на пропускателната способност и изпълнение на приложения за бази данни. Така например, в определени часове на деня броят на сделките, обработвани от много приложения за бази данни, увеличава драстично, което води до увеличаване на консумацията на ресурси и да се намали времето за реакция. С появата на приложение Service Broker, че вече не е необходимо да се извърши всички операции по обработка на търговска сделка, когато го изпратите на заявлението. Сега това приложение чрез услуга Broker ще изпраща информация за приложните програми сделка, извършващи обработка на заден план. Тези приложения за определен период от време да извършат цялостна обработка на транзакцията, и разположението на "входа" Основната заявление продължава да получава нови бизнес сделки.

Ако дестинацията не е на разположение в този момент, съобщението остава в изпращането на предаване на база данни на опашката. Компонент Service Broker извършва повторен опит до тогава, докато съобщението се изпрати успешно, или преди изтичането на поддържането на диалог, който ще продължи силен диалог между двете служби, дори и ако в някакъв момент в хода на този диалог е една от услуги ще бъдат временно недостъпни. Съдържа се в опашката за предаване на съобщения, са част от базата данни. Service Broker компонент доставя съобщението дори и в случай на срив или за подновяването на това копие.

Един от най-големите предизвикателства пред които са изправени потребителите на традиционните системи за съобщения, е как да се гарантира, успоредно лечение на множество програми за една и съща линия. Когато в една и съща линия на традиционните системи за съобщения отваряте няколко програми или нишки, съобщения могат да бъдат преработени в случаен ред. , Service Broker не позволява такива ситуации, като заключите диалозите на групата.

Нека да видим как традиционната заявлението за обработка на поръчките. На свой ред, е действал като послание А, съдържащ инструкции за образуване на заглавната част на поръчката, и съобщение В, съдържащ инструкции за това как да се създаде ред линии на елементи. Ако и двете от тези съобщения се изтеглят от опашката по различни случаи и приложения, се обработват в същото време на сделката е да се гарантира създаването на елементи от ред линии могат да бъдат представени за първи запис и не може да се осъществи, тъй като поръчката все още не съществува. Този неуспех, от своя страна, ще доведе до намаление на цените на сделката, съобщението ще се върнем към опашката и ще бъдат повторно обработени, което ще доведе до загуба на ресурси. Традиционно програмисти са решили този проблем чрез комбиниране на данни от съобщението от постовете на А и Б в едно съобщение. Ако се налага да се справят с две съобщения, този подход е ефективен, но когато става въпрос за системи, координиращи десетки или стотици съобщения, едва ли може да се разчита.

, Service Broker решава този проблем, чрез комбиниране на свързаните с диалози в групата за диалог. Service Broker е автоматично блокира всички съобщения в една и съща група диалози, така че тези съобщения могат да се приемат и обработват от едно приложение, например. В същото време, други случаи на задействането могат да продължат да бъдат отстранени от посланията на опашката и обработват от други групи диалози. Това дава възможност за надеждна и ефективна работа на множество едновременни случаи на задействането и премахване на необходимостта от включване на сложни кодове за кандидатстване за заключване.

Един от най-полезните функции на услугата Broker - е активирана. Активиране позволява на приложенията за динамично самата преоразмеряване, когато промените на броя на опашката за входящи съобщения. Service Broker е оборудван със средства за двете програми, работещи вътре в базата данни и програми, работещи извън базата данни, за да се възползват от предимствата на активиране. Въпреки това, Service Broker не изисква прилагането на задължително използване на функцията за активиране.

, Service Broker следи събитията се редят на опашка, за да се определи дали полученото съобщение до всички диалогови прозорци на приложения, които са налични мнения. Активиране на услугата посредник започва Queue Reader представител в случаите, когато агентът има работа. За да се определи дали работата е за Queue Reader агент, Service Broker компонент следи опашката за събитие. Когато броят на управлението на агент Queue Reader е пропорционална на входящия трафик, като се създава ситуация на опашката периодично или в които няма съобщения от опашката или всички съобщения в опашката принадлежат към диалог, който в момента се обработват от друг Queue Reader Agent. Ако за известно време всичко не попадат в тази ситуация, Service Broker компонент активира друг вариант на приложението.

процедура за активиране се изпълнява по различни начини в приложенията, в зависимост от това дали става дума за програми, които работят вътре в базата данни, или програмите, изпълнявани извън базата данни. За програми, които се изпълняват в рамките на базата данни, Service Broker компонент стартира друго копие съхранена процедура дадена опашка. За програми, които работят извън базата данни, Service Broker създава елемент на събитието на активиране. Програмата следи събитието, за да се определи, когато трябва да се свързва с друга опашка Reader Agent.

Service Broker не се спира изпълнението на програмите, работещи с помощта на процедурата за активиране. Фактът, че активирани приложения се затварят автоматично след определен период от време след последното им съобщение е получено. Тя е написана по такъв начин, прилагането динамично увеличаване и намаляване броя на своите копия в зависимост от промените в обема на трафика, идващи до услугата. Освен това, ако системата се изключва или рестартира, по време на повторното започне прилагането на системата за четене на съобщения в опашката ще започне автоматично.

Традиционните системи за съобщения не са надарени с такива възможности, а в хода на работата им, има случаи, когато, във всеки един момент за дадена опашка се разпределят или твърде много или твърде малко ресурси.