Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Столичная финансово-гуманитарная академия

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Введение в Web подробный полный курс.doc

Скачиваний:

Добавлен:

15.08.2019

Размер:

993.79 Кб

Скачать

☆

Введение в Web-технологии

Глава 1. Распределенные системы

1.1. Сетевые службы

1.2. Технологии клиент-серверного взаимодействия в Internet

1.3. Модели распределенных вычислений

1.4. Технологии распределенных вычислений

1.5. Монитор транзакций

1.6. Файловые системы

1.7. Всемирная паутина

Тест: Web-служба

Глава 2. Компоненты Web-технологий

2.1. Языки разметки

2.2. Кодировка текстовых документов

2.3. Язык HTML

2.4. Язык XML

2.5. Таблица определения типов DTD

2.6. Форматирование Web-страниц

2.7. Языки представления документов с математической нотацией

2.8. Протокол HTTP

2.9. Пространство имен

2.10. Гипермедиа

2.11. Web-сценарии и создание интерактивных Web-страниц

2.12. PHP

2.13. Доступ к XML-документам

2.14. Гиперсвязи (спецификации XLink и XPointer)

Тест: XML

Тест: Пространство имен

Тест: Протокол HTTP

Тест: Команды HTTP

Тест: XML-схема

Глава 3. Web-службы

3.1. Компонентно-ориентированные технологии

3.2. Аплет

3.3. Сервлет

3.4. Технология JSP

3.5. Портал

3.6. Портлет

3.7. Технология CGI

3.8. Технология CORBA

3.9. Протоколы GIOP и IIOP

3.10. Технология EJB

3.11. Технология SOAP

3.12. Технология XML-RPC

3.13. Стандарт UDDI

3.14. Язык WSDL

3.15. Протокол MIME

3.16. Корпоративная сервисная шина ESB

3.17. Сервис-ориентированная архитектура

3.18. Поиск информации в Internet

Тест: Язык IDL

Глава 4. Инструментальные среды

4.1. Платформа J2EE.

4.2. IBM WebSphere

4.3. IBM WebSphere Studio

4.4. IBM WebSphere Application Server

4.5. IBM Tivoli

4.6. Macromedia Flesh

Глава 5. Семантический Web

5.1. Метаданные

5.2. Семантический Web

5.3. Модель метаданных RDF

5.4. Язык RDFS

5.5. Дублинское ядро

5.6. Языки онтологий

5.7. Язык OWL

Тест: Онтология

Сетевые службы

Термином "Сетевая служба" или "Сетевой сервис" принято обозначать, во-первых, программное обеспечение, предоставляющее определенные услуги по обработке информации и/или доступу к ней и взаимодействующее с распределенными клиентскими приложениями через свой внешний интерфейс, во-вторых, собственно услуги и функции, выполняемые службой. Web-службой (Web-сервисом) называют сетевую службу, объединяющую приложения, работающие на базе Web-технологий, с использованием открытых стандартов (таких как XML, SOAP, WSDL и UDDI) в качестве Интернет-протоколов. Другими словами, Веб-службы — это программы, доступ к которым осуществляется через Веб (то есть через протокол HTTP), а обмен данными происходит в формате XML

Примечание 1

По определению консалтинговой компании Stencil Group Web-служба представляет собой свободно связанные, многократно используемые, распределенные компоненты, которые инкапсулируют ряд функций, к которым можно обращаться посредством стандартных Интернет-протоколов.

Рис. 1. Структура сетевой службы

По характеру выполняемых функций можно выделить следующие сетевые службы:

1) обеспечивающие обмен сообщениями между людьми и доступ пользователей к сетевым информационным ресурсам;

2) обеспечивающие разделение информационных ресурсов между приложениями;

3) обеспечивающие обработку информации в распределенной среде и взаимодействие сетевых приложений.

К службам первой группы относятся системы электронной почты (E-mail), средства телеконференций, аудиоконференций, видеоконференций, электронные "доски объявлений", Web-порталы, поисковые системы.

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

В третью группу входят, во-первых, системы клиент-серверной архитектуры, поддерживающие технологии активных серверных страниц, CGI, аплетов и сервлетов, во-вторых, системы с компонентно-ориентированной и сервис-ориентированной архитектурой.

Технологии клиент-серверного взаимодействия в Internet

Под клиент-серверным взаимодействием понимается доступ клиента к ресурсам, имеющимся в серверах, с целью получения хранимой в серверах информации и/или обработки данных с помощью серверных программ. В настоящее время большинство серверов работает под управлением программ либо Internet Information Server (IIS) в среде ОС Windows, либо Apache в среде ОС UNIX. Каждый сервер имеет доменное имя, зарегистрированное в сервере DNS.

Связь обычно осуществляется по протоколу http (HyperText Transfer Protocol). На серверной стороне она реализуется с помощью программы, называемой http-сервером, который обрабатывает запросы, поступающие от браузеров, ищет запрошенный документ и выдает клиенту или содержимое найденного файла, или сообщение об ошибке, если такой файл не был найден или доступ к нему запрещен. Браузер клиента предназначен только для получения и обработки информации с сервера. Воздействие на серверные данные со стороны клиента возможно только с помощью специальных средств, например, на основе технологий CGI или FTP.

Технологии клиент-серверного взаимодействия различаются способом реализации интерактивности и распределением функций между сервером и клиентом.

Преимущества серверного исполнения программ:

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

Недостатки:

опасность перегрузки сервера при большом числе клиентов;
повышенные требования к пропускной способности сети при интерактивной работе пользователей.

К основным Web-технологиям относятся:

включение сценария в HTML-документ (языки сценариев JavaScript, VBScript);
активные серверные страницы (ASP) — сценарий исполняется на сервере;
CGI (Common Gateway Interface) — по каждому запросу сервер создает процесс (приложение) в своем адресном пространстве;
ISAPI (Internet Server Application Programming Interface) — приложения создаются в общем адресном пространстве сервера;
аплеты (Applets) — приложение на Java передается для исполнения клиенту;
сервлеты (Servlets) — приложение на Java исполняется на сервере;
ActiveX — компоненты управления, могут исполняться в узлах сервера или клиента.

Модели распределенных вычислений

О распределенных вычислениях (РВ) говорят, если различные операции по обработке данных в процессе решения задачи выполняются на более чем одном узле сети.

Если в решении задачи участвуют только два узла, то имеем двухзвенную (двухуровневую) клиент-серверную систему РВ В зависимости от того, как поделены между узлами точка доступа, данные и функции обработки данных различают три модели распределенных вычислений:

файловый сервер (FS — File Server);
доступ к удаленным данным (RDA — Remote Data Access);
сервер баз данных (DBS — Data Base Server).

В случае FS территориально разнесены клиентская программа и файловая система. В частности, при этом возникает проблема корректного обновления файлов. Все процессы клиентов и серверов имеют маркеры, содержащие имя файла и маску, в которой указаны права: только чтение атрибутов файла, только чтение самого файла, открытие файла, модификация файла, стирание. Все обращения идут через менеджер маркеров, который отслеживает соблюдение ограничений и разрешает конфликты одновременного обращения для чтения и обновления файлов. Недостаток FS — перегрузка сети из-за необходимости пересылать файлы полностью, хотя пользователю может требоваться только часть файла.

В случае RDA прикладная программа находится в компьютере-клиенте, на сервере размещены СУБД и собственно базы данных. Положительные стороны — уменьшение трафика, возможна унификация интерфейса с сервером на базе языка SQL.

DBS — двухзвенная структура дистанционного управления, основана на разделении прикладных процедур на две части: индивидуальные для каждого пользователя и общие для многих задач. В этой структуре под приложением понимают совокупность именно общих процедур. Эта совокупность обычно представляется на процедурных расширениях SQL и сохраняется в специальном словаре БД. В альтернативных вариантах (например, в RDA) все прикладные процедуры включаются в прикладные программы, и, следовательно, при необходимости их изменения приходится модифицировать практически все прикладное ПО. Показательный пример — изменение законодательства, влияющее на многие процедуры в управлении финансами, подготовке отчетности и т.п. Выделение таких процедур в отдельное приложение облегчает их модификацию. Кроме того, в DBS снижается трафик, так как обмены по сети происходят не для каждой операции с БД, а для каждой транзакции, состоящей из нескольких операций.

Перемещение прикладного программного обеспечения (ПО) или его части на специальный сервер означает образование ApS (Application Server) — трехзвенной системы, известной также под названием сервер приложений, или "монитор транзакций", или система с трехуровневой архитектурой. В ней связь через сеть имеет место как между терминалом пользователя и приложением, так и между приложением и СУБД.

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

Помимо проблемы распределения серверных функций между узлами сети имеется проблема разделения этих функций между многими пользователями автоматизированных информационных систем. Эта проблема решается либо по схеме "один к одному", либо по многопотоковой схеме. В первой из них для каждого активного пользователя создается своя копия СУБД. Во второй СУБД должна обслуживать одновременно многих пользователей. Чтобы эффективно использовать многопотоковую схему в многопроцессорных вычислительных системах, можно иметь СУБД на нескольких процессорах, транзакции между СУБД распределяются программой-диспетчером.

Для реализации многопротокольности разрабатываются специальные технологии. Наиболее известной среди них является технология ODBC (Open Data Base Connectivity) фирмы Microsoft. Фактически ODBC представляет собой библиотеку функций для обращений прикладных программ (ПП) к различным СУБД на основе языка SQL. Из ПП обращение происходит к виртуальной СУБД, в которой с помощью драйверов осуществляется переход к реальной СУБД.

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

Ряд фирм разрабатывает инструментальные средства для создания трехуровневых приложений.

Технологии распределенных вычислений

Совокупность программ организации распределенных вычислений составляет программное обеспечение промежуточного слоя (Middleware). Одно из направлений организации распределенных вычислений в сетях Internet-Intranet основано на создании и использовании программных средств, которые могут работать в различных аппаратно-программных средах. Для совокупности таких средств используют также название многоплатформенная распределенная среда — МРС (crossware).

К технологиям распределенных вычислений относятся технологии мониторов транзакций, MOM (Message-Oriented Middleware), RPC (Remote Procedure Call), CORBA (или ORB - Object Request Broker), DCOM (Distributed Common Object Model), DCE (Distributed Computing Environment), SOAP (Simple Object Access Protocol).

В сравнительно простой объектной технологии MOM связь с серверами асинхронная, используются системные вызовы "послать" и "получить", осуществляющие обмен сообщениями. В отличие от электронной почты здесь обеспечивается связь не между людьми, а между приложениями, при этом часто в реальном масштабе времени. Однако могут быть варианты MOM с очередями, тогда режим on-line необязателен и при передаче не требуется подтверждений.

Широко распространена процедурная блокирующая синхронная технология RPC, предложенная фирмой Sun Microsystems. Вызов удаленных программ подобен вызову функций в языке C. При пересылках на основе транспортных протоколов TCP или UDP данные представляются в едином формате обмена XDR. Синхронность и блокирование означают, что клиент, обратившись к серверу, для продолжения работы ждет ответа от сервера.

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

Для систем распределенных вычислений разработаны специальные языки обмена данными, для RPC это язык IDL (Interface Definition Language), который дает пользователю возможность оперировать различными объектами безотносительно к их расположению в сети. На этом языке можно записывать обращения к серверам приложений.

Удаленная программа в технологии RPC характеризуется следующими атрибутами: имя узла, номер программы (часто это совокупность программ определенного назначения), версия программы (версия — это копия программы, копии создаются для использования в многопользовательском режиме), имя процедуры в программе.

Процедуры, которые пользователь собирается применять, должны быть зарегистрированы в узле-клиенте, т.е. указаны имена узла, программы, процедуры.

Обращение к удаленной программе в соответствии с механизмом RPC начинается с обращения к демону Postmapper, находящемуся в узле-клиенте. В запросе указываются процедура, аргумент, память под результат. Аргумент должен быть единственный, поэтому если аргументов много, то программист должен создать агрегат данных. Демон находит регистрационные данные и с помощью средств транспортного уровня устанавливает соединение и, используя специальные программные модули - стабы, передает запрос серверу (рис. 1). В сервере имеется диспетчер, который находит исполнителя запроса. В ответе сервера содержатся результаты выполнения процедуры.

Рис. 1. Передача данных по технологии RPC

RPC входит во многие системы сетевого ПО. RPC базируется на сетевой файловой системе NFS (для Unix-платформ) и информационной службе NIS — базе данных о конфигурациях всех машин в сети.

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

В архитектуре компонентно-ориентированных систем имеются следующие части:

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

В отличие от RPC, обращения из прикладной программы происходят не сразу к компоненту, а через посредство брокера. Запрос клиента направляется к брокеру. В брокере имеется предварительно сформированный каталог (репозитарий) интерфейсов функций с указанием компонентов-исполнителей. Брокер перенаправляет запрос соответствующему компоненту, после исполнения которого полученные результаты возвращаются клиенту.

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

Одной из объектных сетевых технологий является технология, основанная на спецификациях CORBA (Common Object Request Broker Architecture), разработанных в начале 90-х годов и поддерживаемых ассоциацией ведущих производителей компьютерной техники OMG (Object Management Group).

К компонентно-ориентированным сетевым технологиям относятся также DCOM фирмы Microsoft, ориентированная на операционные системы Windows, и Enterprise JavaBeans (EJB) — технология, ориентированная на язык программирования Java.

Технология DCE реализуется в среде DCE, объединяющей узлы и сети, которые территориально могут быть разнесены на большие расстояния. Среда DCE представляет собой совокупность ячеек, узлы и сети распределены по ячейкам в соответствии с их функциональными связями. В каждой ячейке имеется большой объем разделяемых узлами данных. В ячейке выделяются главный сервер данных и несколько дополнительных серверов с копиями содержимого главного сервера для обеспечения быстрого доступа к данным. При этом доступ к дополнительным серверам разрешен только для чтения. Обновление данных происходит в главном сервере. Ячейка может занимать значительную территорию, главный сервер обычно размещается вблизи от центра ячейки, дополнительные серверы — по периферии.

В структуре DCE можно выделить следующие части. Для управления данными используется распределенная файловая система DFS (Distributed File Service). Служба директорий используется для определения адресов узлов, в частности, включает службу Domain Name Service (DNS), применяемую в Internet. Служба безопасности предназначена для аутентификации и авторизации пользователей, шифрования и дешифрования передаваемых данных. Синхронизация работы узлов в сети возлагается на службу времени. Имеется также служба обеспечения множественного доступа к серверам (Threads Service). Технология DCE может использоваться совместно с другими технологиям распределенных вычислений, например, с технологиями RPC или ORB. Так, для обмена данными в DCE от организации OSF (Open Software Foundation) используется механизм RPC. Определение нужного сервера в DCE либо происходит автоматически через ORB, либо возлагается на программиста, как в RPC.

Для корпоративных систем больших предприятий характерно использование многих программ и программных систем, относящихся к различным аппаратно-программным платформам. В такой гетерогенной среде организация распределенных вычислений обычно вызывает определенные затруднения. Кроме того, связь по технологиям RPC или CORBA происходит только по инициативе клиента. Наличие выделяемых для DCOM или CORBA отдельных портов затрудняет решение проблемы защищенности сети от несанкционированных воздействий. Решение возникающих проблем видится в использовании сервис-ориентированных архитектур распределенных систем.

Монитор транзакций

Монитор транзакций — программный продукт, предназначенный для контроля целостности данных при выполнении транзакций данных.

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

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

Файловые системы

Хранение программ и данных и доступ к ним в распределенных системах являются функциями файловой системы [1]. Файловая система размещается в одном или нескольких узлах компьютерной сети.

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

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

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

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

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

Важной проблемой, связанной со способами именования файлов, является обеспечение независимости от расположения (прозрачности расположения), т.е. возможности перемещения файлов между файл-серверами без изменения имен файлов.

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

Другой проблемой организации распределенных систем является разделение файлов многими пользователями. Один из способов разделения в случае единственного файл-сервера - последовательная обработка обращений к серверу, т.е. считывается всегда последний вариант изменяемого файла. Можно запретить модификацию файлов, но разрешить обновлять каталоги. Тогда изменение файла сводится к созданию нового файла с возможной заменой старого файла.

При создании распределенных систем требуется распределение серверных и клиентских функций между машинами. Некоторые системы (например, NFS) являются одноранговыми, т.е. отсутствует различие между клиентом и сервером, на всех машинах работает одно и то же базовое программное обеспечение. В другом варианте клиенты и серверы - это принципиально различные машины, как с точки зрения аппаратуры, так и программного обеспечения. Часто файловый сервер - это только пользовательская программа, и система может быть сконфигурирована как клиент, как сервер или как клиент и сервер одновременно. Т

Постоянный поиск имен, особенно при использовании нескольких серверов каталогов, может приводить к большим накладным расходам. В некоторых системах делается попытка улучшить производительность за счет кэширования имен. При открытии файла кэш проверяется на наличие в нем нужного имени. Если оно там есть, то этап поиска, выполняемый сервером каталогов, пропускается, и двоичный адрес извлекается из кэша.

Кэширование файлов используется для повышения производительности системы. Требуются алгоритмы для определения, какие файлы или их части следует хранить в кэш-памяти. Кэш-память на сервере легко реализуется и совершенно прозрачна для клиента. Хотя кэширование на сервере исключает обмен с диском при каждом доступе, все еще остается обмен по сети. Существует только один путь избавиться от обмена по сети - это кэширование на стороне клиента.

Существует несколько способов размещения кэша в системе.

Можно кэшировать файлы внутри адресного пространства каждого пользовательского процесса. Обычно кэш управляется с помощью библиотеки системных вызов. По мере того, как файлы открываются, закрываются, читаются и записываются, библиотека просто сохраняет наиболее часто используемые файлы. Когда процесс завершается, все модифицированные файлы возвращаются на сервер. Хотя эта схема реализуется с чрезвычайно низкими издержками, она эффективна только тогда, когда отдельные процессы часто повторно открывают и закрывают файлы.

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

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

Следует также отметить, что кэширование на стороне клиента вносит в систему проблему несогласованности данных. Одним из путей решения проблемы согласования является использование алгоритма сквозной записи. Когда кэшируемый элемент (файл или блок) модифицируется, новое значение записывается в кэш и одновременно посылается на сервер. Теперь другой процесс, читающий этот файл, получает самую последнюю версию. Один из недостатков алгоритма сквозной записи состоит в том, что он уменьшает интенсивность сетевого обмена только при чтении, при записи интенсивность сетевого обмена та же самая, что и без кэширования.

Следующим шагом в этом направлении является принятие сессионной семантики, в соответствии с которой запись файла на сервер производится только после его закрытия. Этот алгоритм называется "запись-по-закрытию". Как мы видели раньше, этот путь приводит к тому, что если две копии одного файла кэшируются на разных машинах и последовательно записываются на сервер, то второй записывается поверх первого.

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

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

Всемирная паутина

WWW (World Wide Web — всемирная паутина) — гипертекстовая информационная система сети Internet. Ее краткое название — Web. Появление и развитие WWW стало одним из основных факторов научно-технической революции, порожденной информационными технологиями. Человечество получило новые уникальные средства связи и доступа к распределенным источникам информации.

История Web началась в 1990 г., когда британец Тим Бернерс Ли, работавший в Швейцарии, представил базовые компоненты Web-технологии, как технологии "клиент-сервер". Этими компонентами были протокол HTTP передачи данных между клиентами и сервером, язык разметки HTML для представления передаваемых данных и клиентская программа-браузер для просмотра документов на языке HTML. Дальнейшее развитие Web-технологий привело к созданию глобальной системы накопления, поиска, обработки и интеграции информации с использованием специально разработанных для Web языков, протоколов, программного обеспечения.

Информация, доступная с помощью Web-технологий, оформляется в виде Web-страниц и хранится на серверах сети Internet. Совокупность Web-страниц в определенном узле сети Internet называется сайтом. С помощью гипертекстовых ссылок можно переходить от одного Web-сервера к другому, "путешествуя" по Web-пространству, включающему миллионы сайтов сети Internet и охватывающему весь земной шар. Именно последнее оправдывает название "всемирная паутина".

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

Клиентские программы WWW называют браузерами (brousers). Для просмотра Web-страницы браузер обращается к Web-серверу с запросом. Web-сервер имеет программу, постоянно отслеживающую приход на определенный порт (обычно это порт 80) запросов от клиентов. Сервер, получив запрос от браузера, находит соответствующую запросу Web-страницу и передает содержимое запрошенных Web-страниц или результатов выполнения запрошенных процедур в браузер клиента для просмотра. Протокола HTTP, реализующий взаимодействие сервера и клиента в Web, функционирует на базе одного из транспортных протоколов, обычно это протокол TCP. Популярными серверными программами являются Apache Digital для ОС Unix, Netscape Enterprise Server и Microsoft Internet Information Server (IIS), которые могут работать как в Unix, так и в Windows NT, и Netware Web Server, предназначенный для работы в ОС Netware.

В браузерах имеются команды листания, перехода к предыдущему или последующему документу, печати полученного текста, перехода по гипертекстовой ссылке и т.п. Из браузеров также доступны различные сервисы — передача файлов, электронная почта, телеконференции. Наиболее широкое распространение получили браузеры Netscape Navigator фирмы Netscape Communications, Internet Explorer фирмы Microsoft, HotJava фирмы Sun Microsystems.

Подготовка материалов к включению в Web-страницы заключается в его структурировании и форматировании с помощью языков разметки HTML (Hypertext Markup Language) и/или XML (Extensible Markup Language). Для этого разработан ряд специальных HTML- и XML-редакторов.

Web-служба

Что такое Web-служба?

1. Провайдер, предоставляющий услуги доступа к удаленным ресурсам.

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

3. Услуги и функции, выполняемые службой. работающей на базе Web-технологий.

