[an error occurred while processing this directive] IT • archiv :: Print

IT • archiv


[an error occurred while processing this directive]

[an error occurred while processing this directive]

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

[an error occurred while processing this directive](none) [an error occurred while processing this directive](none)[an error occurred while processing this directive] ::
[an error occurred while processing this directive](none)
[an error occurred while processing this directive]([an error occurred while processing this directive] Стивен Гоулд [an error occurred while processing this directive])

[an error occurred while processing this directive](none)

Введение в платформу Java 2, Enterprise Edition, спецификация WebLogic Server от BEA.

J2EE Primer
PDF versionPDF версия
Обзор
В этой статье, Стивен Гоулд представляет 13 основных технологий платформы Java 2 ,Enterprise Edition (J2EE): JDBC, JNDI, EJB, RMI, JSP, Java servlet, XML, JMS, Java IDL, JTS, JTA, JavaMail, и JAF. Чтобы объяснение было ближе к реальной жизни, Гоулд рассказывает о J2EE в контексте одной из главных ее реализаций, WebLogic Server компании BEA Systems. (В оригинальной версии на английском языке 3,200 слов)

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

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

В этой статье, мы рассмотрим 13 основных технологий, на которых основана J2EE: JDBC, JNDI, EJB, RMI, JSP, Java servlet, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF. Мы опишем, где и когда стоит использовать каждую из них, и как они взаимодействуют друг с другом.

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

Распределенные архитектуры и J2EE крупным планом.

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

Двухуровневая архитектура приложения.
Рисунок 1. Двухуровневая архитектура приложения.

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

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

Возможно вы уже начинаете гадать: "Зачем так много слоев?" Так вот, подобный подход нужен для лучшей расширяемости корпоративного приложения. Он позволяет каждому слою сфокусироваться на своей специфической роли. Например, Web сервер работает с Web страницами, сервер приложений с приложениями, сервер баз данных с базами данных.

Поскольку J2EE является надстройкой поверх стандартной редакции, Java 2 Standard Edition (J2SE), она дает возможность использовать все ее преимущества, в том числе переносимость в соответствии с принципом "Написанное однажды — работает везде", доступ к базам данных через JDBC, технологию CORBA для взаимосвязи с существующими корпоративными ресурсами и проверенную модель безопасности. Сама J2EE, построенная на этой основе, добавляет поддержку компонентов Enterprise JavaBean (EJB), Java servlets, JavaServer Pages (JSPs), и технологию XML.

Распределенная архитектура в WebLogic Server.

J2EE предоставляет каркас, стандарт API, для разработки распределенных систем. Реализация этого стандарта оставленна для сторонних компаний. Некоторые компании фокусируют свою деятельность на конкретных компонентах архитектуры J2EE. Например, Tomcat в Apache обеспечивает поддержку для JSP и servlet. BEA Systems вместе со своим продуктом WebLogic Server дает более полную реализацию спецификации J2EE .

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

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

Технологии J2EE

В последующих разделах, мы опишем каждую из технологий составляющих J2EE, и увидим, как WebLogic Server поддерживает их в распределенных приложениях. Наверное, наиболее распространенные из используемых технологий J2EE: JDBC, JNDI, EJB, JSP, и servlet, поэтому на них мы сфокусируем наше внимание.

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

Пример n-уровневой архитектуры приложения.
Рисунок 2. Пример n-уровневой архитектуры приложения.

Java Database Connectivity (JDBC)

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

В JDBC определено четыре кардинально различных типа драйверов, как мы это увидим в дальнейшем.

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

Тип 2:Мост через родные (JDBC-native) драйвера
Мост через JDBC-native драйвера обеспечивает JDBC интерфейс, построенный поверх родного драйвера базы данных без использования ODBC. Этот JDBC драйвер конвертирует стандартные вызовы JDBC в родные вызовы API базы данных. При использовании 2 типа драйверов, платформо-независимость JDBC тоже приносится в жертву и требует инсталляции на клиентской стороне.

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

Тип 4: Драйвер на чистом Java
Тип 4 обеспечивает прямой доступ к базе данных, используя драйвер на чистом Java. В соответствии со своим принципом действия драйвера 4-го типа запускаются на клиентской стороне и обращаются к базе данных напрямую. Запуск в таком режиме является неявным использованием двухуровневой архитектуры. В n-звенной модели их лучше всего использовать внутри EJB, осуществляющего доступ к данным, и с помощью этого EJB обеспечивать независящий от платформы доступ к базе данных.

