ДонНТУ > Портал магистров ДонНТУ RUS | ENG
Магистр ДонНТУ Ильенко Олег Витальевич
ИЛЬЕНКО ОЛЕГ ВИТАЛЬЕВИЧ
Факультет: Вычислительной техники и информатики
Специальность: Программное обеспечение
Тема выпускной работы: Исследование эффективности распределенной системы с базами данных
Руководитель: Ладыженский Юрий Валентинович
E-Mail: ora_dba@bk.ru

Реферат

На этой странице вы сможете узнать больше о моей магистерской работе.

Исследование эффективности распределенной системы с базами данных

Содержание

Введение

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-уровневой архитектуры приложения

Рисунок 3 показывает, как продвигается запрос пользователя от браузера до сервера баз данных.

Продвижения запроса пользователя в архитектуре J2EE
Рисунок 3 - Продвижения запроса пользователя в архитектуре J2EE

Java Database Connectivity (JDBC)

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

Архиектура JDBC
Рисунок 4 - Архиектура JDBC

В 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 в приложениях масштаба предприятия
Предыдущий пример годится только для простых приложений. Он тоже предполагает использование двухуровневой архитектуры. В крупных приложениях, более подходящий вариант, чтобы клиент связывался с 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 есть методы, для того чтобы:

Enterprise Java Beans (EJB)

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

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

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

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

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

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

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

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

Существуют другие методы для управления различными типами 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 для большей информации смотрите Ресурсы

Ресурсы

Автобиография |  Реферат |  Библиотека |  Ссылки |  Отчет о поиске |  Индивидуальное задание
ДонНТУ > Портал магистров ДонНТУ © Ильенко Олег 2006г. RUS | ENG