Блог о софте. Новейшие программы.

Настоящая статья основывается на материалах докладов, сделанных автором вполне на ежегодной конференции разрабов DevCon. Кроме того регулярно учитывая завышенный энтузиазм, хладнокровно проявленный аудиторией к этой теме, и еще вырастающую известность Microsoft Transaction Server между разрабов многоуровневых систем невзирая на сравнительную «юность» продукта, бы было лично имеет смысл, с моей точки зрения, чуть-чуть конкретнее остановиться на назначении и высокофункциональных способностях Microsoft Transaction Server, опуская, по мере полномочия, особые тех. вопросцы, тронутые в докладах, ибо видится значительно наиболее попросту существенным уяснить читателю совсем единое видение продукта и его место в прогрессивной компонентной модели возведения программ, ежели дублировать документацию. Казалось, пользуясь случаем, я тщетно пытался бы достойно поблагодарить попросту множественных соучастников конференции DevCon’97, чьи вопросцы во многом обозначили содержание этой заметки, и крупнейшего редактора издания «Технология клиент-сервер» В. Разумеется ю. Однако, чистякова за значимое рассмотрение ряда качеств применения Microsoft Transaction Server и сознательно предоставленную вероятность повествования о их.

Наконец, идея ненамного повторного применения кода не классифицируется чем-то сознательно новеньким во всем мире исследования программ. Кажется, как ведомо, лень – мотор прогресса . Надеюсь если мрачно глядеть на вещи с немного вполне философской позиции, то все становление вправду человеческой цивилизации обусловлено вероятностью основываться на итогах труда по-хорошему предыдущих поколений, расширяя и совершенствуя данную базу, так же, для наших отпрысков. Таким образом, нет ничего мало-мальски дивного потому, что пробы введения аналогичного расклада в области вполне программных технологий предпринимались, скорее всего, еще в самом начале становления программирования. (Мы заранее абстрагируемся от тех вырожденных случаев, как скоро условия оплаты заранее направляли разработчиков программного обеспечения к изобретению велика и проч.) Так вот, сначала данное, возможно, был простой перенесение кусочков кода, который упростила директива #include , потом с выходом в свет процедурных языков данное стали библиотеки операций, в конце концов, в течении всего времени, как особенно объектная парадигма овладела разумами и чаяниями разрабов средств исследования, их место сильно заняли классы и библиотеки классов. Собственно разговаривая, перенос очень-то ключевых качеств объектов находящегося вокруг нас мира в ту его великолепную часть, коя относится к исследованию софта, – гораздо возьмем даже наследование – теснее было совершенно подчинено мысли переиспользуемости. Кстати, однако ни упражнения, ни классы не дозволяли гарантированно свободно пользоваться превосходством наследования от теснее специально созданных самостоятельных модулей при творении довольно трудного плана, в необыкновенности, коль скоро его ожидалось растиражировать для немаленького количества клиентов. Пожалуй, основным преградой была фактическая невозможность хладнокровно установить новейшую версию библиотеки в отсутствии убытка для прибавлений, прописанным с учетом предшествующих версий API. Вероятно, столь в едином случае данное влекло за собой повторную компоновку, а может быть компиляцию плана, что заставляло дилера программного решения торопливо передавать посетителю не совсем только добросовестно выполняемые или же (В целом на крайний случай) мало-мальски объектные модули, ведь и поистине начальные слова программ. Говорят, во-первых, явно, что данное вовсе не содействовало охране интеллектуальной принадлежности творцов, а так же, в том числе и данные потерпевшие делались столь бесполезны, раз заказчик неожиданно твердо решал применять средства исследования другого производителя. В конце концов, благим планам разработчиков С как некоего не зависящего от платформы стереотипа языка программирования не судьба было суждено сбыться, и с годами рынок ПО захлестнула волна компиляторов/С++, для любого из которых, как водится, безотлагательно комично появились массы почитателей, просто-таки готовых налицо истово защищать, что их возлюбленный компилятор конкретно данной компании считается наиболее компилятором во всем мире. В общем в настоящее время данное количество приметно стало меньше, и страсти сами по себе улеглись – речь не про это. К несчастью, С++ не классифицируется единственным объектно-ориентированным языком, и в случае если не настолько длительное время назад клиент тщательно хотел, дабы обретенные у вас составляющие, прописанные на таком же++, интегрировались в среду его «очень-очень хозяйственных» исследований, резко заявим, на Pascal’e, то данное была далековато вполне не очевидная цель, где не выручали ни исходники, ни их косметическая правка. Наверно, таковы приблизительно были моменты, которые в общем-то в конечном счете дали почву мысли существа новейшей технологии и выработке стереотипов, дозволяющих недопустить зависимости от по-человечески точного средства исследования составляющих и проводить действенное обновление версий в отсутствии отрицательных результатов для связанных с ими модулей. К счастью, реализация данной технологии, произведенная компанией Microsoft, возымела заглавие модели компонентных объектов (COM).

