Разработка на основе шаблонов с Mule 2.0

Помимо использования корпоративных интеграционных шаблонов, поток запросов на рисунке 3 также показывает четкое разделение между различными логическими границами интеграционного решения. Конечно, ESB показан как логическая граница, но также брокер сообщений (поставщик JMS), веб-сайт и конечные точки страховых компаний разделены в разных границах. Также обратите внимание, что на рисунке 3 показан только поток запросов решения по изучению страхового случая. Чтобы сохранить дизайн чистым и понятным, часто лучше разделять потоки запросов и ответов в разных схемах проектирования. На рисунке 4 показан ответ интеграционного решения страхового брокера.

[Img_assist | NID = 3188 | название = | убывание = | ссылка = нет | Align = нет | ширина = 432 | Высота = 413]

Рисунок 4 На этом рисунке показан поток ответов решения по интеграции страхования, описанного с использованием шаблонов интеграции предприятия из книги EIP.

Схема проектирования потока ответов, показанная на рисунке 4, содержит множество шаблонов, которые уже использовались при разработке потока запросов, здесь только шаблон агрегатора. Агрегатор используется для объединения сообщений о страховых ответах от страховых компаний BudgetCar и LuxuryCar в один ответ, который можно отобразить на веб-сайте EasyInsurance. Чтобы иметь возможность агрегировать ответные сообщения от двух компаний по страхованию автомобилей, нам нужен какой-то корреляционный идентификатор, который связывает эти ответные сообщения с исходным сообщением запроса на страхование. В этом примере мы используем идентификатор запроса в сообщении запроса страховки, которое также доступно в сообщении страхового ответа.

Это вводит еще один важный шаг на этапе разработки интеграционного решения: дизайн сообщения. Поскольку Mule также может использовать объекты Java в качестве типа полезной нагрузки сообщений, мы будем использовать сообщения на основе Java для связи между веб-сайтом EasyInsurance и брокером JMS и Enterprise Service Bus. В листинге 3 показаны элементы трех типов сообщений, задействованных в этом интеграционном решении.

Листинг 3. Обзор классов Java, представляющих запросы на страхование и ответные сообщения, используемые в реализации брокера интеграции.

public class CarInsuranceRequest implements Serializable {
  
  private String requestID;
  private String numberPlate;
  private String carType;
  private int buildYear;
  private boolean companyCar;
  private Date startDate;
}

public class TravelInsuranceRequest implements Serializable {
  
  private String requestID;
  private String destinationCountry;
  private int numberOfPersons;
  private Date startDate;
  private Date endDate;
}

public class InsuranceResponse implements Serializable {
  private String requestID;
  private String responseID;
  private String insuranceCompanyName;
  private float price;
}

Как видно из листинга 3, в этом примере сообщения хранятся очень просто. Важными частями проекта сообщения для интеграционного решения являются различие между CarInsuranceRequest и TravelInsuranceRequest, которое используется для маршрутизации на основе содержимого, и атрибутом requestID, который будет использоваться для агрегирования сообщений с ответами на страхование автомобиля.

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

Реализация страхового брокера с мулом: часть запроса

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

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

Листинг 4. Чтение из очереди JMS и использование основанного на контенте маршрутизатора для определения следующего пункта назначения

<!--omitted the Mule namespaces -->
<mule>
  <jms:activemq-connector name="jmsCon" brokerURL="tcp://localhost:61616"/>

  <model name=”InsuranceModel”> 
    <service name="JMSInService">
      <inbound>
	   <jms:inbound-endpoint queue="insurance.in" />
      </inbound>
	 <outbound>
        <forwarding-catch-all-strategy>
          <jms:outbound-endpoint queue="insurance.invalid"/>
        </forwarding-catch-all-strategy>
        <filtering-router>
          <vm:outbound-endpoint path="car.insurances"/>
          <expression-filter evaluator="payload-type" 
                    expression="dzone.mule.model.CarInsuranceRequest"/>
        </filtering-router>
        <filtering-router>
          <vm:outbound-endpoint path="travel.insurances"/>
          <expression-filter evaluator="payload-type" 
                    expression="dzone.mule.model.TravelInsuranceRequest"/>
        </filtering-router>
      </outbound>
   </service>
  </model>
</mule>

В листинге 4 вы можете увидеть один сервис mule и конфигурацию подключения к activeMQ. Входящая часть этого сервиса mule читает сообщения из очереди jms с именем «insurance.in» и использует соединитель для activeMQ, поскольку это единственный указанный нами соединитель.

После прочтения сообщения из очереди оно обрабатывается исходящими маршрутизаторами. В этом случае мы проверяем класс запроса, используя фильтр выражений типа полезной нагрузки. Если фильтр соответствует, запрос отправляется на указанную внутреннюю (VM) конечную точку. Если ни один из фильтров не совпадает, сообщение отправляется в очередь «Insurance-invalid», которая в нашем сценарии служит очередью недействительных сообщений.

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

