Перевод на службу не связанную со спецификацией

Обзор документа

Федеральная служба по надзору в сфере здравоохранения в рамках исполнения государственной функции по мониторингу безопасности лекарственных препаратов, находящихся в обращении на территории Российской Федерации, сообщает следующее.

Росздравнадзор доводит до сведения специалистов здравоохранения письмо фармацевтической компании ООО «Джонсон&Джонсон» об отзыве серий лекарственного препарата Силест (МНН: Норгестимат+Этинилэстрадиол), таблетки 250 мкг+35 мкг, производства «Силаг АГ», Швейцария, (регистрационное удостоверение П № 011462/01 от 16.02.2012).

Приложение: на 2 л. в 1 экз.

Врио руководителя М.А. Мурашко

Приложение 1
к письму Федеральной службы понадзору в сфере здравоохранения

от 20 июня 2013 г. № 16и-663/13

Компания Janssen, фармацевтическое подразделение ООО «Джонсон&Джонсон», настоящим письмом информирует о добровольном отзыве с рынка Российской Федерации серий лекарственного препарата Силест (этинилэстрадиол+норгестимат), таблетки, находящихся в настоящее время у дистрибьюторов (серии BLS1F00, BLS1F01, CFS4000, CFS4001, CFS4100, CIS0B00).

Причиной осуществления данного отзыва является получение неудовлетворительных результатов теста «Растворение» норгестимата для двух серий препарата (через 18 месяцев хранения у одной серии и через 24 месяца хранения у второй серии) через 30 минут после начала проведения теста.

Средний показатель растворения норгестимата через 30 минут составил 67%, в то время как должен составлять не менее 70%, согласно спецификации. Результат теста через 60 минут соответствовал спецификации и составил в среднем 81% (спецификация: не менее 80 %).

Результат теста «Растворение» этинилэстрадиола соответствовали спецификации как через 30 мин, так и через 60 мин.

На основании анализа данных по растворению норгестимата и доступных данных по безопасности препарата в пост-маркетинговом периоде, сделано заключение об очень низкой вероятности возникновения у пациентов побочных действий, связанных с замедленным растворением норгестимата.

Несмотря на то, что замедленное высвобождение норгестимата теоретически может вызвать уменьшение контрацептивного эффекта препарата, это является маловероятным, так как Силест принимается внутрь только 1 раз в день. Также увеличение времени достижения достаточной концентрации норгестимата до 60 мин вместо 30 мин не должно влиять на показатели концентрации норгестимата в течение 24 часов.

Проведенный анализ внутренней базы данных безопасности по показателям «недостаточная эффективность препарата» и «возникновение беременности» для препарата Силест, проведенный за период с 01 января 2009 г. по 31 декабря 2012 г., то есть за то время, когда затронутые серии находились на рынке, показал уменьшение числа отчетов по данным показателям.

В том случае, если Вы получили сообщение о недостаточной эффективности или о возникновении беременности у пациентов на фоне приема препарата Силест, пожалуйста, сообщите об этом в ООО «Джонсон & Джонсон» (тел.: +7 (495) 755-83-57, факс: +7 (495) 755-83-58), указав при этом номер серии препарата (если возможно).

В настоящее время проводится оценка возможности возобновления поставок препарата Силест.

Пожалуйста, не назначайте лекарственный препарат Силест новым пациентам в связи с перерывами в поставках. Пациенты, принимающие данный препарат, должны быть переведены на другой пероральный контрацептивный препарат в случае нехватки препарата Силест.

Номер телефона для сообщений о нежелательных явлениях:

Специалистам в области здравоохранения следует сообщать о любых нежелательных явлениях, связанных с приемом препарата Дакоген, в ООО «Джонсон & Джонсн», Россия, 121614, Москва, ул. Крылатская, 17/2, контактные телефоны: тел.: +7 (495) 755-83-57, факс: +7 (495) 755-83-58

Обзор документа

Приведено письмо компании ООО “Джонсон&Джонсон” об отзыве препарата “Силест” (МНН: Норгестимат+Этинилэстрадиол), производства “Силаг АГ” (Швейцария). Причиной отзыва являются неудовлетворительные результаты теста “Растворение”.

Несмотря на то, что замедленное высвобождение норгестимата теоретически может вызвать уменьшение контрацептивного эффекта препарата, это является маловероятным, так как “Силест” принимается внутрь только 1 раз в день.

В настоящее время проводится оценка возможности возобновления поставок препарата “Силест”.

Однако, препарат рекомендуется не назначать новым пациентам из-за перерывов в поставках. Пациентов, принимающих “Силест”, следует перевести на другой пероральный контрацептивный препарат в случае нехватки данного лекарства.

