Статьи

SOA «из коробки» без двухтурбинного двигателя

Просматривая мои последние два поста в этом блоге, я понял, что на самом деле я описывал некоторые из готовых действий JBoss SOA Platform специальным образом. Я подумал, что сейчас самое время сделать шаг назад и просмотреть полный набор готовых действий платформы.

Это заставило меня задуматься о том, насколько это полезно, когда инструмент работает «прямо из коробки», и насколько разочаровывающим оно может быть, когда оно не работает.

В своей книге «Дневник слабого малыша, последняя соломинка» [1]У автора Джеффа Кинни есть главный герой, одержимый тоской ученик средней школы Грег Хеффли, который находит в комиксе рекламу «личного судна на воздушной подушке». Грэг считает себя самым крутым ребенком в школе, если бы он мог получить свое собственное судно на воздушной подушке, поэтому он отсылает все свои накопленные деньги за один. Он, конечно, разочарован, когда он открывает коробку и находит не действующее личное судно на воздушной подушке, а план его постройки.

Первый шаг в плане гласит: «Приобретите промышленный двухтурбинный двигатель».

Платформа SOA, напротив, предоставляет обширный набор действий [2].эта работа прямо из коробки. Платформа SOA также поддерживает создание пользовательских действий, но, когда вы разрабатываете, как ваше приложение будет использовать Платформу, нужно начинать с готовых действий. Все они были протестированы, поэтому вы можете зависеть от результатов, которых они добьются, а также они были задокументированы и проиллюстрированы в быстрых примерах программ. (Что касается меня, я познакомился с платформой SOA и потратил несколько часов на создание действия, когда уже существовало готовое действие для той же задачи!)

Готовые действия, реализованные в платформе SOA, подразделяются на следующие функциональные группы:

  • Трансформаторы и преобразователи — преобразование данных сообщения из одной формы в другую
  • Управление бизнес-процессами — интеграция с JBoss jBPM
  • Сценарии — автоматизация задач на поддерживаемых языках сценариев
  • Услуги — интеграция с EJB
  • Маршрутизация — перемещение данных сообщения в правильные сервисы
  • Уведомитель — отправка данных в ESB неосведомленных адресатов
  • Webservices / SOAP — название говорит само за себя — поддержка веб-сервисов

(Существует также группа Разное, которая включает только одно действие — org.jboss.soa.esb.actions.SystemPrintln. Это действие печатает сообщение.)

Давайте кратко рассмотрим все эти действия, а затем более подробно рассмотрим пару из них.

Трансформаторы и преобразователи

Эти действия необходимы, чтобы позволить службам, которые ожидают, что данные в разных формах будут обмениваться данными друг с другом. То, что делают преобразователи и преобразователи, — это переводить полезные данные сообщений в различные формы. Остановимся на минуту и ​​рассмотрим содержимое сообщений, передаваемых через JBossESB в платформе SOA. Сообщения реализуют интерфейс org.jboss.soa.esb.message.Message. С точки зрения службы, данные в сообщении, другими словами, сообщение «полезная нагрузка», состоят из тела сообщения, вложений и свойств. Способом получения или установки полезной нагрузки сообщения по умолчанию является служебный класс MessagePayloadProxy. Этот класс важен, поскольку он предоставляет стандартный способ получения полезной нагрузки сообщения.

