Подтвердить что ты не робот

Среднее ПО и SOA по примеру

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

  • Сервисно-ориентированная архитектура (SOA)
  • Ориентированное на сообщения промежуточное ПО (MOM)
  • Очередь сообщений
  • Apache Camel
  • Mule
  • EJBs
  • Конечные точки и маршруты
  • Сервисная шина /ESB
  • JMS

После просмотра каждого из них в Интернете/в Википедии я смог получить (по большей части) приличные определения для каждого из них. То, что я не понимаю, , как все эти технологии/концепции работают вместе на сервере, чтобы обеспечить решение 2-го/бизнес-уровня.

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

Изменить. Поскольку я добавил щедрость, у меня было несколько ответов, которые предлагают читать книги. Хотя я ценю всю обратную связь здесь, я просто не могу расстаться с 300 точками репутации за ответ, который, по сути, сводится к "RTM" (особенно, когда я плоский сломан и не могу позволить себе руководство!) Повторить, щедрость и окончательный ответ пойдут кому-то, кто может поразить все эти пули в содержательном, практическом примере. Это не должно быть промежуточным компилятором! Только параграф или два, которые показывают, как все они могут использоваться вместе в гармонии для создания решения бизнес-уровня Java. Еще раз спасибо.

4b9b3361

Ответ 1

Основные принципы SOA: создавать системы как набор сервисов, в которых каждая служба

  • крупнозернистый
  • Interoperable
  • Свободно связанный

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

Что делать, если вы хотите интегрировать эти разрозненные функции, создавая новые решения (например, Amazon store front - это новый сервис, состоящий из службы каталогов, службы корзины покупок и т.д.)?

У вас есть два варианта:

  • Создание новой функции с нуля с учетом 3 принципов. Но это очень дорогостоящие усилия, и это почти никогда не бывает успешным.
  • Эффективной и менее рискованной альтернативой является сборка/составление ее из существующих, проверенных (проверенных) услуг.

Вариант 2 - это где ESBs может помочь с поддержкой маршрутизации, трансформации, мониторинга и т.д. Apache Camel, Mule - это ESB с открытым исходным кодом. Конечные точки и маршруты - это терминология, используемая в EIP (Шаблоны интеграции предприятия), которые эти ESB реализуют. ESB может использовать MOM, когда они хотят маршрутизировать/интегрировать службы, работающие на гетерогенных платформах (например, служба каталогов может работать в системе мэйнфреймов, но корзина покупок реализована с использованием stateful EJBs, работающий на сервере приложений Java). Очередь сообщений - это концепция в MOM, которая выполняет временное хранение сообщения между отправителем и получателем. Это временное хранилище обеспечивает множество преимуществ, таких как асинхронная доставка, гарантированная доставка и т.д. Теперь у меня могут быть несколько поставщиков MOM, таких как IBM (WebSphere MQ), с открытым исходным кодом ActiveMQ и т.д. Мы можем использовать JMS, чтобы кода, независимого от поставщика.

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

MOM не является обязательным требованием для реализации SOA. Напр. если все ваши службы отображаются через SOAP через HTTP, тогда вам не понадобится MOM в этом случае.

Ответ 2

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

  • EJBs Enterprise Java Beans серверная архитектура компонентов. Это позволяет быстро и упростить разработку

    1) распределены (когда несколько серверов приложений взаимодействуют друг с другом, серверные компоненты (например, служба вызывает другую службу, размещенную на другом сервере).

    2) транзакционное - сопротивление bean (DB TXN), самая важная часть любого простого/веб-/распределенного приложения. Простота разработки, например, база конфигурации. Напишите XML, который обрабатывает транзакцию, например. когда совершать, когда откатываться (на исключениях) и т.д. JPA Java Persistance APIs обеспечивают сопоставление отношений объектов. Например, ваша строка таблицы сопоставляется с вашим java-объектом через конфигурацию xml.

    3) безопасная аутентификация (uid/pwd) и авторизация (на основе роли - кто зарегистрирован в пользователе и какова вся его задача).

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