О любых нежелательных явлениях, связанных с приемом “Силеста”, следует сообщать в ООО “Джонсон & Джонсн” – 121614, Москва, ул. Крылатская, 17/2.

Для просмотра актуального текста документа и получения полной информации о вступлении в силу, изменениях и порядке применения документа, воспользуйтесь поиском в Интернет-версии системы ГАРАНТ:

Источник: https://www.garant.ru/products/ipo/prime/doc/70300138/

The Java Language Specification. Chapter 17. Threads and Locks (Перевод. Часть 1)

Привет, Хабр! Представляю вашему вниманию перевод статьи «The Java Language Specification (Chapter 17. Threads and Locks)» Оригинал.

Глава 17. Треды и блокировки (Chapter 17. Threads and Locks)

В то время как большая часть дискуссий в предыдущих главах касалась только поведения кода, исполняемого одновременно и как единое утверждение или выражение одновременно, т.е. в одном треде, JVM (Java virtual machine) может поддерживать одновременно несколько тредов исполнения. Эти треды независимо друг от друга используют код, который действует на значения и объекты, находящиеся в общей памяти (shared main memory). Треды могут поддерживаться за счет использования множества аппаратных процессоров, временным разделением одного аппаратного процессора или временным разделением нескольких аппаратных процессоров.

Треды представлены классом Thread. Единственный способ, каким пользователь может создать тред — это создать объект этого класса; каждый тред ассоциируется с каким-то объектом. Тред начнет свое исполнение, когда будет вызван метод start() на соответствующем Thread-объекте.

Поведение тредов, особенно когда синхронизация выполнена некорректно, может быть непонятно и не соответствовать ожиданиям. Эта глава описывает семантику многопоточного программирования; она содержит правила, согласно которым значения можно увидеть для чтения в общей памяти, которая обновляется множеством тредов. Так как спецификация аналогична Memory Models для различных архитектур, эта семантика известна как Memory Model языка программирования Java. Когда не будет возникать путаницы, мы просто будем называть эти правила “Memory Model”. Эта семаника не предписывает, как должна выполняться многопоточная программа. Скорее, она описывает возможное поведение, которое могут демонстрировать многопоточные программы. Приемлима любая стратегия выполнения, которая генерирует возможные модели поведения.

17.1 Синхронизация (17.1. Synchronization)

Язык программирования Java представляет множество механизмов для взаимодействия между тредами. Самые основополагающие из них — это методы синхронизации (synchronization), которая осуществляется с использованием мониторов (monitors). Каждый объект в Java ассоциируется с монитором, который тред может захватить или отпустить (lock/unlock). Одновременно, только один тред может держать монитор. Любые другие треды при попытке захватить этот монитор блокируются, пока они не смогут захватить его. Тред t может блокировать конкретный монитор множество раз; когда монитор отпускается (unlock), отменяется эффект одной операции блокировки (lock).

Оператор synchronized (§14.19) вычисляет ссылку на объект, а потом он пытается выполнить захват (lock) монитора этого объекта и дальше ничего не происходит, пока захват не выполнен успешно.

После успешного захвата (lock) выполняется тело synchronized оператора.

Если тело synchronized оператора выполнено полностью или в сокращенном варианте, то этот монитор автоматически отпускается (unlock).

Синхронизированный метод (§8.4.3.6) автоматически выполняет захват (lock) при вызове, его тело не исполняется, пока захват (lock) успешно не выполнен.

Если мы имеем дело с методом экземпляра, тогда он захватывает монитор, связанный с экземпляром, для которого был вызван (то есть объектом, который будет известен как this в течение выполнения тела метода).

Если метод статический (static), он захватывает монитор, связанный с объектом Class, который представляет класс, в котором определен метод. Если выполнение тела метода завершено полностью или в сокращенном варианте, этот монитор автоматически отпускается.

Язык программирования Java не предотвращает и не требует определения взаимоблокировки (deadlock) условий. Программы, где треды держат (прямо или косвенно) захват на множестве объектов, должны использовать обычные приемы для избежания взаимоблокировки. Создавайте высокоуровневые блокирующиеся примитивы, у которых не бывает взаимоблокировок, если необходимо. Остальные механизмы, такие как чтения и запись volatile переменных, и использование классов из пакета java.util.concurrent предоставляют альтернативные способы синхронизации.

17.2 Набор ожиданий и уведомления (17.2. Wait Sets and Notification)