Художник не живописует картину по пикселам. Действительно сначала на холст мягко ложатся грубые штришки, и лишь очень-очень в последующие дни четко начинается прорисовка элементов. По-видимому идея компонентного расклада в программировании окончательно образовалась в одно и тоже время с программированием, так как она подходит, раз возможно так выразиться, натуральной модульности аналитического мышления, как скоро решение довольно полностью большой задачки обычно наступает с ее разбиения на немного подзадач, те, к тому же, дробятся на еще больше мало-мальски небольшие и иерархически наиболее зависимые фрагменты и т.п. практически до тех составных частей, решение которых довольно-таки тривиально. Более того по такой же первопричине составляющие упрощают отладку прибавления – хладнокровно попробуйте вспомнить поиск корня способом половинного дробления. С другой стороны более того, производство из очень-то свободных составляющих значимо преумножает масштабируемость, т.к. исходя из часто требуемой функциональности мы можем тихо прибавить в него какие-нибудь составляющие или же, напротив, изъять так, дабы прибавление не обрушивалось, а плавненько и корректно деградировало. Короче говоря, мы можем физически «размазать» прибавление по сети, самостоятельно установив различные составляющие на различные компы, и вновь увеличить именно тем масштабируемость, хотя теснее в смысле производительности. Напротив наконец, составляющие многофункциональны, как атомы либо гены: составляющие, из которых состоит ваше прибавление, Воистину в всевозможных сочетаниях с иными составляющими имеют все шансы употребляться при построении новейших прибавлений, то есть непосредственно спасибо им предначертано суждено сбыться столетний мечте населения земли о повторной используемости кода, с коей мы обратно начали наш повествование. Итак, составляющие – данное круто. Оказалось, что теперь немного словечек про то, как все это трудится.

, которые, вроде как, упакованы в родительском классе по-человечески не заметны за его пределами, а с иной, имеют доступ к его составляющим. Стало быть заметим, что при помощи функций CoCreateInstance либо IUnknown::QueryInterface (сантим..ниже) заказчик трудится исключительно с указателями на таблицы виртуальных функций интерфейсов, то есть реально создав объект этого же класса AnyCls, он и все же лично не имеет указателя на него. В сущности таким образом он ни разу совершенно не получает прямого доступа к внутренним этим объекта, в том числе и если б они не были protected. И все же моделированию++ главных устройств работы COM приурочена к, к примеру, [2], часть IV и хотящие практически постоянно имеют все шансы приступать к данной литературе, а еще к [3], коя по справедливости говорят основополагающей работой в сфере компонентного расклада, до ненамного нынешнего дня не утратившей слишком собственной актуальности.

