Представленное "Практическое пособие по разработке Web-приложений" включает документацию и исходные коды рабочих примеров. Здесь не рассматривается язык программирования Java, полагая, что читатель уже знаком с данным средством разработки. Основной акцент делается на Java сервлетах и JSP-страницах, входящих в Java 2 Enterprise Edition.

Java 2 Enterprise Edition

Java 2 Enterprise Edition - это комплекс взаимодействующих Java-технологий, базирующихся на спецификациях, разработанных фирмой Sun Microsystems(http://java.sun.com/j2ee/), представляющих стандарт разработки серверных приложений уровня предприятия.

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

Технологии платформы J2EE

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

Различные версии J2EE поддерживают разные спецификации технологий, например EJB, Servlets и т.д. В данном практическом пособии мы ориентируемся на спецификацию J2EE 1.3, поддерживающую спецификации EJB 2.0, Servlets 2.3, JSP 1.2. Каждая конкретная реализация платформы J2EE, удовлетворяющая спецификации J2EE версии 1.3, должна предоставлять пользователю перечисленные ниже технологии и соответствующие программные интерфейсы.

Java Remote Method Invocation (RMI) и RMI / IIOP

Java Remote Method Invocation представляет собой Java-ориентированный метод реализации взаимодействиями между распределенными объектами информационной системы. RMI - это технология построения распределенных приложений на основе спецификации языка Java. Типичным примером является организация связи между двумя объектами, запущенными на выполнение на разных компьютерах. RMI / IIOP является расширением RMI с целью интеграции с технологией CORBA. Вообще-то говоря, официальным API в технологии J2EE является не RMI, а именно RMI / IIOP.

Java Naming and Directory Interface, JNDI

Java Naming and Directory Interface (Интерфейс наименований и каталогов) используется для доступа из кода приложения к системам наименований и каталогов. Так, например, JNDI применяется для связи EJB-компонентов через Интернет с другими ресурсами распределенной системы.

Java Messaging Service, JMS

Java Messaging Service (Сервис сообщений Java) используется для взаимодействия J2EE-приложения с помощью сообщений как между отдельными компонентами внутри приложения, так и с внешними системами сообщений среднего уровня - Message-Oriented Middleware (MOM). К таким системам относятся, например, IBM MQSeries и Microsoft Message Queue (MSMQ). Технология сообщений Java выступает альтернативой методу организации связи с помощью протокола RMI/IIOP.

Java Servlets

Технология Java-сервлетов. Servlet (Сервлет) является сетевой технологией, расширяющей функциональные возможности Web-сервера. Сервлеты - это сетевые компоненты, работающий в режиме запрос/ответ. Запрос, получаемый от клиента через Web-браузер, обрабатывается сервлетом, после чего клиенту отсылается ответ. Функционирование сервлетов не требует управления сервером приложения.

Java Server Pages (JSP)

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

Java Database Connectivity, JDBC

Java Database Connectivity - это средство организации доступа к базам данных в сети. Интерфейс JDBC является API для доступа к любым реляционным базам данных.

Java Transaction API, JTA и Java Transaction Service, JTS

Java Transaction API (Программный интерфейс Java транзакций) и Java Transaction Service (Сервис Java-транзакций) используются для поддержки механизма транзакций в J2EE.

Enterprise JavaBeans, EJB

Enterprise JavaBeans - это самая главная технология, которая определяет основные свойства и назначение платформы J2EE. Версия 1.3 платформы J2EE включает поддержку спецификации EJB 2.0, которая дает описание стандартных компонентов серверного приложения и путей их реализации (свойства компонентов, методика написания их программного кода, принципы использования компонентов в многоуровневых приложениях и пр.). В спецификации EJB 2.0 представлены также стандартные соглашения, связывающие компоненты EJB и серверы приложений (application servers), управляющие компонентами. Технология EJB опирается на другие технологии J2EE.

Java Interface Definition Language, Java IDL

Java Interface Definition Language (Язык определения интерфейсов Java) реализует технологию CORBA на основе Java, что позволяет интегрировать CORBA в J2EE-приложения.

Java Mail и JavaBeans Activation Framework

Java Mail предоставляет пользователю возможность отправлять сообщения электронной почты непосредственно из программного приложения, что особенно важно при реализации задач электронной коммерции. При этом поддерживается независимость от платформы и протокола связи. Технология Java Mail базируется на технологии JavaBeans Activation Framework, JAF (Структура активации JavaBeans).

Java Connector Architecture

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

Java API for XML Parsing

Java API for XML Parsing, JAXP (Интерфейс Java для XML-разбора) - технология, позволяющая пользователю работать с документами XML, входящими в состав программного приложения.

Java Authentication and Authorization Service

Java Authentication and Authorization Service, JAAS (Идентификация и авторизация Java) - технология для поддержания защиты информации, предоставляющая пользователю соответствующий API.

Введение

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

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

Состав платформы J2EE:

• Набор стандартов для компонентов J2EE и для платформы J2EE, на которой работают эти компоненты.
• Эскиз проекта разработки приложения, подробно описывающий платформу J2EE и содержащий ценную информацию о том, как следует разрабатывать приложения J2EE.
• Справочная реализация платформы J2EE, предоставленная фирмой Sun Microsystems Inc. в качестве стандарта, с которым можно сравнивать создаваемые коммерческие продукты J2EE. Справочная реализация содержит полностью готовые к использованию примеры приложений.
• Набор тестов на совместимость, предназначенный для проверки и оценивания коммерческих реализаций J2EE относительно стандартов J2EE.

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

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

Дополнительная информация приведена в обзоре платформы J2EE фирмы Sun на Web-сайте http://java.sun.com/ . Выберите ссылку Products & APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) > Overview .

Разработка J2EE в Nutshell

С точки зрения разработчика приложения:

Пример

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

Зачем нужна платформа J2EE?

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

Каждый из этих пунктов подробнее рассматривается ниже в этом разделе.

Стандартизованная, апробированная в промышленности среда

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

Рисунок 1: многоуровневая архитектура J2EE

Клиентский уровень

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

Средний уровень

Web-уровень

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

Бизнес-уровень

Компоненты бизнес-уровня - это объекты .

• Они содержат бизнес-логику приложения.
• Они отправляют запросы на EIS-уровень в соответствии с бизнес-логикой, обычно в ответ на запрос из Web-уровня.

EIS-уровень

EIS-уровень представляет хранимые данные приложения, часто в форме RDBMS. EIS-уровень может также состоять из устаревших систем или ERP, доступ к которым осуществляется через API архитектуры коннектора J2EE.

Дополнительная информация о API архитектуры коннектора J2EE приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > J2EE Connector Architecture.

Дополнительная информация о стандартных конфигурациях развертывания J2EE приведена в разделе Концепция: конфигурации развертывания J2EE .

Серверы J2EE

Серверы J2EE - это коммерческие продукты, реализующие платформу J2EE. Примерами коммерческих серверов J2EE могут служить BEA WebLogic, Borland Enterprise Server, IBM WebSphere и iPlanet.

Термин "сервер J2EE" несколько расплывчат. Обычно имеется в виду "сервер J2EE, поддерживающий и контейнер Web, и контейнер EJB". Если использовать более точную терминологию, Web-сервер J2EE (такой как справочный Web-сервер J2EE, реализация Tomcat) поддерживает Web-контейнер; сервер приложения J2EE (или EJB) поддерживает контейнер EJB.

Контейнеры J2EE

Компоненты Web

Сервлеты Java

Технология Сервлет Java позволяет Web-серверу обрабатывать запросы, поступающие от Web-клиента, и отправлять ответы с динамическим содержимым. Для создания этого динамического содержимого сервлет Java может взаимодействовать с другими компонентами Web и EJB. Созданное содержимое может принимать форму любого текстового документа, в том числе HTML и XML. Кроме того, технологию Сервлет Java можно применять в качестве конечной точки Web-служб во взаимодействии с API JAX-RPC.

Примечание: применение технологии Сервлет Java в качестве конечной точки Web-служб - это новая функция J2EE 1.4 (JAX-RPC 1.1), не поддерживаемая в предыдущих версиях.

Дополнительная информация о сервлетах J2EE приведена на Web-сайте http://java.sun.com/ . Выберите ссылку J2EE > Blueprints .

Страницы JSP

Технология Страницы JSP основана на сервлетах Java, но вместо кода в ней применяется текст. Страница JSP обрабатывает запросы и выдает ответы, как сервлет, но ее логика контролируется прежде всего презентациями. Страница JSP содержит в основном статический HTML, определяющий формат представления данных, получаемых из других источников, таких как объекты JavaBean и EJB. Для того чтобы добавить новые возможности в JSP, разработчик компонентов Web может создавать библиотеки пользовательских тегов.

http://java.sun.com/ . Выберите ссылку J2EE > Blueprints.

Страницы HTML

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

Объекты JavaBean

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

JavaBean не является технологией J2EE, но используется технологиями J2EE. Например, объекты EJB могут применять объекты JavaBean в качестве значений. Различия между объектами JavaBean и объектами Enterprise JavaBean описаны в разделе .

Дополнительная информация об объектах JavaBean приведена в разделе Концепция: объекты JavaBean .

Объекты Enterprise JavaBean

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

Компоненты, определяемые спецификацией EJB, называются объектами Enterprise JavaBean (EJB). Объекты EJB - это серверные компоненты Java, в которых вы реализуете бизнес-правила приложения.

Объекты EJB развертываются и выполняются в среде, называемой контейнером EJB; он был описан ранее в параграфе . Этот контейнер предоставляет службы , и . Архитектура EJB скрывает эти подробности, что позволяет разработчикам компонентов сосредоточиться на бизнес-логике.

Объект Enterprise JavaBean (EJB) - это совокупность, состоящая из интерфейсов Java, класса реализации EJB и файла описания XML. Интерфейсы EJB и класс реализации должны отвечать правилам, задаваемым спецификацией EJB, например, они должны реализовывать определенные интерфейсы и предоставлять определенные методы обратного вызова.

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

Существует три типа объектов EJB: , и .

http://java.sun.com/ . Выберите ссылку J2EE > Blueprints.

Сеансовые объекты EJB

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

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

Сеансовые объекты EJB без сохранения состояния могут использоваться в качестве конечной точки Web-служб, согласно спецификации JSR и EJB.

Примечание: применение сеансовых объектов EJB без сохранения состояния в качестве Web-служб - это новая функция J2EE 1.4 (JSR 109 и EJB 2.1), не поддерживаемая в предыдущих версиях.

Дополнительная информация о сеансовых объектах EJB приведена в документе Enterprise JavaBeans Specification, Version 2.1 на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans .

Сущностные объекты EJB

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

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

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

Дополнительная информация о сущностных объектах EJB приведена в документе Enterprise JavaBeans Specification, Version 2.1 на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans .

Управляемые сообщениями объекты EJB

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

Примечание: управляемые сообщениями объекты EJB не поддерживаются в версиях до EJB 2.0. Поддержка типов сообщений, отличных от JMS, - это новая функция спецификации EJB 2.1, поэтому они не поддерживаются в предыдущей версии.

Дополнительная информация об управляемых сообщениями объектах EJB приведена в документе Enterprise JavaBeans Specification, Version 2.0 на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans .

Сравнительное описание объектов JavaBean и EJB

Несмотря на схожесть названий, объекты EJB значительно сложнее, чем обычные объекты JavaBean. И те, и другие определяют архитектуры для многоразовых компонентов, но объекты EJB добавляют необходимую поддержку для создания распределенных, многопользовательских служб. Собирать оба типа компонентов можно с помощью инструментов компоновки приложений, но для выполнения объекты EJB необходимо развертывать в контейнере EJB.

Службы (API) для компонентов J2EE

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

	Описание	Контейнеры J2EE, где доступны API
	Спецификация EJB определяет модель компонентов для объектов EJB - компонентов бизнес-уровня, которые автоматически поддерживают службы удаленных соединений, управления транзакциями, защиты, постоянных данных и т.п. Дополнительная информация об объектах EJB приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Enterprise JavaBeans .	Приложение-клиент* * только клиентские API
	Служба идентификации и проверки прав доступа Java (JAAS) предоставляет службы для идентификации и проверки прав доступа пользователей, позволяющие убедиться, что у пользователей есть права на выполнение действия. Дополнительная информация о JAAS приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2SE > Core Java > Java Authentication and Authorization Service (JAAS) .	Приложение-клиент
	JavaBeans Activation Framework (JAF) предоставляет службы для идентификации данных и создания экземпляра JavaBean для манипулирования этими данными. Дополнительная информация о JAF приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2SE > Desktop Java > JavaBeans > JavaBeans Activation Framework .	Приложение-клиент
	API Java для обработки XML (JAXP) предоставляет абстрактный интерфейс для обработки документов XML, который можно применять с совместимыми синтаксическими анализаторами и преобразователями, использующими DOM SAX или XSLT. http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Java API for XML Processing (JAXP) .	Приложение-клиент
	Спецификация JAX-RPC определяет API клиента для доступа к Web-службам, а также приемы реализации конечных точек Web-служб. Дополнительная информация о JAX-RPC приведена в разделе JAX-RPC /font>	Приложение-клиент
Web-службы для J2EE 1.1	Спецификация Web-служб для J2EE (JSR-109) определяет функции, которые сервер приложения J2EE должен поддерживать для развертывания конечных точек Web-служб... Дополнительная информация о Web-службах для J2EE приведена на Web-сайте http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html	Приложение-клиент
	API SSAJ предоставляет возможность управлять сообщениями SOAP. Дополнительная информация о JAXP приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > SOAP with Attachments API for Java (SAAJ) .	Приложение-клиент
	Спецификация JAXR определяет API для доступа клиентов к реестрам на базе XML, таким как реестры WebXML и UDDI. Дополнительная информация о JAXP приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Java API for XML Registries (JAXR).	Приложение-клиент
	API JavaMail предоставляет среду, которую можно расширить для компоновки приложений почты на базе Java. Дополнительная информация о JavaMail приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > JavaMail .	Приложение-клиент
	Java Database Connectivity (JDBC) - это API для доступа к табличным источникам данных, например базам данных SQL, электронным таблицам и простым файлам. Дополнительная информация о JDBC приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > JDBC .	Приложение-клиент
	Служба сообщений Java (JMS) предоставляет службы асинхронной отправки сообщений для передачи данных и уведомлении о событиях. JMS позволяет применять управляемые сообщениями объекты EJB для асинхронной обработки сообщений, доставляемых в темы и очереди JMS. Дополнительная информация о JMS приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Java Message Service .	Приложение-клиент
	Спецификация Java Naming and Directory Interface (JNDI) предоставляет службы присвоения имен и работы с каталогами для регистрации и поиска распределенных компонентов и ресурсов. Клиентам достаточно знать зарегистрированное имя JNDI компонента или ресурса; знать фактическое расположение в сети не обязательно. Пример: объекты EJB регистрируются в каталоге предприятия во время развертывания с помощью поля ejb-name файла описания. Клиенты J2EE находят объект EJB с помощью функции поиска JNDI. Все, что необходимо знать клиентам, - это имя, под которым объект EJB был зарегистрирован в каталоге. Функция поиска JNDI возвращает ссылку на домашний объект EJB. Дополнительная информация о JNDI приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2SE > Core Java > Java Naming and Directory Interface (JNDI) .	Приложение-клиент
	API транзакций Java (JTA) определяет интерфейсы для управления службами распределенных транзакций, выполняемыми в администраторе транзакций, в администраторе ресурсов, на сервере приложения и в приложении. Дополнительная информация о JTA приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Transactions.
J2EE Connector 1.5	Service Provider Interface (SPI) архитектуры коннектора J2EE определяет стандарт для подключения ресурсов EIS к контейнеру J2EE. Адаптер ресурсов EIS (поставляемый вендором EIS) встраивается в контейнер J2EE, благодаря чему контейнер может предоставлять EIS защищенную поддержку транзакций. После этого компоненты в контейнере могут получать доступ к EIS через SPI архитектуры коннектора J2EE. Дополнительная информация о коннекторах J2EE приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > J2EE Connector Architecture.
	Технология JavaServer Pages предоставляет разработчикам Web возможность создавать и обслуживать динамические Web-страницы. Страницы JSP основаны на тексте и используют теги типа XML для выполнения бизнес-логики и создания пользовательского информационного наполнения. Технология JSP позволяет делегировать бизнес-логику другим компонентам, так что в страницу JSP нужно встраивать лишь логику презентаций. Дополнительная информация о JSP приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > JavaServer Pages .
	Сервлеты Java расширяют возможности Web-сервера в сфере компоновки приложений на базе Web. Сервлеты часто используются в интерактивных Web-приложениях, когда Web-сервер отвечает на пользовательские запросы с помощью динамически создаваемого информационного наполнения, получаемого из существующих бизнес-систем. Дополнительная информация о сервлетах Java приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Java Servlet .
	Технология Remote Method Invocation, работающая на основе Internet Inter-Orb Protocol (RMI-IIOP), позволяет компонентам Java обмениваться информацией с устаревшими компонентами CORBA, написанными на других языках, таких как C++ или Smalltalk. http://java.sun.com/ . Выберите ссылку Products and APIs > RMI-IIOP .	Приложение-клиент
J2EE Management 1.0	API управления J2EE предоставляет API, с помощью которых инструменты управления могут запрашивать сервер приложения J2EE с целью определить его текущее состояние, развернутые на нем приложения и т.п. Дополнительная информация о RMI-IIOP приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > J2EE Management Specification .	Приложение-клиент
	API JMX применяется API J2EE Management для предоставления некоторой необходимой поддержки для управления продуктом J2EE. Дополнительная информация о RMI-IIOP приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2SE > Core Java > Java Management Extensions (JMX) .	Приложение-клиент
J2EE Deployment 1.1	API развертывания J2EE определяет интерфейсы между средой выполнения инструмента развертывания и компонентами модулей, предоставляемыми сервером приложения J2EE. Дополнительная информация о J2EE Deployment приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > J2EE Deployment Specification .
	Спецификация JACC определяет контракт между сервером приложения J2EE и провайдером стратегий проверки прав доступа. Дополнительная информация о JACC приведена на Web-сайте http://java.sun.com/ . Выберите ссылку Products & Technologies > J2EE > Java Authorization Contract for Containers .	Приложение-клиент

Сборка и развертывание

Приложения J2EE состоят из файла описания приложения (application.xml) и одного или нескольких модулей J2EE, образующих приложение. Модули являются многоразовыми, переносимыми компонентами. Приложения J2EE упаковываются в архивы.ear.

Файлы описания

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

Для каждого приложения или модуля J2EE существует шаблонный тип файла описания. Шаблонные файлы описания, например ejb-jar.xml для модуля EJB, определяют информацию, которая применяется к EJB независимо от сервера, на котором он развернут. Напротив, файлы описания, связанные с конкретным сервером, задают информацию, учитываемую только на этом сервере. Таким файлам описания присваиваются имена, отражающие сервер, для которого они предназначены.

Модули J2EE

Модуль J2EE состоит из предназначенного для него файла описания и различных элементов, образующих модуль, включая:

• Элементы, не относящиеся к Java, развернутые на Web-сервере (страницы JSP, файлы изображений, статические страницы HTML); иными словами, элементы виртуальных каталогов
• Элементы Java, развернутые на Web-сервере (сервлеты, объекты JavaBean, классы Java)
• Элементы, развернутые на сервере EJB (объекты EJB и поддерживающие классы Java)

Существует три вида модулей J2EE:

Приложение-клиент J2EE

Модули приложений-клиентов J2EE упаковываются в архивы.jar и содержат:

• файл описания application-client.xml
• файлы.class реализации приложения-клиента

Web-компонент

Модули Web-компонента упаковываются в архивы.war и содержат:

• файл описания web.xml и файлы описания для конкретных серверов
• страницы JSP
• страницы HTML
• изображения (например, .gif и.jpg)
• файлы классов сервлетов

Если модуль - это Web-служба, то архив.war содержит:

• файл описания webservices.xml
• файлы классов сервлетов
• файлы WSDL

Enterprise JavaBean

Отдельный архив JAR Enterprise JavaBean может содержать несколько объектов EJB, но их информация развертывания хранится в одном наборе файлов описания (ejb-jar.xml плюс файлы описания для конкретных серверов).

Стандартный модуль Enterprise JavaBean содержит:

• файл описания ejb-jar.xml и файлы описания для конкретных серверов
• файлы классов реализации EJB

Модуль Enterprise JavaBean Web-службы содержит:

• файл описания webservices.xml
• файлы классов реализации EJB

http://java.sun.com/ . Выберите ссылку Docs & Training > J2EE Platform, Enterprise Edition > Java Blueprints Program .

Разработка приложений J2EE

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

Роли для разработки приложений J2EE

Роли для разработки приложений перечислены в следующей таблице.

Название роли	Описание
Провайдер продуктов J2EE	Провайдер продуктов J2EE - это поставщик реализации платформы J2EE, называемой также продуктом J2EE. Примерами провайдеров продуктов J2EE могут служить BEA, IBM и Sun. Эти организации обычно используют имеющиеся у них широкие возможности при создании реализации платформы J2EE. Например, реализация BEA создана на основе исключительно успешного монитора обработки транзакций Tuxedo BEA. Провайдер продуктов J2EE также предоставляет инструменты, необходимые для поддержки развертывания приложений и управления ими.
Провайдер компонентов приложений	Провайдер компонентов приложений фактически охватывает несколько ролей, например, разработчиков EJB и проектировщиков документов HTML. Эти роли отвечают за создание компонентов приложений J2EE с помощью предоставленных инструментов.
Ассемблер приложений	Ассемблер приложений создает приложение J2EE из компонентов приложения J2EE с помощью предоставленных инструментов. Приложение J2EE доставляется как файл Enterprise Archive (EAR). Ассемблер приложений также описывает все внешние зависимости приложения J2EE. Средство развертывания обрабатывает эти зависимости во время фактического развертывания приложения J2EE.
Средство развертывания	Средство развертывания отвечает за развертывание приложения J2EE и его компонентов в операционной среде. Первый этап развертывания заключается в установке различных компонентов приложения в соответствующих контейнерах J2EE. Второй этап - в настройке всех объявленных внешних зависимостей для их обработки. Например, определенные роли защиты отображаются в группы пользователей и учетные записи в операционной среде. На третьем этапе развертывания новое приложение выполняется, чтобы оно было готово к приему запросов.
Системный администратор	Системный администратор отвечает за инфраструктуру среды выполнения, включающую все развернутые приложения J2EE. Эта роль выполняет задачу с помощью соответствующих инструментов, предоставляемых провайдером продукта J2EE.
Провайдер инструментов	Провайдер инструментов предоставляет инструменты, предназначенные для поддержки разработки и упаковки компонентов приложений. Эти инструменты часто соответствуют различным типам создаваемых компонентов приложений и включают IDE, например IBM VisualAge for Java и Borland JBuilder.
Провайдер компонентов системы	Провайдер компонентов системы предоставляет различные компоненты системного уровня, например адаптеры ресурсов или провайдер стратегии проверки прав доступа.

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

Этапы разработки приложения J2EE

В этом разделе описаны различные этапы разработки приложения J2EE, задаваемые спецификацией J2EE. Это следующие этапы:

• Разработка компонентов

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

  В следующей таблице приведены этапы разработки приложений J2EE.

  Этап разработки J2EE	Задачи	Выполняющая задачу роль J2EE	Результат (доставляемый объект)
  Создание приложения-клиента J2EE	Создает код клиента и компилирует классы Создает файл описания application-client.xml Создает архив файлов JAR, содержащий файлы классов и XML
  Создание Web-компонента	Создает код сервлета и компилирует классы Создает страницы JSP и HTML Создает файл описания web.xml Создает архив файлов Web Application Archive (WAR), содержащий файлы классов, .jsp, .html и XML	(разработчик программного обеспечения: сервлеты; проектировщик Web: страницы JSP и страницы HTML)
  Создание объекта Enterprise JavaBean	Создать код EJB и откомпилировать классы Создать файл описания ejb-jar.xml и файлы описания для конкретных серверов Создать архив файлов JAR, содержащий файлы классов и XML	(разработчик программного обеспечения)
  Сборка приложения J2EE	Создать файл описания application.xml Создать архив файлов EAR, содержащий объекты EJB (JAR), Web-компоненты (WAR) и файлы XML
  Развертывание приложения J2EE	Добавить приложение J2EE (EAR) в среду сервера J2EE Отредактировать файл описания application.xml с локальной конфигурацией среды Развертывает приложение J2EE на сервере J2EE		Установленное и настроенное приложение J2EE

  
  

  Каждый этап процесса разработки создает доставляемый объект, используемый на следующем этапе. Компоненты, создаваемые на этапах разработки компонентов, используются на этапе сборки приложения J2EE для создания архива EAR приложения J2EE. На этапе развертывания приложения J2EE архив EAR развертывается на сервере J2EE.

  Доставляемые объекты каждого этапа переносимы и не обязательно должны выполняться теми же пользователями или даже в той же среде; среда должна лишь удовлетворять требованиям платформы J2EE.

  Дополнительная информация об упаковке и развертывании J2EE приведена на Web-сайте http://java.sun.com/ . Выберите ссылку J2EE > Blueprints .

  Дополнительная информация

  Дополнительная информация о J2EE приведена в документе Sun J2EE Blueprints. Его можно найти на Web-сайте http://java.sun.com/ . Выберите ссылку J2EE > Blueprints > Guidelines: Designing Enterprise Applications with the J2EE Platform, Second Edition .

  Копия этого документа содержится также в Rational Unified Process.

  Главы документа Sun J2EE Blueprints, содержащие информацию по конкретным темам, указаны в следующей таблице.

  Концепция J2EE	Глава J2EE Blueprints
  Технологии платформы J2EE
  Объекты Enterprise JavaBean
  Транзакции
  Сервлеты
  Страницы JSP
  Развертывание и упаковка

lampsound 29 сентября 2011 в 03:15

Конфигурирование J2SE и J2EE приложений: стандартные способы и их альтернативы

• Java

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

J2SE

java.util.Properties

Классический вариант конфигурирования приложений - применение класса java.util.Properties . Внутри все очень просто - по сути это расширение интерфейса java.util.Map с возможностью сохранения и инициализации значений по-умолчанию.

Минусов несколько:

• Отсутствует типизация - getProperty возвращает только String;
• Отслеживание изменений в файле конфигурации не поддерживается (т.е. при изменении никаких событий порождено не будет и приложение ничего о них не узнает);
• Работа только с одним файлом. N файлов = N экземпляров Properties.

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

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

На все это можно возразить: «Можно же просто добавить перечитывание файла настроек и подсистему генерации событий» - да, это так, только все это уже сделано и сделано до мелочей, которые кажутся неочевидными сейчас, но всегда обязательно проявляются.
В следующей статье я расскажу о Commons Configuration и том, как обозначенные выше проблемы там решаются.
А пока - рассмотрим типовые варианты конфигурирования J2EE-приложений.

J2EE-EJB3

Инжекция ресурса

Один из наиболее простых вариантов конфигурирования EJB-приложений заключается в использовании дескриптора развертывания (ejb-jar.xml):

< enterprise-beans >
< session >
< ejb-name > MyService
< env-entry >
< env-entry-name > myProperty
< env-entry-type > java.lang.String
< env-entry-value > 100500

В дескрипторе мы указываем имя (env-entry-name), тип (env-entry-type) и значение параметра (env-entry-value), после чего производим его инжекцию при помощи аннотации :

@Resource(name = "myProperty" )
private String myProperty;
@PostConstruct
public void postConstruct() {
System.out .println("myProperty = " + myProperty);
}

Данный подход позволяет работать с параметрами следующих типов:

• java.lang.String
• java.lang.Boolean
• java.lang.Byte
• java.lang.Character
• java.lang.Double
• java.lang.Float
• java.lang.Integer
• java.lang.Long
• java.lang.Short

К минусам стоит отнести то, что изменение параметров приводит к редеплою приложения, что, в свою очередь, приводит к некоторому периоду неработоспособности.
Политика редеплоя зависит от настроек сканера изменений дескрипторов приложений на сервере приложений.
Так, например, в случае с сервером приложений JBoss 5.x-6.x изменение ejb-jar.xml гарантированно приводит к редеплою (если, конечно, сканер не выключен и редеплой производится вручную, через JMX-консоль).

Использование внешнего файла настроек

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

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

Тем не менее, использование файлов в роли read-only источников данных допустимо, когда они находятся внутри EE-приложений. Дело в том, что в случае кластерного развертывания EE-приложение будет одинаковым на всех узлах.

Таким образом мы приходим к классическому варианту использования java.util.Properties внутри EE-приложений:

@Stateless(mappedName = "BackendService" )
public class BackendServiceBean implements BackendServiceLocal {

private static final String P_PROPERTIES = "myProperties.properties" ;

private static final Logger logger = LoggerFactory.getLogger(BackendServiceBean.class );

@EJB
private DataRepositoryLocal dataRepository;

@Resource(name = "remoteURL" )
private String remoteURL;

private Properties properties;

@PostConstruct
private void init(){
InputStream propertiesResource = null ;
try {
propertiesResource = getClass().getResourceAsStream(P_PROPERTIES);
properties = new Properties();
properties.load(propertiesResource);
} catch (Exception e) {
logger.error("Error" , e);
}finally {
if (propertiesResource !=null ){
try {
propertiesResource.close();
} catch (Exception e) {
logger.error("Error" , e);
}
}
}
}

public Properties getProperties() {
return properties;
}

Минусы те-же, что и обозначенные ранее у J2SE и java.util.Properties. Плюс к этому - мы находимся в контексте J2EE и не можем просто добавить некий поток, отслеживающий изменения файлов и генерирующий события (т.к. потоки в J2EE-приложении создавать нельзя).
Кто-то может сказать: «Надо перечитывать.properties файл каждый раз, когда приложение вызывает getProperty у нашего properties-proxy-объекта». Да, это можно сделать, но в этом случае следует забыть о высокой производительности приложения - отрытие файла на чтение, его загрузка в буфер, парсинг и создание экземпляра Properties будет вносить ощутимую задержку в обработку.
Правильный вариант применения такого решения - хранение исключительно статических read-only настроек.

Другие варианты

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

Для J2EE приложений такими вариантами могут быть:

• Получение настроек из БД (причем занесением в БД занимается другое приложение - например админка-конфигуратор);
• Запрос настроек у удаленного компонента-поставщика (например с именем ConfigurationProvider).

Как для J2EE, так и для J2SE-приложений можно применять различные фреймворки/создавать свои собственные, заточенные под решение задач конфигурирования.

J2EE-Servlets

При конфигурировании сервлетов мы имеем дело с дескриптором web.xml, в котором задаются необходимые нам параметры:

< web-app version ="2.5" xmlns ="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation ="http://java.sun.com/xml/ns/j2ee java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" >

< context-param >
< param-name > myContextParam1
< param-value > value1

< context-param >
< param-name > myContextParam2
< param-value > value2

< filter >
< filter-name > myFilter
< filter-class > net.universe.filter.EntityAccessFilter
< init-param >
< param-name > checkType
< param-value > ldap

< init-param >
< param-name > myParam
< param-value > true

< servlet >
< servlet-name > MyServlet
< servlet-class > net.universe.servlet.MyServlet
< init-param >
< param-name > servletParam1
< param-value > paramValue1

< load-on-startup > 1

Настройка заключается в изменении элементов конфигурации param-value. После изменений и сохранения файла у нас также происходит редеплой приложения с последующим периодом его неработоспособности. Этот способ конфигурирования, как и вариант с ejb-jar.xml, наиболее подходит для параметров, которые не предполагается изменять по ходу работы приложения. Техники по работе с runtime-настройками здесь аналогичны применяемым в случае с EJB - базы данных, JNDI и т.п…

Общее для всех

System.getProperty

Общим, для всех перечисленных способов конфигурирования, является применение системных параметров передающихся в строке запуска Java-приложения:
java -DmyProperty1=myPropertyValue1 -DmyProperty2=myPropertyValue2 -jar myapp.jar

После этого параметры конфигурации можно взять при помощи класса java.lang.System:
String string = System.getProperty("myProperty1");

Данный способ ограниченно применим в контексте работы с J2EE - при работе в кластерном режиме системная переменная может не приехать на все узлы. Почему «может» - потому что, например, у сервера приложений JBoss есть служба SystemPropertiesService и фрагменты по ее конфигурированию можно включить в наше EE-приложение (т.е. в итоге «системная» переменная окажется на всех узлах, т.к. будет в конфигурационных файлах в составе приложения).

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

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

JMX

JMX является удобным средством много для чего, в том числе и для конфигурирования приложений. Можно комбинировать применение java.util.Properties/Commons Configuration и выставленного MBean-а с методами установки/получения значений наших параметров (при установке - с последующим делегированием к properties.setProperty).
Подобное решение может успешно применяться там, где нет доступа к файлам конфигурации, но есть доступ к MBeanServer-у по сети.

Минусы у такого подхода следующие:

• JMX подсистема в J2SE приложениях по-умолчанию выключена;
• Допустимо применение только простых типов параметров (сложные тоже можно, но тогда управлять через jconsole уже не получится);
• В контексте J2EE работа с JMX может приобретать весьма замысловатые формы. Так, например, микроядро JBoss 4.x-6.x использует в своей основе JMX и попытка получить дерево MBean-ов в утилите jconsole приведет, с высокой долей вероятности, к ее зависанию/очень медленной работе.

На этом пока все.

В ближайшее время будет завершена статья о библиотеке Commons Configuration, которая значительно расширяет возможности по работе с конфигурационными файлами в J2SE и J2EE приложениях.

Спасибо за внимание!

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

Это приложение содержит модуль EJB и веб-модуль. Модуль EJB включает в себя класс сущностей, фасад сеанса класса сущностей и управляемый сообщениями компонент. Веб-модуль содержит сервлеты для отображения и отправки сообщений и единичный сеансный компонент для подсчета числа пользователей в сеансе.

Перед изучением этого руководства необходимо ознакомиться со следующей документацией.

Упражнения по темам руководства

Для работы с этим учебным курсом требуется следующее программное обеспечение и ресурсы.

Предпосылки

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

• Программирование на Java
• IDE NetBeans

О приложении J2EE NewsApp

В этом руководстве приводится несложный пример создания многоуровневого приложения Java EE 6 с именем NewsApp. В приложении NewsApp используется несколько функций, внедренных в спецификации Java EE 6.

Структура приложения NewsApp, как правило, соответствует следующим уровням.

• Веб-уровень. Веб-уровень содержит логику представления приложения и запускается на сервере Java EE. В приложении NewsApp веб-уровень представлен веб-модулем и содержит сервлеты, через которые осуществляется доступ к бизнес-логике в модуле EJB.
• Бизнес-уровень. Приложения бизнес-уровня также выполняются на серверах Java EE и содержат бизнес-логику приложения. В приложении NewsApp бизнес-уровень представлен модулем EJB. Модуль EJB содержит код для обработки запросов от клиентов веб-уровня и для управления транзакциями и способами сохранения объектов в базе данных.
• EIS-уровень. EIS-уровень - это надежный уровень хранения приложения. В приложении NewsApp этот уровень представлен базой данных для сохранения сообщений.

При сборке приложения J2EE в среде IDE модуль EJB и модуль веб-приложения упаковываются в архивный файл EAR, который затем развертывается на сервере. Затем доступ к приложению обычно получается из клиентского уровня. Уровень клиента является средой, в которой клиент запускается и часто является веб-браузером в локальной системе пользователя.

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

Подробные сведения о структуре приложений J2EE Java EE см. в главе Распределенные многоуровневые приложения в .

Создание проекта приложения J2EE

Цель этого упражнения состоит в создании проекта приложения J2EE NewsApp. Для создания приложения J2EE, содержащего EJB-модуль и веб-модуль, используется мастер создания проекта.

1. Выберите "Файл" > "Создать проект" (Ctrl-Shift-N; ⌘-Shift-N в Mac) в главном меню.
2. В категории "Java EE" выберите приложение J2EE и нажмите "Далее".
3. Введите имя проекта NewsApp и укажите местоположение проекта.
4. Снимите флажок "Использовать отдельную папку", если он установлен.
   (В рамках этого руководства копирование библиотек проекта в отдельную папку нецелесообразно, поскольку совместное использование библиотек с другими пользователями или проектами не требуется.)
   Нажмите кнопку "Далее".
5. В качестве сервера выберите сервер GlassFish, а в качестве версии Java EE укажите Java EE 6 или Java EE 7.
6. Выберите пункты "Создать модуль EJB" и "Создать модуль веб-приложения". Нажмите кнопку "Завершить".

После нажатия кнопки "Готово" среда IDE создает три проекта: NewsApp, NewsApp-ejb и NewsApp-war При разворачивании узла NewsApp в окне "Проекты" можно увидеть, что проект приложения J2EE не содержит исходные файлы. Все исходные файлы содержатся в двух модулях, созданных мастером и выведенных в узле "Модули Java EE".

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

Написание кода модуля EJB

В этом упражнении будет создан класс сущностей, управляемый сообщениями компонент и фасад сеанса в модуле EJB. Также будет создана единица сохранения состояния для обеспечения контейнера информацией об источнике данных и о способах управления сущностями, а также ресурсы службы передачи сообщений Java (Java Message Service, JMS), используемые управляемым сообщениями компонентом.

Создание класса сущности

В этом упражнении будет создан класс сущностей NewsEntity . Класс сущностей - это простой класс Java, как правило, соответствующий таблице в базе данных. При создании класса сущностей в среде IDE для определения класса как класса сущностей добавляется аннотация @Entity . После создания класса в нем создаются поля для представления требуемых данных в таблице.

Каждый класс сущностей должен иметь первичный ключ. При создании класса сущностей в среде IDE добавляется аннотация @Id для объявления, какое поле необходимо использовать в качестве первичного ключа. Также в среде IDE добавляется аннотация @GeneratedValue и указывается стратегия создания ключей для первичного идентификатора.

Для создания класса NewsEntity выполните следующие действия.

При нажатии кнопки "Завершить" в среде IDE будет создан файл persistence.xml и класс сущностей NewsEntity.java . NewsEntity.java будет открыт средой IDE в редакторе исходного кода.

В редакторе исходного кода выполните следующие действия.

NewsEntity.java можно закрыть.

Для получения подробных сведений о классах сущностей см. главу Введение в интерфейс API сохранения состояния Java в Руководство по Java EE 6. Часть I .

Создание управляемого сообщениями компонента

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

Для создания управляемого сообщениями компонента выполните следующие действия:

1. Щелкните правой кнопкой мыши модуль EJB в окне "Проекты" и выберите "Создать > Прочее" для открытия мастера создания файла.
2. В категории "Enterprise JavaBeans" выберите тип файла "Компонент, определяемый сообщениями". Нажмите кнопку "Далее".
3. В поле "Имя EJB" введите NewMessage .
4. В раскрывающемся списке "Пакет" выберите ejb .
5. Для открытия диалогового окна "Добавление адресата сообщения" нажмите кнопку "Добавить" рядом с полем "Адресат проекта".
6. В диалоговом окне "Добавление адресата сообщения" введите jms/NewMessage и выберите "Очередь" для типа адресата. Нажмите кнопку "ОК".
7. Подтвердите, что адресат проекта выбран правильно. Нажмите кнопку "Завершить".

При нажатии кнопки "Завершить" в редакторе исходного кода откроется класс компонента NewMessage.java . При этом в среде IDE добавляется аннотация @MessageDriven и свойства настройки для класса.

@MessageDriven(mappedName = "jms/NewMessage", activationConfig = { @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue") }) public class NewMessage implements MessageListener {

Аннотация @MessageDriven указывает на то, что данный компонент является управляемым сообщениями, а также определяет ресурс JMS, используемый компонентом. При создании класса в среде IDE отображаемое имя ресурса (jms/NewMessage) определяется на основе имени класса (NewMessage.java). Ресурс JMS привязан к имени JNDI адресата, от которого в компонент поступают сообщения. Мастер создания управляемых сообщениями компонентов также добавляет в файл glassfish-resources.xml информацию о ресурсах JMS. Для указания ресурсов JMS не требуется настраивать дескрипторы развертывания. Если в среде IDE для развертывания приложения на сервере GlassFish выбрать операцию "Выполнить", то ресурсы JMS создаются на сервере при развертывании.

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

1. Введите в класс ресурс MessageDrivenContext посредством добавления к классу следующего аннотированного поля (выделено полужирным шрифтом): public class NewMessage implements MessageListener { @Resource private MessageDrivenContext mdc;
2. Добавьте диспетчер сущностей в класс, щелкнув правой кнопкой мыши в коде и выбрав "Вставить код" (Alt-Insert, Ctrl-I в Mac) и выбрав "Использовать диспетчер сущностей" из всплывающего меню. В среде IDE к исходному коду добавляется следующая аннотация @PersistenceContext . @PersistenceContext(unitName = "NewsApp-ejbPU") private EntityManager em; Кроме того, в среде IDE создается следующий метод persist . public void persist(Object object) { em.persist(object); }
3. Для изменения имени на save измените метод persist . В результате метод должен выглядеть следующим образом: public void save (Object object) { em.persist(object); }
4. Измените метод onMessage путем добавления следующих строк кода (выделено полужирным шрифтом) в тело метода. public void onMessage(Message message) { ObjectMessage msg = null; try { if (message instanceof ObjectMessage) { msg = (ObjectMessage) message; NewsEntity e = (NewsEntity) msg.getObject(); save(e); } } catch (JMSException e) { e.printStackTrace(); mdc.setRollbackOnly(); } catch (Throwable te) { te.printStackTrace(); } }
5. Щелкните правой кнопкой мыши в редакторе и выберите "Исправить выражения импорта" (Alt-Shift-I; ⌘-Shift-I в Mac) для создания необходимых операторов импорта. Сохраните изменения.

Примечание. При создании операторов импорта необходимо убедиться в импорте библиотек javax.jms и javax.annotation.Resource .

Подробные сведения об управляемых сообщениями компонентах приведены в главе Что такое управляемый сообщениями компонент? в руководстве по Java EE 6. Часть I .

Создание фасада сеанса

В этом упражнении будет создан фасад сеанса для класса сущностей NewsEntity. В спецификации EJB 3.0 упрощено создание сеансных компонентов за счет сокращения объема работ по написанию кода и добавления возможности использования аннотаций для объявления класса как сеансного компонента. Кроме того, в спецификации EJB 3.1 упрощены требования к сеансным компонентам, поскольку выбор бизнес-интерфейсов не является обязательным. Локальные клиенты получают доступ к сеансным компонентам посредством представления с локальным интерфейсом или без интерфейса. В рамках этого руководства будет создан интерфейс для такого компонента. Сервлеты в веб-приложении получают доступ к компоненту через представление без интерфейса.

Для создания фасада сеанса выполните следующие действия:

1. Щелкните модуль EJB правой кнопкой мыши и выберите команду "Создать" > "Другие".
2. Из категории "Сохранение состояния" выберите "Сеансные компоненты для классов сущностей". Нажмите кнопку "Далее".
3. Из списка доступных классов сущностей выберите ejb.NewsEntity и нажмите кнопку "Добавить", чтобы переместить класс на панель "Выбранные классы сущностей". Нажмите кнопку "Далее".
4. Убедитесь в том, что для параметра "Пакет" установлено значение ejb . Нажмите кнопку "Завершить".

При нажатии кнопки "Готово" среда IDE создает класс фасада сеанса NewsEntityFacade.java и AbstractFacade.java и открывает файлы в редакторе. Как видите из созданного кода, аннотация @Stateless используется для объявления NewsEntityFacade.java в качестве простого сеансного компонента без сохранения состояния. Также в среде IDE добавляется аннотация PersistenceContext для внедрения ресурса непосредственно в элемент сеансного компонента. Класс NewsEntityFacade.java расширяет класс AbstractFacade.java , который содержит бизнес-логику и управляет транзакцией.

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

Для получения подробных сведений о сеансных компонентах см. главу Что такое сеансный компонент? в руководстве по Java EE 6, часть I .

Написание кода веб-модуля

В примере в этом разделе будет создано два сервлета в веб-модуле. Сервлет ListNews извлекает сообщения из базы данных через фасад сущностей в модуле EJB. Сервлет PostMessage используется для отправки сообщений JMS.

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

Создание единичного сеансного компонента

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

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

Для создания единичного сеансного компонента выполните следующие действия.

1. Для открытия мастера создания файла щелкните веб-модуль правой кнопкой мыши и выберите "Создать" > "Другие".
2. Выберите "Сеансный компонент" в категории Enterprise JavaBeans. Нажмите кнопку "Далее".
3. В поле "Имя EJB" введите SessionManagerBean .
4. ejb .
5. Выберите "Единичный". Нажмите кнопку "Завершить".

При нажатии кнопки "Завершить" в среде IDE будет создан класс единичного сеансного компонента, который откроется в редакторе. При этом в среде IDE добавляется аннотация @Singleton к классу для объявления единичного сеансного компонента. В мастере также создается аннотация @LocalBean для класса.

@Singleton @LocalBean public class SessionManagerBean { }

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

@Singleton @LocalBean @WebListener public class SessionManagerBean implements HttpSessionListener { private static int counter = 0; public void sessionCreated(HttpSessionEvent se) { counter++; } public void sessionDestroyed(HttpSessionEvent se) { counter--; } public int getActiveSessionsCount() { return counter; } }

Подробные сведения об единичных сеансных компонентах см. в главе Что такое сеансный компонент? в руководстве по Java EE 6, часть I .

Создание сервлета ListNews

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

1. Щелкните проект веб-модуля правой кнопкой мыши и выберите "Создать" > "Сервлет".
2. В поле "Имя класса" введите ListNews .
3. В качестве имени параметра "Пакет" введите web . Нажмите кнопку "Завершить".

При нажатии кнопки "Готово" класс ListNews.java будет открыт в редакторе исходного кода. В редакторе исходного кода выполните следующие шаги.

1. Щелкните правой кнопкой мыши в редакторе исходного кода, выберите пункт "Вставить код" (Alt-Insert; Ctrl-I на Mac) и выберите пункт "Вызов компонента EJB".
2. В диалоговом окне "Вызов компонента EJB" разверните узел NewsApp-ejb и выберите NewsEntityFacade. Нажмите кнопку "ОК".

   В среде IDE добавляется аннотация @EJB для ввода компонента EJB.

3. Используйте диалоговое окно "Вызов компонента EJB" еще раз для ввода компонента SessionManagerBean в узел NewsApp-war.

   В коде можно увидеть следующие аннотации для ввода двух компонентов EJB.

   @WebServlet(name = "ListNews", urlPatterns = {"/ListNews"}) public class ListNews extends HttpServlet { @EJB private SessionManagerBean sessionManagerBean; @EJB private NewsEntityFacade newsEntityFacade;

   Кроме того, можно увидеть, что аннотация @WebServlet используется для объявления класса сервлета и для указания имени сервлета. Аннотация @WebServlet является частью интерфейса API сервлета 3.0, представленного в спецификации Java EE 6. Сервлеты можно определить с помощью аннотации вместо дескриптора развертывания в web.xml . Приложение NewsApp не содержит web.xml .

4. В методе processRequest добавьте следующий код (выделено полужирным шрифтом) для возврата к текущему сеансу или создания нового. protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.getSession(true); response.setContentType("text/html;charset=UTF-8");
5. Добавьте следующий код (выделен жирным шрифтом) к методу processRequest для вывода сообщений и добавления ссылки на сервлет PostMessage. (При необходимости удалите знак комментария для кода в методе.) out.println("

   Servlet ListNews at " + request.getContextPath () + "

   "); List news = newsEntityFacade.findAll(); for (Iterator it = news.iterator(); it.hasNext();) { NewsEntity elem = (NewsEntity) it.next(); out.println(" "+elem.getTitle()+"
   "); out.println(elem.getBody()+"
   "); } out.println("Add new message"); out.println("");
6. Добавьте следующий код (выделено полужирным шрифтом) для получения и отображения количества пользователей/открытых сеансов. out.println("Add new message"); out.println("
   
   "); out.println(sessionManagerBean.getActiveSessionsCount() + " user(s) reading the news."); out.println("");
7. Нажмите сочетание клавиш Ctrl+Shift+I для создания обязательных операторов импорта для класса. При создании операторов импорта может потребоваться импортировать библиотеки java.util .
8. Сохраните измененный файл.

Создание сервлета PostMessage

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

1. Щелкните проект веб-модуля правой кнопкой мыши и выберите "Создать" > "Сервлет".
2. В поле "Имя класса" введите PostMessage .
3. Для имени параметра "Пакет" введите web и нажмите "Завершить".

При нажатии кнопки "Готово" в редакторе исходного кода будет открыт класс PostMessage.java . В редакторе исходного кода выполните следующие шаги.

Выполнение проекта

Теперь проект можно выполнить. При выполнении проекта страница с сервлетом ListNews должна открыться в браузере. Для этого в диалоговом окне "Свойства" для приложения J2EE вводится URL-адрес. Это относительный URL-адрес, связанный с контекстным путем к приложению. После ввода относительного URL-адреса приложение можно собрать, развернуть и запустить в окне "Проекты".

Для указания относительного URL-адреса и запуска приложения необходимо выполнить следующие действия:

1. В окне "Проекты" щелкните правой кнопкой мыши узел приложения корпоративного уровня NewsApp и выберите во всплывающем меню "Свойства".
2. В панели "Категории" выберите "Выполнить".
3. В текстовое поле "Относительный URL-адрес" введите /ListNews .
4. Нажмите кнопку "ОК".
5. В окне "Проекты" щелкните правой кнопкой мыши узел приложения корпоративного уровня NewsApp и выберите "Выполнить".

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

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

Загрузка проекта решения

Решение для данного учебного курса в виде проекта можно загрузить несколькими способами.

• Загрузите .
• Выполните проверку исходных файлов проекта на выходе из примеров NetBeans, выполнив перечисленные ниже действия.
  1. Выберите в главном меню "Группа > Subversion > Проверить".
  2. В диалоговом окне "Проверка" введите следующий URL-адрес репозитория:
     https://svn.сайт/svn/samples~samples-source-code
     Нажмите кнопку "Далее".
  3. Нажмите кнопку Browse ("Обзор") для открытия диалогового окна Browse Repository Folders ("Обзор папок репозитория").
  4. Разверните корневой узел и выберите samples/javaee/NewsAppEE6 . Нажмите кнопку "ОК".
  5. Укажите локальную папку для исходных файлов (папка должна быть пустой).
  6. Нажмите кнопку "Завершить".

     После нажатия кнопки "Готово" среда IDE инициализирует локальную папку в качестве репозитория Subversion и выполняет проверку исходных файлов проекта на выходе.

  7. Щелкните команду "Открыть проект" в диалоговом окне, которое появится после завершения проверки.

  Примечания.

  • Для получения исходных файлов на редактирование требуется клиент Subversion. For more about installing Subversion, see the section on Setting up Subversion in the Guide to Subversion in IDE NetBeans .

Устранение проблем

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

Проблема с ресурсами JMS

При создании ресурсов JMS с помощью мастера в окне вывода может появиться следующее сообщение об ошибке сервера:

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

Для вызова консоли администратора необходимо выполнить следующие действия.

1. Убедитесь в том, что сервер приложений запущен. Для этого разверните узел "Серверы" в окне "Службы" среды IDE. Работающий сервер обозначается зеленой стрелкой рядом с узлом сервера приложений.
2. Щелкните правой кнопкой мыши узел сервера приложений и выберите "Просмотр консоли администратора" для открытия в браузере окна входа в систему.
3. Выполните вход в систему сервера. По умолчанию используется имя пользователя admin и пароль adminadmin .
4. Разверните узлы "Ресурсы" и "Ресурсы JMS" в левом поле консоли администратора в браузере.
5. Щелкните ссылки "Фабрики подключений" и "Ресурсы адресатов" в левом поле и проверьте, зарегистрированы ли ресурсы на сервере; при необходимости внесите требуемые изменения. Если ресурсы не существуют, их можно создать при помощи консоли администратора.

Необходимо убедиться в том, что ресурс фабрики подключений JMS в сервлете PostMessage связан с правильным именем JNDI ресурса фабрики подключений JMS, зарегистрированного на сервере приложений Sun Java System Application Server.

.

(Jonathan Lurie и R. Jason Belanger)

Server-Side Java

Имеет ли одна из платформ, поддерживающих Web-службы, преимущество над другой?

Обзор

Java 2 Platform, Enterprise Edition (J2EE) и.Net являются конкурирующими технологиями, каждая из которых позволяет создавать Web-службы (Web services). В настоящей статье Jonathan Lurie и R. Jason Belanger описывают технологию Web-служб и приводят сравнение основных компонент платформ J2EE и.Net. Вооружившись этой информацией, Вы сможете понять, какую стратегическую помощь могли бы оказать Web-службы Вашей компании. (2600 слов).

Несмотря на то, что в настоящее время ведутся жаркие споры вокруг преимущества одной из платформ (J2EE и.Net), многие полагают, что это не более, чем маркетинговая война. Неважно, так это или нет, но очевидно, что результат этих споров существенно повлияет на эволюцию программного обеспечения в будущем. Руководители Sun Microsystems и Microsoft вложили значительные средства в раскрутку своих платформ и хотят получить соответствующую отдачу. Если Microsoft проиграет эту схватку, у нас появится возможность свободного выбора операционной системы на свой вкус. Победа Sun позволит программному обеспечению выполняться на любых операционных системах и приведет к тому, что доминирование Microsoft в области операционных систем понемногу исчезнет, в то время как на рынке появятся другие операционные системы, на которых сможет выполняться то же самое программное обеспечение. С другой стороны, если победит Microsoft, она еще более укрепит свои технологии в качестве фактических стандартов на ближайшее обозримое будущее.

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

Что было до Web-cлужб

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

Например, предположим, что компания “Know-Can-Do” на своем Web-сайте предлагала информацию о курсе акций. Для этого ей необходимо было получить первичные данные от их поставщика, скажем, компании “Stock-Quote-Provider”. Компания “Know-Can-Do” в типичном случае получала данные от “Stock-Quote-Provider” с помощью некой специально разработанной технологии (например, специально установленного программного обеспечения), а также дорогостоящих аппаратных средств (например, выделенной линии). Более того, “Know-Can-Do” приходилось создавать приложения для преобразования первичных данных в HTML. Этот процесс проиллюстрирован на рисунке 1. Обратите внимание на светло-голубую линию, которая обозначает взаимодействие между “Know-Can-Do” и “Stock-Quote-Provider”; используемая для этого взаимодействия технология весьма дорога, так как специально создана для данной системы.

Рисунок 1. Движение данных и управление ими с помощью специально разработанной технологии

Поскольку компания “Know-Can-Do” хотела бы конкурировать с такими доминирующими Web-порталами как AOL, MSN (Microsoft Network), Yahoo! и Excite, необходимость предоставлять посетителям больше информации стремительно увеличивалась. Чтобы оставаться конкурентоспособной, “Know-Can-Do” была вынуждена добавить услуги по предоставлению информации о погоде и новостей. Оказалось, что использовать для этого модель, представленную на рисунке 1 весьма неэффективно, так как получение данных от различных поставщиков происходит различными, несовместимыми способами и этот процесс становится неуправляемым как с точки зрения технологии, так и с точки зрения стоимости. Необходимо было добиться меньших затрат для получения первичных данных, и кроме того, “Know-Can-Do” нуждалась в более простой технологии для преобразования данных к стандартному виду (например, HTML, WML (Wireless Markup Language), Voice XML).

И вот теперь давайте рассмотрим, что нам предлагает стратегия Web-служб.

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

Web-службы появились как решение, позволяющее стандартным способом получать необходимые данные, без какого-либо специально для этого созданного программного или аппаратного обеспечения. Краеугольным камнем технологии Web-служб является их способность передавать данные от поставщика к потребителю, используя всего лишь повсеместно распространенный HTTP-протокол; при этом в качестве формата данных используется XML. Использование XML в качестве формата данных существенно облегчает преобразование первичных данных в формат, пригодный для просмотра пользователем. Такое простое преобразование, не требующее сложных программ для разбора данных, обеспечивается языком XSLT (Extensible Stylesheet Language Transformations). Вышесказанное иллюстрируется рисунком 2.

Рисунок 2. Высокоуровневая схема XSL-преобразования

Официальный документ фирмы Sun определяет Web-службу следующим образом:

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

В документе "Defining the Basic Elements of .Net" Microsoft определяет Web-службу так:

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

Из этих определений следует один приятный вывод: Sun и Microsoft неявно соглашаются друг с другом по поводу определения Web-службы. На чисто интуитивном уровне Web-служба – это некий сервис, доступ к которому осуществляется через интернет. Более детально можно сказать, что Web-служба вызывается с помощью протокола HTTP и возвращает данные в формате XML.

Концептуальный поворот

Появление Web-служб влечет серьезные изменения в парадигме разработки программного обеспечения. Пока некоторые компании все еще оспаривают право Web-служб на существование, другие компании, такие как “Concord EFS”, зарабатывают миллионы долларов, с помощью Web-службы, обрабатывающей кредитные карточки. Web-службы подталкивают нас к разбиению больших приложений на небольшие независимые части, которые могли бы существовать в качестве Web-служб. Такая модель, возможно, заменит существующую парадигму в соответствии с которой разбиение происходит на динамические библиотеки (DLL, Dynamic Link Library) и COM (Component Object Model) объекты.

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

Эти отличия между Web-службами и их предшественниками (DLL) определяются следующими тенденциями в программной индустрии, проявившимися до появления Web-служб:

1. Принятие HTTP как стандартного протокола, с помощью которого осуществляется доступ в интернет;
2. Принятие XML де-факто как стандарта для передачи данных.

Эти две тенденции обеспечили базис, на котором были построены Web-службы. Рисунок 3 иллюстрирует как компания “Know-Can-Do” могла бы использовать Web-службы. Заметьте, что теперь ей больше не требуются ни выделенные линии, ни специально созданный формат обмена данными.

Рисунок 3. Прежний пример, спроектированный с помощью технологии Web-служб

Java 2 Platform, Enterprise Edition

Часто бывает, что даже те, кто понимают технологию Web-служб, не понимают сущность платформы J2EE. Многие люди (исключая разработчиков) полагают, что J2EE – это некий продукт, который вы покупаете у Sun так же, как вы покупаете.Net у Microsoft. На самом деле, напротив, J2EE – это всего лишь набор спецификаций, каждая из которых устанавливает, как должны работать различные функции из состава J2EE. Например, спецификация Java Transaction Service (JTS) определяет, как создать сервис, поддерживающий распределенные транзакции. Sun предлагает свои образцы реализаций этих спецификаций, которые можно использовать для проверки совместимости со спецификациями.

Возникает вопрос: если вы не покупаете J2EE у Sun, то как же тогда Sun зарабатывает деньги? Sun зарабатывает их, выдавая лицензии независимым поставщикам программного обеспечения (independent software vendors, ISV), которые реализуют данные спецификации и продают в виде готовых продуктов на рынке. Таким образом, если вам надо купить реализацию J2EE вы можете это сделать у одного из поставщиков программного обеспечения, который разработал J2EE-совместимую реализацию. Для того, чтобы найти список таких реализаций, можно сходить на http://java.sun.com/j2ee/compatibility.html

Для того чтобы ознакомиться со списком компаний, получивших лицензию, можно сходить на http://java.sun.com/j2ee/licensees.html. Вы увидите, что Microsoft в этом списке отсутствует - это следствие известной тяжбы, которая закончилась выплатой 20 миллионов долларов.

Хотя технология сервлетов в J2EE и не проектировалась с учетом будущего использования Web-служб, она поддерживает эту технологию. Сервлет выполняет все обработку вызова, включая обращение к Enterprise JavaBeans (EJBs), которые возвращают результирующие данные сервлету. Далее сервлет формирует ответ response), который он заворачивает в XML для доставки клиенту. Новый продукт Sun - Java Web Services Developer Pack (WSDP) содержит все необходимое для создания Java Web-служб. Он содержит в себе Java XML Pack, который позволяет разработчику абстрагироваться от низкоуровневого разбора XML, а также JavaServer Pages (JSP) Standard Tag Library 1.0, Ant 1.4.1, Java WSDP Registry Server 1.0 и Tomcat Java Servlet and JSP container 4.1.

Microsoft"s .Net

Прежде чем исследовать платформу Microsoft"s .Net, мы должны понять, какие события стали поводом для ее появления. К концу 1995 года Microsoft стала перемещать свое основное внимание на интернет; дело в том, что компания слишком поздно вступила в игру в этой области, увлекшись Windows 95. В это время Netscape быстро завоевывала этот сегмент рынка, пока Microsoft силилась раскрутить собственный Web-броузер. Microsoft задействовала все свои колоссальные маркетинговые возможности (не будем вдаваться в споры о проявлении монополизма) и разрушила лидерство Netscape (которая тогда имела более 16 миллионов пользователей).

В это же время Microsoft вступила в схватку по раскрутке таких своих технологий, как Active Server Pages (ASP). Эта технология была достаточно эффективной, хотя и не достаточно зрелой; в конце концов, данная технология предоставляет среду для написания скриптов, что является шагом назад с точки зрения объектно-ориентированного подхода. Можно представить себе, с какой скоростью работали тогда команды разработчиков Microsoft, чтобы как можно скорее распространить свое программное обеспечение, напоминая о временах, когда Силиконовая Долина только родилась. В то время компания выпустила много таких технологий, и многие ранние технологии бесславно исчезли. Можно, например, вспомнить Active Documents – технологию для Visual Basic, которая позволяла разработчикам создавать Web-приложения без всякого дополнительного программирования. Эта технология умерла тихой смертью. Мы обязательно должны помнить о такого рода технологиях в процессе оценки.Net, чтобы понять, не является ли и.Net подобной фикцией.

Основная маркетинговая стратегия Microsoft – продвигать свои технологии всеми возможными средствами как можно дальше вширь и вглубь. Microsoft выходит на рынок с технологиями, которые лишь обеспечивают основной функционал. Некоторые из технологий проваливаются, а некоторые остаются и улучшаются до тех пор, пока не становятся стандартами отрасли. Поэтому главный вопрос здесь такой: .Net – это реальная технология, или Microsoft всего лишь блефует?

Справедливости ради, необходимо поблагодарить Microsoft за работу по доведению важности Web-служб до разработчиков. Компания провела такую огромную работу и затратила такие большие деньги на маркетинговые цели, что многие серьезно полагают, что именно Microsoft разработала технологии, позволяющие использовать Web-службы, хотя на самом деле, конечно, эта роль принадлежит Sun и ее технологии сервлетов. Конечно, дальше можно спорить о том, не была ли технология сервлетов ответом на технологию Microsoft ASP, и кто был первый, а кто – второй и кто был еще раньше, чем первый, и так до бесконечности. (Larry Seltzer возвращается к этому вопросу в публикации "Shadow Initiatives: .Net and Java" (ZDNet, January 2002)).

Теперь, когда разработчики осознают важность Web-служб, можно ожидать, что большее число компаний выделят Web-службы в своих приложениях и смогут продавать их другим компаниям. И здесь Microsoft захватила лидерство, одной из первых предоставив такие Web-службы с потенциально большой пользовательской базой. Например, разработчики могут использовать Web-службы HailStorm – строительные блоки для технологии.Net, выполняющие такие задачи, как обмен сообщениями, временная синхронизация и нотификация. Пожалуй, один из самых известных среди сервисов HailStorm - Microsoft"s Passport, который обеспечивает идентификацию и аутентификацию пользователей. Согласно статистике Microsoft, в настоящее время он выполняет более 1.5 миллиарда операций аутентификации в месяц. Наиболее активно используемой Web-службой на сегодняшней дней является Hotmail, пользователи, которого могут наблюдать логотип Microsoft"s Passport на начальной странице.

Чтобы извлечь выгоду из процесса повсеместного внедрения Web-служб, Microsoft выступила с инициативой использования платформы.Net. С точки зрения архитектуры, .Net отличается от породившей ее технологии DNA (Distributed Internet Architecture), предлагая новые решения для технологии ASP, рассчитанные на использование Web-служб и реализованные в технологии ASP. Net. Эта технология предлагает среду с поддержкой полнофункционального языка программирования, а не только скриптов, как это было прежде. Возможно, наиболее существенным моментом внедрения.Net является то, что Visual Basic наконец-то стал объектно-ориентированным. Еще одна замечательная черта, которую не предлагает Sun, это способность ASP.Net создавать страницы в различных HTML-форматах, что позволяет разработчику не заботиться об поддержке различных версий HTML. Та же задача может быть решена и при помощи сервлетов, но для этого потребуется дополнительно кодировать вручную.

Новизна.Net в том, что.Net–приложения не компилируются в зависимый от платформы (native) код, например, специфический для архитектуры Intel. Вместо этого компиляция сейчас представляет собой процесс из двух шагов. Код, написанный разработчиком, компилируется в Промежуточный Язык Microsoft (Microsoft Intermediate Language (MSIL)). Затем с помощью среды Common Language Runtime (CLR) он компилируется в зависимый от платформы исполняемый код. Не правда ли, это что-то очень знакомое? Похоже, Microsoft умеет извлекать уроки и замечать, что происходит вокруг. .Net включает в себя С# - язык, весьма похожий на Java. Microsoft также предлагает программу, которая конвертирует Java-код в код на С#.

Говорят, что в настоящее время ведутся работы по созданию CLR для Linux. И если эти разговоры небеспочвенны, то появляется возможность работы.Net–приложения на Linux. И тогда основное преимущество Java, заключающееся в платформенной независимости сходит на нет.

.Net против J2EE

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

- Многоплатформенность Для разработчика важно то, что и.Net, и J2EE предоставляют средства для создания Web-служб. До сих пор J2EE могла гордиться своей поддержкой многоплатформенности, но, если верить Microsoft, более это не является прерогативой J2EE. Microsoft позиционирует.Net как платформу с двухступенчатой компиляцией, что позволяет создавать среду выполнения для любой платформы, подобно Java. Eric Rutter, старший вице-президент Microsoft запустил информацию о переносе.Net на FreeBSD. FreeBSD - это операционная система, производная от BSD (Berkeley Software Distribution) Unix. Он объявил, что Microsoft в самом деле занимается созданием среды выполнения для FreeBSD. Создание такой среды нарушило бы гегемонию Java в области платформенной независимости, однако не стоит пока полагаться на эту информацию. Создание CLR для наиболее популярных операционных систем может занять много лет. Более того, однажды, Microsoft уже делала подобные заявления в отношении переноса DCOM (Distributed Component Object Model) на другие платформы. Однако такой перенос так и не был осуществлен.

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

- Многоязыковая поддержка Единственной языковой основой J2EE является Java, что сильно отличается от.Net, где поддерживается более двух дюжин языков, включая Fortran, COBOL, C++ и Visual Basic. Можно, конечно, поспорить насчет того, что единственный язык является более элегантным решением, однако надо признать, что.Net предлагает более простое решение для организаций, которые хотят пользоваться знаниями, которые уже имеются у их разработчиков. Ведь для тех разработчиков, которые используют языки, отличные от Java, .Net дает возможность создавать Web-службы на привычном им языке с минимальными затратами на переобучение.

Стратегия Microsoft состоит в том, чтобы рассматривать Java всего лишь как один из языков программирования. Sun в ответ на это заявляет: Java – это не язык программирования, а платформа.

В продолжение темы смотрите послесловие к данное статье - "Microsoft и Sun сравнивают.Net и J2EE”, где оба производителя обсуждают сильные и слабые стороны двух платформ.

Тестируем обе платформы

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

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

Компания Sun могла бы припомнить высказывание своего пионера Джеймса Гослинга, который на последней Конференции InfoWorld Next-Generation Web Services произнес замечательные дальновидные слова:

Web-службы создают однородное представление для неоднородной среды.

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

В завершение мы предлагаем вам попробовать разработать Web-службы и с помощью.Net, и с помощью J2EE. Тогда вы быстро поймете, какая из платформ лучше подходит для вас. Выбирая поставщика, многие используют такое эмпирическое правило: если в настоящий момент вы используете платформу Microsoft, то выбирайте.Net, в противном случае – J2EE.

Об авторах

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

R. Jason Belanger более пяти лет занимается разработкой Web-приложений. Он разработал полдюжины полномасштабных коммерческих Web-сайтов. В настоящий момент он руководит компанией NoFeeListing.com.

Ресурсы

• Определение Web-службы фирмы Sun можно найти в официальном документе, который по ее поручению написал James Kao из компании The Middleware Company: "Developer"s Guide to Building XML-Based Web Services with the Java 2 Platform, Enterprise Edition (J2EE)" (TheServerSide.com, June 2001):
• Определение Web-службы фирмы Microsoft можно найти в документе "Defining the Basic Elements of .Net" (Microsoft, 2002):
  http://www.microsoft.com/net/whatis.asp
• Лицензии J2EE:
  http://java.sun.com/j2ee/licensees.html
• J2EE-совместимые реализации:
  http://java.sun.com/j2ee/compatibility.html
• "Shadow Initiatives: .Net and Java," Larry Seltzer (ZDNet, January 2002):
  http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2842294,00.html
• Недавно Microsoft опубликовала технический обзор, в котором приложение Sun «Pet Store» было переработано с использованием.Net. Хотя это и любопытный документ, необходимо тщательно взвешивать все, что публикует сам поставщик предлагаемой технологии:
  http://www.gotdotnet.com/team/compare/petshop.aspx
• The Java Transaction Service:
  http://java.sun.com/products/jts/index.html
• "C#: A Language Alternative or Just J--?" Mark Johnson (JavaWorld):
  • Part 1. What the new language for .Net and post-Java Microsoft means to you (November 2000)
  • Part 2. An in-depth look into the semantic differences and design choices between C# and Java (December 2000)
• Выберите наилучшую стратегию использования Web-служб с помощью статьи "A Birds-Eye View of Web Services," Frank Sommers (JavaWorld, January 2002):
  http://www.javaworld.com/javaworld/jw-01-2002/jw-0125-webservices.html
• "Sun Adds Web Services to J2EE," Matt Berger, IDG News Service (JavaWorld, December 2001):
  http://www.javaworld.com/javaworld/jw-12-2001/jw-1221-iw-jxml.html?
• Зайдите в раздел Java 2 Platform, Enterprise Edition тематического каталога JavaWorld:
  http://www.javaworld.com/channel_content/jw-j2ee-index.shtml
• Зайдите в раздел Java and Web Services тематического каталога JavaWorld:
  http://www.javaworld.com/channel_content/jw-webserv-index.shtml
• Зайдите в раздел Servlets тематического каталога JavaWorld:
  http://www.javaworld.com/channel_content/jw-servlets-index.shtml
• Обсудите Web-службы на форуме Enterprise Java:
  http://forums.devworld.com/webx?50@@.ee6b80a
• Подпишитесь на еженедельную бесплатную рассылку журнала JavaWorld Enterprise Java:
  http://www.javaworld.com/jw-subscribe
• Огромное количество статей по информационным технологиям вы найдете на IDG.net

Microsoft и Sun сравнивают.Net и J2EE

В январе 2002 года мы задали несколько вопросов Microsoft и Sun. Вот, что они нам рассказали:

Jonathan Lurie: В чем сходство.Net и J2EE?

John Montgomery, компания Microsoft , руководитель группы, занимающейся платформой.Net: Сходство спецификаций J2EE и платформы Microsoft .Net в том, что они позволяют упростить и ускорить процесс разработки бизнес-приложений. Microsoft .Net – это платформа, включающая серверы, клиенты и сервисы. Она содержит набор приложений, таких, как Visual Studio .Net, Tablet PC, и.Net My Services. Microsoft .Net была спроектирована таким образом, чтобы удовлетворять текущие и будущие требования заказчиков к созданию, внедрению и управлению приложениями. Фундаментальным принципом Microsoft .Net является изменение процесса разработки и внедрения программного обеспечения – в частности, переход от разработки собственных программ к покупке, настройке и интеграции готового программного обеспечения. Microsoft .Net была разработана для интеграции приложений с помощью Web-служб, используя протоколы и форматы, такие, как SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) и UDDI (Universal Description, Discovery, and Integration).

Отличие J2EE в том, что это всего лишь набор спецификаций. Они определят лишь небольшую часть полноценной платформы, сфокусированную на разработке приложений на стороне сервера. Эти спецификации, такие как JSP и EJB являются клонами технологий операционной системы Microsoft Windows 2000.

Например, JSP – это прямой клон технологии Microsoft Active Server Pages, а EJB - это клон COM+ технологий в Windows. J2EE - это в значительной степени набор спецификаций, спроектированных для облегчения разработки серверных приложений на Unix-системах.

David F. Harrah, компания Sun Microsystems, менеджер по маркетингу программного обеспечения, основанного на Java и XML: Главным образом, обе технологии предоставляют платформы для разработки и внедрения программного обеспечения, которые сочетают объектно-ориентированный язык и среду для выполнения приложений. В случае Java, программа на языке Java компилируется в байт-код, который выполняется под управлением Java Runtime Environment (JRE). Код на языках, поддерживаемых.Net, транслируется в Microsoft Intermediate Language, который интерпретируется с помощью среды Common Language Runtime (CLR) в исполняемые инструкции для конкретной платформы.

Новый язык Microsoft C# повторяет Java. J2EE – это реализация Java-технологии, которая дополняет базовые возможности enterprise-компонентами, такими, как EJB и JSP.

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

Lurie: В чем разница между.Net и J2EE?

Montgomery: Прежде всего, J2EE – это набор спецификаций фирмы Sun, выпущенный до пришествия Web-служб – новой технологии, с энтузиазмом встреченной в отрасли программного обеспечения. Microsoft .Net - это набор реализаций, основанный на открытых стандартах, таких как SOAP, WSDL, C#, и CLI (command line interface). Кроме того, J2EE это набор спецификаций, ориентированный на работу серверной части приложений, в то время как Microsoft .Net предлагает полноценную платформу. Наконец, J2EE до сих пор не предлагает стандартного API для работы с XML Web-службами. В отличие от J2EE, с помощью Microsoft .Net, XML Web-службы становятся естественным образом встроенными в платформу. (Примечание редактора: Уже после выхода этой статьи Sun выпустила Java Web Services Developer Pack: http://java.sun.com/webservices/downloads/webservicespack.html.)

Второе и главное крупное отличие состоит в том, что Microsoft .Net спроектирована для поддержки нескольких языков программирования – в настоящее время, Microsoft .Net поддерживает более 20 языков, позволяя создавать.Net приложения на любых языках без затрат на переобучение персонала. Что же касается J2EE, то эта платформа поддерживает единственный язык программирования - Java.

Harrah: Прежде всего, Java - это результат взаимодействия более чем 400 компаний и организаций, а.Net – это продукт одной компании. Технология Java поддерживается и совершенствуется с помощью так называемого процесса Java Community Process (JCP), представляющего из себя взаимодействие группы из более чем 400 компаний, организаций и частных лиц в целях создания платформы для сервисов и приложений, которая может работать на системах любого типа. Java Community Process предполагает создание групп экспертов, состоящих из заинтересованных членов, которые сотрудничают в целях определения новых спецификаций и усовершенствования существующих. Система принятия решений с помощью голосования гарантирует, что Java остается единой и общей платформой для всех без каких-либо предпочтений для какой-то одной компании.

Java приложения могут выполняться на любых операционных системах: системах уровня предприятия, таких, как Unix, Linux, OS/390, Windows 2000, или HP-UX; операционных системах для десктопов, таких как Mac OS, Windows или Linux; а также операционных системах для мобильных устройств, таких как Palm OS или Symbian"s EPOC. .Net была полностью разработана Microsoft и может работать только на операционных системах Microsoft.

Технология Java является открытой и построена на внутриотраслевых стандартах для программного обеспечения. Любой желающий может загрузить и изучать код Java платформы. Microsoft приоткрыла лишь небольшие части технологии.Net, такие как язык C#, но повесила железный занавес на ключевые области своей платформы и не публикует их в открытую. Microsoft лишь избирательно делает небольшие части своего исходного кода доступными для отдельных партнеров.

Net – это новая платформа Microsoft, и на сегодняшний день доступны лишь ее бета-версии. Технология Java активно используется в течение почти 6 лет, что означает, что в различные редакции компонент Java заложен значительный опыт использования платформы. В настоящий момент доступна уже третья версия J2EE в то время как Java Community Process занят разработкой четвертой. (Примечание редактора: Уже после выхода данной статьи Microsoft выпустила Microsoft Visual Studio .Net: http://msdn.microsoft.com/vstudio/.)

Lurie: Какие преимущества имеет J2EE перед.Net?

Montgomery: Главное преимущество J2EE в том, что можно приобрести различные реализации базовых спецификаций у различных поставщиков.

Harrah: Технология Java изначально создавалась в расчете на использование в сетевых приложениях. Она упрощает гетерогенную природу сети и поддерживается на любых операционных системах и микропроцессорных архитектурах, которые только есть в современных сетях. С самого начала в Java была заложена строгая и надежная модель безопасности, поэтому Java уязвима для хакеров и вирусов значительно меньше, чем продукты Microsoft.

Java поддерживает не только Web-службы, но и другие виды служб, такие как беспроводные службы данных (wireless data services) и сервисы, активизируемые по требованию (services on demand). Java поддерживает такие связанные с Web-службами технологии, как XML, SOAP и UDDI и по опросу Evans Data Corp. Developer является платформой номер один для построения Web-служб. Я не слышал, чтобы Microsoft внятно объяснила, каким образом она поддерживает wireless data services в.Net. И это в то время, когда у пользователей имеется по крайней мере 15 миллионов поддерживающих Java телефонов и использующих wireless data services; особенно это актуально для Японии.

Lurie: Какие преимущества имеет.Net перед J2EE?

Montgomery: Главное преимущество Microsoft .Net в том, что это полноценная платформа, а J2EE ориентирована только на серверное программирование. Более того, J2EE - это лишь набор спецификаций и необходимо приобретать дорогостоящие (обычно порядка $15,000 для одной машины) реализации J2EE. В отличие от J2EE, Microsoft .Net – это набор продуктов и служб. В дополнение к этому, Microsoft .Net имеет встроенные в платформу XML Web-службы, а не просто использует их, как дополнительно подключаемый механизм. Это позволяет существенно увеличить производительность как самих приложений, так и труда разработчиков. Microsoft .Net разрабатывался с поддержкой интеграции посредством XML Web-служб с использованием протоколов и форматов таких, как SOAP, WSDL и UDDI.

Как я уже упоминал выше, Microsoft .Net поддерживает различные языки программирования; J2EE поддерживает единственный язык: Java.

Harrah: Я не вижу НИКАКИХ преимуществ.

Reprinted with permission from the March 2002 edition of JavaWorld magazine. Copyright © ITworld.com, Inc., an IDG Communications company. View the original article at:
http://www.javaworld.com/javaworld/jw-03-2002/jw-0308-j2eenet.html

Предлагаю обсудить данную тему на