INTERFACES

LVD (англ. low-voltage-differential) — интерфейс дифференциальной шины низкого напряжения, сигналы положительной и отрицательной полярности идут по разным физическим проводам — витой паре. На один сигнал приходится по одной витой паре проводников. Используемое напряжение при передаче сигналов ±1,8 В.

HVD (англ. high-voltage-differential) — интерфейс дифференциальной шины высокого напряжения, отличается от LVD повышенным напряжением и специальными приемопередатчиками.

Первый стандарт SCSI имеет 50­контактный неэкранированный разъем для внутрисистемных соединений и аналогичный экранированный разъем типа Centronics (Alternative 2) для внешних подключений. Передача сигналов осуществляется 50 контактным кабелем типа — A­50 на 8

разрядной (битной) шине. Но надо иметь в виду, что до появления SCSI, имевшего 50контактный разъём, и даже одновременно с ним был более старый SCSI, имевший 25контактный разъём, почти такой, как разъём LPT (например, в теперь уже почти вышедшем из употребления сканере Mustek 1200 FS есть одновременно три разъёма: OPTION на 26 контактов, SCSI на 25 контактов, SCSI на 50 контактов).

Встандарте SCSI­2 для 8 битной шины предусматривался кабель типа A, который как и в SCSI­1 поддерживал 50­контактными разъемами типа D с уменьшенным шагом выводов (Alternative 1). Разъемы типа Centronics (Alternative 2) в SCSI­2 построены 8 и 16 битной шине. Передача информации осуществляется по 68­контактным кабелям типа — A­68 и P­68(Wide). Для 32 битной версии шины был предусмотрен тип кабеля B, который должен был параллельно подключаться одновременно с кабелем A в одно устройство. Однако кабель B не получил широкого признания и из стандарта SCSI­3 исключен.

Встандарте SCSI­3 кабели A­68 и P­68 поддерживались экранированными, либо неэкранированными разъемами типа D. Кабели в SCSI­3 снабжены фиксаторами­защелками, а не проволочными кольцами, как разъемы Centronics. Начиная с этой версии SCSI в массивах накопителей используется 80­контактный разъем, называемый Alternative 4. Накопители с таким разъемом поддерживают «горячее» подключение устройств, то есть устройства SCSI можно подключать и отключать при включенном питании.

Основные реализации параллельного интерфейса SCSI (в хронологическом порядке):

Обзор интерфейсов SCSI[6]

50. Конфигурирование устройств. Подключение устройств к шине SCSI. Кабели, разъёмы, сигналы.

Параметры конфигурирования SCSI-устройств

Все устройства на шине должны быть согласованно сконфигурированы. Для них требуется программно или с помощью перемычек (джамперов) установить следующие основные параметры.

Идентификатор устройства ­ SCSI ID ­ адрес 0­7 (или 0­15), уникальный для каждого устройства на шине. Обычно хост­адаптеру, который должен иметь высший приоритет, назначается ID 7. Заводское назначение идентификаторов устройств приведено в таблице, хотя оно и не является обязательным. Устройства адресуются позиционным кодом (хотя ID задается 3­4­битовым кодом), что обеспечивает совместимость адресации 8­ и 16­битовых устройств на одной шине. Номер SCSI ID обычно устанавливается с помощью перемычек (хотя в SCSI существуют и новые стандарты, аналогичные Plug­and­Play, не требующие перемычек).

Таблица заводских установов идентификаторов устройств

7 Хост­адаптер

6 Накопитель на магнитных дисках

5 ­

4 Ленточный или R/W­оптический накопитель

3 CD­ROM

2 Сканер, принтер

1 НЖМД, поддерживаемый BIOS хост­адаптера

0 НЖМД, поддерживаемый BIOS хост­адаптера

Контроль паритета ­ SCSI Parity. Если хотя бы одно устройство на шине не поддерживает контроль паритета, он должен быть отключен на всех устройствах данной шины. Контроль паритета, особенно для дисковых устройств, является средством защиты от искажения данных при передаче.

Включение терминаторов ­ Termination. Активные терминаторы могут включаться одним джампером или даже управляться программным сигналом. Терминаторы должны быть включены только на крайних устройствах в цепочке.

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

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

Старт по команде ­ Start on Command, или задержанный старт ­ Delayed Start. При включении этой опции запуск двигателя Устройства выполняется только по команде от хост­адаптера, что Позволяет снизить пик нагрузки блока питания в момент включения. Хост будет запускать устройства последовательно.