Давайте сначала посмотрим, как вызвать две страховые компании. Если вы посмотрите на рисунок 3, вы увидите, что мы хотим использовать для этого файл и JMS. В листинге 5 показана конфигурация этого сервиса и необходимые трансформаторы. Обратите внимание, что мы разделили конфигурацию Mule, чтобы объяснить ее порциями, но вся конфигурация Mule, показанная в этой статье, реализована в одной конфигурации Mule, файле insurance-config.xml.

Листинг 5. Отправьте запрос на страхование автомобиля в две службы страхования автомобилей.

<mule>	
  <jms:object-to-jmsmessage-transformer name="ObjectToJMS"/>
  <xm:object-to-xml-transformer name="InsuranceToXML"/>
  <xm:xml-to-object-transformer name="XMLToInsurance"/>
  <custom-transformer name="InsuranceToCSV" 
       class="dzone.mule.transformer.CSVTransformer"/>

  <!-- repeated the model element to make it comprehensible -->
  <model name=”InsuranceModel”>
    <service name="SendCarInsurancesService">
      <inbound>
        <vm:inbound-endpoint path="car.insurances"/>
	  </inbound>
	  <outbound>
        <multicasting-router>
          <file:outbound-endpoint path="budgetCarIn" 
              outputPattern="${DATE:HH-mm-ss}-carinsurance.csv">
            <transformer ref="InsuranceToCSV"/>
          </file:outbound-endpoint>
          <jms:outbound-endpoint queue="luxurycar.send">
            <transformer ref="InsuranceToXML"/>
            <transformer ref="ObjectToJMS"/>
          </jms:outbound-endpoint>
        </multicasting-router>
      </outbound>
	</service>
  </model>
</mule>

В листинге 5. вы можете видеть, что мы сначала настроили нужные нам трансформаторы. В начале этой статьи мы упоминали, что компания BudgetCar требовала, чтобы сообщение было в формате CSV, а компания LuxuryCar требовала XML. Для этого мы создали специальный преобразователь, который принимает java CarInsuranceRequest и преобразует содержимое в CSV. Этот преобразователь показан в листинге 6.

Листинг 6. Пользовательский преобразователь для преобразования CarInsuranceRequest в строку CSV.

public class CSVTransformer extends AbstractTransformer {

  protected Object doTransform(Object payload, String encoding) 
          throws TransformerException {
    if(!(payload instanceof CarInsuranceRequest)) {
      throw new TransformerException(this, new IllegalArgumentException(
              "only car insurance requests can be transformed"));
    }
    CarInsuranceRequest request = (CarInsuranceRequest) payload;
    return new StringBuffer()
       .append(request.getRequestID())
	  .append(",")
	  .append(request.getNumberPlate())
	  .append(",")
	  .append(request.getCarType())
	  .append(",")
	  .append(request.getBuildYear())
	  .append(",")
	  .append(request.getStartDate())
	  .toString();
  }
}

Для budgetCar insuranceCompany это означает, что при конфигурации из листинга 5. входящее java-сообщение преобразуется в CVS, а затем отправляется в каталог файловой системы.

Для компании LuxuryCar Insurance нам необходимо преобразовать сообщение в XML. Для этого мы просто использовали стандартные трансформаторы, которые предоставляет мул. Это будет проверять Java-бин и использовать его для создания XML-сообщения. Последнее, что мы делаем перед тем, как отправить сообщение в очередь JMS, — это убедитесь, что сообщение является объектом JMSObject. Если мы не используем преобразователь XML, нам не нужно предпринимать этот последний шаг, поскольку тогда Мул будет использовать преобразователь по умолчанию JMS для преобразования сообщения в объект JMSObject. Но так как мы определили преобразователи в конечной точке, мы переопределяем конфигурацию по умолчанию, поэтому нам нужно также явно добавить преобразователь ObjectToJMS.

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

Листинг 7. Мул-конфигурация, которая вызывает веб-сервис

<service name="travelService">
  <inbound>
    <vm:inbound-endpoint path="travel.insurances"/>
  </inbound>
  <outbound>
    <chaining-router>
      <outbound-endpoint
        address="wsdl-cxf:http://localhost:8080/services/TravelInsuranceService?
                wsdl&method=getTravelInsurance">
       <custom-transformer
         class="dzone.mule.custom.TravelRequestToWebserviceRequestTransformer"/>
	  <properties>
         <spring:entry key="service"	 
 	      value="{http://dzone.com/travelInsurance}TravelInsuranceServiceImplService">
         </spring:entry>
	    <spring:entry key="port"								 
           value="{http://dzone.com/travelInsurance}TravelInsuranceServiceImplPort">
         </spring:entry>
       </properties>
      </outbound-endpoint>
      <jms:outbound-endpoint queue="insurance.out">
        <transformer ref="WSToResponseTransformer"/>
        <transformer ref="ObjectToJMS"/>
      </jms:outbound-endpoint>
    </chaining-router>
   </outbound>