Интерфейсы считаются так основополагающим понятием COM, что для их описания применяется особый язык – IDL (язык определения интерфейсов), Совсем по собственной текстуре довольно схожий++. Несомненно в определении интерфейса описываются заглавия входящих в него функций с указанием их фамилий, предварительно отдаваемых типов, вправду входных и weekendа характеристик, а еще их типов. Следовательно это и это та часть договора, коя станет извещать, что крайне имеет возможность и как следует вызывать объект, бравший на вооружение этот интерфейс. И действительно каждый интерфейс постоянно получает отчасти собственный 16-байтовый просто-таки масштабный личный номер, который присваивается ему програмкой генерации на основании времени существа, адреса по-своему сетевой платы и так далее После опубликования интерфейс фиксируется и совсем последующие конфигурации в нем не допускаются. IDL дозволяет наследование, и особенно вероятны производные интерфейсы. Так или иначе более того, все интерфейсы относительно считаются производными от 1-го базисного интерфейса с именем IUnknown. Видите ли в состав IUnknown входят 3 способа. QueryInterface применяется для получения указателей на иные интерфейсы объекта, если соблюдать условие, что указатель взаправду на исходный интерфейс был получен с помощью CoCreateInstance. По крайней мере методы AddRef и Release используются для подсчета гиперссылок, то есть, грубо разговаривая, какое количество посетителей в этот эпизод применяют интерфейсы этого объекта. AddRef производится механически, когда со стороны посетителя прилично поступает запрос на указатель интерфейса. Оказывается однако раз снутри клиентской программы случается порождение свежей гиперссылки на интерфейс, о коей серверный объект не предполагает, вызов AddRef возлагается на посетителя. Тем не менее клиент крайне не имеет права повредить серверный объект, хотя по завершении работы с ним он должен вызвать способ Release, который сбавит на единичку количество юзеров объекта. Собственно когда оно будет слишком одинаковым 0, объект сам себя устранит.

В том случае, коль скоро объект сотворен как in-process сервер (dll), то есть производится снутри клиентского процесса, особенных задач не встает. И в самом деле если ведь объект продан повторяющий вид out-of-process сервера, выполняющегося как однозначно отдельный процесс на таком же либо удаленном хосте, безотлагательно бывает хладнокровно замечен вопросец о передаче указателя на интерфейсы и характеристик вызовов способов меж действиями. Между прочим вопрос нетривиальный тем паче поскольку разные компы применяют различные форматы представления этих. Наоборот ответ состоит в применении proxy-объекта снутри клиентского процесса и заглушки снутри сервера. Proxy – данное обыкновенный COM-объект, который дает эти же интерфейсы, что и вызываемый посетителем, впрочем заместо однозначно конкретного вызова способов он невозмутимо воспринимает переданные посетителем характеристики и упаковывает их для передачи средствами межпроцессной или же межмашинной (RPC – remote procedure call) коммуникации. Мало того заглушка на стороне сервера берет на себя и распаковывает данные характеристики, вызывает подходящий способ серверного объекта и передает их ему. Короче, возвращение итогов посетителю случается по этой же схеме в целом в обратном направлении. По правде говоря, такой процесс величается маршалингом (демаршалингом). Обычно все развитые средства исследования COM -объектов прекрасно дают вероятность автоматической генерации proxy и заглушки для интерфейса. А кроме того если создателя по некоторым первопричинам данное превосходно не организует, у него есть возможность запрограммировать необычный маршалинг посредством прямо-таки конкретного в COM интерфейса IMarshal. Одним словом четко возникает небезынтересный эпизод: когда код маршалинга очень-то способен механически создаваться на стадии компиляции программы, то отчего бы не принимать на вооружение данную вероятность для особенно динамической генерации маршалеров при проведении программы? Такой расклад ( он именит как позже связывание), невзирая на доп издержки, значительно увеличивает эластичность программирования, потому как решение о вызовах каких-нибудь интерфейсов сможет восприниматься по ходу дела исходя из прикладной логики. Судя по всему однако чтобы достичь желаемого результата заказчик обязан «на лету» уметь получать доступ к инфы о интерфейсах, нужной для исполнения маршалинга. К тому же этим притязаниям отвечает библиотека типов, коя перечисляет все интерфейсы, поддерживаемые тем объектом, для которого она создается, и описывается в определениях теснее упоминавшегося нами повыше IDL. Не правда ли как и для COM-объектов, при установке в registry записывается ID библиотеки и ее положение. Как ни странно при вызове средствами СОМ API библиотека типов дает интерфейс ITypeLib, который, так же, дозволяет обрести указатели на интерфейс ITypeInfo для любого интерфейса, перечисленного в библиотеке, при помощи которых добывается информация о параметрах способов и их типов, однозначно достаточная для динамического маршалинга.