Разрешение отключения ­ Enable Disconnection. Выбор этой опции позволяет устройствам отключаться от шины при неготовности данных, что весьма эффективно используется в многозадачном режиме при нескольких периферийных устройствах на шине.

Интерфейс SCSI является параллельным и физически представляет собой плоский кабель с 25­, 50­, 68­контактными Разъемами для подключения периферийных устройств. Шина SCSI содержит восемь линий данных, сопровождаемых линией контроля четности, и девять управляющих линий. Стандарт SCSI определяет два способа передачи сигналов: одно­полярный, или асимметричный (Single ended), и дифференциальный (Differential). В первом случае имеется один провод с нулевым потенциалом («земля»), относительно которого передаются сигналы по линиям данных с уровнями сигналов, соответствующими ТТЛ­логике. При дифференциальной передаче сигнала для

использующие внутренний интерфейс МП (унифицированный канал);

использующие внешний по отношению к МП системный интерфейс.

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

Различают два класса системных интерфейсов: с общей шиной (сигналы адреса и данных мультиплексируются) и с изолированной шиной (раздельные сигналы данных и адреса). Прародителями современных системных шин являются:

Unibus фирмы DEC ( интерфейс с общей шиной ),

Multibus фирмы Intel ( интерфейс с изолированной шиной ).

Шинная архитектура Unibus была разработана фирмой DEC для мини-ЭВМ серии PDP-11. Общая шина для периферийных устройств, памяти и процессора состоит из 56 двунаправленных линий. Unibus поддерживает пересылку одного 16-разрядного слова за 750 нс. Все пересылки инициируются ведущим устройством и подтверждаются принимающим (запоминающим) устройством, что позволяет работать с модулями различного быстродействия. Выбор устройства на роль ведущего является динамической процедурой, поэтому в ответ на запрос периферийного устройства процессор может передать ему управление шиной. Благодаря этой особенности, на основе Unibus возможна разработка мультипроцессорных систем. Unibus позволяет подключать к магистрали большое число устройств, хотя необходимо учитывать снижение надежности по мере увеличения длины магистрали. Данные регистров внешних устройств могут обрабатываться теми же командами, что и данные в памяти. Следует, однако, отметить сложность технической реализации интерфейсных модулей, связанных с пересылкой адресов и данных по одним и тем же линиям.

Свое развитие архитектура Unibus получила в системном интерфейсе NuBus. Интерфейс NuBus (табл. 14.1) был разработан MIT1) совместно с Western Digital в 1979 г. Затем, при участии Texas Instruments, архитектура NuBus была стандартизована IEEE2) (стандарт IEEE 1196-1987) и применялась фирмой Apple в компьютерах Macintosh. В NuBus также используется мультиплексирование адреса и данных. Предусмотрена автоматическая конфигурация. Возможно использование нескольких задатчиков магистрали с децентрализованным арбитражем. Имеется режим блочной передачи данных. К недостаткам NuBus можно отнести слабые возможности режима ПДП, сложный метод обработки прерываний (предусмотрен всего один сигнал запроса прерывания и программный опрос потенциальных источников прерываний).

Альтернативная шинная архитектура Multibus была разработана фирмой Intel. Шина также обеспечивает системную архитектуру с одним или несколькими ведущими узлами и с квитированием установления связи между устройствами, работающими с разной скоростью. Благодаря разделению шины адреса и шины данных, возможны реализации этой архитектуры для процессоров разной разрядности. Существовали 8-разрядный и 16-разрядный варианты архитектуры Multibus для IBM PC. Шина адреса - 20 бит. Multibus подразумевает достаточно простую аппаратную реализацию, однако число устройств, одновременно использующих ресурсы шины, ограничено 16 абонентами. Следует отметить, что скорость обмена на шине Multibus была ниже, чем на шине Unibus.

52. Механизмы доступа к данным.

Язык SQL условно разделяют на интерактивный и встроенный. И если интерактивный SQL функционирует в среде СУБД, то для встроенного языка требуются дополнительные средства связи среды, в которую он встроен, с СУБД: для передачи команд SQL и получения результатов выполнения запросов. Именно этим целям служат интерфейсы доступа к базам данных. Существует несколько основных способов доступа к данным. Подавляющее большинство систем управления базами данных содержит в своем составе библиотеки, предоставляющие специальный прикладной программный интерфейс (Application Programming Interface, API) для доступа к данным этой СУБД. Обычно такой интерфейс представляет собой набор функций, вызываемых из клиентского приложения. В случае настольных СУБД эти функции обеспечивают чтение/запись файлов базы данных, а в случае серверных СУБД инициируют передачу запросов серверу базы данных и получение от сервера результатов выполнения запросов. Библиотеки, содержащие API для доступа к данным серверной СУБД, обычно входят в состав ее клиентского программного обеспечения, устанавливаемого на компьютерах, где функционируют клиентские приложения. Использование клиентского API является наиболее очевидным способом манипуляции данными в приложении. Однако, в этом случае приложение сможет использовать данные СУБД только того

