(Jonathan Lurie и R. Jason Belanger)

Server-Side Java

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Java 2 Platform, Enterprise Edition

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

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

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

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

Microsoft"s .Net

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

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

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

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

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

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

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

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

.Net против J2EE

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторах

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

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

Ресурсы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обе платформы предоставляют специальную поддержку для разработки компонентов на двух уровнях: уровне интерфейса пользователя (WebUI) и уровне связи с данными.

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

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

• В J2EE компоненты EJB предназначены не только для представления данных приложения в виде объектов, но и для реализации его бизнес-логики, т.е. объектов предметной области и основных способов работы с ними.

  В.NET нет специально выделенного вида компонентов, предназначенного для реализации бизнес-логики - она может реализовываться с помощью обычных классов, что часто удобнее. Это положение должно измениться с выходом EJB 3.0.

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

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

Уровень бизнес-логики и модели данных в J2EE

В рамках приложений, построенных по технологии J2EE , связь с базой данных и бизнес-логику, скрытую от пользователя, принято реализовывать с помощью компонентов Enterprise JavaBeans . На момент написания этой лекции последней версией технологии EJB является версия 2.1, в первой половине 2006 года должны появиться инструменты для работы с EJB 3.0 (в рамках J2EE 5.0).

Возможны и другие способы реализации этих функций. Например, бизнес-логика может быть реализована непосредственно в методах объектов пользовательского интерфейса, а обмен данными с базой данных - через интерфейс JDBC . При этом, однако, теряется возможность переиспользования функций бизнес-логики в разных приложениях на основе единой базы данных , а также становится невозможным использование автоматических транзакций при работе с данными. Транзакции в этом случае нужно организовывать с помощью явных обращений к JTA (см. предыдущую лекцию).

Компонент Enterprise JavaBeans (EJB) является компонентом, представляющим в J2EE -приложении элемент данных или внутренней, невидимой для пользователя логики приложения. Для компонентов EJB определен жизненный цикл в рамках рабочего процесса приложения - набор состояний, через которые проходит один экземпляр такого компонента. Компоненты EJB работают внутри EJB-контейнера , являющегося для них компонентной средой . Функции EJB-контейнера следующие:

• Управление набором имеющихся EJB-компонентов , например, поддержкой пула компонентов для обеспечения большей производительности, а также жизненным циклом каждого отдельного компонента, в частности, его инициализацией и уничтожением.
• Передача вызовов между EJB-компонентами , а также их удаленных вызовов. Несколько EJB-контейнеров, работающих на разных машинах, обеспечивают взаимодействие наборов компонентов, управляемых каждым из них.
• Поддержка параллельной обработки запросов.
• Поддержка связи между EJB-компонентами и базой данных приложения и синхронизация их данных.
• Поддержка целостности данных приложения с помощью механизма транзакций.
• Защита приложения с помощью механизма ролей: передача прав ролей при вызовах между компонентами и проверка допустимости обращения в рамках роли к методам компонентов.

Для разработки набора компонентов EJB нужно, во-первых, для каждого компонента создать один или несколько классов и интерфейсов Java , обеспечивающих реализацию самой функциональности компонента и определение интерфейсов для удаленных обращений к нему, и, во-вторых, написать дескриптор развертывания - XML - файл , описывающий следующее:

• Набор EJB-компонентов приложения.
• Совокупность элементов кода на Java, образующих один компонент.
• Связь свойств компонента с полями таблиц БД и связями между таблицами.
• Набор ролей, правила доступа различных ролей к методам компонентов, правила передачи ролей при вызовах одними компонентами других.
• Политику компонентов и их методов по отношению к транзакциям.
• Набор ресурсов, которыми компоненты могут пользоваться в своей работе.

Правила создания

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

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

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

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

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

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

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

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

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

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

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

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

• Представление данных: В типичном Web приложении презентацией управляет браузер, запускаемый на клиентской машине.
• Динамическое создание представления данных: Несмотря на динамические возможности браузеров, для поддержки их различных типов, динамическая обработка, как правило, должна проводиться на Web серверах с использованием JSP и Servlet или XML (расширяемый язык разметки) и XSL (расширяемый язык таблиц стилей).
• Бизнес логика: Бизнес логика наиболее хорошо реализуется в Session EJB (будет описано позднее).
• Доступ к данным: Доступ к данным наиболее хорошо реализуется в Entity EJB (будет описано позднее) с использованием JDBC.
• Интеграция с прикладными серверными системами: Для интеграция с прикладными серверными системами могут использоваться различные технологии. Лучший выбор будет зависеть от точной природы этих систем.

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

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

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

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

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

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

Технологии J2EE

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

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

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

Java Database Connectivity (JDBC)

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

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

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

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

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

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

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

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