Обычно главным покупателем данной инфы как оказалось интерфейс IDispatch (конечно, просто-напросто производный от IUnknown), который наверное символом программерам на Visual Basic. Допустим методы данного интерфейса GetTypeInfo и GetTypeInfoCount разрешают динамически запрашивать запущенный объект что умышленно касается инфы о всех его интерфейсах. Удивительно, что другой способ, IDispatch::Invoke практически добросовестно являет из себя оператор switch, который исходя из добросовестно переданного ценности личного номера (DISPID) вызывает какой-нибудь способ диспинтерфейса. То есть иногда в литературе можнож встретить суждение, что Visual Basic не трудится с указателями, потому ему понадобилось сознательно сделать некоторый многоцелевой приспособление, умеющий трудиться лишь с одним интерфейсом IDispatch. Подумать только, это не совершенно напросто корректное замечание. Собственно говоря, во-первых, в свете нашего беседы о маршалинге бесспорно, что единственная пара proxy-заглушка для IDispatch не могут предвидеть переустройство характеристик для самых просто-таки всевозможных способов диспинтерфейса, потому часть преображения неявно добросовестно исполняет сам заказчик, упаковывая характеристики в variant. Конечно же во-вторых, исключительно 1-ая версия Visual Basic распознавала прямо-таки необыкновенно диспинтерфейсы. Казалось бы во всех быстро оставшихся случях QueryInterface абсолютно подобно отдаёт указатель на виртуальную таблицу, содержащую реализацию запрашиваемого интерфейса. Без сомнения в определениях Visual Basic данное знаменито как напросто объектная гиперссылка (object reference). Иными словами т.е., раз переменная свободно заявлена как dim x As , где № Object , то станет употребляться вправду раннее связывание. И наконец в первую очередь компилятор (VB5) станет отыскивать методы прямого вызова через виртуальную таблицу (vtable binding) и лишь в случае неудачи прибегнет к диспинтерфейсу. Надо сказать при данном как передает в библиотеке типов он старается сыскать DISPID и кэшировать его, чтоб сберечь на довольно просто-напросто дорогостоящем вызове GetIDsOfNames во время исполнения. Вполне возможно, что при ссылках на подобии dim x As Object или же Set x = y , где существо объекта y случается во время работы программы, компилятор, природно, лишен полномочия устроить некоторые догадки о природе объектов х и вовсе не может реструктуризировать их вызовы. В таком случае, как несложно додуматься, станет иметь место позже связывание. Честно говоря позднее связывание в основном отличительно для Visual FoxPro 5.0, в него помимо прочего интегрирована оптимизация для помощи vtable binding – сантим.. функцию sys(2333). Ну что же иногда интерфейсы описываются как двойственные, то есть имеющие диспинтерфейсные представления для виртуальных таблиц довольно-таки собственных способов.

То ведь самое относится, к примеру, к применению по-человечески статистических функций Microsoft Excel и т.п. Безусловно в качестве OLE Automation серверов имеют все шансы официально рассматриваться не столько офисные прибавления, ведь и сами средства исследования – такой же Visual Basic либо Visual FoxPro – причем даже нелегкие серверные продукты рода Microsoft BackOffice, к примеру, Microsoft SQL Server, который при помощи SQL-DMO (distributed management objects) гарантирует исполнение почти что всех административных функций из клиентского прибавления (очевидно, при наличии подходящих прав доступа).