Действия в группе действий «Трансформаторы и преобразователи» (да, названия довольно понятны):

  • ByteArrayToString (org.jboss.soa.esb.actions.converters.ByteArrayToString) — это действие преобразует полезную нагрузку сообщения byte [] в строку Java
  • LongToDateConverter (org.jboss.soa.esb.actions.converters.LongToDateConverter) — и это действие преобразует полезную нагрузку длинных сообщений Java в java.util.Date
  • ObjectInvoke (org.jboss.soa.esb.actions.converters.ObjectInvoke) — с конвертером ObjectInvoke все становится немного интереснее. Это действие принимает сериализованный объект, который составляет всю полезную нагрузку Message, и передает его настроенному классу обработчика. Обработанные результаты становятся новым сообщением. Действие позволяет вам использовать ваши собственные POJO в качестве полезных данных сообщения.
  • ObjectToCSVString (org.jboss.soa.esb.actions.converters.ObjectToCSVString) — это действие преобразует сообщение в строку, разделенную запятыми, на основе предоставленного вами списка имен свойств.
  • ObjectToXStream (org.jboss.soa.esb.actions.converters.ObjectToXStream) — это действие аналогично действию ObjectInvoke, за исключением того, что оно преобразует объект в XML с помощью XStream [3] . Вы, наверное, уже догадались, что действие XStreamToObject преобразует XML в объект, используя XStream.
  • SmooksAction (org.jboss.soa.esb.smooks.SmooksAction) — это действие позволяет использовать мощный набор операций Smooks [4] на платформе SOA. Преобразования, вероятно, являются первым типом операций, о которых вы думаете в Smooks, но с SmooksAction вы также можете использовать операции Smooks, такие как разбиение и маршрутизация полезных нагрузок сообщений [5] . Мы подробнее рассмотрим это действие позже в этом посте. (Обратите внимание, что действие SmooksTransformer не рекомендуется в пользу действия SmooksAction.)
  • PersistAction (org.jboss.soa.esb.actions.MessagePersister) — это действие на самом деле не преобразует и не преобразует сообщение, оно записывает его в постоянное хранилище сообщений. Наиболее распространенное использование этого действия — это то, как сама платформа SOA записывает сообщения в очередь недоставленных сообщений (DLQ), но ее можно использовать в любой ситуации, когда вы хотите сохранить сообщение.

Управление бизнес-процессами

Эта группа действий содержит только одно готовое действие (org.jboss.soa.esb.services.jbpm.actions.BpmProcessor), но одно действие поддерживает интеграцию JBossESB — jBPM в платформе SOA. Эта интеграция позволяет вашим службам осуществлять вызовы в процесс jBPM через API команд jBPM. Из команд в командном API следующие (3) доступны для использования из ESB:

 

  • NewProcessInstanceCommand creates a new ProcessInstance using a process definition that has already been deployed to jBPM. The process instance is left in the start state so that tasks referenced by start node are executed.
  • StartProcessInstanceCommand is the same as NewProcessInstanceCommand, except that the process instance that is created is moved from the start position to the first node in the process graph.
  • As its name implies, CancelProcessInstanceCommand cancels a process instance.

Но это только часть интеграции JBossESB — jBPM. Интеграция также поддерживает оркестровку сервисов из процессов jBPM. Более полное описание интеграции см. По адресу
:
http://jboss-soa-p.blogspot.com/2009/06/hanging-together-on-soa-platform.html

Сценарии.

Эта группа действий позволяет вам создавать пользовательские действия, используя скриптовые языки. Начиная с версии 4.3 платформы SOA поддерживаются действия сценариев в Groovy и Bean Scripting Framework (BSF).

  • GroovyActionProcessor (org.jboss.soa.esb.actions.scripting.GroovyActionProcessor) — который использует скрипты Groovyscript
  • ScriptingAction (org.jboss.soa.esb.actions.scripting.ScriptingAction) — который использует Bean Scripting Framework и поддерживает сценарии BeanShell, Jython и JRuby

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

Услуги

В этой группе есть только одно действие, но оно очень важное.

  • Действие EJBProcessor (org.jboss.soa.esb.actions.EJBProcessor) принимает сообщение и использует его для поиска и вызова EJB. (Благодаря этому действию платформа SOA поддерживает как EJB2, так и EJB3.) Чтобы найти правильный EJB и вызвать правильный метод, вы указываете такую ​​информацию, как jndi-name, initial-context-factory, provider-url, имя метода и и другая конфигурация, специфичная для EJB как свойства сообщения

Маршрутизация

