home | login | register | DMCA | contacts | help | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


my bookshelf | genres | recommend | rating of books | rating of authors | reviews | new | форум | collections | читалки | авторам | add
fantasy
space fantasy
fantasy is horrors
heroic
prose
  military
  child
  russian
detective
  action
  child
  ironical
  historical
  political
western
adventure
adventure (child)
child's stories
love
religion
antique
Scientific literature
biography
business
home pets
animals
art
history
computers
linguistics
mathematics
religion
home_garden
sport
technique
publicism
philosophy
chemistry
close

реклама - advertisement



API-ориентированные архитектуры

Учитывая недостатки процессоро-ориентированных архитектур, многие ISV, производители оборудования и организации по стандартизации совместно разрабатывали архитектуры, в основе которых лежит интерфейс прикладных программ API[ 8 ] (application programming interface). Такие API-ориентированные архитектурыустанавливают коммуникационный барьер — интерфейс, который используется всем прикладными программами для доступа к сервисам операционной системы и изолирует их от аппаратных и программных деталей.

Операционная система — это набор программ, управляющих системными ресурсами и служащих фундаментом для написания прикладных программ. Часто таким фундаментом становятся API. Существуют различные формы реализации API. Это может быть вызов или команда, запрашивающая у операционной системы согласие на выполнение некоторых действий. Хорошо известный пример API — функция операционной системы, вызываемая прикладной программой для выполнения операции ввода-вывода, такой как чтение с диска. Очевидно, что прикладной программе незачем «знать» подробности внутренней работы ввода-вывода. Программы операционной системы, выполняющие функции ввода-вывода и часто называемые подсистемами ввода-вывода, изолируют приложения от деталей аппаратной и программной реализации. Приложения, использующие для выполнения ввода-вывода только соответствующие API, не зависят от каких-либо изменений в структуре ввода-вывода на нижних уровнях.

Дополнительное преимущество дает реализация разными производителями одного и того же набора API. В этом случае приложения легко переносить с одной системы на другую. Один из наиболее известных стандартных наборов API — POSIX. POSIX — сокращение, неформально расшифровываемое как «переносимый интерфейс операционной системы базирующейся на Unix» (portable operating system interface based on Unix) — это набор международных стандартов для интерфейсов Unix-подоб-ных операционных систем. Правительственные и неправительственные организации поощряют реализацию производителями Unix-подобных операционных систем данных стандартов, как обеспечивающую переносимость приложений с одной системы на другую.

Общая проблема стандартов типа POSIX состоит в том, что они никогда не становятся законченными, и стадия определения такого стандарта занимает многие годы. В такой ситуации разработчики приложений часто берут дело в свои руки. В 1993 году группа разработчиков приложений для Unix и производителей Unix-подобных операционных систем решила определить свой собственный набор API. Они не могли ждать, пока спецификация POSIX «созреет» до такой степени, чтобы ее можно было использовать. Кроме того, ясно, что когда спецификация POSIX будет, наконец, полностью завершена, все приложения придется переписывать под новый стандарт.

Вместо этого, упомянутая группа разработчиков выделила все API, которые используются в настоящее время наиболее популярными приложениями для Unix. Из тысяч существующих Unix-приложений они взяли 50 самых распространенных и выбрали 1179 функций API в качестве основы нового стандарта, который первоначально был назван SPEC1170. Позднее это название было заменено на «Единая Спецификация UNIX» (Single UNIX Specification), и данный стандарт становится теперь новой промышленной спецификацией Unix. Помимо указанных API в него входит часть интерфейсов POSIX. В состав спецификации продолжают включаться новые API.

Очевидная проблема во всей этой работе по определению API была лаконично сформулирована одним из сотрудников института NIST (National Institute of Standards and Technology Национального института стандартов и технологий США): «Самое милое в стандартах — это большой их выбор». В самом деле, множество противоречащих друг другу и быстро изменяющихся стандартов делает невозможным создание приложения, которое было бы переносимо на все платформы. Далее, в главе 11, мы рассмотрим язык программирования Java и предоставляемые им возможности по созданию переносимых приложений.

Более того, эти стандарты не являются полными, то есть во многих случаях приложениям приходится действовать «в обход» API. В результате приложение становится зависимым от аппаратуры и программного обеспечения нижних уровней: в тот момент, когда приложение обходит API, все проблемы, присущие процессоро-ори-ентированным архитектурам, возникают снова.


Процессоро-ориентированная архитектура | Основы AS|400 | Машинная архитектура высокого уровня