Чтобы преодолеть такие сценарии, в EJB существует множество альтернатив, например, Hibrnate делает такие же вещи, как OR mapping, TXN-обработку, полученную с помощью persistance bean в EJB. Spring, упрощает бизнес-логику (вы можете использовать свой уже построенный класс, который не должен реализовывать какой-либо интерфейс, проверять исключения или расширять некоторые обязательные абстрактные классы).

Теперь дни, большинство из них работают на работе с легким весом, например Spring, Hibernate, IBatis, Axis-2.

  • Сервис-ориентированная архитектура (SOA) Сервис-ориентированная архитектура - это ответ на независимость платформы на уровне предприятия. ИЛИ Чтобы быстрее интегрировать приложение, для связи между различными серверами приложений.

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

Это возможно, потому что веб-службы отправляют сообщение в SOAP (Simple Object Access Protocol) на основе XML. XML используется для обмена данными по любому языку, платформе или сетевому протоколу.

Веб-сервисы могут быть классифицированы на основе SOAP и REST.       SOAP-сервисы JAX-RPC и JAX-WS (http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html)

Веб-службы могут быть разработаны       контракт сначала - сначала напишите WSDL.       сначала код - первый код записи.

Теперь давайте поговорим о том, как начать работу с веб-сервисами практически.

Простейший веб-сервис или мир привет (JAXWS) можно записать следующим образом: http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/

  • Ориентированное на сообщения промежуточное ПО (MOM)
  • JMS
  • Очередь сообщений (точка-точка)

    MOM требуется для преодоления недостатков связи стиля запроса и ответа. Сервер должен быть жив, когда клиент отправляет ответ. Клиент ожидает ответа до того, как сервер выполнит и ответит.

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

    MOM - концепция, а JMS - спецификация этой концепции. Многие производители используют эту спецификацию, например, IBM имеет MQ, OpenJMS с открытым исходным кодом, EMS от Tibco и т.д.

Спецификация JMS имеет в основном два шаблона. Pub/sub и ponin-to-point.

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

Связь "точка-точка" осуществляется через очередь сообщений.

Бизнес-кейс - подумайте, что у вас есть приложение, например, запрос клиента для обслуживания клиентов. Другая сторона у вас есть несколько представителей обслуживания клиентов и других сторонних клиентов, иногда больше, чем представители обслуживания клиентов, в то время как один и только один представитель получит запрос на обработку, и он/она не получит следующий запрос до завершения задания. (В одной очереди с несколькими окнами и когда-либо свободное окно обрабатывает запрос). Вы можете представить себе другую сложность в этом, например, что, если один из node вышел из строя, запрос не обрабатывается, а конкретный тип запроса должен быть обработан конкретным node. и др.

Код продукта: http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java

Потребительский синхронный код: - (классы POJO) http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java

http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

Потребляйте асинхронный код: - (Spring на примере - читает сообщение от адресата, пока программа не будет остановлена.) http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html

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

  • Сервисная шина /ESB
  • Конечные точки и маршруты
  • Apache Camel
  • Mule

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

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

например. http://localhost:8888/Context/MyService?wsdl

в коде: -

    String endpointAddress = "http://localhost:8080/jaxws/services/hello_world?wsdl";

    // Add a port to the Service
    service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);

    HelloWorld hw = service.getPort(HelloWorld.class);
    System.out.println(hw.sayHi("World"));

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

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

Apache Camel и Muel http://camel.apache.org/how-does-camel-compare-to-mule.html обеспечивает решение для интеграции предприятия.

Ответ 3

Шаблоны интеграции предприятия могут помочь вам понять, как все сочетается.

[update:] Ваш последующий вопрос по другому ответу заставил меня понять, что вы путаетесь с конкретными продуктами. Отчасти потому, что программное обеспечение на практике имеет тенденцию отображать более чем одну концепцию, а отчасти потому, что разные компании утверждают, что они предоставляют "все", когда на самом деле они этого не делают.

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