</service>

В конфигурации из листинга 7 видно, что мы снова создали сервис Mule. Эта служба прослушивает внутреннюю конечную точку vm «travel.insurances», на которую запросы на страхование путешествий маршрутизируются маршрутизатором из листинга 4. Когда здесь получено сообщение, выполняется исходящая часть этой службы. В этом случае мы использовали chaining-router. Этот маршрутизатор сначала вызовет первую указанную исходящую конечную точку и будет использовать результат вызова этой конечной точки в качестве параметра для следующей конечной точки. Поэтому в этом случае мы сначала вызываем веб-сервис, а затем отправляем результат этого вызова веб-сервиса в указанную конечную точку JMS, где веб-сайт прослушивает. Для вызова webservice мы делаем вызов на основе указанного файла WSDL.Кроме того, мы также настраиваем службу и порт из того WSDL, который мы хотим вызвать. Последнее, что нам нужно настроить, — это метод, который мы хотим вызвать. Мы сделали это как атрибут адреса исходящей конечной точки. Мы не будем вдаваться в подробности того, как был создан веб-сервис и т. Д. Если вы заинтересованы в коде, см. Раздел ресурсов в нижней части этой статьи, где вы можете скачать все источники и ресурсы этого сценария.

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

Теперь давайте посмотрим, как мы можем реализовать ответы компаний автострахования.

Реализация страхового брокера с Mule: ответная часть

Для завершения ответной части нам нужно только получить ответы от двух компаний по страхованию автомобилей, собрать их и отправить обратно в очередь, которую прослушивает веб-сайт. Как мы уже упоминали, компания BudgetCar работает с файлами CSV через соединение file / ftp, а LuxuryCar использует XML через очередь JMS. Таким образом, помимо агрегации нам нужно преобразовать входящие ответы в объекты Java.

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

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

<service name="ReceiveCarResponseService">
  <inbound>
    <jms:inbound-endpoint queue="luxurycar.receive">
      <transformer ref="JMSToObject"/>
      <transformer ref="XMLToInsurance"/>
      <transformer ref="CorrelationTransformer" />
    </jms:inbound-endpoint>
    <file:inbound-endpoint path="budgetCarOut">
      <file:file-to-string-transformer />
      <transformer ref="CSVToResponse" />
      <transformer ref="CorrelationTransformer" />
    </file:inbound-endpoint>
  </inbound>
  <outbound>
    <outbound-pass-through-router>
      <vm:outbound-endpoint path="aggregator.in" />
    </outbound-pass-through-router>
  </outbound>
</service>

В листинге 8 вы видите службу, которая прослушивает две входящие конечные точки. Конечная точка jms получает сообщения от страховой компании класса люкс, а конечная точка файла — от бюджетной. Для обоих полученных сообщений мы делаем пару преобразований. Для роскошных ответов мы сначала создаем объект java из объекта JMS (помните, что мы переопределили поведение по умолчанию, поэтому мы должны явным образом преобразовать из JMS в объект), а так как объект является XML, мы преобразуем XML в java объект страхования. Для бюджетных сообщений мы делаем то же самое, только на этот раз мы получаем файл CSV, который необходимо преобразовать.

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

Листинг 9. Корреляционный преобразователь, который устанавливает свойства корреляции Мула

public class ResponseCorrelationTransformer 
        extends AbstractMessageAwareTransformer {

	@Override
	public Object transform(MuleMessage message, String outputEncoding)
			throws TransformerException {
		message.setCorrelationGroupSize(2);
		Object obj = message.getPayload();
		InsuranceResponse response = (InsuranceResponse) message.getPayload();
		String requestID = response.getRequestID();
		message.setCorrelationId(requestID);
		return message;
	}
}

Как видно из листинга 9, мы получаем requestID из сообщения и устанавливаем Mule correlationID для этого requestID. В то же время мы также установили, что при получении двух ответов с этим идентификатором мы закончили корреляцию. Это устанавливается через свойство correlationGroupSize в сообщении.
Таким образом, всякий раз, когда получен ответ, этот преобразователь удостоверится, что вышеупомянутые свойства установлены. Теперь, почему мы это сделали?

Ну, мы сделали это, чтобы мы могли использовать стандартный агрегатор Mule для агрегирования сообщений для нас. Это показано в листинге 10.

Листинг 10. Конфигурация агрегатора мулов