производителя, чьи функции используются, а замена ее на другую повлечет за собой необходимость переписывания значительной части кода приложения (клиентские API и объектные модели не подчиняются никаким стандартам и различны для разных СУБД). Другой способ манипуляции данными в приложении основан на использовании универсальных механизмов доступа к данным.

Универсальный механизм доступа к данным обычно реализуется в виде библиотек и дополнительных модулей, называемых драйверами или провайдерами. Библиотеки предоставляют определенный набор функций, а дополнительные модули осуществляют связь с конкретными СУБД с использованием их API. Наиболее популярными среди универсальных механизмов доступа являются Open Database Connectivity (ODBC), OLE DB и ActiveX Data Objects (ADO).

Вместе интерфейсы ODBC, OLE DB и ADO составляют похожую на иерархическую структуру, где каждый последующий интерфейс может обращаться к данным не только непосредственно, но и с использованием интерфейса более низкого уровня.

ODBC (англ. Open Database Connectivity) — это программный интерфейс (API) доступа к базам данных, разработанный фирмой Microsoft, в сотрудничестве с Simba Technologies на основе спецификаций Call Level Interface (CLI), который разрабатывался[1] организациями SQL Access Group, X/Open и Microsoft. Впоследствии CLI был стандартизован ISO[2]. Стандарт CLI призван унифицировать программное взаимодействие с СУБД, сделать его независимым от поставщика СУБД и программно-аппаратной платформы. C помощью ODBC прикладные программисты могли разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками.

OLE DB (англ. Object Linking and Embedding, Database) — набор интерфейсов, основанных на

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

OLE DB (связывание и внедрение объектов, базы данных, а иногда в литературе встречается как OLEDB или OLE-DB) является API разработанной Microsoft для доступа к различным типам данных, которые хранятся в единой форме. Программа представляет собой набор интерфейсов реализованных с помощью Component Object Model (COM); в данном случае это связано с OLE. Она была разработана в качестве дальнейшего развития и должна прийти на замену и в качестве преемника ODBC, расширяя набор функций для поддержки более широкого круга нереляционных источников данных, таких как объектно ориентированые базы данных или электронные таблицы, и для которых не обязательно использовать SQL.

ADO (от англ. ActiveX Data Objects — «объекты данных ActiveX») — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft (MS Access, MS SQL Server) и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде.

53. Интерфейс ODBC. Функции ODBC.

Open Database Connectivity) — открытый интерфейс баз данных. Необходимость создания ODBC появилась вследствие того, что каждая фирма — разработчица СУБД использовала свой диалект SQL, что делало невозможным обмен данными между двумя БД различных форматов. Поэтому вначале был разработан общий стандарт на SQL, получивший название CLI (Common Language Interface). Затем каждая фирма разрабатывала драйвер перевода своего диалекта SQL в CLI и наоборот.

ODBC предназначена для обеспечения возможности взаимосвязи между различными SQL­ совместимыми БД.

Технология ODBC предусматривает создание дополнительного уровня между приложением и используемой СУБД. В архитектуре ODBC используется один ODBC Driver Manager и несколько ODBC­драйверов, отвечающих за реализацию особенностей доступа к каждой отдельной СУБД. 1. Функция SQLDataSources возвращает список всех источников данных ODBC.

RETCODE SQLDataSources(HENV hEnv, UWORD fDirection, UCHAR * szDSN, SWORD cbDSNMax, SWORD *pcbDSN, UCHAR * szDescription,

SWORD cbDescriptionMax, SWORD * pcbDescription ); hEnv ­ хэндл, возвращаемый функцией SQLAllocEnv();

■технология ODBC позволяет создавать распределенные гетерогенные приложения без учета конкретных СУБД, т.е. приложение становится независимым от СУБД.

Недостатки:

■снижение скорости доступа к данным, что связано с необходимостью трансляции запросов;

■увеличение время обработки запросов, что связано с введением дополнительного программного слоя;

■необходимы предварительная инсталляция и настройка ODBC­драйвера (указание драйвера СУБД, сетевого пути к серверу, базы данных и т.д.) на каждом рабочем месте. Параметры этой настройки являются статическими, т.е. приложение изменить их самостоятельно не может;