WebLogic Server имеет JDBC драйвера для многих широко используемых баз данных, включая Oracle, Sybase, Microsoft SQL Server, и Informix. Он также поставляется с JDBC драйвером для Cloudscape — DBMS, написанной на чистом Java, демонстрационная версия, которой идет с WebLogic Server.

Далее, давайте рассмотрим пример.

Пример JDBC
Наш пример предполагает, что у вас есть база данных PhoneBook, установленная в Cloudscape, и эта база данных содержит таблицу CONTACT_TABLE с полями NAME и PHONE. Мы начнем с загрузки драйвера Cloudscape JDBC. Запрашивая его, менеджер драйверов получает соединение с базой данных PhoneBook в Cloudscape. Используя это соединение, мы создаем объект Statement и с его помощью выполненяем простые SQL запросы. В конечном счете, цикл проходит по всем сущностям полученной выборки, записывая содержимое полей NAME и PHONE в стандартный поток вывода.

 import java.sql.*;

 public class JDBCExample
 {
   public static void main( String args[] )
   {
     try
     {
        Class.forName("COM.cloudscape.core.JDBCDriver");
        Connection conn = DriverManager.getConnection(
                                              "jdbc:cloudscape:PhoneBook");
        Statement stmt = conn.createStatement();
        String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name";
        ResultSet resultSet = stmt.executeQuery( sql );

        String name;
        String phone;
        while ( resultSet.next() )
        {
          name = resultSet.getString(1).trim();
          phone = resultSet.getString(2).trim();
          System.out.println( name + ", " + phone );
        }
     }
       catch ( Exception e )
     {
        // Handle exception here
        e.printStackTrace();
     }
   }
 }

Это все по поводу доступа к БД через драйвер JDBC. Теперь давайте рассмотрим использование JDBC в больших приложениях.

JDBC в приложениях масштаба предприятия
Предыдущий пример годится только для простых приложений. Он тоже предполагает использование двухуровневой архитектуры. В крупных приложениях, более подходящий вариант, чтобы клиент связывался с EJB, который, в свою очередь, будет осуществлять соединение с базой данных. Для улучшения расширяемости и производительности WebLogic Server поддерживает пул соединений.

Пулы соединений сокращают накладные расходы на установление и закрытие соединений с базой данных, поскольку создаются при старте сервера. Когда требуется соединение с базой данных WebLogic Server просто выбирает одно соединение из пула вместо того, чтобы создавать новое с нуля. Пулы соединений в WebLogic Server определяются в файле weblogic.properties. Для поиска дополнительной информации обратитесь к вашему файлу weblogic.properties и документации WebLogic Server.

Другая характерная черта баз данных часто требуемая в крупных приложениях — поддержка механизма транзакций. Транзакция — группа операторов, которые должны выполняться одной операцией для уверенности в целостности данных. По умолчанию JDBC использует режим автоматического подтверждения транзакций (auto commit). Это может быть переопределено с помощью метода setAutoCommit() класса Connection.

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

Java Naming and Directory Interface (JNDI)

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

В JNDI, каждый нод в структуре директориев называется контекст (context.) Каждое имя JNDI соотносится с контекстом. Нет никакого упоминания об абсолютном имени. Приложение может получить начальный контекст, используя класс InitialContext:

 Context ctx = new InitialContext();

От этого начального контекста, приложение может перемещаться по дереву каталогов и искать необходимые ресурсы или объекты. Например, предположите, что вы установили EJB компонент на WebLogic Server и связали домашний (home) интерфейс с именем myApp.myEJB. Клиент этого EJB, после получения начального контекста, может найти home интерфейс, используя:

 MyEJBHome home = ctx.lookup( "myApp.myEJB" );

Как только вы получили связь с полученным объектом, в данном случае home интерфейс EJB компонента, можно вызывать его методы. Мы будем обсуждать это позже в следующем разделе "Enterprise Java Beans."

Это обсуждение JNDI — только верхушка айсберга. В дополнение к поиску объекта в контексте, в JNDI есть методы, для того чтобы:

  • Добавлять или связывать объекты в контексте. Это необходимо, когда вы устанавливаете EJB компоненты.
  • Удалять объекты из контекста.
  • Получать список объектов в контексте.
  • Создавать и удалять подконтексты.