Услуги - это услуги. Вы можете использовать некоторые EJB при их реализации (я только упоминаю об этом, потому что по какой-то причине вы включаете их в свой вопрос).

Средство промежуточного обмена сообщениями - это программное обеспечение, которое получает сообщения от A до B. Это чрезвычайно полезно, но также сложно, и каждый и их брат изобрели свои собственные. Поэтому вам нужна абстракция, которая позволяет избежать блокировки. Это может быть ESB, или, если вы все-Java, то это может быть JMS. Но даже если вы все-Java с JMS, вы все равно можете использовать ESB, потому что это библиотеки всех бит кода Java, которые вам все равно нужно писать (случайные биты логики маршрутизации, переформатирование сообщений и т.д.).

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

Ответ 4

Конечные точки и маршруты: где информация поступает и идет. Очередь сообщений - это один тип конечной точки. Другой тип - Тема сообщения.

Конечная точка - это "логическое имя для вещи", например. PRICE.MSFT, который используется издателем или потребительским приложением для получения или отправки. Темы предоставляют информацию всем подписчикам (один-на-один или один-ко-многим), очереди доставляют сообщения первому, который получает его (обычно один к одному). Забудьте о очередях, все также можно сделать с помощью тем, и темы имеют несколько преимуществ.

Message-Oriented Middleware (MOM): инфраструктура программного обеспечения, которая обеспечивает информацию между темами или queus. Это "ориентированный на сообщения" не "пакетный", а TCP. Таким образом, каждый информационный блоб поставляется в одном, мы надеемся, самоописании, сообщении. Реализация вашей MOM затем дает вам API, где вы можете делать такие вещи, как msg.get( "bid" )

JMS и AMQP являются примерами спецификаций MOM. Реализации MOM являются реальными продуктами, которые реализуют эти спецификации: TIBCO EMS, Websphere MQ, MSMQ, Solace и многие другие.

Apache Camel - очень интересный подход к настройке рабочих процессов в этом мире MOM. Но более продвинутая концепция.

Сервис-ориентированная архитектура (SOA), служебная шина /ESB - это просто новые слова с ключевыми словами, которые раньше назывались EAI (Enterprise Application Integration). Это рекомендации о том, как использовать "MOM" и способ оплаты дорогостоящих консультантов. Что добавляет ESB к MOM - идея думать о том, что ваши издатели являются "сервисами", предоставляющими услугу. Другими словами: не думайте слишком много о том, чего хочет один потребитель прямо сейчас. В будущем может быть 5 потребителей, и издатель должен предоставить услугу, а не "создавать информацию, которую хочет потребитель". (Это станет понятнее, если ваша архитектура выросла до 5+ приложений). Также вы должны иметь некоторую общую объектную модель, возможно, в XML, чтобы сделать вещи простыми между приложениями.

Mule - одна из форм ESB, но ее "не совсем основной поток". Через 5 лет большинство действий промежуточного программного обеспечения, возможно, было перенесено в AMQP или что-то еще.

EJBs: идея Sun о сложных Java-классах, которые запускаются в контейнере. Предполагается облегчить разработку приложений. Но во многих случаях это усложняло ситуацию. Лучшей альтернативой может быть "Spring", но EJB - это нечто другое (а не только MOM). Его больше о том, как разрабатывать более крупные приложения (см. Рисунок IoC).

Если вы смотрите, с чего начать: я бы посоветовал узнать о JMS (все остальные MOM - это simliar, а JMS - основа EJB/Mule,...), и, если у вас нет сверхвысоких требований к производительности, рассмотрите сообщения должны быть TextMessage, содержащие XML. Большинство инструментов доступно в этой области. Или даже более простой, но менее сложный, MapMessage с парами ключ/значение.

Ответ 5

Принимая все ваши требования и упаковывая их в запрос, я столкнулся с отличным примером, который должен соответствовать вашим потребностям:

Я пошел вперед, и полный текст искал книгу, используя функцию Amazon "Поиск внутри этой книги". Он охватывает все рассмотренные вами случаи интеграции, как представляется, тщательно, и вы можете пройти весь процесс проектирования и внедрения.

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

Ответ 6

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

  • Сервисно-ориентированная архитектура (SOA)
    SOA предоставляет набор принципов и методологий для интеграции существующих приложений как слабосвязанных единиц. Из шаблонов интеграции предприятия (см. Ниже): "SOA размывают границу между интеграцией и распределенными приложениями".
  • Сервисная шина /ESB
    ESB является основной концепцией SOA для снижения зависимостей в приложениях в SOA. Вместо множества зависимостей между приложениями каждое приложение подключается к ESB.
  • Информационно-ориентированное промежуточное ПО (MOM)
    MOM - это инфраструктура для отправки и получения сообщений между распределенными системами. Это используется для интеграции приложений. MOM был золотым молотом, прежде чем возникла реклама SOA. Поскольку оба варианта полезны, большие пакеты интеграции предоставляют как ESB, так и MOM (или используют MOM внутри ESB).
  • Очередь сообщений
    Очередь сообщений - это просто технический аспект в архитектуре MOM. Когда отправка/прием сообщений развязаны, сообщение сохраняется в очередях до тех пор, пока получатель не будет готов.
  • Apache Camel
    Когда на рынок вышла книга "Шаблоны интеграции предприятия: проектирование, построение и развертывание решений для обмена сообщениями" , были созданы некоторые программные решения, которые обеспечивают реализацию шаблонов в этой книге. Apache Camel является одним из них. Camel также является частью Apache ServiceMix, который также является ESB с открытым исходным кодом. FuseSource и Talend упаковывают Apache ServiceMix, Apache Camel и Apache Active MQ (MOM) в пакеты с коммерческой поддержкой.
  • Mule
    Mule также представляет собой ESB с открытым исходным кодом и платформу интеграции.
  • EJBs
    Из Википедии: Enterprise JavaBeans (EJB) - это управляемая серверная архитектура компонентов для модульного построения корпоративных приложений. Это означает, что EJB является компонентом внутри приложения и не имеет ничего общего с интеграцией приложений.
  • Конечные точки и маршруты
    Когда вы работаете с Apache Camel, вы разрабатываете маршруты между конечными точками, см. учебник. Короче говоря, сообщение вводит/покидает вашу систему через конечные точки и обрабатывается в потоке, определенном маршрутом.
  • JMS
    JMS или Java Message Service - ориентированное на сообщение промежуточное ПО (MOM) со стандартизованным API Java.

Ответ 7

Интеграция корпоративных приложений (EAI) - ключ к подключению бизнес-приложений к гетерогенным системам. На протяжении многих лет архитекторы интеграционных решений изобретали свое собственное сочетание шаблонов различными способами. Но большинство этих архитектур имеют сходство, инициируя набор общепринятых стандартов в архитектуре интеграционных шаблонов. Большинство этих стандартов описаны в каталоге шаблонов интеграции предприятий, доступном по адресу: http://www.eaipatterns.com/toc.html.

WSO2 ESB

Документация WSO2 Enterprise Service Bus (ESB) 4.7.0! WSO2 ESB - это быстрый, легкий, 100% открытый источник и удобный ESB, распространяемый под лицензией Apache Software v2.0. WSO2 ESB позволяет системным администраторам и разработчикам удобно настраивать маршрутизацию сообщений, посредничество, преобразование, ведение журнала, планирование задач, переход на другой ресурс, балансировку нагрузки и т.д. Он поддерживает наиболее часто используемые шаблоны интеграции предприятий (EIP) и позволяет осуществлять коммутацию на транспорте, eventing, посредничество на основе правил и посредничество на основе приоритетов для расширенных требований интеграции. Время выполнения ESB спроектировано как полностью асинхронное, неблокирующее и потоковое на основе механизма посредничества Apache Synapse.