Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
| Содержание | Предыдущий | Затем |
В любой системе поддержка должна быть оказана для системы, чтобы развиться в течение долгого времени. У большинства существующих систем есть соглашения и механизмы, которые определяют, как изменение размещается. Эти системы были основаны на модели, где программы устанавливаются на компьютере. Как правило, разработчики были в состоянии определить то, что присваивает версию других пакетов, требуются, и процесс установки помог проверить и конфигурирует систему.
В открытых распределенных системах не работают статические предположения о существующих системах, и развитие является более трудным, потому что не возможно управлять, как или когда изменение пакетов и корректная работа зависят от большего числа зависимостей между пакетами. То, что необходимо, является обновленным набором соглашений и механизмов, которые определяют, как пакеты системы должны развиться так, чтобы цель открытой надежной масштабируемой распределенной системы могла быть достигнута.
Этот документ определяет:
Воздействие изменений в пределах распределенной системы оказывает значительное влияние на конечных пользователей, организации поддержки, веб-администраторов, и разработчиков.
У каждой из этих групп есть различные требования к продуктам, развернутым в сети, которые развиваются в течение долгого времени.
Для пользователей есть потребность создать атмосферу доверия, что Java базируемые продукты будет надежным и совместимым в течение долгого времени. Нежелание обновить потребности адресоваться, создавая атмосферу доверия в Записи Однажды Выполнение Где угодно философия. С Java это больше не должна быть норма, что пользователи будут жаловаться, "если я обновлю это, то повредит что-то” или “Я не буду в состоянии другим данных чтения-записи, может использовать”.
Организации продукта полагаются на возможность к легко и правильно идентифицируют продукт, который используется, среда, в которой это используется, и целостность упаковки продукта.
Веб-мастера, администраторы, и поставщики услуг должны развернуть приложения для своих клиентов через веб-или сетевые файловые системы в пути, который надежен и приемлем.
Разработчики продукта должны знать, как записать и развернуть приложения и библиотеки, которые удовлетворяют требования пользователей, администраторов и поддерживают персонал. Должный быть в состоянии сделать продукты и пакеты, что:
В открытых распределенных системах могут произойти много проблем, когда пакеты развиваются и обновляются независимо. Если указанное поведение, свойственное от использования открытых интерфейсов, не сохраняется, система может перестать работать неожиданными способами. Открытые системы составляются из многих пакетов от различных компаний и организаций. Эти организации работают асинхронно, представляя и обновляя их продукты в их собственных расписаниях. Распределение тех обновленных продуктов занимает время, и принятие не универсально.
В Java компоненты локальных и распределенных систем полагаются на открытые интерфейсы и контракты для поведения других пакетов. Те пакеты самостоятельно разовьются в течение долгого времени. Для пакета, чтобы управлять правильно пакетами это зависит от, должен продолжать обеспечивать ожидаемое поведение даже при том, что они были обновлены.
В распределенных системах только частичная непротиворечивость возможна, так как невозможно иметь знание всего состояния системы. У каждого процесса и пакета системы есть свое собственное частичное представление текущего состояния системы, накопленной с приращением, запрашивая информацию от других частей распределенной системы. Каждая информация, должен ли от апплета, который был запущен, класс, который был загружен, удаленный метод, вызванный, или полученная веб-страница, быть обработан тщательно так, чтобы это могло последовательно использоваться с остальной частью того частичного представления.
Много видов ошибок могли следовать из несогласованностей в классах, которые загружаются, включая ошибки проверки класса, классы могли вычислить неправильно, но без распознаваемых ошибок, или пользовательские запрошенные функции могли показать произвольные отказы.
Типичные проблемы включают:
Эти проблемы не могут быть предотвращены или решены непосредственно, потому что они проистекают из несогласованностей между динамически загруженными пакетами, которые не являются объектом управления единственного системного администратора и так не могут адресоваться текущими методами управления конфигурацией.
Ключ к контакту с этими проблемами и удовлетворению вышеизложенных требований является осторожным проектом пакетов и упаковкой системы так, чтобы они могли быть обновлены, распределены, и загружены в непротиворечивых модулях. Типичный к продуктам массового производства понятие поля перекроткий модуль. Это - самый маленький модуль продукта, который может быть идентифицирован со спецификацией, поставщиком, может быть распределен и перераспределен, и может быть заменен если дефектный. Эта та же самая модель используется для распределения программного обеспечения, продукты имеют имя, номер версии, придерживаются одной или более спецификаций, распределяются в сети или CD-ROM, и о его проблемах можно сообщить, чтобы поддерживать организации. Эти пакеты являются самым маленьким модулем, который может быть распределен, использоваться, проверен и заменен или обновлен когда необходимо. Пакеты могут быть собраны с другими пакетами, и каждый пакет может все еще быть идентифицирован, проверен, и распределен.
Язык Java базируемый механизм пакета соответствует хорошо идее перекроткого модуля. Пакеты Java представляют только открытые интерфейсы и используют только открытые интерфейсы других пакетов. Спецификация языка Java определяет подходы для совместимого развития пакетов.
Спецификация языка Java закладывает основу для того, чтобы разработать пакеты, которые, как могут ожидать, разовьются корректно в течение долгого времени. Это определяет, как классы могут измениться и все еще быть обратно совместимыми с другими классами, ранее скомпилированными и распределенными. Важный для устойчивого развития устойчивость общественности, защищенной, и интерфейсы пакета и поведение, поскольку реализации развиваются. Это определяет "совместимые" изменения как те изменения, которые не изменяют существующие интерфейсы или поведение. Таким образом, если класс определяет метод, и у метода было определенное поведение, тот же самый контракт должен поддерживаться всем более поздним развитием класса. Подробные правила даются в Главе 13 Спецификации языка Java. Одно дополнительное несовместимое изменение было добавлено; это является несовместимым, чтобы добавить методы к открытому интерфейсу.
Несовместимые изменения не разрешаются, но новая или подобная функциональность может всегда добавляться в новых или существующих интерфейсах или классах.
Выбирая пакет Java в качестве модуля обновления пакет и закрытые методы классов могут изменить гибкость разрешения в реализации пакета, в то время как общедоступные и защищенные классы и методы поддерживают внешние интерфейсы и семантику.
Устойчивое персистентное хранение и устойчивая передача между компонентами важны для распределенных систем. Компоненты должны быть в состоянии поддержать персистентное хранение, как они развиваются, возможность развить классы и все же сделать, чтобы они считали данные, ранее записанные хранению. Компоненты в распределенной системе развиваются на различных уровнях и должны все еще быть в состоянии достоверно связаться.
Соблюдение требований совместимости объектной сериализации позволяет более новым и более старым версиям связываться предсказуемым и непротиворечивым способом. Детали находятся в Главе 5 Спецификации Сериализации Объекта Java™.
Есть несколько категорий артефактов, которые должны быть идентифицированы включая спецификации, реализацию, виртуальную машину Java и среду выполнения Java.
Открытые системы основаны на идее, что у спецификации могут быть многократные реализации. Спецификации развиваются под покровительством организации или компании. Это чрезвычайно нежелательно, если у спецификации есть многократные несовместимые версии. Каждая версия спецификации или реализации должна развиться только в единственную последующую версию. Философия требования, чтобы спецификации были обратно совместимы, позволяет спецификациям быть идентифицированными как надмножества предыдущей спецификации. С тех пор есть единственная последовательность спецификаций версии, они могут обоснованно быть идентифицированы номерами версий с определенной семантикой, которые подразумевают упорядочивание. Номера версий спецификации используют десятичную запись Dewey, состоящую из чисел seperated к периодам.
Спецификация идентифицируется:
Реализация виртуальной машины Java должна быть, идентифицируют и спецификацию и реализацию. Эти свойства уже должны быть добавлены к тем доступное использование java.lang. System.getProperties.
К этим свойствам получают доступ, используя метод java.lang. System.getProperty и каждый возвращают строку.
Требование, чтобы идентифицировать Среду выполнения Java уже частично удовлетворяется через свойства, определенные Спецификацией языка Java, разделите 20.18.7 использований java.lang. System.getProperties.
В настоящий момент они идентифицируют реализацию Среды выполнения Java и базовых классов, которые доступны. Эти свойства не идентифицируют версию Спецификации языка Java, которую реализует этот JDK.
Дополнительные свойства необходимы, чтобы идентифицировать версию спецификации среды выполнения Java что этот adhere’s реализации к. Свойства:
К этим свойствам получают доступ, используя метод java.lang. System.getProperty и возврат их значения как строки.
Каждый пакет Java составляется из файлов класса плюс дополнительные файлы ресурсов. Информация должна была идентифицировать содержание пакета, сохранен содержанием пакета.
Эта спецификация применяется ко всем пакетам независимо от того, разрабатываются ли они как базовый пакет, распределенный со Средой выполнения Java, стандартным расширением, апплетом или пакетом приложений.
В отличие от номеров версий для информации о версии спецификаций для реализаций не может использоваться, чтобы идентифицировать пакет, как являющийся обратно совместимым с более ранними версиями. Номера версий пакета присутствуют, чтобы идентифицировать различия между спецификацией и реализацией, то есть ошибками. Новые версии реализаций определенно производятся, чтобы удалить (плохой или неправильный) поведение и таким образом предназначаются, чтобы не быть обратно совместимыми. Таким образом строки версии пакета могут иметь любое уникальное значение и могут только быть сравнены для равенства. Для полного объяснения объяснения см. Раздел 1.5.10" Объяснений для того, чтобы ограничить номера версий Реализации идентификационными данными”.
Следующие названия атрибута определяются для пакета. Значение каждого атрибута является строкой:
Эти атрибуты сохранены в декларации и получаются программами, используя java.lang. API пакета, описанный ниже.
java.lang. Класс пакета обеспечивает объект определить местоположение и получить доступ к информации о пакете.
Объекты пакета создаются явно загрузчиками класса и должны быть созданы прежде, чем первый класс в пакете определяется. Атрибуты каждого пакета сохранены в декларации и получаются classloader.
package java.lang;
public class Package {
// Return the name of this package.
public String getName();
// Return the title of the specification of this package.
public String getSpecificationTitle();
// Return the version of the specification of this package.
public String getSpecificationVersion();
// Return the vendor of the specification of this package.
public String getSpecificationVendor();
// Return the title of the implementation of this package.
public String getImplementationTitle();
// Return the version of the implementation of this package.
public String getImplementationVersion();
// Return the vendor of the implementation of this package.
public String getImplementationVendor();
// Is this package is compatible with the requested version
public boolean isCompatibleWith(String desired);
// Get the Package for the named class
public static Package getPackage(String classname);
// Return the packages for currently loaded classes.
public static Package[] getAllPackages();
// Return true if this package is equal to another object.
public boolean equals(Object obj);
// Return the hashcode for this object
public int hashCode();
// Return the string describing this package.
public String toString();
}
getName метод возвращает имя этого пакета, например, java.lang.
getSpecificationTitle возврат метода этот заголовок спецификации пакетов, если это известно и нуль иначе.
getSpecificationVersion возврат метода это номер версии спецификации этот пакет реализации. Нуль возвращается, если версия не известна.
getSpecificationVendor возвращает организацию, группу или поставщика, которому принадлежит спецификация.
getImplementationTitle возврат метода этот заголовок реализации пакетов, если это известно и нуль иначе.
getImplementationVersion возврат метода это номер версии реализации этот пакет реализации. Нуль возвращается, если версия не известна.
getImplementationVendor возвращает организацию, группу или поставщика, которому принадлежит эта реализация.
isCompatibleWith метод возвращает true, если номер версии спецификации этого пакета является совместимым с требуемым номером версии. True возвращается, если этот номер версии спецификации пакетов больше чем предоставленная строка версии. Строка версии является серией положительных чисел, разделенных периодами. Числа являются сравненным компонентом компонентом слева направо. Если какое-либо число больше чем соответствующее число предоставленной строки, метод возвращает true. Если число является меньше, чем оно возвращает false. Если соответствующие числа равны, следующее число исследуется.
getPackage метод определяет местоположение пакета для класса по имени. С текущим загрузчиком класса консультируются, чтобы отобразить имя пакета к объекту пакета в том загрузчике класса. Это возвращает объект пакета, содержащий атрибуты для пакета. Нуль возвращается, если информация о пакете еще не была загружена или если никакая информация о пакете не была определена classloader.
getAllPackages метод возвратит массив пакетов, известных току classloader. Это включает пакеты и системы и classloaded классов. Это не идентифицирует все пакеты, доступные, чтобы быть загруженным classloader. Это только идентифицирует те пакеты, для которых classloader предоставил информацию.
equals метод возвращает true, если у этого пакета есть то же самое имя и classloader как объект, в котором передают.
Метод хэш-кода возвращается, хэш-код, непротиворечивый с определением, равняется как требуется Спецификацией языка Java.
toString метод возвращает строку, состоящую из "пакета" и имени пакета. При наличии заголовок спецификации и номер версии спецификации добавляются к строке.
Метод был добавлен к java.lang.Class получить пакет для этого класса.
Чтобы поддерживать, Упаковывает classloader, расширяется, чтобы отследить отображение от классов до пакетов и позволить classloaders определять экземпляры Пакета для классов, которые они загружают. Дополнительные методы определяются, чтобы позволить подклассам определять пакеты в этом classloader, чтобы позволить реализации Пакета получать информацию о пакетах, определенных этим classloader.
java.lang. Реализация пакета должна идентифицировать ток classloader, чтобы вызвать это из системного кода.
package java.lang;
public class ClassLoader {
...
// Return the non-null classloader of callers
public static ClassLoader currentClassLoader();
// Define a Package
protected Package(String pkgname,
String spectitle, String specversion,
String specvendor, String impltitle,
String implversion, String implvendor);
...
}
currentClassLoader метод используется, чтобы счесть текущий ClassLoder даже если вызванным от системного класса. Когда вызвано от classloader загруженный класс это возвратит эквивалент this.getClass ().getClassLoader (). Это - поведение, идентично текущему методу SecurityManager.currentClassLoader, но общедоступен.
Защищенный доступ definePackage метод используется подклассами, чтобы определить пакеты классов, которые он загружает. Пакеты с именем могут только быть определены однажды и должны быть определены прежде, чем первый класс того пакета загружается. classloader должен предоставить атрибуты управления версиями из декларации, если они доступны.
Текущий явный формат расширяется, чтобы позволить спецификацию атрибутов для информации об управлении версиями пакета. Явная запись должна быть создана для каждого пакета Java. Имя записи будет каталогом в пределах архива, который содержит класс пакета и файлы ресурсов. Например:
Manifest-version: 1.0 Name: java/util/ Specification-Title: “Java Utility Classes” Specification-Version: “1.2” Specification-Vendor: “Sun Microsystems Inc.”. Package-Title: “java.util” Package-Version: “build57” Package-Vendor: “Sun Microsystems. Inc.”
Эти атрибуты могут быть вставлены в декларацию, создавая прототипный файл манифеста и используя “-m” переключатель инструмента фляги, чтобы объединить их в декларацию, когда это создается. JarTool будут расширены на обзор и устанавливают атрибуты управления версиями в декларации.
Пользователи должны быть в состоянии сообщить об идентификационных данных пакетов в использовании, когда ошибки происходят. Это до приложения, апплета или браузера, чтобы представить доступную информацию пользователю по требованию или когда ошибка происходит. API доступен, чтобы позволить следующему сообщаться:
package.getAllPackages метод возвратит активные пакеты.Реализации развиваются независимо в течение долгого времени, чтобы исправить ошибки, улучшить производительность или добавить новые функции, требовавшиеся более поздними версиями спецификаций. Пакеты реализуют спецификации и должны идентифицировать, какую версию каждой спецификации они реализуют. Взаимодействия происходят между пакетами только через их общественность и защищенные интерфейсы и классы. Это - общественность api и поведение, которое должно остаться устойчивым в течение долгого времени так, чтобы изменения могли быть позволены в реализации одного пакета, не влияя на поведение другого пакета.
Если бы классы пакета, всегда искренне реализованного спецификация, было бы достаточно только идентифицировать спецификацию. С тех пор в реальном мире это редко происходит, пакеты должны идентифицировать себя так, чтобы об ошибках можно было сообщить против пакетов, которые, возможно, способствовали проблеме.
Есть существенная тенденция попытаться присоединить некоторое значение присвоить версию идентификаторам реализаций. Если цель состоит в том, чтобы позволить отслеживание ошибок тогда, уникальное число достаточно. Это также достаточно для клиентского пакета к обходному решению ошибка в определенной версии пакета поставщиков, так как та версия может быть протестирована на и ошибка, которой избегают.
Однако, много дополнительных проблем могут произойти, когда один пакет пытается работать вокруг ошибок в других пакетах. Они должны идентифицировать поведение, которое не является частью спецификации и может попытаться использовать поведение, которое является только частью одной реализации. На такую реализацию определенное поведение нельзя положиться, чтобы быть в любой определенной версии кроме одного (s), замеченный и протестированный разработчиком.
Ошибка сначала появляется в некоторой версии пакета поставщиков, и можете, или, возможно, не продолжает быть проблемой в последующих версиях. Если клиент ошибочного пакета использует работу вокруг основанного на номерах версий, он мог бы правильно работать вокруг ошибки в определенной версии. Теперь, если ошибочный пакет был фиксирован, как был бы клиентский пакет знать, была ли ошибка исправлена или нет. Если это предполагало, что более высокие версии, все еще содержавшие ошибка, все еще попытается работать вокруг ошибки. Работа вокруг себя не могла бы работать правильно с неошибочным пакетом. Это могло вызвать каскад ошибок, вызванных, исправляя ошибку. Только разработчик, посредством тестирования с новой версией, может определить, необходимо ли обходное решение для ошибки все еще или вызовет ли это проблемы с правильно ведущим себя пакетом. Разработчик только знает, что ошибка существует в детали отдельные версии.
Этот раздел должен обсудить каждый аспект разработки продукта и дистрибутивов, дающих направление на том, как достигнуть устойчивого evolvable продукта.
| Содержание | Предыдущий | Затем |