Одной из основных задач, которую выполняет JBoss ESB на платформе SOA, является маршрутизация сообщений к сервисам. (Помните, что в ESB все является либо сообщением, либо службой.) В предыдущем посте я описал, как использовать правила JBoss для выполнения маршрутизации на основе содержимого (CBR), где содержимое входящего сообщения определяет его маршрутизацию. Полный набор действий по маршрутизации:

  • Агрегатор (org.jboss.soa.esb.actions.Aggregator) — это интересный. Агрегатор, как указывает его имя, объединяет информацию вместе. Это действие позволяет объединить информацию из нескольких сообщений в одно сообщение. Действие Aggregator является реализацией шаблона интеграции Aggregator Enterprise [6] .
  • EchoRouter (org.jboss.soa.esb.actions.routing.EchoRouter) — In contrast, the EchoRuter just logs and returns the incoming message.
  • HttpRouter (org.jboss.soa.esb.actions.routing.HttpRouter) — The HttpRouter routes the incoming message to a URL that you specify in the action definition.
  • JMSRouter (org.jboss.soa.esb.actions.routing.JMSRouter) — This action routes the incoming message to JMS. For example, to a JMS queue where a service can then retrieve the message asynchronously. In order to find the correct JMS queue or topic, you specify values for properties such as jndi-name, initial-context-factory, and jndi-URL in the action definition.
  • ContentBasedRouter (org.jboss.soa.esb.actions.ContentBasedRouter) — I described content based routing with JBoss Rules in an earlier post to this blog http://jboss-soa-p.blogspot.com/2009/07/when-content-knows-way-content-based.html). Content based routing is a flexible approach to message routing in that the content in a message is actually the determining factor in determining the route a message takes.
  • StaticRouter (org.jboss.soa.esb.actions.StaticRouter) — As its name implies, this router establishes static routes that do not change based on the content of the messages or a set of routing rules.
  • StaticWiretap (org.jboss.soa.esb.actions.StaticWiretap) — Maybe it’s the comic book fan in me, but this is my favorite name for an action. There’s something film noir-ish about a «wiretap.» You can almost imagine Humphrey Bogart sitting it the back room of a bar listening in on a wiretapped SOA action. (On black and white film, of course.) In practice, it’s not all that exciting. This action implements the Enterprise Integration Pattern for a wiretap[7]. The goal of a wiretap is to inspect each message, without affecting the operation of the action chain. This can be a useful action to use to aid in debugging a service.

Уведомители

Так же, как прослушиватель шлюза, позволяет перемещать сообщения, не поддерживающие ESB (другими словами, сообщения в формате, отличном от (org.jboss.soa.esb.message.Message), в ESB платформы SOA, уведомители (org.jboss). soa.esb.actions.Notifier) ​​позволяет вам перемещать сообщения с поддержкой ESB из ESB в службы, не поддерживающие ESB. Уведомители преобразуют сообщения, поддерживающие ESB, в данные в форматы, понятные этим службам.

Следует иметь в виду, что конвейер действий состоит из двух этапов: сначала обычная обработка, а затем обработка результатов. Уведомители не выполняют никакой обработки сообщений на этом первом этапе. Они отправляют уведомления на втором этапе. Уведомление происходит после обработки конвейера действий. Это означает, что вы не можете использовать уведомители для изменения результатов какой-либо обработки действий. Данные, отправляемые уведомителем, являются сообщением ESB, которое обрабатывается конвейером действий. Платформа SOA поддерживает следующие цели уведомлений (имена не требуют пояснений):

  • NotifyConsole — печатает содержимое сообщения ESB в журнал сервера
  • NotifyFiles — печатает содержимое сообщения в файл или файлы
  • NotifySQLTable — Inserts the message contents into an existing database table
  • NotifyFTP — Prints the message contents to a file and then sends the file to a server via FTP
  • NotifyQueues and NotifyTopics — Writes the message contents into a JMS message and adds the JMS message to a specified JMS queue or topic
  • NotifyEmail — Sends the message contents in a mail message

Webservices/SOAP

When you’re considering web services and the SOA Platform, you actually have two separate goals to achieve; you want to be able to expose webservice endpoints as services and you also want to be able to invoke web services from actions defined in a service.

