В настоящее время аппаратные и программные платформы и технологии стремительно развиваются, непрерывно появляются все новые и новые возможности. В то же время, налицо тенденция к
Рост компьютерных и информационных технологий за сравнительно недолгое время, прошедшее с момента появления первых компьютеров (конец 1940х гг.) был невероятно стремительным и пока не проявляет никакой тенденции к замедлению. Считается, что каждые 10 лет происходит полная смена технологий в этих областях. В результате невероятно большое число аппаратных и программных технологий и платформ, которые, казалось бы, еще недавно были самыми передовыми и повсеместно используемыми, в настоящее время осталось лишь в памяти тех, кому с ними пришлось работать. Новые поколения разработчиков программного обеспечения, как правило, не знают даже техники и технологий десятилетней давности (а если и знают, то только из специальных ВУЗовских курсов), поскольку состояние дел в области компьютерных и информационных технологий успело полностью поменяться несколько раз за эти годы. Такие стремительные изменения, кстати, делают весьма неустойчивым компьютерный бизнес: на наших глазах многие фирмы-производители оборудования или программного обеспечения, имевшие, казалось бы, сверхустойчивое положение на рынке, в считанные годы проигрывали конкуренцию и иногда полностью исчезали, а на их месте появлялись новые "звезды". Так, к примеру, всего несколько лет назад произошло с одной из крупнейших в компьютерном мире фирмой DEC,долгие годы в значительной мере определявшей пути развития вычислительной техники и программного обеспечения, и сумевшей построить вполне самобытную "цивилизацию" компьютерных и программных решений - фирмы уже больше не существует, а про ее супербрэнды PDP, VAX и соответствующее программное обеспечение помнят весьма немногие. Учитывая все сказанное, представляется практически нецелесообразным давать сколько-нибудь подробный обзор аппаратных и программных архитектур, имеющихся в настоящее время - их срок жизни весьма мал. Ограничимся поэтому лишь весьма схематическим изложением основных платформ, с которыми приходится иметь дело современному разработчику. Весьма условно можно классифицировать основные встречающиеся в наше время аппаратные платформы следующим образом.
AMD ).RISC -процессоров).Архитектура процессора: RISC или CISC?
В 80-х годах прошлого века была предложена архитектура процессора с сокращенным набором машинных команд ( RISC - Reduced Instruction Set Computer ). Дейв Паттерсон и Карло Секуин сформулировали четыре основных принципа архитектуры RISC:
Создатели RISC -процессоров взяли набор из очень простых наиболее часто используемых команд, которые выполняются быстро, и объединили его с такими технологиями, как
В список основных поставщиков RISC -систем входят компании Hewlett-Packard (PA-RISC), Sun Microsystems Computers (SPARC), Digital Equipment (Alpha), Silicon Graphics - модуль MIPS (R210000) и союз IBM и Motorola (PowerPC).
С другой стороны, семейство Pentium компании Intel продолжает реализацию более традиционной вычислительной архитектуры с полным набором машинных команд (CISC). CISC -процессоры содержат в сотни раз больше команд, чем RISC -процессоры, и используют от 8 до 12 способов адресации памяти по сравнению с 2-3 способами в RISC.Однако
технические различия между RISC и CISC в последние годы становятся все менее четкими, особенно в том, что касается общей производительности систем. Одна архитектура заимствует хорошие идеи у другой. Раньше RISC -процессоры определялись как микропроцессоры с количеством команд меньше 128, сейчас же они имеют 200 команд - сравните с набором из 300 и более команд в CISC.Сегодня CISC -процессоры
используют конвейеризацию и другие современные технологии. Оба лагеря применяют большую кэш-память для повышения производительности.
Основные программные платформы можно классифицировать условно следующим образом:
Следует отметить, что операционные системы Unix и созданный вокруг них
В настоящее время наблюдается тенденция к унификации программных и аппаратных платформ, используемых в типовых конфигурациях.
MySQL и PostgreSQL.Кросс-платформенные технологии обеспечивают совместную эксплуатацию различных аппаратных и программных платформ в интересах организаций-потребителей.
Такими могут быть, как правило, сервисные программы,
Эта архитектура получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы. В архитектуре "клиент-сервер" программное обеспечение разделено на две части -клиентскую часть и серверную часть. Задача клиентской-части (программы-клиента) состоит во взаимодействии с пользователем, передаче пользовательского запроса серверу, получение запроса от серверной части (программы-сервера) и
представление его в удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и выдает ответы. Классические примеры: Web -технологии (клиент-браузер, сервер- Web -сервер), работа с распределенными СУБД (клиент - специальная программа, сервер - сервер базы данных). Развитие архитектуры "клиент-сервер", а особенно появление современных графических интерфейсов, привело сначала к появлению разновидности архитектуры клиент-сервер, называемой "архитектура с толстым
клиентом".Здесь логика представления данных и бизнес-логика размещаются на
клиенте, который (скажем, в случае, когда сервером является СУБД ) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL.Однако необходимость установки "СУБД приходится выполнять расчеты!)
Начало процессу развития корпоративного программного обеспечения в
Программа-клиент, таким образом, может быть "тонкой". Преимущества такой архитектуры очевидны:
СУБД и т.д.;C/C++ ).Следующий логический шаг - дальнейшее увеличение числа звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.
Основной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на
Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо-независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры (методов удаленных объектов). Средства RPC,в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры, программы RPC производят
CORBA (Common Object Request Broker Architecture) - это набор
Object Management Group, Inc. (OMG) - это интернациональная организация, основана в 1989 г., состоящая более чем из 800 членов: поставщиков информационных систем, разработчиков программного обеспечения и пользователей. OMG продвигает теорию и практику объектно-ориентированной технологии в область практической разработки программного обеспечения.
Этот процесс включает в себя разработку промышленных стандартов и спецификаций управления объектами с целью создания общей базы для разработки программного обеспечения. Первоочередными задачами являются: повторное использование, переносимость и
X/Open - независимая всемирная открытая организация, поддерживаемая большинством крупнейших поставщиков информационных систем, пользовательских организаций и компаний-производителей программного обеспечения. X/Open разрабатывает на основе существующих и создающихся стандартов всеобъемлющее и интегрированное системное окружение - Common Applications Environment (CAE).Компоненты CAE определены в стандартах X/Open CAE.Основная цель CAE - создание пакетов программных интерфейсов (API) которые могут применяться на практике с сохранением максимальной переносимости на уровне исходных кодов программ. API также повышают уровень взаимодействия приложений при помощи предоставления определений и ссылок на протоколы и их профили.
Вышеназванные спецификации тщательно тестируются, выдержавшим тестирование присваивается X/Open trademark (XPG brand),лицензированная X/Open.
Концептуальной инфраструктурой, на которой базируются все спецификации OMG,является Object Management Architecture (OMA).В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and vertical CORBAfacilities),язык определения интерфейсов распределенных объектов IDL (Interface Definition Language),стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная модель CORBA.
Реализовать технологию в соответствии со спецификациями может кто угодно. Созданные программные продукты, естественно, уже не являются открытыми, а становятся коммерческими продуктами.
CORBA определяет, каким образом программные компоненты, распределенные по сети, могут взаимодействовать друг с другом вне зависимости от окружающих их операционных систем и языков реализации. Центральным элементом архитектуры CORBA является ORB (Object Request Broker) - программное обеспечение, обеспечивающее связь между объектами, в том числе позволяющее
Тем самым ORB является связующим звеном между распределенными частями основанной на технологии CORBA системы, позволяя одной части системы не заботиться о физическом расположении других частей (объектов) системы. На рынке представлены ORB разных производителей (например, VisiBroker, WebLogic),но все они соответствуют единой спецификации CORBA.
Поэтому в принципе CORBA позволяет строить распределенные системы, одновременно используя ORB разных производителей, и строя систему одновременно на различных платформах и различных сетевых протоколах (это в терминологии CORBA называется интероперабельностью - interoperability).В архитектуре CORBA каждый объект, методы которого доступны другим объектам (обычно его называют CORBA -объектом) имеет уникальную по всей доступной
сети Объектную Ссылку (IOR - Interoperable Object Reference),по
которой к нему можно обратиться. Искать CORBA -объекты можно как по IOR, так и по символическим именам, если они зарегистрированы (обычно при создании) в специальном сервисе имен (NameService).Для обращения к методам CORBA -объекта последний имеет открытый для всех остальных CORBA -объектов интерфейс. Интерфейсы CORBA -объектов принято описывать на специальном, определенном спецификацией CORBA языке IDL (Interface Definition Language).
Производители ORB поставляют вместе с ORB также и утилиты, преобразующие описания интерфейсов CORBA -объектов в конструкции соответствующих языков программирования.
Основой
системы. Почти все современные ORBbi строятся на основе IIOP - Internet inter-ORB Protocol (это версия общего протокола GIOP,предусматривающая использование в качестве транспортного протокола TCP/IP).
Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (Common Facilities). Сервисы представляют собой обычные CORBA -объекты со стандартизованными (и написанными на IDL ) интерфейсами. К таким сервисам относится, например, уже упомянутый сервис имен NameService,сервис сообщений, позволяющий CORBA -объектам обмениваться
сообщениями, сервис транзакций, позволяющий CORBA -объектам организовывать транзакции. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано всего 14 объектных сервисов.
Между объектными сервисами и общими средствами CORBA нет четкой границы. Последние тоже представляют собой CORBA -объекты со стандартизованными интерфейсами. Common Facilities делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области). Например, разработаны Common Facilities для медицинских организаций, для ряда производств и т.п.
Основное содержание SOAP (Simple Object Access Protocol) состоит в обмене сообщениями между удаленными объектами по протоколу HTTP с использованием XML в качестве транспорта. Спецификация SOAP поддерживается и развивается консорциумом W3C (см. http : //www .w3.org/TR/SOAP/).
По функциональным возможностям технология SOAP весьма сходна с первыми версиями CORBA.Однако у нее есть одно несомненное достоинство: простота. На уровне передачи данных в глобальных сетях, между предприятиями, где большой сложности взаимодействие не предвидится - это оптимальное решение по соотношению время разработки/функциональность. Существуют многочисленные мосты (CORBA/SOAP, C++/SOAP, Java/SOAP).
COM (Component Object Model) - это стандарт Microsoft,определяющий структуру и взаимодействие компонентов программного обеспечения в современных операционных системах MS Windows.Архитектура современных Windows -приложений основана на COM:мир этих приложений - это мир COM -компонент. Компоненты COM обладают уникальностью и предоставляют другим
компонентам COM стандартным образом описанные интерфейсы, позволяющие получить доступ к методам этих компонентов. COM определяет механизм связи только между локальными (т.е. находящимися на том же компьютере) компонентами.
DCOM (Distributed Component Object Model) - это распределенная версия COM, обеспечивающая механизм связи между удаленным COM -компонентами (т.е. находящимися на разных компьютерах, но в среде MS Windows).Фактически DCOM это COM с добавленным к последнему механизмом RPC (remote procedure call).Сходную функциональность взаимодействия удаленных Windows -приложений
можно получить с использованием активно развиваемой в последнее время фирмой Microsoft технологии .NET.Важно подчеркнуть, что упомянутые в данном разделе технологии относятся исключительно к операционным системам Microsoft.
Архитектура EJB - это Bean -компоненты являются Java (J2EE) объектами, реализующими технологию Enterprise Java Beans (EJB).Каждый такой компонент выполняется под управлением сервера приложений, который должен соответствовать так называемой спецификации EJB- контейнера, т.е. поддерживать
соответствующий API - EJB Container API (обычно сервер приложений в таком случае называют EJB -контейнером). EJB -контейнер предоставляет компонентам (Enterprise Beans) сервисы системного уровня (например, многопоточность, механизм транзакций), оставаясь при этом прозрачным для разработчика приложений. Эти системные сервисы позволяют разработчику быстро создавать и разворачивать Enterprise Bean -компоненты:
контейнер как бы "закрывает" от разработчика EJB все сложности системного характера (например, уже упомянутые многопоточность или механизм транзакций), позволяя ему сосредоточиться исключительно на бизнес-логике приложения. Enterprise Bean -компонент - это объект требуемого класса, описанного на языке программирования Java,расположенный на стороне сервера
приложений и выполняющий часть бизнес-логики приложения (этим занимается собственно код компонента, осуществляющий задачи приложения). Например, в приложении контроля инвентаря, Enterprise Bean -компоненты могут реализовывать бизнес-логику приложения в методах checkInventoryLevel() и orderProduct(). Вызывая эти методы, удаленные клиенты могут получать доступ к инвентарным сервисам приложения.
Существует несколько причин, по которым использование Enterprise Bean -компонентов упрощает разработку больших распределенных корпоративных приложений.
EJB -контейнер предоставляет все необходимые сервисы системного уровня, позволяя разработчику Bean- компонента сконцентрироваться на решении бизнес-задач. Именно EJB- контейнер (а не Bean -разработчик) является ответственным за обеспечение работоспособности таких механизмов, как транзакции и авторизация доступа.EJB -компонентов является их расположение на сервере. Вследствие этого, разработчикам клиентов не приходится включать бизнес-логику в состав клиентского приложения - в таком коде не должно быть функциональности, реализующей бизнес-правила или доступ к базам данных. В результате, клиентское приложение получается гораздо меньшего размера, что очень важно для выполнения на устройствах с ограниченными ресурсами.Bean -компонент является их переносимость, сборщик приложений может собирать новые приложения из уже существующих Bean -компонент. Такие приложения могут быть запущены на любом J2EE -совместимом сервере.Следует задуматься об использовании Enterprise Bean -компонент, если ваше приложение отвечает хотя бы каким-то требованиям из перечисленных ниже.
Bean -компоненты поддерживают транзакции - механизм, управляющий одновременным доступом к разделяемым объектам.Bean -компонент. Клиентские приложения могут быть небольшими, многочисленными и различными.На сегодняшний день корпорацией Sun Microsystems было выпущено пять спецификации EJB - EJB 1.0, EJB 1.1, EJB 2.0, EJB 2.1 и EJB 3.0. В спецификации EJB 1.0 были впервые описаны сеансовые (session bean) и объектные (entity bean) компоненты. Спецификация EJB 1.1 расширяет спецификацию EJB 1.0.В EJB 2.0 были
добавлены компоненты, управляемые асинхронными сообщениями JMS (Java Messaging Service),а также EJB Query Language (EQL) - язык запросов. В EJB 2.1 был модифицирован и улучшен EQL, добавлена возможность вызова объектных компонент через HTTP/SOAP.Также компоненты,
управляемые сообщениями, смогли принимать сообщения не только по протоколу JMS,но и по другим протоколам. Последняя на данный момент версия EJB - EJB 3.0.В ней модифицированы механизмы описания компонент (вместо XML -файла - метаданные), а сам процесс разработки переведен на JAVA 5.0.
Jini представляет собой технологию создания распределенных систем, ориентированную исключительно на использование Java.В настоящий момент Jini является торговой маркой Sun Microsystems.
Технология Jini состоит из трех основных компонентов:
В отличие от EJB,технология JINI не требует наличия специальных серверов приложений. Кроме того, если модель использования EJB принципиально двух- или трехзвенна (существует клиент, запрашивающий методы EJB,работающий под управлением контейнера, и, как правило, сервер, например, СУБД, к которому обращается в процессе работы EJB,причем иерархия запросов в этой схеме строго задана), то в
модели JINI все сервисы абсолютно равноправны между собой (каждый из них может быть как сервером, так и клиентом к любому). Такая "равноправная" архитектура взаимосвязей называется одноранговой (peer-to-peer).В модели JINI сервисы представляют, таким образом, своего рода "интеллектуальные устройства" (можно представить себе в качестве примера сервис печати), общающиеся между собой по стандартизованным правилам, имеющие стандартизованные имена, общую модель безопасности и т.п. Такой
Поиск сервиса, который может выполнить определенную задачу, происходит приблизительно по такому сценарию.
Технология Jini разрабатывалась с целью создания системы, которая бы требовала к себе мало внимания при обслуживании, успевала за постоянным изменением и наращиванием системы и обеспечивала постоянную доступность сервисов посредством Интернета. Безопасность системы и конфиденциальность информации передаваемой в сети достигается за счет распределенной системы безопасности. Наращиваемость систем возможна за счет добавления новых, наследования и изменения старых сервисов, доступных посредством интернет. Постоянная доступность становится возможной за счет рассредоточенности системы, в которой можно изменять приложения беспрерывно, так, что сервис будет доступен из Интернета постоянно.
Web -технологии чрезвычайно сильно используются в современном корпоративном программном обеспечении. Перечислим основные используемые технологии Web- программирования.
CGI -скрипт - это программа, выполняемая на стороне сервера и следующая правилам интерфейса CGI (Common gateway interface).Исторически это первая технология "динамического" программирования для Web. CGI -скрипты могут быть как обычными исполняемыми модулями (написанными на любом языке программирования, например, на C++ ), так и сценариями ("скриптами"), написанными на интерпретируемых языках
(например, на Perl, Unix shell, Tcl.)
Последовательность действий при работе с CGI -скриптом следующая:
Web -серверу.Web -сервер инициирует выполнение CGI -скрипта (т.е. просто запускает программу, если она представляет собой исполняемый модуль, либо запуская соответствующий интерпретатор с подачей ему на вход текста сценария, если это сценарий) и передает ему необходимые данные.CGI -скрипт выполняется, и по окончании работы передает результаты (ответ на исходный запрос) вызвавшему его серверу. При этом CGI -скрипт может производить сколь угодно сложные действия, например, обращаться к другим удаленным программам и т.п.Web -сервер отдает полученные от CGI -скрипта данные клиенту.Из современных Web -технологий это, пожалуй, самая простая, но и самая немаштабируемая, а также немобильная (платформо-зависимая) и не вполне устойчивая технология.
Ряд Web -серверов предусматривают встроенные интерпретаторы специальных языков для динамического Web -программирования. Примерами являются ASP для Web -сервера Internet Information Server (IIS) и PHP (например, для Web -сервера Apache).
ASP (или, соответственно, PHP) страница представляет собой обычный HTML файл, который кроме текста и тэгов HTML содержит еще и конструкции соответствующего языка (ASP или PHP).При запросе этого документа клиентом Web -сервер сначала просматривает документ, интерпретируя директивы соответствующего языка (ASP или PHP) и преобразуя их в
обычный статический HTML,который и отдается клиенту. Важно отметить, что как ASP,так и PHP,являются полноценными языками программирования, что позволяет создать с использованием этих технологий сложнейшие Web -системы (вплоть до полномоаштабного управления производством или, например, торговлей). Эти технологии кроме того, весьма просты, и поэтому популярны, например, для создания электронных магазинов. Недостатком является принципиальная интерпретируемость этих языков, а также существенная привязка к конкретному Web- серверу
(например, ASP работает только для IIS).
Апплеты - это программы на Java,работающие под управлением другой программы (как правило, интернет-браузера). Апплеты загружаются с Web сайта вместе со статическим HTML кодом, а затем выполняются браузером на компьютере пользователя (естественно, для этого браузер использует виртуальную Java -машину). Они могут использоваться для создания богатых графикой и интерактивными возможностями пользовательских интерфейсов, которые не способны выразить средствами обычного
языка разметки HTML.Важно однако понимать, что апплет - это интеллектуальная программа, а не просто мультипликация (как, например, Flash анимация). Другими словами, апплет способен обрабатывать действия пользователя и динамически менять свое поведение. При работе с программами, полученными из сети, пользователь может столкнуться с неприятными последствиями их работы. Существует множество вирусов, "троянских
коней" или просто некачественных программ. Апплет автоматически запускается при загрузке web- страницы,
поэтому апплеты требуют повышенного режима безопасности. Для обеспечения защиты, создателями Java был разработан механизм, получивший название "песочницы" (sandbox),ограничивает доступ "ненадежных" апплетов к компьютеру пользователя. Если разработчику апплета понадобилось расширить возможности апплета - ему необходимо поставить цифровую подпись, тогда апплет воспринимается броузером как "надежный", и вы сами решаете, доверять апплету или нет. Хотя цифровая подпись не обеспечивает вашей безопасности, вы можете установить происхождение апплета, при возникновении проблем. "Песочница" включает в себя три основных механизма защиты:
Апплеты могли бы быть почти идеальным со всех точек зрения решением для создателей динамических Web -сайтов и корпоративных Web -систем: они не требуют затрат на установку, соответствуют лозунгу сторонников чистого HTML ("написано однажды -работает везде") и имеют собственный богатый графический пользовательский интерфейс. Но до сих пор эти надежды не сбылись. Апплеты, в общем, используются сравнительно редко. Возможно, потому, что некоторые разработчики неверно
оценили накладные расходы при интерпретации байт-кода в виртуальной машине Java.У других множество нареканий вызывает защита, основанная на принципе "песочницы" ( sandbox ), который не позволяет Java использовать в полной мере локальные и удаленные службы. Третьи отмечают различия между виртуальными машинами основных браузеров, имеющихся на рынке. Так или иначе до сих апплеты не оправдали возложенных на них ожиданий, и Web -приложения на базе HTML не
были вытеснены Web -приложениями с равным уровнем переносимости и мобильности, но функционально более мощным графическим пользовательским интерфейсом.
Тем не менее, при помощи апплетов можно сделать немало полезного. Вот несколько ярких примеров.
Сервлеты - это программы на Java,которые работают на серверном компьютере.Их выполнение инициируется Web -сервером или сервером приложений (Application Server) по запросу клиента. Последовательность выполнения сервлета следующая.
Web -серверу или серверу приложений.Web -сервер или сервер приложений инициирует выполнение сервлета, передавая ему необходимые данные.Java -машине сервера), и по окончании работы передает результаты (ответ на исходный запрос) вызвавшему его серверу. При этом сервлет может производить сколь угодно сложные действия, например, обращаться к другим сервлетам или удаленным программам и т.п. Обмен данными между сервлетом сервлетом и сервером происходит при помощи специального Java-API (его главные составляющие это классы HttpServletRequest для передачи запроса и HttpServletResponse для ответа).На самом деле схема, как правило, чуть более сложная. В связке с сервером работает базовый сервлет. Именно ему сервер отправляет данные и от него же получает ответ, отправляемый клиенту. Фактически, базовый сервлет является "мозгом" сервера. Основная функция этого сервлета - прочитать запрос клиента, расшифровать его и, в соответствиии с расшифровкой, передать работу сервлету, отвечающему за конкретный тип запрашиваемой информации. Зачастую, для достижения скорости, роль базового сервлета играет сам сервер.
Именно по такой схеме работает, скажем, Web -сервер Jakarta Tomcat.По сути дела, в этой схеме нет ничего принципиально нового по сравнению с CGI- скриптами, кроме, конечно, большей унифицированности и существенно меньшей зависимости от платформ (благодаря использованию Java).Действительно, сервлеты и были разработаны, чтобы заменить CGI -скрипты.
Среда исполнения сервлетов, кроме того, обеспечивает некоторые полезные и экономящие время возможности, включая преобразование HTTP-запросов из сети в удобный для использования HttpServletRequest объект, обеспечивая выходной поток для программиста, чтобы использовать его для ответа, и преобразование удобного в работе объекта HttpServletResponse в HTTP-ответ,который может быть послан обратно по сети. Она также обеспечивает удобные возможности управления сессиями, в том числе хранения состояния сессии, что позволяет, например, назначать ресурсы (такие как подключения к базе данных), которые могут использоваться для многократных запросов.
По сравнению с апплетами сервлеты имеют преимущества с архитектурной точки зрения. Если апплет, посланный по сети, окажется в несовместимой с ним виртуальной машине Java,то он, скорее всего, корректно работать не будет. Сервлет развертывается в более управляемой среде. Так как параметры JVM известны, проблем совместимости не возникает. Более того, среда, которая окружает данную виртуальную машину, может увеличивать производительность сервлета.
Некоторые серверы Java -приложений могут компилировать сервлеты в "родной" для себя код и тем самым значительно увеличивать скорость выполнения. Другие серверы запускают параллельно несколько JVM,иногда в различных процессах хостовой ОС. Эти стратегии увеличивают масштабируемость и отказоустойчивость службы.
Вариантом сервлета является JSP -страница (Java Server Pages). JSP -страница, подобно ASP или PHP скрипту представляет собой обычный HTML файл с записанным внутри него при помощи специального синтаксиса исходным Java -кодом сервлета. Каждая JSP -страница автоматически преобразуется в сервлет Web -сервером при запросе на эту страницу со стороны клиента. Затем сервлет выполняется по описанной схеме. Подытоживая, можно сказать, что сервлеты имеют преимущество
максимальной переносимости: они могут работать на большем количестве Web -серверов или серверов приложений и на большем количестве платформ, чем любая другая технология динамических Web -приложений, доступная сегодня. Следует также отметить, что API сервлета намного проще в изучении и в использовании, чем технология EJB,поэтому и применяется пока что чаще (хотя EJB также уже стал фактически промышленной технологией).
В современном развитии программных и аппаратных платформ прослеживаются две отчетливые тенденции:
Таким образом, одна и та же задача по разработке программного продукта может быть решена множеством разных способов, и менеджер проекта по разработке программного продукта должен уметь выбирать платформы и технологии, исходя из особенностей задачи и конкретных условий.
В настоящее время аппаратные и программные платформы и технологии стремительно развиваются, непрерывно появляются все новые и новые возможности. В то же время, налицо тенденция к
Рост компьютерных и информационных технологий за сравнительно недолгое время, прошедшее с момента появления первых компьютеров (конец 1940х гг.) был невероятно стремительным и пока не проявляет никакой тенденции к замедлению. Считается, что каждые 10 лет происходит полная смена технологий в этих областях. В результате невероятно большое число аппаратных и программных технологий и платформ, которые, казалось бы, еще недавно были самыми передовыми и повсеместно используемыми, в настоящее время осталось лишь в памяти тех, кому с ними пришлось работать. Новые поколения разработчиков программного обеспечения, как правило, не знают даже техники и технологий десятилетней давности (а если и знают, то только из специальных ВУЗовских курсов), поскольку состояние дел в области компьютерных и информационных технологий успело полностью поменяться несколько раз за эти годы. Такие стремительные изменения, кстати, делают весьма неустойчивым компьютерный бизнес: на наших глазах многие фирмы-производители оборудования или программного обеспечения, имевшие, казалось бы, сверхустойчивое положение на рынке, в считанные годы проигрывали конкуренцию и иногда полностью исчезали, а на их месте появлялись новые "звезды". Так, к примеру, всего несколько лет назад произошло с одной из крупнейших в компьютерном мире фирмой DEC,долгие годы в значительной мере определявшей пути развития вычислительной техники и программного обеспечения, и сумевшей построить вполне самобытную "цивилизацию" компьютерных и программных решений - фирмы уже больше не существует, а про ее супербрэнды PDP, VAX и соответствующее программное обеспечение помнят весьма немногие. Учитывая все сказанное, представляется практически нецелесообразным давать сколько-нибудь подробный обзор аппаратных и программных архитектур, имеющихся в настоящее время - их срок жизни весьма мал. Ограничимся поэтому лишь весьма схематическим изложением основных платформ, с которыми приходится иметь дело современному разработчику. Весьма условно можно классифицировать основные встречающиеся в наше время аппаратные платформы следующим образом.
AMD ).RISC -процессоров).Архитектура процессора: RISC или CISC?
В 80-х годах прошлого века была предложена архитектура процессора с сокращенным набором машинных команд ( RISC - Reduced Instruction Set Computer ). Дейв Паттерсон и Карло Секуин сформулировали четыре основных принципа архитектуры RISC:
Создатели RISC -процессоров взяли набор из очень простых наиболее часто используемых команд, которые выполняются быстро, и объединили его с такими технологиями, как
В список основных поставщиков RISC -систем входят компании Hewlett-Packard (PA-RISC), Sun Microsystems Computers (SPARC), Digital Equipment (Alpha), Silicon Graphics - модуль MIPS (R210000) и союз IBM и Motorola (PowerPC).
С другой стороны, семейство Pentium компании Intel продолжает реализацию более традиционной вычислительной архитектуры с полным набором машинных команд (CISC). CISC -процессоры содержат в сотни раз больше команд, чем RISC -процессоры, и используют от 8 до 12 способов адресации памяти по сравнению с 2-3 способами в RISC.Однако
технические различия между RISC и CISC в последние годы становятся все менее четкими, особенно в том, что касается общей производительности систем. Одна архитектура заимствует хорошие идеи у другой. Раньше RISC -процессоры определялись как микропроцессоры с количеством команд меньше 128, сейчас же они имеют 200 команд - сравните с набором из 300 и более команд в CISC.Сегодня CISC -процессоры
используют конвейеризацию и другие современные технологии. Оба лагеря применяют большую кэш-память для повышения производительности.
Основные программные платформы можно классифицировать условно следующим образом:
Следует отметить, что операционные системы Unix и созданный вокруг них
В настоящее время наблюдается тенденция к унификации программных и аппаратных платформ, используемых в типовых конфигурациях.
MySQL и PostgreSQL.Кросс-платформенные технологии обеспечивают совместную эксплуатацию различных аппаратных и программных платформ в интересах организаций-потребителей.
Такими могут быть, как правило, сервисные программы,
Эта архитектура получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы. В архитектуре "клиент-сервер" программное обеспечение разделено на две части -клиентскую часть и серверную часть. Задача клиентской-части (программы-клиента) состоит во взаимодействии с пользователем, передаче пользовательского запроса серверу, получение запроса от серверной части (программы-сервера) и
представление его в удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и выдает ответы. Классические примеры: Web -технологии (клиент-браузер, сервер- Web -сервер), работа с распределенными СУБД (клиент - специальная программа, сервер - сервер базы данных). Развитие архитектуры "клиент-сервер", а особенно появление современных графических интерфейсов, привело сначала к появлению разновидности архитектуры клиент-сервер, называемой "архитектура с толстым
клиентом".Здесь логика представления данных и бизнес-логика размещаются на
клиенте, который (скажем, в случае, когда сервером является СУБД ) общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL.Однако необходимость установки "СУБД приходится выполнять расчеты!)
Начало процессу развития корпоративного программного обеспечения в
Программа-клиент, таким образом, может быть "тонкой". Преимущества такой архитектуры очевидны:
СУБД и т.д.;C/C++ ).Следующий логический шаг - дальнейшее увеличение числа звеньев, причем возрастет не только за счет разбиения, когда "утоньшается" каждое из известных технических звеньев, но вся бизнес-модель строится как многозвенная. Современные корпоративные программные системы представляют собой, как правило, сложные системы взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.
Основной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на
Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартизованным и платформо-независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры (методов удаленных объектов). Средства RPC,в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры, программы RPC производят
CORBA (Common Object Request Broker Architecture) - это набор
Object Management Group, Inc. (OMG) - это интернациональная организация, основана в 1989 г., состоящая более чем из 800 членов: поставщиков информационных систем, разработчиков программного обеспечения и пользователей. OMG продвигает теорию и практику объектно-ориентированной технологии в область практической разработки программного обеспечения.
Этот процесс включает в себя разработку промышленных стандартов и спецификаций управления объектами с целью создания общей базы для разработки программного обеспечения. Первоочередными задачами являются: повторное использование, переносимость и
X/Open - независимая всемирная открытая организация, поддерживаемая большинством крупнейших поставщиков информационных систем, пользовательских организаций и компаний-производителей программного обеспечения. X/Open разрабатывает на основе существующих и создающихся стандартов всеобъемлющее и интегрированное системное окружение - Common Applications Environment (CAE).Компоненты CAE определены в стандартах X/Open CAE.Основная цель CAE - создание пакетов программных интерфейсов (API) которые могут применяться на практике с сохранением максимальной переносимости на уровне исходных кодов программ. API также повышают уровень взаимодействия приложений при помощи предоставления определений и ссылок на протоколы и их профили.
Вышеназванные спецификации тщательно тестируются, выдержавшим тестирование присваивается X/Open trademark (XPG brand),лицензированная X/Open.
Концептуальной инфраструктурой, на которой базируются все спецификации OMG,является Object Management Architecture (OMA).В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and vertical CORBAfacilities),язык определения интерфейсов распределенных объектов IDL (Interface Definition Language),стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная модель CORBA.
Реализовать технологию в соответствии со спецификациями может кто угодно. Созданные программные продукты, естественно, уже не являются открытыми, а становятся коммерческими продуктами.
CORBA определяет, каким образом программные компоненты, распределенные по сети, могут взаимодействовать друг с другом вне зависимости от окружающих их операционных систем и языков реализации. Центральным элементом архитектуры CORBA является ORB (Object Request Broker) - программное обеспечение, обеспечивающее связь между объектами, в том числе позволяющее
Тем самым ORB является связующим звеном между распределенными частями основанной на технологии CORBA системы, позволяя одной части системы не заботиться о физическом расположении других частей (объектов) системы. На рынке представлены ORB разных производителей (например, VisiBroker, WebLogic),но все они соответствуют единой спецификации CORBA.
Поэтому в принципе CORBA позволяет строить распределенные системы, одновременно используя ORB разных производителей, и строя систему одновременно на различных платформах и различных сетевых протоколах (это в терминологии CORBA называется интероперабельностью - interoperability).В архитектуре CORBA каждый объект, методы которого доступны другим объектам (обычно его называют CORBA -объектом) имеет уникальную по всей доступной
сети Объектную Ссылку (IOR - Interoperable Object Reference),по
которой к нему можно обратиться. Искать CORBA -объекты можно как по IOR, так и по символическим именам, если они зарегистрированы (обычно при создании) в специальном сервисе имен (NameService).Для обращения к методам CORBA -объекта последний имеет открытый для всех остальных CORBA -объектов интерфейс. Интерфейсы CORBA -объектов принято описывать на специальном, определенном спецификацией CORBA языке IDL (Interface Definition Language).
Производители ORB поставляют вместе с ORB также и утилиты, преобразующие описания интерфейсов CORBA -объектов в конструкции соответствующих языков программирования.
Основой
системы. Почти все современные ORBbi строятся на основе IIOP - Internet inter-ORB Protocol (это версия общего протокола GIOP,предусматривающая использование в качестве транспортного протокола TCP/IP).
Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (Common Facilities). Сервисы представляют собой обычные CORBA -объекты со стандартизованными (и написанными на IDL ) интерфейсами. К таким сервисам относится, например, уже упомянутый сервис имен NameService,сервис сообщений, позволяющий CORBA -объектам обмениваться
сообщениями, сервис транзакций, позволяющий CORBA -объектам организовывать транзакции. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано всего 14 объектных сервисов.
Между объектными сервисами и общими средствами CORBA нет четкой границы. Последние тоже представляют собой CORBA -объекты со стандартизованными интерфейсами. Common Facilities делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области). Например, разработаны Common Facilities для медицинских организаций, для ряда производств и т.п.
Основное содержание SOAP (Simple Object Access Protocol) состоит в обмене сообщениями между удаленными объектами по протоколу HTTP с использованием XML в качестве транспорта. Спецификация SOAP поддерживается и развивается консорциумом W3C (см. http : //www .w3.org/TR/SOAP/).
По функциональным возможностям технология SOAP весьма сходна с первыми версиями CORBA.Однако у нее есть одно несомненное достоинство: простота. На уровне передачи данных в глобальных сетях, между предприятиями, где большой сложности взаимодействие не предвидится - это оптимальное решение по соотношению время разработки/функциональность. Существуют многочисленные мосты (CORBA/SOAP, C++/SOAP, Java/SOAP).
COM (Component Object Model) - это стандарт Microsoft,определяющий структуру и взаимодействие компонентов программного обеспечения в современных операционных системах MS Windows.Архитектура современных Windows -приложений основана на COM:мир этих приложений - это мир COM -компонент. Компоненты COM обладают уникальностью и предоставляют другим
компонентам COM стандартным образом описанные интерфейсы, позволяющие получить доступ к методам этих компонентов. COM определяет механизм связи только между локальными (т.е. находящимися на том же компьютере) компонентами.
DCOM (Distributed Component Object Model) - это распределенная версия COM, обеспечивающая механизм связи между удаленным COM -компонентами (т.е. находящимися на разных компьютерах, но в среде MS Windows).Фактически DCOM это COM с добавленным к последнему механизмом RPC (remote procedure call).Сходную функциональность взаимодействия удаленных Windows -приложений
можно получить с использованием активно развиваемой в последнее время фирмой Microsoft технологии .NET.Важно подчеркнуть, что упомянутые в данном разделе технологии относятся исключительно к операционным системам Microsoft.
Архитектура EJB - это Bean -компоненты являются Java (J2EE) объектами, реализующими технологию Enterprise Java Beans (EJB).Каждый такой компонент выполняется под управлением сервера приложений, который должен соответствовать так называемой спецификации EJB- контейнера, т.е. поддерживать
соответствующий API - EJB Container API (обычно сервер приложений в таком случае называют EJB -контейнером). EJB -контейнер предоставляет компонентам (Enterprise Beans) сервисы системного уровня (например, многопоточность, механизм транзакций), оставаясь при этом прозрачным для разработчика приложений. Эти системные сервисы позволяют разработчику быстро создавать и разворачивать Enterprise Bean -компоненты:
контейнер как бы "закрывает" от разработчика EJB все сложности системного характера (например, уже упомянутые многопоточность или механизм транзакций), позволяя ему сосредоточиться исключительно на бизнес-логике приложения. Enterprise Bean -компонент - это объект требуемого класса, описанного на языке программирования Java,расположенный на стороне сервера
приложений и выполняющий часть бизнес-логики приложения (этим занимается собственно код компонента, осуществляющий задачи приложения). Например, в приложении контроля инвентаря, Enterprise Bean -компоненты могут реализовывать бизнес-логику приложения в методах checkInventoryLevel() и orderProduct(). Вызывая эти методы, удаленные клиенты могут получать доступ к инвентарным сервисам приложения.
Существует несколько причин, по которым использование Enterprise Bean -компонентов упрощает разработку больших распределенных корпоративных приложений.
EJB -контейнер предоставляет все необходимые сервисы системного уровня, позволяя разработчику Bean- компонента сконцентрироваться на решении бизнес-задач. Именно EJB- контейнер (а не Bean -разработчик) является ответственным за обеспечение работоспособности таких механизмов, как транзакции и авторизация доступа.EJB -компонентов является их расположение на сервере. Вследствие этого, разработчикам клиентов не приходится включать бизнес-логику в состав клиентского приложения - в таком коде не должно быть функциональности, реализующей бизнес-правила или доступ к базам данных. В результате, клиентское приложение получается гораздо меньшего размера, что очень важно для выполнения на устройствах с ограниченными ресурсами.Bean -компонент является их переносимость, сборщик приложений может собирать новые приложения из уже существующих Bean -компонент. Такие приложения могут быть запущены на любом J2EE -совместимом сервере.Следует задуматься об использовании Enterprise Bean -компонент, если ваше приложение отвечает хотя бы каким-то требованиям из перечисленных ниже.
Bean -компоненты поддерживают транзакции - механизм, управляющий одновременным доступом к разделяемым объектам.Bean -компонент. Клиентские приложения могут быть небольшими, многочисленными и различными.На сегодняшний день корпорацией Sun Microsystems было выпущено пять спецификации EJB - EJB 1.0, EJB 1.1, EJB 2.0, EJB 2.1 и EJB 3.0. В спецификации EJB 1.0 были впервые описаны сеансовые (session bean) и объектные (entity bean) компоненты. Спецификация EJB 1.1 расширяет спецификацию EJB 1.0.В EJB 2.0 были
добавлены компоненты, управляемые асинхронными сообщениями JMS (Java Messaging Service),а также EJB Query Language (EQL) - язык запросов. В EJB 2.1 был модифицирован и улучшен EQL, добавлена возможность вызова объектных компонент через HTTP/SOAP.Также компоненты,
управляемые сообщениями, смогли принимать сообщения не только по протоколу JMS,но и по другим протоколам. Последняя на данный момент версия EJB - EJB 3.0.В ней модифицированы механизмы описания компонент (вместо XML -файла - метаданные), а сам процесс разработки переведен на JAVA 5.0.
Jini представляет собой технологию создания распределенных систем, ориентированную исключительно на использование Java.В настоящий момент Jini является торговой маркой Sun Microsystems.
Технология Jini состоит из трех основных компонентов:
В отличие от EJB,технология JINI не требует наличия специальных серверов приложений. Кроме того, если модель использования EJB принципиально двух- или трехзвенна (существует клиент, запрашивающий методы EJB,работающий под управлением контейнера, и, как правило, сервер, например, СУБД, к которому обращается в процессе работы EJB,причем иерархия запросов в этой схеме строго задана), то в
модели JINI все сервисы абсолютно равноправны между собой (каждый из них может быть как сервером, так и клиентом к любому). Такая "равноправная" архитектура взаимосвязей называется одноранговой (peer-to-peer).В модели JINI сервисы представляют, таким образом, своего рода "интеллектуальные устройства" (можно представить себе в качестве примера сервис печати), общающиеся между собой по стандартизованным правилам, имеющие стандартизованные имена, общую модель безопасности и т.п. Такой
Поиск сервиса, который может выполнить определенную задачу, происходит приблизительно по такому сценарию.
Технология Jini разрабатывалась с целью создания системы, которая бы требовала к себе мало внимания при обслуживании, успевала за постоянным изменением и наращиванием системы и обеспечивала постоянную доступность сервисов посредством Интернета. Безопасность системы и конфиденциальность информации передаваемой в сети достигается за счет распределенной системы безопасности. Наращиваемость систем возможна за счет добавления новых, наследования и изменения старых сервисов, доступных посредством интернет. Постоянная доступность становится возможной за счет рассредоточенности системы, в которой можно изменять приложения беспрерывно, так, что сервис будет доступен из Интернета постоянно.
Web -технологии чрезвычайно сильно используются в современном корпоративном программном обеспечении. Перечислим основные используемые технологии Web- программирования.
CGI -скрипт - это программа, выполняемая на стороне сервера и следующая правилам интерфейса CGI (Common gateway interface).Исторически это первая технология "динамического" программирования для Web. CGI -скрипты могут быть как обычными исполняемыми модулями (написанными на любом языке программирования, например, на C++ ), так и сценариями ("скриптами"), написанными на интерпретируемых языках
(например, на Perl, Unix shell, Tcl.)
Последовательность действий при работе с CGI -скриптом следующая:
Web -серверу.Web -сервер инициирует выполнение CGI -скрипта (т.е. просто запускает программу, если она представляет собой исполняемый модуль, либо запуская соответствующий интерпретатор с подачей ему на вход текста сценария, если это сценарий) и передает ему необходимые данные.CGI -скрипт выполняется, и по окончании работы передает результаты (ответ на исходный запрос) вызвавшему его серверу. При этом CGI -скрипт может производить сколь угодно сложные действия, например, обращаться к другим удаленным программам и т.п.Web -сервер отдает полученные от CGI -скрипта данные клиенту.Из современных Web -технологий это, пожалуй, самая простая, но и самая немаштабируемая, а также немобильная (платформо-зависимая) и не вполне устойчивая технология.
Ряд Web -серверов предусматривают встроенные интерпретаторы специальных языков для динамического Web -программирования. Примерами являются ASP для Web -сервера Internet Information Server (IIS) и PHP (например, для Web -сервера Apache).
ASP (или, соответственно, PHP) страница представляет собой обычный HTML файл, который кроме текста и тэгов HTML содержит еще и конструкции соответствующего языка (ASP или PHP).При запросе этого документа клиентом Web -сервер сначала просматривает документ, интерпретируя директивы соответствующего языка (ASP или PHP) и преобразуя их в
обычный статический HTML,который и отдается клиенту. Важно отметить, что как ASP,так и PHP,являются полноценными языками программирования, что позволяет создать с использованием этих технологий сложнейшие Web -системы (вплоть до полномоаштабного управления производством или, например, торговлей). Эти технологии кроме того, весьма просты, и поэтому популярны, например, для создания электронных магазинов. Недостатком является принципиальная интерпретируемость этих языков, а также существенная привязка к конкретному Web- серверу
(например, ASP работает только для IIS).
Апплеты - это программы на Java,работающие под управлением другой программы (как правило, интернет-браузера). Апплеты загружаются с Web сайта вместе со статическим HTML кодом, а затем выполняются браузером на компьютере пользователя (естественно, для этого браузер использует виртуальную Java -машину). Они могут использоваться для создания богатых графикой и интерактивными возможностями пользовательских интерфейсов, которые не способны выразить средствами обычного
языка разметки HTML.Важно однако понимать, что апплет - это интеллектуальная программа, а не просто мультипликация (как, например, Flash анимация). Другими словами, апплет способен обрабатывать действия пользователя и динамически менять свое поведение. При работе с программами, полученными из сети, пользователь может столкнуться с неприятными последствиями их работы. Существует множество вирусов, "троянских
коней" или просто некачественных программ. Апплет автоматически запускается при загрузке web- страницы,
поэтому апплеты требуют повышенного режима безопасности. Для обеспечения защиты, создателями Java был разработан механизм, получивший название "песочницы" (sandbox),ограничивает доступ "ненадежных" апплетов к компьютеру пользователя. Если разработчику апплета понадобилось расширить возможности апплета - ему необходимо поставить цифровую подпись, тогда апплет воспринимается броузером как "надежный", и вы сами решаете, доверять апплету или нет. Хотя цифровая подпись не обеспечивает вашей безопасности, вы можете установить происхождение апплета, при возникновении проблем. "Песочница" включает в себя три основных механизма защиты:
Апплеты могли бы быть почти идеальным со всех точек зрения решением для создателей динамических Web -сайтов и корпоративных Web -систем: они не требуют затрат на установку, соответствуют лозунгу сторонников чистого HTML ("написано однажды -работает везде") и имеют собственный богатый графический пользовательский интерфейс. Но до сих пор эти надежды не сбылись. Апплеты, в общем, используются сравнительно редко. Возможно, потому, что некоторые разработчики неверно
оценили накладные расходы при интерпретации байт-кода в виртуальной машине Java.У других множество нареканий вызывает защита, основанная на принципе "песочницы" ( sandbox ), который не позволяет Java использовать в полной мере локальные и удаленные службы. Третьи отмечают различия между виртуальными машинами основных браузеров, имеющихся на рынке. Так или иначе до сих апплеты не оправдали возложенных на них ожиданий, и Web -приложения на базе HTML не
были вытеснены Web -приложениями с равным уровнем переносимости и мобильности, но функционально более мощным графическим пользовательским интерфейсом.
Тем не менее, при помощи апплетов можно сделать немало полезного. Вот несколько ярких примеров.
Сервлеты - это программы на Java,которые работают на серверном компьютере.Их выполнение инициируется Web -сервером или сервером приложений (Application Server) по запросу клиента. Последовательность выполнения сервлета следующая.
Web -серверу или серверу приложений.Web -сервер или сервер приложений инициирует выполнение сервлета, передавая ему необходимые данные.Java -машине сервера), и по окончании работы передает результаты (ответ на исходный запрос) вызвавшему его серверу. При этом сервлет может производить сколь угодно сложные действия, например, обращаться к другим сервлетам или удаленным программам и т.п. Обмен данными между сервлетом сервлетом и сервером происходит при помощи специального Java-API (его главные составляющие это классы HttpServletRequest для передачи запроса и HttpServletResponse для ответа).На самом деле схема, как правило, чуть более сложная. В связке с сервером работает базовый сервлет. Именно ему сервер отправляет данные и от него же получает ответ, отправляемый клиенту. Фактически, базовый сервлет является "мозгом" сервера. Основная функция этого сервлета - прочитать запрос клиента, расшифровать его и, в соответствиии с расшифровкой, передать работу сервлету, отвечающему за конкретный тип запрашиваемой информации. Зачастую, для достижения скорости, роль базового сервлета играет сам сервер.
Именно по такой схеме работает, скажем, Web -сервер Jakarta Tomcat.По сути дела, в этой схеме нет ничего принципиально нового по сравнению с CGI- скриптами, кроме, конечно, большей унифицированности и существенно меньшей зависимости от платформ (благодаря использованию Java).Действительно, сервлеты и были разработаны, чтобы заменить CGI -скрипты.
Среда исполнения сервлетов, кроме того, обеспечивает некоторые полезные и экономящие время возможности, включая преобразование HTTP-запросов из сети в удобный для использования HttpServletRequest объект, обеспечивая выходной поток для программиста, чтобы использовать его для ответа, и преобразование удобного в работе объекта HttpServletResponse в HTTP-ответ,который может быть послан обратно по сети. Она также обеспечивает удобные возможности управления сессиями, в том числе хранения состояния сессии, что позволяет, например, назначать ресурсы (такие как подключения к базе данных), которые могут использоваться для многократных запросов.
По сравнению с апплетами сервлеты имеют преимущества с архитектурной точки зрения. Если апплет, посланный по сети, окажется в несовместимой с ним виртуальной машине Java,то он, скорее всего, корректно работать не будет. Сервлет развертывается в более управляемой среде. Так как параметры JVM известны, проблем совместимости не возникает. Более того, среда, которая окружает данную виртуальную машину, может увеличивать производительность сервлета.
Некоторые серверы Java -приложений могут компилировать сервлеты в "родной" для себя код и тем самым значительно увеличивать скорость выполнения. Другие серверы запускают параллельно несколько JVM,иногда в различных процессах хостовой ОС. Эти стратегии увеличивают масштабируемость и отказоустойчивость службы.
Вариантом сервлета является JSP -страница (Java Server Pages). JSP -страница, подобно ASP или PHP скрипту представляет собой обычный HTML файл с записанным внутри него при помощи специального синтаксиса исходным Java -кодом сервлета. Каждая JSP -страница автоматически преобразуется в сервлет Web -сервером при запросе на эту страницу со стороны клиента. Затем сервлет выполняется по описанной схеме. Подытоживая, можно сказать, что сервлеты имеют преимущество
максимальной переносимости: они могут работать на большем количестве Web -серверов или серверов приложений и на большем количестве платформ, чем любая другая технология динамических Web -приложений, доступная сегодня. Следует также отметить, что API сервлета намного проще в изучении и в использовании, чем технология EJB,поэтому и применяется пока что чаще (хотя EJB также уже стал фактически промышленной технологией).
В современном развитии программных и аппаратных платформ прослеживаются две отчетливые тенденции:
Таким образом, одна и та же задача по разработке программного продукта может быть решена множеством разных способов, и менеджер проекта по разработке программного продукта должен уметь выбирать платформы и технологии, исходя из особенностей задачи и конкретных условий.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.