■предоставляет доступ только к реляционным SQL­ориентированным БД. OLE DB.

55. Интерфейс JDBC. Функции JDBC. Преимущества и недо-статки JDBC.

JDBCTM ­ это прикладной программный интерфейс (далее API) JavaTM для выполнения SQL­ запросов. Он состоит из множества классов и интерфейсов, написанных на языке Java. JDBC предоставляет стандартный API для разработчиков, использующих базы данных (далее БД). С помощью JDBC можно писать приложения на языке Java, использующие БД.

С помощью JDBC легко отсылать SQL­запросы почти ко всем реляционным БД. Другими словами, использование JDBC API избавляет от необходимости для каждой СУБД (Informix, Oracle и т.д.) писать свое приложение. Достаточно написать одну единственную программу, использующую JDBC API, и эта программа сможет отсылать SQL­запросы к требуемой БД. Кроме того, это проложение будет переносимо на различные платформы.

JDBC расширяет и без того богатую функциональность Java. Например, можно опубликовать в Интернет веб­страницу, содержащую апплет, связанный с БД на сервере. Еще один пример: организация с помощью JDBC может подключить всех сотрудников к одной БД, даже если мы имеем дело с конгломератом операционных систем на рабочих станциях сотрудников ­ Windows, Macintosh, UNIX

JDBC включает четыре компонента:

1.API JDBC — API JDBC™ обеспечивает программируемый доступ к реляционным данным от языка программирования Java™. Используя API JDBC, приложения могут выполнить SQL­ операторы, получить результаты, и распространить, возвращается к базовому источнику данных. API JDBC может также взаимодействовать с многократными источниками данных в распределенной, неоднородной среде.

API JDBC является частью платформы Java, которая включает Java™ Standard Edition (Java™ SE) и Java™ Enterprise Edition (EE Java™). JDBC 4.0 API делится на два пакета: java.sql и javax.sql. Оба пакета включаются в Java SE и платформы EE Java.

2.Менеджер по Драйверу JDBC — JDBC DriverManager class определяет объекты, которые могут соединить приложения Java с драйвером JDBC. DriverManager традиционно была магистраль архитектуры JDBC. Это является довольно маленьким и простым.

Стандартные Пакеты расширения javax.naming и javax.sql позвольте Вам использовать a DataSource объект, зарегистрированный в Именовании Java и Каталоге Interface™ (JNDI) именование службы, чтобы установить соединение с источником данных. Можно использовать любой соединительный механизм, но использование a DataSource объект рекомендуется когда бы ни было возможно.

3.Тестовый Комплект JDBC — тестовый комплект драйвера JDBC помогает Вам решить, что драйверы JDBC выполнят Вашу программу. Эти тесты не являются всесторонними или исчерпывающими, но они действительно осуществляют многие из важных функций в API JDBC.

4.Мост JDBC­ODBC — мост программного обеспечения Java обеспечивает доступ JDBC через драйверы ODBC. Отметьте, что Вы должны загрузить двоичный код ODBC на каждую клиентскую машину, которая использует этот драйвер. В результате драйвер ODBC является самым соответствующим на корпоративной сети, где клиентские установки не являются большой проблемой, или для кода сервера приложений, записанного в Java в трехуровневой архитектуре. Преимуществами JDBC считают:

Лёгкость разработки: разработчик может не знать специфики базы данных, с которой работает;

Код не меняется, если компания переходит на другую базу данных;

Не нужно устанавливать громоздкую клиентскую программу;

К любой базе можно подсоединиться через легко описываемый URL.

56. Интерфейс уровня вызовов Oracle (OCI) – это набор интерфейсов языка C, обеспечивающих взаимодействие с сервером Oracle. Он предоставляет программистам гибкий механизм использования возможностей сервера.

Важным компонентом OCI является набор вызовов, которые позволяют прикладным программам использовать рабочую область, называемую объектным кешем. Объектный кеш – это область памяти на стороне клиента, в которой программы хранят объекты целиком. Это позволяет программам иметь доступ к объектам, не обращаясь к серверу.

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

Функции LNOCI позволяют выполнять следующее.

– Обращаться к объектам сервера с использованием SQL.

– Обращаться, обрабатывать и управлять объектами, расположенными в объектном кеше, через указатели или ссылки REF.

– Преобразовывать даты, числа и строки Oracle в типы данных C.

– Управлять размером объектного кеша.

