При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Вся введенная информация защищена.

My developerWorks:

Сообщения:

Выйти

Выбрать язык:

Сторонник EJB: SOA представляет собой новый этап в развитии приложений на базе компонентов

Джефф Хэмбрик, инженер, IBM

Джефф Хэмбрик (Geoff Hambrick) является ведущим консультантом IBM Software Services для группы обеспечения WebSphere (WebSphere Enablement Team). Он живет в Раунд Рок, Техас (недалеко от Остина). Общей задачей группы обеспечения является поддержка предпродажных процессов, которая осуществляется с помощью подробного технического инструктажа и кратковременных совещаний по проверке концепций. За свою работу по созданию и распространению передового опыта для разработки приложений J2EE на базе IBM WebSphere Application Server в марте 2004 года Джефф был удостоен звания инженера с отличием IBM (IBM Distinguished Engineer).

Описание: Каким-то образом ситуация переменилась! В этом месяце Сторонник EJB (EJB Advocate) находится на позициях защиты спецификаций, связанных с SOA. Это, например, сервисно-компонентная архитектура (SCA - Service Component Architecture), поскольку она связана с Enterprise JavaBeans™.

Пометить это!

Дата: 15.02.2007
Уровень сложности: средний
Активность: 1429 просмотров
Комментарии:

Из IBM WebSphere Developer Technical Journal.

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

Что действительно нового в SOA?

Уважаемый Сторонник EJB,

я слегка смущен всей этой шумихой вокруг сервис-ориентированной архитектуры (SOA - Service Oriented Architecture). И вы, похоже, тоже этим увлечены.

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

Для тех из нас, кто имеет опыт создания успешных приложений с применением таких распределенных объектных технологий, как CORBA и Enterprise JavaBeans, описанные принципы не представляют собой ничего нового. Я полагаю, что мы всегда были "сервис-ориентированными".

Я допускаю, что из названия "сервис-ориентированной" архитектуры получился лучший акроним, чем из названия "распределенно-объектной" архитектуры. Но, помимо этого, у меня есть серьезный вопрос: есть ли что-то новое в SOA? В частности, почему мне нужно обращать внимание на новые спецификации Service Component Architecture и Service Data Objects, когда я могу сделать все с помощью компонентов Enterprise JavaBean?

Подписано,
Что Такое SOA

В начало

SCA представляет собой естественную эволюцию на стороне сервера

Уважаемый Что Такое SOA!

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

Напомню, что Java-сервлеты были представлены как стандартный Java-компонент для унификации закрытых Java API, связанных с отдельными Web-серверами. Например, для®Internet Server API (ISAPI) компании Microsoft. Java-сервлеты позволили программистам на Java генерировать динамические Web-страницы, которые можно было использовать с более широким диапазоном Web-серверов различных производителей.

Наиболее часто используемым компонентом является HttpServlets, который берет на себя все подробности сопоставления входных данных из потока HTTP-запросов и выходных данных в потоке HTTP-ответов. Это освобождает программиста и позволяет ему сосредоточиться на логике работы приложения.

Как бы хорошо это ни выглядело, пользователи скоро нашли генерацию HTML в Java-коде утомительной. Например, вот фрагмент метода HttpServlet doGet() для генерации простой динамической страницы с сообщением "Hello world":

String name = request.getAttribute("name");
PrintWriter pw = request.getPrintWriter();
pw.println("<HTML>");
pw.println("<BODY>");
pw.println("<P>Hello " + name + "!</P>");
pw.println("</BODY>");
pw.println("</HTML>");

Быстро начали развиваться различные "шаблонные" языки. Это позволило встраивать Java-код в HTML, что сделало модель программирования более похожей на WYSIWYG (то есть декларативной). Стандартизация этих подходов привела к спецификации Java Server Page (JSP). Благодаря JSP можно смешивать с HTML такие элементы Java, как "скриптлет" (<%...%>) и "выражение" (<%=…%>). Например, вот фрагмент JSP для отображения того же сообщения "Hello world":

<% String name = request.getAttribute("name"); %>
<HTML>
<BODY>
<P>Hello <%=name%>!</P>
</BODY>
</HTML>"

Одно только исключение скобок, кавычек и точек с запятой уберегло программистов Web-приложений от несметного количества ошибок. Более того, устранение необходимости компиляции, упаковки и распространения компонента HttpServlet значительно сократило время, необходимое для внесения изменений в случае исправления ошибки или другой необходимости.

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

Примерно в то же время отдельно появилась спецификация Enterprise JavaBeans, призванная еще больше разделить эти функции. Добавление компонентов EJB позволило реализовать для Web-приложений истинную архитектуру Model-View-Controller. В этой архитектуре модель (Model) была инкапсулирована с помощью компонентов EJB, представление (View) было инкапсулировано с помощью JSP, а контроллер (Controller) был инкапсулирован с помощью HttpServlets.

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