Каждый объект, в дополнение к тому, что имеет ассоциацию с монитором, так же связан с набором ожиданий (Wait Sets). Набор ожиданий — представляет собой набор тредов.

Когда объект впервые создается, его набор ожиданий пуст. Элементарные действия, которые добавляют или удаляют треды в/из набор ожиданий атомарны. Набор ожиданий управляется исключительно через методы Object.wait, Object.notify, and Object.notifyAll.

На манипуляции с набором ожиданий так же могут повлиять статическое прерывание треда и методов класса Thread связанные с прерыванием (interruption). Кроме того методы класса Thread для sleeping и joining других тредов имеют свойства, полученные от свойств действий методов wait and notification.

17.2.1. Ожидание (17.2.1. Wait)

Действие ожидание происходит при вызове метода wait() или с временными сигнатурами wait(long millisecs) and wait(long millisecs, int nanosecs).

Вызов wait(long millisecs) с параметром ноль или вызов wait(long millisecs, int nanosecs) с двумя параметрами указанными равным нулю эквиваленты вызову wait().

Тред возвращается и ожидания, если он не выпросил исключение InterruptedException.

Предположим, тред t выполняет метод wait на объекте m, и, пусть, n будет число блокирующихся действий по t на m, которые не были сопоставлены с разблокирующимися действиями. Произойдет одно из следующий действий:

  • Если n ноль (т.е. тред t еще не захватил блокировку (lock) на целевой m-объект), тогда будет выброшено исключение IllegalMonitorStateException.
  • Если этот wait с заданой временной сигнатурой nanosecs-аргумент не в диапозоне 0-999999 или millisecs-аргумент задан негативным числом,, тогда будет выброшено исключение IllegalArgumentException
  • Если тред t прерывается, тогда будет выброшено исключение InterruptedException и состояние прерывания (interruption status) t устанавливается в false.
  • В противном случае имеет место следующая последовательность.
    1. Тред t добавляется в набор ожидания объекта m, и выполняет n разблокировок (unlock) на M.
    2. Тред t не выполняет больше никаких инструкций, пока не будет удален из набора ожиданий объекта m. Тред может быть удален из набора ожидания по любой из следующих причин и будет восстановлен когда-нибудь позже:
      • Действие notify было выполнено на m, в котором t выбран для удаления из набора ожиданий.
      • Действие notifyAll выполнено на m.
      • Действие interrupt выполнено на t.
      • Если wait с заданой временной сигнатурой, внутренние действие удаляющие t из набора ожиданий m, которое происходит после, по крайней мере millisecs плюс nanosecs после начала этого действия ожидания.
      • Внутреннее действие путем реализации. Реализация разрешена, хотя и не желательна, чтобы выполнить «ложные активации (spurious wake-ups)», то есть удалить тред из набора ожиданий и таким образом позволить возобновить действия без дополнительных инструкций для этого.Обратите внимание, что это положение требует практики кодирования на Java, при использовании wait только внутри циклов, которые заканчиваются только по логическом условии, что тред удерживает блокировку.

      Каждый тред обязан определить порядок событий, которые могут вызывать его (т.е. этого треда) удаления из набора ожиданий. Этот порядок не должен быть консистентный с другими упорядочиваниями, но тред должен вести себя так, как будто эти события произошли в этом порядке.

      Например, если тред t в наборе ожиданий для m, а потом происходит и прерывание t и уведомление. Эти события должны происходить в некотором порядке.

      Если предположим, что сначало произошло прерывание, тогда t в итоге возвращается из wait с выбросом исключения InterruptedException и некоторые другие потоки в наборе ожиданий m (если они существуют в момент уведомления) должны получить уведомление.

      Если предположим, что сначало произошло уведомление, тогда t обычным порядком, в конце концов, вернется из wait при этом прерывание будет в режиме ожидания.

    3. Тред t выполнить n блокировок на m.
    4. Если тред t был удален из набора ожиданий m на шаге 2 в связи с прерыванием, тогда статус прерывания t устанавливается в false и wait-метод просит InterruptedException.

17.2.2. Уведомление (17.2.2. Notification)
Уведомление (notification) происходит при вызове метода notify and notifyAll.
Давайте представим, что тред t будет использовать любой из этих методов на объекте m, и пусть n будет число захвата блокировок на t по m, которому не соответствовали количество выполнения действий отпуска монитора (unlock). Произойдет одно из следующих действий:

  • Если n равно нулю, то будет брошено IllegalMonitorStateException. Это случай, когда тред t уже не обладает блокировкой для целевого m-объекта.
  • Если n больше нуля и это notify действие, тогда, если набор ожиданий m не пуст, выбирается тред u являющийся членом текущего набора ожиданий m и его удаляют из набора ожиданий. Нет гарантии, какой тред из набора ожиданий будет выбран. Удаление треда u из набора ожиданий возобновляет u в wait-действие. Заметьте, однако, что действие захвата u, при возобновление, будет осуществляться спустя некоторое время после того как t полностью разблокирует монитор для m.
  • Если n больше нуля и выполняется notifyAll действие, тогда все треды удаляются из набора ожиданий m и таким образом возобновляются. Заметте, однако, что, одновременно, только один из них захватит требуемый монитор вовремя возобновления wait.

