Настоящая статья посвящена платформам для создания корпоративных решений. Не секрет, что сейчас архитекторов приложений волнует другой вопрос: какую из платформ следует выбрать в качестве основы создания корпоративного решения Microsoft .NET или J2EE (Java 2 Enterprise Edition)? Сравнению этих платформ как с технологической, так и с экономической точки зрения в последние полтора года посвящено немало публикаций, к которым могут обратиться те, кто интересуется деталями реализации платформ и приложений, на них базирующихся, а также особенностями материальных затрат при реализации основанных на этих платформах проектов.
ель данной статьи ответить на вопрос, в чем заключаются наиболее важные различия этих двух платформ; судя по письмам читателей, ясное представление об этом до сих пор имеется далеко не у всех разработчиков и других IT-специалистов.
Согласно данным Gartner Group Research, поляризация между Microsoft .NET и J2EE, с которой в данный момент приходится иметь дело IT-менеджерам, приведет к тому, что эти две платформы в ближайшее время окажутся доминирующими при создании новых корпоративных приложений, при этом 45% всех вновь разрабатываемых проектов будут так или иначе иметь дело с обеими платформами (рис. 1). Отметим, что, согласно Gartner, с вероятностью 70% широко применяться будут обе платформы (источник: Gartner .NET vs Java: Competition or Cooperation).
Приведенные данные свидетельствуют о том, что в ближайшее время ни одна из двух указанных выше платформ для создания корпоративных приложений не будет явно доминировать над другой и, следовательно, архитекторы подобных приложений будут вынуждены выбирать одну из них и применять средства интеграции (такие как Web-сервисы XML) для того, чтобы использовать сервисы, выполняемые на второй. В настоящей статье мы никоим образом не претендуем на роль советчиков относительно выбора платформ и средств интеграции, однако попробуем рассмотреть, в чем принципиальное различие между этими платформами и в какой степени они поддерживаются ведущими производителями средств разработки, серверов приложений и СУБД.
Архитектура корпоративных приложений
рхитектуры корпоративных приложений, основанных на обеих платформах, имеют много общего. Как правило, современные приложения масштаба предприятия логически делятся на три звена, первое из которых предоставляет сервисы данных (реально роль этого звена выполняет сервер баз данных), второе сервисы бизнес-логики (в случае обеих платформ они обычно реализуются в виде компонентов, выполняющихся под управлением серверов приложений либо runtime-среды), третье презентационные сервисы, которые могут представлять собой либо GUI-приложения, либо Web-браузеры (рис. 2).
Отметим, что обе платформы изначально предназначались для упрощения создания, внедрения и сопровождения многозвенных приложений. Следует подчеркнуть, что главным образом речь может идти именно о применении этих платформ при реализации сервисов бизнес-логики.
J2EE
2EE представляет собой спецификацию, реализованную в серверах приложений различных производителей. Данная спецификация результат совместной деятельности ряда компаний, выпускающих программное обеспечение (включая IBM, BEA, Oracle), лидером среди которых является Sun Microsystems; в настоящее время эти компании образуют сообщество Java Community Process (JCP). Предполагается, что при идеальном соответствии спецификации код приложения будет переносим между серверами приложений различных производителей. Цель создания этой спецификации предоставить потенциальным пользователям возможность выбора серверов приложений и средств разработки из нескольких возможных предложений разных производителей (на данный момент производителей J2EE-совместимых серверов приложений и средств разработки существует около трех десятков).
Для создания J2EE-приложений используется один-единственный язык программирования Java. Java-приложения представляют собой скомпилированный из исходного текста байт-код, переносимый между платформами и интерпретируемый внутри виртуальной Java-машины (Java Runtime Environment, JRE), реализации которой существуют для разных платформ. J2EE-приложения выполняются внутри контейнеров, предоставляемых серверами приложений. Серверы приложений и средства разработки J2EE-приложений выпускаются разными производителями, включая BEA, Borland, IBM, Novell, Oracle, Sybase, Sun, и поддерживают широкий спектр платформ и СУБД. Согласно исследованиям аналитиков, 60% рынка J2EE-совместимых серверов приложений принадлежит компаниям BEA и IBM.
Один из недостатков J2EE с точки зрения разработки приложений необходимость применения единственного языка программирования для решения абсолютно всех бизнес-задач. При этом одним из преимуществ этой платформы является возможность выбора поставщика программного обеспечения и создания решения, переносимого между операционными системами, что предоставляют многие производители J2EE-совместимых серверов приложений.
Microsoft .NET
Отличие от J2EE, Microsoft .NET представляет собой не просто спецификацию, созданную компанией Microsoft, но еще и реализацию этой спецификации для платформы Windows. Приложения для этой платформы представляют собой переносимый код на промежуточном языке MSIL (Microsoft Intermediate Language), сходным с байт-кодом Java. В процессе выполнения приложения этот код заменяется в памяти на машинный код, оптимизированный для данного процессора. Сам же MSIL-код получается при компиляции исходного текста, созданного на одном из языков высокого уровня, для которых имеются соответствующие компиляторы (сейчас таких языков около 30), причем все эти языки используют общую библиотеку классов. Возможность создания приложений с помощью разных языков является одним из несомненных преимуществ.NET. Хотя Microsoft .NET можно создавать для разных операционных систем, на данный момент реализация этой платформы существует только для нескольких версий Windows и частично для FreeBSD.
Отметим, что среда выполнения.NET-приложений Common Language Runtime, CLR (в определенной степени аналог виртуальной Java-машины) предоставляет множество сервисов для этих приложений, например автоматическую сборку мусора, межъязыковое наследование, поддержку применения нескольких версий одного и того же компонента.
Говоря о серверных продуктах для этой платформы (аналогах серверов приложений), чаще всего вспоминают словосочетание Microsoft .NET Enterprise Servers так называется семейство серверов различного назначения для платформы Windows. Тем не менее в течение ближайшего времени, пока не произошла смена версий всех этих серверов на более новые, содержащие встроенную среду выполнения.NET-кода Common Language Runtime, это словосочетание будет оставаться скорее маркетинговым термином, нежели отражением реального положения дел. Из средств разработки для этой платформы на данный момент доступно только одно Microsoft Visual Studio .NET, а также более двух десятков компиляторов независимых производителей, большая часть из которых может быть использована совместно с Visual Studio .NET. Тем не менее компании Borland и Macromedia объявили о своих планах, связанных с выпуском собственных средств разработки для этой платформы; так, средство разработки для этой платформы от Borland следует ожидать в 2003 году.
Из недостатков Microsoft .NET стоит отметить то, что на данный момент применимость соответствующих приложений ограничена операционными системами Windows и FreeBSD. К достоинствам можно отнести более низкую стоимость решений, чем в случае применения J2EE, за счет более низких требований к аппаратному обеспечению, необходимому для выполнения серверной части приложений, возможности использования унаследованного кода и имеющегося опыта разработки на различных языках программирования, а также возможности создания с помощью технологии ASP .NET универсальных приложений, не зависящих от типа устройства, на котором выполняется клиентская часть.
Что общего у.NET и J2EE
тметим, что обе платформы в силу сходного назначения имеют много общих черт. Обе они, по существу, основаны на интерпретации кода или компиляции его «на лету» в случае J2EE роль среды выполнения играет JRE, в случае Microsoft .NET CLR. Обе платформы поддерживают компоненты, выполняющиеся в среднем звене многозвенных приложений (Enterprise Java Beans, EJB в случае J2EE, управляемые компоненты в случае.NET), а также средства создания динамических Web-страниц, содержащих выполняемый сервером код (в случае J2EE это технология Java Server Pages (JSP), в случае.NET ASP .NET). И J2EE и.NET обладают собственными универсальными механизмами доступа к данным: в первом случае это Java Database Connectivity (JDBC), во втором ADO .NET. Обе платформы удовлетворяют общим требованиям, предъявляемым к средствам middle-ware, как-то: поддержка баланса за-грузки и устойчивость к сбоям за счет резервирования и дублирования. Наконец, обе платформы поддерживают технологию Web-сервисов XML, включая сопутствующие стандарты (SOAP, WSDL, UDDI). Более того, сегодня Web-сервисы являются единственным способом интеграции приложений, созданных с помощью этих двух платформ.
В отношении обеих платформ следует помнить, что их применение в любом случае потребует затрат на обучение разработчиков либо языку и технологиям Java, либо созданию.NET-приложений. Впрочем, более простая модель программирования, применяемая в.NET, поможет слегка сэкономить на процессе обучения. Однако необходимо отметить, что для обеих платформ имеются библиотеки классов, дающие возможность освободить разработчика от написания многих рутинных процедур и функций, а также визуальные средства разработки, позволяющие генерировать значительную часть кода общего назначения.
С помощью обеих платформ возможно создание Web-сервисов, на данный момент являющихся единственной технологией интеграции этих двух платформ между собой, а также решений, отличающихся невысокой начальной стоимостью. Скажем, для реализации J2EE-решений существуют бесплатные версии серверов приложений (например, от Sun Microsystems, Hewlett-Packard и некоторых других производителей) и бесплатные операционные системы (такие как Linux), а некоторые.NET-решения могут требовать только наличия операционной системы семейства Windows. Обе платформы позволяют создавать решения, основанные на программных продуктах единственного производителя, поскольку производители серверов приложений, как правило, создают и средства разработки, а нередко и СУБД. Отметим также, что масштабируемость решений, созданных с помощью обеих платформ, чрезвычайно высока.
Аргументы в пользу выбора одной из платформ
ем не менее можно назвать целый ряд аргументов в пользу выбора той или иной платформы. В частности, выбирая платформу Microsoft .NET, лица, отвечающие за принятие данного решения, отмечают более раннее появление у этой платформы полноценной поддержки Web-сервисов, высокое качество Visual Studio .NET как средства разработки и наличие большого количества разработчиков, знакомых с прежними версиями этого продукта, простую модель программирования, возможность применения различных языков программирования в одном приложении, высокую степень интеграции с операционной системой.
В то же время аргументами в пользу выбора платформы J2EE могут служить наличие большого количества производителей и поддержка этой платформы на уровне всей индустрии, а не одного конкретного производителя, возможность легкого представления унаследованного кода в виде Web-сервисов (в случае Windows DNA, предшественника.NET, данная процедура также возможна, но не столь проста), поддержка в Web-сервисах общепринятого языка обмена данными между приложениями электронной коммерции ebXML, лучшие возможности применения унаследованных приложений за счет архитектуры Java Connector Architecture (JCA), возможность более широкого выбора аппаратных платформ и операционных систем для реализации серверной части приложений, а также большое количество 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 приложениях.
Спасибо за внимание!
Сегодня все больше и больше разработчиков хотят создавать распределенные транзакционные корпоративные приложения и использовать преимущества в скорости, защищенности и надежности, обеспечиваемые серверными технологиями. Если вы уже работаете в этой области, то вам известно, что в современном, быстро меняющемся и выдвигающем все новые требования мире электронной коммерции и информационных технологий, корпоративные приложения должны проектироваться, создаваться и внедряться за меньшие деньги, с большей скоростью и меньшими затратами ресурсов, чем это было ранее.
Для уменьшения стоимости и увеличения скорости проектирования и разработки корпоративного приложения платформа J2EE предлагает компонентный подход к проектированию, разработке, сборке и внедрению корпоративных приложений. Платформа J2EE предлагает модель многоуровневого распределенного приложения, возможность повторного использования компонентов, интегрированный обмен данными на основе XML, унифицированную модель безопасности и гибкое управление транзакциями. Вы не только можете выпускать на рынок инновационное решение для пользователей быстрее, чем раньше, но и Ваши платформо-независимые, основанные на компонентах J2EE-решения больше не привязаны к продуктам и API какого-либо одного производителя. Производители и пользователи обладают свободой выбора продуктов и компонентов, которые наиболее полно удовлетворяют их деловые и технологические требования.
Это руководство основано на примерах, описывающих возможности и функции, доступные в J2EE SDK версии 1.3. Вне зависимости от того, новичок Вы или опытный корпоративный разработчик, Вы найдете в примерах и сопровождающем их тексте полезную и доступную информацию для создания ваших собственных корпоративных решений.
Если Вы новичок в разработке J2EE приложений, эта глава – хорошее место для старта. В ней вы изучите архитектуру J2EE, ознакомитесь с важными соглашениями и понятиями, а также найдете собственные подходы к программированию, сборке и внедрению J2EE приложений.
В этой главе
Распределенные многоуровневые приложения
Платформа J2EE использует модель многоуровневого распределенного приложения. Логически приложение разделено на компоненты в соответствии с их функциональностью. Различные компоненты, составляющие J2EE-приложение, установлены на различных компьютерах в зависимости от их уровня в многоуровневой среде J2EE, которой данный компонент принадлежит. На рисунке 1-1 представлены два J2EE-приложения, разделенные на уровни, перечисленные в следующем списке. Части J2EE-приложения, показанные на рисунке 1-1, представлены в разделе "J2EE -компоненты".
Компоненты клиентского уровня работают на клиентской машине.
Компоненты Web-уровня работают на J2EE-сервере.
Компоненты бизнес-уровня работают на J2EE-сервере.
Программное обеспечение уровня корпоративной информационной системы (EIS) работает на EIS-сервере.
Хотя J2EE-приложение состоит из трех или четырех уровней, показанных на , многоуровневые J2EE-приложения обычно принято называть трехуровневыми, т.к. они расположены на трех различных системах: клиентский компьютер, сервер J2EE и сервер базы данных или обычный сервер. Трехуровневые приложения, работающие данным способом, расширяют стандартную архитектуру клиент-сервер, добавляя многопоточный сервер приложений между клиентской частью и сервером базы данных.
Рисунок 1. Многоуровневые приложения
J2EE-компоненты
J2EE-приложения состоят из компонентов. J2EE-компонента представляет собой законченный функциональный программный модуль, встроенный в приложение J2EE с соответствующими классами и файлами и взаимодействующий с другими компонентами. J2EE-спецификация определяет следующие J2EE-компоненты:
Клиентские приложения и апплеты – это компоненты, работающие на клиентской машине.
Компоненты технологии Java-сервлет и JavaServer Pages (JSP) – это Web-компоненты, работающие на сервере.
Корпоративные компоненты – это бизнес-компоненты, работающие на сервере.
J2EE-компоненты пишутся на языке программирования Java и компилируются точно так же, как и любая другая Java-программа. Отличием между J2EE-компонентами и "стандартными" классами Java является то, что J2EE-компоненты собираются в J2EE-приложение, находящееся в строгом соответствии со спецификацией J2EE, развернутое для функционирования в соответствующем месте и управляемое сервером J2EE.
J2EE-клиенты
J2EE-клиентом может быть Web-клиент или клиент приложения.
Web-клиенты
Web-клиент состоит из двух частей: динамические Web-страницы, написанные на языках разметки различного типа (HTML, XML и т.д.), генерируемые Web-компонентами на Web-уровне, и Web-браузер, визуализирующий полученные от сервера страницы.
Web-клиент иногда называют тонким клиентом. Тонкие клиенты обычно не выполняют таких функций как запрос к базе данных, реализация сложных бизнес-правил или связь с серверными приложениями. При использовании тонкого клиента подобные полновесные операции переносятся на корпоративные компоненты, выполняющиеся на J2EE-сервере и использующие безопасность, скорость, сервисы и надежность J2EE-серверных технологий.
Апплеты
Web-страница, полученная от Web-уровня, может включать в себя встроенный апплет. Апплет - это небольшое клиентское приложение, написанное на языке Java и выполняющееся на установленной в Web-браузере виртуальной машине Java. Однако системы клиента могут потребовать Java- Plug-in и файл политики безопасности для того, чтобы апплет успешно выполнялся в Web-браузере.
Web-компоненты являются более предпочтительным API для создания клиентской Web-программы, т.к. на системах клиента не требуется никаких дополнений и файлов политики безопасности. К тому же Web-компоненты предоставляют более ясную модульную структуру приложения, т.к. обеспечивают способ отделения программного кода приложения от кода оформления Web-страниц.
Клиенты приложения
Клиент J2EE-приложения работает на клиентской машине и обеспечивает пользователей возможностью работать с задачами, требующими более богатого пользовательского интерфейса, чем тот, который предоставлен языками разметки страниц. Они обычно имеют графический пользовательский интерфейс, созданный при помощи Swing или AWT API, хотя, безусловно, возможен и интерфейс командной строки.
Клиенты приложения имеют непосредственный доступ к корпоративным компонентам, исполняющимся на бизнес-уровне. Тем не менее, клиент приложения J2EE может открыть HTTP соединение для коммуникации с сервлетом, работающим на Web-уровне, если существуют такие требования к приложению.
Архитектура компонентов JavaBeans
Уровни сервера и клиента могут также включать компоненты, основанные на архитектуре компонентов JavaBeans, для управления потоком данных между клиентом приложения или апплетом и компонентами, выполняющимися на сервере J2EE, либо компонентами сервера и базой данных. Компоненты JavaBeans не считаются компонентами J2EE согласно спецификации J2EE.
Компоненты JavaBeans содержат переменные экземпляра и методы get и set для доступа к данным в переменных экземпляра. Компоненты JavaBeans, используемые таким образом, обычно просты по дизайну и реализации, но должны быть согласованы с правилами именования и дизайна, определенными в архитектуре компонентов JavaBeans.
Коммуникации сервера J2EE
Уровень корпоративной информационной системы
Уровень корпоративной информационной системы образует программное обеспечение информационной системы и включает в себя системы корпоративной инфраструктуры, такие как планирование ресурсов предприятия (ERP), управление транзакциями мейнфрейма, базы данных, и другие стандартные информационные системы. J2EE-компоненты могут нуждаться в доступе к корпоративным информационным системам для взаимодействия, например, с базами данных.
J2EE-контейнеры
Обычно многоуровневые приложения для тонких клиентов писать тяжело, потому что они включают в себя много строк сложного кода для управления транзакциями и состояниями, многопоточностью, обменом ресурсами и другими комплексными низкоуровневыми задачами. Основанная на компонентах и платформо-независимая архитектура J2EE облегчает написание J2EE-приложений, потому что бизнес-логика локализуется в компонентах многократного использования. Кроме того, J2EE-сервер обеспечивает основные сервисы в форме контейнера для каждого типа компонентов. Т.к. Вы не должны разрабатывать эти сервисы самостоятельно, Вы можете сконцентрироваться на решении текущих бизнес-задач.
Контейнерные сервисы
Контейнеры являются интерфейсом между компонентом и низкоуровневыми платформо-зависимыми функциональными возможностями, поддерживающими компонент. До того, как Web-компонент, корпоративный компонент или компонент клиентского приложения может быть выполнен, он должен быть скомпонован в J2EE-приложение и размещен внутри своего контейнера.
Процесс компоновки включает в себя определение установок контейнера для каждого компонента в J2EE-приложении и для самого J2EE-приложения. Установки контейнера настраивают внутреннюю поддержку, обеспечиваемую J2EE-сервером, которая включает в себя такие сервисы как безопасность, управление транзакциями, JNDI-поиск и удаленную связь. Вот некоторые из основных положений:
Модель безопасности J2EE позволяет сконфигурировать Web-компонент или корпоративный компонент так, что доступ к системным ресурсам разрешается только авторизованным пользователям.
Модель транзакции J2EE позволяет вам определять взаимосвязи между методами, которые составляют простую транзакцию, так, что все методы в одной транзакции интерпретируются как один модуль.
Сервисы поиска JNDI обеспечивают унифицированный интерфейс к различным сервисам каталогов и имен на предприятии, так что компоненты приложения получают доступ к этим сервисам.
Модель удаленного доступа J2EE управляет низкоуровневыми взаимосвязями между клиентами и корпоративными компонентами. После того, как корпоративный компонент создается, клиент вызывает его методы так, как если бы они находились на той же виртуальной машине.
Тот факт, что J2EE-архитектура обеспечивает конфигурируемые сервисы, означает, что компоненты в J2EE-приложении могут вести себе по-разному, в зависимости от места их размещения. Например, корпоративный компонент может иметь установки безопасности, дающие ему определенный уровень доступа к базе данных в одном рабочем окружении и другой уровень доступа - в другом.
Контейнер также управляет неконфигурируемыми сервисами, такими как время жизни корпоративного компонента и сервлета, ресурсный пул (объединение ресурсов) связи с БД, персистенция данных, доступ к API J2EE-платформы, описанным в разделе "J2EE API". Хотя сохраняемость данных является неконфигурируемым сервисом, J2EE-архитектура позволяет замещать сохраняемость, управляемую контейнером, при помощи включения соответствующего кода в реализацию вашего корпоративного компонента в тех случаях, когда вы желаете получить больший контроль, чем обеспечиваемый по умолчанию. Например, Вы можете использовать персистенцию, управляемую компонентом, для реализации Ваших собственных методов поиска или для создания пользовательского кэша базы данных.
Типы контейнеров
Процесс размещения устанавливает компоненты J2EE-приложения в J2EE-контейнеры, как показано на
J2EE-сервер: является частью времени исполнения J2EE-приложения. J2EE-сервер предоставляет EJB и Web-контейнеры.
Корпоративный EJB-контейнер: управляет исполнением корпоративных компонентов для J2EE-приложений. Корпоративные компоненты и их контейнер выполняются на J2EE-сервере.
Web-контейнер: управляет исполнением JSP-страницы и сервлетов для J2EE-приложения. Web-компоненты и их контейнер выполняются на J2EE-сервере.
Контейнер клиентского приложения: управляет исполнением компонентов клиентского приложения. Клиентские приложения и их контейнер выполняются на клиенте.
Контейнер апплетов: управляет выполнением апплетов. Состоит из web-броузера и Java- plug-in, выполняющихся на клиенте совместно.
Рисунок 5. J2EE-сервер и контейнеры
Пакетирование
J2EE-компоненты упаковываются раздельно и связываются в J2EE-приложение. Каждый компонент, его файлы, такие как GIF и HTML-файлы, или сервисные классы на сервере и дескриптор размещения компонуются в модуль и добавляются в J2EE-приложение. J2EE-приложение состоит из одного или нескольких модулей корпоративных компонентов, web-компонентов или компонентов клиентского приложения. Окончательное корпоративное решение может использовать одно J2EE-приложение или состоять из двух и более J2EE-приложений в зависимости от требований проекта.
J2EE-приложение и каждый из его модулей имеет собственный дескриптор размещения. Дескриптор размещения является XML-документом с расширением.xml, описывающим установки размещения компонента. Дескриптор размещения модуля корпоративного компонента, например, описывает атрибуты транзакции и уровень безопасности для корпоративного компонента. Т.к. информация дескриптора размещения является описательной, она может меняться без изменения исходного кода компонента. Во время выполнения J2EE-сервер читает дескриптор размещения и соответствующим образом обрабатывает компонент.
J2EE-приложение со всеми своими модулями поставляется в файле корпоративного архива (EAR). EAR-файл является стандартным Java-архивом (JAR) с расширением.ear. В GUI-версии J2EE SDK Вы сначала создаете EAR-файл и добавляете JAR и WAR (Web Archive) файлы в EAR. Если Вы используете средства пакетирования командной строки, Вы сначала создаете JAR и WAR файлы, а затем создаете EAR. J2EE SDK инструменты описаны в разделе "Инструменты".
Каждый EJB JAR-файл содержит дескриптор размещения, файлы корпоративных компонентов и связанные с ними файлы.
Каждый JAR-файл клиентского приложения содержит дескриптор размещения, файлы классов клиентского приложения и связанные с ними файлы.
Каждый WAR-файл содержит дескриптор размещения, файлы Web-компонентов и связанные с ними ресурсы.
Использование модулей и EAR-файлов делает возможной компоновку нескольких различных J2EE-приложений, используя некоторые из тех же самых компонентов. Никакое дополнительное кодирование не требуется; это вопрос компоновки различных J2EE-модулей в EAR-файлы.
Роли в разработке ПО
Модули повторного использования дают возможность разделить процесс разработки и размещения приложения на отдельные составляющие, так что разные люди и компании могут выполнять различные части процесса.
Первые две фазы включают приобретение и инсталляцию J2EE-приложения и инструментов. Когда программное обеспечение приобретено и установлено, J2EE-компоненты могут быть разработаны поставщиками компонентов приложения, скомпонованы сборщиками приложения и размещены установщиками. В большой организации каждая из этих фаз может выполняться различными специалистами или их группами. Такое разделение труда работает, потому что на каждой фазе создается переносимый файл, являющийся входным для следующей фазы. Например, на фазе разработки компонента приложения разработчик корпоративного компонента создает EJB JAR-файлы. На фазе компоновки приложения другой разработчик компонует эти файлы в J2EE-приложение и сохраняет его как EAR-файл. На фазе размещения приложения системный администратор на сайте пользователя использует EAR-файл для инсталляции J2EE-приложения на J2EE-сервере.
Различные фазы не всегда выполняются разными людьми. Если вы работаете в маленькой компании или разрабатываете простое приложение, вы можете выполнять задачи на всех фазах.
Поставщик J2EE-продукта
Поставщиком J2EE-продукта является компания, которая проектирует и продает J2EE-платформу, наборы API и другие средства, определенные в спецификации J2EE. Обычно поставщики продукта – это продавцы операционной системы, системы управления базами данных, сервера приложений или Web-сервера, которые поставляют J2EE-платформу согласно спецификации J2EE.
Поставщик инструмента
Поставщик инструмента – это компания или человек, который создает средства разработки, компоновки и пакетирования, используемые поставщиками компонентов, компоновщиками и установщиками. Для более детальной информации о средствах, доступных в J2EE SDK версии 1.3, смотри раздел "Инструменты".
Поставщик компонента приложения
Поставщиком компонента приложения является компания или человек, который создает Web-компоненты, корпоративные компоненты, апплеты или клиентские приложения для использования в J2EE-приложениях.
Разработчик корпоративного компонента
Разработчик корпоративного компонента выполняет следующие задачи по созданию EJB JAR-файла, содержащего корпоративный компонент:
Описывает дескриптор установки.
Собирает class-файлы и дескриптор установки в EJB JAR-файл.
Разработчик Web-компонента
Разработчик Web-компонента выполняет следующие задачи по созданию WAR-файла, содержащего Web-компонент:
Создает и компилирует исходный код сервлета.
Создает JSP и HTML-файлы.
Описывает дескриптор установки для Web-компонента.
Собирает.class, .jsp, .html-файлы и дескриптор установки в WAR-файл.
Разработчик клиентского приложения J2EE
Разработчик клиентского приложения выполняет следующие задачи по созданию JAR-файла, содержащего клиентское приложение J2EE:
Создает и компилирует исходный код.
Описывает дескриптор установки для клиента.
Собирает.class-файлы и дескриптор установки в JAR-файл.
Компоновщик приложения
Компоновщик приложения - это компания или человек, который получает JAR-файлы компонента приложения от поставщика компонента и компонует их в EAR-файл J2EE-приложения. Компоновщик или установщик может редактировать дескриптор установки непосредственно, или используя инструменты, которые корректно добавляют XML-тэги в диалоговом режиме. Разработчик программного обеспечения выполняет следующие задачи по созданию EAR-файла, содержащего J2EE-приложение:
Собирает EJB JAR и WAR-файлы, созданные на предыдущих этапах, в EAR-файл J2EE-приложения.
Описывает дескриптор установки для J2EE-приложения.
Установщик приложения и администратор
Установщик приложения и администратор – это компания или человек, который конфигурирует и устанавливает J2EE-приложение, администрирует вычислительную и сетевую инфраструктуру, в которой работают J2EE-приложения, и следит за рабочим окружением. В его обязанности входит также настройка управления транзакциями, настройка атрибутов безопасности, а также определение связей с базами данных.
В процессе конфигурирования установщик следует инструкциям, предоставленным поставщиком компонента приложения, для разрешения внешних зависимостей, определяет настройки безопасности и назначает атрибуты транзакции. В процессе инсталляции установщик размещает компоненты приложения на сервере и генерирует зависящие от контейнера (container-specific) классы и интерфейсы.
Установщик/системный администратор выполняет следующие задачи по инсталляции и конфигурированию J2EE-приложения:
Добавляет EAR-файл J2EE-приложения, созданный на предыдущем этапе, на J2EE-сервер.
Конфигурирует J2EE-приложение под рабочее окружение, изменяя дескриптор установки J2EE-приложения.
Проверяет корректность содержимого EAR-файла и его соответствие спецификации J2EE.
Инсталлирует EAR-файл J2EE-приложения на J2EE-сервере.
Программное обеспечение
J2EE SDK – некоммерческое практическое определение платформы J2EE и спецификация, свободно распространяемые Sun Microsystems для демонстрации, апробирования и обучения. J2EE SDK включает в себя сервер приложений J2EE, Web-сервер, реляционную базу данных, набор J2EE API и полный набор инструментов для разработки и установки. J2EE SDK можно загрузить с
Цель J2EE SDK – позволить поставщикам продукта определить, что должна делать их реализация в конкретных условиях, и запустить набор тестов совместимости J2EE для проверки соответствия этих продуктов спецификации. Они также могут запускать свои J2EE-приложения на J2EE SDK для проверки полной переносимости всех J2EE-продуктов и инструментов.
Доступ к базам данных
Реляционная база данных обеспечивает постоянное место хранения данных приложения. Для реализации J2EE не требуется поддержки определенного типа базы данных. Это означает, что базы данных, поддерживаемые различными J2EE-продуктами, могут быть разными. Список баз данных, поддерживаемых в данной реализации, приведен в Release Notes, включенном в J2EE SDK.
J2EE API
Для запуска J2EE SDK необходимо наличие: Java 2 Platform, Standard Edition (J2SE) SDK, которая предоставляет основные API для создания J2EE-компонентов, основные инструменты разработки и виртуальную машину Java. J2EE SDK предоставляет описанные ниже API, используемые в J2EE-приложениях.
Технология Enterprise JavaBeans 2.0
Корпоративный компонент представляет собой код с полями и методами, реализующий модули бизнес-логики. Корпоративный компонент можно представить в виде строительного блока, который может использоваться как самостоятельно, так и совместно с другими компонентами, для исполнения бизнес-логики на J2EE-сервере.
Существует три вида корпоративных компонентов: сессионные компоненты, компоненты управления данными, управляемые сообщениями компоненты. Корпоративные компоненты часто взаимодействуют с базами данных. Одним из преимуществ компонентов управления данными является то, что вы не должны писать никакого SQL-кода или использовать JDBC API непосредственно для выполнения операций доступа к базе данных, т.к. EJB-контейнер сделает это за вас. Однако, если вы по какой-либо причине меняете установленную по умолчанию персистенцию, управляемую контейнером, то вы должны использовать JDBC API. Также, если необходимо, чтобы сессионный компонент имел доступ к базе данных, требуется использование JDBC API.
JDBC API 2.0
JDBC API позволяет вызывать SQL-команды из методов языка программирования Java. JDBC API используется также в корпоративных компонентах при изменении установленной по умолчанию персистенции, управляемой контейнером, или при обращении к базе данных из сессионного компонента. При персистенции, управляемой контейнером, операции доступа к базе данных обрабатываются контейнером, т.е. реализация корпоративного компонента не содержит кода JDBC или SQL-команд. Также, возможно использование JDBC API в сервлете или JSP-странице для прямого доступа к базе данных, минуя корпоративный компонент.
JDBC API состоит из двух частей: интерфейса прикладного уровня, используемого компонентами приложения для доступа к базе данных, и интерфейса поставщика сервиса, используемого для подключения JDBC-драйвера к J2EE-платформе.
Технология Java Servlet 2.3
Технология Java Servlet позволяет определить классы сервлетов. Класс сервлета расширяет возможности серверов, доступные хост-приложениям при использовании ими модели программирования "запрос - ответ". Хотя сервлеты могут отвечать на запросы любого типа, они обычно используются в приложениях, поддерживаемых Web-серверами.
Технология JavaServer Pages 1.2
Технология JavaServer Pages позволяет встраивать фрагменты кода сервлета прямо в текстовые документы. JSP-страница представляет собой текстовый документ, который содержит два типа текста: статичные шаблонные данные, которые могут быть представлены в любом текстовом формате, таком как HTML, WML и XML, а также JSP-элементы, которые определяют способ построения динамичного содержимого страницы.
Java Message Service 1.0
JMS представляет собой стандарт обмена сообщениями, позволяющий компонентам J2EE-приложения создавать, посылать, принимать и читать сообщения. Он обеспечивает двустороннее, надежное, асинхронное распределенное соединение. Дополнительную информацию по JMS можно получить в руководстве по Java Message Service на
Java Naming and Directory Interface 1.2
JNDI обеспечивает функции имен и каталогов. Интерфейс предоставляет приложениям методы для стандартных операций с каталогами, таких как назначение атрибутов объектам и поиск объектов по их атрибутам. Используя JNDI, J2EE-приложение может сохранять и восстанавливать любые типы именованных Java-объектов.
Поскольку JNDI не зависит от какой бы то ни было специализированной реализации, приложения могут использовать JNDI для доступа к многочисленным сервисам имен и каталогов, включая такие сервисы, как LDAP, NDS, DNS и NIS. Это позволяет J2EE-приложениям сосуществовать с традиционными приложениями и системами. Дополнительную информацию по JNDI можно получить в онлайн-руководстве по JNDI на
Java Transaction API 1.0
Java Transaction API (JTA) обеспечивает стандартный интерфейс для разделенных транзакций. J2EE-архитектура обеспечивает автоматическую фиксацию транзакции по умолчанию для управления фиксацией и откатом транзакций. Автофиксация означает, что любые другие приложения, просматривающие данные, будут видеть обновленные данные после каждой операции чтения или записи в базу данных. Однако если приложение выполняет две отдельные операции доступа к базе данных, зависящие друг от друга, необходимо использовать JTA API для разграничения целостной транзакций, включающей обе операции, на начало, откат и фиксацию.
JavaMail API 1.2
Приложение J2EE может использовать JavaMail API для отправления e-mail сообщений. JavaMail API состоит из двух частей: интерфейса прикладного уровня, используемого компонентами приложения для отправления почты, и интерфейса поставщика сервиса. J2EE-платформа включает JavaMail вместе с поставщиком сервиса, что позволяет компонентам приложения отправлять Интернет-почту.
JavaBeans Activation Framework 1.0
JavaBeans Activation Framework (JAF) используется JavaMail. Он предоставляет стандартные сервисы для определения типа произвольных частей данных, инкапсулирует доступ к ним, разрешает операции над ними, и создает соответствующий JavaBeans-компонент для выполнения этих операций.
Java API for XML Processing 1.1
XML – это язык для представления текстовых данных таким образом, чтобы эти данные могли быть прочитаны и обработаны любой программой или инструментом. Программы и инструменты могут генерировать XML-документы, которые могут быть прочитаны и обработаны другими программами и инструментами. Java API for XML Processing (JAXP) поддерживает обработку XML-документов, используя DOM, SAX и XSLT. JAXP позволяет приложениям анализировать и преобразовывать XML-документы независимо от особенностей реализации XML-обработки.
Например, J2EE-приложение может использовать XML для построения отчетов. Различные компании, получив отчеты, могут обрабатывать данные, способом, наиболее соответствующим их требованиям. Одна компания может передать XML-данные в программу, преобразующую XML в HTML для публикации в Web. Другая компания может обработать XML-данные для создания презентации. Третья компания может прочитать XML-данные в свое J2EE-приложение для обработки.
J2EE Connector Architecture 1.0
J2EE Connector Architecture используется поставщиками J2EE-инструментов и системными интеграторами для создания адаптеров ресурсов, поддерживающих доступ к информационной системе предприятия. Эти адаптеры могут быть включены в любой J2EE-продукт. Адаптер ресурса - это программный компонент, позволяющий компонентам J2EE-приложения иметь доступ и взаимодействовать с базовым менеджером ресурсов. Т.к. адаптер ресурса специфичен для своего менеджера ресурсов, обычно существуют различные адаптеры для каждого типа базы данных или информационной системы предприятия.
Java Authentication and Authorization Service 1.0
Java Authentication and Authorization Service (JAAS) предоставляет возможность приложению J2EE аутентифицировать и авторизовывать определенного пользователя или группу пользователей.
JAAS – это Java-версия стандартной системы подключаемого модуля аутентификации PAM (Pluggable Authentication Module), которая расширяет архитектуру безопасности платформы Java 2 поддержкой пользовательской авторизации.
Упрощенная системная интеграция
Платформа J2EE – это платформо-независимое решение с полной системной интеграцией, создающее открытый рынок, где любой продавец может продать свой продукт любому покупателю. Этот рынок вынуждает продавцов соревноваться, пытаясь не ограничивать покупателей своей технологией, а превзойти друг друга, предоставляя продукты и сервисы, которые в большей степени удовлетворяют покупателей, имеют лучшую производительность, лучшие инструменты, лучшую поддержку.
Набор J2EE API обеспечивает системную интеграцию и интеграцию приложений при помощи:
Унифицированой прикладной модели на всех уровнях посредством корпоративных компонентов.
Упрощенного механизма запросов и ответов посредством JSP-страниц и сервлетов.
Надежной модели безопасности посредством JAAS.
Интеграции обмена XML-данными посредством JAXP.
Упрощенного взаимодействия систем посредством архитектуры J2EE-коннектора.
Простого взаимодействия с базой данных посредством JDBC API.
Интеграции корпоративных приложений посредством управляемых сообщениями компонентов и JMS, JTA и JNDI.
Вы можете узнать больше об использовании J2EE-платформы для построения интегрированных бизнес-систем, прочитав "J2EE-технология на практике" на
Инструменты
Реализация J2EE предоставляет средства размещения приложения и набор скриптов для компоновки, проверки и размещения J2EE-приложений, а также управления средой разработки и рабочим окружением. Смотрите приложение В, в котором содержится информация об инструментах.
Инструмент размещения приложения
J2EE-реализация предоставляет инструмент размещения приложения (deploytool) для компоновки, проверки и размещения J2EE-приложений. Существует две версии: командная строка и GUI.
GUI-версия включает мастера для:
Пакетирования, конфигурирования и размещения J2EE-приложений.
Пакетирования и конфигурирования корпоративных компонентов.
Пакетирования и конфигурирования Web-компонентов.
Пакетирования и конфигурирования клиентских приложений.
Пакетирования и конфигурирования адаптеров ресурсов.
Кроме того, информация о конфигурации может быть установлена для каждого типа компонента или модуля на закладке "inspector".
Скрипты
Таблица 1-1 содержит список скриптов, включенных в J2EE-реализацию и позволяющих выполнить действия из командной строки.
Таблица 1. J2EE-скрипты
| Скрипт | Описание |
|
Запуск и остановка J2EE-сервера |
|
|
Запуск и остановка базы данных по умолчанию |
|
|
Добавление JDBC-драйверов, JMS-назначений и мастеров соединений для различных ресурсов |
|
|
Создание общих и персональных ключей и генерация сертификата X509 |
|
|
Импорт файлов сертификата. Добавление и удаление J2EE пользователей из списка аутентификации и авторизации для J2EE-приложения |
|
|
Пакетирование компонентов J2EE-приложения в EAR, EJB JAR, JAR и WAR-файлы |
|
|
Проверка корректности EAR, EJB JAR, JAR и WAR-файлов и соответствия их J2EE-спецификации |
|
|
Запуск клиентского приложения J2EE |
|
|
Удаление всех размещенных приложений с J2EE-сервера |
(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-служб:
- Принятие HTTP как стандартного протокола, с помощью которого осуществляется доступ в интернет;
- Принятие 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
Предлагаю обсудить данную тему на
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 приложениях.
Спасибо за внимание!