Теперь, уделим внимание EJB.

Enterprise Java Beans (EJB)

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

Спецификация EJB определяет три фундаментальных типа bean:

  • Stateless session beans: Обеспечивают одноразовый сервис, не запоминают состояние компонента, не восстанавливаются после сбоев сервера и имеют относительно короткое время жизни. Одним из примеров использования stateless session bean может быть выполнение конвертации шкал температур из одной в другую.
  • Stateful session bean: Обеспечивают диалог с клиентом ,так как хранят его состояние. Онлайновая корзина покупок — классический пример stateful session bean. Stateful session beans не восстанавливаются после сбоев сервера, тоже имеют относительно короткое время жизни, и каждый экземпляр может быть только в одном потоке.
  • Entity beans: Обеспечивают представление постоянных данных, обычно хранимых в базе данных, и, следовательно, могут восстанавливаться после системных сбоев. Разные клиенты могут использовать EJB, представляющий те же самые данные. Пример entity EJB — информация счета клиента.

Несмотря на их различие, все EJB имеют много общего. Они все имеют интерфейс home, который определяет как создавать и уничтожать EJB, удаленный (remote) интерфейс, который определяет методы bean доступные клиенту и bean класс, который реализует основную бизнес логику.

Описание разработки EJB выходит за границы этой статьи. Однако, если EJB уже разработан или куплен у сторонней фирмы, он должен быть установлен на сервере приложений. WebLogic Server 5.1 поставляется с так называемым EJB Deployer Tool для помощи в установке EJB. Когда вы устанавливаете EJB , используя EJB Deployer Tool, вы определяете имя JNDI, которое будет использоваться клиентами для доступа к EJB. Deployer Tool генерирует классы-упаковщики (wrapper classes), управляющие обменом информации с контейнером и собирает Java классы вместе в одном jar файле.

С того момента как EJB установлен, клиент может найти EJB через его JNDI имя. Первое, он должен связаться с home интерфейсом. Затем, используя этот интерфейс, клиент может вызвать один из create() методов bean для получения управления экземпляром bean, выполняющемся на сервере. Теперь, клиент может вызывать методы bean.

От EJB мы перемещаемся к JSP.

JavaServer Pages (JSPs)

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

Рассмотрим пример простого JSP, который показывает серверную дату и время. Объяснение деталей примера вне компетенции этой статьи, однако, обратите внимание на Java код между <% и %> символами, и следующее выражение Java между <%= и %> символами.

 <html>
 <head>
  <title>Sample JSP Page</title>
 </head>
 <body>
 <h1>Date JSP sample</h1>

 <h2>
 <% response.setHeader("Refresh", 5); %>
 The current date is <%= new Date() %>.
 </h2>

 </body>
 </html>

Вы могли случайно слышать упоминание о JHTML, это — устаревший стандарт, замененный на стандарт JSP с момента его появления. WebLogic Server может поддерживать JSP также хорошо как JHTML. Но замечу, что по умолчанию, поддержка JSP внутри WebLogic Server не включена. Для ее включения необходимо отредактировать файл weblogic.properties и включить Web сервер, если он не был включен, как и JSPServlet.

Следующее: Java servlets

Java servlets

Servlet-ы предоставляют почти те же самые возможности, что и JSP, хотя используют несколько иной подход. Тогда как JSP традиционно состоят в основном из HTML со вставками небольшого количества Java, servlet(ы), напротив, написаны полностью на Java и формируют код HTML.

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

Разрабатывая сервлеты, вы будете главным образом наследовать класс javax.servlet.http.HttpServlet и переопределять некоторые из его методов. Наиболее интересные методы:

  • service() : Действует как диспетчер HTTP запросов, перенаправляя их в соответствующий метод.
  • doGet() : Управляет HTTP GET запросом клиента
  • doPost(): : Управляет HTTP POST запросом клиента

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

Все методы, описанные выше, — часть стандартного J2EE Servlet API. WebLogic Server предоставляет полную реализацию этого API. Разработав свой сервлет, вы можете установить его на WebLogic Server, зарегистрировав его в файле weblogic.properties.