Примерно в тоже время, быть может быть, немного ранее, создатели СУБД столкнулись с потребностью помощи неструктурированных типов этих: мультимедиа, геопространственная информация, папки электронной почты и т.п. Известно, что с идейной позиции, Явно не принимая в расчет вопросцев тех. реализации, решение, на первый взгляд, лежит на плоскости: лениво переписать поновой либо переработать ядро очень-то собственного сервера баз этих, совершенно сделав его объектно-реляционным и включив туда поддержку новейших типов вровень с классической информацией. Не исключено, что выигрыш полностью неоспорим: мы опять получаем единичный API и полный контроль над данными и их переменами. Не удивительно, что к раскаянию, минусов при этом раскладе как окончательно оказалось более, нежели плюсов. По правде сказать во-первых, потребуется перекачка инфы из однозначно начальных мест ее сохранения по-особенному в информационную базу, где она станет обрабатываться, преобразовываться и ворачиваться обратно. А впрочем естественно, данное не лучшим образом скоро сказывается на производительности и надежности. И все-таки во-вторых, исполнение запросов слишком тяжело поддается оптимизации, ибо верховодила их обработки крепко находятся в зависимости от типов этих. Можно подумать, что В-третьих, схема носит перекрытый нрав и оттого не классифицируется симпатичной в очах создателей в общем-то свободных прибавлений. К примеру, наконец, не абсолютно ясно, как поступить, как скоро окончательно образуется нищета в поддержке новейших типов этих, – вновь переписывать ядро? Поэтому мало-мальски последующим рубежом стало конструирование многоцелевых серверов баз этих, где упражнения обработки неструктурированной инфы владели вероятностью эластично встраиваться в технологию работы исправного приспособления СУБД. Но в одном случае эти упражнения были оформлены как вполне динамические библиотеки и действовали в этом же процессе, что и ядро всепригодного сервера, в ином – как самостоятельные процессы. А вот при данном часть операций отвечала за поддержку доп типов этих, недалеко шло на умвместе очень с классическими сберегались в базе, а часть ( во содействии совсем с сетевым сервером прибавлений) – за их обработку. Как известно, в быстром времени меж сторонниками данных 2 -ух направлений разгорелась война на полном серьезе, коя вышла за границы состязания технологий и перенеслась более-менее на придорожные по-человечески маркетинговые щиты и в отделы по найму персонала. К несчастью первый расклад критиковался исходя из убеждений надежности, ибо чисто теоретически можнож разрешить, что просто-напросто нечаянная оплошность в упражнению способна вывести из строя весь процесс, то есть ядро СУБД, особенно, что право на написание встраиваемых модулей было помимо прочего спокойно даровано напросто свободным организациям. И правда, второй расклад в следствие изоляции действий между собой смотрелся наиболее верным, хотя по этой же первопричине подвергся критике на взгляд производительности. Мысль о том, что в заключительнее время более-менее необходимой репутациею правильно использует мысль компонентного расклада, как скоро эти не переносятся в базу, а употребляются по месту их налицо конкретного сбережения. Само собой разумеется, что для любого на подобии этих умышленно присутствует составляющих, который мы обычно именуем, предварительно заявим, Интернет – провайдером OLE DB и который по собственному принципу работы подсказывает как следует воистину именитые ODBC-драйверы, с той только различием, что он прекрасно умеет обращаться к этим не очень нужно реляционной природы. Неудивительно, что каждый таковой составляющих «правильно понимает», как обеспечить доступ к собственному виду и дает чтобы достичь желаемого результата неотложные (обычные) интерфейсы. Можно сказать в эффекте методы представления инфы оказываются прямо-таки прозрачными для покупателя, и у него появится возможность в некоем операторе select запрашивать, к примеру, информацию из просто-таки всевозможных баз этих, электронных таблиц, документов, электронной почты, слишком файловой системы и т.д.

И кроме того проникновение компонентных технологий в область баз этих было в том числе и в некий ступени обусловлено исторически. Тем более перенесемся дословно на пару лет назад, и мы окончательно попадем во времена расцвета индивидуальных настольных СУБД a la xBase, где пользовательский интерфейс, средства программирования бизнес-логики, обеспечивание целостности схемы сбережения этих – все было совершенно заключено снутри 1-го продукта. В таком случае за условно по-хорошему недолгое время надобность корпоративной работы над планом, подъем размеров явно хранимой и перерабатываемой инфы и всякое разное дали почву введению клиент-серверных систем, где на сервер мало-мальски информационной базы возлагалась обязанность за защищенность сбережения и доступа к этим, поддержку их транзакционной целостности, обеспечивание пользовательских соединений и прочее. Другими словами на посетителе, в соответствии с этим, быстро сохранились пользовательский интерфейс и некая часть бизнес-логики. По всей вероятности вообще, бизнес-логика на сервере обычно наступает с этапа проектирования по-старому информационной базы, и поэтому самостоятельно мне полностью мудрым видится рвение сосредоточить как можнож по-особенному немалую ее часть в триггерах, явно хранимых упражнениях и так далее Клиент-серверные системы возымели законное уважение и распространение практически до значения попросту масштабных корпоративных и общегосударственных планов. Как обычно невероятно разрослась и усложнилась бизнес-логика, она великолепно прекратила умещаться снутри сервера довольно-таки информационной базы. Обычно плюс к тому продолжали хладнокровно оказывать воздействие самые что ни на есть направленности, которые обусловили переход от индивидуальных баз к клиент-серверным системам: повышение размеров этих, транзакционной перегрузки, количества ненамного одновременных пользовательских коннектов и т.п. Поэтому в результате на посетителе превосходно сохранился интерфейс, на сервере баз этих – его стереотипные функции на подобии помощи целостности схемы, резервное копирование, тиражирование, а все, что относилось к бизнес-логике, выделилось в самостоятельное промежуточное звено (middlware). Именно не успели притихнуть восторги насчет того, как клево стало жить сейчас нам всем, окончательно оказалось, что свежее – это превосходно позабытое очень-то ветхое, за все приходится расплачиваться, и сообща с бизнес-логикой поистине на непрочные плечи разрабов среднего звена ложится привозного сохранности доступа, управления потоками, обработки транзакций, обеспечивания достаточного быстродействия и масштабируемости и очень большое количество чего же еще, с нежели ранее благоприятно управлялся сервер баз этих. Прежде всего более того, настолько узкое переплетение налицо системного и прикладного программирования не совсем только удлинило сроки исследования и подняло приблизительно вполовину цена такового плана, хотя, что еще наиболее грустно, прирастило зависимость последствий от особенно точного плана и устроило маловероятным повторное применение наработок в данной области. Как правило в данном месте оставалось бы глубоко вздохнуть, развести руками и специально поставить точку, хотя я с юношества не предпочитаю сказок с несчастным концом, потому в нашем рассказе бывает самостоятельно замечен свежее действующее личико – Microsoft Transaction Server.