There are (3) out of the box actions that support web services:

  • SOAPProcessor (org.jboss.soa.esb.actions.soap.SOAPProcessor) — This action is only available for use on the SOA Platform embedded server. You use this action to expose webservice endpoints. To do this, you write a «service wrapper webservice» that conforms to the JSR 181[8] («Web Services Metadata for the Java Platform») standard. JSR 181 enables you to create webservices from a POJO by adding annotations such as @WebService and @WebMethod to it. This service wrapper webservice wraps calls to your service and exposes that service through JBossESB listeners. Your service can also be accessed through other transports (FTP, JMS, etc.) supported by the JBossESB in the SOA Platform. These 3 types of JBossWS webservice endpoints can be exposed through JBoss ESB listeners using this action:
    • Webservice bundled into a JBossESB .esb archive — When the webservice .war is bundled into a deployed .esb archive
    • Webservice bundled into an .ear — When the .war is bundled into a deployed .ear
    • Standalone webservice — When the webservice .war is deployed
  • WISE SOAPClient (org.jboss.soa.esb.actions.soap.wise.SOAPClient) — This action uses the WISE[9] client service (org.jboss.wise.core.client.WSService) to create a JAX-WS (Java API for XML Web Services) client class and then call the target service. WISE stands for «Wise Invokes Services Easily» and enables the dynamic generation of a client to access web services, without your having to write the code for the client. (This is referred to as «zero-code web service invocation»).
  • SOAPClient (org.jboss.soa.esb.actions.soap.SOAPClient) — это действие использует клиентскую службу soapUI (org.jboss.soa.esb.services.soapui.SoapUIClientService), чтобы создать сообщение, а затем направить его в целевой сервис.

Примеры

Мы уже рассмотрели, как использовать некоторые из готовых действий (Управление бизнес-процессами, Маршрутизация, Уведомители) в предыдущих публикациях в этом блоге. Теперь давайте рассмотрим некоторые примеры других типов готовых действий. Как всегда, программы «быстрого старта» в платформе SOA предоставляют пример кода.

преобразование

Мы начнем с рассмотрения трансформаций и действия Smooks из коробки. Но сначала давайте посмотрим на Smooks. Обычно Smooks называют движком трансформации, но это еще не все. Smooks — это действительно среда обработки более общего назначения, которая может работать с фрагментами сообщения. Smooks выполняет это с помощью «логики посетителя», где «посетитель» — это код Java, который выполняет определенное действие для определенного фрагмента сообщения. Это позволяет Smooks выполнять различные действия над разными фрагментами сообщений. Как указано в проекте Smooks
[10] :

Smooks поддерживает следующие типы обработки фрагментов сообщений:

  • Шаблонирование: Преобразование фрагментов сообщения с помощью XSLT или FreeMarker.
  • Java Binding: Bind message fragment data into Java objects
  • Splitting: Split messages fragments and rout the split fragments over multiple transports and destinations
  • Enrichment: «Enrich» message fragments with data from databases
  • Persistence: Persist message fragment data to databases
  • Validation: Perform basic or complex validation on message fragment data

Готовое действие SmooksAction платформы SOA предоставляет вам доступ ко всем этим возможностям Smooks.

Давайте рассмотрим очень простой пример, метко названный «transform_XML2XML_simple». Этот быстрый запуск выполняет преобразование сообщения путем применения XSLT (преобразования языка расширяемой таблицы стилей) к сообщению XML. Сообщение преобразуется в XML в другой форме. Интересные части файла быстрого запуска jboss-esb.xml:

25  <actions mep="OneWay">
26 <action name="print-before" class="org.jboss.soa.esb.actions.SystemPrintln">
27 <property name="message" value="[transform_XML2XML_simple] Message before transformation" />
28 </action>
29 <action name="simple-transform" class="org.jboss.soa.esb.smooks.SmooksAction">
30 <property name="smooksConfig" value="/smooks-res.xml" />
31 <property name="reportPath" value="/tmp/smooks_report.html" />
32 </action>
33 <action name="print-after" class="org.jboss.soa.esb.actions.SystemPrintln">
34 <property name="message" value="[transform_XML2XML_simple] Message after transformation" />
35 </action>

 

  • Line 25: This line is not specific to transformations, but it’s worth mentioning. «mep» stands for «message exchange pattern.» The pattern used by this quickstart is «one-way» in that the requester invokes a service (by sending it a message) and then does not wait for a response.
  • Lines 26-28, 33-35: These lines simply cause the message to be written to the server log before and after its transformation. (org.jboss.soa.esb.actions.SystemPrintln, is, incidentally, the only out-of-the-box action in the Miscellaneous action group.)
  • Line 29: Here’s where we specify that we want to invoke a SmooksAction
  • Line 30: And here is the XSLT that will be executed. We’ll examine this file in a moment.
  • Строка 31: эта строка на самом деле не в быстром старте. Я добавил свойство reportPath, чтобы мы могли просмотреть итоговый отчет. Обратите внимание, что для создания этого отчета требуются некоторые ресурсы обработки, поэтому его не следует использовать в производственных средах. Ниже приведены скриншоты этого отчета.

Теперь давайте посмотрим на smooks-res.xml:

1  <?xml version='1.0' encoding='UTF-8'?>
2 <smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.0.xsd">
3
4 <resource-config selector="OrderLine">
5 <resource type="xsl">
6 <![CDATA[<line-item>
7 <product><xsl:value-of select="./Product/@productId" /></product>
8 <price><xsl:value-of select="./Product/@price" /></price>
9 <quantity><xsl:value-of select="@quantity" /></quantity>
10 </line-item>]]>
11 </resource>
12 <param name="is-xslt-templatelet">true</param>
13 </resource-config>
14 </smooks-resource-list>
  • Line 2: The namespace referenced here is the Smooks XML Schema Definition
  • Line 4: The resource-config element corresponds to an org.milyn.cdr.SmooksResourceConfiguration object[11]
  • Lines 7-9: These XPath (XML Path Language) [12] statements locate the Product element’s productId and price attributes and the OrderLine element’s quantity attributes. XPath is used by XSLT to find or reference data in XML documents.

Когда вы запустите этот быстрый запуск, вы увидите сообщение XML, как определено в SampleOrder.xml, отображаемое до и после его преобразования XSLT.

Веб-сервисы

Еще одной важной особенностью платформы SOA является ее способность публиковать веб-сервисы как сервисы. Помните, как мы говорили о том, как JBossESB, включенный в платформу SOA, позволил развернуть конечные точки веб-службы в качестве конечных точек на ESB? Затем к сервисам также можно получить доступ через другие транспорты (FTP, JMS и т. Д.), Поддерживаемые JBossESB в платформе SOA.

Сначала мы рассмотрим быстрый запуск webservice_producer. Этот краткий обзор демонстрирует, как открыть конечную точку веб-службы JSR181 на JBossESB в платформе SOA с помощью действия org.jboss.soa.esb.actions.soap.SOAPProcessor.

Давайте начнем с рассмотрения этих строк в jboss-esb.xml:

37  <actions>
38 <action name="print-before" class="org.jboss.soa.esb.actions.SystemPrintln">
39 <property name="message"
40 value="[Quickstart_webservice_producer] BEFORE invoking jbossws endpoint"/>
41 </action>
42 <action name="JBossWSAdapter" class="org.jboss.soa.esb.actions.soap.SOAPProcessor">
43 <property name="jbossws-endpoint" value="GoodbyeWorldWS"/>
44 </action>
45 <action name="print-after" class="org.jboss.soa.esb.actions.SystemPrintln">
46 <property name="message"
47 value="[Quickstart_webservice_producer] AFTER invoking jbossws endpoint"/>
48 </action>
49 <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
50 </actions>

  • Lines 38 and 45: As we discussed earlier, the SystemPrintln action displays the message to the server.log
  • Lines 42,43: Here is where we invoke the SOAPProcessor action to generate the JSR181 web service from the specified class, GoodbyeWorldWS