Import java.sql.*; public class JDBCExample { public static void main(String args) { try { Class.forName("COM.cloudscape.core.JDBCDriver"); Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook"); Statement stmt = conn.createStatement(); String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name"; ResultSet resultSet = stmt.executeQuery(sql); String name; String phone; while (resultSet.next()) { name = resultSet.getString(1).trim(); phone = resultSet.getString(2).trim(); System.out.println(name + ", " + phone); } } catch (Exception e) { // Handle exception here e.printStackTrace(); } } }

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

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

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

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

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

Java Naming and Directory Interface (JNDI)

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

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

Context ctx = new InitialContext();

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

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

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

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

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

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

Enterprise Java Beans (EJB)

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

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

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

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

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

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

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

JavaServer Pages (JSPs)

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

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

Date JSP sample

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

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

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

Java servlets

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

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

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

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

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

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

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

Remote Method Invocation (RMI)

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

Java IDL/CORBA

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

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

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

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

JavaMail и JavaBeans Activation Framework

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

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

Java Messaging Service (JMS)

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

Extensible Markup Language (XML)

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

Заключение

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

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

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

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

Об авторе

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

Ресурсы

Ресурсы JavaWorld

• "JDBC драйвера в чистом виде," Нитин Нанда (JavaWorld, Июль, 7, 2000) объясняет как устанавливать, использовать, и оценивать производительность JDBC драйверов 1, 2, 3, и 4 типа:
  http://www.javaworld.com/ jw-07-2000/jw-0707-jdbc.html
• "Обработка XML документов в Java с использованием XPath и XSLT," Андре Тост (JavaWorld, 8, Сентября, 2000):
  http://www.javaworld.com/javaworld/ jw-09-2000/jw-0908-xpath.html
• "Программирование XML в Java, Часть 1," Марк Джонсон (JavaWorld, Март, 2000) показывает, как использовать SAX для обработки XML документов в Java:

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

J2SE

java.util.Properties

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

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

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

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

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

J2EE-EJB3

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

< 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-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.lang.System:
String string = System.getProperty("myProperty1");

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

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

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

JMX

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

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

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

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

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

Сегодня множество людей пользуются всеми преимуществами Интернет. Общение, работа, разнообразные игры и приложения, создание сайтов и многое другое — все это можно найти в сети Интернет. Для создания различных приложений, используют языки программирования, из которых самый популярный — Java. С помощью него можно разрабатывать как программы (или игры) для телефонов, так и различные бизнес-системы и компоненты.

Одной из редакций Java — Java Enterprise Edition (J2EE), пользуются для создания различных корпоративных приложений. Применяют данную программную технологию для разработки приложений, а также необходимых компонентов для корпоративного использования. Результатом такого применения Java может стать биллинг-сервис, поисковая система или же Интернет-портал с различными функциональными возможностями (ERP, CRM, система управления проектами и т.д.), которые необходимы компании.

Основные преимущества Java:

• Высокая производительность. Приложение, созданное с использованием языка Java, будет эффективно и стабильно работать, при этом используя минимальное количество вычислительных ресурсов.
• Экономичность. Разработка необходимых приложений с помощью Java, происходит намного быстрее, чем с применением других языков программирования — это экономит Вам время, средства и ресурсы.
• Кроссплатформенность. Созданный продукт будет стабильно и без ошибок работать на самых разных операционных системах (Unix, Windows, Mac и т.д.).
• Кроссбраузерность. Приложение, написанное на Java, будет правильно отображаться в любом популярном браузере (Opera, Internet Explorer , Mozilla и др.).

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

Предоставляемые услуги

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

Направления разработки корпоративного ПО на J2EE:

• Разработка онлайн-систем
  для коллективной работы (Предприятие 2.0),
• Системы управления
  взаимоотношениями с клиентами (CRM),
• Разработка корпоративных
  информационных систем (ERP),
• Системы документооборота (СЭД),
• Автоматизация бизнес-процессов,
• Аналитические системы (OLAP),
• Корпоративные базы знаний,

• Корпоративные базы данных,
• Учёт рабочего времени,
• Управление задачами,
• Системы ip-телефонии,
• Управление заявками,
• Автоматизация продаж,
• Управление персоналом,
• Управление складом,
• Экспертные системы,
• Управление логистикой,

Применение языка Java

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

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

Технологические особенности

Java Enterprise Edition — в первую очередь ориентирован на крупные корпорации, которые стремятся создать единую, общую информационную сеть, биллинговую систему или какой-либо комплексный продукт.

Java EE (Java Platform, Enterprise Edition) — это набор различных спецификаций и необходимой документации для Java языка, который полностью описывает архитектуру серверной платформы для соответствующих задач крупных и средних предприятий. Данные спецификации настолько детализированы, что позволяют полностью обеспечить быстрый и качественный перенос необходимых приложений с одной платформы на другую. Также, спецификации обеспечивают целостность Ваших данных в процессе работы.

Java EE — включает следующие технологии:

• Сервлет (с javax.servlet и javax.servlet.http).
• Веб-сервис.
• Enterprise JavaBean (с javax.ejb.*).
• Java Server Pages.
• J2EE Connector.
• Интерфейс для обработки XML.
• Java Message Service (с javax.jms.*).
• Java Persistence API (с javax.persistence).
• Authorization Contract for Containers.
• JavaServer Faces (с javax.faces.component.html).

Сервер приложений

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

Он включает такие сервисы:

• JMS. Сервис по доставки различных сообщений между серверами и компонентами.
• Управление различными ресурсами (доступ к файловой системе, СУБД, почте и т.д.).
• EJB. Контейнер, поддерживающий авто синхронизацию объектов Java с базой данных.
• Безопасность и надежная защита всех данных.
• Поддержка различных транзакций и веб сервисов.

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

Сроки реализации оцениваются индивидуально для каждого проекта.

Услуга услуги разработки и программирования на Java EE (J2EE) доступна для заказа во всех регионах.

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

Если Вы хотите получить точную оценку стоимости и сроков реализации услуги "услуги разработки и программирования на Java EE (J2EE)" под Ваши задачи, либо желаете получить более подробную информацию по услуге, заполните форму заявки расположенную ниже и наши специалисты свяжутся с Вами.