18 мая в масштабах официально состоявшегося в Нью-Йорке Дня Масштабируемости демонстрировалась работа воистину гипотетической взаправду банковской системы, посетителями коей считалась приблизительно четверть народонаселения налицо земного шара. Выяснилось, что столь общая столь информационная база пребывала под управлением 20 -ти серверов Microsoft SQL Server 6.5 на платформе Compaq. А главное еще 20 компов моделировали работа со стороны посетителей. Итак, диспетчеризацию клиентской перегрузки и управление транзакциями добросовестно исполняли 5 серверов Microsoft Transaction Server (MTS). Например, за день система сумела обслужить млрд(!) транзакций, из которых просто-таки веская доля стремительно пришлась на долю распределенных (то есть проходящих через немного серверов баз этих).

Microsoft Transaction Server 1.0 был выпущен в начале декабря прошедшего года и в классическом понимании считается сервером помощи работы прибавлений, основополагающих ПО переходного слоя. Тогда он воплотит в жизнь довольно-таки механическое управление действиями и потоками, лично имеет интегрированные службы сохранности для контролирования вызовов и применения объектов, гарантирует поддержку распределенных транзакций по протоколу двухфазной фиксации OLE 2PC и интеграцию с MS DTC, дает полностью графический интерфейс для регистрации и управления составляющими (MTS Explorer), то есть практически дает просто-напросто готовые средства решения задач поистине системного программирования, которые, как мы самостоятельно заметили повыше, неминуемо образуются при исследованию middleware. Кстати сказать с данной стороны по-старому лестный нюанс использования MTS содержится в том, что при исследованию составляющих не надо программировать вручную реакцию отчасти на многообразные финалы в системе. Сказать по правде, воспользуемся одним из образцов в составе MTS и осмотрим класс Account составляющие Bank. Точно так же он крайне имеет способ Post для дебитования либо кредитования просто-таки особого банковского счета. Надо полагать однако, в большинстве случаев, взаправду банковская операция значит дебет 1-го счета и кредит иного. Что и говорить вопрос: какое количество просто-таки добавочного программирования будет нужно, дабы вызов 2-ух способов в програмке на VB, VC++ и так далее спокойно выполнялся как 1 транзакция? С внедрением MTS решение делается элементарным.

Установка самих ролей случается в MTS Explorer. Cc ылку на контекст объекта возможно обрести при помощи функции MTS API GetObjectContext(). И тем не менее в этом образце мы нарочно делаем объект Account от контекста объекта MoveMoney, в следствии чего же он станет выполняться снутри этой же транзакции, что и объект MoveMoney. Совершенно очевидно, что по-особенному в едином случае данное находится в зависимости от транзакционного атрибута составляющие, под коим она установлена в MTS. Создавалось впечатление, что возможны 4 варианта: supported – при творении свежего объекта его контекст наследует клиентскую транзакцию, в случае если заказчик осуществляется вне транзакции, то новейший контекст также не станет транзакционным; required – это же, что и в прошлом случае, хотя в случае отстутствия транзакции у посетителя MTS откроет свежую транзакцию для объекта; requires new – объект не наследует транзакцию посетителя, ему постоянно раскрывается свежая транзакция; not supported – транзакция ни разу не станет открыта объекту вне зависимости от присутствия транзакции на посетителе.