17  @WebService(name = "GoodbyeWorldWS", targetNamespace="http://webservice_producer/goodbyeworld")
21 @WebMethod
22 public String sayGoodbye(@WebParam(name="message") String message) {
23
24 Message esbMessage = SOAPProcessor.getMessage();
25 if(esbMessage != null) {
26 System.out.println("**** SOAPRequest perhaps mediated by ESB:\n" + esbMessage.getBody().get());
28 }
29 System.out.println("Web Service Parameter - message=" + message);
30 return "... Ah Goodbye then!!!! - " + message;
31 }

(Remember how we talked about having to write a «service wrapper webservice» that conforms to the JSR 181 («Web Services Metadata for the Java Platform») standard? You do this by adding @WebService and @WebMethod annotations.)

  • Line 17: The definition of the web service.
  • Lines 24-31: The definition of the method in the web service to be invoked when the action is triggered.

The following lines in jboss-esb.xml are tangential to the goal of demonstrating exposing the webservice endpoint. But it is interesting as is shows some of the paths and protocols that can be used to inserting a message into the JBossESB withing the SOA Platform:

6   <providers>
7 <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
8 <jms-bus busid="quickstartGwChannel">
9 <jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_webservice_producer_gw"/>
10 </jms-bus>
11 <jms-bus busid="quickstartEsbChannel">
12 <jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_webservice_producer_esb"/>
13 </jms-bus>
14 </jms-provider>
15
16 <jbr-provider name="JBR-Http" protocol="http" host="localhost">
17 <jbr-bus busid="Http-1" port="8765" />
18 </jbr-provider>
19
20 <jbr-provider name="JBR-Socket" protocol="socket" host="localhost">
21 <jbr-bus busid="Socket-1" port="8888" />
22 </jbr-provider>
23 </providers>
30 <listeners>
31 <jms-listener name="JMS-Gateway" busidref="quickstartGwChannel" is-gateway="true"/>
32 <jbr-listener name="Http-Gateway" busidref="Http-1" is-gateway="true"/>
33 <jbr-listener name="Socket-Gateway" busidref="Socket-1" is-gateway="true"/>
34 <jms-listener name="JMS-ESBListener" busidref="quickstartEsbChannel"/>
35 </listeners>

The last quickstart we’ll look at is webservice_consumer1 — as you can guess by its name, this quickstart demonstrates how to access (or «consume») a JSR181 Web Service in an ESB action by using the org.jboss.soa.esb.actions.soap.SOAPClient action.

This quickstart requires that a web service be deployed for the SOAPClient to access. The webservice is very simple and is deployed in a .war. In HelloWorldWS.java we see the definition of the web service:

28  @WebService(name = "HelloWorld", targetNamespace = "http://webservice_consumer1/helloworld")
29 public class HelloWorldWS
30 {
31 @WebMethod
32 public String sayHello(@WebParam(name = "toWhom")
33 String toWhom)
34 {
35
36 String greeting = "Hello World Greeting for '" + toWhom + "' on " + new java.util.Date();
37
38 return greeting;
39
40 }
41 }

Pay attention to the «toWhome» parameter. We’ll look for this in the web service request.

In MyRequestAction.java, we see that toWhome parameter added as the key in a hashmap for the msg body:

44  /*
45 * Convert the message into a webservice request map.
46 */
47 public Message process(Message message) throws Exception
48 {
49 logHeader();
50 String msgBody = (String) message.getBody().get();
51 HashMap requestMap = new HashMap();
52
53 // add parameters to the web service request map
54 requestMap.put("sayHello.toWhom", msgBody);
55
56 // The "paramsLocation" property was set in jboss-esb.xml to
57 // "helloworld-request-parameters"
58 message.getBody().add(requestMap);
59 System.out.println("Request map is: " + requestMap.toString());
60
61 logFooter();
62 return message;
63 }

 

  • Строка 54 — параметр towhome, добавленный в качестве ключа в хэш-карту для тела сообщения. Ключом HashMap является выражение Object-Graph Navigation Language (OGNL) [13], которое идентифицирует параметр SOAP, который должен быть заполнен соответствующим значением ключа. OGNL — это язык выражений для получения и установки свойств объектов Java.