<% 
   OrderStatus orderStatus = (OrderStatus)request.getAttribute(
	"OrderStatus"
   );
   OrderData d[] = orderStatus.orders;
   int orderID = 0;
   String status = null;
   for (int i=0 ; i < d.length; i++)
   {
      orderID = d[i].orderID;
      status = d[i].status;
%>
<P>Order Id =<%=orderID%> Status =<%=status%></P>
<% } %>

Скриптлет для начала цикла довольно сложен. Скриптлет для его окончания простой, но его часто забывают (или помещают в неверное место). Не существует никаких средств для обнаружения этих и других частых ошибок в процессе редактирования JSP (подобно тому, что случается в Java IDE для "чистых" HttpServlets).

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

Возникла идея специальных тегов JSP. Это было стандартизовано с целью минимизации или даже полного исключения потребности в программировании на Java. Например, подразделение IBM Software Services for WebSphere разработало некоторые специальные теги, которые обеспечивали итерацию во вложенной структуре. Эти теги работали с тегами USEBEAN и GETPROPERTY, которые предоставляются как часть базовой библиотеки тегов JSP, что значительно упрощает логику. Ниже приведен пример:

<JSP:USEBEAN 
  ID="OrderStatus"
  CLASS="com.onlinemall.data.OrderStatusData"
  SCOPE="request"/>
<SW296:INDEXEDBEANPROPERTY 
   BEAN="OrderStatus" 
   PROPERTY="orders" 
   VAR="order" 
   TYPE="com.onlinemall.data.OrderData">
<P>Order ID=<JSP:GETPROPERTY NAME="order" 
   PROPERTY="orderID"/>
Status=<JSP:GETPROPERTY NAME="order" 
   PROPERTY="status"/></P>
</SW296:INDEXEDBEANPROPERTY>

Это было незадолго до того, как для исключения необходимости писать HttpServlets появились такие среды, как Struts. Struts включает в себя богатый набор специальных тегов для работы с формами, а также концепцию под названием "tiles" ("мозаика"), которая обеспечивает построение декларативных страниц. Важной функцией шаблонов "tiles" является возможность легко перестроить страницу, не меняя лежащие в ее основе компоненты кода. Среда Struts была одной из вдохновляющих идей для технологии Java Server Faces (JSF), которая стандартизует концепцию сборки декларативного интерфейса пользователя из компонентов. Подробное сравнение JSF и Struts см. в прекрасной статье Роланда Барсиа (Roland Barcia).

Эволюция на стороне клиента от Java-сервлетов и JSP к средам специальных тегов и JSF была последовательным уходом от процедурно программируемых компонентов, которые должны компилироваться, к декларативно собираемым, которые можно интерпретировать (или, по крайней мере, компилировать в период исполнения). Сервисно-компонентную архитектуру (SCA - Service Component Architecture) можно рассматривать в качестве схожей эволюции по обеспечению декларативной сборки серверных компонентов в приложение.

Полагаю, вы уже видели некоторые другие статьи developerWorks по технологиям Service Component Architecture и Service Data Objects. Если да, то, вероятно, видели диаграмму, подобную этой, которая показывает компонент SCA:

Рисунок 1. Пример компонента SCA

Есть три важных параметра сравнения SCA и EJB, которые нужно запомнить.

Композиция. Для EJB единственным языком реализации является Java, поэтому вся композиция служб в более крупную сборку осуществляется процедурно с помощью Java. SCA поддерживает в качестве языка реализации не только Java, но и исполняемый язык бизнес-процессов (BPEL - Business Process Execution Language), который расширяется для работы с такими концепциями, как машины состояния, бизнес-правила, человеческие задачи и др.;
Вызов. Способ, которым используется сессионный компонент, не имеющий состояния (Stateless Session Bean) отличается от того, как используется компонент с состоянием (Stateful Session Bean), компонент управления данными (Entity Bean), home-метод для специального объекта (Custom Entity Home Method) или управляемый сообщениями компонент (Message Driven Bean). Точнее, для каждого типа компонентов есть свой способ нахождения и вызова его методов. Компоненты SCA обеспечивают для клиента общую модель вызова, независимо от типа реализации;
Данные. Компоненты управления данными EJB никогда не предназначались для упорядочивания и эффективного использования вне области действия контейнера или границ транзакции. Для заполнения этого пробела и появились объекты передачи данных (Data Transfer Objects). Компоненты SDO обеспечивают общую абстракцию для потока данных, независимо от области действия.

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

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

До свидания,
Ваш Сторонник EJB

В начало

Повторят ли компоненты EJB судьбу динозавров?

Уважаемый Сторонник EJB,

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

Напишите мне,
Сбитый С Толку SOA

В начало

Компоненты EJB похожи на ДНК: кирпичики эволюции

Уважаемый Сбитый С Толку SOA,

важными словами в моем заключении были "в конце концов" и "минимальной".

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

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

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

Надеюсь, после этого вы сможете подписаться "Счастлив с SOA"!

До свидания,
Ваш Сторонник EJB

Ресурсы