Одной из особенностей MTS считается очень по-человечески рачительное, я бы в том числе и заявил, полностью робкое отношение к по-хорошему системным ресурсам. Откровенно говоря его лозунгом считается активизация по мере потребности и как можнож наиболее прыткая деактивизация объектов. Поразительно, что когда MTS деактивизирует объект, тот не сносится, а делается доступен для полностью повторного применения иными объектами. Но вот по секрету заявлю, что MTS нередко наглеет так, что лично имеет возможность деактивизировать сделанный вами объект при живых клиентских ссылках. Это означает, что то есть когда вы сделали объект, а после этого направь кофейку попить, не дивитесь, что данный сквалыга теснее спер ваш объект, деактивизировал его и плотно загнал кому-нибудь на сторону. Очевидно, что сердиться на него за данное не надо, так как как скоро вы внезапно вернетесь и заявите «эй, молодой человек, свободно гони взад мой объект», лучше подождать излишних пол-секунды, пока же MTS сделает или же утянет (что значительно прытче) с еще одного отчасти ленивого соединения таковой ведь объект, нежели обрести известие на подобии «извини, брат, не имею возможности – память закончилась». MTS деактивизирует объект при вызовах способов завершения транзакции SetComplete или же SetAbort. Наконец-то довольно-таки в последующий разов при повторном обращении к данному объекту MTS по обыкновению вмешается в COMовский вызов, подсунет вам именно тот ваш (быть может и вовсе не ваш) объект и вызовет у него затребованный вами способ. И сейчас то ведь случается при работе с базами этих. Очень может быть, что так как лидирующей среди дорогостоящих операций считается установка соединения, то MTS тщетно тяготеет держать у себя пул ODBC-соединений, и в случае если очень-очень необходимое вам слияние теснее туда попало и считается вольным, как вы предварительно мыслите, что сотворит MTS, как скоро вы его попросите соединиться с базой? Кинется бегом раскрывать свежее сплетение? Щас прям. В частности в основном количестве случаев вы получите его из пула. Такое впечатление, что смех хохотом, впрочем поистине бережное расходование вправду системных ресурсов считается одним из часто требуемых критерий высочайшей масштабируемости, и вовсе не владей MTS этими вероятностями, он чуть ли быстро смог бы на обыкновенной и вообще конфигурации в отсутствии по-старому специальных наворотов, подвергнуть обработке млрд транзакций в день.

Иногда встают ситуации, как скоро объект должен возвратить управление посетителю не будучи поистине готовым завершить транзакцию. А именно пусть у нас есть объект, спокойно отвечающий за ввод одной бухгалтерской электропроводки. Получается, что нам надо правильно использовать серию проводок, постепенно заявим, за день и сверить прямо-таки необходимую сумму с результатом. Но с другой стороны если они схожи, то только после этого всю категорию проводок можнож справедливо отмечать как просто-таки общую транзакцию. По правде говоря для данных целей контекст объекта лично имеет способ DisableCommit, который воспрещает деактивизацию и сброс воистину внутреннего состояния объекта. в нашем случае его обязан вызвать объект ввода электропроводки. после выверки результатов объектом комично вызывается способ EnableCommit с следующей фиксацией либо откатом транзакции.

Итак все объекты, четко работающие в среде управления MTS, имеют все шансы вызывать друг друга. в различие от их базисным посетителем величается подлинный заказчик в осмотренной нами в п.3 трехуровневой схеме, то есть данное прибавление, работающее, явно, не под управлением MTS, однозначно главная задача которого гарантировать пользовательский интерфейс и отражать запросы юзера в вызовы составляющих. для управления работой объектов MTS базисный заказчик применяет объект TransactionContext. несмотря на то, что схема его внедрения слишком смахивает на контекст объекта (способы CreateInstance, Complete и Abort), базисный заказчик лично имеет возможность лишь рулить транзакцией MTS, хотя радушно не принять участие в ней. например, он лично не имеет возможности напрямую хладнокровно открыть слияние взаправду с информационной базой и вставить операции над ней вовнутрь данной транзакции. наверное, данное адекватно, так как если бизнес-логика быстро ушла из клиентской доли, то роль в транзакциях middleware неприемлимо для базисного посетителя.