Создавать временные описания типов. Временные описания типов не хранятся в СУБД постоянно. Необходимо установить совместимость с Oracle 9i или с более поздней версией.

В LNOCI усовершенствован механизм конкурентного доступа, благодаря тому, что в нем разрешена блокировка отдельных объектов. Он улучшает производительность, поддерживая возможность выборки сложных объектов.

Разработчики программ на основе LNOCI могут использовать транслятор объектных типов для создания типов данных С, соответствующих объектным типам Oracle.

OLE DB (англ. Object Linking and Embedding, Database) — набор интерфейсов, основанных на

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

OLE DB (связывание и внедрение объектов, базы данных, а иногда в литературе встречается как OLEDB или OLE­DB) является API разработанной Microsoft для доступа к различным типам данных, которые хранятся в единой форме. Программа представляет собой набор интерфейсов реализованных с помощью Component Object Model (COM); в данном случае это связано с OLE. Она была разработана в качестве дальнейшего развития и должна прийти на замену и в качестве преемника ODBC, расширяя набор функций для поддержки более широкого круга нереляционных источников данных, таких как объектно ориентированые базы данных или электронные таблицы, и для которых не обязательно использовать SQL.

OLE DB отделяет хранилище данных из приложения, которое должно иметь доступ к нему через набор абстракций, которые включают DataSource, сессию, командную строку. Это было сделано потому, что различным приложениям необходим доступ к различным видам и источникам данных и не всегда нужно знать, как получить доступ к методологии функционирования конкретной технологии. OLE DB концептуально разделена на потребителей и поставщиков. Потребителями являются приложения, которым необходим доступ к данным, а поставщик реализует в своем интерфейсе программный компонент и, следовательно, обеспечивает информацией потребителя. OLE DB является частью Microsoft Data Access Components (MDAC). MDAC является группой технологий Microsoft, которые взаимодействуют вместе, как основа, которая позволяет программистам создать единый и всеобщий способ разработки приложений для доступа к данным практически любого хранилища. OLE DB провайдеры могут быть созданы для обеспечения простого доступа к таким хранилищам данных как текстовые файлы и электронные таблицы, вплоть до таких сложных баз данных, как Oracle, SQL Server и Sybase ASE. Он может также обеспечить доступ к иерархическими хранилищами данных таких, как системы электронной почты.

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

Возможности, которые доступны осуществляются посредством использования объектов COM — поставщик OLE DB будет отсылать к карте хранилища данных технологий обеспечивая функциональность для конкретного интерфейса COM. Microsoft описывает наличие интерфейса «конкретного поставщика», поскольку оно не может применяться в зависимости от используемой технологии баз данных. Отметим также, что поставщики могут увеличить возможности хранения данных — таких возможностей, как услуги в терминологии Microsoft.

57. ADO (ActiveX Data Objects ­ объекты данных, построенные как объекты ActiveX) ­ это часть архитектуры универсального доступа к данным от Microsoft. ADO является частью более крупномасштабной технологии под названием MDAC (Microsoft Data Access Components) . Термин MDAC является общим обозначением для всех разработанных компанией Microsoft технологий, связанных с базами данных. К этому набору относятся ADO, OLE DB, ODBC и др.

Технология ADO базируется на возможностях СОМ, а именно интерфейсов OLE DB. OLE DB представляет собой интерфейс системного уровня, обеспечивающий доступ к различным источникам данных, изолируя приложение от вида источника. ADO представляет собой высокоуровневый программный интерфейс для доступа к OLE DB­интерфейсам.ADO содержит набор объектов, используемых для соединения с источником данных, для чтения, добавления, удаления и модификации данных.

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

Технология ADO завоевала популярность у разработчиков, благодаря универсальности ­ базовый набор интерфейсовOLE DB имеется в каждой современной операционной системе Microsoft. Поэтому для обеспечения доступа приложения к данным достаточно лишь правильно указать провайдер соединения ADO и затем переносить программу на любой компьютер, где имеется требуемая база данных и установленная ADO.

Так как технология ADO основана на стандартных интерфейсах СОМ, которые являются системным механизмомWindows, это сокращает общий объем работающего программного кода и позволяет распространять приложения без вспомогательных программ и библиотек.

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

Большинство новых программных продуктов фирмы Microsoft имеет поддержку интерфейса OLE DB, поскольку это интерфейс низкого уровня, построенный на основе COM­технологии и он позволяет использовать в каждом конкретном случае не все элементы интерфейса, а лишь необходимые. Что в свою очередь позволяет добиться компактности и наилучшей скорости взаимодействия с СУБД.