Затем MyResponseAction.java извлекает сообщение и отображает ответ — см. Строки 54-55:

44  /*
45 * Retrieve and output the webservice response.
46 */
47 public Message process(Message message) throws Exception
48 {
49
50 logHeader();
51
52 // The "responseLocation" property was set in jboss-esb.xml to
53 // "helloworld-response"
54 Map responseMsg = (Map) message.getBody().get(Body.DEFAULT_LOCATION);
55 System.out.println("Response Map is: " + responseMsg);
56
57 logFooter();
58 return message;
59 }

В jboss-esb.xml:

36  <actions mep="OneWay">
37 <action name="request-mapper"
38 class="org.jboss.soa.esb.samples.quickstart.webservice_consumer1.MyRequestAction">
39 </action>
40 <action name="soapui-client-action"
41 class="org.jboss.soa.esb.actions.soap.SOAPClient">
42 <property name="wsdl"
43 value="http://127.0.0.1:8080/Quickstart_webservice_consumer1/HelloWorldWS?wsdl" />
44 <property name="responseAsOgnlMap" value="true" />
45 <property name="SOAPAction" value="sayHello"/>
46 </action>
47 <action name="response-mapper"
48 class="org.jboss.soa.esb.samples.quickstart.webservice_consumer1.MyResponseAction">
49 </action>
50 <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
51 </actions>
  • Line 41: The SOAPClient class makes the call to the webservice. This is the «zero-code web service invocation» that we mentioned earlier in the post.
  • Line 43: The reference to the web service’s wsdl
  • Line 44: The parameter responseAsOgnlMap tells the JBossESB move the SOAP response data into that OGNL-based map and attach it to the message.
    Line 45: The reference to the method to be invoked in the web service.

Заключение Мысли

может быть сложной попыткой создать новое сервисное приложение с нуля. Сочетание готовых действий и быстрого запуска платформы SOA может значительно облегчить эту задачу. Даже без реактивного турбины. ?

Ресурсы

[1] Кинни, Джефф, «Дневник слабого малыша», «Последняя соломинка», книги «Амулет»; 1-е издание (январь 2009 г.), ISBN-10: 0810970686, ISBN-13: 978-0810970687

   [2]
http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/4.3.GA/html/Programmers_Guide/chap -SOA_ESB_Programmers_Guide-Out-of-the-box_Actions.html

   [3]
http://xstream.codehaus.org/

   [4]
http://www.smooks.org/mediawiki/index.php?title=Main_Page

   [5]
http://www.milyn.org/javadoc/v1.0/smooks/org/milyn/container/plugin/PayloadProcessor.html

   [6]
http://www.enterpriseintegrationpatterns.com/Aggregator.htmlШаблоны, описанные на этом сайте и в соответствующей книге, были созданы, чтобы помочь дизайнерам и разработчикам в создании программных решений для предприятий. Шаблоны не зависят от платформы и языка, поэтому они могут быть очень полезны во многих системах.

  [7]
http://www.enterpriseintegrationpatterns.com/WireTap.html

  [8]
http://jcp.org/en/jsr/summary?id=181

  [9]
http://jboss.org/wise

  [10 ]
http://www.smooks.org/mediawiki/index.php?title=Why_Smooks_was_Created

  [11]
http://www.milyn.org/javadoc/v1.0/smooks/org/milyn/cdr/SmooksResourceConfiguration.html

  [12]
http://www.w3.org/TR/xpath

  [13]
http://www.opensymphony.com/ognl/

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

Как всегда, я хотел бы поблагодарить участников проекта SOA Platform за их помощь и своевременные комментарии! Кроме того, этот пост в значительной степени опирается на обширные документы по платформе SOA и краткие обзоры.