17.2.3. Прерывания (17.2.3. Interruptions)
Прерывания (Interruptions) происходят при вызове Thread.interrupt, а также методы, предназначенные в свою очередь для вызова, такие как ThreadGroup.interrupt.
Пусть t будет вызывать u.interrupt, для некого треда u, где t и u могут быть одинаковыми. Эти действия выставляют статус прерывания u в true.

Дополнительно, если существует какой-то объект m чей набор ожиданий содержит u, тогда u удаляется из набора ожиданий m. Это включает u для возобновления в wait-действие, в этом случае, после повторного захвата монитора m будет брошено исключение InterruptedException.

Вызовы Thread.isInterrupted могут определить статусы прерывания тредов. Статический метод Thread.interrupted может быть вызван в треде для наблюдения и очистки его собственного статуса прерывания.

17.2.4. Взаимодействие Ожиданий, Уведомления, and Прерывания (17.2.4. Interactions of Waits, Notification, and Interruption)

Упомянутые выше спецификации позволяют нам определить некоторые свойства связанные с взаимодействие ожиданий, уведомлений и прерываний. Если тред уведомлен и прерван в течение ожидания, он может либо:

  • Вернуться нормально в ожидание, все еще находясь в режиме ожидания прерывания (другими словами вызов Thread.interrupted вернет true)
  • Вернется из ожидания с выбросом исключения InterruptedException

Тред может не сбросить этот статсу-прерывания и вернуться нормально из вызова ожидания.

Аналогично, уведомления не могут быть потеряны из-за прерываний. Предположим, что набор s тредов в наборе ожиданий объекта m, а другой тред выполняет notify на m. Тогда либо:

  • Как минимум один тред и s должен вернуться нормально и ожидания, или
  • все треды из s должны выйти из и выбросить InterruptedException

Заметьте, что если тред и прерван, и разбужен через notify и что этот тред вернулся из ожидания бросив InterruptedException, тогда какой-либо другой тред в наборе ожиданий должен быть уведомлен.

17.3. Спать и Уступать (17.3. Sleep and Yield)

Thread.sleep переводит работающий тред в спящий режим (временное прекращение выполнения) на определенный срок в зависимости от точности таймеров (system timers) и планировщиков системы (schedulers). Тред не теряет контроль над мониторами и его действие возобновляется в зависимости от планирования и доступности процессоров на которых можно выполнять треды.

Важно упомянуть, что ни Thread.sleep ни Thread.yield не имеют никакой семантики синхронизации. В частности, компилятор не должен выполнять записи в кеш на регистры вне общий памяти до вызова Thread.sleep или Thread.yield, компилятор так же не должен перегружать значения регистров кеша после вызова Thread.sleep или Thread.yield.
Например, следующий (не корректный) сегмент кода, предположим, что this.done не-volatile boolean поле. while (!this.done) Thread.sleep(1000); Компилятор читает в кеш this.done только один раз, и после этого использует значения из кеша каждую итерацию цикла. Это значит, что цикл никогда не будет прекращен, даже, если другой тред измени значение this.done. В следующих частях будет представлено: Часть 2) Memory Model;

Часть 3) Семантика final полей; Word Tearing на некоторых процессорах (х32); не атомарную поддержку double и long.

Спасибо за внимание!:)

  • java
  • multithreading
  • memory model

Источник: https://habr.com/ru/post/358880/

Спецификация языка WSDL 1.1

Константин Александров, 9 декабря 2012

Поскольку транспортные протоколы и форматы сообщений были стандартизованы web-сообществом, появилась возможность и необходимость описания взаимодействия систем в структурированном виде.

Эту задачу решает WSDL — язык на базе XML, который описывает службу как набор конечных точек, способных обмениваться сообщениями.

WSDL документирует и определяет в комплексе детали взаимодействия распределённых систем в удобном для машинной обработки виде.

WSDL определяет службу (service), как набор конечных точек (endpoint), или портов (port).