4. Система компьютерной почтовой связи.

5. Средства авторизации и аутентификации пользователей в информационной системе.

Языки разметки

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

Одним из первых был разработан язык разметки SGML (Standard Generalized Markup Language), представленный в стандарте ISO 8879. Этот язык принят в качестве основного языка оформления технической документации, в том числе интерактивных электронных технических руководств на создаваемые изделия в CALS-технологиях.

В языке SGML определяется структура документов в виде последовательности объектов данных. Объекты данных, представляющие части документа, могут храниться в различных файлах. Стандарт SGML устанавливает такие множества символов и правил для представления информации, которые позволяют различным системам правильно распознавать и идентифицировать эту информацию. Названные множества описывают в отдельной части документа, называемой декларацией DTD (Document Type Decfinition), которую передают вместе с основным SGML-документом. В DTD указывают соответствие символов и их кодов, максимальные длины используемых идентификаторов, способ представления ограничителей для тегов, другие возможные соглашения, синтаксис DTD, а также тип и версию документа. Следовательно, SGML можно назвать метаязыком для семейства конкретных языков разметки. В частности, подмножествами SGML можно считать языки разметки XML и HTML.

Техническое описание в виде SGML-документа включает:

основной файл с техническим руководством, размеченный SGML-тегами;
описание сущностей, если документ относится к группе, в которой используются одни и те же сущности и подразумевается их известность;
словарь для пояснения SGML-тегов;
DTD.

Однако язык SGML сложен для освоения и применения. Поэтому для широкого применения разметки в документах, представляемых в WWW-технологиях, в 1991 г. на базе SGML был разработан упрощенный язык HTML (HyperText Markup Language), а в 1996 г. язык XML (eXtensible Markup Language), который становится в сочетании с HTML основным языком представления документов в различных приложениях.

Язык HTML разработан с целью широкого применения разметки в документах, представляемых в WWW-технологиях.

Описание на языке HTML представляет собой текст в формате ASCII и последовательность включенных в него команд (управляющих кодов), называемых также дескрипторами или тегами. Этот текст называют HTML-документом, или HTML-страницей, или после размещения на Web-сервере — Web-страницей. Теги расставляются в нужных местах исходного текста, они определяют шрифты, переносы, появление графических изображений, ссылки и т.п. При использовании WWW-редакторов вставка команд осуществляется простым нажатием соответствующих клавиш.

Язык XML, как и HTML, считается подмножеством языка SGML. В настоящее время язык XML претендует на роль основного языка представления документов в информационных технологиях, его можно рассматривать как метаязык, служащий основой для создания частных языков разметки в различных приложениях. При этом XML более удобен, чем SGML, что обеспечивается устранением в XML некоторых второстепенных особенностей SGML. Описания на XML легче воспринимаются, приспособлены для использования в современных браузерах при сохранении основных возможностей SGML.

Для конкретных приложений создаются свои варианты XML, называемые XML-словарями или XML-приложениями. Так, для описания текстов со специфической математической символикой разработано XML-приложение OSD (Open Software Description). Для CALS интерес представляет вариант Product Definition eXchange (PDX), посвященный обмену данными. Известны словари для химии (CML — Chemical Markup Language), биологии (BSML — Bioinformatic Sequence Markup Language) и др.

Кодировка текстовых документов

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

Проблемы кодировки текстовых документов в Web-технологиях в основном связаны с отображением текстов на русском языке. В настоящее время используется несколько основных кодировок кириллицы, это КОИ-8, Windows 1251, ISO, Unicode (UTF-8) и некоторые другие.

Восьмибитная кодировка КОИ-8 (KOI8), соответствующая ГОСТ 19768-74, разработана в середине семидесятых годов в СССР и в настоящее время является основным способом кодировки для русифицированных систем на платформе UNIX (например, для http-сервера Apache) и по умолчанию для пересылки сообщений электронной почты на русском языке.

Кодировка Windows 1251 предложена компанией Microsoft и получила довольно широкое распространение.

Кодировка ISO-8859-5 была разработана Комитетом по международным стандартам (International Standards Organization, ISO) и применяется в основном в UNIX-подобных операционных системах.

В набор символов двухбайтной кодировки Unicode (UTF-8) входят буквы практически всех алфавитов мира и множество специальных символов — математических, музыкальных, физических.

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

Язык HTML

Язык разметки HTML (HyperText Markup Language) разработан в 1991 г. с целью широкого применения разметки в документах, представляемых в WWW технологиях.

Собственно команды имеют форму <команда>, где вместо слова "команда" записывается имя команды.

Структура текста в HTML-странице имеет вид:

<TITLE>Заголовок текста</TITLE>

</HEAD>

<BODY>

Текст HTML-документа

</BODY>

</HTML>

В клиентской области окна при просмотре появляется только текст, помещенный между тегами <BODY> и </BODY>. Заголовок между тегами <TITLE> и </TITLE> выполняет лишь служебные функции.

Приведем примеры HTML-тегов. К тегам форматирования текста (тегам компоновки) относятся:

<P> — конец абзаца;
<BR> — перевод строки;
<HR> — перевод строки с печатью горизонтальной линии, разделяющей части текста;
<CENTER> — выравнивание изображения по центру страницы;
<LISTING> Текст </LISTING> — представление листингов программ;
<BLOCKQUOTE> Текст </BLOCKQUOTE> — выделение цитат;
<FONT> — задание типа, размера и цвета используемого шрифта, имена этих параметров (атрибутов) FACE, SIZE и COLOR соответственно.

Теги форматирования символов имеют вид <B>, <I>, <U>; текст между открывающем и закрывающем тегами будет выделен соответственно полужирным шрифтом, курсивом, подчеркиванием.

Для форматирования заголовков используются теги <H1> ... <H6>:

<H1> Текст </H1> — текст печатается наиболее крупным шрифтом, используется для заголовков верхнего уровня;
<H2> Текст </H2> — для заголовков следующего уровня и т.д. вплоть до <H6>;
<PRE> Текст </PRE> — указанный текст представлен заданным при его записи шрифтом.

В HTML имеются теги форматирования списка. Это теги <OL> и <UL>, используемые для выделения пунктов списков с нумерацией или с пометкой специальным символом (например, *) соответственно. Каждый пункт в списке должен начинаться с тега <LI>. В словарях и глоссариях удобно применять тег <DL>, отмечающий начало списка, теги <DT> и <DD>, отмечающие очередной новый термин словаря и определяющий его текст соответственно.

В командах вставки графики и гипертекстовых ссылок используются адреса вставляемого или ссылочного материала, называемые URL (Uniform Resourse Locator). Ссылаться можно как на определенные места в том же документе, в котором поставлена ссылка, так и на другие файлы, находящиеся в любом месте сети. Перед простановкой внутренней ссылки, т.е. ссылки на некоторую позицию в данном файле, нужно разместить метку в этой позиции. Тогда URL есть указание этой метки, например, URL=#a35 есть ссылка на метку a35. URL может представлять собой имя файла в данном узле сети или IP-имя другого узла с указанием местоположения файла в этом узле и, возможно, также метки внутри этого файла.

Строка гипертекстовой ссылки в HTML-документе имеет вид:

<A HREF="URL">Текст</A>

Текст, указанный в этой строке и отображаемый на экране дисплея, будет выделен цветом или подчеркиванием. Можно ссылаться на определенное место в документе. Тогда ссылка имеет вид:

<A HREF="URL#метка">Текст</A>

Сама метка в документе имеет вид:

<A NAME="метка">Текст</A>

Ссылки на фрагменты данного документа можно упростить:

<A HREF="#метка">Текст</A>

Тег вставки графического изображения:

Здесь URL указывает адрес графического изображения, ALIGN — параметр выравнивания, указывает место в окне для расположения рисунка; ALT — параметр, задающий текст, который выводится на экран вместо рисунка в текстовых браузерах. Например:

Кроме параметров ALIGN и ALT можно использовать параметры HEIGHT и WIDTH, задающие высоту и ширину изображения (в пикселах), HSPACE и VSPACE, определяющие размер промежутка между изображением и границами страницы в горизонтальном и вертикальном направлениях, BORDER, задающий рамку вокруг изображения. Сами изображения должны быть в определенном формате (обычно это форматы GIF или JPEG).

Экран может быть разделен на несколько окон (областей, фреймов) с помощью парного тега <FRAMESET>. В каждом окне помещается содержимое файла (текст, изображение) указанием источника в теге <FRAME>, например:

Представление таблиц выполняется с помощью тегов формирования таблиц. Парные теги <TABLE> и </TABLE> служат для указания начала и конца таблицы; <TH> и </TH> — то же для шапки таблицы; <TR> и </TR> — для строки таблицы; <TD> и </TD> — для элемента таблицы. Для форматирования таблиц используются параметры, записываемые в открывающих тегах и задающие цвет фона, ширину таблицы, расположение текста в ячейках.

Имеются возможности создания на Web-странице формы, в которую пользователи могут заносить информацию, передаваемую браузером на сервер (тег <FORM>) или управляющую выбором из меню (тег <INPUT>).

Поскольку в языке HTML множество тегов ограниченное и фиксированное, действия, предусматриваемые ими, в частности, операции форматирования, реализованы в браузерах. При этом тегам, подобным <H1>, соответствует определенный стиль (тип, размер, цвет шрифта). Чтобы дать возможность пользователям устанавливать желаемый стиль изображения, разрабатывают таблицы стилей, представляющие информацию о параметрах стиля, и способы связывания таких таблиц с HTML-документом. Большинство браузеров поддерживают каскадные таблицы стилей CSS (Cascading Style Sheet).

Таблица CSS состоит из правил форматирования. В каждом правиле указываются тип элемента, к которому относится форматирование, и список объявлений. Список обрамляется фигурными скобками, объявления в списке разделяются точками с запятой. Каждое объявление задает значение одного из свойств отображения элемента в виде свойство:значение. К свойствам относятся тип (гарнитура), размер, цвет, способ выравнивания и стиль (обычный, полужирный, курсив) шрифта, цвет или рисунок фона, межстрочные интервалы, наличие рамок, взаимное расположение блоков текста и другие характеристики, обычные для управления видом изображения в текстовых редакторах. Можно вместо типа элемента указать имя оригинального вводимого стиля, имя стиля должно начинаться с точки.

Использование таблицы стилей подразумевает указание типа таблицы в разделе <HEAD> HTML-документа. Там же между тегами <STYLE> и </STYLE> записываются правила форматирования. Можно все правила форматирования записать в отдельном файле и тогда в HTML-документе достаточно сослаться на этот файл в специальном теге <LINK>. Если вводимый стиль относится лишь к части документа, используется тег <SPAN> с параметром CLASS, например:

<SPAN CLASS="имя_вводимого_стиля">Часть документа</SPAN>

Первые версии языка HTML были достаточно простыми, но не лишенными ряда недостатков. Прежде всего нужно отметить ограниченность набора тегов, что не соответствует потребностям многих приложений. Кроме того, в тегах HTML не отделены данные, задающие структуру документа, от данных по его изображению (форматированию) на экране дисплея при просмотре с помощью браузера, что затрудняет работу с документами. В результате в новые версии языка стали вводится усовершенствования, что заметно усложнило язык, но не устранило основные недостатки. Наиболее существенными недостатками HTML являются, во-первых, невозможность отделить информацию о структуре документа от информации о форматировании, во-вторых, отсутствие в языке HTML средств, позволяющих производить такие операции обработки текста, как сортировка, поиск фрагментов по определенным признакам и т.п.

Поэтому в 1996 г. был предложен новый язык разметки — язык XML (eXtensible Markup Language).

Кроме того, было разработано расширение DHTML (Dynamic Hyper Text Markup Language) языка HTML, названное динамическим языком разметки гипертекста. С помощью DHTML можно создавать Web-страницы, включающие интерактивные элементы, анимацию, движущиеся объекты и фон, расположенный под основным содержимым документа, выпадающие меню и т.п. Стандарт DHTML используется для создания скриплетов -- сценариев, обрабатываемых браузером совместно с кодом HTML.

Язык XML

Язык разметки XML (eXtensible Markup Language) разработан в 1996 г. Он, как и HTML, считается подмножеством языка SGML.

В настоящее время язык XML претендует на роль основного языка представления документов в информационных технологиях, его можно рассматривать как метаязык, служащий основой для создания частных языков разметки в различных приложениях. При этом XML более удобен, чем SGML, что обеспечивается устранением в XML некоторых второстепенных особенностей SGML. Описания на XML легче воспринимаются, приспособлены для использования в современных WWW-браузерах при сохранении основных возможностей SGML.

Для конкретных приложений создаются свои варианты XML, называемые XML-словарями или XML-приложениями. Известны словари для химии (CML — Chemical Markup Language), географии GML (Geography Markup Language), математичеких текстов MathML (Mathematical Markup Language), синтаксиса и семантики естественных языков LGML (Linguistics Markup Language), обмена данными по аутентификации и авторизации между системами безопасности SAML (Security Assertion Markup Language), описания голосоввых диалогов между человеком и компьютером VoiceXML и др. Для CALS интерес представляют варианты Product Definition eXchange (PDX) и 3D XML, посвященные обмену данными в CAE/CAD/CAM системах.

XML-документ состоит из пролога, корневого элемента "Документ", собственно и являющегося размеченным документом, таблицы определения типов (декларации DTD) и сведений по форматированию. Документ, сформированный в соответствии с синтаксическими правилами языка XML, при отсутствии DTD называют корректным, а при наличии DTD — валидным. Процессор отказывается от обработки некорректных документов. Отсутствие DTD в корректном документе считается ошибкой, но не препятствует обработке документа.

Пролог начинается со строки:

<?xml version="1.0" дополнения ?>

Эта строка указывает используемую версию языка XML (в данном случае версия 1.0). В эту строку можно в качестве дополнения включить также объявление автономности документа, если не предполагается связывать с документом какие-либо внешние файлы:

<?xml version="1.0" standalone='yes'?>

В дополнениях (или в отдельной команде) может быть указана используемая кодировка, например, encoding='ISO 8859-1'. В пролог могут входить также одна или несколько пустых строк, строки комментария и командные строки. Форма комментария:

Текст комментария может включать любые символы, кроме двух дефисов.

Командные строки являются указанием XML-процессору на обработку документа. Они имеют вид:

<?команда?>

Элемент "Документ" представляет собой иерархически организованное множество элементов, являющихся размеченными фрагментами исходного документа. Фрагменты документа помещаются в контейнеры XML, обрамленные каждый открывающим <тип> и закрывающим </тип> тегами, где вместо слова "тип" записывается конкретный тип элемента. Типы элементов задаются в декларации DTD. Фрагменты могут иметь те или иные атрибуты (параметры), значения которых записываются внутри открывающего тега, т.е. тег имеет вид <тип атрибуты>.

Декларация DTD выполняет ту же роль, что и в языке SGML. В ней указываются средства разметки, с помощью которых структурируют исходный документ. Декларация может быть помещена в отдельный файл и тогда в прологе нужно указать XML-процессору имя этого файла с помощью строки

<!DOCTYPE имя_документа SYSTEM "имя_файла_DTD">

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

Инструкции по форматированию документа, необходимые для его визуализации с помощью браузера, могут быть заданы несколькими способами. Один из них — использование каскадных таблиц стилей CSS, таких же, какие используют для HTML-документов. В этих таблицах для каждого типа элемента указаны способы визуализации — тип, размер, цвет шрифта, расположение на экране дисплея при просмотре. Таблица CSS помещается в отдельный файл. Ссылка на этот файл в XML-документе размещается в прологе и имеет вид:

<?xml-stylesheet type="text/css" href="имя_файла"?>

Здесь имя_файла — имя файла с таблицей CSS, это имя должно иметь расширение .css.

Пример пролога XML-документа:

<?xml version="1.0" ?>

<?xml-stylesheet type="text/css" href="dict.css"?>

<!DOCTYPE dictionary SYSTEM "dict.dtd">

В заголовке записаны номер используемой версии языка XML (version="1.0"), имя документа (в нашем примере dictionary), ссылки на файлы, в которых размещены таблицы CSS (файл dict.css) и DTD (файл dict.dtd):

Основные рассмотренные свойства XML-документов поясним следующим примером. Пусть исходный неразмеченный документ представляет собой фрагмент словаря, состоящий из трех пунктов (в нашем примере названия пунктов CALS, Ethernet, PDM). Каждый пункт относится к одному из понятий определенной предметной области и включает название понятия, его краткое определение и возможно некоторые поясняющие примеры.

Целесообразно использовать иерархическую структуру документа: верхний уровень относится к пунктам словаря, нижний уровень относится к элементам пункта. Принятая структура отражается в DTD.

После разметки исходного текста получаем XML-документ следующего вида:

<?xml version="1.0" ?>

<?xml-stylesheet type="text/css" href="dict.css"?>