Java servlet-ы, последняя из основных технологий J2EE, но не все, что J2EE может предложить. В следующих разделах, в нескольких словах, мы кратко рассмотрим оставшиеся технологии, включая RMI, Java IDL и CORBA, JTA, XML.

Remote Method Invocation (RMI)

Как и предполагает название, протокол RMI вызывает методы удаленных объектов. Он использует сериализацию (serialization) для передачи данных между клиентом и сервером. RMI лежит в основе протокола, используемого EJB.

Java IDL/CORBA

Благодаря поддержке IDL в Java, разработчики получают возможность интегрировать Java с CORBA. Они могут создавать объекты Java, которые могут быть установлены внутри CORBA ORB, и они могут создавать классы Java, которые действуют как клиенты CORBA объектов, установленных внутри других ORB. Последний подход — еще один путь использования Java для интеграции вашего приложения в уже существующую систему.

Java Transaction Architecture (JTA)/Java Transaction Service (JTS)

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

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

JavaMail и JavaBeans Activation Framework

JavaMail — API для доступа к почтовым серверам. JavaMail API предоставляет множество абстрактных классов, моделирующих почтовую систему. Поддерживаются как SMTP, так и IMAP сервера.

JavaMail использует JavaBeans Activation Framework (JAF) для управления MIME-кодированными почтовыми дополнениями. Байтовый MIME поток может быть получен из Java объекта и преобразован в Java объект. Большинство приложений не должны использовать JAF напрямую.

Java Messaging Service (JMS)

JMS — API для связи с ориентированным на сообщения связующим программным обеспечением MOM. Оно поддерживает как режим передачи сообщений между одиночными клиентами (point-to-point) так и передачу сообщений по подписке (publish/subscribe), поддерживает гарантированную доставку сообщений, механизм транзакций при доставке сообщений, сообщения c признаком обязательной доставки (persistent message), и долговременных подписчиков (durable subscribers). JMS дает другой метод интеграции ваших приложений с унаследованными прикладными серверными системами.

Extensible Markup Language (XML)

XML — расширяемый язык разметки, способный определять другие языки разметки. Он может быть использован совместного использования данных различными задачами. XML был разработан независимо от Java, однако, они имеют общие цели в вопросе платформо-независимости. Комбинируя Java и XML, вы получаете полностью платформо-независимое решение. Различные компании работают над развитием тесной интеграции Java и XML. Для большей информации посетите страницу Java-XML на Sun, или XML Zone на developerWorks компании IBM для большей информации смотрите Ресурсы

Заключение

В этой статье, мы представили распределенную архитектуру построенную в J2EE, и мы описали как WebLogic поддерживает J2EE. Это, однако, только вершина айсберга, Невозможно в статье из 3000 слов отдать должное потенциалу J2EE в разработке корпоративных приложений.

Мы сфокусировали наше внимание на технологиях, с которыми вы вероятнее всего можете столкнуться, когда начнете работать с J2EE: JDBC, JNDI, EJB, JSP, и servlet. Мы также снабдили вас некоторой исходной информацией по менее известным технологиям J2EE. Если вы разработчик, специалист в области конъюнктуры рынка или руководитель проекта, теперь вы должны представлять, что J2EE и WebLogic Server могут предложить вам, вашему предприятию и вашим корпоративным приложениям.

Благодарности

Благодарю Шари Л. (Shari L.), Джонса (Jones) и Била Данклау (Bill Dunklau) за их вклад в эту статью.

Об авторе

Стивен Гоулд Исполнительный консультант CGI Information Systems. Живет в Далласе, работает проектировщиком и ведущим разработчиком, главным образом с Java и C++ на Windows и разных Unix платформах. Сертифицированный Sun разработчик на Java , Стивен использует Java с момента появления beta версии JDK 1.0. Публиковал статьи по Java в родственном JavaWorld издании SunWorld, а также в Java Developers Journal.

Ресурсы

Ресурсы JavaWorld

Другие ресурсы

Reprinted with permission from the December 2000 edition of JavaWorld magazine. Copyright © ITworld.com, Inc., an IDG Communications company.
View the original article at: http://www.javaworld.com/javaworld/ jw-12-2000/jw-1201-weblogic.html

[an error occurred while processing this directive]
[an error occurred while processing this directive] Перевод на русский © Дмитрий Зацеляпин, 2001
< Вернуться на caйт :: Copyright © 1999 — 2010, IT • archiv.