<service name="insuranceAggregator">
  <inbound>
    <vm:inbound-endpoint path="aggregator.in" />
    <collection-aggregator-router />
  </inbound>
  <outbound>
    <outbound-pass-through-router>
      <jms:outbound-endpoint queue="insurance.out" />
    </outbound-pass-through-router>
  </outbound>
</service>

Этот небольшой фрагмент кода из листинга 10 является полной конфигурацией агрегатора. Мы говорим mule для прослушивания внутренней конечной точки, на которую отправляются ответы (см. Листинг 7). После получения сообщения оно будет передано маршрутизатору-агрегатору. Этот стандартный компонент mule использует два свойства, которые мы установили в листинге 9. Поэтому, когда первое сообщение получено, этот агрегатор проверит ожидаемый размер (в нашем случае 2) и requestID. Затем он проверит, сколько сообщений с этим ID он уже получил. Поскольку это первый, агрегатор будет просто ждать. Для второго сообщения те же шаги повторяются. Но так как у нас теперь есть оба наших сообщения, агрегатор помещает их в список и передает их на исходящий маршрутизатор.
Этот исходящий маршрутизатор просто отправляет агрегированные данные в настроенную конечную точку, которая является очередью JMS.

И это все для ответной части!

Реализация страхового брокера с мулом: резюме

Давайте быстро подведем итоги того, что мы сделали. Для части запроса мы получили сообщения через JMS. В зависимости от типа полученного сообщения мы использовали маршрутизатор на основе содержимого, чтобы определить, куда отправить сообщение. Если в сообщении содержался запрос на страхование путешествий, сообщение отправлялось на веб-службу туристического агентства. Если запрос был запросом автострахования, сообщение было отправлено двум страховым компаниям.
Мы также применили несколько шагов преобразования к сообщениям. Мы использовали пару встроенных трансформаторов Mule, но и сами создали пару трансформаторов. Это было необходимо, поскольку наши компании по страхованию автомобилей запрашивали информацию не так, как мы использовали ее внутри страны.
Ответ от веб-службы путешествий был отправлен обратно в очередь ответов, которую прослушивал веб-сайт. Однако ответы от компаний по страхованию автомобилей были агрегированы на основе их requestID. Для этого мы использовали стандартный агрегатор сбора Mule и преобразователь, чтобы установить правильные свойства сообщения.

Если вы хотите проверить это, скачайте исходники этой статьи. Он также содержит небольшой тест JUnit, который можно использовать для имитации веб-сайта и запуска решения по интеграции. Имейте в виду, что вам нужно будет загрузить ActiveMQ отдельно, чтобы весь пример работал.

Вывод

In this article we’ve shown how you can implement an integration design with Mule. We’ve first shown you a general description of the problem we faced, and how you can use EIPs to describe this problem in a technology independent manner. We’ve also shown how easy it is with Mule to implement this example. As you’ve seen the Mule configuration is pretty much a one-on-one copy of figure 3 and figure 4. Mule uses the same terminology as is used for the EIPs which makes implementing these scenarios easy. An additional advantage is that the Mule configuration is very readable and self-explaining.

We hope you enjoyed this first introduction into Mule 2.0 and in the pattern based integration development approach. In a couple of weeks we’ll also show how to implement this same scenario using Java Business Integration (JBI) with Apache ServiceMix.

Дополнительные ресурсы

1. Мул — http://mule.mulesource.org
2. Мул 2.x против Мула 1.x — http://mule.mulesource.org/display/MULE2INTRO/Whats+New+in+Mule+2.0
3. Шаблоны корпоративной интеграции — http://www.enterpriseintegrationpatterns.com
4. Загрузка Mule 2.0.1 — http://mule.mulesource.org/display/MULE/Download
5. Загрузка исходного кода статьи — http: //www.esbinaction .com / файлы / dzonemule.zip

Йос Дирксен

Йос — архитектор программного обеспечения, работающий в Atos Origin и специализирующийся на интеграции предприятий. Джос является соавтором будущей книги Мэннинга «ESB с открытым исходным кодом в действии» ( http://www.manning.com/rademakers ). Он часто выступает на конференциях Java, таких как JavaPolis, JavaZone, JavaOne и NL-JUG, о проектах корпоративной интеграции с открытым исходным кодом, таких как Mule, ServiceMix, jBPM и Axis2.

Тийс Радемакерс

Tijs — разработчик программного обеспечения, работающий на Atos Origin и специализирующийся на интеграции предприятия. Tijs является соавтором будущей книги Мэннинга «ESB с открытым исходным кодом в действии» ( http://www.manning.com/rademakers ). Он часто выступает на конференциях по Java, таких как JavaPolis, JavaZone, JavaOne и NL-JUG, о проектах корпоративной интеграции с открытым исходным кодом, таких как Mule, ServiceMix, Apache Synapse и Apache Tuscany.