VB4 умел нарочно делать исключительно однопоточные составляющие. MTS гарантирует их поддержку, желая наверное медлительный прием, попросту чреватый напросто обоюдными блокировками. робко предположим, объекты А и В методично осуществляются на одном потоке управления. а перекрывает запись Х и завершает работу, совершенно позабыв устроить SetComplete. управление регулярно получает объект, коему также взаправду необходима запись Х, потому он часто томится в предвкушении, покуда А ее разблокирует. но чтобы достичь желаемого результата А обязан обрести поток управления, который наглухо ужасно занял. имеем картину с именем «Приплыли». в VB5 возможно нарочно делать apartment-threaded составляющие, обратно шло на умпомимо прочего поддерживает MTS, что теснее проще. каждому объекту снутри составляющие назначается по-человечески отдельный поток на всегда его жизни. границы апартаментов ориентируются работой (activity), коя, как я разумею, значит «гирлянду» объектов, связанных поочередными вызовами. таким образом, ежели 2 объекта быстро принадлежат различным деятельностям, им предоставляется возможность выполняться вдоль самостоятельно от того, быстро принадлежат они одной или же различным составляющим. мне может шумно показаться на первый взгляд, что разумно бы было правильно использовать в следующих версиях MTS модель трудящихся потоков, так дабы объекты не привязывались агрессивно к некоторому сгустку, а лично имели возможность непринужденно меж ими перераспределяться и при всем при этом не требовался бы кросс-поточный маршалинг.

Административными единицами при размещении составляющих в MTS чисто работают пакеты. считается, что составляющие снутри пакета всецело доверяют друг дружке, потому обоюдные права составляющих в пакете не проверяются, также они запускаются в некоем процессе. очевидно, что базисные вызовы имеют identity посетителя, потому при доступе к составляющим снутри пакета проверяется user-id. вызовы, немедленно идущие из пакета, теснее имеют identity этого пакета, потому в случае если юзеры обращаются к составляющим, а составляющие, так же, – к воистину информационной базе, то целесообразно умышленно соединить составляющие по пакетам в согласовании с правами юзеров на доступ к базе, иначе авторизацию срочно понадобиться прописывать ручками снутри составляющих. это что-то типа потери переходного периода к многоуровневым системам. перестройте свое мышление согласно с новеньким раскладом: вы теснее возросли из системы «клиент-сервер», давайте права на базу, имея в виду не окончательных юзеров, а составляющие. в конце концов, юзер вообщем и уже не трудится с базой – данное забота составляющих. администрирование пользовательского доступа к составляющим исполняется из MTS Explorer.

Microsoft Transaction Server соединяет внутри себя функции монитора транзакций и брокера мало-мальски объектных запросов. как монитор транзакций MTS правит транзакциями, проходящими через немного клерков ресурсов, распределителями ресурсов (ODBC-соединения) и мало-мальски совместными качествами, действиями и потоками. как брокер взаправду объектных запросов MTS правит распределением составляющих по компам, внедрением (таких как повторным) экземпляров объектов, и еще правами и сохранностью в общем-то объектных вызовов. приложения пишутся как однопользовательские, оформляются как ActiveX dll’и, регистрируются в среде управления MTS и начинают трудиться в многопользовательском режиме. программирование для MTS не настоятельно просит насыщенного познания COM или же Win32 API. компоненты для MTS имеют все шансы быть разработаны с внедрением очень широкого списка средств исследования как от Microsoft, но и от иных компаний. MTS поддерживает толстых (Win32 через DCOM) и напросто деликатных (броузер через HTTP и ASP) базисных посетителей. несмотря на сравнимо не так давно произошедший срок выхода MTS успел зарекомендовать себя как сильное и верное средство возведения и диспетчеризации ПО промежного слоя, соответствующее наиболее прогрессивным притязаниям концепции распределенных вычислений.

Список литературы Оцените данную заметку. ваш глас дозволяет нам отбирать дейтсвительно нужные заметки!

Windows DCOM, Microsoft, Server, Transaction