При этом специфичные параметры реализации — формат данных, настройки транспортного протокола — отделены от определения абстрактных сообщений (message), операций (operation) и типов портов (port type), что позволяет переиспользовать эти определения.

Конкретный тип порта с указанным протоколом передачи и форматом сообщений образует связывание (binding), ассоциация связывания с конкретным сетевым адресом образует порт, а множество портов образует службу. Отсюда для описания службы в WSDL используются следующие сущности:

Тип (type) Контейнер для описания типов данных с помощью какого-либо языка (например, XSD). Сообщение (message) Абстрактное типизированное определение данных для обмена. Операция (operation) Абстрактное описание поддерживаемого службой действия или функции. Тип порта (port type) Абстрактный набор операций, поддерживаемых одной или несколькими конечными точками. Связывание (binding) Спецификация транспортного протокола и формата данных для конкретного типа порта. Порт (port) Единичная конечная точка, определённая путём задания связывания и конкретного сетевого адреса. Служба (service) Множество связанных конечных точек.

Эти элементы будут детально описаны в следующем разделе. Важно отметить, что WSDL не вводит нового языка определения типов.

WSDL признает потребность в развитом механизме типизации для описания формата сообщений и поддерживает спецификацию XML Schema (XSD) как каноническую систему типизации.

Однако это вовсе не означает, что выбор грамматики ограничивается только одной XSD — использование других грамматик допустимо посредством использования механизма расширения.

Кроме того WSDL определяет общий механизм связывания. Он используется для ассоциации специфичных параметров протокола или формата и структуры данных с абстрактными сообщениями, операциями или конечными точками, что позволяет переиспользовать абстрактные определения.

В дополнение к описанию самого механизма определения служб эта спецификация даёт введение в расширения связывания (binding extension) для следующих протоколов и форматов сообщений:

  • SOAP 1.1
  • HTTP GET / POST
  • MIME

Несмотря на то, что указанные выше расширения описываются в этом документе и наслаиваются на описание ядра механизма определения служб, никто не запрещает использовать другие расширения связывания вместе с WSDL.

Пример WSDL-документа

Ниже приведён пример WSDL для простой сетевой службы, которая предоставляет информацию о котировках на бирже. Она поддерживает одну операцию GetLastTradePrice, которая разворачивается в сети с использованием SOAP 1.1 поверх HTTP-транспорта. Запрос включает аббревиатуру ценной бумаги строкового типа, а ответ цену дробного типа.

Соглашение об обозначениях

В этом документе используются следующие пространства имен с префиксами:

Префикс URI пространства имен Определение

wsdl http://schemas.xmlsoap.org/wsdl/ Пространство имен фреймворка WSDL
soap http://schemas.xmlsoap.org/wsdl/soap/ WSDL-пространство имен для SOAP binding
http http://schemas.xmlsoap.org/wsdl/http/ WSDL-пространство имен для HTTP GET и POST связывания
mime http://schemas.xmlsoap.org/wsdl/mime/ WSDL-пространство имен для MIME связывания
soapenc http://schemas.xmlsoap.org/soap/encoding/ Пространство имен для атрибутики, относящейся к кодированию (сериализации) SOAP-сообщений, определено в SOAP 1.1
soapenv http://schemas.xmlsoap.org/soap/envelope/ Пространство имен SOAP-конверта (envelope), определено в SOAP 1.1
xsd http://www.w3.org/2000/10/XMLSchema Пространство имен XML схемы, определено в спецификации XSD
xsi http://www.w3.org/2000/10/XMLSchema-instance Пространство имен, ориентированное на использование в любых XML-документах для указания XSD-специфичных атрибутов, но не относящихся к непосредственному определению типов; определено в спецификации XSD
tns любой По соглашению префикс tns (от «this namespace») используется для обращения к пространству имен текущего документа
остальные любой Все остальные префиксы пространств имен используются только для примеров, в частности URI, начинающийся с http://example.com, используется для представления некоторого независимого от приложения URI

В текущей спецификации используется свободный синтаксис для описания XML-грамматики WSDL:

  • Вместо использования строгой грамматики типы XML-сущностей, используемые в WSDL, описываются с помощью фрагментов XML с примерами этих сущностей.
  • Имена элементов, заканчивающиеся на …, означают, что элементы или атрибуты, не имеющие значения в данном контексте, были опущены: .
  • За XML-элементами и атрибутами следуют количественные квантификаторы: ? (0 или 1), * (0 или более), + (1 или более).
  • Конструкции, упоминаемые впервые, либо представляющие основной интерес в контексте конкретного примера выделяются цветом фона.

Источник: http://falstart.com/lib/wsdl_1_1.html