<!DOCTYPE dictionary [

<!ELEMENT dictionary (item)>

<!ELEMENT item (termin,description,examples?)>

<!ELEMENT termin (#PCDATA)>

<!ATTLIST termin number ID #REQUIRED>

<!ATTLIST termin group (technology|networks|software|other) #REQUIRED>

<!ELEMENT description (#PCDATA)>

<!ELEMENT examples (#PCDATA)>

<!ENTITY ЛВС "локальная вычислительная сеть">

<item>

<description> - Continuous Acquisition and Lifecycle Support,

информационное сопровождение и поддержка этапов жизненного цикла

промышленных изделий. Технология взаимодействия различных

автоматизированных систем в промышленности.

</description>

</item>

<item>

<termin number ='_24' group='networks'> Ethernet </termin>

<description> - &ЛВС с методом доступа МДКН/ОК.

</description>

<examples> Варианты реализации 10Base-5, 10 Base-T, 100Base-X. Gigabit Ethernet.

</examples>

</item>

<item>

<description> - Product Data Management, управление проектными данными.

Системы PDM, называемые также системными средами, входят в состав

программного обеспечения CALS-технологий.

</description>

<examples> Windchill eSeries,iMAN, SmartTeam, Optegra.

</examples>

</item>

</dictionary>

В приведенном примере XML-документа атрибут number относится к маркерному типу. Его идентификатор ID означает, что этот атрибут должен иметь уникальные значения для каждого элемента termin, т.е. number является ключевым атрибутом (значения типа ID не должны начинаться с цифры, поэтому в примере используется знак подчеркивания).

В нашем примере XML-документа dictionary используются каскадные таблицы стилей. Пусть мы хотим элементы типа termin выделить полужирным шрифтом (bold) 12-го размера с отступом первой строки на 5 мм, а элементы типа examples — курсивом (italic) 10-го размера с отступом на 10 мм. Тогда таблица CSS, помещаемая в файл dict.css, должна быть задана в виде:

item

{display:block;}

termin

{font-weight:bold; font-size:12pt; text-indent:5mm; font-style:normal;}

description

{font-size:12pt;}

examples

{display:block; font-style:italic; font-size:10pt; text-indent:10mm;}

Обращение к браузеру для просмотра нашего документа позволит увидеть текст, представленный на рис. 1.

Рис. 1. Пример XML-документа

Часто возникает необходимость включения в XML-документ символов, отсутствующих на клавиатуре компьютера (например, буквы греческого алфавита) или на символы, относящиеся к служебным символам языка. На них следует ссылаться с помощью записи &#код_символа_по_ISO/IEC10646;.

Кроме того, для символов &, <, >, ', " можно использовать ссылки &, <, >, ', " соответственно.

В языке XML расширены возможности гиперсвязей. Механизм связей в XML изложен в спецификациях XLink и XPointer.

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

К функциям программного обеспечения, поддерживающего XML, кроме синтаксического анализа и визуализации, относятся поиск заданных фрагментов, создание, удаление, модификация элементов в XML-документе. Для поддержки этих функций в рабочей группе W3C, занимающейся вопросами Web-технологий, разрабатывается объектная модель HTML и XML-документов DOM (Document Object Model), предназначенная для создания прикладного интерфейса API (Application Program Interface) к XML-документам, и соответствующие языки запросов XPath (XML Path Language), XQuery, XSLT, позволяющие ссылаться на части XML-документов..

Таблица определения типов DTD

Декларация DTD используется для отображения структуры XML-документа и состоит из объявлений используемых в документе типов элементов, атрибутов и сущностей.

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

<!ELEMENT тип_элемента содержание>

Содержание — либо тип содержимого элемента (модель элемента), либо список типов элементов, вложенных в данный элемент в иерархической структуре:

<!ELEMENT тип_элемента (#PCDATA)>

<!ELEMENT тип_элемента (список_типов_вложенных_элементов)>

Модель элемента (#PCDATA) означает, что элемент может состоять только из символьных данных, модель ANY допускает любые данные, а модель EMPTY соответствует пустому (бесконтейнерному) элементу. Возможен также смешанный тип содержимого, когда элемент может содержать и символьные данные, и вложенные элементы (т.е. одним из пунктов списка вложенных элементов будет #PCDATA).

Пример описания типов элементов в DTD (назначение знаков + и ?, имеющихся в примере, будет пояснено ниже):

<!ELEMENT metadata (name, authors, type, description,

owner?, year?, price?)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT authors (#PCDATA)+>

<!ELEMENT type (#PCDATA)>

<!ELEMENT description (#PCDATA)>

<!ELEMENT owner (#PCDATA)>

<!ELEMENT year (#PCDATA)?>

<!ELEMENT price (#PCDATA)?>

Атрибуты служат для характеристики типов элементов. С помощью типов элементов и значений их атрибутов можно сортировать части документа, устанавливать между ними отношения, выделять нужные экземпляры и т.п. Объявление атрибутов, относящихся к определенному типу элементов, имеет вид:

<!ATTLIST тип_элемента имя_атрибута тип_атрибута статус>

Атрибуты могут быть строкового, маркерного или нумерованного типов. Строковый тип обозначается CDATA и соответствует типу данных string, т.е. атрибут типа CDATA в документе должен быть записан в виде строки символов в кавычках. Маркерный тип отличается от строкового тем, что на значения атрибута маркерного типа накладываются некоторые ограничения. Имеется несколько вариантов ограничений и для каждого из них выделен определенный идентификатор, записываемый в поле тип_атрибута. Значения атрибута нумерованного типа либо выбираются из конечного списка значений, записанного в поле тип_атрибута, либо представляют собой тексты предопределенного формата (например, форматов HTML, SGML и т.п.), на что указывает запись NOTATION список_форматов в поле тип_атрибута.

Статус может иметь четыре значения (варианта). Вариант #REQUIRED используется, если для соответствующих типов элементов в документе запись значения данного атрибута обязательна. Вариант #IMPLIED используется, если значение атрибута в документе использовать необязательно. Значение "значение_по_умолчанию", записываемое в поле статус, есть значение атрибута, используемое по умолчанию. В случае варианта #FIXED "значение_по_умолчанию" никакое другое значение атрибута, кроме указанного по умолчанию, в документе использовать нельзя.

Отметим, что в одной записи может быть описано более одного атрибута.

Приведем несколько примеров объявлений атрибутов. Предварительно напомним, что размеченный текст в элементе "Документ" состоит из элементов, помещаемых в контейнеры, т.е. между парой тегов. Например, такими тегами могут быть <item> и </item>, <termin> и </termin>, <description> и </description>, <examples> и </examples>. Значения атрибутов могут включаться в открывающий тег, как это сделано для тега <T1> в следующем примере.

Пример 1

<!ATTLIST T1 A1 CDATA #REQUIRED>

Здесь элемент типа T1 имеет атрибут A1, его значения относятся к типу данных CDATA, значение атрибута A1 должно быть указано в открывающем теге каждого элемента типа T1, например:

<T1 A1='high-level'> Программный комплекс CATIA </T1>

Пример 2

<!ATTLIST book title CDATA #REQUIRED author CDATA #IMPLIED

publisher CDATA #REQUIRED>

Элемент типа book имеет три атрибута строкового типа, значения атрибута author указывать необязательно, два других атрибута обязательны.

Пример 3

<!ATTLIST ray color (red|green|blue) "red">

Атрибут color элемента типа ray может обозначать красный, зеленый или синий цвет, по умолчанию задается красный цвет.

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

Блок данных может быть внутренним примитивом, т.е. фразой, непосредственно записываемой в объявлении:

<!ENTITY псевдоним "фраза">

Например, с помощью ENTITY можно вводить аббревиатуры для словосочетаний, как в следующей строке:

<!ENTITY IEEE "Institute of Electrical and Electronics Engineers">

В документе записи вида &IEEE; будут заменены на блок XML-данных Institute of Electrical and Electronics Engineers.

Блок XML-данных может быть внешним файлом, и тогда ссылка есть указание адреса файла:

<!ENTITY псевдоним SYSTEM "адрес_файла">

Например:

<!ENTITY Приложение SYSTEM "http://ifc.com/addition1.xml">

В документе записи вида &Приложение; будут заменены на XML-содержимое файла с указанным адресом.

Несколько сложнее выглядит включение в XML-документ внешних не XML-данных. В этом случае строка ссылки имеет вид:

<!ENTITY псевдоним SYSTEM "адрес_файла" NDATA имя_нотации>

Здесь имя_нотации — описание формата не XML-данных или адрес программы для обработки этих данных.

Например, если нужно внутри элемента типа item разместить рисунок, данные о котором находятся в файле fig.bmp в формате BMP, то в DTD нужно добавить строки

<!ELEMENT place EMPTY>

<!ATTLIST place par ENTITY #REQUIRED>

<!NOTATION BMP SYSTEM "pbrush.exe">

<!ENTITY figure SYSTEM "fig.bmp" NDATA BMP>

Первые две строки объявляют пустой элемент place с атрибутом par маркерного типа, в котором используется идентификатор ENTITY. Назначение идентификатора ENTITY — ограничивать возможные значения атрибута значениями псевдонимов, введенных в DTD. Две следующие строки задают месторасположение графических данных (файл fig.bmp) и способ их обработки (программа pbrush.exe). В самом документе в контейнерах элементов типа item достаточно записать следующую строку, чтобы при визуализации элементов типа item появилось изображение в соответствии с данными файла fig.bmp:

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

<!ENTITY % имя_перечня 'список_атрибутов'>

Список атрибутов записывается по тем же правилам, что и в объявлении ATTLIST.

Нужно сделать ряд дополнительных пояснений особенностей языка XML.

Прежде всего рассмотрим, как в определении типов элементов оформляется содержание в виде списка типов элементов нижнего уровня, вложенных в элемент верхнего уровня.

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

<!ELEMENT item (termin,description,examples)>

В этом случае вложенные типы termin, description, examples должны обязательно присутствовать в каждом элементе верхнего уровня типа item, причем по одному разу и в том же порядке, как они представлены в списке.

Во-вторых, элементы списка можно отделять не запятыми, а символом "вертикальная черта":

<!ELEMENT item (termin|description|examples)>

Теперь в элементе типа item может присутствовать единственный вложенный элемент одного из типов termin, description, examples.

В обоих рассмотренных случаях можно варьировать характером ограничений, используя после элементов списка (или после скобки, закрывающей часть или весь список) соответствующие знаки +, * и ?. Знак + означает, что элемент соответствующего типа (или группа элементов, типы которых перечислены в списке, заключенном в круглые скобки) может присутствовать в элементе верхнего уровня один или более раз. Знак * отличается от знака + тем, что указываемый им тип элемента может отсутствовать в элементе верхнего уровня. Знак ? отличается от знака * тем, что позволяет использовать вложенный элемент не более одного раза. Так, в нашем примере благодаря знаку ? после элемента типа examples, можно не во всех пунктах словаря приводить примеры, что и сделано для пункта с атрибутом number = '_14'. Если бы нам требовалось разрешить произвольные число и порядок следования вложенных элементов, то нужно было бы использовать описание элемента типа item в виде

<!ELEMENT item (termin|description|examples)+>

Форматирование Web-страниц

Под форматированием в языках разметки понимают указание в документе сведений, необходимых для его визуализации. Форматирование определяет вид документа, получаемый в устройстве вывода (обычно на экране дисплея)

Средствами форматирования в Web-технологиях являются каскадные таблицы стилей и языки форматирования. Специально разработанный для XML язык форматирования XSL (eXtensible Stylesheet Language) предоставляет более богатые возможности форматирования по сравнению с каскадными таблицами стилей CSS.

Указания по форматированию, выраженные средствами языка XSL, составляют XSL-таблицу, с помощью которой XML-документ преобразуется в HTML-страницу, отображаемую браузером. Использование XSL обеспечивает ряд преимуществ по сравнению с применением CSS, поскольку появляется возможность сортировать и фильтровать элементы документа при его выводе на экран. Кроме того, изменяя XSL-таблицу, можно один и тот же документ изображать по-разному в соответствии с потребностями конкретной ситуации.

В XSL шаблоны, по которым браузер определяет отображение элементов документа на экране, обрамляются выделенными для этого тегами, например, <xsl:template> и </xsl:template>. Шаблоны содержат правила, в которых указываются типы XML-элементов, к которым правило относится, и задаются инструкции отображения, например, аналогичные принятым в языке HTML. Шаблон может относиться ко всему XML-документу или к его части. В первом случае в теге <xsl:template> указывается атрибут match со значением "/": <xsl:template match="/">. Во втором случае значением атрибута match будет имя типа соответствующего XML-элемента.

В шаблонах можно использовать как HTML-элементы, так и XSL-элементы. Последние имеют вид

<xsl:имя_xsl_элемента имя_параметра="значение_параметра"/>

Например, значениями параметра с именем select могут быть типы отображаемых XML-элементов. В качестве имен XSL-элементов используются value-of (выбор для отображения текущего XML-элемента, тип которого указан в параметре select), for-each (команда отображения всех XML-элементов, тип которых указан в параметре select) и некоторые другие. Нужно отметить, что для сортировки XML-элементов используется параметр order-by, указываемый в XSL-теге <xsl:for-each>.

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

<?xml-stylesheet type="text/xsl" href=путь_к_файлу?>

Языки представления документов с математической нотацией

В базовых HTML и XML средствах недостаточно учтены требования к высококачественному представлению математических текстов в документах (книгах, статьях, учебных материалах, презентациях) с естественно-научным и инженерным содержанием. Поэтому существует и применяется ряд языков и основанных на них программных систем, специально предназначенных для описания документов с математической нотацией. Среди них наиболее известными являются система TEX, XML-приложение MathML (Mathematical Markup Language), а также математические пакеты, такие как Mathematica или Maple.

TEX-технология создана для представления научных документов, включающая одноименный язык программирования и разметки документов, а также совокупность программных средств, поддерживающих этот язык. Различают физическую и логическую разметки. Первая из них используется для форматирования, а вторая для структурирования текста.

Программное обеспечение TEX-технологии представлено рядом программных средств. Это базовая компонента tex, компоненты для создания разнообразных шрифтов Metafont, для подготовки графических иллюстраций MetaPost, для обработки библиографических списков и ссылок bibtex. Эти или подобные им компоненты входят в макропакеты, реализующие TEX-технологию, примерами макропакетов могут служить LATEX, Plain и др.

Несмотря на свою универсальность, TEX-технология имеет и определенные недостатки. Во-первых, она довольно сложна в освоении. Во-вторых, в ней отсутствуют средства для вызова других программ и совместного с ними исполнения. В-третьих, язык TEX не согласован с XML, так как TEX-технология создавалась еще в 80-е годы.

Поэтому при создании учебных материалов с математическими текстами все в большей мере используется язык MathML.

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

Физический тип состоит из элементов представления, а логический тип - из элементов содержания. Элементы представления описывают ориентированную на визуализацию двухмерную структуру математической нотации. К простым элементам относятся цифры, буквы и другие символы Unicode, более сложные элементы образуются комбинированием простых элементов. Как принято в XML, элементы представляют собой символы нотации вместе с парой обрамляющих тегов.

В качестве примера рассмотрим запись на языке MathML простой математической формулы .

<mrow>

<mrow>

<mrow>

<msup>

</msup>

<mfrac>

<mrow>

</mrow>

</mfrac>

</mrow>

</mfenced>

</mrow>

В этом тексте использованы элементы с тегами (токенами) mi, mn и mo, служащими для представления соответственно идентификаторов, чисел и операторов. Элемент mrow предназначен для обозначения последовательности данных с выравниванием по горизонтали. Элемент mfenced используется для ограничения формул различными типами скобок (по умолчанию используются круглые скобки). Элемент msup применяется в выражениях с верхними индексами и имеет два аргумента: основание (в нашем случае a) и показатель (в нашем случае 2). Элемент mfrac используется для описания дроби. Аналогичным образом описываются и другие символы, выражения и уравнения математических текстов.

Разметка содержания отражает иерархическую структуру математических выражений. Эту структуру можно представить в виде графа, каждый узел графа соответствует элементу MathML, листья соответствуют атомарным элементам, таким как числа, символы и т.п. Приведенный выше пример в случае разметки содержания имеет следующий вид:

<mrow>

<apply>

<eq/>

<apply>

<apply>

<plus/>

<apply>

</apply>

<apply>

</apply>

</mrow>

Описание функций, операций и их операндов выполняется в элементе <apply>. Можно заметить, что в контейнере этого элемента используется префиксная форма записи выражений.

Всего для разметки содержания в MathML введено около 120 элементов.

Протокол HTTP

HTTP (HyperText Transfer Protocol) — протокол передачи информации между клиентом и сервером в Web-технологиях. Обмен информацией состоит из запроса клиента и ответа сервера.

Запрос - это сообщение, посылаемое клиентом серверу.

Структура запроса.

Запрос включает в себя следующие указатели:

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

В нижеследующем примере запрашивается выполнение метода POST по отношению к ресурсу, находящемуся по адресу http://www.serv.ru/index.html, в дополнительных данных указаны форматы и кодировка сообщений, которые клиент может принимать. Заголовок завершается пустой строкой. Например:

POST /index.html HTTP/1.0

Host: www.serv.ru

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

После этого может быть записано тело запроса с данными, которые нужно передать обрабатывающему приложению, например, CGI-программе (в случае использования метода POST).

Методы

Названия методов чувствительны к регистру. В список существующих методов входят [1]:

GET, HEAD, PUT, POST, DELETE, LINK, UNLINK, дополнительные-методы.

Клиент всегда оповещается сервером через код статуса ответа, допускается ли применение данного метода для указанного ресурса.

Метод GET служит для получения любой информации, идентифицированной URI Если ресурс генерирует данные, то в ответе будут присутствовать эти данные.

Метод GET изменяется на "условный GET", если сообщение запроса включает в себя поле заголовка "If-Modified-Since". В этом случае содержательный ответ будет только, если ресурс изменялся после даты, указанной в заголовке "If-Modified-Since". Использование условного GET направлено на разгрузку сети, так как он позволяет не передавать по сети избыточную информацию.

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

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

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

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

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

Метод PUT запрашивает сервер о сохранении тела-запроса под URI, равным URI-запроса. Если URI-запроса ссылается на уже существующий ресурс, тело-запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI. Если ресурс с указанным URI не может быть создан или модифицирован, должно быть послано соответствующее сообщение об ошибке.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой-нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в содержании-запроса. Использующий запрос PUT точно знает, какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.

Метод DELETE используется для удаления ресурсов, идентифицированных с помощью URI-запроса.

Метод LINK устанавливает взаимосвязи между существующим ресурсом, указанным в URI-запроса, и другими существующими ресурсами. Отличие метода LINK от остальных методов, допускающих установление ссылок между документами, заключается в том, что метод LINK не позволяет передавать в запросе тела-запроса, и в том, что в результате работы данного метода не создаются новые ресурсы.

Метод UNLINK удаляет одну или более ссылочных взаимосвязей для ресурса, указанного в URI- Запроса.

Поля Заголовка-Запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Структура ответа

Первая часть ответа - строка статуса, содержащая версию протокола HTTP, код статуса и понятный для человека текст, поясняющий этот код. Элементы строки статуса разделены пробелами. Например:

HTTP/1.0 200 OK

После строки статуса следует заголовок ответа, содержащий данные о самом сервере и затребованном документе. Завершает заголовок пустая строка. Например:

Date: Fri, 20 Sep 1996 08:17:58 GMT

Server: NCSA/1.5.2

Last-modified: Mon, 17 Jun 1996 21:53:08 GMT

Content-type: text/html

Content-length: 2482

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

Возможные интерпретации значений кода статуса:

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

Примеры значений кодов-статуса и соответствующих им фраз-объяснений приведены в табл. 1.

Таблица 1

Код-Статуса	Фраза Объяснения
"200"	OK
"201"	Created
"202"	Accepted
"204"	No Content
"304"	Not Modified
"400"	Bad Request
"402"	Payment Required
"403"	Forbidden
"404"	Not Found
"405"	Method Not Allowed
"406"	None Acceptable
"407"	Proxy Authentication Required
"500"	Internal Server Error
"502"	Bad Gateway
"504"	Gateway Timeout

Тело сообщения

Под телом сообщения понимается Содержание-Запроса или Содержание-Ответа соответственно. Тело сообщения, если оно присутствует, посылается в запросе или ответе в формате и кодировке, определяемыми полями заголовка-Содержания.

Тело сообщения включается в запрос, только если метод запроса подразумевает его наличие. Для спецификации HTTP/1.0 такими методами являются POST и PUT.

Что касается сообщений-ответов, наличие тела сообщения в ответе зависит от метода, который был использован в запросе, и Кода-Статуса. Все ответы на запросы HEAD не должны содержать тело сообщения, хотя наличие некоторых полей Заголовка-Сообщения может указывать на возможное присутствие такового. Соответственно, ответы "204 No Content", "304 Not Modified", и "406 None Acceptable" также не должны включать в себя тело сообщения.

Пространство имен

В разных приложениях возможно использование одних и тех же терминов для обозначения своих прикладных понятий. При объединении документов из этих приложений может возникнуть конфликт имен. Чтобы избежать конфликтов, требуется сделать имена разных понятий гарантированно различными. Для определенных приложений можно заранее договориться о именах используемых основных понятий, совокупность таких имен называют пространством имен. Поэтому внутри конкретных приложений конфликты исключаются.

Однако в каждом конкретном документе могут использоваться понятия из разных приложений. Чтобы избежать конфликта имен, применяют составные имена (QNames), состоящие из идентификатора приложения (префикса) и собственно локального имени элемента. В качестве идентификатора приложения рекомендуется использовать ссылку на документ, задающий пространство имен.

Пространство имен XML — это идентифицируемая с помощью ссылки URI коллекция имен, используемых в XML документах для обозначения типов элементов и именования атрибутов.

Ссылка есть URI документа, чаще всего это URL. Вместо громоздкого URI можно использовать его псевдоним. Тогда ссылка имеет вид: псевдоним:локальное_имя

Например: rdfs:class, где rdfs есть псевдоним. Псевдоним связывается с URL пространства имен следующим образом:

<!- для элемента "x" и его содержимого псевдоним "rdfs" заменяет ссылку

http://www.w3.org/2000/01/--></x>

Примеры некоторых часто используемых префиксов:

для XML-схем xsd или xs: namespace URI: http://www.w3.org/2001/XMLSchema#

для модели RDF rdf: namespace URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#

для RDF-схемы rdfs: namespace URI: http://www.w3.org/2000/01/rdf-schema#

для Дублинского ядра dc: namespace URI: http://purl.org/dc/elements/1.1/

для языка онтологий OWL owl: namespace URI: http://www.w3.org/2002/07/owl#

Гипермедиа

Гипертекст представляет собой размеченный обычный текст. Разметка позволяет структурировать документ, ссылаться на элементы данного или других документов. Термин гипертекст был впервые использован Т.Нельсоном в 60-х годах прошлого века, хотя разметку еще раньше использовал В.Буш.

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

Гиперграфика (интерактивная графика) реализуется путем выделения в изображении контактных ("горячих") зон. Выбор мышкой некоторой зоны вызывает действия такие же, как и в случае обычных гиперссылок. Могут использоваться изображения как реальных, так и синтезируемых объектов. Каждое изображение может представлять собой одну гипертекстовую ссылку. Если нужно ссылаться на разные документы, то используется несколько изображений, объединяемых под названием карта изображений. При использовании карт изображений направление перехода по ссылке определяется выбором той или иной части изображения.

Карта изображений состоит из графического файла, содержащего собственно изображение, и текстового файла с расширением map в кодировке ASCII, содержащего список гиперссылок и соответствующих им координат областей изображения. Программа обработки карты изображения (обычно это программа CGI) находит по координатам URL документа и передает извлеченный документ браузеру.

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

Видео- и звуковая информация обычно передается в форматах MPEG или AVI по протоколу UDP.

Web-сценарии и создание интерактивных Web-страниц

Доступ к гипертекстовым документам, расположенным на сервере, осуществляет программное средство, называемое WWW-сервером (Web-сервером). С его помощью осуществляются также обращения к программам, таким как СУБД, электронная таблица, программы моделирования и т.п., организуется интерактивная работа пользователей. Для использования в WWW-серверах предлагается несколько технологий.

Интерактивная работа пользователей сопровождается визуализацией меняющихся изображений, реакцией системы на определенные действия пользователя или иными операциями по обработке информации при просмотре документов. Эти операции выполняются по сценариям, задаваемым на языке программирования. Применяемые при этом технологии различаются как по типу используемого языка, так и по месту исполнения программ, реализующих сценарии, а также по затратам вычислительных ресурсов. К используемым средствам относятся языки HTML, XML, JavaScript, PHP (Personal Home Pages), VBScript, Perl, Java, технологии CGI, ISAPI (Internet Services Application Program Interface), ASP (Active Server Pages) и др.

Сравнительно простые сценарии обычно представляют на языках типа JavaScript, PHP, VBScript или их разновидностях. Язык PHP близок по своему назначению и сложности освоения к языку JavaScript, но мощнее последнего по функциональности (разнообразие типов данных, поддержка ODBC). Очевидно, что браузер должен поддерживать используемый язык сценариев.

Обычно команды сценария непосредственно включаются в HTML-документ, например, c помощью следующего фрагмента

</SCRIPT>

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

Технология ASP появилась в связи с стремлением сделать интерактивность страниц платформно независимой, поскольку в браузерах может не быть поддержки того языка сценариев, который применен в Web-странице. Для этого нужно перенести обработку сценария с клиента на сервер, что и выполнено в ASP. Обычно в ASP обмен данными между браузером и сервером включает запрос из браузера, передачу формы (таблицы) из сервера для ее заполнения пользователем, пересылку заполненной таблицы на сервер, обработку по сценарию в сервере и возвращение в браузер результата в виде HTML-текста без вставок команд сценария. Следует отметить, что ASP — технология компании Microsoft и связана с использованием компонентов AcniveX, что часто неудобно. В Web-порталах преимущественно используется Java и потому чаще используется аналогичная ASP технология JSP (Java Server pages).

Обращение к мультимедийным объектам возможно способом связывания, т.е. использованием обычной ссылки на мультимедийный файл, при этом выбор данной ссылки пользователем означает переход к демонстрации визуальной или воспроизведению звуковой мультимедийной информации. Чаще требуется визуальную мультимедийную информацию внедрять в Web-страницу, отводя для показа данных видео или мультипликации часть изображения (экрана). Для внедрения используют компоненты ActiveX — программы управления некоторыми операциями, например, визуализацией документа, доступом к базе данных и т.п.

Компонент ActiveX добавляется в Web-страницу с помощью элемента <OBJECT>. В элементе указывают код, по которому будет найден нужный компонент ActiveX, и параметры, такие как адрес мультимедийного файла и расположение поля вывода мультимедийной информации на экране дисплея. Средства обработки мультимедийной информации, представленной в файлах большинства известных форматов таких, как AVI, MOV, MPG, МР3, WAV, MID, обычно встроены в браузеры.

Более сложные сценарии требуют использования прикладных программ, написанных на языках программирования Java, C, C++ и т.п. Если прикладная программа специально создается для использования в Web-среде, целесообразно использовать язык Java.

В ряде случаев используемые прикладные программы не являются платформно независимыми и по этой или иным причинам должны исполняться на сервере. В этих случаях используется технология CGI (Common Gateway Interface — простой шлюзовой интерфейс) или ISAPI (Internet Server Application Program Interface).

В CGI и ISAPI прикладная программа исполняется на сервере. Допустимо использовать программы на различных языках программирования (C/C++, Fortran, Perl, Java, Visual Basic, Apple Script и др.). Но для обеспечения интерфейса Web-сервера с прикладной программой необходимо иметь программу-шлюз (посредник), обрабатывающую запросы, которые поступают от браузера, и передающую обработанные запросы браузеру в нужной для него форме. После исполнения прикладной программы (ПП) шлюз преобразует результаты в приемлемую для визуализации форму (в HTML-документ) и передает результаты обратно браузеру, т.е. для каждой ПП нужно иметь соответствующий обработчик.

Если сервер создан на базе Microsoft Internet Information Server, то вместо CGI лучше использовать технологию ISAPI, как более быстродействующую.

Дальнейшее развитие Web-технологий связано с появлением объектно-ориентированного языка программирования Java. Язык Java позволяет создавать аппаратно независимые приложения, ориентированные на применение в системах распределенных вычислений. Программы на языке Java обладают достаточно высокой вычислительной эффективностью. Эти свойства достигнуты за счет двухэтапной обработки исходных модулей. На первом этапе на сервере производится преобразование исходных модулей в платформно независимый промежуточный байт-код методом компиляции. Благодаря использованию компиляции потеря эффективности, присущая интерпретации, оказывается незначительной. На втором этапе программа, представленная в виде байт-кода и называемая аплетом (applet), передается на компьютер клиента вместе с Web-страницей. Браузер клиента начинает выполнение аплета при его обнаружении в полученном HTML-файле.

Обращение к Java-аплетам из браузера возможно с помощью специального элемента <APPLET> или заменяющего его элемента <OBJECT>, например:

элементы <PARAM>

</APPLET>

Элементы <PARAM>, задают параметры, передаваемые в аплет. В одном HTML-файле можно предусмотреть обращения к нескольким аплетам, находящимся в разных узлах сети. Следует однако отметить, что обычно в целях повышения информационной безопасности загружаемому аплету запрещается обновлять и читать файлы, кроме тех, которые находятся на хосте самого аплета.

Чтобы выполнить Java-программу, необязательно передавать ее браузеру. Как и в технологии CGI, она может исполняться на сервере, в этом случае она называется сервлетом. Поскольку использование технологии CGI имеет много ограничений, связанных с проблемами производительности и безопасности, технологии сервлетов и JSP получили более широкое распространение.

Сервлет можно определить как серверную версию аплета, используемую для обработки клиентских запросов на Web-сервере. С точки зрения языка, сервлет можно считать классом Java, не имеющим привязки к конкретным платформе или Web-серверу и взаимодействующим с клиентом по стандартной схеме запрос-ответ. Отличиями технологии сервлетов от технологии CGI являются, во-первых, большая простота реализации сервлетов, благодаря присущей языку Java платформенной независимости. Во-вторых, большая эффективность, связанная с тем, что сервлет в процессе транзакции загружается один раз, в то время как в CGI каждое обращение к прикладной программе из обработчика генерирует новый процесс, на что тратится значительное время работы серверного узла.

Для реализации технологии сервлетов на Web-сервере необходимо иметь виртуальную Java-машину и программу связи Web-сервера с сервлетом (аналогично шлюзам в CGI), называемую Web-контейнером (servlet engine). Функциями Web-контейнера являются управление циклом жизни сервлетов — их создание, установка, активизация/деактивизация, сохранение состояния, уничтожение. Web-контейнер обеспечивает интерфейсы "запрос" и "ответ" с сервлетом. Он заносит данные запроса в некоторый объект req и передает этот объект сервлету вместе с пустым объектом resp. Сервлет обрабатывает информацию, заключенную в req, и оформляет ответ, заполняя объект resp. Контейнер отправляет ответ клиенту через Web-сервер.

Примерами Web-контейнеров могут служить программы Resin, Tomcat, JRun, JServ. Для создания самих сервлетов используется набор инструментальных средств, например JSDK 1.4 (Java Software Development Kit) фирмы Sun Microsystems.

PHP

Язык PHP (Hypertext Preprocessor) — язык программирования, разработанный для использования в Web-технологиях. Описания на PHP могут входить в HTML-документы.

Пример 1

Структура HTML-документа с внедренным PHP-фрагментом:

<html>

<head>

<title>Пример</title>

</head>

<body>

<?php

echo "Внедряемый текст";

</body>

</html>

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

В отличие от JavaScript язык PHP используется для скриптов, выполняемых на сервере. Клиент получает только результат выполнения скрипта. Можно сконфигурировать сервер таким образом, чтобы HTML-файлы обрабатывались процессором PHP, так что клиенты даже не смогут узнать, получают ли они обычный HTML-файл или результат выполнения скрипта.

Язык PHP довольно прост, тем не менее способен удовлетворить запросы профессиональных программистов. Хотя PHP, главным образом, предназначен для работы в среде web-серверов, область его применения не ограничивается только этим.

Доступ к XML-документам

Для доступа к XML-документам разработаны объектная модель документа DOM и языки запросов XPath и XQuery.

Спецификация DOM, предложенная консорциумом W3C, вводит модель XML-документа DOM в виде иерархии его элементов и язык запросов XPath (XML Path Language), позволяющий ссылаться на части XML-документов (на те или иные элементы).

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

XPath обеспечивает синтаксис и семантику для запросов и ссылок на содержимое XML-документов. Если язык SQL служит для обращений к содержимому реляционных баз данных, то язык XPath предназначен для обращений к содержимому баз XML-документов. Выражение XPath представляют собой указание пути к узлу XML-документа в иерархической DOM-модели этого документа. Так, запрос "найти элементы 'termin' " при обращении к словарю приведенного в "Язык XML" примера с помощью XPath-выражения dictionary/item/termin позволит получить список всех терминов словаря, а запрос dictionary/item/termin[@group='networks'] список только тех терминов, у которых атрибут group равен 'networks'.

Список некоторых операций и операторов языка XPath приведен в табл. 1.

Таблица 1

Оператор	Описание
/	Выбирает дочерние элементы коллекции, находящейся слева от него. При использовании в начале шаблона означает поиск от корневого элемента.
//	Рекурсивный спуск; ищет указанный элемент на любой глубине. При использовании в начале шаблона означает рекурсивный поиск от корневого элемента.
.	Текущий контекст.
*	Wildcard, выбирает все элементы, независимо от имени.
@	Атрибут; префикс имени атрибута. При использовании без имени атрибута выбирает все атрибуты, независимо от их имени.
:	Сепаратор пространств имен. Отделяет префикс пространства имен от имени элемента или атрибута.
( )	Группирует операции для явного задания очередности.
[ ]	1. Накладывает фильтр. 2. Используется для индексации коллекции.
+	Сложение.
-	Вычитание.
div	Деление с плавающей точкой (согласно IEEE 754).
*	Умножение.
mod	Возвращает остаток при делении с остатком.

Предложены и другие языки обращений к XML-документам, например гибкий язык запросов XQuery или язык XSLT (XSL Transformations). В языке XQuery запросы представляют собой последовательность выражений, задающих возвращаемые узлы, которыми могут быть элементы и атрибуты XML-документов. Язык XSLT — подмножество XSL, предназначенное для преобразования одних XML-документов в другие документы XML, HTML или документы некоторых других форматов. Как XQuery, так и XSLT используют правила языка XPath. Результатом распространения DOM на мультимедийные данные является язык SMIL — Synchronized Multimedia Integration Language.

При использовании современных Web-браузеров возможна привязка XML-документа к HTML-странице. Например, в Internet Explorer, начиная с пятой версии, для этой цели предусмотрен тег <XML>. Например:

<XML ID="имя_для_доступа_к_XML-документу"

SRC="имя_файла_XML-документа"> </XML>

Сцепление осуществляется с помощью некоторых HTML-тегов, например тега <SPAN>:

<SPAN DATASRC="#имя_для_доступа_к_XML-документу"

DATAFLD="элемент_XML-документа"> </SPAN>

Теперь "элемент_XML-документа" сцеплен с тегом <SPAN> и может быть отображен браузером с помощью записи строки

<SPAN параметры_стиля> элемент_XML-документа </SPAN>

Гиперсвязи (спецификации XLink и XPointer)

В языке XML расширены возможности гиперсвязей, которым посвящены спецификации XLink и XPointer. В XLink описаны связи между документами, в XPointer — связи внутри документа.

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

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

Для простановки ссылок применяют атрибут xlink:type. Этот атрибут, указываемый в элементах размеченного документа, может иметь следующие основные значения:

simple: простая связь;
extended: расширенная связь;
locator: указание на внешний ресурс;
resource: указание на внутренний ресурс;
arc: последовательный обход ресурсов.

Пример простой связи:

<author xmlns:xlink="http://www.w3.org/1999/xlink"

xlink:type="simple"

xlink:href="http://www.library.ru/">

I.Ivanov

</author>

Здесь в элементе author атрибут xlink:href связывает содержание "I.Ivanov" данного элемента с удаленным документом, находящимся по алресу http://www.library.ru/. Следовательно, I.Ivanov становится гиперссылкой на http://www.library.ru/.

Другой пример:

<item xmlns:xlink="http://www.w3.org/1999/xlink"

xlink:type="simple"

xlink:href="unit.xml">

CPU

</item>

В элементе item значение атрибута xlink:href - это относительный URL unit.xml. Этот связующий элемент описывает соединение элемента item текущего документа, содержание которого "CPU", с документом с именем unit.xml, находящимся на том же сервере, в том же каталоге, что и документ, в котором появляется эта связь.

В следующем примере в отличие от предыдущего случая активизация связи происходит автоматически, благодаря атрибуту xlink:actuate="onLoad", а атрибут xlink:show="embed" указывает, что результат будет встроен в текущий документ, а не заменит его:

<IMAGE xmlns:xlink="http://www.w3.org/1999/xlink"

xlink:type="simple" xlink:href="fig.gif"

xlink:actuate="onLoad" xlink:show="embed"/>

Атрибуты actuate и show могут иметь также другие значения. Например, значение onRequest атрибута actuate указывает, что связь должна активироваться только при запросе ее выбором ссылки, как это реализовано в обычных связях HTML. Значение атрибута show, равное replace, также приводит к результату, аналогичному с применением HTML, т.е. к замене текущего документа вызываемым. Если значение show равно new, то активизация связи приводит к открытию нового окна, в котором отображается вызываемый ресурс. Если значение show равно other, то приложение будет искать другую разметку, которая должна объяснить, что делать.

Расширенные связи могут быть многонаправленными и внешними, связывающими удаленные и локальные ресурсы.

Локальный ресурс является частью элемента расширенной связи, значение атрибута xlink:type которого равно resource.

Элемент, ссылающийся на удаленный ресурс, может иметь любое имя, но включать атрибут xlink:type, значением которого является locator. Каждый элемент типа locator содержит атрибут xlink:href, значением которого является URI удаленного ресурса.

Сами расширенные связи обозначаются с помощью значения extended атрибута xlink:type:

<device xmlns:xlink="http://www.w3.org/1999/xlink"

xlink:type="extended">

<component1 xlink:type="locator"

xlink:href="http://..."/>

<component2 xlink:type="locator"

xlink:href="http://..."/>

При многонаправленных связях возможны различные пути обхода ресурсов. Участки пути, называемые ребрами (arc), представляются с помощью элементов, у которых значение атрибута xlink:type равно arc. Правила обхода указываются добавлением атрибутов xlink:show и xlink:actuate к элементам типа arc.

Для указания направления обхода используются атрибуты to и from. Сами ресурсы помечаются значениями атрибута xlink:label, например, xlink:label="А". Тогда, если атрибут xlink:from равен A, а атрибут xlink:to равен B, то тогда ребро направляется из ресурса, у которого атрибут xlink:label равен A, в ресурс, чей атрибут xlink:label равен B. Например:

<CONNECTION xlink:type="arc"

xlink:from="A"

xlink:to="B"

xlink:show="replace"

xlink:actuate="onRequest"/>

XML

Что такое "элемент данных" и как он представляется в XML-документе?

Пространство имен

Что означает фраза <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema#"> в XML-документе?

Ответ

Протокол HTTP

Для чего предназначен протокол HTTP?

Ответ

Команды HTTP

Назовите основные команды протокола HTTP. Их назначение?

Ответ

XML-схема

Задана объектная модель документа (DOM) в виде рис. 1:

Рис. 1. Модель документа

Представьте эту модель в виде XML-схемы.

Ответ

Компонентно-ориентированные технологии

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

Компиляция программ из готовых компонентов — идея не новая. Уже первые шаги в области автоматизации программирования были связаны с созданием библиотек подпрограмм. Конечно, для объединения этих подпрограмм в конкретные прикладные программы требовалась ручная разработка значительной части программного кода на языках третьего поколения. Упрощение и ускорение разработки прикладного ПО достигается с помощью языков четвертого поколения (4GL), но имеющиеся системы на их основе являются специализированными и не претендуют на взаимодействие друг с другом.

Современные системы интеграции ПО построены на базе объектной методологии. Так, имеются библиотеки классов, применяя которые прикладные программисты могут создавать субклассы в соответствии с возможностями наследования, заложенными в используемые объектно-ориентированные языки программирования. При этом интероперабельность компонентов в сетевых технологиях достигается с помощью механизмов, подобных удаленному вызову процедур RPC. К библиотекам классов относятся MFC, библиотеки для доступа к реляционным БД (например, для встраивания в прикладную программу драйверов ODBC) и др.

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

В то же время в компонентах библиотек классов спецификации интерфейсов не отделены от собственно кода, следовательно, использование библиотек классов не профессиональными программистами проблематично. Именно стремление устранить этот недостаток привело к появлению CBD — компонентно-ориентированных технологий разработки ПО. Составными частями таких технологий являются унифицированные способы интеграции программного обеспечения.

Возможны два способа включения компонентов (модулей) в прикладную программу — модернизация (reenginering) или инкапсуляция (encapsulation или wrapping).

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

Инкапсуляция выполняется включением модуля в среду с помощью интерфейса — его внешнего окружения (оболочки — wrapper). При этом компонент рассматривается как "черный ящик": спецификации, определяющие интерфейс, выделены из модуля, а детали внутреннего содержимого скрыты от пользователя. Обычно компоненты поставляются в готовом для использования виде скомпилированного двоичного кода. Обращения к модулю возможны только через его интерфейс. В спецификации интерфейса включаются необходимые для интероперабельности сведения о характеристиках модуля — модульная абстракция. В состав этих сведений могут входить описания всех входных и выходных для модуля данных (в том числе имеющихся в модуле интерактивных команд), структура командной строки для инициализации процедур, сведения о требуемых ресурсах.

Компонентно-ориентированные системы построены на основе инкапсуляции компонентов. В архитектуре этих систем можно выделить следующие части:

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

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

Схематично взаимодействие компонентов можно представить следующим образом. Клиент обращается с запросом на выполнение некоторой процедуры. Запрос направляется к посреднику. В посреднике имеется предварительно сформированный каталог (реестр или репозитарий) интерфейсов процедур с указанием компонентов-исполнителей. Посредник перенаправляет запрос соответствующему исполнителю. Исполнитель может запросить параметры процедуры. После выполнения процедуры полученные результаты возвращаются клиенту.

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

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

Наиболее популярными в 90-е годы были следующие CBD-технологии.

CORBA — технология, основанная на разработанных в начале 90-х г.г.спецификациях консорциума OMG, в который вошли представители ведущих компьютерных фирм. В CORBA реализуется технология распределенных вычислений на базе программ-посредников ORB.

COM (Common Object Model) — технология, развиваемая корпорацией Microsoft на базе механизма OLE. Сетевой вариант этой технологии (для систем распределенных вычислений) известен под названием DCOM (Distributed COM). Объекты DCOM (в частности, объекты, которые можно вставлять в HTML-документы или к которым можно обращаться из Web-браузеров) известны под названием компонентов ActiveX. В COM/DCOM, как и в CORBA , можно использовать компоненты, написанные на разных объектно-ориентированных языках программирования. Но в отличие от CORBA в COM/DCOM остается естественная для Microsoft ориентация только на операционные системы Windows. Технология ActiveX (прежнее название OLE Automation) обеспечивает интерфейс для управления объектами одного приложения из другого. В общем плане ActiveX — технология интеграции программного обеспечения фирмы Microsoft. Например, используя эту технологию, можно в среде VBA организовать доступ к объектам AutoCAD.

В технологии COM/DCOM все объекты сгруппированы в классы и каждый класс имеет свой идентификатор CLSID, а каждый интерфейс (метод) класса — свой идентификатор. Для создания объекта (экземпляра класса) клиент обращается к серверу библиотеки COM с указанием CLSID и идентификаторов всех требуемых интерфейсов. Сервер библиотеки COM находит в таблице-реестре по CLSID адрес удаленной машины, на которой размещен запрошенный компонент, и передает ей запрос клиента. На серверной стороне создается объект (копия компонента), он активируется и возвращает клиенту указатели-ссылки на требуемые интерфейсы. Теперь клиент может многократно обращаться к методам объекта, указывая в своих запросах имена интерфейса, методов и их параметров. Обычно объект исполняется на той машине, на которой размещен компонент, но можно выбрать и другую машину, указав в запросе, например, ее IP-адрес.

В настоящее время технология DCOM считается устаревшей в связи с разработкой в Microsoft среды и технологии создания программного обеспечения (в том числе распределенных приложений) Microsoft.NET.

Enterprise JavaBeans (EJB) — технология, в которой используются компоненты, написанные на языке Java. Технологию JavaBeans отличают от COM/DCOM две особенности. Во-первых, Java — единственный в JavaBeans язык программирования. Единственность языка и притом объектно-ориентированного обусловливает сравнительную легкость освоения и применения технологии JavaBeans. Во-вторых, технология JavaBeans является платформно-независимой.

Компоненты в JavaBeans являются классами Java. Для их создания, модификации и объединения в прикладные программы имеются специальные средства в составе среды J2EE.

Поэтому в настоящее время все более широкое распространение приобретает технология интеграции Internet-ресурсов, основанная на протоколе SOAP (Simple Object Access Protocol). Это объектная технология, в которой объектами являются Web-службы (Web Services), а для представления обращений к Web-службам используется язык XML. Web-службой называют программный компонент, предоставляющий определенные услуги по обработке информации и взаимодействующий с распределенными клиентскими приложениями через свой внешний интерфейс. Протокол SOAP обеспечивает взаимодействие распределенных систем независимо от типа объектной модели, операционной системы или языка программирования. Благодаря использованию XML, сообщения SOAP могут передаваться посредством транспортного протокола HTTP, как правило, не закрываемого сетевыми экранами.

Пример системы интеграции Internet-ресурсов — система WesSphere Application Server компании IBM. Система поддерживает технологии CORBA и ActiveX, протокол SOAP вместе с WSDL и UDDI. Интеграция основана на использовании средств Java 2 Enterprise Edition (J2EE), позволяющих различным приложениям, написанным нв Java, обмениваться информацией и совместно обрабатывать сложные транзакции.

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

В общем случае компоненты системной среды объединены в несколько сценариев (потоков процедур или маршрутов), в которых выделяются точки входа для вставки специфичных пользовательских фрагментов и расширений. Имеются возможности не только вставки новых фрагментов, но и замены исходных компонентов в потоках процедур на оригинальные с сохранением интерфейса. Собственно многие системы, основанные на применении языков четвертого поколения (4GL), относятся именно к таким системным средам, в которых последовательности инкапсулированных модулей образуются с помощью операторов 4GL.

Аплет

Аплет (applet) -это приложение, передаваемое через Internet и выполняемое на компьютере клиенте Java-совместимым браузером. Аплет представляет собой программу, пересылаемую по сети подобно изображениям, звуковым файлам или видеоклипам. Это программа, которая может реагировать на команды пользователя и динамически изменять свое поведение. Аплеты могут использоваться для создания богатых графикой и интерактивными возможностями пользовательских интерфейсов, которые не способны выразить средствами обычного языка разметки HTML или XML.

Аплеты передаются по сети, автоматически устанавливаются и запускаются как часть HTML-документа. Если аплет доставлен клиенту, его доступ к ресурсам ограничен. Поэтому даже самый сложный аплет с мультимедиа-интерфейсом, предназначенный для выполнения сложных вычислений, не может повредить данные или действовать как вирус. Возможность запуска аплетов без нежелательных побочных явлений (в том числе сохранение неприкосновенности секретных данных) считается многими пользователями одним из важнейших достоинств Java.

Компилятор Java компилирует аплеты в файл с расширением .class. После компиляции аплет включается в файл HTML с помощью дескриптора APPLET. Браузер начнет выполнение аплета при обнаружении в файле HTML элемента вида

</applet

Когда появился язык Java, аплеты обещали стать почти идеальным со всех точек зрения решением: не требуют затрат на установку, соответствуют лозунгу сторонников чистого HTML ("написано однажды — работает везде") и отличаются богатым "родным" графическим пользовательским интерфейсом.

Но до сих пор (2000 г.) эти надежды не сбылись. Проведенный недавно опрос, касающийся использования аплетов Java, показал, что они применяются менее чем на 2% из 500 самых популярных Web-сайтов. Почему? Некоторые разработчики неверно оценили накладные расходы при интерпретации байт-кода в виртуальной машине Java. У других множество нареканий вызывает защита, основанная на принципе "песочницы" (sandbox), который не позволяет Java использовать в полной мере локальные и удаленные службы. Третьи отмечают различия между виртуальными машинами основных браузеров, имеющихся на рынке. Так или иначе по прошествии пяти лет аплеты не оправдали ожиданий, и Web-приложения на базе HTML не были вытеснены Web-приложениями с равным уровнем переносимости и мобильности, но с функционально более мощным графическим пользовательским интерфейсом.

Тем не менее, хотя аплеты не заслуживают той шумихи, которая была поднята при их появлении, они делают немало полезного. Вот несколько ярких примеров.

Пример 1

AnywareOffice компании VistaSource (www.anywareoffice.com). VistaSource использует аплет Java для реализации Applixware, своего популярного офисного пакета, в браузерах, ориентированных на Java. Когда провайдер услуг доступа к приложениям использует AnywareOffice, приложения (такие, как текстовый процессор) работают на сервере, но отображаются в аплете.

Пример 2

QuestAgent компании JObjects (www.jobjects.com). Этот аплет представляет собой кроссплатформный механизм поиска, часто включаемый в состав компакт-диска с публикациями на базе HTML. Браузер может отображать информационное наполнение таких публикаций, но не может выполнять поиск в своем индексе. QuestAgent предлагает мобильный поиск и позволяет отказаться от необходимости создавать и отображать оригинальный механизм поиска.

Пример 3

MindTerm компании Mindbright Technologies (www.mindbright.com). Предположим, что пользователь оказался вне офиса и при нем нет мобильного компьютера, а ему необходимо передать файл на домашний сервер. MindTerm — реализация защищенной версии интерпретатора команд Secure Shell (SSH) на базе Java позволяет преобразовать любой ориентированный на Java браузер в клиент SSH, который можно применять для шифрования сеансов передачи файла.

Сервлет

Сервлет — это самостоятельный компонент программы, который согласно спецификации J2EE функционирует в Web-контейнере, динамически генерируя HTML страницу, XML документ или другой материал в ответ на полученный от клиента запрос. Как правило, такой запрос доставляется сервлету с использованием протокола HTTP. Сервлет является одним из видов "WEB-компонентов", а servlet engine — среда исполнения сервлетов -называется "WEB-контейнером". Сервлет можно рассматривать как серверный аналог аплета Java: и тот, и другой являются Java-программой, оба управляются своими контейнерами (аплет — браузером, сервлет — servlet engine), оба имеют строго определенный цикл жизни.

В общем случае, сервлет — это определенным образом построенный Java класс, не имеющий привязки к какой-либо конкретной платформе или Web-серверу. Сервлеты действуют как мост между бизнес-данными и интерфейсом Web-браузера. В частности, сервлеты используют для доступа к базам данных, программируя все удаленные операции с базой из браузера.

Взаимодействие сервлета с клиентом строится по стандартной схеме запрос-ответ. При этом сам сервлет непосредственно с клиентом не связывается, а в роли посредника, поддерживающего связь с удаленным клиентом, выступает Web-контейнер.

Для выполнения Java-сервлетов требуется установка на сервере Java Virtual Machine (JVM). Кроме того, сервер должен поддерживать Java Servlet API — набор функциональных команд для получения и отправления информации на сервер и с сервера. Технологию сервлетов можно использовать на любом web-сервере, имеющем соответствующую поддержку. С другой стороны, благодаря унификации языка Java, сервлеты можно переносить с одной платформы на другую без какой-либо перекомпиляции. Та же стандартизация подразумевает, что сервлетам всегда будет предоставлен доступ к определенному прикладному интерфейсу на любом сервере приложений. Например, они всегда будут иметь доступ к одной и той же библиотеке JDBC. Далее, использование объектно-ориентированного языка Java дает свободную расширяемость сервлетов. Например, Java класс сервлета контроллера может быть унаследован новым классом и дополнен функциями контроллера безопасности. При этом все старые функции контроллера сохранятся, но будут предоставлены уже по новой схеме безопасности.

Технология JSP

JSP (Java Server Pages) - спецификация, оговаривающая, каким образом на базе сочетания статического HTML, XML-кода, директив и скриптов в ответ на запрос клиента может быть динамически сформирован ответ в виде HTML, XML- или другого документа.

JSP-документы, как и сервлеты, являются WEB-компонентами, которые должны быть установлены в Web-контейнер.

JSP-документы можно рассматривать как более удобное для дизайнера представление сервлета (JSP при установке в WEB-контейнер компилируется в сервлет). Задачи, стоящие перед сервлетами и JSP-документами, абсолютно одинаковы.

Портал

Концепция порталов появилась в процессе развития Web-сайтов. Портал есть ориентированная на пользователя информационная Web-система с единой для каждого конкретного пользователя точкой доступа к разнообразной информации, относящейся к определенному приложению. Порталы, в основном, базируются на технологиях Web-приложений, таких как Web-серверы и Java 2 Platform Enterprise Edition (J2EE). Если Web-сайты в большинстве случаев представляют собой наборы статических Web-страниц, то порталы являются совокупностями программных средств и заранее неструктурированной информации, которую эти средства превращают в структурированные данные по запросу конкретных пользователей.

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

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

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

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

Торговые порталы, такие как eBay и ChemWeb, — это торговые площадки, которые связывают продавцов и покупателей.

Специализированные порталы, такие как портал MySAP.com, предлагают путь доступа к приложениям определенного вида.

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

Особенности порталов, отличающие их от обычных Web-сайтов:

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

Возможности порталов определяются следующими основными функциями и сервисами (рис. 1):

Поиск как по атрибутам (например, предмет, тип материала, уровень образования), так и по ключевым словам.
Средства публикации и рубрикации материалов.
Персонализация и кастомизация. Служба настройки (customization) распознает различных пользователей и предлагает им информационное наполнение, сконфигурированное с учетом их специфических требований. Эта служба основана на сборе информации о пользователях и сообществах пользователей и должна предоставлять нужное информационное наполнение в нужное время.
Наличие раздела новостей, списков рассылки, средства опроса
Доступ к форумам, справочным базам данных, телеконференциям.
Служба агрегирования информационного наполнения (content aggregation) готовит информацию, полученную из различных источников для различных пользователей. Она учитывает ориентированный на конкретного человека контекст, идентифицируя пользователя с помощью службы защиты и службы настройки.
Служба получения информационного наполнения (content syndication) накапливает информацию из различных источников. Поставщики коммерческого информационного наполнения часто предоставляют информацию в стандартизованных форматах, например, распространенная операция — "клиппировать" (вырезать) копирует информацию с существующих Web-сайтов в формате HTML. Портал для сотрудников, к примеру, может вырезать информацию из внутрикорпоративной интранет-сети.
Служба поддержки устройств (multidevice support) готовит информационное наполнение для различных каналов коммуникаций (например, проводные и беспроводные телефоны, пейджеры и факсы), анализируя их характеристические особенности. Как правило, для этого необходимо фильтровать информационное наполнение (скажем, из информации, предназначенной для беспроводного телефона, при этом удаляют все изображения, а для беспроводных соединений WML — преобразуют HTML в нужный язык разметки).

Рис. 1. Основные части и функции порталов

Пользовательский портал должен предоставлять средства коммуникации такие, как электронная почта, файловый обмен, различные виды конференц-связи, участие в телеконференциях и т.п. В образовательных порталах эти средства успешно используются при реализации связей "студент-преподаватель", "студент-деканат", "студент-студент". Особенно они необходимы при дистанционном обучении.

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

Среда для корректного выполнения и взаимодействия всех сервисов портала обеспечивается ядром – сервером приложений (Application Server). В ядро системы интегрированы функции поддержки авторизации и персональной настройки сервисов портала. Логика работы всех сервисов портала реализуется на основе портлетов – специализированных программных модулей на языке Java (преимущество которого – многоплатформность). Портлетами могут являться как самостоятельные компоненты портала, реализующие конкретный сервис, так и интерфейсы (коннекторы) к интегрированным в портал приложениям и источникам данных. Портал может представлять собой мультиагентную систему, тогда функции управления порталом выполняют программные агенты.

В основе портала лежит концепция разделения внутренних и внешних функций системы по блокам и модулям. Любой запрос пользователя к порталу проходит через блок, ответственный за авторизацию, аутентификацию и персонализацию. Далее он поступает в блок маршрутизации, где определяется, с какими параметрами должен быть вызван соответствующий функциональный модуль (портлет). Портлет интерпретирует запрос пользователя и выполняет его, обращаясь к программным подсистемам, базам данных, внешним приложениям и другим источникам через DCOM, JDBC, API, CORBA, HTTP и т. д. Так как в качестве входных данных портлет использует информацию о клиенте и его правах доступа, работа происходит с учетом разделения прав доступа.

Результаты работы портлета представляют собой описание сведений на расширяемом языке разметки данных XML, которое передается блоку, ответственному за их предоставление. Последний форматирует результаты работы портлета с использованием XSL-трансформации на основе различных XSL-шаблонов с учетом персональных предпочтений и типа используемого им клиента: Web-браузер, карманный компьютер, мобильный телефон с поддержкой WAP или какое-либо другое устройство.

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

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

Аутентификация пользователей при входе в систему и их авторизация при доступе к различным ресурсам выполняется отдельными компонентами портала, служащими элементами системы безопасности. Аутентификация основывается на информации LDAP-сервера. Для обеспечения доступа через Web-интерфейс к корпоративной Интранет-сети может учитываться информация о правах доступа домена Windows NT.

Примером системы создания и поддержки порталов может служить система WebSphere Portal Server, предлагаемая корпорацией IBM. В IBM разработан также продукт под названием WebSphere Portal — Express Plus. Дополнительно к типичным функциям пакета WebSphere Portal Server, таким как индивидуальная настройка интерфейса, однократная регистрация для доступа к нескольким приложениям, единый механизм аутентификации и взаимодействия для всех компонентов портала, пакет WebSphere Portal-Express Plus поддерживает коллективное обсуждение вопросов (чат), виртуальные комнаты для семинаров, ведение архива различных материалов с возможностями обмена ими и совместной работы над документами.

Портлет

Портлеты входят в программное обеспечение порталов.

Портлет — это многократно используемый компонент, который содержит в себе некоторые данные, набор собственных бизнес функций и стандартную схему свойств (property schema), определяющую содержание сервиса портлета, в том числе и то, каким образом этот портлет отображается в браузере пользователя. Портлет — это Java-сервлет, который работает внутри портала.

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

J2EE — одна из самых известных серверных компонентных моделей. В J2EE серверные компоненты размещаются в специальных контейнерах (контейнерах компонентов). Контейнер компонентов представляет собой среду исполнения для серверного компонента; он вызывает компонент и предоставляет специфические для компонента службы (например, информация о пользователе и сохранение состояния объекта между сеансами).

Точно так же портлеты размещаются в контейнерах портлетов. API портлетов определяет интерфейс между портлетом и контейнером портлетов.

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

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

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

Ядро портала получает запрос сервлета от контейнера сервлета и преобразует этот запрос в запрос портлета, который оно направляет соответствующему портлету. Портлет должен извлечь информационное наполнение, используя службы портлета, предоставленные сервером порталов. Затем ядро портала объединяет множество ответов портлетов и возвращает ответ сервлета пользователю. Чтобы корректным образом вывести страницу, служба агрегирования должна учесть предпочтения пользователей и возможности устройства.

Поскольку в будущем портлеты будут строиться на основе единого стандарта (прежде всего — это стандартное XML-описание), компании смогут создавать библиотеки этих компонентов для построения корпоративных информационных порталов, а системные администраторы смогут распространять компоненты, используя эти библиотеки.

Две наиболее перспективные технологии создания корпоративных информационных порталов на основе портлетов — это Digital Dashboard от Microsoft и J2EE-портлеты от группы компаний, куда входят Apache Software Foundation, BEA, IBM, iPlanet, Oracle, Epicentric.

Технология CGI

Технология CGI разработана для выполнения на сервере прикладных программ по запросам из браузеров. Определение нужной прикладной программы, ее активация/дезактивация, передача параметров выполняются программой-посредником, иначе называемой шлюзом. Спецификация CGI не зависит от платформы.

Технология CGI обычно реализуется либо с использованием программ, написанных на языке PERL (Practical Extraction and ReportLanguage), либо с помощью приложений, созданных с применением языка С и откомпилированных непосредственно на сервере.

Как правило, посредник CGI находится на сервере в специальном каталоге cgi-bin, он является обработчиком запросов, идущих от браузера. Обращение к каталогу осуществляется по ссылке, например:

ссылочная фраза

</A>

Обычно url_сценария имеет вид http://<имя_сервера>/cgi-bin/<имя_прикладной_программы>. Передаваемые_параметры могут содержаться или в самой ссылке, или в теле HTTP-сообщения (в случае использования методов POST или PUT). Информация о передаваемых_параметрах представляется в следующей форме:

имя=значение&имя1=значение1&..,

где имя- имя переменной, значение - ее реальное значение.

Сервер определяет тип URL, то есть то, что это именно сценарий, а не простой HTML-текст, либо по маршрутному имени ресурса (обычно - каталог cgi-bin), либо по расширению имени файла (обычно *.cgi). Запускается соответствующий обработчик. Выполняется предназначенная для вызова CGI программ функция CreateProcess() с помощью командной строки следующего формата:

WinCGI-exe cgi-data-file

где WinCGI-exe - это полный путь к исполняемой CGI программе; cgi-data-file - полный путь к CGI файлу данных.

Если браузер обращается к документу не в HTML-формате, то посредник преобразует форму документа в HTML-формат и возвращает его браузеру. Пример CGI-программы — WebDBC, организующей связь Web-сервера через ODBC-драйверы с нужными СУБД.

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

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

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

Примечание 1

CGI файл данных состоит из нескольких секций.

Секция [CGI] содержит большинство специфических CGI параметров (тип доступа, тип запроса, дополнительные заголовки, определенные в других секциях и т.п.). Каждое значение представлено в виде символьной строки. Если значение является пустой строкой, то данный параметр был опущен. К числу параметров относятся:

Название и модификация информационного протокола, использованного для передачи данного запроса. Формат: протокол/модификация. Пример: "HTTP/1.0".
Метод, который использовался для данного запроса. Для HTTP это "GET", "HEAD", "POST" и т.д.
Логический путь к исполняемой CGI программе.
Путь к ресурсам, необходимым для выполнения данного запроса, и др.

Секция [Accept] содержит типы данных, посылаемых клиентом, найденные в заголовке запроса в виде Accept: type/subtype {parameters}

Секция [System] содержит параметры, специфические для Windows реализации CGI:

Секция [Extra Headers] содержит "дополнительные" заголовки, которые включены в запрос в виде "параметр=значение". Сервер должен раскодировать как параметр, так и его значение прежде чем они будут помещены в файл данных CGI.

Секция [Form Literal] содержит данные в виде "параметр=значение&параметр=значение&...", полученные по POST из формы и раскодированные сервером.

CGI программа возвращает результат работы, отвечающий (явно или неявно) целям запроса. Сервер кодирует результат работы в соответствии со стандартом HTTP и использует HTTP для отправки результата клиенту. Это означает, что сервер добавляет необходимый HTTP заголовки в сообщение, формируемое CGI программой.

Результат работы CGI программы состоит из двух частей: заголовка и тела сообщения. Заголовок состоит из одной или более строк текста, отделенных от тела пустой строкой. Тело сообщения содержит данные, представленные в MIME формате, указанном в заголовке.

Сервер не изменяет тело документа, что означает, что сервер передает сформированный CGI программой ответ "как он есть".

Главный недостаток технологии CGI - низкая скорость выполнения запросов пользователей.

Альтернативный подход - использование интерфейсов API, например NSAPI (API для Netscape), ISAPI (API для IIS), API для Apache. Суть API-интерфейсов заключается в повышении производительности работы сервера за счет того, что новых полноценных процессов для выполнения запросов не порождается. Главный недостаток API - сложность его использования, поскольку для написания API-приложения необходимы глубокие знания архитектуры сервера и ее реализации.

Технология CORBA

Технология распределенных вычислений CORBA (Common Object Request Broker Architecture) предложена ассоциацией OMG (Object Management Group). Это инвариантная к приложениям и языку программирования компонентно-ориентированная (объектная) сетевая технология. Архитектура CORBA представлена на рис. 1.

Схематично взаимодействие компонентов в технологии CORBA можно представить следующим образом. Клиент обращается с запросом на выполнение некоторой процедуры или получение некоторых данных. Запрос направляется к посреднику, называемому ORB (Object Request Broker), который способен выполнить действия, необходимые для нахождения нужного объекта в сети и его подготовки к обработке запроса. В посреднике имеется предварительно сформированный каталог (реестр или репозитарий) интерфейсов процедур с указанием компонентов-исполнителей. Посредник перенаправляет запрос соответствующему исполнителю. Исполнитель может запросить параметры процедуры. После выполнения процедуры полученные результаты возвращаются клиенту.

Рис. 1. Архитектура CORBA

Для описания интерфейсов и для организации связи клиента с серверными компонентами используется язык IDL (предложенный OMG и не совпадающий с языком IDL в RPC). Язык IDL в CORBA позволяет описывать интерфейсы создаваемых компонентов. Описание, называемое метаданными, представляется в виде модуля метаданных, модуль включает заголовок, описания типов данных, интерфейсов и операций. В заголовке указывается идентификатор модуля. В части типов данных перечисляются атрибуты, возвращаемые значения, исключительные ситуации. Примерами типов данных могут служить типы базовые (например, float, double, char, boolean, struct), конструируемые пользователем (например, записи и массивы) и объектные ссылки, указывающие на интерфейсы компонентов. Описание интерфейсов начинается с ключевого слова interface, за которым следуют идентификаторы данного интерфейса и возможно наследуемых интерфейсов. Далее описываются операции (методы) в виде идентификаторов операций с возможными перечислениями параметров операций и указанием их принадлежности к входным или выходным данным.

Классы объектов (программные модули) должны быть реализованы в CORBA-среде. Для этого компилятор IDL выполняет следующие действия. Во-первых, метаданные для каждого класса объектов помещаются в специальную базу данных, имеющуюся в ORB, — репозитарий интерфейсов. Во-вторых, компилятор создает для каждого определенного на IDL метода клиентский и серверный стабы – программные модули, обеспечивающие доступ к компонентам.

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

Определения интерфейсов хранятся в репозитарии в виде множества объектов, содержащих описания операций, возможных исключительных ситуаций, типов параметров. Репозитарий обеспечивает также механизм доступа к этим объектам. Являясь одной из главных компонент стандарта CORBA, IR поддерживает взаимодействие брокеров различных производителей.

Физически репозитарий интерфейсов является программным компонентом, имеющим собственный IDL-интерфейс. Через этот интерфейс различные приложения и получают данные о других CORBA-объектах.

Спецификация репозитария интерфейсов удобна для построения приложений, в которых данные, параметры и функции могут изменяться во время работы приложений. К этой категории относятся CASE-средства, навигаторы и т.д.

Стабы используются для обеспечения взаимодействия клиента и сервера, функционирующих в разных адресных пространствах или на разных компьютерах (в том числе и в разных операционных системах). В терминологии CORBA они называются stub и skeleton. Stub (стаб) - это представитель сервера в адресном пространстве клиента (иногда для его обозначения используют и термин proxy). Skeleton (скелетон)- это представитель клиента в адресном пространстве сервера.

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

Клиентское приложение взаимодействует со stub-объектом, вызывая его методы (названия которых совпадают с названиями методов серверного объекта). В действительности stub-объект обращается к клиентской части Object Request Broker (ORB), обращающейся, в свою очередь, к специализированному сервису middleware - Smart Agent (он может функционировать на каком-либо из компьютеров сети), представляющему собой не что иное, как directory service - службу, обеспечивающую поиск доступного сервера, содержащего реализацию запрашиваемого клиентом объекта.

Когда сервер найден, в его адресном пространстве создается запрошенный серверный объект, содержащий, в свою очередь, skeleton-объект, которому ORB передает запрос клиента с помощью базового объектного адаптера Basic Object Adapter (BOA). BOA - это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Используя эту службу, skeleton регистрирует созданный серверный CORBA-объект с помощью Smart Agent, а также сообщает о доступности, факте создания и о готовности объекта принимать запросы клиента.

На серверной стороне данные о каждом новом классе объектов, поддерживаемом конкретным сервером, заносятся в репозитарий реализаций. Эту операцию выполняет объектный адаптер. Обычно в ORB имеется несколько объектных адаптеров, обслуживающих разные группы компонентов (так, возможны объектные адаптеры, ориентированные на библиотеки, на базы данных, на группу отдельных программ и т.п.).

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

При реализации запроса брокер через объектный адаптер активирует соответствующий компонент. Далее клиент-серверное взаимодействие происходит через стабы.

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

В CORBA предусмотрен ряд унифицированных сервисов, работающих под управлением ORB. В частности, это сервисы:

именования — присваивает объектам уникальные имена, в результате пользователь может искать объекты в сети по имени;
жизненного цикла – обеспечивает создание, перемещение, копирование и удаление объектов (документов) в системе, в том числе составных объектов вместе со всеми ссылками и ассоциированными объектами;
обработки транзакций — осуществляет управление транзакциями (блокировка, фиксация и откат транзакций) из приложений или из ОС, что позволяет многим объектам в сети использовать одни и те же серверы;
событий — обеспечивает асинхронное распространение и обработку сообщений о событиях, происшедших при реализации процессов, что позволяет заинтересованным объектам координировать свои действия;
обеспечения безопасности — поддерживает целостность данных.

Протоколы GIOP и IIOP

Основной задачей спецификации CORBA является обеспечение взаимодействия объектов, распределенных по разнородной сети и использующих в общем случае различные брокеры запросов. Для связи между брокерами был разработан протокол General Inter ORB Protocol (GIOP), стандартизующий низкоуровневое представление данных и множество форматов сообщений.

Internet Inter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP через TCP/IP-соединения. При необходимости протокол GIOP может быть реализован на основе других транспортных протоколов, например, IPX/SPX.

Технология EJB

EJB (Enterprise JavaBeans) — компонентная модель и технология распределенных вычислений, ориентированная на решение следующих задач (характерных для "среднего слоя" в трехзвенных распределенных системах):

управление транзакциями; контейнер компонентов EJB обеспечит вовлечение в транзакцию нужных компонентов, а после ее выполнения произведет фиксацию или откат;
обеспечение безопасности путем ограничения доступа к удаленным компонентам;
асинхронный доступ в соответствии с JMS;
оптимизация ресурсов сервера (в первую очередь оперативной памяти) путем управления циклом жизни экземпляров компонента
повышение производительности серверов за счет использования эффективных многопоточных моделей;
обеспечение универсального доступа к данным;
оптимизация ресурсов сервера за счет эффективного использования сетевых соединений и соединений с базами данных;
повышение производительности распределенных систем за счет кеширования данных на уровне серверов приложений.

Основными понятиями технологии EJB являются следующие:

роли EJB
session-компоненты
entity-компоненты
контейнер компонентов EJB для развертывания компонент EJB
сервер EJB (application server)
дескриптор развертывания (deployment descriptor)
модель управления сохранением состояния компонентов
модель управления транзакциями.

Компоненты EJB выполняются внутри EJB-контейнера, который, в свою очередь, выполняется внутри EJB-сервера. Компонент EJB имеет два внешних интерфейса (Home и Remote), через которые клиент взаимодействует с компонентом.

Взаимодействие начинается со входа в Home-интерфейс [1]. Клиент обращается к интерфейсу и создает через него экземпляр (объект) компонента. Remote-интерфейс используется для вызова бизнес-методов компонента, реализующих логику приложения. Таким образом, последовательность действий при использовании компонента выглядит следующим образом:

1. Клиент ищет Home-интерфейс нужного компонента по его имени через службу имен JNDI (клиенту возвращается в результате поиска Home-интерфейс этого найденного компонента).

2. Клиент, через найденный Home-интерфейс, вызывает функцию создания экземпляра компонента на стороне сервера (клиенту возвращается Remote-интерфейс созданного экземпляра компонента).

3. Сервер создает экземпляр компонента.

4. Клиент вызывает бизнес-метод компонента через его Remote-интерфейс.

5. Сервер вызывает бизнес-метод компонента.

EJB-контейнер реализует для находящихся в нем компонента такие сервисы как транзакции (transaction), управление ресурсами, управление версиями компонент, их мобильностью, настраиваемостью, мобильностью, жизненным циклом. Так как EJB-контейнер реализует все эти функции, то разработчик EJB-компонента может не реализовывать их самостоятельно, а просто вызывать соответсвующие методы у контейнера (правила вызова методов у контейнера описываются в спецификации). Как правило, в одном EJB-контейнере может находиться несколько однотипных EJB-компонентов.

Клиентские приложения вызывают методы на удаленных EJB-компонентах через EJB-объект. EJB-объект реализует удаленный интерфейс'' EJB-компонента на сервере. Суть в том, что находящийся на сервере EJB-компонент, помимо бизнес-функций, ради которых он был а разработан, должен реализовывать также некоторые функции, определяемые спецификацией, которые служат для ``управления'' EJB-компонентом со стороны контейнера. EJB-объект реализует лишь бизнес-интерфейс для EJB-компонента, являясь, в некотором смысле, ``промежуточным'' звеном между клиентом и EJB-компонентом.

EJB-объекты и EJB-компоненты представляют собой разные классы, хотя ``снаружи'' (при взгляде на их интерфейсы), они выглядят одинаково. Это происходит потому, что они реализуют один и тот же интерфейс (а именно, интерфейс, описанный для EJB-компоненты). Однако при этом они выполняют совершенно разные функции. EJB-компонента выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно вызывает методы у EJB-компоненты [2].

На стороне клиента Remote-интерфейс и Home-интерфейс оформлены в виде классов (EJB объект на рис. 1), которые скрывают сетевые взаимодействия на основе RMI с сервером приложений. Клиент работает с объектами так же, как с объектами в том же адресном пространстве, что и само приложение, хотя на самом деле происходят сетевые вызовы и приложение выполняется совсем на другой вычислительной машине.

Рис. 1.

Технология SOAP

В настоящее время все более широкое распространение приобретает технология интеграции Internet-ресурсов, основанная на протоколе SOAP (Simple Object Access Protocol). SOAP — транспортный протокол, предназначенный для организации взаимодействия удаленных систем при помощи асинхронного обмена XML-документами. Первоначально SOAP предназначался, в основном, для реализации удалённого вызова процедур (RPC).

SOAP — объектная технология, в которой объектами являются Web-службы (Web Services), а для представления обращений к Web-службам используется язык XML. Язык разметки XML распознается разными системами, и потому технология SOAP значительно проще реализуется, чем такие технологии как CORBA или DCOM.

Протокол SOAP обеспечивает взаимодействие распределенных систем независимо от типа объектной модели, операционной системы или языка программирования. Благодаря использованию XML, сообщения SOAP могут передаваться посредством транспортного протокола HTTP, как правило, не закрываемого сетевыми экранами.

В стандарте, описывающем протокол SOAP, изложены принципы, по которым может быть осуществлена привязка SOAP-сообщений к абстрактному транспортному протоколу, общая схема создания SOAP-оболочек для RPC-ориентированных интерфейсов, способы возврата сообщений о сбоях, а также конкретная реализация способа оформления сообщений SOAP в качестве содержимого команд GET и POST протокола HTTP.

Структура SOAP-сообщения показана на рис. 1.

Рис. 1. Структура SOAP-сообщения

Заголовок HTTP может иметь вид:

POST/OrderEntry HTTP/1.1

Host: www.xmlbus.com

Content-Type: text/xml; charset="utf-8"

Content-Length: ...

SOAPAction: ...

В строке SOAPAction указывается URI получателя запроса или посредника.

SOAP-заголовок необязателен (но заголовков может быть несколько). Заголовки могут содержать любую информацию, связанную с приложением. В теле сообщения указываются запрашиваемый метод с его аргументами либо XML-документ.

SOAP-заголовок и тело вложены в конверт, имеющий вид:

<soap-env:Envelope

xmlns:soap-env="http://www.w3.org/2001/06/soap-envelope">

<soap-env:Header>

...

</soap-env:Header>

<soap-env:Body>

. . .

</soap-env:Body>

</soap-env:Envelope>

Прием информации, содержащейся в теле SOAP-сообщения, выполняется SOAP-процессором, который пересылает сведения из тела сообщения в запрошенную службу (например, EJB).

Кроме языка XML и Интернет-протоколов, таких как HTTP, в технологии Web-служб входят следующие компоненты:

язык WSDL (Web Service Description Language) — язык объявления возможностей (функций) Web-службы, описания на WSDL являются XML-документами;
стандарт UDDI (Universal Description, Discovery and Integration), служащий для фиксации возможностей Web-службы.

Стандарт UDDI помогает Web-сервис найти, WSDL — его охарактеризовать, а SOAP — взаимодействовать с ним.

Механизм взаимодействия клиента и сервера в технологии SOAP можно представить в виде последовательности следующих процедур (рис. 2):

Клиентское приложение создает экземпляр объекта SOAPClient;
SOAPClient просматривает UDDI, тем самым определяется нужный метод Web-сервиса;
SOAPClient формирует SOAP-сообщение и отправляет его серверу;
Серверная программа Listener принимает SOAP-сообщение, создает объект SOAPServer и передает ему это сообщение;
SOAPServer вызывает метод Web-сервиса;
Результаты помещаются объектом SOAPServer в ответное сообщение и передаются клиенту;
Объект SOAPClient проводит разбор принятого сообщения и возвращает клиентскому приложению результаты работы Web-сервиса.

Рис. 2. Взаимодействие клиента и сервера в SOAP

Пример системы интеграции Internet-ресурсов — платформа .NET Framework компании Microsoft. В нее входят семейство .NET Enterprise Servers, представляющее собой набор корпоративных серверных приложений, и визуальная среда VisualStudio.NET, поддерживающая все основные языки программирования и используемая для разработки и потребления Web-сервисов.

Компания IBM предлагает сервер приложений WebSphere Application Server, MQ Series для управления сообщениями для объединения систем, включая поддержку SOAP и Web-сервисов на уровне СУБД DB2.

Технология XML-RPC

Формат обмена данными при классической модели RPC (DCOM, CORBA) является бинарным, что неудобно, если надо организовать работу распределенной системы, где между отдельными участками сети стоят firewall/прокси-серверы. Кроме того, технология DCOM реализована только для Windows-систем, CORBA функционирует преимущественно в среде J2EE. Поэтому развиваются технологии, основанные на обмене данными в виде XML-документов. Это SOAP и XML-RPC.

Основным транспортом в XML-RPC. является протокол HTTP. Использование XML. и HTTP снимает ограничения, налагаемые как на конфигурацию сети, так и на маршрут следования пакетов.- Вызовы XML-RPC представляют собой простые типы данных text/xml и свободно проходят сквозь шлюзы везде, где допускается ретрансляция http-трафика.

Рассмотрим примеры запросов и ответов в XML-RPC. В запросе сначала задается HTTP-заголовок (в примере метод POST) [1]:

POST /RPC2 HTTP/1.0

User-Agent: MyAPP-Word/5.1.2 (WinNT)

Host: server.localnet.com

Content-Type: text/xml

Content-length: 172

затем следует собственно запрос в виде XML-документа:

<? xml version="1.0"?>

<methodName>имя вызываемого метода</methodName>

<param>

<value>значение передаваемого параметра</value>

</param>

<param>

<value>значение передаваемого параметра</value>

</param>

. . .

</params>

</methodCall>

Пример XML-RPC ответа:

HTTP/1.1 200 OK

Connection: close

Content-Length: 166

Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:08 GMT

Server: MyWordCheckSerwer/5.1.2-WinNT

<? xml version="1.0"?>

<param>

<value>значение параметра результата</value>

</param>

<param>

<value>значение параметра результата</value>

</param>

. . .

</params>

</methodResponse>

В протоколе XML-RPC для передачи параметров методу и возвращаемых значений предусмотрено семь простых типов данных и два сложных. Эти типы отображают основные типы данных реальных языков программирования. Более сложные типы, такие, например, как объекты, нужно передавать в двоичном виде или заменять структурами.

Пример описания структуры из двух строковых элементов:

<name>FirstWord</name>

<value><string>Hello</string></value>

</member>

<name>SecondWord</name>

<value><string>World!</string></value>

</member>

</struct>

Стандарт UDDI

Для поиска нужных пользователю Web-служб создана спецификация UDDI (Universal Description Discovery and Integration - универсальный стандарт описания, обнаружения и интеграции документов), которая является каталогом (аналогичным телефонной книге) Web-служб. Стандарт UDDI служит для описаний возможностей Web-служб, размещаемых в Internet. В описания могут входить названия компаний, контактные реквизиты, URL предоставляемых Web-сервисов, метаданные, описывающие интерфейсы к соответствующим веб-сервисам, и.т.д. Сама служба UDDI- размещена по известному пользователю адресу.

Рис. 1. Архитектура UDDI-службы

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

UDDI базируется на записях четырех типов: Business Entity, Business Service, Binding Template и Technology Model.

Элемент Business Entity описывает приложение, к которому относится данный Web-сервис. Этот элемент может включать описания категорий приложения для облегчения поиска данных. Это так называемые "Белые страницы", напоминающие телефонную книгу и включающие адреса, контактную информацию и известные идентификаторы компаний.

Элемент Business Service — это класс сервисов в рамках определенного приложения. Это так называемые "Желтые страницы" с информацией об отраслевых кодах, наименованиях продуктов, идентификаторах бизнеса и т.п.

Вместе элементы Binding Template и Technology Model описывают технические характеристики Web-службы. Это "Зеленые страницы", включающие ссылки на спецификации для Web-служб, на различные файлы и механизмы обнаружения, основанные на URL. Важной характеристикой является адрес для вызова данной Web-службы. Адресом может быть URL, адрес электронной почты или телефонный номер. Т.е. UDDI напоминает по своей архитектуре службу доменных имен DNS.

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

Технология UDDI включает API для публикаций и для поиска информации.

Организации, заинтересованные в распространении информации, используют API для публикаций. Описания в виде репозитария UDDI (базы данных общего пользования, в которой компании сами себя регистрируют) имеются в сети Internet на определенных серверах (например, на серверах компаний Microsoft, Hewlett Packard, IBM, SAP). Для регистрации в репозитарии, последующей поддержки сведений о себе и извлечения нужной информации в распоряжение компаний стандарт UDDI предоставляет ряд команд (сохранение или удаление той или иной записи, просмотр данных, активизация Web-сервиса, доступного благодаря Binding Template и Technology Model и т.п.).

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

Язык WSDL

Язык WSDL (Web Service Description Language) предназначен для описания Web-служб. В основе WSDL лежит язык XML.

С помощью WSDL представляются типы данных, операции и привязки.

Описание сервиса на языке WSDL выглядит довольно громоздко. Однако это не является осложняющим фактором, поскольку для генерации WSDL-файлов имеются удобные редакторы, примером которых могут служить XML Spy.

В начале WSDL-описания указывается имя сервиса, ссылка на пространство имен WSDL и на целевое пространство имен (targetNamespace), которому будут принадлежать все имена, объявляемые в этом документе.

Далее следуют части WSDL-описания: типы данных, используемых Web-службой (types); сообщения (message) — формат запросов и ответов; типы портов (portType) — набор операций, выполняемых Web-службой; связи (binding) — адрес для вызова операции (service):

<definitions

name="имя сервиса"

xmlns="http://schemas.xmlsoap.org/wsdl/"

targetNamespace="http://...

<types> ...

<message> ...

<portType> ...

<binding> ...

<service> ...

</definition>

Типы данных, фигурирующие в сообщениях, которыми обмениваются пользователи распределенных приложений, должны правильно интерпретироваться как отправителем, так и получателем. Поэтому типы описываются с помощью XML-схемы, входящей в WSDL-файл, т.е. становятся доступными обоим участникам связи. Пример части types (вместо многоточия должны быть указаны конкретные имена и элементы):

<types>

<xsd:schema

targetNamespace="http://..."

xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="..." type="..."/>

...

</xsd:sequence>

</xsd:complexType>

</xsd:element name="..." type="..."/>>

...

</xsd:schema>

</types>

Часть message служит для указания данных, которыми будут обмениваться участники связи.

Часть message состоит из одного или более элементов part, где каждый элемент part ассоциирован или с element (при использовании документ-стиля), или с type (при использовании RPC-стиля). В случае документ-стиля базовая структура описания сообщения имеет вид (* означает нуль или более):

<message name="..."> *

<part name="..." element="..."/> *

</message>

В случае RPC-стиля в теге part вместо element="..." записывается type="..." и значение атрибута name из тега part становится именем элемента в конкретном сообщении.

Часть portType (иначе интерфейс) определяет группу операций. Операции в WSDL служат для интерпретации данных, содержащихся в сообщениях.

Каждая операция (operation) содержит элементы input и/или output (при наличии элемента output возможен еще элемент fault). Параметр message у элементов input и output указывает на описание соответствующего сообщения (message).

...

</operation>

...

</portType>

Имеется несколько вариантов операций. Если элемент input предшествует элементу output, то конечный узел получает сообщение и отправляет соответствующий ответ. Такая операция называется запрос-ответ (request-response). Обратный порядок output и input определяет операцию требование-ответа (solicit-response), при которой конечный узел отправляет сообщение и получает соответствующий ответ. При наличии только элемента input имеем однонаправленную операцию — сообщение получает конечный узел. Операция, содержащая только элемент output, означает отправку сообщения конечным узлом.

Связи (привязки) используются для отображения типов данных и операций на транспортный протокол. Атрибут type в теге binding ссылается на конкретный portType (интерфейс). Далее указываются тип сервиса (например, SOAP или MIME), стиль представления (document или RPC), транспортный протокол (атрибут transport). Для каждой операции нужно задать URI получателя сообщения (атрибут soapAction, его значение используется в HTTP-заголовке). Имя в теге operation ссылается на имя операции в части portType.

Элемент soap:body определяет, как части сообщения появляются в SOAP-элементе Body. В случае документ-стиля значение атрибута use есть "literal" и это означает, что тело сообщения будет содержать XML-документ и что части сообщения определяют XML-элементы. Использование стиля RPC в SOAP показывает, что тело будет содержать XML-представление вызова метода и что части сообщения представляют параметры метода (use="encoded").

Структура части binding в случае SOAP, транспортного протокола HTTP и стиля RPC имеет вид:

<soap:binding style="rpc"

transport=

"http://schemas.xmlsoap.org/soap/http"/>

<soap:operation soapAction="..."/>

<input>

<soap:body

use="encoded"

encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/" />

</input>

<soap:body

use="encoded"

encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/" />

</output>

</operation>

...

<soap:operation soapAction="..."/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>

</binding>

Часть service может описывать несколько портов для разных транспортных протоколов и служит для задания имени (service name="...") и адреса сервиса (location="http:..."). Атрибут binding указывает на имя, присвоенное помещенной выше части binding.

<port name="..."

binding="...">

<soap:address

location="http:..."/>

</port>

</service>

Ниже приведен пример, взятый из источника [1], WSDL-документа, описывающего Веб-сервис, предоставляющий всего одну операцию Sum (сложение двух целых чисел).

<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:s0="http://tempuri.org"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

targetNamespace="http://tempuri.org" xmlns="http://schemas.xmlsoap.org/wsdl/">

//Описание типов данных аргументов метода и возвращаемого значения

<types>

<s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org">

// Методу Sum передаются два аргумента val1 и val2 с указанными типами данных

<s:element name="Sum">

<s:complexType>

<s:sequence>

<s:element name="val1" type="s:long" minOccurs="0" />

<s:element name="val2" type="s:long" minOccurs="0" />

</s:sequence>

</s:complexType>

</s:element>

// Описание типа данных возвращаемого методом значения

<s:element name="SumResponse">

<s:complexType>

<s:sequence>

<s:element name="SumResult" type="s:long" minOccurs="0" />

</s:sequence>

</s:complexType>

</s:element>

</schema>

</types>

// Описание входящего сообщения метода Sum c входящим сообщением; ассоциирован

//тип данных Sum

</message>

// Описание исходящего сообщения метода Sum c исходящим сообщением; ассоциирован тип данных

// SumResponse

</message>

// Описание операций (методов), предоставляемых Веб-сервисом

// Данный Веб-сервис предоставляет операцию Sum, операция имеет входящее сообщение SumSoapIn

// и исходящее сообщение SumSoapOut

</operation>

</portType>

// Определение формата сообщения и деталей протокола для каждого порта

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

<soap:operation soapAction="http://tempuri.org/Web.Arithmetic.Sum" style="document" />

<input>

<soap:body use="literal" />

</input>

<soap:body use="literal" />

</output>

</operation>

</binding>

// Определяет имя сервера Веб-служб, позволяет объединить внутри себя несколько портов

// (наборов методов), определяет расположение сервиса

<soap:address location="http://MASHA:1972/csp/www/Web.Arithmetic.cls" />

</port>

</service>

</definitions>

Протокол MIME

Протокол MIME (Multipurpose Internet Mail Extensions) - многоцелевое расширение электронной почты, протокол был разработан с целью представления изображений, звука и видео в письмах электронной почты. В дальнейшем MIME стал применяться также в Web-технологиях для передачи документов от сервера к клиенту.

Сообщение MIME имеет заголовок и собственно передаваемый документ, в заголовке указывается вид передаваемых данных:

Content-Type: <тип_MIME>

Перечень типов MIME постоянно пополняется и может быть дополнен даже пользователем для описания своего собственного вида данных. Формат типа MIME:

<Тип>/<Подтип>[;<параметры>]

где компонент <Тип>, определяющий общий тип данных, может иметь значения:

Audio - для звуковых данных
Application - данные, являющиеся входными для какого-либо приложения (программы)
Image - для графических образов
Message - для сообщения, которое само по себе является MIME - документом
Multipart - для сообщения, состоящего из нескольких MIME - документов
Text - для текстовых данных в различном виде
Video - для видеоданных.

Компонент <Подтип> - указывает на специфический формат данных типа <Тип>, его значениями могут быть:

text/html - текстовые данные в формате HTML;
image/gif - графические данные в формате gif

<Параметры> - список параметров, необходимых для интерпретации данных.

Для обработки файлов различных типов и форматов на клиентской и серверной сторонах поддерживаются списки соответствий типов MIME и расширений файлов. Формат записи такого списка:

<Тип>/<Подтип> <расширение1> ... <расширениеN>

Например, запись text/html html htm означает, что всем файлам с расширением html и htm приписывается формат text/html и используется алгоритм обработки, предусмотренный для этого формата.

Корпоративная сервисная шина ESB

Корпоративная сервисная шина ESB (Enterprise Service Bus) — программное обеспечение промежуточного слоя, используемое для передачи данных между приложениями, поддерживающее Web-службы на основе протокола SOAP, языка WSDL, спецификации UDDI, а также такие сервисы, как обработка и проверка сообщений, маршрутизация, балансирование нагрузки и др. Некоторые сервисы встроены в основание шины, другие — исполняются в модулях расширения.

В общем случае ESB решает следующие задачи:

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

Web-служба может быть вызвана любым из следующих способов:

1. Напрямую и синхронно;

2. Синхронно через брокера;

3. Асинхронно через брокера.

Enterprise Service Bus является брокером, поддерживающим вызов службы в синхронном и асинхронном режимах. Она разрешает также передачу данных и уведомлений о событиях между приложениями. Она помогает потребителям найти провайдеров и управляет деталями взаимодействия между ними.

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

Сервис-ориентированная архитектура

Корпоративные информационные системы (КИС) могут состоять из большого числа подсистем, взаимосвязанных посредством сетевых технологий. Построение таких КИС целесообразно выполнять на основе сервис-ориентированных архитектур.

Сервис-ориентированная архитектура SOA (Service Oriented Architecture) — архитектура информационной системы, основанная на следующих принципах:

Архитектура является распределенной, компонентно-ориентиррованной;
Интерфейс компонентов обеспечивает динамическое обнаружение и вызов компонентов (сервисов) на основе независящего от платформы интерфейса;
Используются общепринятые стандарты.

Согласно SOA любые компоненты информационных систем, имеющие функциональность, рассматриваются как службы (service providers, провайдеры служб), предоставляющие услуги другим частям системы.

SOA-приложения обычно представляют собой web-службы. Службы являются автономными, могут быть реализованы в разных программных средах, на разных языках программирования. Для интеграции служб в настоящее время используются XML-интерфейс, протоколы HTTP, SOAP спецификация UDDI и язык WSDL. Поиск web-служб происходит в UDDI-каталоге, интерфейс службы описан на WSDL, а вызов происходит по протоколу SOAP. Возможны синхронные и асинхронные вызовы служб. Механизм обмена сообщениями определяется в описании сервисов на WSDL, которое которое включает форматы сообщений, типы данных, транспортные протоколы, способы сериализации, используемые при обмене между агентами заказчика и поставщика услуг. Информация о веб-сервисах содержится в реестре UDDI. Технология UDDI дает возможность поиска и публикации нужного сервиса, как человеком, так и программой-клиентом.

Сервис-ориентированная архитектура тесно связана с шиной ESB, которая является способом реализации SOA. -Однако, не все информационные системы, построенные на основе web-служб, соответствуют SOA, и SOA не обязательно должна базироваться на технологии web-служб.

Службы на основе их функциональности можно условно поделить на следующие группы:

Службы доступа к данным, предоставляющие чтение и изменение данных. Они предоставляют единый унифицированный интерфейс для доступа к данным вне зависимости от количества и вида используемых источников данных. Для обмена данными могут использоваться специально созданные сущностные объекты, XML данные или же объекты, инкапсулирующие таблицы БД.
Службы бизнес-логики используются для выполнения различных бизнес-операций. В ходе выполнения бизнес-операций обычно вызываются методы других служб (к примеру, служб доступа к данным для получения списка проданных товаров за последнюю неделю)
Компоненты внешних приложений, вызываемые через их собственные интерфейсы, например, CRM система, хранящая данные о покупателях и предоставляющая доступ к этим данным через COM.
Низкоуровневые вспомогательные службы, отвечающие за аутентификацию и авторизацию, мониторинг, поиск служб, регистрацию ошибок и т.п.
составные службы, делегирующие работу остальным типам служб и координирующие их действия. Они интегрируют остальные службы системы и выполняют контроль за транзакциями и преобразование потока данных от одних служб к другим путем конвертации в нужные форматы

Поиск информации в Internet

В сети Internet существует уже несколько миллионов сайтов, их число и объем накопленной в Web-сайтах информации продолжают увеличиваться. Большой объем информации имеет как положительную, так и негативную стороны, так как затрудняет поиск данных, требующихся конкретному пользователю в конкретное время. Для облегчения поиска на открытых для доступа сайтах в Internet используют информационно-поисковые системы (ИПС) и электронные каталоги.

Информационно-поисковые системы могут быть документальными, фактографическими или гипертекстовыми.

В документальных ИПС собирается, индексируется и регистрируется информация о документах, имеющихся в обслуживаемой системой группе Web-серверов. Индексирование включает создание поисковых образов документов. Обычно в поисковый образ входят или все значащие слова, имеющиеся в документе, или только слова из заголовка. Информационно-поисковая система выполняет анализ документов, создание и хранение поисковых образов документов, анализ запросов пользователей, поиск и выдачу пользователю данных о месте расположения в сети запрашиваемых документов. В основе поиска лежит сопоставление запроса пользователя с поисковыми образами документов, в результате отбираются релевантные документы, т.е. документы, чьи поисковые образы соответствуют запросу. Во многих ИПС пользователю предоставляется возможность обращаться к серверу с запросами на естественном языке, со сложными запросами, включающими логические связки. Примерами таких ИПС могут служить системы Excite, Lycos, Altavista и др. Для функционирования Altavista в свое время фирма DEC выделила несколько компьютеров, в том числе 10-процессорную ЭВМ Alpha-8400.

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

В фактографических системах хранится структурированная информация в виде фактов, относящихся к определенной предметной области. Примером может служить реляционная БД.

В гипертекстовых системах хранятся гипертекстовые документы.

Поиск в электронных каталогах основан на сопоставлении запроса с разделами информации в иерархической структуре ее классификации.

Классификацию информации называют рубрикацией. Наиболее сложной является разработка тематической рубрикации. В мире существует и применяется ряд систем тематической рубрикации. Так, в России широко известны иерархические системы УДК (Универсальная десятичная классификация) и ГРНТИ (Государственный реестр научно-технической информации). Однако в силу своей громоздкости и естественной консервативности они не всегда удобны для использования в электронных каталогах и информационно-поисковых системах. Поэтому существует ряд частных систем рубрикации с несколькими уровнями иерархии, например, в образовательных порталах.

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

Примерами поисковых систем, работающих по принципу электронного каталога, служат системы Yahoo!, Galaxy, Looksmart, Yandex. Так, в Yahoo! на верхнем уровне иерархии выделены 14 категорий (например, искусство и гуманитарные науки, образование, бизнес и экономика, наука и др.). Пользователь при поиске осуществляет навигацию по разделам иерархического дерева, спускаясь от верхнего уровня до искомого конечного, на котором он получает сведения об адресах сайтов с нужными информационными ресурсами.

Технологии поиска, основанные на упорядочении метаинформации наподобие библиотечных каталогов (классификации по содержанию), продолжают развиваться, например в создаваемой технологии RDF (Resource Definition Format).

Однако поиск по ключевым словам во всем пространстве Internet не всегда оказывается эффективным. Поиск нужной информации в множестве документов, на которые указывает ИПС в ответ на запрос пользователя, может потребовать слишком много времени. Сделать работу пользователя корпоративной системы в Internet более эффективной позволяет технология порталов, применение языка разметки XML и языков поиска XPath или XQuery в базах XML-документов.

Язык IDL

Что такое язык IDL, в каких системах он используется? Приведите расшифровку аббревиатуры IDL.

Ответ

Платформа J2EE.

Компонентно-ориентированная технология — это технология создания больших программных комплексов, в том числе таких как АСУ, выделяемая среди объектно-ориентированных технологий благодаря большей функциональной законченности используемых компонентов. Различные компоненты, которые могут использоваться в приложениях, распределены по различным узлам сети

J2EE (Java 2 Enterprise Edition) — комплекс взаимодействующих объектно- и компонентно-ориентированных технологий, который можно рассматривать как стандарт и платформу для создания прикладных программных комплексов (в том числе и распределенных систем) на основе использования языка Java. Подразумевается, что при этом используется среда JDK версии 1.2 или старше, что отражено цифрой "2" в названии.

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

клиентские приложения и апплеты, которые выполняются на клиентских компьютерах;
сервлеты и Java Server Pages, которые представляют собой Web-компоненты и выполняются на Web-серверах;
Enterprise JavaBeans, которые являются бизнес-компонентами и выполняются на прикладных серверах.

Технология J2EE создана в 1999 г. В состав J2EE входят [1,2] в качестве основных технологии EJB (Enterprise JavaBeans), сервлетов, JSP. Кроме того, в J2EE используются технология удаленного вызова объектов RMI, служба управления транзакциями в распределенных системах JTS, стандарт взаимодействия J2EE с реляционными базами данных JDBC.

В соответствии со спецификацией EJB процесс разработки распределенной системы включает следующие этапы:

разработка сервера EJB, выполняемая одним из известных производителей программного обеспечения — (Server Provider);
разработка контейнера EJB, выполняемая Container Provider; контейнеры - это низкоуровневые API, связывающие компоненты с клиентами и системными сервисами, выполняют функции системной поддержки и служат для устанавки в них компонентов;
разработка EJB-компонентов, выполняемая Bean Providers — специалистами в прикладной области, компетентными в вопросах функционирования создаваемой системы и реализации ее бизнес-логики;
сборка сетевого приложения из готовых компонентов, выполняемая также специалистами в прикладной области;
настройка готовой программы (deployment).

Обычно под сервером приложений (application server) понимают любое приложение, которое в рамках распределенной системы способно получать и обслуживать запросы клиентов. Далее термин "Application Server" будет применяться только к серверным приложениям, созданным в соответствии с технологией J2EE.

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

Контейнер компонентов EJB служит для управления циклом жизни экземпляров (instances) компонентов — их установкой, созданием, активизацией/деактивизацией, сохранением состояния, доставкой клиентских запросов, уничтожением. Для своего выполнения компонент должен быть скомпонован в J2EE-приложение и размещен внутри своего контейнера. Процесс компоновки включает в себя определение установок контейнера для каждого компонента в J2EE-приложении и для самого J2EE-приложения. Установки контейнера касаются таких сервисов как безопасность, управление транзакциями, JNDI-поиск и удаленная связь.

Аналогичные функции по отношению к сервлетам и компонентам JSP выполняет Web-контейнер, а по отношению к аплетам — контейнер аплетов.

Компонент в J2EE- представляет собой законченный функциональный программный модуль, встроенный в приложение J2EE с соответствующими классами и файлами и взаимодействующий с другими компонентами. Разделяют компоненты клиентские (встроенные в HTML- и XML-документы, Java-аплеты, браузер) и серверные (Web-компоненты и бизнес-компоненты, реализующие прикладную логику). Web-компоненты могут быть либо сервлетами, либо страницами JSP. Сервлеты — это классы языка Java, которые динамически управляют запросами и конструируют ответы. JSP-страницы являются текстовыми документами, которые исполняются так же, как и сервлеты, но предлагают более естественный подход к созданию статического содержания. Компоненты JavaBeans используются для управления потоком данных между клиентскими и серверными компонентами или между компонентами сервера и базой данных (рис. 1).

Рис. 1. Структура распределенной системы на основе J2EE

Бизнес-компоненты, иначе называемые корпоративными, подразделяются на сессионные, управления данными и управляемые сообщениями. Сессионные компоненты предназначены для кратковременного общения с клиентом. Когда клиент заканчивает работу, сессионный компонент и его данные исчезают. Данные из компонентов управления данными сохраняются в БД. Управляемые сообщениями компоненты комбинируют особенности сессионного компонента и службы сообщений JMS , позволяя бизнес-компоненту получать сообщения JMS асинхронно.

JMS (Java Message Service) — это набор интерфейсов и стандарт обмена сообщениями, позволяющий компонентам J2EE-приложения создавать, посылать, принимать и читать сообщения. Он обеспечивает двустороннее, надежное, асинхронное распределенное соединение, допускает взаимодействие с существующими MOM (Message-Oriented Middleware) системами. JMS поддерживает работу как в стиле "отправитель-получатель", так и в режиме "рассылка-подписка".

Другие средства, входящие в J2EE:

1. JDBC (Java DataBase Connectivity) — стандарт взаимодействия J2EE с реляционными базами данных, позволяющий "соединить" Java-программы и SQL. API JDBC позволяет вызывать SQL-команды из модулей, написанных на языке Java. Основными частями технологии JDBC являются JDBC API (набор классов и методов, к которым обращается прикладной программист) и JDBC-драйверы, которые транслируют эти вызовы в команды API конкретной СУБД. JDBC поддерживает распределенные базы данных и двухфазное завершение транзакций.

2. JNDI (Java Naming and Directory Interface) — набор Java-интерфейсов, описывающих функции, характерные для так называемых "служб имен" и "служб каталогов". Под "службой имен" понимают структуры, обеспечивающие хранение некоторых ресурсов и доступ к ним по сопоставленным с этими ресурсами произвольным именам (например, файловые системы операционных сред). "Служба каталогов" (Directory Service) может рассматриваться как расширение служб имен за счет сопоставления с ресурсами дополнительных атрибутов (помимо имен) и управления ими.

3. JTS (Java Transaction Service) — служба управления транзакциями в распределенных системах (не путать с транзакциями на уровне систем управления базами данных), в том числе созданных в соответствии со стандартами J2EE. Для использования JTS взаимодействие объектов в рамках распределенной системы должно происходить с использованием протокола IIOP — базового протокола CORBA. В качестве транзакционного API для работы с JTS используется JTA.

4. JTA (Java Transaction API) — набор классов и методов, который обеспечивает основную функциональность для управления транзакциями — начать транзакцию, завершить ее с подтверждением или с откатом, получить ее статус. Вызовы JTA обычно транслируются в вызовы JTS (или сразу в вызовы API конкретной реализации JTS).

5. Java API for XML Processing (JAXP)- средство, предназначенное для обработки XML-документов с использованием спецификаций DOM, SAX и XSLT. JAXP позволяет приложениям анализировать и преобразовывать XML-документы.

6. J2EE Connector Architecture — продукт для создания адаптеров, поддерживающих доступ к информационным системам предприятий. Адаптер ресурса — это программный компонент, позволяющий компонентам J2EE-приложения иметь доступ и взаимодействовать с базовым менеджером ресурса.

7. RMI (Remote Method Invocation) — технология обеспечения удаленного взаимодействия объектов в распределенных системах, написанных на Java. Концептуально очень похожа на CORBA. Для RMI (в отличие от CORBA) характерна передача объектов "по значению" — с использованием механизма сериализации Java.

Технология RMI сравнительно проста. Программирование с использованием RMI не вызывает проблем, если разработчик приобрел определенный опыт создания распределенных приложений и программирования на языке Java. При этом не требуется использование абстрактных языков (таких как IDL) для описания удаленного серверного объекта, не создается никаких сервисов, как это было в случае с CORBA. Но все эти аспекты должны учитываться разработчиками. Для использования RMI необходимо наличие Java-машин на обеих сторонах соединения.

Для технологии J2EE характерно теснейшее взаимодействие технологий RMI и CORBA. В частности, механизмом выполнения удаленных вызовов в J2EE (EJB) является RMI, но с использованием протокола CORBA IIOP, и транзакционность такого взаимодействия обеспечивается в соответствии со спецификацией CORBA OTS, "отображенной" стандартным образом на Java (JTS).

Формально такое взаимодействие определено с помощью введения некоторого подмножества возможностей, характерных как для RMI, так и для CORBA. Это подмножество получило название RMI/IIOP (или RMI/IDL).

IBM WebSphere

Основное назначение продуктов WebSphere — разработка и развертывание приложений электронного бизнеса. Можно выделить три группы продуктов:

базовые средства и инструменты — основа для быстрой разработки и развертывания приложений электронного бизнеса по требованию;
бизнес-порталы — инструменты для расширения возможностей клиентов, сотрудников, партнеров и поставщиков для ведения бизнеса;
интеграция бизнес-приложений — средства интеграции приложений и автоматизации бизнес-процессов для повышения эффективности и гибкости деловых операций.

WebSphere Portal Server (WPS) — это среда для построения горизонтальных и корпоративных порталов, предоставляющая доступ к приложениям, данным и экспертам с помощью программных модулей (адаптеров), называемых портлетами.

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

WPS может быть развернут как корпоративный портал для сотрудников, бизнес-партнеров и заказчиков. Этот продукт содержит функции структурирования и категоризации информационного наполнения, обеспечения безопасности, персонализации, управления документооборотом.

Структура WPS основана на следующих продуктах: WebSphere Application Server, WebSphere Personalization, WebSphere Everyplace Suite, а также на программных продуктах Lotus Corporation.

Службы представления WPS предоставляют простой в использовании тонкий клиент с Web-интерфейсом, с помощью которого пользователи, работающие с браузером, могут настраивать вид портала, опции поиска бизнес-контента и доступа к нему. Данные службы работают совместно с WebSphere Everyplace Suite, который позволяет адаптировать пользовательский интерфейс к возможностям мобильных устройств и WAP-телефонов. Службы персонализации WPS используют интеграцию с продуктами Tivoli.

WPS предоставляет доступ к службам поддержки коллективной работы путем интеграции с продуктами Lotus и Microsoft, причем интерфейс к этим продуктам представлен в виде портлетов. WPS содержит адаптеры-портлеты для Lotus Notes View, E-mail, Calendar, списков To Do и дискуссионных групп. Такие продукты, как Lotus Quickplace, Sametime, LearningSpace и Domino.Doc, можно приобрести отдельно и добавить в WPS в виде портлетов. WPS содержит портлеты и для компонентов Microsoft Exchange: Calendar, Inbox, Contacts и Office Library.

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

Подробную информацию о WebSphere Portal Server можно найти на сайте компании IBM (http://www.ibm.com/).

IBM WebSphere Studio

IBM WebSphere Studio — интегрированный набор средств разработки Web-сайтов и приложений для ведения электронного бизнеса без использования таких технологий, как CGI, ASP. и т.п.

Возможности набора:

создание JavaBeans, запросов к базам данных и сервлетов Java;
создание Web-сайта для группировки файлов, относящихся к сайту, в проекты и папки для облегчения управления сайтом;
поддержка тестов для всех типов файлов, что расширяет возможности использования инструментов Web-разработки для редактирования, обновления и запуска файлов и публикации Web-сайта на любом из серверов WebSphere Application .

WebSphere Studio включает:

Web Development Workbench — организатор проекта по созданию Web-сайта и платформа запуска.
Мастер генерации сервлетов — генерация сервлетов Java для доступа к базам данных через ODBC и компонентам JavaBeans.
VisualAge for Java, Professional Edition — среда для разработки Java-приложений, апплетов, сервлетов и компонентов JavaBeans. При ее помощи разрабатываются унаследованные приложения, совместимые с Web.
NetObjects Fusion — создание Web-сайтов, включая отдельные страницы и все ссылки. Функциональные возможности включают построение автоматизированных сайтов, автоматическое управление ссылками, удаленный доступ к базам данных, а также средства дизайна и публикации.
NetObjects BeanBuilder — визуальный авторизационный инструмент для комбинирования JavaBeans с апплетами Java. BeanBuilder обеспечивает возможность просмотра содержимого бизнес-процессов, протекающих в онлайн для создания лучших, высокоинтерактивных сайтов с невероятной легкостью в использовании.
NetObjects ScriptBuilder — сочетает в себе текстовый редактор скрипта и средства разработки для создания и редактирования HTML-документов, скриптов и серверных страниц Java.

WebSphere Studio содержит также многие из инструментов управления, такие как управление ссылками, импорт сайтов и диаграммы связей между компонентами сайта.

IBM WebSphere Application Server

IBM WebSphere Application Server — программное обеспечение для построения корпоративных решений и развертывания приложений на базе Java-2 Enterprise Edition (J2EE) и Web-сервисов в условиях динамичного электронного бизнеса по требованию (on demand).

IBM Tivoli

IBM Tivoli — семейство программных продуктов, поддерживающих эффективную работу средств корпоративной информационной сети. Обеспечивает распределение информационных и вычислительных ресурсов с соответствии с текущими приоритетами бизнеса, безопасность информации, конфиденциальность, целостность и доступность электронных данных.

Macromedia Flesh

Система Macromedia Flesh, разработанная компанией Macromedia (первая версия появилась в 1996 г.), предназначена для создания интерактивных анимационных Web-страниц с использованием как растровой, так и векторной графики, с возможностью воспроизведения музыки и звуков в формате MP3. Разработанные файлы встраиваются в HTML-документ автоматически.

Написанные с помощью специального языка программирования модули могут импортироваться в документ в виде аплетов и вставляться в кадры, в которых должно произойти динамическое изменение изображения, возможно управление проигрыванием видеофрагментов. В общем случае подготовленные разработчиком интерактивные элементы и анимация превращаются в интерпретируемый код, который вставляется в HTML-страницу. Для распознавания модулей в браузере нужно иметь программу Macromedia Flash Player.

Метаданные

Метаданными принято называть данные о данных. Так, в системах документооборота, хранения и поиска документов метаданные называют поисковым образом. В этих системах документы должны помимо содержательной части иметь некоторые атрибуты, характеризующие те или иные свойства документов. Атрибуты полезно используются для классификации, отбора и поиска документов.

Метаданные часто представляют собой некоторую фреймовую структуру, с определенным числом слотов (полей) и их назначением.

Существует ряд унифицированных систем представления метаданных. К ним относятся системы:

Dublin Core Metadata Element Set (Дублинское ядро), для различных информационных ресурсов и получившая распространение в библиотечных системах;
GEM, являющаяся частным случаем Дублинского ядра для образовательных ресурсов;
LOM (Learning Object Metadata), разработанная в IEEE и принятая за основу организацией IMS для описания метаданных образовательных ресурсов.

В Web-технологиях для описания метаданных различных документов предложены модель RDF и язык RDFS (RDF Schema), используемые в процедурах интерпретации данных и обмена данными между приложениями.

Семантический Web

Семантический Web представляет собой иерархическую структуру, включающую несколько слоев моделей и языков описания информации (рис. 1).

В основании иерархической пирамиды находятся способы кодирования (форматы) данных, такие как, например, ASCII, UNICODE, графические форматы, а также ссылочные идентификаторы URI (Universal Resource Identifier).

Выше расположен уровень языков разметки HTML и XML (вместе со схемами HTML и XML или таблицами определения типов DTD).

Далее следует уровень с моделью RDF и языком RDFS (RDF Schema), служащими для описания метаданных, их интерпретации и обмена данными между приложениями. Если на уровне языков HTML и XML рассматриваются вопросы, связанные только со структурой документов, то на уровне RDF/RDFS решаются проблемы обеспечения семантической интероперабельности документов.

Верхний уровень занимают модели и языки онтологии, создаваемые на базе RDF/RDFS-средств. К языкам онтологии относятся DAML (DARPA Agent Markup Language), OIL (Ontology Interchange Language), OWL (Web Ontology Language) и др. С их помощью можно устанавливать эквивалентность классов, представлять теоретико-множественные операции над классами и т.п.

Применение семантического Web направлено на повышение эффективности решения следующих проблем:

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

Следует отметить, что для всех языков разметки на верхних иерархических уровнях, представленных на рис. 1, в качестве основы принят язык XML.

Рис. 1. Семантический Web

Модель метаданных RDF

RDF (Resource Description Framework) — модель, предложенная консорциумом World Wide Web Consortium (W3C) для описания метаданных информационных ресуросов в Web. Для представления модели RDF используется язык XML. В получающемся XML-документе RDF-метаданные помещаются в контейнер XML с дескриптором rdf:RDF.

Модель состоит из предложений вида субъект - предикат - объект, где субъект — ресурс, о котором идет речь в предложении, предикат — ресурс, являющийся свойством субъекта, объект — ресурс, являющийся значением свойства. Ресурсами являются некоторые модельные представления об объектах реального мира, обычно описываемые в документах, имеющих URI. Отметим, что свойство в RDF — понятие, которое может использоваться самостоятельно, вне связи с субъектом. Пример предложения:

Команда имеет тренера, его имя Иванов.

Здесь субъектом, предикатом и объектом являются команда, тренер, Иванов соответственно.

Ресурсы могут объединяться в группы, называемые классами. Сами классы также являются ресурсами и идентифицируются ссылками RDF-URI. В RDF определение класса или свойства (так называемый интенсионал) отделено от множества экземпляров класса и значений свойства (от экстенсионала).

Для записи RDF-модели используют язык XML. RDF-модель документа на языке XML есть последовательность элементов Description. Каждый элемент Description применяется к одному определенному ресурсу и содержит описания свойств ресурса (т.е. содержит значение определенного поля метаданных документа). URI этого ресурса указывается в Description в качестве атрибута about или ID. Например:

<rdf:Description about="http://...">

Свойство может быть URI, строкой символов или элементом Description. Возможно использование нескольких элементов Description как включаемых в модель последовательно, так и вложенных друг в друга. Свойства представляются в виде XML-элементов <предикат>объект</предикат> или <предикат rdf:resource="объект"/>.

Общая структура модели имеет вид:

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

<rdf:Description rdf:about="субъект">

<предикат>объект</предикат>

</rdf:Description>

...

<rdf:Description rdf:about=...>

<предикат rdf:resource="объект"/>

</rdf:Description>

</rdf:RDF>

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

Предположим, что некоторый термин "system" имеет разный смысл в предметных областях, описываемых в документах с URI http://www.cl.edu/cont/ и http://aba.ru/technologies/elements/. Тогда на этот термин в RDF-модели нужно ссылаться с помощью составных имен (QNames), например, m1:system и m2:system, причем предварительно должны быть введены псевдонимы m1 и m2 для указанных URI. Структура RDF-модели может иметь вид (в примере использование m1:system и m2:system подразумевается в XML-предложениях внутри элементов rdf:Description):

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:m1="http://www.cl.edu/cont/"

xmlns:m2="http://aba.ru/technologies/elements/">

<rdf:Description rdf:about=...>

...

</rdf:Description>

</rdf:RDF>

Приведем простой пример RDF-модели:

<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">

<rdf:Description rdf:about="http://www.work.ru/person/">

<contact:fullName>Ivan Ivanov</contact:fullName>

<PlaceOfBirth>Moscow</PlaceOfBirth>

<contact:personalTitle>Professor</contact:personalTitle>

</rdf:Description>

</rdf:RDF>

Здесь элемент rdf:Description служит для представления метаданных документа, находящегося по адресу http://www.work.ru/person/, другими словами, .http://www.work.ru/person/ есть URI субъекта, его свойствами являются полное имя, место рождения, звание, а значениями свойств соответственно Иван Иванов, Москва и профессор.

Полные URI можно заменять псевдонимами, используя объявления ENTITY в таблице определения типов DTD. Например:

<!ENTITY dev "http://ee.com/product/comp#">

Теперь полный URI (http://ee.com/product/comp#diode) может быть заменен на &dev;diode.

Язык RDFS

Язык RDFS — язык описания словарей классов и свойств Web-ресурсов, предназначен для определения, стандартизации и использования метаданных, описывающих ресурсы Web. Так же как XML схема служит для задания структуры и типов в документах XML, язык RDFS нужен для описания структуры и типов для моделей RDF.

Язык RDFS предоставляет базовую систему типов для моделей RDF (аналогично Express в STEP). В числе типов имеются некоторые предопределенные типы, такие как Class, subPropertyOf и subClassOf, используемые всеми интегрируемыми приложениями. В RDFS вводятся понятия класса, подкласса, свойства и подсвойства, имеется возможность накладывать на них ограничения. В модели RDF используется иерархическое построение классов (сущностей) и свойств (атрибутов) предметной области, определяется, какие свойства и с какими классами могут быть использованы. Концепция RDF близка к концепции семантической сети.

Как и в XML, в RDFS вводятся теги для задания типов и атрибутов метаданных.

Множество ресурсов, родственных в том или ином смысле, является классом. Классы задаются с помощью тега rdfs:Class, их принадлежность к некоторому надклассу описываются с помощью тега rdfs:Resource, т.е. данный класс является ресурсом такого-то надкласса. К числу классов относится rdfs:Literal, его экземплярами могут быть, например, string и integer. Экземплярами класса rdfs:Datatype, т.е. типов данных, являются подклассы класса rdfs:Literal. Принадлежность ресурса к конкретному классу задается с помощью свойства rdf:type.

Класс rdf:Property служит для описания свойств ресурсов. Свойство может быть выражено литералом или быть отношением двух классов. Класс свойств rdfs:domain позволяет указать область определения свойства, т.е. классы, к которым это свойство может быть применено. Класс rdfs:range позволяет указать диапазон свойства, т.е. классы, чьи ресурсы могут появиться в качестве значений заданного свойства.

Свойства rdfs:subClassOf и rdfs:subPropertyOf относятся соответственно к подклассу класса и подсвойству свойства.

Например, описание класса diode как подкласса класса device со свойством material может иметь следующий вид:

<rdfs:Class ID="diode">

<rdfs:subClassOf rdf:resource="#device"/>

</rdfs:Class>

<rdf:Property ID="material">

<rdfs:domain rdf:resource="#diode"/>

<rdfs:range rdf:resource="#string"/>

</rdf:Property>

Свойства rdfs:label и rdfs:comment применяются для задания удобных для человека псевдонимов именам и содержимому ресурсов.

В таблице 1 перечислены классы RDFS, а в таблице 2 — свойства RDFS.

Таблица 1

Имя класса	Пояснение
rdfs:Resource	Класс-ресурс, включает "всё"
rdfs:Literal	Класс литеральных значений, текстовых строк или чисел
rdf:XMLLiteral	Класс XML-литералов
rdfs:Class	Класс классов
rdf:Property	Класс RDF-свойств
rdfs:Datatype	Класс типов данных RDF
rdf:Statement	Класс утверждений
rdf:Bag	Класс неупорядоченных контейнеров
rdf:Seq	Класс упорядоченных контейнеров
rdf:Alt	Класс контейнеров-альтернатив
rdfs:Container	Класс RDF-контейнеров
rdfs:ContainerMembership	Класс свойств "членства" в контейнерах
rdf:List	Класс RDF-списков

Индивидами являются сущности, состоящие из единственного объекта.

Описание типа rdf:type служит для связывания индивида с классом, членом которого он является. Например, в следующем предложении Х является экземпляром класса Р:

<owl:Thing rdf:about="#Х">

<rdf:type rdf:resource="#Р"/>

</owl:Thing>

Но то же можно выразить и таким образом:

<Р rdf:ID="Х" />

Таблица 2

Имя свойства	Пояснение	Домен	Диапазон
rdf:type	Субъект является экземпляром класса	rdfs:Resource	rdfs:Class
rdfs:subClassOf	Субъект является подклассом класса	rdfs:Class	rdfs:Class
rdfs:subPropertyOf	Субъект является подсвойством свойства	rdf:Property	rdf:Property
rdfs:domain	Домен свойства субъекта	rdf:Property	rdfs:Class
rdfs:range	Диапазон свойства субъекта	rdf:Property	rdfs:Class
rdfs:label	Человекочитаемое название субъекта	rdfs:Resource	rdfs:Literal
rdfs:comment	Текстовое описание ресурса	rdfs:Resource	rdfs:Literal
rdfs:member	Член ресурса субъекта	rdfs:Resource	rdfs:Resource
rdf:first	Первый элемент списка	rdf:List	rdfs:Resource
rdf:rest	Оставшийся за первым элементом "хвост" списка	rdf:List	rdf:List
rdfs:seeAlso	Дополнительная информация о субъекте	rdfs:Resource	rdfs:Resource
rdfs:isDefinedBy	Определение ресурса субъекта	rdfs:Resource	rdfs:Resource
rdf:value	Свойство, используемое для структурированных значений	rdfs:Resource	rdfs:Resource
rdf:subject	Субъект RDF-утверждения (см. "реификация")	rdf:Statement	rdfs:Resource
rdf:predicate	Предикат RDF-утверждения (см. "реификация")	rdf:Statement	rdfs:Resource
rdf:object	Объект RDF-утверждения (см. "реификация")	rdf:Statement	rdfs:Resource

Дублинское ядро

Hаиболее перспективным средством формирования описательных метаданных для широкого класса цифровых объектов является, по мнению многих ученых, система метаданных Дублинского ядра DC (Dublin Core).

Система Дублинского ядра разрабатывается с 1995 г.

Набор метаданных Дублинского ядра состоит из 15 элементов. Все элементы являются необязательными.

Hиже приводится список элементов DC, взятый из книги Вильяма Армса «Электронные библиотеки».

Title (Заголовок) — название, присвоенное ресурсу создателем или издателем.
Creator (Автор) — человек или организация, имеющие непосредственное отношение к созданию содержимого ресурса (например, авторы; фотографы, иллюстраторы и т.п.).
Subject (Предмет) — тема ресурса. Обычно предмет выражается в ключевых словах или фразе, описывающей предмет или содержание ресурса.
Description (Описание) — текстовое описание содержания ресурса, включая реферат в случае документов или описание содержания в случае визуального ресурса.
Publisher (Издатель) — организация, ответственная за создание ресурса в его нынешней форме — например, издательство, университетский департамент или корпорация.
Contributor (Участник создания материала) — человек или организация, которые не являются авторами (не обозначены в элементе «автор»), но внесли значительный интеллектуальный вклад в ресурс, но чья роль менее значима, чем авторов (например, редактор или переводчик).
Date (Дата) — дата, указывающая на создание или появление (в доступном виде) ресурса.
Type (Тип) — категория ресурса (например, учебник, поэма, статья, справочник, технический отчет, словарь).
Format (Формат) — формат представления данных ресурса (например, doc, xml, ftp).
Identifier (Идентификатор) — набор букв или цифр, который обычно используется для уникальной идентификации ресурса. В случае сетевых ресурсов примером является URL.
Source (Источник) — информация о вторичном источнике, из которого был получен настоящий ресурс.
Language (Язык) — язык, на котором изложено содержание ресурса.
Relation (Связь) — идентификатор вторичного ресурса и его связь с настоящим ресурсом. Этот элемент позволяет связывать между собой близкие ресурсы, а также описания ресурса, которые необходимо показать. Примеры — издание книги и глава книги.
Coverage (Охват) — характеристики местонахождения и временной продолжительности ресурса.
Rights (Права) — утверждение об авторских правах и управление ими; идентификатор, связанный с таким утверждением; идентификатор, связанный с сервисом, представляющим информацию об управлении правами на данный ресурс.

Согласно рекомендации RFC 2413, все элементы Дублинского ядра, описанные в перечне, можно разбить на три группы:

элементы, относящиеся к содержанию ресурса (Content);
элементы, описывающие цифровой ресурс с точки зрения интеллектуальной собственности (Intellectual Property);
элементы, относящиеся к конкретному экземпляру ресурса (Instanitation).

В нижеприведенной таблице эта группировка раскрыта более полно:

Таблица 1

Content	Intellectual Property	Instantiation
Title, Subject, Description, Type, Source, Relation, Coverage	Creator, Publisher, Contributor, Rights	Date, Format, Identifier, Language

Примеры использования метаданных Дублинского ядра, встроенных в HTML и RDF документы (взяты из http://xmlhack.ru/archives/2005/06/000111.html):

content="http://purl.oclc.org/metadata/dublin_core">

Запись в формате RDF:

<RDF:RDF>

<RDF:description RDF:about= "http://hamlet.org">

<DC:creator> Shakespeare </DC:creator>

<DC:type> play </DC:type>

</RDF:description>

</RDF:RDF>

К 2003 г. система метаданных Дублинского ядра официально включала 15 элементов (см. ISO 15836:2003. Information and documentation – The Dublin Core metadata element set). В дальнейшем множество элементов может быть расширено.

Языки онтологий

Онтологии являются описаниями семантики конкретных предметных областей в виде совокупности сущностей, их атрибутов, значений атрибутов и ограничений. В свою очередь, сущность определяется как множество однородных объектов или как некоторое понятие предметной области. Множество сущностей можно представить в виде словаря (тезауруса) понятий.

Одним из развитых языков онтологий является язык Express, созданный для целей информационной поддержки промышленных изделий на различных этапах их жизненного цикла и изложенный в группе стандартов STEP (ISO 10303). Онтологии ряда приложений, выраженные на языке Express и представленные в прикладных протоколах STEP, используются для создания электронных макетов изделий и информационного согласования различных промышленных автоматизированных систем.

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

Шагом на пути перехода от языка XML к языкам онтологий стало создание модели и языка описания обмена метаданными RDF/RDFS, разработанных практически одновременно с XML. Язык RDFS можно рассматривать как надстройку над XML. Отметим, что обычно метаданные интерпретируют как данные о данных, а в базах знаний под метаданными подразумевают синтаксические и семантические правила обработки информации.

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

Собственно языки онтологий для Web создаются на базе RDF/RDFS. Так, язык онтологий OIL является расширением RDFS, в котором используются фреймовые представления из моделей искусственного интеллекта.

Язык онтологий DARPA Agent Markup Language (DAML) предложен в 2000 г. Целью DAML и реализующего его программного обеспечения являются динамическая идентификация и интерпретация данных, интероперабельность между программными агентами, представление метаданных и управление знаниями. Объединение языков DARPA и OIL расширило возможности классификации, типизации и описания свойств ресурсов.

Другой язык онтологий OWL (Ontology Web Language), созданный на базе XML, также является элементом стека web-протоколов. В нем используется объектно-ориентированный метод описания предметных областей, реализуется представление о приложении, как о множестве сущностей (объектов) с наборами ограничений и атрибутов, характеризующих свойства и межобъектные связи. В языке есть средства описания версий онтологий и их агрегирования. Предполагается наличие агентов, которые смогут автоматически пополнять базу знаний информацией, вновь появляющейся в Интернет, строить тестирующие системы и т.п.

Примерами редакторов для разработки онтологий могут служить программы Webonto или OilEd (последняя поддерживает языки OIL и RDFS).

Существующие языки онтологий являются декларативными. Основная область применения таких языков, как RDF/RDFS, OIL, DAML, OWL - информационный поиск. Имеются языки, ориентированные на создание экспертных систем, например LOOM. С момента их создания первых языков онтологий прошло пока еще мало времени. Следует ожидать появления более мощных языков, позволяющих описывать как структурные, так и поведенческие аспекты приложений.

Язык OWL

В языках онтологий должны быть средства описания классов (концептов) предметной области, экземпляров классов, свойств концептов и отношений между концептами. Рассмотрим, как эти части онтологий описываются в языке OWL (WEB Ontology Language).

Задание класса Х осуществляется следующим образом:

<owl:Class rdf:ID="Х"/>

Далее может использоваться ссылка на класс Х в виде #X.

Экземпляр Y класса X (индивид) может быть задан в виде

Свойствами могут быть ObjectProperty, DatatypeProperty, rdfs:subPropertyOf, rdfs:domain, rdfs:range.

Например, свойство А, относящееся к концептам Х и Z (ограничения domain и range — см. язык RDFS), будет выглядить таким образом

<owl:ObjectProperty rdf:ID="А">

<rdfs:domain rdf:resource="#Х"/>

<rdfs:range rdf:resource="#Z"/>

</owl:ObjectProperty>

Отношения иерархии классов и свойств выражаются конструкциями subClassOf и subPropertyOf. Например, пусть Z — подкласс класса X. Тогда

<owl:Class rdf:ID="Z">

<rdfs:subClassOf rdf:resource=#Х" />

</owl:Class>

Отношения представляются как свойства. Например, отношение А между Y1 и Y2 и отношение C между Y1 и Y3 можно описать так

<имя свойства А rdf:resource="#Y2" />

<имя свойства С rdf:resource="#Y3" />

</Х>

Отношения могут быть симметричными, несимметричными, функциональными, транзитивными и т.п., что в случае, например, симметричного отношения может быть выражено строкой <rdf:type rdf:resource="&owl;SymmetricProperty" /> в

<owl:ObjectProperty rdf:ID="А">

<rdf:type rdf:resource="&owl;SymmetricProperty" />

. . .

</owl:ObjectProperty>

Если свойство А имеет подсвойство С, то

<owl:ObjectProperty rdf:ID="С">

<rdfs:subPropertyOf rdf:resource="#А" />

</owl:ObjectProperty>

В язык онтологий OWL дополнительно по отношению к RDFS введены такие отношения классов и свойств, как equivalentClass, equivalentProperty, sameAs (один и тот же), differentFrom, AllDifferent, distinctMembers.и др.

Средства equivalentClass и equivalentProperty используются для задания отношения эквивалентности между двумя классами или двумя свойствами. Средство sameAs позволяет создать несколько имен для одного и того же объекта. С помощью differentFrom можно задать отличие одного ресурса от других, а с помощью AllDifferent указать, что все перечисленные экземпляры различны.

ObjectProperty — используемое в OWL средство для описания отношения объектов. При описании свойств используются характеристики inverseOf (инверсия свойства), FunctionalProperty, InverseFunctionalProperty (инверсия функциональная), TransitiveProperty, SymmetricProperty и ограничения AllValuesFrom и SomeValuesFrom.

Примерами инверсных свойств, описываемых с помощью inverseOf, могут служить больше-меньше, родитель-потомок, холоднее-жарче и т.п. В функциональных отношениях и при функциональной инверсии определяемое свойство может не иметь ни одного или иметь только одно значение. Так, для субъекта "человек" свойство "место жительства" является функциональным. Если пара (x,y) объявлена с помощью TransitiveProperty как транзитивное отношение Р и пара (y,z) — экземпляр того же отношения Р, то пара (x,z) также экземпляр отношения Р. Так, отношение "больше" — транзитивное в отличие, например, от отношения "отец-сын". Отношение симметричности задается с помощью характеристики SymmetricProperty, примером такого отношения может служить отношение партнерства.

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

Пример 1

Отношение эквивалентности классов paper и publication и их отличие от класса letter:

<owl:Class rdf:about="paper">

<owl:equivalentClass rdf:resource="publication"/>

<owl:differentFrom rdf:resource="letter"/>

</owl:Class>

Пример 2

Описание свойства founded_before_1900, применяемого к классу City и принимающего значения в классе capitals, может быть представлено следующим образом:

<owl:ObjectProperty rdf:ID="founded_before_1900">

<owl:domain rdf:resource="#City"/>

<owl:range rdf:resource="#capitals"/>

</owl:ObjectProperty>

Здесь использована возможность присвоения классам и свойствам имен с помощью атрибута ID, например:

<owl:Class rdf:ID="City"/>

Теперь ссылка на этот класс имеет вид #City.

Онтология

Что такое "онтология"?

Ответ

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

#
14.07.201928.08 Кб2БУУ вопросы.docx
#
09.02.20161.51 Mб91Бычков Виктор Васильевич. Эстетика.rtf
#
15.12.2018193.74 Кб1в айфон.docx
#
18.09.2019145.41 Кб3ВАРИАНТ 5.doc
#
09.02.201640.96 Кб56Введение (дипломная работа_пример).doc
#
15.08.2019993.79 Кб5Введение в Web подробный полный курс.doc
#
23.09.2019155.65 Кб0ВКР_Бакалавр_с_практ.doc
#
18.09.2019158.72 Кб2внедоговорные обяз-ва.doc
#
28.10.20181.21 Mб33Волны Эллиотта и их составные части.doc
#
20.08.201987.55 Кб12вонючее земельное.doc
#
21.07.201963.49 Кб4Воплощение идеи вечной жизни.doc