У меня есть приложения Java EE (ear), работающие на отдельных экземплярах JBoss и на другом оборудовании. Я хочу позвонить из

  1. одно приложение к другому, которое находится на другом сервере JBOSS.
  2. Тот же JBOSS, между двумя ушами.
  3. Тот же сервер, между двумя JBOss.

Типы данных связи могут быть любыми. Например; JSON или объекты. Я хочу знать, какие легкие веб-фреймворки Java с открытым исходным кодом я могу использовать для вызова от одного к другому? Вот некоторые из них. Но у меня нет опыта от них. Обычно используются сервисы SOAP и RESTful, и для них существует множество фреймворков.

Пожалуйста, предложите мне узнать из вашего опыта, какие доступные фреймворки подходят для моих требований? Позвольте мне иметь источник, который объяснит любое сравнение. Меня беспокоит то, что методология коммуникации должна быть легкой, поддерживать передачу любых типов данных, не должно быть большого количества конфигураций или стандартов. Фреймворк должен поддерживать простую и безопасную передачу (все коммуникации выполняются в моих приложениях. Поэтому нет необходимости в хорошо структурированных, стандартизованных конфигурациях веса). и это должно быть на Java. Я использую Java 7.

0
Débora 23 Апр 2014 в 05:33

5 ответов

Лучший ответ

Это типичная проблема интеграции. Для интеграции, посредничества, проксирования и т. Д. Различных сервисов и даже передачи данных используйте Apache Camel. Краткий ответ о том, что такое Camel, см. В разделе Что такое Apache Camel?

В Camel вы определяете маршруты с помощью Java DSL или XML Spring DSL. Проксирование веб-службы описано здесь. Используя XML Spring DSL, маршрут будет выглядеть следующим образом:

<route>
    <from uri="jetty:http://0.0.0.0:8080/myapp?matchOnUriPrefix=true"/>
    <to uri="jetty:http://realserverhostname:8090/myapp?bridgeEndpoint=true&amp;throwExceptionOnFailure=false"/>
</route>

Используя Java DSL, это будет:

from("jetty:http://0.0.0.0:8080/myapp?matchOnUriPrefix=true"
    .to("jetty:http://realserverhostname:8090/myapp?bridgeEndpoint=true&amp;throwExceptionOnFailure=false")

Camel поддерживает множество различных протоколов, таких как JSM, SOAP WS, RESTful WS, простой HTTP, TCP. Взгляните на https://camel.apache.org/components.html, чтобы узнать обо всех возможностях. .

В следующем примере показано, как легко определить сервер RESTful с помощью компонента Restlet:

from("restlet:http://localhost:8400/orders/{id}?restletMethod=post")
    .process(new Processor() {
        @Override
        public void process(final Exchange exchange) throws Exception {
            final String res = "received [" + exchange.getIn().getBody(String.class) + "] with order id = " + exchange.getIn().getHeader("id");
            exchange.getIn().setBody(res);
        }
   });

Соответствующий клиент выглядит следующим образом:

 from("direct:start")
     .setBody(constant("Hello, world!!"))
     .to("http://localhost:8400/orders/22?restletMethod=post")
     .log("order: direct start body result = ${bodyAs(String)}")

Тем не менее, Camel поддерживает множество шаблонов интеграции предприятия, таких как сплиттер, агрегатор и т. Д., Которые можно использовать для ваших нужд. Взгляните на http://camel.apache.org/enterprise-integration-patterns. html, чтобы узнать об этом подробнее.

Вы можете просто использовать «обычные» классы Java для преобразования данных и привязать их к маршрутам. Кроме того, существует множество встроенных преобразователей типов для преобразования одного типа данных в другой. Эти преобразователи легко расширяются. См. https://camel.apache.org/type-converter.html.

Вы можете использовать Camel в качестве базовой платформы интеграции и добавить, например, JMS / ActiveMQ для связи. Однако также можно использовать ActiveMQ в качестве основы и добавить Camel для преобразования данных, см. https://activemq.apache.org/broker-camel-component.html : "Компонент верблюда брокера делает это еще проще - он перехватывает сообщения по мере их прохождения через самого брокера, позволяя их изменять и перед тем, как они будут сохранены в хранилище сообщений или доставлены конечным потребителям ". Однако я предпочитаю использовать Camel в качестве основы и добавлять JMS / ActiveMQ для асинхронной связи (например, если требуется постоянство сообщения или если связь должна происходить между разными хостами).

Camel поддерживает огромное количество различных протоколов и форматов. Однако вам не обязательно их использовать, если они вам не нужны. Просто добавьте зависимости в свой pom.xml, если они вам нужны. Apache Camel - небольшая библиотека (11,2 МБ) с минимальными зависимостями для легкого встраивания в любое приложение Java. Camel работает автономно, в движке сервлетов или в контейнере OSGI, таком как Karaf / ServiceMix / JBoss Fuse ESB. Вы можете начать с малого, а приложение может расти, если ваши потребности растут.

Чтобы начать использовать Camel, прочтите прекрасную книгу Клауса Ибсена: http://www.manning.com/ibsen/.

2
Community 23 Май 2017 в 11:46

Исходя из моего понимания вашей ситуации, я думаю, что ESB будет хорошим решением вашей проблемы.

http://en.wikipedia.org/wiki/Enterprise_service_bus

ESB от WSO2 представляет собой довольно легкую ESB с открытым исходным кодом и имеет хорошее активное сообщество. http://wso2.com/products/enterprise-service-bus/

2
Vinay Rao 30 Апр 2014 в 05:31

Вы можете использовать jax-ws для предоставления веб-сервисов из JBoss и вызывать их с помощью javax.xml.soap. Я не знаю, можно ли отправить данные объекта, возможно, вам нужно сериализовать из и в конец xml, отправить его в кодировке как строка base64.

Другой способ - jms.

1
JPhil 30 Апр 2014 в 13:03

Если все остальные перечисленные здесь решения не соответствуют вашим потребностям, вы можете взаимодействовать с приложениями, отправляя данные JSON или XML через HTTP.

Spark - это микро-веб-фреймворк для Java, который позволяет быстро создавать конечные веб-точки.

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

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

1
dMcNavish 1 Май 2014 в 15:36

Простой и открытый выигрыш. Вы можете открывать объекты удаленно разными способами, но Java RMI и EJB ограничивают вас только клиентами Java.

Самый открытый и простой способ сделать это - использовать HTTP в качестве протокола и веб-служб, SOAP или REST (я предпочитаю). Они будут легко взаимодействовать с любым клиентом, даже если он не является Java. Клиенты не должны знать или заботиться о том, что вы выбрали Java и JBOSS для реализации логики сервера.

0
duffymo 3 Май 2014 в 12:19